Talk:Attack tree

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computer Security: Computing Low‑importance 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.Computer SecurityWikipedia:WikiProject Computer SecurityTemplate:WikiProject Computer SecurityComputer Security articles Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Computing (assessed as Low-importance). Things you can help WikiProject Computer Security with: Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information... Review importance and quality of existing articles Identify categories related to Computer Security Tag related articles Identify articles for creation (see also: Article requests) Identify articles for improvement Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc. Find editors who have shown interest in this subject and ask them to take a look here.

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.

Hello fellow Wikipedians,

I have just modified one external link on Attack tree. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to https://acc.dau.mil/CommunityBrowser.aspx?id=322427#8.5.3.3
• Added archive https://web.archive.org/web/20100630060200/http://powercyber.ece.iastate.edu/publications/GM-CS.pdf to http://powercyber.ece.iastate.edu/publications/GM-CS.pdf
• Added {{dead link}} tag to http://www.innovativedecisions.com/documents/Buckshaw-Parnelletal.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:36, 21 October 2016 (UTC)[reply]