Blog post #3 outlined a hypothetical roadmap for a brand new deception program to follow in its first year. The purpose of this post is to assist decision makers as they navigate the countless options that may reveal themselves after the program’s pivotal first year. There are three areas that all influence the priority that opportunities in deception should be given.
Recent security incidents
Recent incidents can provide a deception team with a wealth of knowledge about the environment they aim to protect. In order for deception to catch attackers and improve the security of an organization, the deception has to be in an attacker’s path. The path an attacker took during a successful breach can be a very fruitful for a deception program. It provides a command-by-command view into the mindset the attacker had; from the internal reconnaissance commands they ran to discover potential victims to the accounts, devices, and services they chose to target, it is an unbiased account of the weak points in the security posture of an organization. These weak points can be bolstered with, or outright replaced by, decoys that might catch the next attacker in a similar situation.
It is worth noting that incidents don’t necessarily have to be “real” for them to be valuable. Offensive security exercises, especially when performed by a third party, can provide most of the benefits that a real security incident can, without the downsides. Third party tests of a security landscape are most effective when the rules of engagement - often defined in the contract, or scope of work (SoW) - are relaxed. If an offensive tester is told to achieve a specific outcome without using one or more specific approaches, it limits how helpful the test can be.
The biggest pitfall deception practitioners face when using recent security incidents - real or manufactured - to build their future roadmap is recency bias. Just because a recent attacker used a particular technique against a vulnerable target does not mean that future attackers will use the same technique against the same target.
Industry trends
Breach reports like those produced by Verizon, security risk lists like OWASP top ten, and attack frameworks like Mitre ATT&CK all aggregate data that can help an organization counter the recency bias they may experience when reviewing its past incidents.
Industry-wide trends in security can provide useful insight into what attackers are doing, and what is working for them against other targets. Combining information from reports like the above with information about the environment a deception team aims to protect may make it clear which opportunities for deception are most likely to pay off.
Environment
Very few environments are configured exactly the way the documentation says it is, and the drift between what is written and what is implemented is often home to things that keep the security team up at night. Spending time with other parts of the organization, whether that be other teams in security, teams responsible for IT, or other administrators of the organization may help shed light on a few known differences between documentation and implementation. These differences can be copied, or at least closely mimicked, by decoys, which could help catch an attacker later on.
Even if an environment was configured exactly the way the documentation says it was, it will likely be in a constant state of upgrading. Similar to a city that is never devoid of scaffolding, cranes, and an in-construction building — networks, fleets, and software stacks almost never remain untouched for long. Knowing in advance what is being deprecated - and what is replacing it - helps reveal even more opportunities for deception. Maybe a company has finally decided to migrate from password manager “A” to password manager “B,” it could be a good time to plant fake backups of solution “A” strategically around the organization. Or maybe the company is moving from software-as-a-service (SaaS) provider “C” to SaaS provider “D”. That might signal to the deception team that it should no longer put much effort into protecting provider “C’s” tenant with deception.
Wrapping up
There are, and likely always will be, many ways a deception team can protect an organization. Because the team won’t have the time or the resources to do them all, it is important for the team to work on the next-most-likely-to-work thing. This takes time and forethought, as it means that the team must constantly discover new methods of deceiving attackers and evaluating them against their current roadmap. The context of where the organization is and where it is going next must also influence the team’s decision, or it will fail to maximize its chances of detecting an attack.