We hold ourselves to high standards in this regard. It’s not enough that Canaries are excellent security devices; they must also be excellently secure devices. We’ve invested heavily in keeping Canary as secure as we know how, including leaning on our previous experience in offensive security work, and in hiring outside security auditors. Here we detail our approach to security, the measures we've implemented, and our ongoing commitment to protecting our Customers.

Security Measures

Securing your Canaries and your data hinges on architectural decisions and our choice of features, to both minimise vulnerabilities and reduce their usefulness (should any be discovered). Some of these are proactive features, and some are (weirdly) anti-features (?!?). At a high-level, these measures include:

• Single-tenant Consoles; your data sits in an isolated tenant that isn’t shared with any other Customer, removing the risk that a web app bug leads to data loss.
• We implement Canary network services in memory-safe languages to remove memory corruption vulnerabilities as a class of potential bugs.
• We sandbox network services that need to touch the underlying OS.
• Canaries will never support VLANs; we don't want attackers to use Canaries to jump between different trust zones.
• Canaries will only accept updates from your specific Console. These updates are signed by a key that is never exposed to the Internet.
• Intentionally rejecting new features that require the honeypots to hold sensitive information (like capturing and exporting PCAPs). They’re passive sensors that only send the data you see in alerts to your Console.
• We hire a rotating set of outside security assessors to perform regular security assessments, and will share these reports with Customers on request. Following one such assessment, NCC’s technical director wrote about our security choices and had positive things to say.

Exploring the Measures

You can read more about our practices on our blog. It’s where we expand on several of our security measures. Here are highlights that help understand our security mindset:

• Why we use Isolated VMs — We explore our data isolation model.
• Are Canaries Secure? — A discussion about the core considerations regarding the security of Canaries.
• Sandboxing: a dig into building your security pit — How we evaluated multiple sandboxing techniques to choose the best one for Canaries.
• Using the Linux Audit System to detect badness — How we preemptively detect if a Console was ever compromised.
• Making NGINX slightly less “surprising” — How we addressed an unexpected security issue on development servers and, as a result, enhanced overall security and reduced the risk of future surprises.
• If I run your software, can you hack me? — We discuss the inherent security risks of using third-party software with auto-update features, emphasising the importance of vigilance and robust detection mechanisms to mitigate these risks.
• Communications and Cryptography - Our whitepaper on secure communication between Canaries and Consoles.

Security Issues

A technology product that claims to be completely free of all defects is, well, lying. Bugs occur, and sometimes they impact the product’s security. We can’t promise a defect-free product, but we can promise we strive to make a secure product. If we do have a security issue then we’ll be transparent and open with you about the issue and its impact.

We welcome security reports and will list public reports (with acknowledgements) on our sites. We publish security advisories for Canaries and their Consoles, and will actively inform you if an issue affects you.

For our Open Source projects, please use Github's reporting tool (quick links: Canarytokens, and OpenCanary).

Security FAQ

• Can a Canary be hacked?

  We don’t know of ways to remotely hack Canaries, and if we find any then we fix ‘em. Generally we don’t rely on standard implementations of network services, but reimplement them in memory-safe languages. Where we do expose OS functionality, we sandbox those services. We’ve reduced the risk using all mechanisms at hand.

  Unrestricted physical access to Canaries isn’t defensible as Microsoft pointed out so many years ago, so we recommend keeping Canaries under the same physical lock-and-key protections for your other infrastructure.

• OK, but what happens if my Canary has been hacked?

  Attackers breach systems for access or data. No valuable data is stored on your Canary. An attacker who does manage to compromise it will not find secrets or other data that yield further access into your network.

  Canaries deliberately don’t allow network multihoming; a compromised Canary can never bridge VLANs so the attacker’s network perspective remains the same after a Canary breach and they cannot pivot into other networks.

• Will Canaries leak data from your network?

  Some security appliances collect background telemetry and data (like PCAPs) and export that out of your network. You have no say in what’s included in those artefacts. Canaries do not collect or store sensitive data from your environment; they are purely passive sensors. The only information they send to your Console is in the Alerts generated by an attacker when they interact with a Canary. All communication is performed over end-to-end encryption, which is detailed further in our Communications and Cryptography whitepaper.

• How often is my Canary updated?

  We typically perform three or four planned releases per year; (Updates are automatically deployed to online Canaries over-the-air. I.e. you won't need to do any manual patching). Update details can be found at https://canary.tools/new.

• How are security updates handled?

  We perform out-of-schedule updates to address security issues.

• Can I cycle the encryption keys?

  There are several keys involved with device communication, but none are exposed to end users and they are not cyclable. For further information, refer to our Communications and Cryptography white paper.

• How often is my Console backed up, and what is the RTO/RPO?

  We perform full backups hourly. In case of a Console failure, we can return the service to full functionality within 24 hours, though typically it will be much shorter than that.

• Why does my Canary Console have a weird-looking domain?

  Obfuscation has its place. A simple DNS bruteforce shouldn’t reveal our list of customers, and assigning you a random domain prevents this minor information leak.

• You haven’t answered my question!

  Sorry, not every question is asked frequently! We’d love to answer your infrequently asked question (IAQ?), our Support team is standing by.