Resilient Cyber Newsletter #3
"Reasonable" Security, the Evolving CISO role, Supply Chain Attacks, Widespread Memory-Unsafe Open Source Code and Threat Modeling LLM-powered Applications
Let’s start by saying it has been quite a busy week in cybersecurity, aside from the resources and topics I will discuss below, this image from Ryan Naraine, host of the Security Conversations podcast (which I recommend subscribing to) succinctly shows just how much is going on in the space of a week.
From supply chain attacks targeting both open source and vendors, to vulnerabilities in widely used products to data breaches being disclosed impacting major firms - we have a lot going on.
The sad thing is, this is honestly the status quo when it comes to cybersecurity and the problem seems to be getting worse, not better, as more and more criminal and malicious activity targets the digital ecosystem that drives modern society.
Interested in sponsoring an issue of Resilient Cyber?
This includes reaching over 6,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives
Reach out below!
Cybersecurity Leadership & Market Analysis
Defining “Reasonable” Security
The Center for Internet Security (CIS) recently released “A Guide to Defining Reasonable Cybersecurity”.
They point out that in the U.S. there is no national, statutory, cross-sector minimum standard for information security. No uniform way of defining the minimum level of security that should be in place for organizations when it comes to data breaches.
This is of course problematic as we start to see more and more calls for things such as Software Liability and Safe Harbor, including in the latest U.S. National Cybersecurity Strategy.
I unpacked the topic in a piece titled “Software: Liability, Safe Harbor and National Security: A look at the evolving dialogue around software liability, safe harbor, and the role of software in national security”.
It is hard to have liability or safe harbor without a uniform definition of what the minimum level of security, or “reasonable” security actually looks like.
Others have been taking similar efforts to try and define what software liability underpinned by a reasonable definition of security could look like, most notable UC Berkeley Law School Lecturer and Senior Policy Advisor at the Stanford Cyber Policy Center, Jim Dempsey who published a paper titled “Standards for Software Liability: Focus on the Product for Liability, Focus on the Process for Safe Harbor”.
I also had a podcast episode in the past with researcher Chinmayi Sharma and Jim Dempsey titled “Software Liability and Safe Harbor”.
While the CIS publication and software liability aren’t exactly the same, because one is focusing on organizations and their security practices and the other is more focused on software suppliers, the conversations are closely intertwined - as they both seek to define what a minimum level of security should look like.
SEC Charging Organizations for Failing to Maintain Sufficient Cybersecurity
Building on the above discussion around liability and cybersecurity, one key regulator, the Securities and Exchange Commission (SEC) has begun charging firms for “inadequate policies that led to a ransomware attack, resulting in data encryption, data exfiltration and business disruptions.”
In this case, it was a company named R.R> Donnelley & Sons and it settled with a $2.125M civil penalty.
In a LinkedIn post from Kayne McGladrey he points out how the SEC is using its authority to enforce cybersecurity policies, although some SEC commissions disagree with the approach. It isn’t the first time it has happened either, with the first example being SolarWinds, which is under litigation currently in the Souther District of New York.
The examples show how increasingly organizations can face regulatory scrutiny and litigation tied to poor internal security practices and programs.
Is it time to split the CISO role?
An interesting piece from CSO Online discussing how as the CISO’s role has continued to growth in terms of both technical oversight and involvement as well as regulatory aspects and the need to integrate with the business, it may be time to split the CISO role.
I shared this piece on LinkedIn and overwhelmingly people thought it was an awful idea, and I agree.
After years of hearing how CISO’s and Security Leaders need to “speak the language of the business”, some now seem to be throwing up their hands, saying it is too complicated and we need to split the role.
The idea is awful and would further muddy lines of reporting, lower the bar to entry into CISO roles and also undermine years of helping CISO’s evolve to be business-peer executives.
A CISO needs to be a well rounded individual with both a solid technical foundation and business acumen.
NightDragon’s “Evolving CISO Role” Report
Security investment firm NightDragon published a report focusing on the evolving CISO role, including surveying many F500 CISO’s and Security Leaders.
It covers key findings, a focus on the mental health of security leaders (often overlooked) as well as the evolution of the CISO’s team and the importance of effective business leadership.
While there are some highlights, like the overwhelming majority of CISO's saying they feel supported by their leadership and many seeing an increased emphasis for their role in the organizational leadership, there are also some concerning or challenging findings as well.
Some that jumped out to me was the convergence of security functions to broader technology areas and operational areas, challenges with measuring and reporting risks, budget constraints and the ever present workforce/talent woes.
1H 2024 Cyber Security Industry Health Check
Longtime industry analyst Richard Stiennon published his “2024 Cybersecurity Industry Health Check” which demonstrates funding in the cybersecurity ecosystem.
As he points out, the industry is on track to his $16.5 billion in cyber investments, which is 64% more than 2023, and includes 215 investments in over 213 companies.
Richard mentions this could be a breakout year for cyber investing, depending on how the remainder of the year goes and market dynamics at play.
AI
CSA’s SECtember.ai
Cloud Security Alliance has begun starting to tease the agenda for their upcoming “SECtember.ai” event, which should be one to tune into. It will be in-person and streamed online and has three tracks: AI Security Fundamentals, AI Security Governance and Controls, and AI Security Operations and Emerging Trends.
CSA has been putting out a lot of great AI Security content, including comprehensive publications and stood up the AI Safety Initiative, which is chaired by industry leader Caleb Sima.
Skeleton Key - AI Jailbreak Technique
Microsoft has discovered and begun sharing insights around a new generative AI attack they have dubbed “Skeleton Key” because the attack can cause models to ignore guardrails and enable a full bypass of protections.
The attack technique allows the user to cause models to product ordinarily forbidden behaviors - and they mentioned like any other Jailbreak type attack is focused on “narrowing the gap between what the model is capable of doing and what it is willing to do” - meaning, undermining protections and guardrails the model designers have built-in.
Some of their recommended mitigations include input and output filtering, system messages and implementing abuse monitoring.
Probllama - CVE’s in open-source AI Infrastructure Project Ollama
Wiz put together a comprehensive blog covering vulnerabilities discovered in Ollama, which is one of the most popular open-source projects for running AI models. The article is insightful not only for the specific vulnerability, but for the broader context around AI security and demonstrates how widely used open-source projects, including in the AI space can be vulnerable.
Wiz previously provided comprehensive coverage around vulnerabilities impacting Hugging Face and others and has a “State of AI in the Cloud Report” which I recommend checking out as well.
Threat Modeling and Risk Analysis for LLM-Powered Applications
Excellent paper exploring threat modeling and risk analysis specifically tailored for LLM-powered applications. There are unique attacks and considerations that apply to LLM’s and the paper does a great job covering some of them such as data poisoning, prompt injection and jailbreaking among several others.
The authors proposed a framework combining the longstanding threat modeling methodologies STRIDE/DREAD and even utilize a case-study of a custom-built LLM application to demonstrate the value.
Speaking of Threat Modeling for AI/ML systems, the Godfather of Threat Modeling, Adam Shostack has a course titled “Threat Modeling for AI/ML Systems” on LinkedIn learning, using the four questions framework, oriented four course phases:
What are you working on with AI/ML?
What can go wrong with AI/ML Security?
What can go wrong with AI: Trustworthiness
What are you doing to do about it?
Threat modeling is a fundamental activity organizations should be implementing when building new systems, iterating on existing ones and looking to drive secure organizational outcomes.
Thanks for reading Resilient Cyber! Subscribe for FREE to join over 6,000 others and receive new posts and support my work.
AppSec, Supply Chain and Cloud Security
The CloudSec Engineer
Cloud Security leader Marco Lancini has published his “CloudSec Engineer” guide which he says is “A practice guide on how to enter, establish yourself, and thrive in the Cloud Security industry as an individual contributor”
I’m a longtime follower of Marco’s content, especially over the last several years where I found myself holding a variety of cloud security focused roles and have no doubt this will be an incredible resource.
It covers a broad array of critical topics ranging from entering the field, establishing yourself, and thriving.
Cloud continues to grow, and the field offers tremendous opportunities for sharp engineers and that isn’t likely to change soon as more workloads get migrated to cloud-native environments and even the AI craze is underpinned by high-compute workloads in cloud.
WTF is Application Detection and Response (ADR)
I recently had shared a post from James Berthoty of Latio Tech titled “WTF is CDR” where he dove into Cloud Detection & Response. He now has published a follow up piece titled “WTF is Application Detection & Response (ADR)” where he unpacks what ADR is, why the category of tooling has emerged, how it differs from EDR and traditional security tooling and who some of the key players are.
James breaks down some of the key factors making EDR obsolete for cloud apps, such as attacker sophistication, cloud-native applications, growth of applications overall and the convergence between applications and infrastructure, as the latter has now become software-defined as-Code.
TeamViewer Breach: A Potentially Devastating Supply Chain Attack with Global Implications
The widely used TeamViewer disclosed a breach of their enterprise network this past week and attributed it to Russian Foreign Intelligence Service (SVR). It remains to be seen if this will impact customers or products however, a compromise of a leading software vendors network is never a good sign and could lead to a much bigger cascading impact. TeamViewer claims to have over 320 million active deployments across many industry verticals.
The latest announcement as of June 28th from TeamViewer is below
That said, Co-Founder and Chief Security Officer of Red Canary Keith McCammon mentioned that the history of these types of intrusions tell us to assume a significantly broader scope and impacting including third-parties, and I absolutely agree with him, especially given the APT involved here and their past activities.
MOVEit Transfer Critical CVE
I won’t belabor this one long, but MOVEit, which led to one of the largest software supply chain attacks in 2023, impacting many across both industry and U.S. Federal agencies issued a security bulletin for a critical CVE that could allow authentication bypass and some have mentioned already seeing attempts at malicious exploitation in the wild.
Image Credit - Patrick Garrity
Safe to say, given the success of exploiting MOVEit last year, malicious actors will definitely be looking to use this product as an attack vector again in software supply chain attacks.
Polyfill.io Software Supply Chain Attack Hits 100k+ sites
In another software supply chain attack impacting the OSS community and thousands relying on the component in question, a Chinese company bought a domain and GitHub account that controlled the popular polyfill.js library used to support older browsers.
Shortly after, it began redirecting users to fake malicious sites and it is said that the malicious code used has specific protections to mitigate reverse engineering and only activates on specific mobile devices at specific hours.
The original projects author now recommends not using it at all and popular providers like Fastly and Cloudflare have put up secure alternatives for users.
This is another example where there doesn’t have to be a hostile takeover of a project or component to impact the ecosystem, much like in the xz utils case where social engineering was used to assume control.
The OSS ecosystem is vastly under-maintained, and incredibly vulnerable, as I have written about in my book Software Transparency. If you haven’t read it, and are interested in software supply chain security I humbly recommend checking it out.
These attacks are only going to increase as attackers continue to realize the rich attack surface of the OSS ecosystem and the millions of people who rely on it from consumer goods, to critical infrastructure.
Half of all Critical Open Source Projects Contain Memory-Unsafe Code
CISA released a paper exploring memory safety in critical open source projects.
There's been a big emphasis on trying to shift the industry towards "memory safe" programming languages. This makes sense, given a large portion of routinely exploited vulnerabilities and systemic weaknesses (e.g. Common Weaknesses and Enumerations (CWE)'s) are related to memory safety.
- 52% of projects contain code written in memory unsafe languages
- 55% of TOTAL Lines of Code (LoC) for ALL projects were written in memory-unsafe languages
- Even those written in memory safe languages have direct and transitive dependencies written in memory unsafe languages
This of course is concerning, since these projects are heavily used and relied upon widely across the entire digital ecosystem. Further complicating the fact is that these aren't your suppliers, these projects are generally maintained (sometimes poorly) unpaid volunteers so pushes to re-write/re-factor these projects will not be a small feat. Couple that with the fact that attackers continue to target the brittle and target rich open source ecosystem and it is definitely a cause for concern.
For a deeper dive on the state of the open source software ecosystem, I would recommend my recent article titled “Open Source Security Landscape 2024”. Anyone familiar with the state of OSS security shouldn’t be surprised by the findings in the CISA report, and a lack of memory safe languages is just the tip of the iceberg in terms of potential risks to OSS components and the vast ecosystem of applications and software that rely on them.
Microsoft announces Cloud Service CVE’s
This week Microsoft announces they plan to begin issuing CVE’s for Cloud Service vulnerabilities. It was disclosed in their blog titled “Toward greater transparency: Unveiling Cloud Service CVE’s”.
Historically, CVE’s haven’t been assigned to cloud services from CSP’s but instead products and software. Microsoft acknowledged that more and more organizations are now relying on cloud services, and historically CVE’s weren’t assigned due to the shared responsibility model and no actions generally being required to address the vulnerability from the consumer, as it was going to be handled by the CSP’s.
This is part of Microsoft’s Secure Futures Initiative and comes as a time when Microsoft has faced a tone of scrutiny from visible security incidents with far reach, including impacting the U.S. Government and leading to congressional testimonies, as I covered in Issue #1 of the Resilient Cyber Newsletter.
Closing Thoughts
It’s genuinely been a hectic week in the world of cybersecurity and software, both good and bad. While there’s been a lot of great resources around vulnerability management, AI and cloud, there’s also been some not so good activities hogging the headlines.
Software supply chain attacks key among them, impacting both commercial software providers as well as widely used OSS projects. This activity has been rising consistently with no signs of slowing down, as attackers realize the high ROI of targeting a single vendor or project and having an outsized impact across the ecosystem of software consumers.
Some of how have been trying to raise awareness around this attack type for the last several years and luckily there are a lot of great resources out there to get started.
That said, as discussed in this issue of the newsletter when it comes to reasonable security and software liability - vendors likely aren’t going to take drastic action until they’re driven to do so (e.g. regulation).
The uncomfortable truth here is we will get what we deserve, as regulation often has undesired impacts, but when an industry and market fails to regulate itself, leading to market failures, we’re left with no choice.
We will get what we deserve.