Review: Secure by Demand

Joint guidance for Digital Product Owners & Tech Operators.

Notice: Our FY2024 is coming in Febuary.

Dear Readers,

Often “Secure GenAI” newsletter offers knowledge of threats, mitigation and notices case by case using real situations. For example, we recently learn about a story of US Treasury Department and how their third party vendor manages the risk. Still it did not stop the breach but it was expected.

This time, we send you review with a broader context using the guideline of joint security agencies recently updated on Jan 13 2025. This is a long thorough post with several references.

tl; dr.

Your Security Outcome = Sum of ( your manufactures x Secure by Design principles.)

Following the criteria as above, here is the list of questions to ask your manufactures, considerations and why it matters.

1. Configuration Management:

1. Does the product enable authenticated backup recording and deployment for configuration settings and engineering logic?

2. Does the product have tamper prevention or detection capabilities?

3. Does the manufacturer provide custom processes and response plans for interruptions involving their products or services?

4. Does the product provide alerts for known insecure configurations or attempts to change to less secure configurations?

5. Does the product allow authorization and restriction of configuration changes?

6. Does the product use Open standards for backup files?

2. Logging in the Baseline Product:

7. Does the product log restarts, logins, or changes to the product?
8. Does the product provide telemetry and logs that help predict and prevent process failure?
9. Does the product log security events and safety events by default using open standard logging formats?
10. Does the product have standardized access and change logs for building incident response capabilities?
11. Does the product include authentication events? both successful and unsuccessful
12. Does the product provide logs for data events including create, read, update and delete?
13. Does the product log errors and exceptions?

Best Practices for even logging and threat detection.

Source: Australian Government and joint agencies.

• United States (US) Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and the National Security Agency (NSA)

• United Kingdom (UK) National Cyber Security Centre (NCSC-UK)

• Canadian Centre for Cyber Security (CCCS)

• New Zealand National Cyber Security Centre (NCSC-NZ) and Computer Emergency Response Team (CERT NZ)

• Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and Computer Emergency Response Team Coordination Center (JPCERT/CC)

• The Republic of Korea National Intelligence Services (NIS) and NIS’s National Cyber Security Center (NCSC-Korea)

• Singapore Cyber Security Agency (CSA)

• The Netherlands General Intelligence and Security Service (AIVD) and Military Intelligence and Security Service (MIVD).

1. Develop an enterprise-approved logging policy.

2. Centralise log collection and correlation.

3. Maintain log integrity, including through secure log storage.

4. Develop a detection strategy for relevant threats.

Detection Strategy for Relevant Threats - Detailed Breakdown

1. Core Principles of Detection

• Anomaly-Based Detection: This is the central pillar. Instead of focusing on known malware signatures, the strategy centers on identifying deviations from established "normal" baselines.

• Behavioral Analysis: It focuses on understanding typical user, account, device, and network behaviors and flagging anything that falls outside those norms.

• Proactive Approach: The strategy advocates for threat hunting to uncover previously unknown attacks or breaches.

2. Key Areas for Detection

• User Behavior: Monitoring for unusual login times, locations, devices, and access patterns.

• Account Activity: Tracking the creation, modification, or re-enabling of user accounts, especially those with elevated privileges.

• Network Traffic: Identifying abnormal communication patterns between devices, unusual network flows, and suspicious connections.

• System Activity: Monitoring for unusual script executions, software installations, and administrative tool usage.

• Security Software: Tracking unauthorized changes to security software configuration or logging settings.

• File/Data Access: Detecting the downloading or exporting of large amounts of data or access to sensitive files.

3. Specific Tactics to Detect LOTL Techniques

• Detailed Logging: Enable robust logging of process creation and command-line activity. This provides essential data to investigate suspicious activity.

• Baseline Legitimate Tools: Establish baselines for normal usage of common system administration tools. LOTL often uses these tools for malicious activity.

• SIEM Detection Rules: Use SIEM tools to create specific detection rules that recognize the methods and tools employed in LOTL attacks.

• Endpoint Detection & Response (EDR): EDR tools monitor activity directly on the endpoint to detect and respond to malicious activity.

• Threat Hunting: Threat hunting involves proactively searching for advanced threats that may not trigger automated alerts.

4. Examples of Anomalous Behavior

• Logins during unusual hours (non-working hours, holidays)

• Account access to services not typically used

• Unusual login devices

• High number of failed login attempts

• Impossible travel (logins from geographically distant locations within short time periods)

• Large volume of data downloads

• Unusual network connections

• Unexpected clearing of logs

• Configuration changes to security tools

• Execution of processes from unusual or suspicious paths.

5. Implementation Aspects

• Real-Time Data: Prioritize real-time analysis of logs, especially for OT environments.

• Timely Ingestion: Ensure quick collection and delivery of logs for effective detection.

• Collaboration: Foster collaboration between IT and OT teams.

• Automation: Where possible, use automation to speed up detection and response.

• Regular Reviews: Continuously update and improve detection strategies as new threats evolve.

6. Specific Areas Mentioned in the Document

• Cloud Environment: Using machine learning to detect irregular API patterns, unusual storage access, and atypical network traffic.

• OT Environment: Monitoring for unexpected use of engineering tools, unauthorized changes, and abnormal communications.

3. Open Standards:

14. Does the product support open, interoperable standards to simplify replacing or adding products?
15. Is the manufacturer demonstrating their alignment to industry regulations or international standards (e.g., ISA/IEC 62443)?
16. Does the manufacturer actively participate in interoperability working groups?

4. Ownership:

17. Does the product enable OT operators to perform necessary actions without an onward dependency on the vendor?
18. Does the manufacturer allow for support contracts with local engineering firms?
19. Does the warranty policy for the product allow for adding security software or products (e.g., firewalls, gateways, continuous monitoring, diodes)?
20. Does the manufacturer have clearly defined roles and responsibilities?

5. Protection of Data:

21. Does the product encrypt data at rest?
22. Does the product have a way to verify the integrity of its data?
23. Does the product share or sell its data to anyone?
24. Does the manufacturer rely on data pushes out of the OT network rather than pulling data out of the OT network?
25. If two-way communication is required, does the product need the operator's approval?

Principles of operational technology cyber security.

Source: Australia Government and joint agencies.