Blog

Incomplete Thought: HoneyClouds and the Confusion Control

By 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?

No Related Posts
Comments

Well, a bot won’t necessarily give up…

An approach like this feels a lot like the old approach to “protecting” your privacy with search engines by spamming random searches against the engine, producing so much noise that is dilutes your actual issues. The problem with that is two-fold: You might actually harm yourself when those noise searches for herpes cream show up somehow. And your real searches are actually still there. You’ve not really protected your privacy much at all, other than dilute the results, but they’re still there for character assassination or whatever.

Making more noise for attackers means you may have some collateral damage to take care of if they mess up your honeypots. You also have done nothing to actually secure the vulnerable pieces; they’re still there.

I whole-heartedly feel the allure of fake information to thwart human attackers, and I do feel there is *some* value there. The problem is whether that is enough to justify the overhead cost of keeping it up, testing it to make sure it’s working, acquisition cost, opportunity cost of diverting your talent away from other tasks (probably the biggest cost right now, since we continue to facepalm about failing on the basics), dealing with the creative ways such subterfuge screws with normal, valid ops, watching the logs, etc. You might actually confuse your own pen-testing operations or even cause regular false alarms like, “WTF is this port doing open? WTF is this system? WTF is this piece of code? Oh, wait, that’s our fake stuff…”

(A presumption here is that we’re already at full capacity with talent and budget, meaning any effort made on honeypots/subterfuge is taken away from actually securing the insecure stuff. Do I have 100 hallways, 99 of which are fake and 1 that is the real one and a bit weak as part of my security regimen, or just 1 hallway that is super secure? We’ll also depend on the current discussions on whether shit is fixable right now, or whether the only real recourse is to layer controls on top of that shit we can’t/won’t fix.)

I wonder how many highly secured physical implementations are created with false hallways, fake “top secret” doors, and other things designed to slow down, frustrate, mislead, or expose intruders? I’m of a mind that if it’s not good enough for a similar control in physical security, it might not be worth as much as the allure suggests for the digital world.

(I’ve purposely avoided trying to throw down the “security/obscurity” gauntlet…at least overtly!)

By LonerVamp


We will not be able to tell if the effectiveness of these Proteus tactics actually works, although I would welcome it.

I do actually believe these tactics will work against certain people / bots. I am a big believer in time, the longer time it takes the more a person / bot is prone to give up and move onto the next target.

I think we should concentrate less on hardening the network till the point of no intrusions and focus on detection. This doesn’t mean we can abandon good ol defense, the point will come one day when (if it hasn’t) that attacks ARE happening, now what are we doing to detect and stop it.

By Michael Lubinski


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.