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?
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.
EDIT: typo
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.
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.
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!
* Disclaimer: I manage one of those nine-figure security products you mention.
> 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.
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.
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...
(It was great meeting Gadi in the speakers lounge at a conference in Hamburg and doing the YC sales pitch last year.)
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.
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!
