Success breeds…confusion?
AppSec teams face an average of 118,000 vulnerability alerts across their software supply chain. If even 1% of those are being exploited in the wild, finding – and triaging – them in a sea of noise is difficult at best.
Throw in multiple tools – on average, security teams need to monitor 129 applications and manage over 118,000 alerts – — and a development environment where third-party code makes up a significant portion of the codebase
, and it starts to look more like a tsunami.
Eighty-five percent of CISOs believe vulnerability noise and alert fatigue are significant challenges to finding, responding to, and remediating vulnerabilities. This shouldn’t shock anyone working in AppSec, or, more generally,cybersecurity because, as we saw in last week’s post, they’ve seen it all before…
I got tools, they’re multiplying
Fragmented security solutions. Security gaps. Scalability issues. Compliance pressures. False positive rates. Manual security processes. Lack of real-time threat intelligence…
No, we’re not talking about AppSec 2024; this was the state of security over a decade ago. A second generation of tools had made security more proactive and flexible. Detection rates were through the roof. The problem was, there seemed to be a siloed tool for every scenario. Defenders were working across ten or more consoles, each detecting thousands of threats. Someone was going to have to figure out how to get ten into one without losing sight of everything.
AppSec today is in a similar place. Teams are juggling multiple disparate (sometimes static) Application Security Testing (AST) tools. Software composition analysis (SCA), Dynamic Application Security Testing (DAST) and Interactive Application Security Testing (IAST) are enabling a more holistic approach that integrates security into DevOps processes, and preventing siloes. Nonetheless, because many current tools often don’t “talk” to each other, and lack sufficient context to manage growing software supply chain risk, defenders are staring down the barrel of a coverage and visibility gap compounded by alert fatigue and inadequate remediation capacity. AppSec teams are also at risk of becoming bottlenecks in today’s accelerated software development lifecycle (SDLC).
The revolution will not be siloed
For cybersecurity teams, the development of SIEM started the trend toward consolidation and orchestration. It brought the logs of multiple systems into one, giving defenders the context, accuracy and single management console they needed to analyze security data from multiple sources. SIEM also provided the data teams needed to identify threats, along with historical analysis and compliance reporting capabilities.
So far so good. Until, yet again, the data volumes increased, integration difficulties emerged and alert fatigue threatened to overwhelm security teams. Regular fine-tuning of logs for good hygiene, to ensure quality data and prevent
“garbage in, garbage out”added a new administrative burden.
By 2020, Gartner was reporting that 57% of security leaders weren’t getting sufficient value from their SIEM investments. A more integrated, efficient approach to threat detection and response was needed and extended detection and response (XDR) emerged as both the answer and the next revolutionary step. Integrating data from multiple layers, from the endpoint to the network and everything in between, XDR brings advanced analytics and automated response to the table. No one is likely to complain about its claimed 50% reduction in mean-time-to-detect compared to SIEM either.
ASPM: AppSec’s SIEM moment
From an AppSec perspective, we’re currently sitting somewhere in the SIEM-meets-XDR zone. A newer category — Application Security Posture Management (ASPM) — takes multiple siloes like static application security testing (SAST), software composition analysis (SCA), secrets detection, and infrastructure as code (IAC), and brings them into a single management plane. The next jump? Closer to XDR. ASPM provides the aggregation and correlation between products; additional data sources can bring deeper insights and context.
For AppSec defenders, ASPM is a new approach. It involves removing historical siloes between application and vulnerability scanning tools, providing more context and giving AppSec practitioners the ability to prioritize, fix and track issues throughout the SDLC. For example, AppSec teams can now not only identify software libraries used in their code, but also see code flaws, dependencies, and vulnerabilities. The ability to trace source code to all its sources — along with accompanying vulnerabilities — allows teams to move beyond simple identification and into holistic risk management. With ASPM, AppSec and developer teams can evolve from simply finding CVEs to understanding and flagging libraries that are badly maintained/ have poor hygiene/are out of date. This adds the contextual component missing from siloed, traditional AppSec and DevOps processes.
The emergence of context is transformational. For instance, organizations can move from seeing an issue to seeing the specific container it was generated from, and then analyzing it to learn that the issue isn’t within the container, so you can discount it. Or it is inside the container and that makes it very important. Or the issue can be mapped to another location where it can be fixed.
Wouldn’t it be great if we had a common language to describe all of this, so everyone can read from the same playbook?
From Kill Chain to deep dive
Whether you’re looking at SIEM logs or pulling insights from XDR or ASPM, the value of seeing vulnerabilities from the point of view of the attacker becomes crucial. And for that to really work, everyone — security, AppSec and development teams — needs to be on the same page, using the same frameworks and language.
Lockheed Martin’s Cyber Kill Chain provided an early —and influential — framework for breaking down and understanding the stages of an attack, but the scope was limited, there was a lack of detail, and the linear nature of the model didn’t capture the reality of multi-faceted attacks. The process for describing an attack was complicated, a weighting system had to be incorporated, and it had vague descriptions; there wasn’t a common vocabulary everyone could work from. The MITRE ATT&CK framework evolved out of the need to address these shortcomings.
MITRE essentially built a catalog of every type of attack, applied unified naming and vocabulary, and put a structure around it that enabled defenders to describe attacks in a way that security practitioners understood. This same language enabled comparisons and a unified way to talk about coverage and tools. Security professionals finally knew where they stood — and could explain it, simply, to executive teams and boards of directors. It was transformational.
Maybe that kind of thinking could translate in the AppSec world. Wouldn’t it be good to have a solid, unified framework for describing and understanding attacks on the software supply chain?
We’re glad you asked! This week, we’ll take a look at how the OSC&R framework was inspired by MITRE’s success, what’s going on in AppSec and supply chain defense today — and where we’re headed for the future.
Uncover how SIEM is revolutionizing AppSec. – Sign up for a free account of OX
