Deception vs Analytics, or Can Analytics Catch True Unknown Unknowns?

deception

Gartner analyst, Anton Chuvakin, recently published a debate post, looking into deception tools as a way to detect “unknown unknowns”, questioning whether they are the correct detection solution, if they are the most economical solutions, and if they can be the only approach in detecting true unknown unknowns.

Anton describes typical attack scenarios and their detection counterpart, mainly (of course) lateral movement such as network traffic analysis (NTA) and endpoint defense response (EDR). The debate that follows is whether a third and new type of focus can provide better answers — i.e. deception.

Anton also considers SIEM as a viable solution as it combines NTA, EDR, and more. Leaving aside the religious wars about SIEM’s efficacy as a tool, I want to treat the SIEM as an “analytics platform” for combining those various relevant log sources and for the sake of this argument, assume that the SIEM tool works.

To continue Anton’s premise — let’s ignore the “stop the attacker at the border” crowd and assume what many of us must assume, i.e. that the attacker is already inside. Let’s assume he/she managed to take over one of the employee laptops. This did not touch any of the deception technology, so we can move on.

Let’s assume that our attacker is smart and focused. He, or she, is looking for something specific, and their goal is to remain as silent as possible — to remain undetected. Knowing there could be traps, the attacker watches what the laptop he took over does — what other servers it accesses, with whom it communicates, where does it have privileged access, etc. Since it is unlikely that an employee will be regularly communicating with a deception server, the attacker is able to build a list of legitimate resources to target next — the targets of lateral movement, for example.

The attacker can repeat the above technique, uncovering more and more of the legitimate network, and avoid touching the Deceptions — I mean, decoy trap servers.

Let’s go back to our analytics platform — meaning SIEM — and see if it can help. Assuming logs are not tampered, which they usually are, they will contain the network and endpoint trail of everything the attacker did. Let me repeat: those logs will contain the logs generated by the actions of the attacker, even if no actual detection fired. They will contain when the attacker logged into the machine, what did he do, and where he did connect from there; and the logs on that destination to which he connected — they will have more evidence, and so on.

If the attacker managed to avoid firing any endpoint or network alerts, you still have the evidence of the attack in your log repository. If you only use Deception — you have nothing; you’ve deceived yourself.

If you are stuck with a SIEM, then mining those logs is not going to be fun, but mining will be worthwhile nonetheless, because they contain the “UNKNOWN UNKNOWNS”. Those logs are the evidence of it so next time it can be a “known unknown.”
If you do have analytics, and you fed it quality data from the network, the endpoint, the mail gateway, and other quality data, then at least there is a chance it will fire an alert sometime. If your analytics are good, it might even detect it with low false positive.

On-demand webinar: how to achieve autonomous and optimized hunting and detection for cybersecurity

 

Share with your audience

   

    Related posts