Alerts That Matter: Knowing When (and How) to Take Decisive Action

NDR, EDR, NGFW, SIEM, all these tools have at least one thing in common: alerts. There is nothing new about tools generating alerts—warning that something needs attention. Another common thread is that those alerts tend to be low fidelity and high volume, leaving a wide range of issues each competing for an analyst's attention.

Analysts encounter frustrating situations where decisive action is needed to ensure the continuity and stability of business operations, but the set of critical alerts is lost in the noise. The result is alert fatigue and low priority issues being addressed while critical issues can slip through the cracks. This culminates in cyber attacks going undetected or uninvestigated for weeks or months.

A typical incident response cycle looks like:

1. Prepare the incident response plan
2. Detect an incident
3. Analyze incident impact
4. Recover from the incident
5. Add lessons learned to preparation plan

Steps 2-4 in this cycle are the ones we're talking about in this post. Having the right data and mindset can accelerate these steps and assure that each incident helps you harden your systems against similar attacks in the future.

Taking decisive action requires knowing which alerts are important and how to properly respond without impacting critical operations. Responding quickly requires a confident understanding of what has happened and a trust in the data sources and analytics that have been used in detection.

How Do You Know If An Alert Deserves Attention or Not? Context Is Everything.

There are a few ways to examine any given alert and determine whether it represents a real threat that warrants investigation, a false positive for the trash heap, or something in between. Analysts with more experience in a given environment are likely to grow more familiar with the unique factors in that environment, and will probably be faster and more effective at identifying alerts that matter, but there are pieces of contextual information that, if available, any analyst can look at to gauge an alert's significance.

1. Which resources were implicated in the alert? Were any databases or network-attached storage areas involved? If so, the alert likely deserves attention. If you can tell at a glance which database or storage area was affected, that's an even better signal.
2. Which users were involved in the alert? If any users with high administrative privileges were involved, that may indicate stolen credentials or an insider threat—definitely worth investigating.
3. Which devices and protocols were involved? If an IoT device suddenly starts using SSH, that could very well mean the IoT device has been compromised. This behavioral context can provide a quick indicator that an alert is worth investigating.

All of these types of information are great for identifying alerts that matter, but the catch is that they need to be quickly available to the right people. Security analysts need to know which devices were involved, to map IP addresses to specific assets and users, and to determine whether protocol behavior was expected or unusual.

If they have to look at several different tools, or even contact different teams to figure it out, then they'll end up spending a lot of time gathering info before they can determine if an alert is worth responding to. That defeats the purpose.

How Reveal(x) Surfaces Relevant Alert Information

Reducing the time, the number of steps, and the level of expertise required to validate an alert's importance is the best way to be sure to respond to every alert that actually matters. Reveal(x) focuses on reducing the total number of alerts and only surfacing those that deserve investigation, and then providing clear contextual information and investigation guidance to analysts. The result is a faster response cycle requiring fewer resources.

Reveal(x) not only prioritizes alerts and maps them to the MITRE framework, but it simplifies the investigative process by providing critical information right in the alert-generated detection card. All the information covering devices, users, protocols, and behaviors involved in an alert is available on screen immediately, with deeper forensic data available in just a click.

It surfaces the relevant transaction records and packet captures within a single click in every detection, allowing for rapid validation and response to threats. It's also able to directly trigger quarantine events through integrations with vendors like CrowdStrike EDR or Palo Alto NGFWs, several security orchestration, automation, and response (SOAR) platforms. Quarantines can also be triggered via APIs with major cloud service providers like AWS, Azure, and GCP.

Reveal(x) Enables Rapid Response

Responding appropriately to risks and threats requires more than just the ability to detect threats and block traffic. In dynamic enterprise environments that may involve multiple cloud providers, many remote employees, and constant evolution, any action taken to block a security threat may end up impacting productivity and putting business continuity at risk.

Reveal(x) passively analyzes network data, meaning it introduces no latency, and provides rich analytics and highly contextualized detections. Security teams can be confident that they understand the extent and impact of an alert very quickly, so they can respond appropriately. They can base automated responses on rich data, to stop fast acting threats without having to worry about a false positive triggering a shutdown unnecessarily.

This rich contextualization is deepened with a timeline of related detections, showing the sequence of events leading up to any given alert. Analysts can see what happened before and after.

That gives them a complete picture of an attacker's behavior, to precisely and effectively cut off that attacker's access and progress without disrupting related systems. Watch the video at the top of this post to see exactly how quickly and effectively Reveal(x) helps analysts understand the criticality of an alert.