Yes and No.

Honeypots are a great idea. Everyone knows this, so why is almost nobody running them on internal networks? Simple: because with all the network problems we have, nobody needs one more machine to administer and worry about. We know the benefits that honeypots can bring but the cost and effort of deployment always drops honeypots to the bottom of the list of things to do.

Canary changes this. Canaries can be deployed in minutes (even on complex networks), giving you all of the benefits without the admin downsides.

It usually takes less than 2 minutes from unboxing your Canary, to have it ready for action on your network. With just a few clicks, you'll have a high interaction honeypot, and be able to track who’s browsing shares for PDF documents, trying to log into a NAS, or port scanning your network.

Canaries are deployed inside your network and communicate with the hosted console through DNS. This means the only network access your Canary needs is to a DNS server that's capable of external queries, which is much less work than configuring border firewall rules for each device.

Simply choose a profile for the Canary device (such as a Windows box, brand name router, or Linux server). If you want, you can further tweak the services your Canary runs. Perhaps you need a specific IIS server version or OpenSSH, or a Windows file share with real files constructed according to your own naming scheme (say, 2016-tenders.xls). Lastly, register your Canary with our hosted console for monitoring and notifications.

Then you wait. Attackers who have breached your network, malicious insiders and other adversaries make themselves known by accessing your Canary. There's little room for doubt. If someone browses a file share and opened a sensitive-looking document on your Canary (\\fin_srv_02\Planning\2016_forecasts.xls) you'll immediately be alerted to the problem.

You possibly already do have a problem, you might just not know it. Canary changes that.

No. Canary doesn't do anomaly detection (with machine learning or otherwise) by learning to detect malicious behaviour in day-to-day activity. The Canary triggers are incontrovertibly simple: if someone is accessing your lure-files, or brute-forcing your fake internal ssh server, then you have a problem. Canary uses deceptively simple, but high-quality markers of trouble on your network.

You could certainly setup honeypots but, the truth is, most haven't. Why? Two reasons as far as we can tell: most projects have limited protocol support meaning you have to run multiple honeypots to cover a range of common protocols, and monitoring and notifications across multiple honeypots quickly becomes tricky especially if you want to have many honeypots scattered around your network.

Canary makes this easy; we have multiple protocols supported out-of-the-box, and our hosted console gives you effortless monitoring and notifications.

We have a console, and we think it's pretty, but we really don't want you to spend much time on it. After you setup your Canaries you forget about the whole thing completely. When one of your Canaries chirp, only then do you attend to the problem.

If your Canary can get off just one alert (and it really should) then your console far away is going to log and alert on this. Whatever happens to the Canary after that won't matter since it stores nothing of value.

Identification will require active interrogation of the devices, and we detect common methods for fingerprinting and then alert. After that, even if the attacker correctly identifies a Canary, you know they're looking and can investigate further.

Yes. We publish security advisories to disclose security issues in both the Canaries and Canary Consoles.