
Cymmetria (YC S15) Uses Virtual Machines to Decoy and Detect Hackers - easyd
http://techcrunch.com/2015/06/27/cymmetria/
======
tptacek
Gadi Evron has been in the security industry for a long, long time. He's a
malware/botnet/honeynets guy. Mile-long resume.

This is kind of a surprising pick for YC: a down-the-middle enterprise
security play, the kind of company that usually gets funded by Battery because
one of the cofounders successfully sold a portfolio company a couple
iterations ago.

It's interesting to see what seems to be a pretty conventional bit of security
technology (sandboxing malware and exploit code into virtual machines is the
kernel of several 9-figure security products) get extra attention because of
the YC pedigree. Or maybe TechCrunch just got this wrong? Either way: not
complaining!

~~~
FreakLegion
It's a fun twist on that conventional bit of security technology, though* .
What I'm unsure of is whether these decoy-type products really provide much
value beyond alert triage. Even if we're charitable and assume they don't
introduce new false positives into the system, all the old false positives
remain.

* Disclaimer: I manage one of those nine-figure security products you mention.

~~~
ddiinn
The system will not catch everything in any way - but what it does catch has
no false positives by definition. We're very happy to demonstrate live the
value proposition and how alerting is one aspect of what we do.

~~~
FreakLegion
_> no false positives_

 _> will not catch everything in any way_

This is why I'm unsure of the value. And to be clear, by "unsure of the value"
I don't mean "unsure whether it has any value." It certainly has value. I'm
just not sure how much, as, say, a dollar figure.

"No false positives" is fine marketing, but in practice you aren't replacing
anyone's firewalls, endpoint agents, sandboxes, SIEMs, etc. All those false
positives will still be there, along with many legitimate detections your
system never sees.

If money were no object, then absolutely I'd buy. But given that money is
usually a factor, that you're limited to detection, that you're only effective
in scenarios where attackers touch your decoy systems, and that you're
competing for dollars against products that detect more, detect it sooner, and
often prevent it automatically, I don't know.

~~~
ddiinn2
When you get one alert that you realize isn't false and has the forensic data
tied to it, you can use it as a harness against the loads of information from
all the other sensors (firewall, endpoints, sandboxes etc) to give you a
definitive picture you're certain in.

------
ddiinn
Hi all, Gadi here (CEO of Cymmetria). We are here on Hacker News and would be
happy to answer any questions, technical or otherwise, and discuss.

~~~
wglb
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?

~~~
ddiinn2
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.

~~~
wglb
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

~~~
ddiinn2
\- 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 :)

~~~
wglb
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?

~~~
ddiinn2
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 :)

------
nickpsecurity
Mass market IT tech has been hacker heaven so far but better stuff isn't
making many inroads. All these desktop, cloud, etc offerings don't have a hope
of stopping determined attackers. Knowing this, industry mostly focuses on
reducing risk, detection, recovery, etc. Honeynets are another great tool
that's under-utilized in mainstream industry. They make the right assumption
(they'll get in), the right goal (let's spot it), and add extra benefit (real
damage maybe averted).

With that in mind, I'm liking what I see in the article. A true pro building
on honeynet tech while maxing out ease of use and knocking out false
positives. That last part is huge if he gets it right: too many just make
people ignore the alarms. I look forward to seeing what it achieves in the
field.

Like the names, too: Deception Stack, Maze Runner... good stuff haha.

~~~
tptacek
No, honeynetwork research actually dominates academic security programs. It's
problematic how much of it there is. Almost all of honeypot innovation comes
from schools now. They're also the ones doing large-scale longitudinal studies
done from honeynetwork and "network telescopes", in which universities like
UCSD are enlisting BGP peering relationships to capture malware.

~~~
nickpsecurity
I appreciate the correction. Edited the comment to reflect that. Weird how the
field is fragmented enough that I can go through hundreds of INFOSEC papers
(ACM, IEEE, conferences) without seeing hardly anything on honeynets then you
see a flood of them in the sources you read. I expect a certain amount of this
due to specialization but I think INFOSEC innovation is way too scattered
compared to some fields. People end up missing key findings.

It's why I keep toying with the idea of a unified resource for INFOSEC
professionals of all these fields. Collection of papers by category, tools,
wikis, forum, and so on. Free or cheap to avoid exclusion the way
ACM/IEEE/Springer end up causing. The wisdom of our field would be passed down
more easily, all stuff in one category would be there with authors maybe
discussing it, and different types of researchers would have higher chance of
bumping into each other for cross-disciplinary advances. Pretty idealist, I
know, but would be great if pulled off.

Epstein at NSF liked the idea but thought you'd need a ton of buy-in from
Universities & private parties ahead of time. Haven't solved that one yet...

------
rdl
This is a solid idea with a great team behind it. The challenge with this kind
of product is to make it easy to deploy while delivering actual value to
users, and looks like they've figured that out.

(It was great meeting Gadi in the speakers lounge at a conference in Hamburg
and doing the YC sales pitch last year.)

~~~
ddiinn
Thanks for your support!

------
lawl
It's an interesting concept. But there's one thing that bugs me. If an
attacker is already in the network, I think we need to distinguish between two
types of boxes. Servers, and clients. Honeypots are nothing new, so having a
few servers that are honeypots in the network doesn't seem that interesting to
me.

If someone wants to break into your network, they'll probably target a small
amount of users and try to get a RAT on their box to spread from their, I
don't know but that's what I'd do.

If you want honeypot Clients, things get a bit harder, since you will need to
mimic user interaction. But even if a box clicks every link for a decoy email
account a drive-by exploit or something can easily fingerprint the system and
bail out if it's a VM since it's unlikely for clients to be VMs. Depending on
the exploit, that could be hard to detect.

So, we're back to honeypots as servers? I don't want to sound negative, but
the article is just so vague and that seems to be the only plausible thing.

------
yammesicka
Good luck guys :)

~~~
ddiinn
Thank you, we appreciate it. :)

------
ejcx
I actually built an identical project following watching Rob Fuller's talk
"Attacker Ghost Stories". I've actually built it twice.

First was a Java based service for each service I wanted as a honeypot. FTP,
SSH, MySQL, etc. They basically were low interaction honeypots, for example
MySQL. Prompt for password, do the handshake, say failure, and report to
admin.

Second was a Go logtailer and bash script that would securely set up services,
tail the logs, and notify admins when there was suspicious activity (err...any
activity).

It was a ton of fun building it and very straightforward. Gen1 in Java was the
most fun implementing all the authentication schemes, but Gen2 worked way
better, faster, and easier. I wanted to try to turn it into a company but
chickened out that nobody would ever want it. Awesome to see literally the
exact same use-case software here! I guess it was a good idea! =]

Good luck to you Cymmetria!

