Current alerting systems have many issues, but the problem really traces back to the ability to track so much data, and a complex security stack that logs everything (or most of the things) going on in a network.
Then, there is an eternal struggle to make sense of all that data. especially if it’s isolated within each original system, because of the resources it can take to do so. This process takes time and human analysis to piece together and derive meaning, and often it takes weeks or even months to wade through all of the alerts to choose which are the biggest priority — which is way too long, and also means that by the time the security team addresses something critical, it may be too late.
As a security expert, you know this is a problem so you install a “smart” log collector or a SIEM, but even those systems aren’t really as smart as SOC teams need them to be. They require operators to learn complicated query languages, and then, even after the query language is mastered, building automated searches based on individual or group behaviors is extremely complicated (often impossible) because the system isn’t built to decipher subjective concepts — such as “normal” or “anomalous.” In this scenario, these systems still require analysts to connect the dots themselves if they want to figure out which alerts are related, and which are critical.
So, what is the answer? To figure this out, we have to look at what exactly the different stakeholders in the SOC need.
The Architect’s Perspective
As a security architect, I need monitoring products to be able to share data between themselves in order to synchronize operations and simplify detection and investigation tasks.
In most cybersecurity systems, this is done via the sharing of an alert of some kind, by way of either a push or pull mechanism.
- In a push scenario, I expect the data to be shared via a standard protocol that other systems are aware of (i.e. not a custom protocol).
- In a pull scenario, I expect the data format to be one that’s well-known and does not require that complex parsers be built on the “puller side.”
As the alerting system changes, I should not have to re-architect how the mechanism works in other devices (backwards compatible version support is needed if a change is forced). I am measured on how well I can present contextual information to security analysts so they can make faster decisions, which is why alerting that works properly is critical to my success and therefore the success of the products I implement.
My primary integration point will likely be with my SIEM system, and I’d love to have a set of search terms built that correlate data from my enterprise security applications with alerts from the behavioral analytics platform so I don’t have to do this from scratch. A pre-built architecture with solutions like Splunk would be great to have. They would also save me time in coming up with this on my own.
The Analyst’s Perspective
As a security analyst, I need to be alerted when something that is deemed “interesting” is spotted so that I do not have to sit in front of the UI and wait for things to happen.
With most monitoring products, I’m allowed to create an alert to be sent to my mailbox via SMTP (or SMS, or another app) with enough detail that I can make an actionable decision. The decision comes down to, “Is this something for which I need to drop what I’m doing and deal with right now?”
If there’s not enough information to make that decision, the alert is not useful to me. I expect flexibility for my alerts. For example, the ability to make my alerts contain different content than alerts to others on my team, as I’m the network security owner and am interested in network-security-related information. I expect the ability to change the order in which data is presented to me, the size of that data, and the format in which it is sent.
I also carry a mobile phone, and I’d prefer to get alerts via an app that I can control when, where, and how I am alerted. I’m not always at work, but I do monitor situations on weekends and need to determine whether I excuse myself from dinenr with my family to jump on an alert. I also need a mechanism to let the system know that I do not want an alert of this type or from this user, host, and/or destination, at this time of day, or with this risk score.
I will make many changes to alerting configurations early in my deployment, but over time I will only make a few. It would delight me if the system self-tuned its alerting based on my feedback, and improved and/or configured itself rather than me explicitly changing it. It would also be great to be able to know what alerts I’m not seeing at any given time, so I can adjust that configuration as needed.
The Solution for All
Alerting today uses many tools and simply requires too much manual work for architects and analysts, which instead could be offloaded to a “smart” machine that is built with machine learning. This would allow more efficiency in alert handling, and would be more effective in mitigating breaches before anything bad can happen.
E8 Security’s Fusion Platform is powered by big data and smart machine learning. It identifies the “who” behind every alert and combines otherwise seemingly isolated log entries and alerts from different technologies and vendors to show analysts the complete sequence of events. These features provide unprecedented visibility into the digital goings-on within an enterprise. E8 Security delivers this to customers so that architects can easily set up a system, and analysts can easily explore situational information and event details, discover new indicators, and come to conclusions quickly.