diff --git a/docs/_static/3.png b/docs/_static/3.png
index 2c9f22d..5e7f731 100644
Binary files a/docs/_static/3.png and b/docs/_static/3.png differ
diff --git a/docs/_static/evidencescoring.png b/docs/_static/evidencescoring.png
index 7d3ee82..2f2a689 100644
Binary files a/docs/_static/evidencescoring.png and b/docs/_static/evidencescoring.png differ
diff --git a/docs/_static/protection_layer.svg b/docs/_static/protection_layer.svg
index 3f1a154..f8854ec 100644
--- a/docs/_static/protection_layer.svg
+++ b/docs/_static/protection_layer.svg
@@ -1,2 +1,2 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/_static/question1graphic.png b/docs/_static/question1graphic.png
index 8a44909..d690aae 100644
Binary files a/docs/_static/question1graphic.png and b/docs/_static/question1graphic.png differ
diff --git a/docs/_static/risklayer.svg b/docs/_static/risklayer.svg
index 32b43d7..622ec98 100644
--- a/docs/_static/risklayer.svg
+++ b/docs/_static/risklayer.svg
@@ -1 +1,2 @@
-
\ No newline at end of file
+
+
\ No newline at end of file
diff --git a/docs/_static/scoringlayer.svg b/docs/_static/scoringlayer.svg
index b6dc045..12f8b49 100644
--- a/docs/_static/scoringlayer.svg
+++ b/docs/_static/scoringlayer.svg
@@ -1 +1,2 @@
-
\ No newline at end of file
+
+
\ No newline at end of file
diff --git a/docs/_static/theory.svg b/docs/_static/theory.svg
index 5643e77..fbb074e 100644
--- a/docs/_static/theory.svg
+++ b/docs/_static/theory.svg
@@ -1,2 +1,2 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/_static/theory_evidence.svg b/docs/_static/theory_evidence.svg
index efb44e5..034cb9b 100644
--- a/docs/_static/theory_evidence.svg
+++ b/docs/_static/theory_evidence.svg
@@ -1,2 +1,2 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/_static/theoryevidencettps.png b/docs/_static/theoryevidencettps.png
index 8bcd087..b4966da 100644
Binary files a/docs/_static/theoryevidencettps.png and b/docs/_static/theoryevidencettps.png differ
diff --git a/docs/_static/theoryscoring.png b/docs/_static/theoryscoring.png
index 6d7513e..50e3bb6 100644
Binary files a/docs/_static/theoryscoring.png and b/docs/_static/theoryscoring.png differ
diff --git a/docs/additional-resources.rst b/docs/additional-resources.rst
index 318e7a1..46f1be3 100644
--- a/docs/additional-resources.rst
+++ b/docs/additional-resources.rst
@@ -1,3 +1,5 @@
+.. _Additional Resources:
+
Additional Resources
====================
@@ -10,13 +12,31 @@ Leveraging existing CTI allows you to develop known attack vectors that could be
* Many venders publish opensource reports on blogs or their websites. Monitor these sources for new/relevant reports. Attack Flow created best practices for selecting open-source reports and this can be beneficial during this step:
.. important::
- * “Reports should be transparent about where the data originates and provide a technically competent overview of an incident.
+ * Reports should be transparent about where the data originates and provide a technically competent overview of an incident.
* Reports should originate from a vendor with a track record of accurate reporting and first-hand analysis of the incident in question.
* Reports should provide the most current information on the malware or breach.
* Reports should make it easy to identify any information gaps. Use multiple sources to address gaps and corroborate the data, if possible.
* Reports should distinguish between facts, assumptions, and analytical assessments.
- * When available, use attribution and targeting information from reports to enrich your attack flows.”
+ * When available, use attribution and targeting information from reports to enrich your attack flows.
* When it comes to researching CTI for embedded systems, MITRE developed a publicly available knowledge base called `EMB3D `_. This is a great resource for both theory and evidence. Start by down selecting by embedded system property and read through the various threats to each.
It is a good idea to have a central location/repository for all your CTI data. This can be a spreadsheet or a threat intelligence platform (TIP) like OpenCTI (see example data below for FIN7). There are many TIP out there that will do to research work for you – automatically pulling in the latest vender reports. Some TIPs will even auto-parse the data in reports for you. Be sure to spot check any automated report parsing for accuracy.
+
+Attack Flow
+-----------
+
+.. raw:: html
+
+
+
+
+|
+
+Emulation Tools Mapped to ATT&CK
+--------------------------------
+There are existing processes or data sources you can leverage to answer these questions. Perhaps your organization has a process for system risk acceptance, or you actively track system patches and compliance metrics.
+
+Alternatively, you can stress test your system by subjecting it to some type of security assessment. This can be accomplished through an internal or external team emulating adversary behavior. Short of a full red teaming exercise, existing resources such as `Caldera `_ integrate directly with MITRE ATT&CK and can be used as part of attack simulation exercises. Other tools, like the `Atomic Red Team `_, detail tests tied to specific ATT&CK techniques that can be performed on your system to evaluate the strength of your mitigations.
+
+These can all inform your secondary review and give you the answers you need. From this secondary review, you’ll be able to ensure that your mitigations are sufficiently tailored to your system as it evolves with time.
diff --git a/docs/extra/layers/protection_layer.json b/docs/extra/layers/protection_layer.json
index e87a3b8..47e3355 100644
--- a/docs/extra/layers/protection_layer.json
+++ b/docs/extra/layers/protection_layer.json
@@ -308,16 +308,6 @@
"metadata": [],
"links": [],
"showSubtechniques": false
- },
- {
- "techniqueID": "T1059",
- "tactic": "execution",
- "color": "#bdbdbd",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
}
],
"gradient": {
diff --git a/docs/extra/layers/risk_layer.json b/docs/extra/layers/risk_layer.json
index f4a2594..a1c9c12 100644
--- a/docs/extra/layers/risk_layer.json
+++ b/docs/extra/layers/risk_layer.json
@@ -320,17 +320,6 @@
"metadata": [],
"links": [],
"showSubtechniques": false
- },
- {
- "techniqueID": "T1059",
- "tactic": "execution",
- "score": 3,
- "color": "",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
}
],
"gradient": {
diff --git a/docs/extra/layers/scoring_layer.json b/docs/extra/layers/scoring_layer.json
index a5c7061..3faeb3b 100644
--- a/docs/extra/layers/scoring_layer.json
+++ b/docs/extra/layers/scoring_layer.json
@@ -57,17 +57,6 @@
"links": [],
"showSubtechniques": false
},
- {
- "techniqueID": "T1059",
- "tactic": "execution",
- "score": 3,
- "color": "",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
- },
{
"techniqueID": "T1528",
"tactic": "credential-access",
diff --git a/docs/extra/layers/theory.json b/docs/extra/layers/theory.json
index 098dfc2..47658f4 100644
--- a/docs/extra/layers/theory.json
+++ b/docs/extra/layers/theory.json
@@ -294,16 +294,6 @@
"links": [],
"showSubtechniques": false
},
- {
- "techniqueID": "T1134",
- "tactic": "privilege-escalation",
- "color": "#9e9ac8",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
- },
{
"techniqueID": "T1111",
"tactic": "credential-access",
@@ -344,16 +334,6 @@
"links": [],
"showSubtechniques": false
},
- {
- "techniqueID": "T1059",
- "tactic": "execution",
- "color": "#9e9ac8",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
- },
{
"techniqueID": "T1059.001",
"tactic": "execution",
diff --git a/docs/extra/layers/theory_+_evidence.json b/docs/extra/layers/theory_+_evidence.json
index 0c28cbe..785c5e0 100644
--- a/docs/extra/layers/theory_+_evidence.json
+++ b/docs/extra/layers/theory_+_evidence.json
@@ -294,16 +294,6 @@
"links": [],
"showSubtechniques": false
},
- {
- "techniqueID": "T1134",
- "tactic": "privilege-escalation",
- "color": "#9e9ac8",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
- },
{
"techniqueID": "T1111",
"tactic": "credential-access",
@@ -344,16 +334,6 @@
"links": [],
"showSubtechniques": false
},
- {
- "techniqueID": "T1059",
- "tactic": "execution",
- "color": "#969696",
- "comment": "",
- "enabled": true,
- "metadata": [],
- "links": [],
- "showSubtechniques": false
- },
{
"techniqueID": "T1059.001",
"tactic": "execution",
diff --git a/docs/index.rst b/docs/index.rst
index 3a7e4f7..150290e 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -10,10 +10,12 @@ Threat Modeling with ATT&CK |version|
Threat Modeling with ATT&CK provides a recommended approach that integrates the common language that security operations teams rely upon - `MITRE ATT&CK® `_ - into their organization’s threat modeling practices. Creating an approach to threat modeling that integrates ATT&CK enables cyber defenders to focus on the activity of threat modeling with a clear, consistent understanding of adversary behaviors and tailor defensive investments to mitigate threats related to their systems or environments.
At the core of this approach are four key questions, outlined in the `Threat Modeling Manifesto `_, that we need to answer:
-Question 1: What are we working on?
-Question 2: What could go wrong?
-Question 3: What are we going to do about it?
-Question 4: Did we do a good job?
+
+* Question 1: What are we working on?
+* Question 2: What could go wrong?
+* Question 3: What are we going to do about it?
+* Question 4: Did we do a good job?
+
This project is created and maintained by `MITRE Engenuity Center for Threat-Informed Defense (Center) `_ and is funded by our `research participants `_, in furtherance of our mission to advance the state of the art and the state of the practice in threat-informed defense globally. This work builds upon The MITRE Corporation’s `Playbook for Threat Modeling Medical Devices `_ by applying this integrated threat modeling approach to the fictional medical device created under that project.
.. toctree::
diff --git a/docs/introduction.rst b/docs/introduction.rst
index a6fe617..c60f691 100644
--- a/docs/introduction.rst
+++ b/docs/introduction.rst
@@ -7,7 +7,7 @@ Introduction
Threat Modeling with ATT&CK Overview (Click to Enlarge)
-The process outlined in this project details an approach developed by MITRE Engenuity’s Center for Threat-Informed Defense (hereafter, the Center) for integrating MITRE ATT&CK® into your organization’s existing threat modeling methodology.
+The process outlined in this project details an approach developed by `MITRE Engenuity’s Center for Threat-Informed Defense `_ (hereafter, the Center) for integrating `MITRE ATT&CK® `_ into your organization’s existing threat modeling methodology.
At the core of this approach are four key questions, outlined in the `Threat Modeling Manifesto `_, that we need to answer:
* Question 1: What are we working on?
diff --git a/docs/question-1.rst b/docs/question-1.rst
index a6327f0..467e8d8 100644
--- a/docs/question-1.rst
+++ b/docs/question-1.rst
@@ -5,7 +5,7 @@ Question 1: What are we working on?
.. figure:: /_static/question1graphic.png
:alt: Question 1 Overview
- :scale: 30%
+ :scale: 20%
:align: center
Question 1 Overview Graphic (Click to Enlarge)
@@ -84,7 +84,7 @@ As a security team evaluating AMPS for its manufacturer, we identified that a co
.. figure:: /_static/3.png
:alt: Mission/System Decomposition Graphic
- :scale: 50%
+ :scale: 20%
:align: right
Step 2: Identify Operational Tasks (Cross Functional Flow Chart)
@@ -100,7 +100,7 @@ Next, leverage the knowledge pooled from stakeholders to determine the different
Part 3: System Decomposition
----------------------------
-Step 3: Develop a Data Flow Diagram (DFD) of your system.
+Step 1: Develop a Data Flow Diagram (DFD) of your system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are multiple ways to design a DFD, but we recommend the `DFD3 `_ standard. Begin by answering the following questions:
@@ -124,7 +124,7 @@ From these questions, start to draw your diagram and gradually add additional co
Mid-level DFD with Trust Boundaries (Click to Enlarge)
-Step 4: Determine which system functions are associated with distinct operational tasks.
+Step 2: Determine which system functions are associated with distinct operational tasks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the DFD of your system in hand, you can then link the system’s operational tasks to specific system functions. When executing a specific task, what parts of the system are utilized? These include both assets and data flows between systems.
diff --git a/docs/question-2.rst b/docs/question-2.rst
index aa30c55..ee4f082 100644
--- a/docs/question-2.rst
+++ b/docs/question-2.rst
@@ -94,7 +94,7 @@ Using our knowledge of the system we codified responding to Question 1, we now n
Visualizing attack trees
^^^^^^^^^^^^^^^^^^^^^^^^
-To visualize these attack trees, we used (and recommend using) MITRE Engenuity’s Attack Flow Builder (see below), but there are several other simple and complex tools you can use to build your attack trees. The easiest approach is to use a common tool like Microsoft Word or PowerPoint. The graphic design tool Canva is another great, easy-to-use option (any graphic design software can work as well). For more formal tools capable of complex analysis, there are a few options:
+To visualize these attack trees, we used (and recommend using) `MITRE Engenuity’s Attack Flow Builder `_, but there are several other simple and complex tools you can use to build your attack trees. The easiest approach is to use a common tool like Microsoft Word or PowerPoint. The graphic design tool Canva is another great, easy-to-use option (any graphic design software can work as well). For more formal tools capable of complex analysis, there are a few options:
* `SecurITree `_, developed by Amenaza Technologies, is purpose-built for attack tree analyses and allows for the addition of detailed attributes to different attack paths, risk metrics, and adversary personas.
* The `AT-AT `_ (Attack Tree Analysis Tool) allows users to develop and analyze attack scenarios in much the same way.
@@ -161,7 +161,7 @@ Below is an example of how a theoretical attack can be aligned with a TTP (Brows
During our search for threats relevant to the AMPS device, we determined that one of the vectors (branch of the tree) an attacker could use to access user location data was by accessing their web portal. We determined that one potential vector for gaining access to the user’s portal was by stealing their log-in credentials. This can be done using an activity characterized as Session Hijacking in ATT&CK.
-Ultimately, we will be integrating these threats into a singular tree using the Center’s Attack Flow tool and directly linking them to our critical assets. Attack Flow integrates seamlessly with ATT&CK. Threat actor actions represented as nodes on the tree can be linked to specific TTPs. Furthermore, additional contextual elements such as attack characteristics, assets, data types, conditions, and references can be added to each node of the tree. With Browser Session Hijacking (T1185) identified as one of our theoretical exploits, we can now associate that specific node on the tree with T1185, thereby pulling in all the data that’s been associated with that exploit. Not all the threats you identify will be directly tied to TTPs, but these threats should still be included in your tree and will still inform the response you develop in Question 3.
+Ultimately, we will be integrating these threats into a singular tree using the Center’s Attack Flow tool and directly linking them to our critical assets. Attack Flow integrates seamlessly with ATT&CK. A Threat actor actions represented as nodes on the tree can be linked to specific TTPs. Furthermore, additional contextual elements such as attack characteristics, assets, data types, conditions, and references can be added to each node of the tree. With Browser Session Hijacking (T1185) identified as one of our theoretical exploits, we can now associate that specific node on the tree with T1185, thereby pulling in all the data that’s been associated with that exploit. Not all the threats you identify will be directly tied to TTPs, but these threats should still be included in your tree and will still inform the response you develop in Question 3.
An example of the AMPS attack tree and all associated TTPs can be found below.
@@ -172,6 +172,8 @@ An example of the AMPS attack tree and all associated TTPs can be found below.
Example AMPS Attack Tree Converted into Attack Flow
+For more information on the Attack Flow Builder, review the :ref:`Additional Resources` page. There you'll find a more detailed walkthrough of the Builder and its attack tree modeling capabilities.
+
Evidence
---------
@@ -532,8 +534,8 @@ The following table summarizes the TTPs identified during the Theory and Evidenc
.. figure:: /_static/theoryevidencettps.png
:alt: Evidence and Theory TTPs Table
- :scale: 40%
- :align: right
+ :scale: 25%
+ :align: center
Evidence and Theory TTPs Table
@@ -552,7 +554,7 @@ To keep the rest of this example concise, we have elected to only score the TTPs
.. figure:: /_static/theoryscoring.png
:alt: Theory Scoring Table
- :scale: 30%
+ :scale: 25%
:align: center
Theory Scoring Table
@@ -579,7 +581,7 @@ Some notes on the above:
.. figure:: /_static/evidencescoring.png
:alt: Evidence Scoring Table
- :scale: 40%
+ :scale: 25%
:align: center
Evidence Scoring Table