Gartner Blog Network


Yes, Give Deception a Chance!

by Augusto Barros  |  January 14, 2016  |  6 Comments

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.

Category: future  honeypots-and-honeytokens  insights-and-philosophical  threat-detection  

Tags: deception  honeypots  honeytokens  security-monitoring  

Augusto Barros
Research Director
1 years at Gartner
19 years IT Industry

Augusto Barros is Research Director in the Gartner for Technical Professionals (GTP) Security and Risk Management group. Read Full Bio


Thoughts on Yes, Give Deception a Chance!


  1. Andre Gironda says:

    I see deception everywhere. From a baseline perspective, all threat-based information (sub computer, sub cyber) risk is deception. Malware is deception. DDoS is deception. It’s all deception, right?

    What is missing, specifically, is an understanding of external threat versus insider threat — and/or coordination thereof. What most people do not understand is that the major difference is between trusted insider (think Snowden) and unintentional insider (think everyone who clicks on links in emails, spear-phished or not). Deception systems, such as deception engagement servers and deception engagement credentials (but also web-bug image solutions such as OpenCanary) provide the ability to catch both types of insiders and provide more details to the motivations, intent, indications, etc.

    Deception systems, as detectors, do belong in a Cyber Defense program. That is not the only place that they belong. In Cyber Defense programs, though, deception systems should be integrated with the defense processes and value chains. A closed-loop system should update detectors as users or entities are locked-down temporarily, locked-out permanently, quarantined temporarily or permanently, notified, restored, reimaged, et al.

    Deception systems can also play a role in Cyber Operations, but are linked to data products instead of the closed-loop defense system/process. Lastly, deception systems can be brought in during cyber investigations. It’s a multi-purpose control that is looking for a framework or set of frameworks.

  2. Gary Klausner says:

    I don’t get it.(?) When you consider “…median number of days that attackers were present on a victim’s network before being discovered dropped to 146 days in 2015 from 205 days in 2014—a trend that shows positive improvement since measuring 416 days back in 2012. However, breaches still often go undetected for years…”, why would organizations with the most to lose ie Healthcare, financial services, and municipalities think that having a tool with the capability of “real time” detection (ie earliest stages of attack chain), not consider it a “must have”?? You would think spending money for accurate and early threat VISIBILITY inside your network, would be a priority. I might be a novice in the security industry, but I am very long on common sense. What am I missing??

    • Augusto Barros says:

      Gary,

      you are not missing the value of these tools. But they are constantly competing against others, and deceptions tools, but their nature, will never be able to be offered as silver bullets, what frequently happens with competing technologies. So, the question is not about not wanting visibility, as you said, but how to do it. Organizations still doubt (or don’t even consider that) deception is a valid way to achieve or to improve that.



Leave a Reply

Your email address will not be published. Required fields are marked *

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.