Fri Apr 8 06:51:40 PDT 2016
Incidents: Deception: When are deceptions used to defend networks and systems?
Options:
Option 1: Never use deceptions.
Option 2: Use deceptions when they are built into existing systems
Option 3: Use deceptions at firewalls
Option 4: Use deceptions within internal networks.
Option 5: Use deceptions within systems.
Decision:
IF legal impediments prevent the use of deception, THEN Never use deceptions.
OTHERWISE
IF risk is High, expertise is high, and other options have been exhausted with residual risk in excess of thresholds, THEN Use deceptions within systems.
IF insider threats are not adequately mitigated by other methods OR there is substantial residual risk of outsiders gaining internal access, THEN Use deceptions within internal networks.
IF the enterprise is using a layered zoning architecture THEN Use deceptions at firewalls.
AND Use deceptions when they are built into existing systems.
Basis:
Never use deceptions.
Deceptions must be disabled in order to prevent their use, and in
many systems, this may be difficult and expensive to do. However;
if legal mandates require that all deceptions be disabled, this
must be done.
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.
Copyright(c) Fred Cohen, 1988-2015 - All Rights Reserved
|