So, Anton finally brought the deception subject up on his blog, leaving a small bait for me at the end of his post. Ok, that’s a great subject to return to my blogging activities in 2016.
A few years ago I jumped into a discussion about honeypots evolution and how to make them more useful for enterprises. The “Honeytoken” term was born at that moment, but it was in fact an old concept (just check Cliff Stoll’s “Cuckoo’s Egg” book, where he applied the idea to catch the hacker playing with his systems back in the 80’s). The idea was widely discussed at that time, but as many other deception techniques, it has never become a mainstream thing and the majority of organizations still don’t do anything similar. Why, we keep asking?
The main reason is that applying deception (I’m considering here deception as a detection mechanism only) is hardly seen as a requirement for having decent security. With most organizations struggling to keep their heads above the water, it wouldn’t make sense to invest time and resources in something that is not a “must”. Deception is certainly not a basic and fundamental security control, and it doesn’t make sense to invest on it when you’re still struggling with the basics. I admire the vendors that offer exclusively deception based solutions: their sales job is far more difficult than those selling things considered required for a minimum level of security.
People would usually read what I just wrote and think “ok, so I can forget about deception, as there’s still a lot to be done that is more important”. Not necessarily. The selection of tools and practices to apply is not a simple decision. It is mostly a resource (budget, people, time) allocation problem, but there are many additional factors that make it far more interesting that it seems. In fact, when planning detection capabilities, constraints and opportunities come in all different shapes and colors. Those will create situations where deception will make sense as the next step or measure to apply. You may have a strong monitoring infrastructure on the perimeter, for example, and not enough resources for big initiatives such as rolling our EDR or NFT for the internal network. Why not put some honeypots in place to minimize some of that gap? I believe this is not as simple as “only the most mature organizations should apply deception”. I believe there is a point in the maturity scale (not the highest!) when deception starts to be one of the things that could be useful for the organization. You know those videogames where you “unlock” new weapons and items that you can use to keep going? Yes, deception is one of the items that are unlocked in the middle of the game.
We’ve been seeing a lot of guidance about how to look for threats inside the organization, working with red and blue teams, considering all phases of the attack chain, etc. We are far past the point where there was a generic recipe of how to do security monitoring right. Your security monitoring capabilities should be a composition assembled according to your environment and the threats you are concerned about. For many cases, applying some deception will eventually make sense. The question is not if organizations in general should be doing it, but if they have it and consider it as part of what they can do.
Apart from organizations planning their own security, there are also the security tools vendors working on the evolution of their products. That’s also an opportunity for deception techniques to be applied. Tools that track users and other entities behavior for anomalies can benefit from deception techniques (with access to honeypots and honeytokens being the ultimate behavior anomaly), and some vendors are already adding that to their feature set. An organization selecting detection products should consider those that can also apply deception techniques, as they will expand the range of available detection capabilities.
As our own research indicates, deception use by organizations is increasing (“By 2018, 10% of enterprises will use deception tools and tactics, and actively participate in deception operations against attackers”). However, I doubt it will ever be considered a “must do” security control. But security practitioners should not discard it as a viable option to improve detection, and those keeping it as part of their toolbox will always have more options to build a good security monitoring environment.
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.