Crown Jewels: Monitoring vs Mitigating

There are many defenses one can build to protect and monitor systems in the cyber world.  More times than not, one would monitor for a certain type of behavior, but not block (i.e. alert only).

Most typically, this is due to the fact that it might be difficult to have enough fidelity in the detection to distinguish between good and evil and your SLAs would not tolerate mitigations that were constantly causing usability issues.

Additionally, one needs to consider the fact that mitigations will tip off the attacker, and the attacker will, in a lot of cases, get confirmation that you detected and blocked something.  Of course, the attacker would just try again and next time attempt to circumvent detection altogether.  It is for this reason, you never want to have a “block, but don’t alert” policy for anything dealing with attacks, internal recon, lateral movement, C2, exfil, etc.  The only category it might be safe to take that approach with is external recon.

With that said, let’s discuss blocking vs alert only for access to what I would consider “Crown Jewels” – your custom detection database (DB).  Any organization of any size will have a custom detection/mitigation DB, probably by a different name, even if it’s something as basic as a firewall rule set.  But, many mature organizations will take things much further and monitor for all kinds of potential evil activity, possibly all the way up to and including full application whitelisting.  And, in some cases, they will prevent unauthorized use.

One common custom detection your security team may have is looking for odd powershell usage (https://attack.mitre.org/wiki/Technique/T1086).  In addition to looking for “powershell.exe” as the process name, you would probably also have a suppression list of known good script names, paths, and frequent powershell developers to ensure your detection only alerts on odd powershell usage only.  What would happen if an attacker obtains one or more of those detection DBs and is able to read/view it?  They would know exactly what you are alerting on, possibly blocking, and what things you are ignoring.  Why is this bad? Because the attacker will now know how to avoid all of your detections!

Do you think you’ll be okay if you add monitoring around known attack vectors that are trying to get at and read your detection DBs?  How confident are you that you have all the attack vectors covered?  You may feel that if the attacker carries out any of the attack vectors, you stand a good chance of seeing them.  However, more times than not, that is not how it plays out.  Not only are you going to miss attack vectors you are not thinking of, but even if/when you see them, it will be too late.  Let’s assume that you have a 100% (I am confident the odds are not that good; not even close) chance of seeing an attacker on the box and you go into full blown Incident Response (IR) when it happens.  How fast is your IR process?  I doubt that you can pull off the SANS PICERL process in milliseconds/seconds, which is what the response would need to be to stop the attacker.  I can almost guarantee it would take you hours or possibly even days/weeks.

How fast do you think an attacker, with full attack automation, could smash-n-grab what they need and break away?  How valuable do you think this recon info would be in preparation for a follow-on persistent attack?  If an attacker gets in once, they’ll get in again.  When this happens, are you prepared to blow away and rebuild your entire (compromised) detection/mitigation capability?  That is exactly what you will need to do to ensure the attacker doesn’t bypass your security next time.

Some general solutions – ensure your detection/mitigation database is encrypted, the encryption keys are securely handled, related files have the most restrictive directory/file permissions set, ensure the DB cannot be accessed by unauthorized processes, etc.  Consider sending “all” events from your endpoints to a SIEM to perform your signature and behavioral matches there.  This ensures a compromised endpoint will not put the database at immediate risk.

IMO, if an attacker is able to gain access to your entire detection database, you’re screwed.  In fact, the “database” of your capabilities might be one of, if not the, most valuable thing there is to an attacker.  There are some detections that are okay to be in “alert only” mode, but your detection/mitigation DB is not one of them.  It must be protected at all costs.

Image courtesy of Noupload (safe) & OpenClipart-Vectors (diamond) from https://pixabay.com.