Many of my recent blog postings have been focused on incident response. I've written these blog postings from the vantage point of an organization already in the midst of an incident response. In other words, many of the recent blog postings assume that an organization has already detected or been notified of a breach. Some people have asked, rightfully so, about the detection piece of the picture. This is an excellent question, and I would like to discuss this question in this blog posting.
At a high level, the modern threat landscape necessitates fairly sophisticated detection techniques. Several years ago, it was often possible to identify malicious activity by looking for traffic to a specific IP address or domain. Those days have left us, and as we've discussed previously, attackers have moved up the stack. Modern detection techniques need to be granular, flexibly leveraging layer 7 meta-data fields deep into the packet. At the same time, alerts, and the rule logic that goes into those alerts, need to be sophisticated and tightened to hone in on the specific activity of concern without generating high volumes of false positives.
To illustrate this concept, consider these two different approaches to alert writing. The first approach uses a domain name watch list approach to alerting, which was very popular about a decade ago, and to some extent remains popular today. The second approach uses the domain name watch list as one element of a much more complex logical structure. In my estimation, this is the new frontier of alert writing, and it is already being used in some organizations with more mature incident response functions.
Approach 1: Alert on all traffic to dynamic DNS provider domain names.
Approach 2: Alert on all Office documents leaving the network destined for dynamic DNS provider domain names that currently resolve to public, routable IP addresses, but previously resolved to private, non-routable IP addresses.
As you can see, approach 2 is far more likely to zero in on suspect traffic than approach 1, which is far more likely to generate high volumes of false positives. So why don't more organizations write alerting in the style of approach 2, rather than in the style of approach 1? The answer is often that many organizations do not have technology solutions that allow them to write the incisive alerting they need.
Based on my experience designing and implementing alerting and workflow over the past decade+, technologies that allow the analyst to design sophisticated, granular, incisive, and intelligent alerts are long overdue. Isn't it about time we allowed our alert writers to move up the stack with the attackers?
At a high level, the modern threat landscape necessitates fairly sophisticated detection techniques. Several years ago, it was often possible to identify malicious activity by looking for traffic to a specific IP address or domain. Those days have left us, and as we've discussed previously, attackers have moved up the stack. Modern detection techniques need to be granular, flexibly leveraging layer 7 meta-data fields deep into the packet. At the same time, alerts, and the rule logic that goes into those alerts, need to be sophisticated and tightened to hone in on the specific activity of concern without generating high volumes of false positives.
To illustrate this concept, consider these two different approaches to alert writing. The first approach uses a domain name watch list approach to alerting, which was very popular about a decade ago, and to some extent remains popular today. The second approach uses the domain name watch list as one element of a much more complex logical structure. In my estimation, this is the new frontier of alert writing, and it is already being used in some organizations with more mature incident response functions.
Approach 1: Alert on all traffic to dynamic DNS provider domain names.
Approach 2: Alert on all Office documents leaving the network destined for dynamic DNS provider domain names that currently resolve to public, routable IP addresses, but previously resolved to private, non-routable IP addresses.
As you can see, approach 2 is far more likely to zero in on suspect traffic than approach 1, which is far more likely to generate high volumes of false positives. So why don't more organizations write alerting in the style of approach 2, rather than in the style of approach 1? The answer is often that many organizations do not have technology solutions that allow them to write the incisive alerting they need.
Based on my experience designing and implementing alerting and workflow over the past decade+, technologies that allow the analyst to design sophisticated, granular, incisive, and intelligent alerts are long overdue. Isn't it about time we allowed our alert writers to move up the stack with the attackers?
No comments:
Post a Comment