The most challenging step in building a successful deception program is planning the first year. Creating the plan is not sexy, but doing it poorly or skipping it entirely ensures failure.

The first year’s plan should prioritize delivery; a functioning deception program has a larger impact on an organization’s security posture than even the most bell-and-whistle-laden work in progress. A small pilot team of one or two security professionals can likely complete three distinct deception projects in the first year.

These three projects should:

1. Take four or fewer months for one person to complete. Choosing projects this size enables the team to iterate from one project to the next, which is pivotal in the early development of a new program.

2. Focus on detecting malicious activity. While tarpitting, confusing an attacker, and generating threat intelligence are all benefits that a deception program may achieve, detecting malicious activity is the easiest to accomplish and test.

3. Meaningfully improve the security of the organization in some way. While it is ok for this improvement to be small, it should be more than a “redundancy project”. This means it should be able to detect some kind malicious activity that the organization isn’t already well prepared to detect.

4. Protect something different within the organization’s environment. This takes careful planning, as deception projects usually protect the thing they are stored in or on, not the thing they are. For example, placing a decoy API key from a software service on a user’s computer helps detect malicious activity on the user’s computer, not on the software service the API key came from.

Project 1 - Decoy machines

The first project may feel daunting because it will feel like there are infinite possibilities and only slightly less pressure to deliver. A great candidate that fits the previously mentioned criteria is deploying decoy machines - spoiler alert, the blog’s next post will be about them - in strategic locations. Some organizations choose to place decoy machines in a subset of physically separated office locations, others place them in a subset of logically separated networks, and yet others choose some other strategy. Regardless of deployment strategy, decoy machines are a great first project for a number of reasons:

1. There are commercial products that do the majority of the heavy lifting. Off-the-shelf decoy machines are inexpensive, easy to configure, and come with alerting capabilities that can interface with common security information and event management (SIEM) platforms.

2. Building a custom decoy machine is not complicated. As the next post will demonstrate, the amount of effort required to DIY a decoy machine is low compared to other deception projects.

3. Decoy machines can catch attackers early in their attack. If a decoy machine catches an attacker while they are performing internal reconnaissance (looking for a machine to laterally move to), their attack may be stopped before it has a chance to do much damage.

4. There is more to deploying decoy resources to making deception valuable for a security organization. The relative simplicity of decoy machines allows the team to build good habits on “the rest.” Documenting how to deploy a decoy, the inventory of the decoys, what alerts the decoys can emit, and any additional information that can help the SOC respond to the alerts are all crucial to actually making the organization more secure (which, of course, is the point of having a deception program).

Project 2 - Decoys in file hosting service

The primary focus of project two should be to make incremental improvements to the other parts of a deception project. While the decoys themselves are important, the choices that determine where the decoys of this project land on the precision and recall spectrum, the documentation, and the hand-off to the SOC are the parts that the team should aim to revise.

Placing decoy documents in the organization’s file hosting service is a project that allows the team to refine the process of deploying and operationalizing deception while increasing the likelihood a decoy somewhere in the environment catches an attacker. Depending on which file hosting service the organization uses, there may be commercial products that solve the problem well.

Whether using a commercial product or building custom file hosting decoys, the team will have to choose where on the alert fidelity spectrum makes the most sense. While not an exhaustive list, the following two examples demonstrate how basic file attributes can be used to affect the decoy file’s precision and recall:

1. Sharing permissions - decoys shared to the entire organization by default will likely achieve high recall at the cost of precision. While any account compromised will be able to access it, any employee may accidentally come across it.

2. File name - file names that indicate the file contains sensitive information not often required by employees may have higher precision and lower recall. While there is no reason for an employee to seek out the file, malicious actors will be drawn to the sensitive information.

Answering the question “when a decoy alerts, what happened?” is not always easy, but a deception project is not complete until its documentation includes the likely alerting scenarios so that the SOC can determine what information is required to support or disprove each scenario. Without this information, the SOC team is left to fend for themselves in the dark each time an alert is triggered. With it, they can begin to understand an alert’s story. Maybe alert A is a benign positive caused by an employee who mistook a decoy (designed for high recall and low precision) for the real company-wide budget document. On the other hand, alert B might be a true positive that indicates a database administrator’s account was compromised, and the attacker used it to try to access what they believe is a backup of users’ password hashes. Though an alert may not be able to tell a full story by itself, leveraging the deception program’s expertise in its decoys to document as much of the story as possible enables the SOC to uncover the rest.

The conclusion of any deception project involves a hand-off to the SOC team, which will then triage the alerts that the decoys produce. While the documentation the deception team writes is vital to ensure a successful hand-off, it is not by itself sufficient. SOC teams often use tools like a SIEM to collect all alerts in one place, and sometimes a security orchestration, automation, and response (SOAR) platform to perform actions on an alert when it first fires. The deception and SOC teams should review the documentation of each decoy completed together so that the SOC team can determine how much of an alert’s response can be automated via features of the SIEM and SOAR platforms, and how much must be done by one of the team’s members manually. Strengthening the hand-off habits in project two will prepare the deception team for it’s “final exam” of year one; project three.

Project 3 - Decoy API keys

Project three should build upon projects one and two and set the tone for the future of the program. While the first two projects (hopefully) improved security at least a little bit, project three can be more ambitious and aim to make a sizeable difference in the organization’s security posture. A good option for project three is deploying fake API keys for a well-known and often-used software service on all users’ workstations. Cloud compute services, corporate productivity tools, and source code version control platforms commonly use API keys, and as a result such API keys are routinely targeted by attackers. Off-the-shelf solutions exist for some cloud compute services and corporate productivity tools, so the team can use one of those options instead of building the entire solution on its own.

Even if utilizing an off-the-shelf token solution, the team will have to figure out how to scale its deployment to the desired environment. If, for instance, the organization’s fleet is managed by an endpoint management solution like Intune (a common choice for Windows devices), or JAMF (for OSX devices), building a deploy script that can place a decoy API key on each machine might do the trick. If, however, the fleet is managed by multiple management solutions, or does not have a management solution at all, the deployment task may require a more creative solution.

Since project three directly impacts the computers that an organization’s employees use on a daily basis, the team should take great care to test the deployment mechanism and the decoy’s effects on the machine. Placing decoy API keys in locations that real ones are normally found is often the best way to ensure that the decoy achieves high recall, but it means that precision may be low. This can also interrupt an employee’s work; for example if an engineering team frequently uses API keys for a cloud compute service as part of their day-to-day tasks and suddenly an unknown-to-them deploy script overwrites their key with a decoy key, whatever they are working on will break until they restore the correct key. In this scenario, undoing the damage that the deception team caused also renders the machine unprotected by project three’s perspective, highlighting the need for careful planning by the deception team. A good rule of thumb is to deploy decoy keys as close to their expected location as possible without ever putting them in a spot where they can be used without some user interaction.

Beyond

If all three projects went well, the team has succeeded in improving the security posture of the organization and it has laid the foundation for its own future by learning how to plan, document, deliver, and operationalize a project. If one or more of the projects didn’t go well, it is worth taking a step back to evaluate why. There are many reasons a project might go poorly, so determining the cause of the problem is a prerequisite to solving it.

The end of the first year is the perfect time to evaluate whether or not the program is worth continuing to invest in. If the team was not able to meaningfully improve the security of the organization, or if resources will not be available to expand upon the improvements that were made, it is likely best to reallocate the resources the team had and revisit it sometime in the future. If, however, the team does show promise, there are nearly endless of opportunities to disrupt attackers with deception for the team to explore.