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!
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.
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.
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.
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.
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.
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.
- 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 :)
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.
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.
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.
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...
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.)
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.
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! =]
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!