Just what, exactly, is “security observability?”
One way to answer is to look at a simple example of when having observability could make the difference between losing weekends researching a security scenario vs. having all the information you need, generated painlessly and automatically. Let’s say you have a third-party library that’s potentially vulnerable to JNDI injection, as was the situation with the Log4j library and its calamitous Log4Shell vulnerability.
Wouldn’t it have been nice to have visibility into what routes contained those libraries?
We’re talking about a live security blueprint: a way to monitor all application and application programming interface (API) activities in multiple directions, including attack surface, defenses, dangerous methods, and outbound calls to API endpoints, system interactions, database connections and file system interactions.
Observability answers an essential question: i.e., what does each workload do? To answer, security teams need to know:
- What’s the environment? Server, platform, upstream, configuration and other details?
- What is the attack surface?
- What defenses are in place for each route?
- How are authentication, authorization and encryption managed and used, and how often?
- What dangerous functions are called, using which interpreters, parsers, filesystems, network functions and more?
- What services and connections are used?
- What are the data characteristics?
Roll back the clock to December 2021: A blueprint that showed not only what routes contained the Log4j library but also whether there was a vulnerable path to access that library would have been a lifesaver for the countless security teams that spent their weekends scrambling to track down the ubiquitous library … a vulnerability that, if exploited, could have allowed unauthenticated remote code execution (RCE), granting attackers control over both an exploited application and the server it sits on.
For the sake of Log4Shell and countless other use cases where a security blueprint is desperately needed, Contrast showcased a groundbreaking observability capability — Security Observability, aka Contrast Observability — at Black Hat 2023. This innovative feature can automatically create a contextual security blueprint that contains the details you need regarding how applications and APIs actually work.
Recently, Contrast Co-Founder and Chief Technology Officer Jeff Williams drilled down into how software and security teams can use these blueprints. Read on if you’re sick and tired of wasting countless hours in conversations with development teams, manually drawing data flow diagrams and threat models to better understand your systems when the security team needs to effectively assess and manage the risks of complex application architectures.
Why is Security Observability so important?
A: The evolving threat landscape makes it an imperative. Given our current fast-paced, interconnected digital landscape, application/API security faces multiple challenges: For all the good we’re seeing from technological advancements, they’ve also increased complexity and obscured visibility.
According to Deloitte Insights, 79% of organizations say they’ve got an asset visibility gap, and that obscurity is leading to 3x more incidents. The sheer volume, sophistication and difficulty of detecting cyberattacks is simply overwhelming to humans.
What we need to keep our heads above water is Runtime Security, which includes Security Observability as well as runtime security testing, runtime SCA, and runtime protection. You’ve got to have real-time insights into the behavior of your applications and APIs while they’re in operation: That’s how you can detect and neutralize potential threats before they can cause significant damage.
Q: Does Security Observability enable teams to be more proactive than monitoring?
A: The primary purpose of security monitoring is to detect and respond to known threats and anomalies in real time or near-real time. It focuses on identifying and alerting security teams to specific events or patterns that have already been defined as being security concerns.
Security Observability, on the other hand, has a broader purpose: It’s not limited to detecting known threats or predefined events. Rather, it’s about gaining a comprehensive understanding of the entire security landscape, as well as understanding the overall security posture.
This involves going beyond a focus on specific security incidents or known attack vectors and instead taking a more holistic approach by collecting and analyzing a wide range of data, including logs, metrics and traces, to provide a deep and comprehensive understanding of the security environment — in other words, it’s a blueprint not a list of issues.
It comes down to the difference between being proactive vs. reactive: Whereas security monitoring involves responding to known threats or events as they occur, and alerting security teams to take action, Security Observability helps organizations better understand their overall security posture.
Q: What are the biggest use cases for Security Observability?
A: Security teams can leverage security blueprints for a variety of use cases. Maybe the best way to think about it is that Security Observability makes everything in Application Security better. All AppSec activities benefit from having detailed, accurate, real-time insight into exactly how security works in a workload. Observability enables effective communication between development, security and operations teams using accurate, real-time data.
(See below for specific use cases.)
Use case: Threat modeling
Q: What’s wrong with the threat-modeling tools now on the market?
A: The threat-modeling tools that are available on the market — like IriusRisk, Microsoft Threat Modeling and things like that — are fairly primitive.
They're mostly data-gathering tools that require answering a ton of questions to try to figure out what the blueprint is, and then they try to lead through some processes to help identify threats and make sure the right security mechanisms are in place.
Threat modeling is super labor-intensive. It often entails several weeks of data gathering and interviews with architects and other people on the project to try to just get a picture pulled together of how the application actually works.
Sometimes an old, often out-of-date Visio diagram is available. But threat modelers often have to create their own pictures. Security observability can save those teams all the work gathering all that data and drawing those pictures.
Observability could end up making organizations’ threat modeling practice much more scalable, much more cost effective, because really, nobody can do threat modeling at scale. There are just not enough people that are skilled enough to do it, and it's very time-consuming.
Use case: Penetration testing
Q: Does Security Observability help with penetration testing?
A: There’s interest from penetration-testing teams that want to be much more efficient about how they test applications. Observability will offer targeted pen testing, delivering insights that help security teams focus penetration testing for maximum efficiency and effectiveness. My estimate is that if you use Contrast as part of a pen test, you could probably cut the labor involved in the pen test by something like 50% or 75%.
Observability will also enable recon and exercise applications that will be able to expose vulnerable behavior and components, the targeting of analysis based on discovered data and actual application behavior, and the ability to determine the exploitability of found vulnerabilities using observed behavior data.
Use case: Risk prioritization
Q: Does Security Observability help with risk rating and prioritization?
A: We’re looking at contextual risk assessment, in which security teams can better understand and prioritize risk associated with each vulnerability, determine exploitability based on controls and context, generate a risk score for each vulnerability based on its context within the application, and create detailed risk reports incorporating real-time data for stakeholders. It will identify the services, APIs, files and databases accessed by the application, which will enable teams to assess and rank vulnerabilities based on potential impact.
Use case: Incident response & forensics
Q: Can this contextualized data be used in incident response?
A: Absolutely. With the context provided by Security Observability, security operations teams will be able to quickly understand security incidents and create highly focused response plans. Without a security blueprint, these teams waste valuable time doing research and gathering context manually. Observability will enable them to instead determine the blast radius of a potential exploit.
We know that observability is a fundamental capability: It gives our customers a blueprint for their applications for how security actually works. Our customers may figure out cool things to do with those blueprints that we haven't thought of yet. Who knows? Maybe they’ll feed them to their quality teams. We’re eager to see what they do with these security blueprints.
Q: How does Contrast’s Observability feature improve on threat-modeling tools?
A: By gathering all this data automatically and allowing our customers to basically ask questions. For example, if you said, ‘Hey, Contrast, I want to see all the routes that don't have authorization checks on them,’ Contrast can answer that question immediately. You don't need to export that data anywhere or do anything with it.
Q: What’s the difference in technology approaches between threat modeling and what Contrast is offering with Observability?
A: We do it with lightweight instrumentation that offers continuous monitoring for high-performance examination of real application behavior, which carves clarity out of the complexity. It's not just about finding vulnerabilities — it's about understanding your applications' heartbeats, the intricate connections they make and the hidden risks they carry. Contrast Observability will transform a typical security assessment program from a vague, time-consuming endeavor to an accurate and efficient process.
How will security teams be able to consume Observability data?
Q: Do you need visualization tools to make sense of the threat-model data that Contrast collects?
A: It's just a table full of data, which is actually really useful.
I look forward to when we have better visualization tools for the threat-model data that we've collected. Like, I'd love to see a picture. But I don't necessarily think people will export it to other places, because I don't know where they would export it to. I think most people will just use it right where it's at.
Q: What about importing the data into security information event management (SIEM) platforms?
A: That would be another way of analyzing the data. I don't think SIEM is particularly well-suited to threat models, but it is a place where you could store that kind of time-series data and do stuff with it.
Q: Will there be any correlation to observability in Software Bills of Materials (SBOMs)?
A: Security Observability tools continuously create Runtime SBOMs, automatically detecting which libraries are actually used by applications and APIs. This will enable organizations to identify security gaps in the software supply chain and to focus on exploitable vulnerabilities.
Related: