Use deceptions when they are built into existing systems.
Built-in deceptions include everything from concealing files and directories when the user is not authorized to see them, to refusing to tell the user whether a user ID or password is wrong when a login fails. They are generally sound, in common use, and there is no reason to try to disable these mechanisms when they are built into systems. To the extent that configuration is required to manage them, unless there is a reason to disable some of them, they should be enabled. This tends to delay the attacker and thus reduces the need for rapid detection and response.
Use deceptions at firewalls.
In physically isolated architectures and completely open architectures, firewalls are largely in place as a side effect of the need to have gateways and routers. In these cases, firewalls should not perform other functions, because they are not required. However, in all other circumstances, deceptions in firewalls should be enabled and applied wherever feasible without severe performance impact. This reduces the "attack surface" and intelligence results without significant impact or configuration costs. This tends to delay the attacker and thus reduces the need for rapid detection and response.
Use deceptions within internal networks.
The same principles that apply to external attacks apply to the deception of attackers who have broken into the company network and insiders who wish to do unauthorized exploration of internal networks. By placing deceptions at internal firewalls and routers, internal scans and attacks are greatly disrupted while intrusion attempts are rapidly identified. This tends to delay the attacker and thus reduces the need for rapid detection and response.
Use deceptions within systems.
Deceptions within systems currently requires substantial time, effort, and expertise, with the exception of the default built-in deception mechanisms identified earlier. The key differentiating issue in the use of deceptions that are not built into systems and operational by default is their use in mitigating against event sequences with potentially serious negative consequences. In order to be effective, such defenses must conceal event sequences that attackers are likely to attempt to exploit and that have serious negative consequences. They can do this preventively by adding more event sequences that are likely to be tried by the attacker and that do not have serious negative consequences, thus increasing the search space for the attacker. Alternatively, they can be used responsively once an attack attempt has been detected to cover event sequences with potentially serious negative consequences from the attacker while permitting normal users and uses to continue uninterrupted.