Briefly Briefed: Newsletter #2 (14/09/23)
Briefly Briefed: Newsletter #2 (14/09/23)
Welcome to week two of the ‘Briefly Briefed:’ newsletter, now with page dividers and 20% more exotic formatting*. There were quite a few interesting posts this week, especially those outlining new frameworks. My top picks are:
The CSPM evaluation matrix by David White. This could be especially useful, if timely.
Clint Gibler and Francis Odum’s particularly comprehensive guide to software supply chain security, it’s a great reference and signposts many additional sources.
Wiz’s spicy write-up of Storm-0558.
Have the day you deserve :o)
Lawrence
*bold text
Funny Cyber Quote || Meme of the Week:
OWASP (in partnership with Google) have launched OpenCRE-Chat.
Utilising Google's conversational PaLM AI technology and powered by the knowledge base of OpenCRE, the chatbot offers reliable answers based on vetted security standards such as ISO, NIST, and OWASP, complete with references. Unlike conventional chatbots, OpenCRE-Chat provides information from trustworthy sources, mitigating the risk of disseminating outdated or unreliable data. Sponsored by the Software Improvement Group (SIG), bot aims to simplify the intricate landscape of cybersecurity standards. Users can now conveniently ask questions and receive ‘authoritative’ answers. I have had a play with this quickly and got mixed results, others have given mixed feedback on LinkedIn when I shared this too.
US CISA (Cybersecurity and Infrastructure Security Agency) released its Open Source Software Security Roadmap, aimed at fortifying the open source software ecosystem.
Acknowledging both the advantages and vulnerabilities inherent in open source software, such as the recent Log4shell incident. The roadmap sets out four key priorities:
1) Defining CISA's role in enhancing OSS security
2) Increasing transparency in OSS usage and associated risks
3) Alleviating risks to federal agencies
4) Reinforcing the robustness of the open source ecosystem. This initiative serves as a strategic guideline for ensuring a more secure digital landscape.
The UK NCSC have released a useful collection of documents outlining an approach to cyber risk management.
The collection covers the following areas:
1. The fundamentals and basics of cyber risk
2. Cyber security risk management framework
3. Cyber security governance
4. Introducing the cyber security risk management toolbox
5. A basic risk assessment and management method
6. Risk management information
7. Introducing cyber security risk quantification
8. Introducing system and component driven risk management approaches
9. System driven risk management methods
10. Component driven risk management methods
11. How to gain and maintain assurance
12. Using attack trees to understand cyber security risk
13. Threat Modelling
14. Using cyber security scenarios
The tl;dr folks release an extremely comprehensive write-up on Software Supply Chain Security by Clint Gibler and Francis Odum
The article provides a breakdown of what constitutes the software supply chain and how to secure each stage.
Wiz release an insightful write-up relating to the recent incident at Microsoft (Storm-0558) by Amitai Cohen
The post provides a summary of key takeaways and questions they feel are still unanswered (amongst other things).
Key Takeaways (from Microsoft’s key takeaways)
1. Log Scanning: Organisations should review logs spanning April 2021 to June 2023 for any activity related to the threat actor.
2. Hardware Security Module (HSM) Use:
Utilise Hardware Security Modules to ensure encryption keys are not exposed in crash dumps.
3. Data Purging: Regularly eliminate debugging and crash dump data to mitigate the risk of sensitive information exposure.
4. Asset Inventory: Maintain a detailed inventory of assets where debugging and crash dump data are stored, enhancing access controls where necessary.
5. Environment Isolation: Isolate sensitive production environments from corporate networks to minimise the risk of cross-contamination.
6. Key Rotation: Rotate cryptographic keys regularly to limit their useful lifespan in the hands of a threat actor.
7. Secret Scanning: Constantly monitor and test mechanisms designed to detect leaking keys between high- and low-trust environments.
8. SDK Defaults: Ensure Software Development Kits (SDKs) include critical security functions by default, or alert developers when manual steps are required.
Unanswered Questions
1. Acquisition of the Signing Key
2. Other Compromised Signing Keys
3. Timing of Engineer's Account Compromise
4. Threat Actor's Goals
5. Extent of Compromise
6. Threat Actor's Target Range
7. Discovery of Vulnerability
A nice write-up on physical penetration testing persistence by Brian Harris
The post focuses on the importance of achieving 'persistence' in physical penetration testing. The blog argues that merely gaining one-time access to a building is insufficient; a truly effective exercise must also assess whether an attacker can repeatedly access the facility without detection. Methods to achieve this include:
1. Cloning Physical Keys: Various techniques, like key impressions and 3D printing, can be used to duplicate keys.
2. Cloning ID Badges: RFID or NFC technologies in ID badges can be cloned, but it’s advised to use multi-factor authentication to heighten security.
3. Lock Replacement: In a slightly YOLO strategy, a lock may be replaced with one that the tester controls.
The blog also stresses the need for ongoing vigilance. After achieving persistence, it is vital to monitor for any changes in security measures. Tailgating, while a useful entry strategy, is deemed insufficient for ensuring persistence due to its limitations like increased suspicion and unpredictability. The overarching message is that organisations should view pentesting, particularly its persistence phase, as a way to uncover deep vulnerabilities and shift towards a more robust, multi-layered security approach.
Contrast Security release an open source Generative AI policy template under a Creative Commons Attribution-ShareAlike 4.0 International License.
“The primary aim of this project is to provide a comprehensible and adoptable policy to control the potential privacy and security risks in using Generative AI and LLMs within your organisation. This open source policy serves as a starting point for CISOs, security professionals, compliance, and risk teams who are new to this domain, and those who have a need to quickly release a policy for their organisations.”
Microsoft released a great checklist of tasks for security teams supporting remote working in Microsoft environments.
A summary of ‘best practice’ actions:
1: Enable Azure AD Multifactor Authentication (MFA)
2: Protect against threats
3: Configure Microsoft Defender for Office 365
4: Configure Microsoft Defender for Identity
5: Turn on Microsoft 365 Defender
6: Configure Intune mobile app protection for phones and tablets
7: Configure MFA and conditional access for guests, including Intune mobile app protection
8: Enrol PCs into device management and require compliant PCs
9: Optimise your network for cloud connectivity
10: Train users
11: Get started with Microsoft Defender for Cloud Apps
12: Monitor for threats and take action
A really handy CSPM (Cloud Security Posture Management) evaluation matrix by David White
The GitHub repo has a link to the conference talk also, explaining how to utilise it.
A useful cheat sheet for incident response in Microsoft Azure by Cado Security
With the rapid migration to the cloud, it’s becoming increasingly difficult to keep track of all of the different data sources, commands, and tools available from each Cloud Service Provider (CSP). The cheat sheet provides incident responders with an overview of key best practices, data sources, and tools that are available when responding to an incident in an Azure environment.
A short but insightful post, outlining emerging threats for the back-end of the year by Florian Roth
A quick summary of the key threats:
1. Token/Cloud API Abuse: Attackers are increasingly exploiting tokens and cloud APIs, which can bypass multi-factor authentication, rendering traditional defences less effective.
2. EDR Scope Evasion: Systems not covered by traditional Endpoint Detection and Response (EDR) are targeted for persistence, as they often lack centralized logging for detection.
3. Vulnerable Driver Usage: Attackers exploit signed vulnerable drivers to disable security measures. Current solutions are slow to adapt to new threats.
4. Malicious File Types: There is a rise in embedding malicious Office documents within PDF files and using HTML files for HTML smuggling, complicating detection.
5. Havoc Implants: The Havoc C2 framework is gaining popularity among threat actors due to its robust feature set and ability to evade detection.
6. Legitimate Remote Access Abuse: Attackers are using legitimate remote access software to evade detection and maintain persistence.
7. Tunnelling: Tools like ngrok and frp are used to proxy internal connections, aligning with the trend of targeting out-of-scope EDR systems.
8. SEO Poisoning: Manipulating search engine results to direct users to malicious sites has surged, with some attacks even being tailored to specific targets.
NIST release SP800-204D (a draft) "Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines."
The draft is focused on Software Supply Chain (SSC) security in cloud-native applications. Developed through DevSecOps and CI/CD pipelines, applications are increasingly vulnerable to both malicious threats and oversights in due diligence. The paper aligns with existing governmental and industry initiatives, offering actionable measures to bolster SSC security in CI/CD pipelines.
There is a particularly interesting case study in the document, which outlines the best practices for implementing GitOps in CI/CD pipelines. It emphasises the need for automation over manual operations and insists on thorough record-keeping of each software release. The study sets out guidelines, including avoiding manual runtime changes and keeping Git commits as the authoritative record for the software's state. It also covers monitoring and remediation procedures to ensure configuration consistency.
International Criminal Court to Prosecute Cyberwar Crimes: A Significant Shift in the Legal Landscape by Andy Greenberg
The International Criminal Court (ICC) has officially expanded its jurisdiction to include cyberwar crimes, as announced by its lead prosecutor, Karim Khan. The decision comes without the necessity of new international laws, such as a "Geneva Convention for cyberwar," allowing the ICC to enforce consequences for cyberattacks against civilian critical infrastructure like hospitals, power grids, and banks. Karim Khan articulated the ICC's new commitment to investigate cybercrimes that could potentially violate the Rome Statute, which is the foundational treaty governing the court's authority.
This shift occurs during increased scrutiny on Russia's cyberattacks against Ukraine, although neither Karim Khan nor the ICC explicitly mentioned Russia or Ukraine in their statements. The prosecution could potentially extend to the command structure responsible for the cyberattacks, making the decision a critical one in international law.