Skip to content

If only I’d known ADR was possible when I was a SOC analyst!

By Will Derksen, Solution Engineer, Contrast Security

October 31, 2024

Threat threat detection incident response SOC detection

    
If only I’d known ADR was possible when I was a SOC analyst!

Paged at 3 a.m. again … we had another breach to respond to in the security operations center (SOC). While the incident response team was busy delegating roles and responsibilities, I was just starting my investigation into root cause analysis. But something was bugging me: We couldn’t figure out how the intruder had gotten in, and we probably never will. I’m about to show you why. 

Before joining Contrast Security, I was a senior SOC analyst for several years, supporting tens of thousands of users across several large private and public sector organizations. With a staff of fewer than 10 people, our team’s workload was quite heavy.

SOCs exist with one primary goal: to detect threats and respond appropriately to stop them. My responsibilities were quite broad and provided a mission-critical function for our organization. I oversaw endpoint detection and response (EDR), log aggregation policy, deployment, and asset management for security information and event management (SIEM) platforms, and database encryption, among other roles. I also supported our security engineering and design implementation and oversaw the deployment and management of an automated incident response tool … and the list goes on.

While we had tools that automated certain processes and tasks, much of the workload was manual—and quite cumbersome. Keeping up with the massive volume of alerts on a daily basis, in addition to my other responsibilities, was challenging. 

If only I’d known that Application Detection and Response (ADR) was possible! My life in the SOC would have been tremendously easier, and I would have been more effective at stopping attacks at the application layer. Without ADR, we had no visibility into applications and application programming interfaces (APIs) and the threats targeting them, making it impossible to detect and understand app-layer intrusions until they made their way into other systems. Letting the threat actor get a foothold is not a desirable method of stopping attacks!

A typical incident life cycle: It all starts with an alert

Every day in the SOC is different. Detecting and responding to attacks typically starts with an alert that notifies the team of anomalies that need investigation.

The expectation in the SOC was that we would respond to alerts within 15 minutes, so we had to streamline and minimize our mean time to detect and respond as much as possible. As stated above, we had some process automation that kicked in once an incident was detected. For example, automated processing of queries in Splunk gave us aggregated data for a specific time period leading up to or after an event started. After that, the process was manual, including probing servers for syslog info and working with the engineering, networking and OS teams as boots on the ground, looking for lateral movement in other systems.

You can reduce MTTR. Here’s how. 

What about application visibility?

When it came to detecting vulnerabilities targeting applications and APIs, we had a couple of issues. As I said, we had no visibility. There were many incidents that started at the application layer, but they were unsolvable. Without the ability to see what was actually happening inside applications and APIs or the ability to understand what anomalous behavior was occurring, it was like trying to build a 1,000-piece puzzle with a lot of missing pieces.

The other issue was that we had no integration with the application development team. As the builders of key applications for internal and external use, they were the revenue generators, and we were the insurance policy to protect them. Having no visibility into what they were doing or how incidents were targeting their work created roadblocks to building trust with them.

We could see downstream events and network and firewall logs to pinpoint where traffic originated, but often, it was a black box because of our inability to see into applications in production. As a result, we had no idea how many attacks came through applications and APIs. We knew attacks were happening, but we could only focus on what we could see and what action to take. Our EDR had a software-based firewall and intrusion detection, but policies would kick in that stopped essential traffic, exacerbating our problems. Without root cause analysis, incident response and incident post-mortems were difficult, tedious and time-consuming, often without clear answers.

At some point, I consulted our security architecture group about the problem. They agreed there was a gap but couldn’t offer guidance on how to address it. We didn’t have a web application firewall (WAF) in place, but even that wouldn’t have protected us. WAFs provide very limited, high-level visibility into the behavior of applications in production, making it difficult to identify, understand and stop emerging threats. So I began searching for “WAF alternatives.” That’s when I discovered Contrast Security.

How ADR would have helped

Having ADR in place would have saved me enormous amounts of time and enabled me to stop threats further up the chain. Developers focus on shifting left, and security professionals should be protecting as much of the attack surface as possible. 

Why shift smart beats shift-left fairytales

Applications and APIs are a part of the attack surface that’s exposed to the internet, and ADR would have empowered our team to identify vulnerabilities, detect threats and stop attacks that targeted this critical layer.

ADR allows you to look for code vulnerabilities in production, which helps SOC teams validate the development team’s security work. Monitoring for both vulnerabilities and attacks in production can provide a full picture of your Application Security (AppSec), your threat position and how to manage it. ADR also provides a single pane of glass, which is hugely beneficial. You can get all the information from one place without multiple clicks and moving around between systems. 

An example of an incident where ADR could have had an impact is when we detected remote code execution (RCE) on a server linked to an application front-end. It was like chasing a dragon trying to figure out how far they got in the system. We saw some fishy activities, looked at logs and tracked areas the threat actor could access that they shouldn’t have. We knew the hacker had been lurking for a while, snooping around in SAP workloads, including invoices, personally identifiable information (PII), PCI-compliant info and more. 

There were security controls that weren't in place that probably should have been. This was definitely a case where multifactor authentication (MFA) wasn’t commonplace. There were service-level accounts with passwords that probably needed to be updated. From that perspective, it could have looked like any of us on the team had been logging into the server. That entry point is more than likely: He may have seen an open port, or he saw an application with an easily exploitable means to get into the server and then move laterally.

It’s very likely that they’d been in the system for quite a long time, and that they’d been planning their next move. Then, when they executed, they might have got what they needed. Who knows?

With ADR, we could have spotted the threat actor’s activities much earlier on and taken preventive action to stop him from penetrating other systems.

When I talk to prospects now, they commonly ask, “What does ADR do?” Once they grasp the capabilities, they usually agree that the solution offers tremendous potential value and want to know more. 

Contrast Security’s ADR is the next evolution in Application Security (AppSec), arming security teams with the means to:

  • See attacks on applications and APIs: Security operations teams can now get real-time alerts that include crucial context and fewer false positives on devastating attacks such as command injection, path traversal and SQL injection. 
  • Stop attacks on applications and APIs: SecOps teams can choose to utilize Contrast ADR’s real-time attack blocking capabilities or perform incident response actions as defined by their standard security workflows. 
  • Improve detection & response with new SOC integrations: Security analysts can now take faster action armed with better attack intelligence on application and API attacks by leveraging the consoles of leading security information and event management (SIEM), cloud-native application protection platform (CNAPP), and extended detection and response (XDR) platforms. 

September attack data: Spotlight on path traversal,
one of the gnarliest application attack types

If I’d had access to ADR as a SOC analyst, it would have been a game-changer. ADR fills the glaring gap in application and API visibility, giving SOC teams the tools to detect and respond to threats that traditional systems miss. With real-time alerts, fewer false positives, and the ability to stop attacks before they wreak havoc, ADR streamlines security operations and allows for faster, more effective threat response. It's a must-have for any security team looking to safeguard their application layer and stay ahead of attackers.

To learn more about how ADR technology can protect your organization, request a demo of Contrast Security ADR to see its capabilities in action.

See Contrast ADR for yourself

Read more: 
Threat threat detection incident response SOC detection
Will Derksen, Solution Engineer, Contrast Security

Will Derksen, Solution Engineer, Contrast Security

Previous

Cybersecurity Insights with Contrast CISO David Lindner | 10/25/24