Talk:Attack tree

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer Security / Computing   
WikiProject icon This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
 

Mitigating threats[edit]

I want to write about mitigating threats, but it's largely "original research" in that I am just looking at the attack tree and pointing out obvious cause and effect. For example I stated that modifying the attack tree as close to the root is the most obvious way to eliminate as many threats as possible, but also adds other threats. This could be expanded on; but these are my own thoughts. On the other hand, these are proovable easily:

  • Mitigating a threat mitigates all subthreats that exist for the soul purpose of triggering the mitigated threat.
  • Mitigating a threat requires enabling feature X or adding software Y.
  • Enabling feature X raises concerns of flaws in feature X.
  • Adding software Y raises concerns of flaws in software Y.

This means an entire discussion can be made on the thought path of mitigating flaws and how this affects the attack tree. On the OTHER hand, an ARGUMENT is present in the FACTS as well:

  • Mitigating flaw A requires activating feature X.
  • Mitigating flaw B requires adding software Y.
  • Mitigating flaw C requires activating feature Z.
  • Mitigating flaws A, B, and C by activating features X and Z and adding software Y raise concerns for all of X, Y, and Z.

Here we show that mitigating A, B, and C in isolated and direct ways will add concerns for each option X, Y, Z used for mitigation. However, with more assumptions, we see an argument:

  • If flaw T requires sets of combinations of A, B, and C; and A, B, and C are on their own uninteresting without triggering flaw T; then mitigating flaw T mitigates A, B, and C by proxy.
  • If flaw T can be mitigated alone by feature S, then feature S mitigates A, B, and C.
  • Mitigating flaw T obsoletes X, Y, and Z.
  • If only feature S is activated, then concerns for feature S only are raised.

This means that basically by mitigating flaws close to the root, the minimum set of mitigation features and software is used, and thus added variables are kept to a minimum. As an example, individual incremental bug-fix patches on Apache, ProFTPd, and MySQL each create a risk of the software not working or encountering other security holes; while a system-level protection software such as PaX mitigates the intrusion threats covered by several of these patches while leaving the denial of service threats. Implementing PaX would bring similar concerns, but in much smaller force; and it would mitigate the individual concerns that each incrimental bug-fix patch may actually create an extra buffer overflow et al to replace the one it solves.