Posted by: John Bradshaw, VP WW Sales Engineering –
I don’t remember when it was that honeypots came onto the scene in computer security, but I do know it was before I had my first child (who is in college now). As services on the Internet proliferated, along with the corresponding increase in cyber-crime, so too did different types of honeypots emerge onto the scene. Honeypots were designed to help identify malware, trick spammers, provide early detection for worm outbreaks, and lure human intruders into its trap.
The early generations of honeypots, while intriguing (Deception has been a classic tactic in warfare for centuries), did offer challenges for the enterprise customers:
- Deployment required installation of target systems, either on hardware or virtual instances making wide-dispersal across the enterprise problematic
- Target systems incurred licensing, maintenance and administrative costs equal to their counterpart production systems
- For desired targets that only come in appliance form-factor, acquisition costs made use within the Deception Framework too costly
- Administrators needed to configure the target vulnerable enough to be exploited by the attacker, yet strong enough not to let the attacker turn the targeted system against the organization
- Administrators need to acquire, install and configure monitoring tools that would capture the attacker’s activities – and hope the attacker’s level of sophistication could not bypass detection (as most Advanced Persistent Threat actors have been quite adept at doing)
While the honeypot tactic was sound, implementing it on the cyber battlefield was too limiting for CIOs and CISOs.
Like other security methodologies, honeypots needed an evolutionary leap to make it an integral part of Security Operations/Incident Response workflow. This story should sound familiar, malware analysis went through this same evolution over the past ten years. Imagine if malware analysis was still being done manually today. Could your company afford reverse malware engineers to figure out how attackers were getting into your environment? Could you afford enough of them based on the deluge of new malware variants? How fast could you easily identify commodity malware versus highly evasive malware today? Malware analysis went through an evolution into the various sandboxing technologies we know of today. You can even see how within sandboxing technologies, evolution continues to occur http://info.lastline.com/blog/extinction-level-event-evolution-of-the-sandbox.
The evolution of honeypots had to address several areas before security teams could embrace them for Enterprise Deception Operations:
John’s Key Tenets of Dynamic Deception Operations
The wider you cast your deception, the more successful your deception becomes…The more diverse and realistic the deception, the better the odds your decoys will be targeted…Your deception decoys should not be able to be used against you…
So as you start to consider Deception Operations as part of your integrated security stack, you should consider some of the following as core requirements:
- You should be able to seamlessly insert your decoys across all network segments in the smallest form-factor possible
- You should not have to pay for separate licensing for every decoy you deploy
- Your decoy’s attack vectors should be limited and known – something difficult to achieve when running full versions of operating systems and enterprise applications
- The forensic recording process should be baked-in to the Deception technology
- You should be able to utilize real-world systems into your Deception Operations
- You should be able to utilize realistic, but false information as part of your Deception Operations
- Your vendor should understand how advanced adversaries accomplish their mission and not just cite buzzwords https://www.linkedin.com/pulse/race-bottom-john-bradshaw?trk=pulse_spock-articles
Are you ready for that evolutionary leap?