SECOPS Should Prioritize Alert Forward >
In the last few years, alert-throwing technology has (mostly) done its job. So, now what? Focus on managing the alert forward.
Let’s talk about the birds and the bees. How are alerts made?
Assets > BIOS > OS > Configurations > Software > Events > ( ) > Alerts
I hope that what is contained in ( ) is (SIEM). Assets (servers, laptops, devices) have configurations and software running that write events (log messages) when something of interest happens. These events then need to be reviewed to determine if they are of interest or can be ignored. If they are of interest (meet some configured criteria or absence thereof) then (a SIEM) creates an “alert.” Alerts are sent to ticketing systems or to email inboxes from which analysts determine what should and should not be acted upon.
101 right? It may be basic. It may be simple. But it’s incredibly hard to do in a repeatable, efficient manner. Consistent performance should always result in measurable outcomes. When improvements are made, the impact should be measurable, and inputs adjustable for continuous improvement.
Which part is hard? In my experience, the majority of cyber security professionals focus left of the alert. OS configs, network configs, device types, logging and event management, and aggregation of events into alerts. Then the tsunami came.
The Mandiant APT-1 report opened a floodgate of common awareness that fundamentally shifted the expectations and awareness of Boards and executives.
The Target breach solidified the concept that security tools are doing their job. The methods and processes of reviewing the alerts, and acting on them is where teams struggle.
If thats where the struggle is… then what? Is it reasonable to expect teams to be successful with managing alert forward with capabilities that exist today?
No. It’s not. Here’s why.
“We often see organizations ignoring alarms like this because they’ve become numb to them, receiving too many false positives, or because they’re understaffed,” Chiu [of HyTrust] said. “You can have all the alarms you want, but unless you put security in a prominent position in the company and have enough staff to review them, those alarms don’t mean anything.”
So what do you need to do? Buy better alert-throwing technology?
Clearly, even though FireEye has industry-leading technology rivaled only by Palo Alto Networks, it wasn’t enough. Alert fatigue still existed, and prioritization, workflow and policy decisions failed the Target Security Operations Center team.
As they uploaded exfiltration malware to move stolen credit card numbers — first to staging points spread around the U.S. to cover their tracks, then into their computers in Russia — FireEye spotted them. Bangalore got an alert and flagged the security team in Minneapolis. And then …Nothing happened.
For some reason, Minneapolis didn’t react to the sirens. A FireEye alert that indicated unfamiliar malware: “malware.binary.” Details soon followed, including addresses for the servers where the hackers wanted their stolen data to be sent. As the hackers inserted more versions of the same malware (they may have used as many as five, security researchers say), the security system sent out more alerts, each the most urgent on FireEye’s graded scale.
Poring over computer logs, Target found FireEye’s alerts from Nov. 30 and more from Dec. 2, when hackers installed yet another version of the malware. Not only should those alarms have been impossible to miss, they went off early enough that the hackers hadn’t begun transmitting the stolen card data out of Target’s network.
The point is simple: Tools work. They’re (mostly) doing their job. They create alerts. A lot of alerts. Which one matters? Which should be addressed first? How long should you spend on each alert? What constitutes escalation? How do you escalate and track to resolution? How do you measure the effectiveness of your team at performing these tasks?
Simple. Through a Security Operations Management Platform.
