Incomplete Thought: HoneyClouds and the Confusion ControlBy Mike Rothman
I was somewhat captivated by Lenny Zeltser’s recent post on a Protean Information Security Architecture. His idea is that another set of controls can be based on confusing the attacker. If you open/close different potential attack vectors, you can somewhat obscure the real payload you are trying to protect.
Of course, Lenny nails that complexity cuts both ways:
An environment that often changes may be harder to attack, but it is also hard to manage. In fact, many vulnerabilities seem to be associated with our inability to securely and timely implement changes, such as deploying security updates or disabling unnecessary services.
But I think the concept is solid. It’s basically a more sophisticated approach to honeypots. But this time the objective isn’t necessarily to catch the bad guys in the honeypot – instead it’s to make their lives harder. And we all know that most attackers take the path of least resistance. So if they get confused, or their automated reconnaissance scripts miss stuff or dead-end, most will move on to the next target.
But I’m very sensitive to the complexity issue. At scale, far too many organizations can barely manage their devices and network configurations (and I’m being kind). So as Lenny says, we need to make sure we don’t add even more management overhead and create a situation that inadvertently creates exposures due to operational failure.
Lenny lays out a couple tactics that could confuse attackers, like opening/closing perimeter firewall ports, tarpitting inbound packets, building fake Internet servers, etc. All these are interesting concepts, but again create significant management overhead to provision and de-provision with enough variation to not be obvious obfuscation.
And then it hit me. A lot of these operational tactics could be scripted and deployed in a private cloud, perhaps within your DMZ. Scripts could be built with varying attributes ti make the desired changes (likely on a second set of devices, to avoid messing with production/operational security) without requiring a lot of overhead.
Basically you would build a sophisticated honeynet in a private cloud. A “HoneyCloud” of sorts. Sure, there are clear risks to this approach. Do it wrong and you could create holes large enough to drive a truck through. You would need to revisit the patterns & scripts every so often to change things up. You would have to invest in additional infrastructure to run this stuff. So it’s probably not for everyone, or even for most.
But as Lenny says:
“a protean approach to defense isn’t foolproof–it is one of the elements we may be able to incorporate into an information security architecture to strengthen our resistance to attacks.”
I don’t know. I’m not sure if it’s just interesting as a shiny object, or if there is more there. Whether it’s operationally practical or economically feasible. We know this wouldn’t deter a persistent attacker for long. It doesn’t address targeted client-side attacks either. But at least it’s an interesting intellectual exercise. What say you? Is there anything to this Proteus stuff, or am I smoking seaweed?