So we’ve been working on our deception technologies research (have we mentioned we want to hear YOUR story about how YOU are using those?) and one of the things we are trying to understand is how organizations are building business cases for deceptions tools. As Anton said, most of the times deception will be seen as a “nice to have”, not a “must have”. With so many organizations struggling to get money for the musts, how would they get money for a should?
Anton mentioned two main lines to justify the investment:
- Better threat detection
- Better (higher quality) alerts
In general, most arguments will support one of the two points above. However, I think we can add some more:
– More “business aligned” detection: with all these vendors doing things such as SCADA and SWIFT decoys, it looks like one of the key ideas to justify deception tools is the ability to make them very aligned to the attacker motivations. However, in the end, isn’t that just one way of supporting #1 above?
– Cheap (ok, “less expensive”) detection: most of the products out there are not as expensive as other detection technologies, and certainly are cheaper when you consider the TCO – Total Cost of Ownership. They usually cost less from a pure product price point of view and also require less gear/staff to operate. This is, IMO, the #3 on the list above, but could also be seen as an expansion of #2 (high quality alerts -> less resources used for response -> less expensive).
– Less friction or reduced risk of issues: Some security technologies can be problematic to implement, but it’s hard to break anything with deception tools; organizations that are too sensitive about messing with production environments might see deception as a good way to avoid unnecessary risks of disruption. I can see this as an interesting argument for IoT/OT (sensitive healthcare systems, for example). Do we have a #4?
– Acting as an alternative control: This is very similar to the point above. Some organizations will have issues where detection tools relying on sniffing networks, receiving logs or installing agents just cannot be implemented. Think situations like no SPAN ports or taps available/desirable, legacy systems that don’t generate events, performance bottlenecks preventing the generation of log events or installation of agents, etc. When you have all those challenges and still want to improve detection, what do you do? Deception can be the alternative to not doing anything. This looks like a strong #5 to me.
– Diversity of approaches: This is a bit weak, but it makes some sense. You might have many detection systems at network and endpoint level, but you’re still looking for malicious activity among all the noise of normal operations. Doesn’t it just make sense to have something that approaches the problem differently? I know it’s a quite weak argument, but surprisingly I believe many attempts to deploy deception tools start based on this idea. At least for me it is worth a place on the list.
With all these we have a total of 6 points that could be used to justify an investment in deception technologies. What else do you see as a compelling argument for that? Also, how would you compare these tools to other security technologies if you only have resources or budget to deploy one of them? When does deception win?
Again, let us hear your stories!
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.