Do you want to optimize your Mean Time To Response in your SOC? Do not feed your SOC with misconfigurations!

What’s the problem?🤔

You see, there are lots of alerts in your SIEM which your SOC analysts have nothing to do with. Examples could be:

• Unauthenticated service found
• Publicly available endpoint
• Password authentication on SSHD

Security Operation Center is a great resource to find and contain threats, but very often SOC analysts encounter misconfiguration alerts which tell you only about probability of exploitation, not the malicious behaviour / threat has already occured.

This leads to misunderstanding what to do with alert and having your SOC team suffer from finding a responsible member of certain service instead of monitoring actually malicious ongoing behaviour.

Also I like a post from James Berthoty about this problem. Check it out!

Truth is, it is responsibility of your Infrastructure / Application Security team to watch for misconfigurations and communicate this to services. Not your SOC team.

What can be done?📋

To tackle the problem I usually divide alerts into two categories:

• policy events (broken auth, vulnerable service, public s3 bucket, misconfigs)
• security events (bruteforce, anomalous activity, breakglass access, privesc)

Ideally the policy events should be displayed in CSPM, which is monitored by security engineers and security events should be handled by SOC in SIEM and / or CWPP. This simple division outlines the border of seucutiy teams’ responsibilities. If we are taking about classic on-prem infrastructure, than your setup should be like this:

• Vulnerability management and misconfigurations — security engineers
• Anomalous/malicious security events — SOC

The simple advice here is think of a playbook for SOC analyst. If you do not understand, what and how should your SOC analyst process the alert, than this is probably a junk alert.