One of the most memorable parts of Black Hat was an interview with Alan Shimel of TechStrong TV and Katie Norton, Research Director at IDC. We had a wide-ranging discussion about the state of AppSec and DevSecOps. The segment provided a great opportunity to talk about the deficiencies in these current approaches to Application Security (AppSec) and how our new Application Detection and Response (ADR) model offers a path to better security for applications and application programming interfaces (APIs). I encourage you to watch the interview. I've also provided a summary below.
AppSec isn’t working in production
We agreed that DevSecOps and AppSec were not functioning in production environments. All they’re doing is producing huge backlogs of vulnerabilities in development. According to a Ponemon study, the average organization has a backlog of 1.1 million vulnerabilities. But most organizations don’t have any visibility into attacks or a way to prevent those vulnerabilities from being exploited.
What’s arguably worse is that DevSecOps and AppSec don’t do much to protect software that’s in production. People really don't have visibility into what's going on in production in their apps and APIs from a security perspective. They don't see attacks.
The irony here is that DevSecOps was meant to break down barriers between teams and processes, but in many critical ways, it has simply created new silos in Dev and Ops. This has to do with the way the tools work. They create silos because they produce backlogs that nobody wants to touch. It’s like, “Here, let that group over there manage this giant pile of stuff.” That’s not a good way to bring people together.
The fact that DevSecOps often wants developers to function like security professionals further compounds this problem. Likewise, security pros are never going to be developers. We need to find ways to empower everyone to deal with application and API incidents that happen in production.
Filling the gaps with ADR
We officially announced Contrast ADR at Black Hat. ADR is exactly what you think: Just like endpoint detection and response (EDR), cloud detection and response (CDR), network detection and response (NDR) and the rest of the extended detection and response (XDR) ecosystem, you install ADR on your application and API servers, and it detects incidents, reports to Operations and intervenes to prevent exploits. ADR fills in these various security gaps at the application layer and integrates right into the existing XDR, security information and event management (SIEM) and cloud-native application protection platform (CNAPP) ecosystem. This includes both applications and APIs. When an ADR solution sees an attack, it can share telemetry about it — as well as the full context — with the security operations center (SOC) team; security orchestration, automation and response (SOAR) platforms; and so forth.
ADR brings Development and Operations together with context
Katie Norton had an important observation about the “context” needed to interpret and measure both vulnerabilities and attacks. There’s a huge chasm between what developers see and what's happening in the SOC. For instance, how do these two groups come together to prioritize vulnerabilities for remediation, when developers can’t see threats and attacks? And Operations staff can’t understand what application and API workloads do or where they are vulnerable. Enter ADR: By providing the full production context to both development and operations, ADR is a huge lever that needs to be pulled in the larger prioritization problem. You can’t prioritize what you need to do with just code context, so we leverage production security observability. This provides the full risk context to developers as well as keeping Operations aware of potential danger areas.
API security is just AppSec
Our discussion veered off into a relevant tangent involving the differences between AppSec and API security. Security professionals have been told to treat API security as separate and different from AppSec, but isn’t it really the same? The three of us came to a consensus that an API is simply another piece of software and libraries that requires security testing, detection and response. You don't need a bunch of separate tools doing essentially the same thing.
Katie Norton had a distinctive take on this question, which is that API protection has mostly been on the production side of things. The problem is that you can't understand the code part from the production. Web application firewalls (WAFs) give you telemetry about API traffic, which comprises a lot of network traffic these days. But WAFs don’t show you much about the API code.
Translating to make DevSecOps work
How do you close this chasm? ADR offers a solution. It bridges the gap by essentially serving as a translator. For instance, operations teams generally don’t talk about vulnerabilities, remediation and backlog. Developers don’t talk about SIEM events and SOAR playbooks. The goal with ADR was to create software that understands how to speak both languages and provide the data that people need to get their jobs done, regardless of their role. In this, the accuracy of the data is critical. With good quality data, everyone can work together to make DevSecOps work better.
Conclusion
ADR is new, and we have just started to engage with customers on putting it to work for AppSec. Everyone we’ve spoken to has recognized the need for it. The gaps, the silos, the lack of visibility — these are real issues that security professionals, developers and Operations need to solve. ADR solves these problems by providing data about attacks occurring in production and sharing enriched alerts with the SOC team and other critical stakeholders.
Read more:
.jpg)