As we mentioned a few times before, we see a lot of “deception as detection” use cases. Frankly, we see nearly all deception projects focused on threat detection (typically of the lateral movement of the attacker and other middle parts of the killchain) and not on the observation of the entrapped attackers and not on distracting (or delaying) the attackers away from production assets.
However, the question is then: what kinds of threats, specifically? To me, the question becomes …
… is this a better way to A) detect mundane threats better (“a better IDS” scenario) or B) a way to detect “better” threats (“an APT catch” scenario).
So far, we’ve seen mostly case A) where the emphasis was on “frictionless” threat detection which does not involve pesky production systems. A typical catch may include relatively elaborate (but not truly novel or advanced) malware, low-impact insiders, and other “suspicious-ish” internal activities. Of course, some of the vendors will sometimes try to position this as “APT detection” (using the corrupted meaning of the word “APT” to mean “malware that passes through traditional AV”)….
Nevertheless, we have seen a tiny number of cases where B) was probably true and deception tools may have enabled the defenders to catch those “top tier” threats.
Finally, we are ready to state, given our fact base, that A) can be made easier with deception tools. However, I hope you do realize that B) will forever remain hard…by definition (if you aim at the top of the threat food chain predator, you will have to work hard)
Our related blog posts on deception:
- Better Data or Better Algorithms?
- Deception as a Feature
- Building a Business Case for Deception
- Tricky: Building a Business Case for A Deception Tool?
- It Is Happening: We Are Starting Our Deception Research!
- New Research: Deception Technologies!
- Yes, Give Deception a Chance!
- “Deception as Detection” or Give Deception a Chance?