Canary Program Communication: Secrecy vs. Discretion

The goal of deploying canaries across your organization is to detect both external intrusions and internal unauthorized behavior. Given the sensitive nature of what we do - when we first start deploying Tracebit within an organization we’re often asked what the internal communication should look like.

We think that careful consideration is especially important as security teams are usually working hard to build trust and healthy relationships with teams across their organization and don’t want to give the impression that they’re trying to “trick” or “catch” people out. 

The value in secrecy

The thing is, for a canary program full transparency is not an option, part of the value of such a program is some degree of secrecy.

There’s two reasons for this:

• Given enough time there will be an employee who wishes to perform malicious actions in an organization that are detectable with canaries - with knowledge of such a program they may avoid detection.
• Even disregarding internal threats, with full transparency about the program, over time the chance of accidental leakage of this information that is leveraged for avoidance trends towards 100%.

A balanced approach: discretion.

Given these risks it might be tempting to limit information about the very existence of the program to a trusted few. 

However, with reference to our previous point about building trust and healthy relationships across an organization, secrecy puts trust at risk and minimizes other benefits.

Consider these scenarios:

1. An employee interacts with a canary and is asked by security to confirm their actions (which could be an innocent mistake, just doing their work).
2. An employee discovers a canary resource and alerts the security team to what they perceive to be a potential breach.

If the employee has no idea whatsoever that canaries are in use  - there’s a real risk of alienation, which modern security teams don’t love!

There’s also a missed benefit here - in both cases if the employee knew about the existence of a program they could have highlighted this to the security team, saving time in response.

Finally, full secrecy misses out on a key benefit of a canary program. There is empirical evidence that demonstrates that if an attacker knows you deploy canaries, their attacks are slow and less effective (1). In our opinion, this makes a strong case that even speaking publicly about the existence of a program has value.

We hope these examples are clear - full secrecy is probably not the answer, we think that communication with discretion is the right balance.

How might that look?

What good looks like: internal communication

There will never be a one size fits all approach for this but we think breaking down the organization into 3 key groups is the place to start.

Group #1 - Whole Organization

This is the most important group when considering communication - we need to retain trust but we also need to communicate the importance of there being some level of discretion around the program.

The 3 key points we would reinforce with the wider team are as follows:

1. We’re adopting a program of ‘canaries’ across our organization for detection of intrusions and unauthorized access
2. The goal of this program is to protect the business from security risks, by faster detection and response.
3. Part of the value of such a program requires discretion around the details, we’re grateful for your support in the success of the program by your continued discretion around any details you learn.

It’s also worth considering that there will be individuals with privileged access (e.g. DevOps or Platform Engineers) that may enable them to go ‘canary hunting’, it’s worth explicitly calling out that this wouldn’t be considered a good idea.

Here’s an example internal communication that we think is a great starting point:

We are expanding our security capabilities to include ‘canary’ resources, the goal of which is to detect and response to certain security issues faster.

These are benign resources across our organization designed to attract the attention of and detect would-be attackers.

We've designed this program to keep out of your way, but it is possible you will encounter these canary resources. If you do so by accident - this is not a problem, but please do report to the security team (security@company.com).

We intend to keep the specifics of the deployment private (details could be used to avoid detection). We're grateful for your respect here and ask you don't go looking for and certainly not documenting canaries you may find.

Thanks for your support - the security team is here for any questions!

Group #2 - Canary Program Responders

The next important group to consider are those that may be responding to a canary trigger. They may not know all of the details, but they will need to know more and who to speak to to escalate.

Generally this may include the whole security team or security operations team and perhaps ‘security champions’ within an organization, depending upon the alerting setup.

The privileged information to share with this group would be:

• High level awareness of the systems that are engaged in the program (which cloud platforms, which class of endpoints, which SaaS Applications)
• Access to alerts that the systems trigger
• A clearly defined escalation path if they need additional context. 

‍

Group #3 - Canary Program Insiders

Of course, there needs to be a set of people who are aware that the program exists, understand the tools being used to implement it, and how to know what is and isn’t a canary.

Privileged information:

• Access to administrative tools used for the deployment and a comprehensive asset inventory of all the canaries.
• Understanding of the architecture of the deployment.
• Access to any ‘meta’ alerts relating to the deployment.

We’d recommend trying to keep this group small - it’s likely a subset of the security team.

‍

Other considerations  - communication medium

When weighing up these groups and ideas, it’s worth being intentional about how this is communicated. 

For Group #1 - given the limited scope of information and especially given our point earlier about knowledge of a canary program’s existence slowing attacks - we believe that email and security on boarding is completely reasonable. 

We’d advise treating Group #2 and Group #3 communication as secret. You may want to consider limiting as much as feasible to word of mouth with key details stored in a password manager or a tightly controlled source code repo. 

It bears repeating - attackers love to read company wikis - don’t make their job easy!

‍

Wrapping up

In conclusion, we think it’s clear that defining a communication strategy for your canary program is valuable but think this can be pretty light weight. We’d love to hear any lessons you’ve learned in deploying such a program!