Don’t Be a SOC B

coffeefilterJoshua Godfarb wrote an excellent article a while ago that I often reference when trying to explain to non-security types why less is more when it comes to SOC alerts. In his post he basically emphasizes the need to up the signal (high fidelity alerts we are sure about) and turn down the noise (all those false-positives) from the alerts analysts see. In the article Joshua mentions a fictitious SOC A, with high S:N ratio, and SOC B (probably most of us not due to own own fault), with a low S:N ratio. As the use case goes on … of course SOC A stops the bad guys and SOC B gets pwned. At the end he mentions using alert S:N ratio as a metric you might want to start tracking. If you are one of those many SOC Bs out there, SOC A in this article should be your goal.

Here is the relevant part of his post.

The same concept applies to security operations and incident response. In security operations, true positives are the signal, and false positives are the noise. Consider the case of two different Security Operations Centers (SOCs), SOC A and SOC B. In SOC A, the daily work queue contains approximately 100 reliable, high fidelity, actionable alerts. In SOC A, an analyst is able to review each alert. If incident response is necessary for a given alert, it is performed. In SOC B, the daily work queue contains approximately 100,000 alerts, almost all of which are false positives. Analysts attempt to review the alerts of the highest priority.

Because of the large volume of even the highest priority alerts, analysts are not able to successfully review all of the highest priority alerts. Additionally, because of the large number of false positives, SOC B’s analysts become desensitized to alerts and do not take them particularly seriously.

One day, 10 additional alerts relating to payment card stealing malware fire within a few minutes of each other.

In SOC A, where every alert is reviewed by an analyst, where the signal-to-noise ratio is high, and where 10 additional alerts seems like a lot, analysts successfully identify the breach less than 24 hours after it occurs. SOC A’s team is able to perform analysis, containment, and remediation within the first 24 hours of the breach. The team is able to stop the bleeding before any payment card data is exfiltrated. Although there has been some damage, it can be controlled. The organization can assess the damage, respond appropriately, and return to normal business operations.

In SOC B, where an extremely small percentage of the alerts are reviewed by an analyst, where the signal-to-noise ratio is low, and where 10 additional alerts doesn’t even raise an eyebrow, the breach remains undetected. Months later, SOC B will learn of the breach from a third party. The damage will be extensive, and it will take the organization months or years to fully recover.

You can find the full article here.

#####

Today’s post pic is from Wikipedia.org. See ya!

2 comments for “Don’t Be a SOC B

  1. January 8, 2016 at 5:12 pm

    Don’t Be a SOC B https://t.co/hkSSM9N1db

  2. January 8, 2016 at 6:59 pm

    BLOGGED: Don’t Be a SOC B https://t.co/BR3Tod10ck

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.