Deception Deployment Strategies: Containment versus Detection 

Wednesday, May 9, 2018
Deception Deployment Strategies

Deception discussions often lead to honeypots and then some level of confusion begins. Add in an array of acronyms for deception including: breadcrumbs, decoys, traps, beacons, canaries and tarpits – and most people new to the topic see another security research project.  Deception technologies within discussions can confuse deployment strategies leaving legacy perceptions about the topic falsely standing within our minds.  Significant innovations have developed for deception defenses impacting deployment strategies. 

First, traditional real operating system honeypots focused on containment and open to compromise are required for security research. However, deploying thousands of them inside your network to use as a post-breach detection strategy only increases your attack surface and risk level.  Just as we need skilled law enforcement personnel to detect and find package bombers and snipers, we need skilled security researchers capturing attack tools and methods to learn possible attribution and how to mitigate these attacks.  The results are often in the headlines noting a nation state or hacking group and how their malware functions and method flow within kill chains.  

So, an in-depth discussion on honeypots for security research will focus on containment as a deployment strategy.  The honeypot must be as real as possible to avoid detection by attackers, so they install their tools and commence their methods while security researchers learn.  Conversely, using deception as a post-breach defense internally focuses on detection (vs containment) where innovation has improved this deployment strategy.  Over time, pure honeypots built upon real operating systems evolved into virtual machines making them easier to reset.  Then emulation of services evolved honeypots into decoys not open to compromise, however, open to automation and scale.  

Given a post-breach deception strategy of detection, by the time an attacker discovers a medium or low interaction decoy is an emulation of services and data, the goal of detection has long been completed.  To make deception deterministic (vs attackers statistically finding decoys), lures or bait are placed on real assets to then lead attackers to decoys.  These lures are also known as breadcrumbs, poisoned data, fake credentials, traps, mini-traps, and beacons.  Modern deception is focused on the link between breadcrumbs and decoys for the most effective detection possible.   

We know most attacks arrive via phishing, social engineering or drive-by attacks onto a foothold system. Rarely is the foothold system the desired asset or data, so attacks use reconnaissance to find paths for lateral movement to what they desire.  Herein lies the opportunity knowing what attackers desire to lure, detect and defend with deception as a detection deployment strategy.  The attack landscape is changing given the news that nearly 60% of attacks do not have malware, over 40% of compromised systems show no signs of malware, over 95% of malware is only seen once, and nearly half of users will open an email and click on attachments within an hour of delivery.  It adds up to a post-breach environment where early detection is required.    

So how does automation enable deception as an early post-breach detection defense?  Automation enables the mapping of networks and profiling assets to then auto create emulated decoys matching the environment.  Automation then deploys decoys and seeds breadcrumbs, plus monitors for any changes in the environment, making deception layers as realistic as possible with minimal human effort.  Given deception components are unknown to users, alerts have high fidelity with few false positives to detect newly compromised foothold systems, attack lateral movements, and insider threats.  Deception is also effective for assets that cannot have defenses installed, such as enterprise IoT and legacy systems.  A modern deception solution with automation can be monitored and maintained by a tier one security analyst in less than five hours per week. 

The net result is you have opposite ends for deception deployment strategy.  One end is the pure honeypot for security research, focused on containment and open to compromise as a cyber stakeout where emulation is not effective to collect malware and attack tools.  The other is a post-breach smart alarm system focused on detection where emulation enables automation and scale without risk of compromise inside of networks.  Given the deployment strategy is detection, there is no need to take the risk of a real operating system decoy or honeypot within your network. 

For your next discussion on deception, start with knowing your deployment strategy of containment or detection before the technical details confuse things.  A legacy opinion or perspective on honeypots could be holding you back from leveraging deception as a post-breach detection deployment strategy. 

- Tom Clare
Sr. Manager, Product Marketing