How SMBs Can Sift Through Security Alerts and Find What Matters

1. Start by Correlating Alerts To Triage 

An analyst, whether a real person or a hypothetical superpowered nonhuman agent, needs to look at incidents, not individual alerts. It’s truly rare that a single alert is worthy of action. Most of the time, it’s a combination of things, such as a strange sign-on, an impossible geolocation for a user, an anomalous process on a desktop, a business process rule change or a pile of data moving in the wrong direction. Individually, these are interesting but unworthy of action in the sea of daily alerts. However, when these alerts are tied to the same identity, to the same time window and to high-value systems, that’s important. 

Correlating alerts means looking at multiple factors, such as identity, asset, time window and session, geolocation, known indicators of compromise and velocity. Everything must be gathered, deduplicated (because networks always duplicate alerts) and then turned into an incident that can be triaged. 

Correlation doesn’t mean getting rid of raw alert data; it means compiling small pieces and turning them into big pieces before handing them to an analyst. The goal is to give the analyst all of the information they need to decide whether something is important — not just alerts but also contextual information, such as risk profile and recent configuration changes.

2. Score Risk Rigorously for Every Incident 

Cybersecurity vendors typically try to help with this process by assigning a risk score to common vulnerabilities and exposures, and such CVE severities are nice inputs to have. But the real prioritization has to be from a small business’s own risk scoring model. That means knowing a lot about the applications and servers involved. Which are for production, and which are for testing? Which are critical, and which are not? Which are exposed to the internet or have weak internal access controls? Which have sensitive data or are subject to regulatory controls? Which identities are highly privileged, and which are tightly constrained? 

These factors, among others, are inputs to the prioritization process. Security professionals should also include external information, such as the CVE severity and whether there’s active exploitation being observed elsewhere, along with information that is relevant to the incident, such as the scope of the alerts or whether lateral movement is being detected. 

All of this helps an IT team member decide what they need to look at and how much containment or reaction is required. IT leaders shouldn’t think they can make a risk scoring model right the first time. Transparency in risk scoring is important. Analysts need to be able to override priorities, and they’ll be able to do so with greater confidence when they understand why something showed up in their action queue. Their feedback on the accuracy and relevance of incidents is critical to improving the model.

Click the banner below to find the right IT support for your small business.

3. Automate Both Incident Creation and Incident Containment, But Not Equally 

Automated containment is valuable, but IT leaders should avoid over-reliance on artificial intelligence. Obvious conditions and narrow circumstances can be handled by machines; for example, disabling clearly compromised accounts, isolating mischievous endpoints or blocking internet attackers with detectable malice. Those are things small businesses should automate. 

DISCOVER: Find security and continuity solutions tailored for small businesses. 

But be careful. Every automated defense needs to be accompanied by a one-click rollback procedure, an audit trail (with all of the correlated incident alert evidence) and periodic validation. 

IT teams should look at the incidents that can’t be automated, and when they see an incident, they should immediately know all the W’s: who is involved, what happened, where it happened, when it started, why these assets are important and what underlying evidence created the incident. In the most mature threat detection environments, IT personnel must also know what containment actions are recommended. 

When analysts look at incidents that are well structured and supported by appropriate evidence, they can make decisions quickly. This is the risk-decision pipeline that’s so important to modern alert management.

4. Close the Loop on Incidents 

Analysts work through their queues and close out incidents. That cycle has highly valuable information that should be used to improve the threat response system. Incident lifecycles should be analyzed carefully, including which are true positives but benign, which are false positives, which are confirmed break-ins and which are unsupported by sufficient evidence. Was the priority appropriate, and was the recommended fix effective? 

GET THE DETAILS: The right partner can help small businesses gain critical insights into their security risks. 

Bringing together the postmortems of every incident and feeding that back into the system is a critical final step. Correlation rules and guidelines need to be fine-tuned. Asset and data categorizations need to be corrected. Old detections that don’t do anything should be retired, and new correlations to handle new telemetry or attacks should be created. Where possible, automation of responses should be promoted, and existing automations should be evaluated. The goal of this fine-tuning is not to get the incident count down to zero. 

The goal is to turn a data lake full of high-velocity alerts into a manageable stream of contextualized incidents with prioritization and timelines, supporting evidence and (hopefully) containment procedures. Alert volume isn’t a measure of threat reduction; it’s a background metric to let businesses know how big of a database they need. When security professionals focus on incidents, they spend time on what is important, and the organization wins by reducing risk and containing threats.