Based upon some conversations I’ve had lately, I feel comfortable stating that some people don’t understand the difference between logging and alerting particularly well. There is an important difference, and it becomes noticeably more important as the volume, velocity, and variety of data within a security operations setting continue to grow. In this post, I hope to illustrate the difference in order to help people mature their security operations programs.
In essence, I think much of the confusion stems from ambiguity around the meaning of the word “alert”. In a security operations setting, an alert is something that needs to be qualified, vetted, and acted on appropriately. Every alert that presents itself to the work queue should be reviewed. Due to resource limitations, an organization can realistically handle only a small number of alerts per day -- say on the order of hundreds per day at a typically resourced organization. We’ve all met people who make statements like, “Our SOC handles 100,000 alerts per day”. Bollocks.
Unfortunately, many technologies use the term “alerts” when they are really producing “logs”. For illustrative purposes, consider the following example. Say we install an IDS, outfit it with the latest ruleset, and set it loose. It will produce tens of thousands or hundreds of thousands of events per day. The vendor will call them alerts, but let’s take a step back and think about what the IDS is producing in actuality. The IDS is producing a notification every time it sees a packet matching a signature that the IDS maintains. To me, this is a log -- a log of network events. I don’t intend to belittle or pick on IDS -- there is huge value to be brought to security operations by IDS and the events it produces. Rather, I am saying that IDS is essentially producing logs to be sent to the SIEM or data warehouse, just like any other network sensor produces.
So, I’m sure you will ask me, “Well, what do you consider an alert then?”. Great question -- thank you for asking. To me, an alert consists of one or more events that match a defined risk, threat, concern, and/or priority to the business with a low incidence of false positives. For example, it is possible that thousands of IDS events, hundreds of proxy log entries, and a DLP event could meet the criteria of a particular alert we have developed. Thus, one alert would fire that happened to involve thousands of event logs.
All of the various network sensors we have are important and contribute to our overall security posture. But, it’s important to remember that they produce logs, and not alerts. Alerts should be specifically designed around our requirements and use cases. Alerts are what get bubbled up to our work queue and provide us with jumping off points into analysis, forensics, and investigation around activity of interest. Because of this, alerts need to be higher in sophistication and fewer in number than logs. The logs that our network sensors produce are an important component of our alerts, but they are not alerts in and of themselves. In my experience, this is an important concept that, when properly understood, contributes to the differentiation between weaker security programs and stronger security programs.
In essence, I think much of the confusion stems from ambiguity around the meaning of the word “alert”. In a security operations setting, an alert is something that needs to be qualified, vetted, and acted on appropriately. Every alert that presents itself to the work queue should be reviewed. Due to resource limitations, an organization can realistically handle only a small number of alerts per day -- say on the order of hundreds per day at a typically resourced organization. We’ve all met people who make statements like, “Our SOC handles 100,000 alerts per day”. Bollocks.
Unfortunately, many technologies use the term “alerts” when they are really producing “logs”. For illustrative purposes, consider the following example. Say we install an IDS, outfit it with the latest ruleset, and set it loose. It will produce tens of thousands or hundreds of thousands of events per day. The vendor will call them alerts, but let’s take a step back and think about what the IDS is producing in actuality. The IDS is producing a notification every time it sees a packet matching a signature that the IDS maintains. To me, this is a log -- a log of network events. I don’t intend to belittle or pick on IDS -- there is huge value to be brought to security operations by IDS and the events it produces. Rather, I am saying that IDS is essentially producing logs to be sent to the SIEM or data warehouse, just like any other network sensor produces.
So, I’m sure you will ask me, “Well, what do you consider an alert then?”. Great question -- thank you for asking. To me, an alert consists of one or more events that match a defined risk, threat, concern, and/or priority to the business with a low incidence of false positives. For example, it is possible that thousands of IDS events, hundreds of proxy log entries, and a DLP event could meet the criteria of a particular alert we have developed. Thus, one alert would fire that happened to involve thousands of event logs.
All of the various network sensors we have are important and contribute to our overall security posture. But, it’s important to remember that they produce logs, and not alerts. Alerts should be specifically designed around our requirements and use cases. Alerts are what get bubbled up to our work queue and provide us with jumping off points into analysis, forensics, and investigation around activity of interest. Because of this, alerts need to be higher in sophistication and fewer in number than logs. The logs that our network sensors produce are an important component of our alerts, but they are not alerts in and of themselves. In my experience, this is an important concept that, when properly understood, contributes to the differentiation between weaker security programs and stronger security programs.
No comments:
Post a Comment