So two questions, really. First, given We generate one because our decoys are real machines and nothing should run on them except for what we put on them., won't that machine look a little different from the outside, that is, the next machine over in the horizontal network than all the other machines? And thus the attacker would be suspicious?

Secondly, who is to say that the attacking army doesn't have a lab simulating an enterprise environment with one or two of your installs there, learning how to detect/avoid/silently compromise them?

Hi, dean here (Cymmetria CTO). Two great questions:

1. The concept being that from looking at the machine on the network we don't do anything different then regular machines, so the goal is to prevent fingerprinting.

2. If the attacker actually attacks the decoy then we are able to capture what that attack looks like, send it to threat management while it's happening and mitigate. At that point if the attacker has found out it's too late. When Attackers will have our systems installed in his labs he'll have to find some way of identifying our machines without attacking them and that's what we've been developing to prevent.

Thanks for the reply.

So I am unclear on the meaning of "attack". Is this more than a series of pings, or an attempt to do a pexec or remote viewing of the event log?

Secondly, if the sensor is placed in a pool of developer machines, does it have to have the whole development environment loaded up, for example, and occasionally do compiles?

"Doing anything different" seems to require close emulation of whatever is going on in the rest of the environment, no?

Further, if he has your machines installed in a controlled lab with properly tied off alarm end points (the things you trigger when you see something odd), what is to prevent an attack analogous to a virus writer having a lab full of each kind of antivirus hammering at his samples?

It seems the challenge for building a static alert system or sensor is that engineering talent from a team larger than yours in some other time zone is going to do the equivalent of sending a drone over your island to see what your radar response looks like. As in if they find the destination of your alerts before tickling your box and compromise that first. Or figure out how to set off an fake alarm or nine.

EDIT: typo

- What is alerted on (or "attack") is configurable and can range from code being executed (which is the true positive alert) to connecting to ports(which has more noise)

- It needs to look like the machine an attacker will be after when he's looking around on the network and that's much simpler then a whole loaded up environment.

- Yes, the decoys look like an integral part of the network

- It could be within every segment of the network and not in it's own island. But it's true that every security solution depends on it's management interface not being compromised :)

One final question.

Let's say that an attacking organization fully installs your sensor in their own lab. What is to prevent them from engineering an approach to fully defeat the sensor itself?

Like was said before, you have to attack the decoy to recognize it and that enables catching the attack traffic. Also the mere fact that they recount every single action 10 times over before acting is a huge value in and of itself.

On another note I agree that they will try and we will be constantly remembering that fact :)

How does it work, really? Do you provide a plausible-looking virtualized fake enterprise network that will look like a real thing to outsiders? Or do you put honeypot servers alongside other production servers, running whatever applications are really being used by the company? Do you intend to protect against inside threats as well?

Each decoy is configured to look exactly the way that makes sense for the network it's in. An example is a git server with interesting code or an employees pc that shares files that are crafted to draw attackers to that decoy. The decoys themselves can be placed within the customers network or hosted in the cloud by us.

The real trick is "breadcrumbs" which is specific data/files that you can place on the real machines that directs the attackers towards the decoys.

> "breadcrumbs" which is specific data/files that you can place on the real machines

If the breadcrumbs are realistic then you will end up having employees mistake them for real data, and the employees being mistaken for an attack, no?

If the decoys are realistic then they will have realistic behaviour, for instance, doing an auto update. Now, let's say I'm a malicious actor on the network, and I fake the auto-update server so the patches downloaded are backdoored. Its very hard to detect this attack. Any network has a lot of broadcast traffic between all the nodes - if a decoy doesn't transmit any then it would be a suspicious, and if it does, then its hard work for a decoy to separate the real traffic from a potential attack.

The trick is to make the breadcrumbs the type of data that an attacker is interested in, but a regular user will never be aware of.

For example in windows there is a cache of used credentials along with passwords, it is a known infection spreading technique to read that of an infected machine and use t across the network.

A breadcrumb would put a decoy's credentials in that cache. Thereby never doing any side effect to the user and definitively flag attackers by looking at any usage of those credentials.

Are you also hooking OS APIs or the machine feels almost completely real? I mean, if the attacker can detect that some APIs are hooked they can infer you are using some kind of honeypot.

Nothing much to add except good luck Gadi. There's always going to be bad actors in this world and the more techniques the better.

(Slight disclaimer: I know Gadi well from the anti-spam world)

Thank you. :)