diff --git a/README.md b/README.md index 4e3b400..2aa9696 100644 --- a/README.md +++ b/README.md @@ -1,87 +1,61 @@ # Threat Modeling with ATT&CK - - -Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor -incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud -exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure -dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. -Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt -mollit anim id est laborum. +Threat Modeling with ATT&CK defines how to integreate MITRE ATT&CK® into your +organization’s existing threat modeling methodology. This process is intended for +universal application to any system or technology stack (large or small) using any +existing threat modeling methodology like STRIDE, PASTA, or Attack Trees. To demonstrate +its use and applicability to a wide audience of cybersecurity practitioners, we apply +this process to a fictional internet-of-things (IOT) system called the Ankle Monitoring +Predictor of Stroke (AMPS). **Table Of Contents:** - - - [Getting Started](#getting-started) - [Getting Involved](#getting-involved) - [Questions and Feedback](#questions-and-feedback) -- [How Do I Contribute?](#how-do-i-contribute) - [Notice](#notice) ## Getting Started - +Go to the project website to learn all about the Threat Modeling with ATT&CK process, +including detailed steps for applying the process and comprehensive examples based. -Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor -incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud -exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure -dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. -Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt -mollit anim id est laborum. - -| Resource | Description | -| --------------- | ------------------------ | -| [Resource 1](#) | Description of resource. | -| [Resource 2](#) | Description of resource. | -| [Resource 3](#) | Description of resource. | +| Resource | Description | +| ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | +| [Project Website](https://center-for-threat-informed-defense.github.io/threat-modeling-with-attack/) | The project website describes the comprehensive threat modeling process. | ## Getting Involved - - There are several ways that you can get involved with this project and help advance threat-informed defense: -- **Way to get involved 1.** Lorem ipsum dolor sit amet, consectetur adipiscing elit, - sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. -- **Way to get involved 2.** Ut enim ad minim veniam, quis nostrud exercitation ullamco - laboris nisi ut aliquip ex ea commodo consequat. -- **Way to get involved 3.** Duis aute irure dolor in reprehenderit in voluptate velit - esse cillum dolore eu fugiat nulla pariatur. +- **Read the Threat Modeling process.** Read the detailed process defined by this + project and learn how to apply it by following through the realistic examples. +- **Apply Threat Modeling to your own projects.** Put the project into action by using + it to conduct your next threat modeling exercise. +- **Spread the word.** Provide feedback to us regarding the usefulness of the project + and share the word with your peers and colleagues in the industry. ## Questions and Feedback -Please submit issues for any technical questions/concerns or contact +Please submit [issues on +GitHub](https://github.com/center-for-threat-informed-defense/threat-modeling-with-attack/issues) +for any technical questions or requests. You may also contact [ctid@mitre-engenuity.org](mailto:ctid@mitre-engenuity.org?subject=Question%20about%20threat-modeling-with-attack) -directly for more general inquiries. - -Also see the guidance for contributors if are you interested in contributing or simply -reporting issues. - -## How Do I Contribute? - -We welcome your feedback and contributions to help advance -Threat Modeling with ATT&CK. Please see the guidance for contributors if are you -interested in [contributing or simply reporting issues.](/CONTRIBUTING.md) +directly for more general inquiries about the Center for Threat-Informed Defense. -Please submit -[issues](https://github.com/center-for-threat-informed-defense/threat-modeling-with-attack/issues) for -any technical questions/concerns or contact -[ctid@mitre-engenuity.org](mailto:ctid@mitre-engenuity.org?subject=subject=Question%20about%20threat-modeling-with-attack) -directly for more general inquiries. +We welcome your contributions to help advance Threat Modeling with ATT&CK in the form of +[pull +requests](https://github.com/center-for-threat-informed-defense/threat-modeling-with-attack/pulls). +Please review the [contributor +notice](https://github.com/center-for-threat-informed-defense/threat-modeling-with-attack/blob/main/CONTRIBUTING.md) +before making a pull request. ## Notice -Copyright 2024 MITRE Engenuity. Approved for public release. Document number REPLACE_WITH_PRS_NUMBER +© 2024 MITRE Engenuity. Approved for public release. Document number(s) REPLACE_WITH_PRS_NUMBER. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at diff --git a/docs/additional-resources.rst b/docs/additional-resources.rst index 46f1be3..697536f 100644 --- a/docs/additional-resources.rst +++ b/docs/additional-resources.rst @@ -6,10 +6,19 @@ Additional Resources Cyber Threat Intelligence Resources ----------------------------------- -Leveraging existing CTI allows you to develop known attack vectors that could be used against your system. There are many resources for CTI data and this appendix is made to refence a few that we have found useful. +Leveraging existing CTI allows you to develop known attack vectors that could be used +against your system. There are many resources for CTI data and this appendix is made to +refence a few that we have found useful. -* The Center’s `Sightings Ecosystem `_ project is an example of data that can be leveraged throughout this process to help identify, or highlight, commonly seen TTPs. At the time of publish, the work consists of over 1.6 million sightings of 353 unique techniques from almost 200 countries. -* 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: +* The Center’s `Sightings Ecosystem + `_ + project is an example of data that can be leveraged throughout this process to help + identify, or highlight, commonly seen TTPs. At the time of publish, the work + consists of over 1.6 million sightings of 353 unique techniques from almost 200 + countries. +* 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. @@ -19,9 +28,17 @@ Leveraging existing CTI allows you to develop known attack vectors that could be * Reports should distinguish between facts, assumptions, and analytical assessments. * 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. +* 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. +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 ----------- @@ -30,13 +47,27 @@ Attack Flow +.. TODO were they planning to put a video here? we don't have an attack flow youtube | 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. +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. -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. +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 the +`Adversary Emulation Library +`_ +and `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/cheat-sheet.rst b/docs/cheat-sheet.rst index 365baca..7abb85c 100644 --- a/docs/cheat-sheet.rst +++ b/docs/cheat-sheet.rst @@ -2,7 +2,10 @@ Condensed Process ================= .. note:: - This Condensed Process should only be used if your team has limited time to conduct threat modeling (days instead of weeks). Before using, please review Questions 1 through 4 of the uncondensed process. + + This Condensed Process should only be used if your team has limited time to conduct + threat modeling (days instead of weeks). Before using, please review Questions 1 + through 4 of the uncondensed process. :ref:`Question 1` ------------------- @@ -16,7 +19,8 @@ Condensed Process Develop a top-level Dataflow Diagram for your system -Identify critical components and dataflows that, when impacted, would result in mission failure +Identify critical components and dataflows that, when impacted, would result in mission +failure :ref:`Question 2` ------------------- @@ -50,7 +54,8 @@ Implement the mitigations listed within the ATT&CK page for each brainstormed TT **OR** -Implement the NIST 800-53 controls for each brainstormed TTP using the MITRE Engenuity Mappings Explorer +Implement the NIST 800-53 controls for each brainstormed TTP using the MITRE Engenuity +Mappings Explorer .. figure:: /_static/condensedprocess4.png :alt: Mappings Explorer Outline @@ -70,5 +75,6 @@ Implement the NIST 800-53 controls for each brainstormed TTP using the MITRE Eng Reevaluate -Periodically repeat this process to evaluate your existing mitigations and make sure they are in sync with the development of your system. +Periodically repeat this process to evaluate your existing mitigations and make sure +they are in sync with the development of your system. diff --git a/docs/index.rst b/docs/index.rst index 150290e..a0c77a2 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -3,20 +3,24 @@ Threat Modeling with ATT&CK |version| .. figure:: /_static/projectphoto.png :alt: Project Photo - :scale: 30% + :scale: 40% :align: center | -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? - -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. +Threat Modeling with ATT&CK provides a recommended approach that integrates `MITRE +ATT&CK® `_ – the common language that security operations +teams rely upon – into their organization’s threat modeling practices. The ATT&CK +integration 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. + +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. .. toctree:: :maxdepth: 2 diff --git a/docs/introduction.rst b/docs/introduction.rst index c60f691..29974e9 100644 --- a/docs/introduction.rst +++ b/docs/introduction.rst @@ -7,18 +7,43 @@ 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. -At the core of this approach are four key questions, outlined in the `Threat Modeling Manifesto `_, that we need to answer: +This project defines how to integreate `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? * 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 process is intended for universal application to any system or technology stack (large or small) using any existing threat modeling methodology like STRIDE, PASTA, or Attack Trees. To demonstrate its use and applicability to a wide audience of cybersecurity practitioners, we apply this process to a fictional internet of things (IOT) system called the Ankle Monitoring Predictor of Stroke (AMPS). The fictional AMPS device gives the wearer and their healthcare providers indications and warnings of a stroke. The systems and subsystems that make up this device are modeled after a popular commercially available IOT device and intentionally chosen for their mobile/cloud-based dependencies. This broad application to a system spanning mobile and enterprise environments allows readers to visualize how this process could be applied to their problem sets. Examples throughout this project are from the perspective of a security team working for the AMPS manufacturer. They have been tasked with modeling threats to the AMPS device and supporting system infrastructure. +This process is intended for universal application to any system or technology stack +(large or small) using any existing threat modeling methodology like STRIDE, PASTA, or +Attack Trees. To demonstrate its use and applicability to a wide audience of +cybersecurity practitioners, we apply this process to a fictional internet-of-things +(IOT) system called the Ankle Monitoring Predictor of Stroke (AMPS). The fictional AMPS +device gives the wearer and their healthcare providers indications and warnings of a +stroke. 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. -Using the process described throughout Questions 1-4, we identify critical components of the AMPS, prioritize threats to those components, and recommend mitigations. Threat modeling with ATT&CK allows us to leverage data from the Cyber Threat Intelligence (CTI) community and significantly improve our results in Questions 2 and 3. We will break down our means of answering each question in further detail throughout the sections. +The systems and subsystems that make up this device are modeled after a popular +commercially available IOT device and intentionally chosen for their mobile/cloud-based +dependencies. This broad application to a system spanning mobile and enterprise +environments allows readers to visualize how this process could be applied to their +problem sets. Examples throughout this project are presented from the perspective of a +security team working for the AMPS manufacturer. They have been tasked with modeling +threats to the AMPS device and supporting system infrastructure. + +Using the process described throughout Questions 1-4, we identify critical components of +the AMPS, prioritize threats to those components, and recommend mitigations. Threat +modeling with ATT&CK allows us to leverage Cyber Threat Intelligence (CTI) data to +significantly improve our results in Questions 2 and 3. We will break down our means of +answering each question in further detail throughout the sections. .. note:: - Detailed examples of each step throughout this process will be available in collapsed sections throughout. Be sure to check them out! + Detailed examples of each step throughout this process will be available in + collapsed sections throughout. Be sure to check them out! diff --git a/docs/question-1.rst b/docs/question-1.rst index 467e8d8..4af1339 100644 --- a/docs/question-1.rst +++ b/docs/question-1.rst @@ -10,7 +10,10 @@ Question 1: What are we working on? Question 1 Overview Graphic (Click to Enlarge) -Question 1 enables the primary and secondary function(s) of the system to be identified and analyzed. It identifies critical tasks that must be performed for the system to successfully accomplish its function(s) and highlights the resources those critical tasks rely upon. +Question 1 enables the primary and secondary function(s) of the system to be identified +and analyzed. It identifies critical tasks that must be performed for the system to +successfully accomplish its function(s) and highlights the resources those critical +tasks rely upon. Part 1: Assemble your team -------------------------- @@ -18,7 +21,10 @@ Part 1: Assemble your team Step 1: Gather relevant documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Ensure the team familiarizes themselves with relevant documentation of the system under analysis. We want to ensure the team understands the system prior to engaging other stakeholders. Depending on your type of system and the time you have, some documents we recommend reviewing are: +Ensure the team familiarizes themselves with relevant documentation of the system under +analysis. We want to ensure the team understands the system prior to engaging other +stakeholders. Depending on your type of system and the time you have, some documents we +recommend reviewing are: +------------------------------------------------+------------------------------+ | Documents of Interest | @@ -47,40 +53,80 @@ Ensure the team familiarizes themselves with relevant documentation of the syste +------------------------------------------------+------------------------------+ Step 2: Identify key stakeholders -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -These individuals are your subject matter experts who will provide insights into the nature of the assessed system. They can either serve as active members of the assessment team or as points of contact throughout the assessment as needed. You may already know who these individuals are, but there are some techniques that might help you narrow your search for relevant personnel: +These individuals are your subject matter experts who will provide insights into the +nature of the assessed system. They can either serve as active members of the assessment +team or as points of contact throughout the assessment as needed. You may already know +who these individuals are, but there are some techniques that might help you narrow your +search for relevant personnel: #. Pre-mortem - * Imagine a crisis scenario: the assessed system is inoperable; the timeline for project development has broken down; you’re unable to provide a key service to your customers, etc. Who do you call? What information do you need? + * Imagine a crisis scenario: the assessed system is inoperable; the timeline for + project development has broken down; you’re unable to provide a key service to your + customers, etc. Who do you call? What information do you need? #. Responsible, Accountable, Consulted, and Informed (RACI) Matrix - * A RACI Matrix lets you represent which staff are involved in the operation of the system in question, and their respective impact. - * A RACI Matrix that ties specific staff to tasks and cyber assets can be developed in tandem with the development of a Mission Impact Assessment (see below) + * A RACI Matrix lets you represent which staff are involved in the operation of the + system in question, and their respective impact. + * A RACI Matrix that ties specific staff to tasks and cyber assets can be developed + in tandem with the development of a Mission Impact Assessment (see below). Step 3: Prepare for the kick-off -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Prior to your initial kick-off meeting with the individuals identified in Step 2, request precise programmatic documentation that only speaks to the materials in scope for the assessment – consider using draft documentation instead of waiting for final products. +Prior to your initial kick-off meeting with the individuals identified in Step 2, +request precise programmatic documentation that only speaks to the materials in scope +for the assessment – consider using draft documentation instead of waiting for final +products. -* For external stakeholders, pairing this with a site visit would allow them to tour the host’s facilities, observe a demonstration, or participate in a technical briefing. +.. note:: -Step 4: Meet with stakeholders -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + For external stakeholders, pairing this with a site visit would allow them to tour the + host’s facilities, observe a demonstration, or participate in a technical briefing. -Depending on time, we recommend having at least two meetings. This gives your stakeholders a chance to communicate with each other and fosters valuable crosstalk. The first meeting is your “kick-off,” which establishes a common understanding of the scope and intent of your threat modeling, establishes relationships with your identified stakeholders, and gives them an understanding of how/why you will be working with them. The second meeting is at the end of your threat modeling process and gives you a chance to present your assessments and get feedback from your stakeholders prior to completion. Informal technical exchanges between stakeholders should also occur outside of these meetings throughout the duration of the assessment. +Step 4: Meet with stakeholders +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Depending on time, we recommend having at least two meetings. This gives your +stakeholders a chance to communicate with each other and fosters valuable crosstalk. The +first meeting is your “kick-off,” which establishes a common understanding of the scope +and intent of your threat modeling, establishes relationships with your identified +stakeholders, and gives them an understanding of how/why you will be working with them. +The second meeting is at the end of your threat modeling process and gives you a chance +to present your assessments and get feedback from your stakeholders prior to completion. +Informal technical exchanges between stakeholders should also occur outside of these +meetings throughout the duration of the assessment. Part 2: Mission Decomposition ----------------------------- -After conducting your kick-off meeting, it's time to start conducting an analysis of your mission and the systems needed to facilitate it. Drafting this analysis can also be done during your kick-off meeting or over the course of several meetings/discussions with stakeholders, depending on how much time you have. Below are four steps that can guide you through mission and system decomposition. Each step has a series of questions that drive a better understanding of your critical assets. + +After conducting your kick-off meeting, it's time to start conducting an analysis of +your mission and the systems needed to facilitate it. Drafting this analysis can also be +done during your kick-off meeting or over the course of several meetings/discussions +with stakeholders, depending on how much time you have. Below are four steps that can +guide you through mission and system decomposition. Each step has a series of questions +that drive a better understanding of your critical assets. Step 1: Map the mission objectives -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -At this stage we want to determine: What is the ultimate purpose of the system? What goal is the system trying to accomplish? -It’s here that we’ll invoke our fictional example device: the Ankle Monitoring Predictor of Stroke (AMPS). This fabricated IoT device is borrowed from MITRE’s `Playbook for Threat Modeling Medical Devices `_. In our scenario, this device is meant to be worn by a patient who is at increased risk of experiencing a stroke. By wearing the device throughout the day, the patient and their doctor can monitor for indicators of an imminent stroke via a companion app on the patient’s phone and readings uploaded to the AMPS cloud service each day. -As a security team evaluating AMPS for its manufacturer, we identified that a core mission objective of AMPS is to collect and share patient health data accurately and securely. Because of the sensitive nature of the health data AMPS collects and shares, which includes location data to guide an emergency response in the event of a stroke, the AMPS device should effectively protect the confidentiality of that data. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At this stage we want to determine: What is the ultimate purpose of the system? What +goal is the system trying to accomplish? It’s here that we’ll invoke our fictional +example device: the Ankle Monitoring Predictor of Stroke (AMPS). This fabricated IoT +device is borrowed from MITRE’s `Playbook for Threat Modeling Medical Devices +`_. +In our scenario, this device is meant to be worn by a patient who is at increased risk +of experiencing a stroke. By wearing the device throughout the day, the patient and +their doctor can monitor for indicators of an imminent stroke via a companion app on the +patient’s phone and readings uploaded to the AMPS cloud service each day. As a security +team evaluating AMPS for its manufacturer, we identified that a core mission objective +of AMPS is to collect and share patient health data accurately and securely. Because of +the sensitive nature of the health data AMPS collects and shares, which includes +location data to guide an emergency response in the event of a stroke, the AMPS device +should effectively protect the confidentiality of that data. .. figure:: /_static/3.png :alt: Mission/System Decomposition Graphic @@ -89,26 +135,41 @@ As a security team evaluating AMPS for its manufacturer, we identified that a co Step 2: Identify Operational Tasks (Cross Functional Flow Chart) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Next, leverage the knowledge pooled from stakeholders to determine the different operational sub-systems that contribute to the system’s primary purpose identified in Step 1. An Analytic Hierarchy Process (AHP) can be used to weigh the importance of different operational systems. Ask yourself, what are the operational tasks that must be executed to perform that function? These are also known as Mission Essential Functions (MEFs). To visualize these MEFs, we recommend using a cross functional flow chart like the one below for the AMPS. + +Next, leverage the knowledge pooled from stakeholders to determine the different +operational sub-systems that contribute to the system’s primary purpose identified in +Step 1. An Analytic Hierarchy Process (AHP) can be used to weigh the importance of +different operational systems. Ask yourself, what are the operational tasks that must be +executed to perform that function? These are also known as Mission Essential Functions +(MEFs). To visualize these MEFs, we recommend using a cross functional flow chart like +the one below for the AMPS. .. figure:: /_static/4.png :alt: Cross-Functional Flow Chart of a Data Flow in a Fictional Medical Device: the Ankle Monitor Predictor of Stroke (AMPS) :scale: 75% :align: center - Cross-Functional Flow Chart of a Data Flow in a Fictional Medical Device: the Ankle Monitor Predictor of Stroke (AMPS) + Cross-Functional Flow Chart of a Data Flow in a Fictional Medical Device: the Ankle + Monitor Predictor of Stroke (AMPS) Part 3: System Decomposition ---------------------------- + 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: + +There are multiple ways to design a DFD, but we recommend the `DFD3 +`_ standard. Begin by answering the following +questions: * What are the known components of the system? * What components within your system connect to each other? * What known third-party connections exist outside of your system’s control? -From these questions, start to draw your diagram and gradually add additional components and sub-systems to the DFD depending on scope and time. Start at a high level and work your way down as seen in the below AMPS examples. Ultimately, these datapoints should come together to form a comprehensive map of your system. +From these questions, start to draw your diagram and gradually add additional components +and sub-systems to the DFD depending on scope and time. Start at a high level and work +your way down as seen in the below AMPS examples. Ultimately, these datapoints should +come together to form a comprehensive map of your system. .. figure:: /_static/5.png :alt: High-level DFD for AMPS @@ -126,7 +187,10 @@ From these questions, start to draw your diagram and gradually add additional co 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. + +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. +-----------------------------+-------------------------+-----------------------+ |Mission Objective | Operational Task | System Function | @@ -141,14 +205,19 @@ With the DFD of your system in hand, you can then link the system’s operationa Part 4: Identification of critical assets ----------------------------------------- -Now that you’ve done mission and system decomposition, you should have a much better idea of which system functions facilitate operational tasks that enable your mission. Using your DFD and the matrix from Part 7, you can now identify critical assets. Ask yourself the following questions: + +Now that you’ve done mission and system decomposition, you should have a much better +idea of which system functions facilitate operational tasks that enable your mission. +Using your DFD and the matrix from Part 7, you can now identify critical assets. Ask +yourself the following questions: * Which system assets and dataflows are shared by multiple processes? * What assets and data flows enable different system functions? * How does the failure of each operational task impact the system’s mission objectives? * What are downstream effects of taking each cyber asset offline? -In the example below, we’ve identified critical assets/components of the AMPS using our DFD, highlighting them in gold. +In the example below, we’ve identified critical assets/components of the AMPS using our +DFD, highlighting them in gold. .. figure:: /_static/7.png :alt: Critical AMPS System Components diff --git a/docs/question-2.rst b/docs/question-2.rst index 6e7bd05..008c0c9 100644 --- a/docs/question-2.rst +++ b/docs/question-2.rst @@ -10,14 +10,25 @@ Question 2: What could go wrong? Question 2 Overview (Click to Enlarge) -The process outlined in Question 1 derives critical assets within a particular system. In Question 2, we identify and prioritize threats to those assets. MITRE ATT&CK® will serve as the framework through which we map and discuss threats to our system. While our analysis will go beyond the tactics, techniques, and procedures (TTPs) found within ATT&CK, its value as a language for detailing adversary behaviors makes it a central part of our approach. ATT&CK’s widespread use within the CTI community and its comprehensive classification system allow us to draw upon existing threat data while still integrating additional threats not yet captured in public reporting. - -For more information on ATT&CK, see `these resources `_. +The process outlined in Question 1 derives critical assets within a particular system. +In Question 2, we identify and prioritize threats to those assets. MITRE ATT&CK® will +serve as the framework through which we map and discuss threats to our system. While our +analysis will go beyond the tactics, techniques, and procedures (TTPs) found within +ATT&CK, its value as a language for detailing adversary behaviors makes it a central +part of our approach. ATT&CK’s widespread use within the CTI community and its +comprehensive classification system allow us to draw upon existing threat data while +still integrating additional threats not yet captured in public reporting. Theory vs. Evidence ------------------- -Generally, there are two complementary approaches that can be utilized to perform threat analysis: **Theoretical Modeling**, and **Evidence-based Analysis**. Regardless of which threat modeling methodology you use to answer Question 2, you will need to strike a balance between these two approaches for your model to be effective. Both approaches handle different aspects of the threat landscape, directly addressing the potential (“Could” and “Could not”) and the possible (“Has” and “Has not”) threats that concern your system. +Generally, there are two complementary approaches that can be utilized to perform threat +analysis: **Theoretical Modeling**, and **Evidence-based Analysis**. Regardless of which +threat modeling methodology you use to answer Question 2, you will need to strike a +balance between these two approaches for your model to be effective. Both approaches +handle different aspects of the threat landscape, directly addressing the potential +(“Could” and “Could not”) and the possible (“Has” and “Has not”) threats that concern +your system. .. figure:: /_static/theoryvsevidence.png :alt: Theory vs Evidence Rationale Table @@ -26,48 +37,84 @@ Generally, there are two complementary approaches that can be utilized to perfor Theory vs Evidence Rationale Table -The two axes on the above table represent the theoretical and evidence-based outcomes of a manifested threat. +The two axes on the above table represent the theoretical and evidence-based outcomes of +a manifested threat. -* Theory describes threats that have potential to impact your system. +* *Theory* describes threats that have potential to impact your system. - * Theory-based threats are hypothetical threats. These include brainstorming conducted by your team, known exploits performed in a controlled environment, and hypothetical attacks that have not been leveraged by threat actors. + * Theory-based threats are hypothetical threats. These include brainstorming + conducted by your team, known exploits performed in a controlled environment, and + hypothetical attacks that have not been leveraged by threat actors. -* Evidence describes documented threats that have been leveraged against other systems. +* *Evidence* describes documented threats that have been leveraged against other systems. - * Evidence-based threats are observed threats. These include TTPs used to exploit technology platforms leveraged by your system, known exploits used by adversaries that target your industry, and malicious actions you’ve recorded within your system. + * Evidence-based threats are observed threats. These include TTPs used to exploit + technology platforms leveraged by your system, known exploits used by adversaries + that target your industry, and malicious actions you’ve recorded within your + system. -When considered together, these two approaches give a well-rounded view of a system’s security posture, for both known and unknown threats. +When considered together, these two approaches give a well-rounded view of a system’s +security posture, for both known and unknown threats. .. figure:: /_static/10.png :alt: Theory and Evidence Scale - :scale: 80% :align: center Theory and Evidence Scale -Another way to consider how theory and evidence operate is in the context of vulnerability disclosure. The above timeline illustrates where and how theory and evidence support each other during the lifecycle of a zero-day. Inherently, theory-based modeling approaches tend to be more preparatory in anticipation of an unknown vulnerability, while evidence-based approaches tend to be more reactionary and respond to actualized threats in the wild. +Another way to consider how theory and evidence operate is in the context of +vulnerability disclosure. The above timeline illustrates where and how theory and +evidence support each other during the lifecycle of a zero-day. Inherently, theory-based +modeling approaches tend to be more preparatory in anticipation of an unknown +vulnerability, while evidence-based approaches tend to be more reactionary and respond +to actualized threats in the wild. -In the following section, we will be modeling threats against the AMPS device to demonstrate a well-rounded theory and evidence approach. We will employ Attack Trees as our example threat modeling methodology that could be used to derive potential threats. Using our tree, we’ll map theoretical and evidence-based threats an adversary might exploit to extract user information. +In the following section, we will be modeling threats against the AMPS device to +demonstrate a well-rounded theory and evidence approach. We will employ Attack Trees as +our example threat modeling methodology that could be used to derive potential threats. +Using our tree, we’ll map theoretical and evidence-based threats an adversary might +exploit to extract user information. Theory ------ -As we’ve discussed, a theory-based approach, regardless of which threat modeling methodology is used, identifies threats that have the potential to impact your system. We break this approach into three parts. +As we’ve discussed, a theory-based approach, regardless of which threat modeling +methodology is used, identifies threats that have the potential to impact your system. +We break this approach into three parts. Part 1: Structured threat brainstorming ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Goal:** Generate an unweighted list of threats against your system, based on the system analysis produced when answering Question 1. +**Goal:** Generate an unweighted list of threats against your system, based on the +system analysis produced when answering Question 1. -Mapping theoretical attacks on our system establishes the scope for our threat calculus. Much as we did in answering Question 1, we must think about the key assets we’re trying to protect. We then start from a high level, identifying as many access vectors targeting our critical assets as we can, or at least a large representative sample. This wide aperture allows us to then hone our focus as we progress to cataloguing attacks based on real-world evidence in the next section. In this manner, we’re able to capture attacks that are entirely possible but have yet to be observed in the wild, while also focusing much of our efforts on known vulnerabilities. While there are varying methods for building our catalogue of intrusions, we’ve chosen to leverage attack trees. +Mapping theoretical attacks on our system establishes the scope for our threat calculus. +Much as we did in answering Question 1, we must think about the key assets we’re trying +to protect. We then start from a high level, identifying as many access vectors +targeting our critical assets as we can, or at least a large representative sample. This +wide aperture allows us to then hone our focus as we progress to cataloguing attacks +based on real-world evidence in the next section. In this manner, we’re able to capture +attacks that are entirely possible but have yet to be observed in the wild, while also +focusing much of our efforts on known vulnerabilities. While there are varying methods +for building our catalogue of intrusions, we’ve chosen to leverage attack trees. **What is an attack tree?** -An attack tree is a threat modeling technique that allows analysts to map the various ways in which an adversary could exploit a specific system to accomplish a specific set of goals. In the context of the AMPS, we’ve identified that a key mission objective is maintaining the confidentiality of the user’s data. Our example attack tree will therefore aim at mapping the different pathways an adversary could take to access sensitive user information, namely their location. +An attack tree is a threat modeling technique that allows analysts to map the various +ways in which an adversary could exploit a specific system to accomplish a specific set +of goals. In the context of the AMPS, we’ve identified that a key mission objective is +maintaining the confidentiality of the user’s data. Our example attack tree will +therefore aim at mapping the different pathways an adversary could take to access +sensitive user information, namely their location. **Bottom-up attack trees** -Attack trees typically represent the flow of attacker actions in two ways: top-down or bottom-up. The attack tree below relies on a bottom-up approach and will serve as our template moving forward. This tree captures the sequential pathways an attack could, and in some cases must, take to reach its objective. Regardless of the attacker's intention, any adversary seeking to exploit a given system must achieve these intermediate goals. In this manner, the tree is agnostic towards the attacker’s subsequent goals. +Attack trees typically represent the flow of attacker actions in two ways: top-down or +bottom-up. The attack tree below relies on a bottom-up approach and will serve as our +template moving forward. This tree captures the sequential pathways an attack could, and +in some cases must, take to reach its objective. Regardless of the attacker's intention, +any adversary seeking to exploit a given system must achieve these intermediate goals. +In this manner, the tree is agnostic towards the attacker’s subsequent goals. .. figure:: /_static/11.png :alt: Example of Bottom-Up Attack Tree and One of its Isolated Sub-Trees @@ -76,9 +123,21 @@ Attack trees typically represent the flow of attacker actions in two ways: top-d Example of Bottom-Up Attack Tree and One of its Isolated Sub-Trees -Here we see a theoretical attack tree for a thief attempting to burgle a house. The thief has several potential avenues for achieving their goal. Some are more complex than others, requiring multiple steps. Some constitute entire sub-trees of their own, such as the “Garage Attack.” Each attack has its associated characteristics: the cost of the attack, the complexity, the likelihood of success, the time needed to execute it. Each of these will influence the attacker’s actions and therefore influence where mitigation strategies should be deployed. - -The origin point of the tree is the kernel, or root node, the ultimate objective of the attacker that sits at the top of the tree (in the example above, the root node of the tree is “Burgle House”). The attacker works their way towards that objective by satisfying the intermediate goals that branch out from the root node. Each branch represents a different exploitation strategy that can or must be employed to achieve the ultimate objective. In some cases, a particular strategy (branch) must be executed to allow another strategy to move forward. +Here we see a theoretical attack tree for a thief attempting to burgle a house. The +thief has several potential avenues for achieving their goal. Some are more complex than +others, requiring multiple steps. Some constitute entire sub-trees of their own, such as +the “Garage Attack.” Each attack has its associated characteristics: the cost of the +attack, the complexity, the likelihood of success, the time needed to execute it. Each +of these will influence the attacker’s actions and therefore influence where mitigation +strategies should be deployed. + +The origin point of the tree is the kernel, or root node, the ultimate objective of the +attacker that sits at the top of the tree (in the example above, the root node of the +tree is “Burgle House”). The attacker works their way towards that objective by +satisfying the intermediate goals that branch out from the root node. Each branch +represents a different exploitation strategy that can or must be employed to achieve the +ultimate objective. In some cases, a particular strategy (branch) must be executed to +allow another strategy to move forward. .. figure:: /_static/12.png :alt: Attack Tree design language @@ -87,56 +146,92 @@ The origin point of the tree is the kernel, or root node, the ultimate objective Attack Tree design language -The arrow-shaped OR nodes within the tree represent goals that can be achieved by any of the goals below them (here, Intermediate Goal 1 OR 2 OR 3). The flat bottom AND nodes, similarly, are fulfilled by the goals listed beneath them. All these goals (here, Subgoal 3a AND Subgoal 3b) must be fulfilled to progress. The square subgoals represent the actions that must be taken to achieve their final goal. +The arrow-shaped OR nodes within the tree represent goals that can be achieved by any of +the goals below them (here, Intermediate Goal 1 OR 2 OR 3). The flat bottom AND nodes, +similarly, are fulfilled by the goals listed beneath them. All these goals (here, +Subgoal 3a AND Subgoal 3b) must be fulfilled to progress. The square subgoals represent +the actions that must be taken to achieve their final goal. -Using our knowledge of the system we codified responding to Question 1, we now need to brainstorm potential attacks that could be launched against the critical assets we identified. We will do this using an attack tree. Initially, the nodes within the tree can be conceptual in nature. In the later steps, these will become more granular. +Using our knowledge of the system we codified responding to Question 1, we now need to +brainstorm potential attacks that could be launched against the critical assets we +identified. We will do this using an attack tree. Initially, the nodes within the tree +can be conceptual in nature. In the later steps, these will become more granular. Visualizing attack trees ^^^^^^^^^^^^^^^^^^^^^^^^ -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. -* `AttackTree `_ by Isograph similarly allows for attack tree modeling and additional threat analyses beyond the capabilities of a basic visualization tool. +To visualize these attack trees, we used the Center's `Attack Flow Builder +`_, but there are +several other tools you can use to build your attack trees. The simplest approach is to +use an office producitivy app like Microsoft Word or PowerPoint. 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. +* `AttackTree `_ by Isograph similarly + allows for attack tree modeling and additional threat analyses beyond the capabilities + of a basic visualization tool. All of these are viable options for crafting attack trees of your own. Part 2: Critical Path Analysis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Goal:** Find commonalities between threats produced during brainstorming and identify critical paths or components in your system. +**Goal:** Find commonalities between threats produced during brainstorming and identify +critical paths or components in your system. -In this step, just as we mapped system processes to critical assets in Question 1, we’re taking the theoretical attacks we’ve brainstormed and associating them with critical paths and components. +In this step, just as we mapped system processes to critical assets in Question 1, we’re +taking the theoretical attacks we’ve brainstormed and associating them with critical +paths and components. .. figure:: /_static/simpletree.png :alt: Bottom-up Simple Attack Tree - :scale: 5% - :align: left + :align: center Bottom-up Simple Attack Tree (Click to Enlarge) +As we establish these associations between threats and assets, we’ll begin distilling +our theoretical threats. This exercise will clarify how steps in an attack are +associated with one another, determining which attacks must be executed and in what +order. It will also verify whether certain steps in an attack are still possible once +mapped onto specific assets within the system. + .. figure:: /_static/14.png :alt: AMPS location information alongside Mid-Level DFD of relevant critical assets - :scale: 65% - :align: right + :align: center AMPS location info with Mid-Level DFD of relevant critical assets (Click to Enlarge) -As we establish these associations between threats and assets, we’ll begin distilling our theoretical threats. This exercise will clarify how steps in an attack are associated with one another, determining which attacks must be executed and in what order. It will also verify whether certain steps in an attack are still possible once mapped onto specific assets within the system. -In the example below, we’ve created an attack tree and populated it with theoretical threats against our AMPS device. In Question 1, we said collecting and securely storing patient data was essential to our product. We’ve therefore made the goal of our attack tree stealing patient sensor data, specifically user location data. We’ve spoken with our team, trawled academic literature, reviewed blog posts by industry professionals, and watched presentations by security experts to create an initial set of theoretical threats to our device. -Another resource we reviewed was MITRE’s `EMB3D threat knowledge base `_, which worked great to break down the AMPS device by its properties and the specific threats to each. For more help brainstorming insider threat behaviors, take a look at the Center’s `insider threat knowledge base `_. Taken together, all this research gives us an initial list of threats we can then associate with our critical assets. See the AMPS attack tree below for an example of the compiled theoretical threats against our critical assets. +In the example below, we’ve created an attack tree and populated it with theoretical +threats against our AMPS device. In Question 1, we said collecting and securely storing +patient data was essential to our product. We’ve therefore made the goal of our attack +tree stealing patient sensor data, specifically user location data. We’ve spoken with +our team, reviewed academic literature, read blog posts by industry professionals, and +watched presentations by security experts to create an initial set of theoretical +threats to our device. Another resource we reviewed was MITRE’s `EMB3D threat knowledge +base `_, which worked great to break down the +AMPS device by its properties and the specific threats to each. For more help +brainstorming insider threat behaviors, take a look at the Center’s `Insider Threat TTP +Knowledge Base +`_. +Taken together, all this research gives us an initial list of threats we can then +associate with our critical assets. See the AMPS attack tree below for an example of the +compiled theoretical threats against our critical assets. .. figure:: /_static/fulltheorytree.png :alt: Example AMPS attack tree mapped to our critical assets - :scale: 15% :align: center Example AMPS attack tree mapped to our critical assets (Click to Enlarge) Part 3: Translating Attack Tree Concepts into ATT&CK TTPs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Goal:** Use ATT&CK as a common language to describe adversarial behaviors against your system + +**Goal:** Use ATT&CK as a common language to describe adversarial behaviors against your +system .. figure:: /_static/16.png :alt: Example of an ATT&CK Framework @@ -145,25 +240,52 @@ Part 3: Translating Attack Tree Concepts into ATT&CK TTPs Example of an ATT&CK Framework -Now that we’ve built out our attack tree, clarifying our language and invoking specific system data exchanges and assets, we can begin cataloguing the ATT&CK TTPs needed to facilitate those attacks on each critical path and component. These datapoints will constitute the core of our attack tree and link our results from this theoretical exercise to the results of our evidence-based analysis later. +Now that we’ve built out our attack tree, clarifying our language and invoking specific +system data exchanges and assets, we can begin cataloguing the ATT&CK TTPs needed to +facilitate those attacks on each critical path and component. These datapoints will +constitute the core of our attack tree and link our results from this theoretical +exercise to the results of our evidence-based analysis later. -This step is essentially the manual translation of Part 2’s conceptual attack steps into tangible ATT&CK TTPs. We recommend using `Decider `_ to assist in these translations. This tool allows you to either filter for specific tactics, platforms, and data sources that will direct you towards the appropriate TTP, or search key terms related to your attack concept in the search bar to derive the appropriate TTP. When comparing your Part 2 attack tree concepts to existing ATT&CK TTPs, consider adding nodes to your attack tree for any TTPs you may not have thought of. +This step is essentially the manual translation of Part 2’s conceptual attack steps into +tangible ATT&CK TTPs. We recommend using `Decider `_ +to assist in these translations. This tool allows you to either filter for specific +tactics, platforms, and data sources that will direct you towards the appropriate TTP, +or search key terms related to your attack concept in the search bar to derive the +appropriate TTP. When comparing your Part 2 attack tree concepts to existing ATT&CK +TTPs, consider adding nodes to your attack tree for any TTPs you may not have thought +of. -Below is an example of how a theoretical attack can be aligned with a TTP (Browser Session Hijacking T1185). +Below is an example of how a theoretical attack can be aligned with a TTP (Browser +Session Hijacking T1185). .. figure:: /_static/17.png :alt: Browser Session Hijacking Node Closeup :scale: 50% - :align: right + :align: center Browser Session Hijacking Node Closeup -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. 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. +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. 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. +.. TODO can we get a better graphic? + .. figure:: /_static/18.png :alt: Example AMPS Attack Tree Converted into Attack Flow :scale: 75% @@ -171,7 +293,11 @@ 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. +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. + +.. TODO hyperlink to the attack tree in the flow library Evidence --------- @@ -179,31 +305,56 @@ Evidence .. note:: To save time in this section, layers can be omitted. We recommend organizations include at least the tech platform layer. -The previous section focused on a theory-based approach using attack trees. In this section, we will cover the evidence-based approach to complement our theoretical tree and aid in identifying additional TTPs for consideration in the tree. Evidence is derived by attacks observed in the wild and reported on by legitimate sources. The ATT&CK team reads open-source reports published by these sources and associates adversarial behavior with a TTP. Sources for these TTPs are different from those previously used to build the theory-based attack tree, which is why the complementary approach of theory and evidence is crucial. We will use the TTPs derived in this section to add to the attack tree in the previous section. We recommend considering TTPs derived by four types of observed behavior. +The previous section focused on a theory-based approach using attack trees. In this +section, we will cover the evidence-based approach to complement our theoretical tree +and aid in identifying additional TTPs for consideration in the tree. Evidence is +derived by attacks observed in the wild and reported on by legitimate sources. The +ATT&CK team reads open-source reports published by these sources and associates +adversarial behavior with a TTP. Sources for these TTPs are different from those +previously used to build the theory-based attack tree, which is why the complementary +approach of theory and evidence is crucial. We will use the TTPs derived in this section +to add to the attack tree in the previous section. We recommend considering TTPs derived +by four types of observed behavior. #. TTPs used against your Technology Platform(s) #. TTPs used by Threat Actor(s) targeting your Industry #. TTPs used by Software used maliciously against your Industry #. TTPs used by Campaign(s) targeting your Industry -Throughout this section, we break down each type of observed behavior and demonstrate how to use the TTPs describing this behavior in your attack tree. We will continue to use AMPS in all examples. +Throughout this section, we break down each type of observed behavior and demonstrate +how to use the TTPs describing this behavior in your attack tree. We will continue to +use AMPS in all examples. -Multiple technology platforms were identified in our attack tree. For the purposes of this project, however, we will only be using observed TTPs related to the cloud platform (Azure) branch of the attack tree. +Multiple technology platforms were identified in our attack tree. For the purposes of +this project, however, we will only be using observed TTPs related to the cloud platform +(Azure) branch of the attack tree. -As we walk through this section and explain how to generate TTPs from each of the four types of observed behaviors above, we will start to compile a consolidated list of TTPs pertinent to branches of our tree (in this case the Azure branch). These TTPs will be compiled in the form of ATT&CK Navigator Layers. The figure below shows the process of stacking the multiple ATT&CK Navigator Layers derived from each category of data. The information gathered in this section will also support scoring in the following section. +As we walk through this section and explain how to generate TTPs from each of the four +types of observed behaviors above, we will start to compile a consolidated list of TTPs +pertinent to branches of our tree (in this case the Azure branch). These TTPs will be +compiled in the form of ATT&CK Navigator Layers. The figure below shows the process of +stacking the multiple ATT&CK Navigator Layers derived from each category of data. The +information gathered in this section will also support scoring in the following section. .. figure:: /_static/19.png :alt: Layered Steps to Form Collection of TTPS - :scale: 50% - :align: right + :align: center - Layered Steps to Form Collection of TTPS + Layered Steps to Form Collection of TTPS (Click to enlarge) -The observed TTPs in these layers may not have been previously used to achieve the goal we are analyzing in our attack tree (user location data). This is expected. Often, intrusions go through your company to access your business partners or customers. Although your company, or others in your industry, may not have been the desired end target in these reported incidents, you were an intermediate target and the TTPs used in these “leap frog” intrusions against your industry or tech platform can be used to target you in the future. Thus, we include them in our observed TTP layers. +The observed TTPs in these layers may not have been previously used to achieve the goal +we are analyzing in our attack tree (user location data). This is expected. Often, +intrusions go through your company to access your business partners or customers. +Although your company, or others in your industry, may not have been the desired end +target in these reported incidents, you were an intermediate target and the TTPs used in +these “leap frog” intrusions against your industry or tech platform can be used to +target you in the future. Thus, we include them in our observed TTP layers. .. note:: - All ATT&CK Navigator Layer examples can be found within drop downs throughout the Evidence section. Each example will allow for download and opening within ATT&CK Navigator for editing. + All ATT&CK Navigator Layer examples can be found within drop downs throughout the + Evidence section. Each example will allow for download and opening within ATT&CK + Navigator for editing. Layer 1: Technology Platform TTPs @@ -211,11 +362,30 @@ Layer 1: Technology Platform TTPs **Goal:** Compile a list of TTPs that have been used to target your tech platform -To characterize the observed threats targeting your system, we recommend starting with techniques targeting your specific technology platform. This information will be used to prioritize threats in your attack tree later. - -Types of observed CTI data vary by company, depending on which commercial data you subscribe to or which public datasets you leverage. As a best practice, if the data is available, internally generated observed threat data targeting your network and technology platforms should be incorporated. For the purposes of our example, the fictitious team evaluating AMPS doesn’t pay for any CTI data and only has publicly available data at its disposal. A good starting place for any team, regardless of budget, is `ATT&CK Navigator `_. In this tool is an option to filter mobile, enterprise, or industrial control system matrices by technology platform. Our theory-based attack tree is already broken down into technology platform branches, and the focus is on generating observed TTPs one branch at a time. Navigator will generate an ATT&CK matrix with TTPs targeting your technology platform that have been observed in the wild. ATT&CK version 14.1 has the following platform filters: macOS, Windows, Linux, Azure AD, PRE, Containers, Office365, SaaS, Google Workspace, and IaaS. We recommend adding TTPs (or Navigator Layers) derived from your commercial data or data generated internally to this technology platform Navigator layer. This additional data will help capture more observed TTPs used against your technology platform. - -Below is an ATT&CK Navigator view showing the TTPs linked to Azure AD. Throughout this evidence section, we will down-select from these base-layer TTPs. +To characterize the observed threats targeting your system, we recommend starting with +techniques targeting your specific technology platform. This information will be used to +prioritize threats in your attack tree later. + +Types of observed CTI data vary by company, depending on which commercial data you +subscribe to or which public datasets you leverage. As a best practice, if the data is +available, internally generated observed threat data targeting your network and +technology platforms should be incorporated. For the purposes of our example, the +fictitious team evaluating AMPS doesn’t pay for any CTI data and only has publicly +available data at its disposal. A good starting place for any team, regardless of +budget, is `ATT&CK Navigator `_. In +this tool is an option to filter mobile, enterprise, or industrial control system +matrices by technology platform. Our theory-based attack tree is already broken down +into technology platform branches, and the focus is on generating observed TTPs one +branch at a time. Navigator will generate an ATT&CK matrix with TTPs targeting your +technology platform that have been observed in the wild. ATT&CK version 14.1 has the +following platform filters: macOS, Windows, Linux, Azure AD, PRE, Containers, Office365, +SaaS, Google Workspace, and IaaS. We recommend adding TTPs (or Navigator Layers) derived +from your commercial data or data generated internally to this technology platform +Navigator layer. This additional data will help capture more observed TTPs used against +your technology platform. + +Below is an ATT&CK Navigator view showing the TTPs linked to Azure AD. Throughout this +evidence section, we will down-select from these base-layer TTPs. .. collapse:: Example Platform Layer @@ -240,15 +410,36 @@ Below is an ATT&CK Navigator view showing the TTPs linked to Azure AD. Throughou Layer 2: Threat Actor (TA) TTPs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Goal:** Compile a list of TTPs that have been used by a threat actor/s targeting your industry - -If time permits, we also recommend generating threat profiles to characterize the adversaries, or groups, that are likely to target your industry and therefore your system. This information will also help in prioritizing threats in your attack tree later. - -To get started with threat actors that are relevant to your organization, consider any threat actors that have been known to be a concern in the past, or have been mentioned recently as a concern to your organization. It is always a good idea to consider threat actors that have previously been a threat to your organization since they are known to you. Ask your stakeholders if there are any TAs they are concerned with too. - -The ATT&CK Groups knowledge base can be a good starting point for any team. The `Groups `_ page gives an overview of all the TAs reported publicly. Although many CTI vendors have their own naming structure, ATT&CK Groups is an attempt at combining these TAs under a single naming convention. On this page, you can “CTL + F” to look for groups relevant to you. Some focus areas to search for might be location (i.e., United States, Iran, China) or industry (i.e., financial, government, retail); both searches help to narrow down threat actors important to your organization. Also keep an eye out for when these groups were active. Groups that have not been active recently might not be useful to your organization, but this is an internal decision that needs to be made based on your organization’s needs. Be sure to keep these dates in mind as they will affect the scoring in the next section. - -A Navigator layer exists on each Group’s page. Use this layer to generate a list of TTPs for each TA you identified. Below is an ATT&CK Navigator example for FIN7 that highlights the TA’s TTPs in blue. This threat actor was chosen by searching “medical” on the ATT&CK Groups page, which identified this group as previously targeting our industry’s “medical equipment.” +**Goal:** Compile a list of TTPs that have been used by a threat actor/s targeting your +industry + +If time permits, we also recommend generating threat profiles to characterize the +adversaries, or groups, that are likely to target your industry and therefore your +system. This information will also help in prioritizing threats in your attack tree +later. + +To get started with threat actors that are relevant to your organization, consider any +threat actors that have been known to be a concern in the past, or have been mentioned +recently as a concern to your organization. It is always a good idea to consider threat +actors that have previously been a threat to your organization since they are known to +you. Ask your stakeholders if there are any TAs they are concerned with too. + +The ATT&CK Groups knowledge base can be a good starting point for any team. The `Groups +`_ page gives an overview of all the TAs reported +publicly. Although many CTI vendors have their own naming structure, ATT&CK Groups is an +attempt at combining these TAs under a single naming convention. Some focus areas to +search for might be location (i.e., United States, Iran, China) or industry (i.e., +financial, government, retail); both searches help to narrow down threat actors +important to your organization. Also keep an eye out for when these groups were active. +Groups that have not been active recently might not be useful to your organization, but +this is an internal decision that needs to be made based on your organization’s needs. +Be sure to keep these dates in mind as they will affect the scoring in the next section. + +A Navigator layer exists on each Group’s page. Use this layer to generate a list of TTPs +for each TA you identified. Below is an ATT&CK Navigator example for FIN7 that +highlights the TA’s TTPs in blue. This threat actor was chosen by searching “medical” on +the ATT&CK Groups page, which identified this group as previously targeting our +industry’s “medical equipment.” .. collapse:: Example Threat Actor Layer @@ -271,25 +462,60 @@ A Navigator layer exists on each Group’s page. Use this layer to generate a li | -This is our first down-select from the technology platform layer. Additional TAs and the following layers will provide more. If you have more time to spend on this layer, once you’ve finished using the ATT&CK Groups page, you should look at threat actors in the news that are potentially relevant to your industry. If your organization subscribes to commercial data, search those databases or use Threat Intelligence Platforms (TIPs) available to you. An example of this can be found in the Additional Resources Section. Another good starting point for teams on a budget is the `APT Groups and Operations Google Sheet `_. This spreadsheet consists of a list of threat actors by country as well as their name and aliases, operations associated, origin, toolset/malware utilized, a description of their motives/goals, and targeted industries. - -This spreadsheet contains community-derived information. Because it is a living spreadsheet with various people making edits, it allows for a more real-time approach in terms of updates that can be helpful to organizations focusing on a specific threat actor. Ultimately this resource is another opportunity to find more evidence-based TTPs associated with the actor. - -One final open-source resource is the `Thai CERT database `_. This database allows you to search for threat actors by country, sector targeted, motivation, or key word. Once you’ve identified TAs of concern, compare these to the aliases on the ATT&CK Groups page (“CTL + F” search for name) and consider using any resulting group’s Navigator Layer. +This is our first down-select from the technology platform layer. Additional TAs and the +following layers will provide more. If you have more time to spend on this layer, once +you’ve finished using the ATT&CK Groups page, you should look at threat actors in the +news that are potentially relevant to your industry. If your organization subscribes to +commercial data, search those databases or use Threat Intelligence Platforms (TIPs) +available to you. An example of this can be found in the Additional Resources Section. +Another good starting point for teams on a budget is the `APT Groups and Operations +Google Sheet +`_. +This spreadsheet consists of a list of threat actors by country as well as their name +and aliases, operations associated, origin, toolset/malware utilized, a description of +their motives/goals, and targeted industries. + +This spreadsheet contains community-derived information. Because it is a living +spreadsheet with various people making edits, it allows for a more real-time approach in +terms of updates that can be helpful to organizations focusing on a specific threat +actor. Ultimately this resource is another opportunity to find more evidence-based TTPs +associated with the actor. + +One final open-source resource is the `Thai CERT database +`_. This database allows you to search for +threat actors by country, sector targeted, motivation, or key word. Once you’ve +identified TAs of concern, compare these to the aliases on the ATT&CK Groups page and consider using any resulting group’s Navigator Layer. Layer 3: Malicious Software TTPs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Goal:** Compile a list of relevant TTPs executed by malicious tools targeting your technology platform. - -The next step will follow a similar process to the steps above. To start, an organization should always compile internal data first. This can be done by utilizing datasets within any TIPs you use as well as any previous threats your company has seen. Starting with the known and building on the new data allows for a more exhaustive list of TTPs while ensuring company-specific data is considered. - -After reviewing internal and commercial data, use the ATT&CK Software page similarly to how we used it for the TA layer. In this scenario you will use it to build a list of TTPs used by malicious software targeting your specific technology platform. This will be done by accessing the ATT&CK Software page and using “CTL + F” to search for your technology platform. -In our case, we search “Azure,” which results in two findings of software: AADInternals and ROADTools. For the sake of this example, the team will focus on ROADTools. We recommend including all software pertaining to your platform, or just specific software you find most applicable; you will have to make this decision based on your needs and time. During this step, remember that ATT&CK software is not just compromised or malicious software, but also commercial, open-source, built-in, or publicly available software that could be used by a defender, pen tester, red teamer, or adversary conducting “living off the land” techniques. Each Software page comes with a Navigator Layer. The ROADTools ATT&CK Navigator layer can be seen below in red. +**Goal:** Compile a list of relevant TTPs executed by malicious tools targeting your +technology platform. + +The next step will follow a similar process to the steps above. To start, an +organization should always compile internal data first. This can be done by utilizing +datasets within any TIPs you use as well as any previous threats your company has seen. +Starting with the known and building on the new data allows for a more exhaustive list +of TTPs while ensuring company-specific data is considered. + +After reviewing internal and commercial data, use the ATT&CK Software page similarly to +how we used it for the TA layer. In this scenario you will use it to build a list of +TTPs used by malicious software targeting your specific technology platform. + +In our case, we search “Azure,” which results in two findings of software: AADInternals +and ROADTools. For the sake of this example, the team will focus on ROADTools. We +recommend including all software pertaining to your platform, or just specific software +you find most applicable; you will have to make this decision based on your needs and +time. During this step, remember that ATT&CK software is not just compromised or +malicious software, but also commercial, open-source, built-in, or publicly available +software that could be used by a defender, pen tester, red teamer, or adversary +conducting “living off the land” techniques. Each Software page comes with a Navigator +Layer. The ROADTools ATT&CK Navigator layer can be seen below in red. .. collapse:: Example Software Layer - **This ATT&CK Navigator view shows the TTPs linked to the ROADTools software. These TTPs will be added onto the layer with platform and threat actor TTPs.** + **This ATT&CK Navigator view shows the TTPs linked to the ROADTools software. These + TTPs will be added onto the layer with platform and threat actor TTPs.** .. figure:: /_static/21.svg :alt: Example ATT&CK Navigator Layer for ROADTools @@ -311,11 +537,26 @@ In our case, we search “Azure,” which results in two findings of software: A Layer 4: Campaign TTPs ~~~~~~~~~~~~~~~~~~~~~~ -**Goal:** Compile a list of TTPs that have been used in a campaign targeting your industry. - -To provide a more detailed picture, if your organization has the time, it is recommended you research campaigns that might be applicable to you. This can be done in various ways similar to the previous layers. First, any campaigns recently reported on that are of concern to your organization should be included. It might also make sense to include any data from previous campaigns that targeted your organization as well as data from tools used internally. Once this data has been considered and added, the team should use the `ATT&CK Campaigns `_ page for further research. Focus on campaigns targeting your specific industry. These can be searched by using “CTL + F” on the ATT&CK campaign page. During this step, be cognizant of the timing of these campaigns, since some may be too old to be useful. Only your organization can know which campaigns they find useful, but keep these dates in mind as they will affect the scoring in the next section. - -For the AMPS device, we focused on one of the campaigns related to healthcare, specifically C0014. In many cases, this campaign might be considered not recent enough to be relevant, but for the sake of this example we will use it, despite the reported date being in 2022. The ATT&CK Navigator Layer below highlights the TTPs relevant to this campaign in yellow. +**Goal:** Compile a list of TTPs that have been used in a campaign targeting your +industry. + +To provide a more detailed picture, if your organization has the time, it is recommended +you research campaigns that might be applicable to you. This can be done in various ways +similar to the previous layers. First, any campaigns recently reported on that are of +concern to your organization should be included. It might also make sense to include any +data from previous campaigns that targeted your organization as well as data from tools +used internally. Once this data has been considered and added, the team should use the +`ATT&CK Campaigns `_ page for further research. +Focus on campaigns targeting your specific industry. During this step, be cognizant of +the timing of these campaigns, since some may be too old to be useful. Only your +organization can know which campaigns they find useful, but keep these dates in mind as +they will affect the scoring in the next section. + +For the AMPS device, we focused on one of the campaigns related to healthcare, +specifically C0014. In many cases, this campaign might be considered not recent enough +to be relevant, but for the sake of this example we will use it, despite the reported +date being in 2022. The ATT&CK Navigator Layer below highlights the TTPs relevant to +this campaign in yellow. .. collapse:: Example Campaign Layer @@ -338,8 +579,10 @@ For the AMPS device, we focused on one of the campaigns related to healthcare, s | +The video below walks through an example of adding together all of the layers mentioned +throughout the evidence section. -The video below walks through an example of adding together all of the layers mentioned throughout the evidence section. +.. TODO video 1 goes here .. raw:: html @@ -352,11 +595,18 @@ Compile All CTI Layers and Compare to Theory-Base Attack Tree **Goal:** Compile list of TTPs that your system will most likely face -Right now you have a list of TTPs, in the form of ATT&CK Navigator Layers, that have been observed against technology platforms in your tree. Take those lists and overlap them all using Navigator. The overlap between layers can provide some insight for prioritization. +Right now you have a list of TTPs, in the form of ATT&CK Navigator Layers, that have +been observed against technology platforms in your tree. Take those lists and overlap +them all using Navigator. The overlap between layers can provide some insight for +prioritization. .. collapse:: Example Evidence Combined Layer - **The example below shows a combination of all layers used as examples above. The blue TTPs show those used by threat actors targeting your industry, the red TTPs signify the TTPs used by malicious software targeting your industry, the yellow highlights the TTPs used by campaigns targeting your industry, and grey shows any overlap between multiple layers.** + **The example below shows a combination of all layers used as examples above. The + blue TTPs show those used by threat actors targeting your industry, the red TTPs + signify the TTPs used by malicious software targeting your industry, the yellow + highlights the TTPs used by campaigns targeting your industry, and grey shows any + overlap between multiple layers.** .. figure:: /_static/23.svg :alt: Example ATT&CK Navigator Layer for Combined Layers @@ -375,11 +625,15 @@ Right now you have a list of TTPs, in the form of ATT&CK Navigator Layers, that | -Compare these TTPs to those in your theory-based attack tree. Since these TTPs are all related to the Azure branch of the attack tree, we will focus there. In practice, you will make one combined overlay for each technology platform branch of your tree. +Compare these TTPs to those in your theory-based attack tree. Since these TTPs are all +related to the Azure branch of the attack tree, we will focus there. In practice, you +will make one combined overlay for each technology platform branch of your tree. .. collapse:: Example Theory Layer - **To apply this to our current example, we will take our attack tree branch centered around Azure and map the steps back to ATT&CK techniques, as seen in the Navigator Layer below.** + **To apply this to our current example, we will take our attack tree branch centered + around Azure and map the steps back to ATT&CK techniques, as seen in the Navigator + Layer below.** .. figure:: /_static/theory.svg :alt: Example ATT&CK Navigator Layer for Azure Theory Branch @@ -400,23 +654,26 @@ Compare these TTPs to those in your theory-based attack tree. Since these TTPs a The video below walks through an example of combining the theory and evidence layers. +.. TODO video 2 goes here + .. raw:: html - | .. collapse:: Example Theory Evidence Overlay Layer - **This Navigator Layer is now placed on top of our overall evidence layer (above); the TTPs that are supported by theory and evidence are highlighted in orange.** + **This Navigator Layer is now placed on top of our overall evidence layer (above); + the TTPs that are supported by theory and evidence are highlighted in orange.** .. figure:: /_static/theory_evidence.svg :alt: Example ATT&CK Navigator Layer for Azure Theory Branch Overlayed with Evidence Layers :scale: 75% :align: center - Example ATT&CK Navigator Layer for Azure Theory Branch Overlayed with Evidence Layers + Example ATT&CK Navigator Layer for Azure Theory Branch Overlayed with Evidence + Layers .. raw:: html @@ -427,16 +684,24 @@ The video below walks through an example of combining the theory and evidence la | -Your next step is to evaluate the techniques that are not overlapping to see if they have a place in the Azure branch of the attack tree. Once you’ve added any new and relevant evidence-based TTPs to your branch, the resulting list of evidence and theory attack tree TTPs will be used in the next section. +Your next step is to evaluate the techniques that are not overlapping to see if they +have a place in the Azure branch of the attack tree. Once you’ve added any new and +relevant evidence-based TTPs to your branch, the resulting list of evidence and theory +attack tree TTPs will be used in the next section. Scoring the Catalogue of Threats to Your System ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: - Scoring is not a mandatory step, however it can provide great context for priorization. + Scoring is not a mandatory step, however it can provide great context for + priorization. -This step lets us calculate the level of threat associated with specific attack vectors and TTPs. The end goal of this step is to prioritize which threats to mitigate in Question 3. Note, if you are limited on time you can skip this step and proceed directly to Question 3 with your long list of TTPs. However, conducting this scoring step might save you more time in Question 3 by enabling you to focus only on high-threat TTPs. +This step lets us calculate the level of threat associated with specific attack vectors +and TTPs. The end goal of this step is to prioritize which threats to mitigate in +Question 3. Note, if you are limited on time you can skip this step and proceed directly +to Question 3 with your long list of TTPs. However, conducting this scoring step might +save you more time in Question 3 by enabling you to focus only on high-threat TTPs. .. figure:: /_static/scoringgraphic.png :alt: Theory and Evidence Scoring Scale @@ -445,9 +710,16 @@ This step lets us calculate the level of threat associated with specific attack Theory and Evidence Scoring Scale -Revisiting the ideas presented in the introduction to Question 2, we can organize identified TTPs into different priority categories depending on the strength of their individual theory and evidence factors. These categories are not meant to be a strict numerical ranking – rather, they should be used as an aid to help prioritize your time and effort while evaluating mitigations and countermeasures. +Revisiting the ideas presented in the introduction to Question 2, we can organize +identified TTPs into different priority categories depending on the strength of their +individual theory and evidence factors. These categories are not meant to be a strict +numerical ranking – rather, they should be used as an aid to help prioritize your time +and effort while evaluating mitigations and countermeasures. -Given a particular TTP identified by your overlay of theory and evidence, consider some of the following factors to help guide your prioritization of TTP data. Note that this list is non-exhaustive, and you may wish to incorporate other factors specific to your use case. +Given a particular TTP identified by your overlay of theory and evidence, consider some +of the following factors to help guide your prioritization of TTP data. Note that this +list is non-exhaustive, and you may wish to incorporate other factors specific to your +use case. .. list-table:: :widths: 50 50 @@ -477,7 +749,12 @@ Given a particular TTP identified by your overlay of theory and evidence, consid * - TTP is associated with a critical system choke point identified in threat analysis - -The more factors that apply for either theory or evidence, the further you move in the table right or down, respectively. The simplest form of this analysis assigns an equal value to all factors (i.e., a weight of 1). However, you may find that some factors should be treated with more importance to suit your prioritization needs. For example, you may give TTPs associated with external system boundaries (i.e., external network connections) extra weight to prioritize developing mitigations for system entry points. +The more factors that apply for either theory or evidence, the further you move in the +table right or down, respectively. The simplest form of this analysis assigns an equal +value to all factors (i.e., a weight of 1). However, you may find that some factors +should be treated with more importance to suit your prioritization needs. For example, +you may give TTPs associated with external system boundaries (i.e., external network +connections) extra weight to prioritize developing mitigations for system entry points. .. figure:: /_static/scoringplot.png :alt: Example TTPs Plotted on Scoring Scale @@ -486,34 +763,65 @@ The more factors that apply for either theory or evidence, the further you move Example TTPs Plotted on Scoring Scale -The result will manifest like the diagram shown above. TTPs are assigned a theory-evidence score, which places them at a point in the table. Thresholds can be individually adjusted for both theory and evidence to determine how large or small to make the sectors in the table. For example, in industries that utilize newer or more specialized technology, there may be less available evidence to consider in your threat overlay. Consequently, you may choose to weigh individual pieces of evidence higher for other industries. +The result will manifest like the diagram shown above. TTPs are assigned a +theory-evidence score, which places them at a point in the table. Thresholds can be +individually adjusted for both theory and evidence to determine how large or small to +make the sectors in the table. For example, in industries that utilize newer or more +specialized technology, there may be less available evidence to consider in your threat +overlay. Consequently, you may choose to weigh individual pieces of evidence higher for +other industries. Example scoring ^^^^^^^^^^^^^^^ -Consider TTP: **T1011.001** – Exfiltration Over Other Network Medium: Exfiltration Over Bluetooth - -Assume the adversarial goal in this case is to steal sensitive patient data. One avenue would be to go directly to the source – the AMPS device itself. -T1011.001 describes activity where *“Adversaries may attempt to exfiltrate data over Bluetooth rather than the command-and-control channel. If the command-and-control network is a wired Internet connection, an adversary may opt to exfiltrate data using a Bluetooth communication channel.”* The AMPS device has been designed with Bluetooth in mind, as it needs to pair with a phone. -Several Bluetooth vulnerabilities have been documented in the literature, but we will choose to focus on one named `SweynTooth `_. SweynTooth is a collection of vulnerabilities in certain Bluetooth Low Energy (BLE) chipsets, with a range of impacts ranging from crashes to security bypass. Perusing the website dedicated to this vulnerability, we can come to the following conclusions on the strength of theory factors: +Consider TTP: **T1011.001** – Exfiltration Over Other Network Medium: Exfiltration Over +Bluetooth + +Assume the adversarial goal in this case is to steal sensitive patient data. One avenue +would be to go directly to the source – the AMPS device itself. T1011.001 describes +activity where *“Adversaries may attempt to exfiltrate data over Bluetooth rather than +the command-and-control channel. If the command-and-control network is a wired Internet +connection, an adversary may opt to exfiltrate data using a Bluetooth communication +channel.”* The AMPS device has been designed with Bluetooth in mind, as it needs to pair +with a phone. Several Bluetooth vulnerabilities have been documented in the literature, +but we will choose to focus on one named `SweynTooth +`_. SweynTooth is a collection of +vulnerabilities in certain Bluetooth Low Energy (BLE) chipsets, with a range of impacts +ranging from crashes to security bypass. Perusing the website dedicated to this +vulnerability, we can come to the following conclusions on the strength of theory +factors: * The TTP has been hypothesized in the writeup (beyond hypothesized, in fact) -* The TTP has been demonstrated (there is proof of concept code against multiple devices) +* The TTP has been demonstrated (there is proof of concept code against multiple + devices) * The TTP has known tools for execution (there is proof of concept code) * SweynTooth is a Bluetooth vulnerability and therefore applies to this TTP -* Patient data is a critical cyber asset for this device (which the TTP directly affects) -* The Bluetooth connection between the AMPS device and the patient phone is a link that crosses a trust boundary on the DFD (and is therefore a critical link) -* This TTP is present in attack tree branches that directly access the device, but there are other ways to get patient data (e.g. compromising their online account). Ergo, this may or may not be considered a choke point from a threat analysis standpoint. - -On the theory side, the above culminates in **6/7 factors** applying here, indicating **strong supporting theory** for this TTP. -With respect to evidence, we see a much different story manifesting: - -* Threat groups operating against the healthcare industry have generally not been targeting Bluetooth (caveat - at the time of writing) +* Patient data is a critical cyber asset for this device (which the TTP directly + affects) +* The Bluetooth connection between the AMPS device and the patient phone is a link + that crosses a trust boundary on the DFD (and is therefore a critical link) +* This TTP is present in attack tree branches that directly access the device, but + there are other ways to get patient data (e.g. compromising their online account). + Ergo, this may or may not be considered a choke point from a threat analysis + standpoint. + +On the theory side, the above culminates in **6/7 factors** applying here, indicating +**strong supporting theory** for this TTP. With respect to evidence, we see a much +different story manifesting: + +* Threat groups operating against the healthcare industry have generally not been + targeting Bluetooth (caveat - at the time of writing) * There **are** several reports of Bluetooth exploits being leveraged in the wild -* Similar to the first point, there are very few **campaigns** leveraging Bluetooth in the wild, and by extension, very few campaigns targeting this industry and tech platform -* While Bluetooth is generally regarded as insecure, there have not been any major vulnerability disclosures over the past 30 days (at the time of this writing) +* Similar to the first point, there are very few **campaigns** leveraging Bluetooth in + the wild, and by extension, very few campaigns targeting this industry and tech + platform +* While Bluetooth is generally regarded as insecure, there have not been any major + vulnerability disclosures over the past 30 days (at the time of this writing) -On the evidence side, the above culminates in **1/5 factors** applying here, indicating **little or weak supporting evidence**. Together, the theory and evidence place this TTP toward the upper-right on the figure, which gives this TTP a medium priority under normal weighting. +On the evidence side, the above culminates in **1/5 factors** applying here, indicating +**little or weak supporting evidence**. Together, the theory and evidence place this TTP +toward the upper-right on the figure, which gives this TTP a medium priority under +normal weighting. .. figure:: /_static/scoringpriority.png :alt: Example TTPs on Scoring Scale Prioritized @@ -522,14 +830,24 @@ On the evidence side, the above culminates in **1/5 factors** applying here, ind Example TTPs on Scoring Scale Prioritized -To reiterate, this step is not meant to produce a definitive first-to-last ranking of TTPs – rather, it serves to quickly prioritize where to focus your efforts when considering countermeasures and mitigations in Question 3. Therefore, once you are done sorting TTPs, sort the boxes, rather than the individual TTPs themselves, for priority. Returning to the example figure, this would result in the following prioritization scheme. +To reiterate, this step is not meant to produce a definitive first-to-last ranking of +TTPs – rather, it serves to quickly prioritize where to focus your efforts when +considering countermeasures and mitigations in Question 3. Therefore, once you are done +sorting TTPs, sort the boxes, rather than the individual TTPs themselves, for priority. +Returning to the example figure, this would result in the following prioritization +scheme. -Depending on your priorities, you may choose to sort the categories of TTPs differently if your concerns align more with theory or with evidence; i.e., you may choose to prioritize the center box higher than the top right box if you are more worried about strength of evidence than strength of theory. +Depending on your priorities, you may choose to sort the categories of TTPs differently +if your concerns align more with theory or with evidence; i.e., you may choose to +prioritize the center box higher than the top right box if you are more worried about +strength of evidence than strength of theory. Example Scoring TTPs within AMPS’s Azure Attack Tree Branch ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following table summarizes the TTPs identified during the Theory and Evidence activities presented earlier in this section. We’ve sorted the table into three columns – Theory, Evidence, and both, to track which activity each TTP was derived from. +The following table summarizes the TTPs identified during the Theory and Evidence +activities presented earlier in this section. We’ve sorted the table into three columns +– Theory, Evidence, and both, to track which activity each TTP was derived from. .. figure:: /_static/theoryevidencettps.png :alt: Evidence and Theory TTPs Table @@ -538,12 +856,15 @@ The following table summarizes the TTPs identified during the Theory and Evidenc Evidence and Theory TTPs Table -To keep the rest of this example concise, we have elected to only score the TTPs listed under the “Theory and Evidence” column. However, scoring can (and should) be applied to all identified TTPs. +To keep the rest of this example concise, we have elected to only score the TTPs listed +under the “Theory and Evidence” column. However, scoring can (and should) be applied to +all identified TTPs. *Theory factor scoring* #. TTP has been hypothesized in research paper(s) -#. TTP has been technically demonstrated in a published setting (lab, presentation, etc.) +#. TTP has been technically demonstrated in a published setting (lab, presentation, + etc.) #. TTP has known, publicly available tools for execution #. TTP has associated vulnerabilities (CVEs) applicable to your tech platform(s) #. TTP is associated with accessing a critical cyber asset in your system @@ -560,20 +881,33 @@ To keep the rest of this example concise, we have elected to only score the TTPs Some notes on the above: -* Datapoints for Factor 1 encompass TTPs that are theoretically possible but have yet to be demonstrated. Threats were primarily identified from academic publications and industry publications. -* Sources for Factor 2 often pull from academic and industry publications, but these exploits have been corroborated by testing. Presentations by security professionals at conferences and online are another valid source for this information. -* Satisfying Factor 3 entails tracking down sources that link the identified TTP with existing tools. For this example, Azure red teaming reports were a key source in identifying known tools associated with specific TTPs. -* Entries for Factor 4 were determined by searching through existing CVE repositories for CVEs specifically tied to Azure and Microsoft products. -* Entries for Factor 5 were identified by reviewing our attack tree and determining whether a TTP directly targeted critical assets. -* Entries for Factor 6 were identified by examining our original DFD. Chokepoints or interests that represent key information bottlenecks within the system were identified. -* Entries for Factor 7 were identified in much the same way as Factor 6, but in this case choke points were identified within the system attack tree as lynchpins within a larger adversary campaign. +* Datapoints for Factor 1 encompass TTPs that are theoretically possible but have yet to + be demonstrated. Threats were primarily identified from academic publications and + industry publications. +* Sources for Factor 2 often pull from academic and industry publications, but these + exploits have been corroborated by testing. Presentations by security professionals at + conferences and online are another valid source for this information. +* Satisfying Factor 3 entails tracking down sources that link the identified TTP with + existing tools. For this example, Azure red teaming reports were a key source in + identifying known tools associated with specific TTPs. +* Entries for Factor 4 were determined by searching through existing CVE repositories + for CVEs specifically tied to Azure and Microsoft products. +* Entries for Factor 5 were identified by reviewing our attack tree and determining + whether a TTP directly targeted critical assets. +* Entries for Factor 6 were identified by examining our original DFD. Chokepoints or + interests that represent key information bottlenecks within the system were + identified. +* Entries for Factor 7 were identified in much the same way as Factor 6, but in this + case choke points were identified within the system attack tree as lynchpins within a + larger adversary campaign. *Evidence factor scoring* #. TTP has been used by a threat group targeting your industry #. TTP has public reports of execution using publicly available (malicious) tools #. TTP has been used in a campaign targeting your industry within the last 90 days -#. TTP has been used in a campaign targeting a tech platform you use within the last 90 days +#. TTP has been used in a campaign targeting a tech platform you use within the last 90 + days #. TTP is associated with a vulnerability/CVE disclosed within the past 30 days #. TTP has documentation of previous use against your tech platform. @@ -587,14 +921,32 @@ Some notes on the above: Some notes on the above: -* Entries for Factor 1 were determined by searching the Groups page on the ATT&CK website. Relevant groups were identified by searching for the keyword “healthcare,” where their TTP lists were cross-referenced with entries in the table. -* Entries for Factor 2 were determined by searching the relevant TTP entries in ATT&CK for related software artifacts applicable to Azure. -* Entries for Factors 3 and 4 were determined by searching campaigns on the ATT&CK website targeting Azure. At the time of writing, there are no known campaigns occurring within the last 90 days against Azure. While there have been campaigns targeting healthcare in the past, they have largely focused on denial of service and ransomware outcomes, which fall outside of the scope of the TTPs we are evaluating. -* Entries for Factor 5 were determined by a keyword search for “Azure” on the CVE website. While there are multiple Azure CVEs at the time of writing, none are related to the TTPs. -* Entries for Factor 6 were taken directly from the ATT&CK Navigator Overlay presented in Evidence Layer 1 detailing TTPs relevant to the Azure platform. - -It is important to note that Factors 3, 4, and 5 are all considered with restricted time windows, as allowing all instances of a TTP may lead to over-scoring based on “stale” information; i.e., a campaign that occurred two years prior, while informational, does not carry the same urgency as a campaign actively happening within the last month. -After scoring, the TTPs can be placed on a heatmap overlay, then sorted by grouping from highest to lowest priority. The following figure illustrates the outcome of this process. Points on the heatmap with multiple listings represent TTPs that achieved the same score. Note that in this example, T1556 and T1059.001 could have their positions exchanged, depending on whether your priorities align closer to Theory or Evidence factors. +* Entries for Factor 1 were determined by searching the Groups page on the ATT&CK + website. Relevant groups were identified by searching for the keyword “healthcare,” + where their TTP lists were cross-referenced with entries in the table. +* Entries for Factor 2 were determined by searching the relevant TTP entries in ATT&CK + for related software artifacts applicable to Azure. +* Entries for Factors 3 and 4 were determined by searching campaigns on the ATT&CK + website targeting Azure. At the time of writing, there are no known campaigns + occurring within the last 90 days against Azure. While there have been campaigns + targeting healthcare in the past, they have largely focused on denial of service and + ransomware outcomes, which fall outside of the scope of the TTPs we are evaluating. +* Entries for Factor 5 were determined by a keyword search for “Azure” on the CVE + website. While there are multiple Azure CVEs at the time of writing, none are related + to the TTPs. +* Entries for Factor 6 were taken directly from the ATT&CK Navigator Overlay presented + in Evidence Layer 1 detailing TTPs relevant to the Azure platform. + +It is important to note that Factors 3, 4, and 5 are all considered with restricted time +windows, as allowing all instances of a TTP may lead to over-scoring based on “stale” +information; i.e., a campaign that occurred two years prior, while informational, does +not carry the same urgency as a campaign actively happening within the last month. After +scoring, the TTPs can be placed on a heatmap overlay, then sorted by grouping from +highest to lowest priority. The following figure illustrates the outcome of this +process. Points on the heatmap with multiple listings represent TTPs that achieved the +same score. Note that in this example, T1556 and T1059.001 could have their positions +exchanged, depending on whether your priorities align closer to Theory or Evidence +factors. .. figure:: /_static/scoringplotpriority.png :alt: Example TTPs on Scoring Scale Prioritized by Score @@ -603,5 +955,7 @@ After scoring, the TTPs can be placed on a heatmap overlay, then sorted by group Example TTPs on Scoring Scale Prioritized by Score -As a reminder, this example only scored TTPs that appeared during both Theory and Evidence investigations. When creating a full threat model, it is important to consider all TTPs for completeness. +As a reminder, this example only scored TTPs that appeared during both Theory and +Evidence investigations. When creating a full threat model, it is important to consider +all TTPs for completeness. diff --git a/docs/question-3.rst b/docs/question-3.rst index 86cd186..ee34004 100644 --- a/docs/question-3.rst +++ b/docs/question-3.rst @@ -10,29 +10,64 @@ Question 3: What are we going to do about it? Question 3 Overview (Click to Enlarge) -Now that we have a prioritized list of TTPs our adversaries will likely use against our specific tech platform(s), we need to identify how our tech platform(s)’s existing security measures mitigate them. This section will provide a guide for using the Center’s Mappings Explorer website to identify which existing security capabilities within your environment are mapped to the threats you're concerned about. If the Explorer’s existing mappings don’t fit your needs, this section will also introduce a process for mapping security controls and capabilities, native to a technology platform or mapping framework, to ATT&CK TTPs. These resources can be used to understand, assess, and record the real-world threats that security controls, within your technology platform, are able to mitigate. Using these Mappings, we can prioritize defensive investments against high priority TTPs targeting our technology platforms. Continuing with the AMPS example in Question 2, we will see which of the TTPs identified within our Azure attack tree branch are mitigated by leveraging the Azure mapping within Mappings Explorer. +Now that we have a prioritized list of TTPs that our adversaries will likely use against +our specific tech platform(s), we need to identify how our tech platform(s)’s existing +security measures mitigate them. This section will provide a guide for using the +Center’s Mappings Explorer website to identify which existing security capabilities +within your environment are mapped to the threats you're concerned about. If the +Explorer’s existing mappings don’t fit your needs, this section will also introduce a +process for mapping security controls and capabilities, native to a technology platform +or mapping framework, to ATT&CK TTPs. These resources can be used to understand, assess, +and record the real-world threats that security controls, within your technology +platform, are able to mitigate. Using these Mappings, we can prioritize defensive +investments against high priority TTPs targeting our technology platforms. Continuing +with the AMPS example in Question 2, we will see which of the TTPs identified within our +Azure attack tree branch are mitigated by leveraging the Azure mapping within Mappings +Explorer. Mappings Explorer Overview ~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Center provides a collection of mappings connecting security capabilities to the MITRE ATT&CK® framework through `Mappings Explorer `_. This website hosts a collection of open, independently developed mappings products, tools, and resources. These mappings form a bridge between the threat-informed approach to cybersecurity (Question 2) and the traditional security controls perspective. -Mappings Explorer enables cyber defenders to understand how security controls and capabilities map onto adversary behaviors catalogued in the ATT&CK knowledge base. The website presents security control mappings and threat and mitigation data in user-friendly ways. This enables the exploration of adversary techniques and the corresponding mapped capabilities across platforms and frameworks. -The mappings provided in Mappings Explorer are designed to provide independent data on which native security capabilities are most useful in defending against specific adversary TTPs. You will need to decide what types of capability functions are applicable for implementation in your environment and meet your threat mitigation needs. -The security capabilities of the following frameworks mapped to ATT&CK are freely and openly available: +The Center provides a collection of mappings connecting security capabilities to the +MITRE ATT&CK® framework through `Mappings Explorer +`_. This +website hosts a collection of open, independently developed mappings products, tools, +and resources. These mappings form a bridge between the threat-informed approach to +cybersecurity (Question 2) and the traditional security controls perspective. Mappings +Explorer enables cyber defenders to understand how security controls and capabilities +map onto adversary behaviors catalogued in the ATT&CK knowledge base. The website +presents security control mappings and threat and mitigation data in user-friendly ways. +This enables the exploration of adversary techniques and the corresponding mapped +capabilities across platforms and frameworks. The mappings provided in Mappings Explorer +are designed to provide independent data on which native security capabilities are most +useful in defending against specific adversary TTPs. You will need to decide what types +of capability functions are applicable for implementation in your environment and meet +your threat mitigation needs. The security capabilities of the following frameworks +mapped to ATT&CK are freely and openly available: .. figure:: /_static/mappingsexplorer.png - :alt: Question 3 Overview Graphic + :alt: Screenshot of Mappings Explorer :scale: 70% :align: center - Question 3 Overview + Screenshot of Mappings Explorer -You can use Mappings Explorer for many different purposes. In this document, we will focus on using the mappings to align cyber defenses to threats by identifying security capabilities mapped to detect, defend against, or respond to specific technology platform-based branches of our attack trees. Later in this section, we will use these resources to visualize and assess defensive coverage to identify deficiencies and plan policy and security capability implementation around adversary TTPs from Question 2. +You can use Mappings Explorer for many different purposes. In this document, we will +focus on using the mappings to align cyber defenses to threats by identifying security +capabilities mapped to detect, defend against, or respond to specific technology +platform-based branches of our attack trees. Later in this section, we will use these +resources to visualize and assess defensive coverage to identify deficiencies and plan +policy and security capability implementation around adversary TTPs from Question 2. Creating Security Capability Mappings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Center uses a standard methodology to map security controls native to a technology platform to ATT&CK. As discussed previously, many of these mappings have already been done for you and are readily accessible in mappings explorer referenced in the previous section. In the event you have a technology platform that has not been mapped, the below steps are a reusable method of using ATT&CK to determine the capabilities of a platform's security offerings. +The Center uses a standard methodology to map security controls native to a technology +platform to ATT&CK. As discussed previously, many of these mappings have already been +done for you and are readily accessible in mappings explorer referenced in the previous +section. In the event you have a technology platform that has not been mapped, the below +steps are a reusable method of using ATT&CK to determine the capabilities of a +platform's security offerings. .. admonition:: The methodology consists of the following basic steps: @@ -50,38 +85,76 @@ The Center uses a standard methodology to map security controls native to a tech #. Assess and Score Control Effectiveness - * Assess the effectiveness of the type of protection the control provides (protect, detect, or response) for the identified ATT&CK techniques and sub-techniques. + * Assess the effectiveness of the type of protection the control provides + (protect, detect, or response) for the identified ATT&CK techniques and + sub-techniques. #. Create a Mapping * Create a mapping based on the information gathered from the previous steps. -The full mapping methodology and scoring rubric are available on the `Mappings Explorer website `_. +The full mapping methodology and scoring rubric are available on the `Mappings Explorer +website +`_. Creating Custom Mappings ~~~~~~~~~~~~~~~~~~~~~~~~ -For most users, you should start with Mappings Explorer to find mappings data relevant to your environment, available for downloading the data in spreadsheet or machine-readable formats. If you have a need to produce your own customized mappings data, then you can apply the mapping methodology to the platform capabilities you have. -If you are not using one of the mapping frameworks in the Mappings Explorer collection and instead plan on creating a custom mapping for your technology platform, we recommend using the Center’s Mappings Editor tool and following the documentation to create new mappings. +For most users, you should start with Mappings Explorer to find mappings data relevant +to your environment, available for downloading the data in spreadsheet or +machine-readable formats. If you have a need to produce your own customized mappings +data, then you can apply the mapping methodology to the platform capabilities you have. +If you are not using one of the mapping frameworks in the Mappings Explorer collection +and instead plan on creating a custom mapping for your technology platform, we recommend +using the Center’s Mappings Editor tool and following the documentation to create new +mappings. Mappings Editor ~~~~~~~~~~~~~~~ -Mappings Editor is an interactive, web-based tool created by the Center for creating and updating mappings of security capabilities to ATT&CK. At the time of publication, this tool is available as a public beta. -Mappings Editor makes it quick and easy to create, edit, and review mappings and includes several features specially engineered to enhance the mapping process. The Editor is designed to streamline the creation of mapping files, which consist of one or more mappings that associate a security control, vulnerability, or capability to an adversary behavior catalogued by ATT&CK. Using the Mappings Editor, the mapping files can be exported as ATT&CK Navigator Layers or as .CSV, .JSON, .YAML, or Microsoft Excel (.XLSX) Files. To get started, review the Editor Documentation to learn how to create the initial mappings file, and then use the link provided to launch the Mappings Editor web application. +Mappings Editor is an interactive, web-based tool created by the Center for creating +and updating mappings of security capabilities to ATT&CK. At the time of publication, +this tool is available as a public beta. Mappings Editor makes it quick and easy to +create, edit, and review mappings and includes several features specially engineered to +enhance the mapping process. The Editor is designed to streamline the creation of +mapping files, which consist of one or more mappings that associate a security control, +vulnerability, or capability to an adversary behavior catalogued by ATT&CK. Using the +Mappings Editor, the mapping files can be exported as ATT&CK Navigator Layers or as +.CSV, .JSON, .YAML, or Microsoft Excel (.XLSX) Files. To learn more, visit the `Mappings +Editor wiki +`_. Mitigating Threats to AMPS ~~~~~~~~~~~~~~~~~~~~~~~~~~ -Continuing with the AMPS device scenario, we will be looking at the security capabilities native to the Azure cloud platform. Using Mappings Explorer, we can easily identify 48 Azure security capabilities mapped to ATT&CK techniques and sub-techniques, with a total of 978 mappings. Analyst attention can be focused on considering the applicability of these mapped security capabilities as mitigation options for the specific threats identified in Question 2. -Azure security capability mappings fall under Security Stack Mappings, which include scoring assessments for each control’s ability to protect against, detect, and respond to TTPs. These assessments are provided to reflect the security capability’s functions and ability to mitigate the mapped threats. Azure mappings are provided for the following capability function areas: +Continuing with the AMPS device scenario, we will be looking at the security +capabilities native to the Azure cloud platform. Using Mappings Explorer, we can easily +identify 48 Azure security capabilities mapped to ATT&CK techniques and sub-techniques, +with a total of 978 mappings. Analyst attention can be focused on considering the +applicability of these mapped security capabilities as mitigation options for the +specific threats identified in Question 2. Azure security capability mappings fall under +Security Stack Mappings, which include scoring assessments for each control’s ability to +protect against, detect, and respond to TTPs. These assessments are provided to reflect +the security capability’s functions and ability to mitigate the mapped threats. Azure +mappings are provided for the following capability function areas: * **Protect:** capability limits or contains the impact of a (sub-)technique. * **Detect:** capability identifies the potential occurrence of a (sub-)technique. * **Respond:** capability provides actions to take for detected (sub-)technique. -Typically, it is recommended that capability mappings scored as Partial or Significant effectiveness at mitigating the behavior described by a (sub-) technique, be considered for implementation. If you are inclined to include a capability scored as Minimal effectiveness, carefully consider whether this control would actually be a practical means of mitigating the threat. Often, minimally scored controls could technically mitigate the behavior but in the real world would not be used for that purpose. In that case, the recommendation would be to exclude it. -Using Mappings Explorer data and looking at each of the specific TTPs identified in Q2, we identify the Azure security capabilities mappings as listed in the table below. Native Azure capabilities scored as significant or partial effectiveness for protecting against, detecting, or responding to the TTP are included, resulting in a total of 83 mappings. Note: The TTPs with strike-throughs are ones we did not score in Q2 due to time limitation but these would typically be used too. +Typically, it is recommended that capability mappings scored as Partial or Significant +effectiveness at mitigating the behavior described by a (sub-) technique, be considered +for implementation. If you are inclined to include a capability scored as Minimal +effectiveness, carefully consider whether this control would actually be a practical +means of mitigating the threat. Often, minimally scored controls could technically +mitigate the behavior but in the real world would not be used for that purpose. In that +case, the recommendation would be to exclude it. Using Mappings Explorer data and +looking at each of the specific TTPs identified in Q2, we identify the Azure security +capabilities mappings as listed in the table below. Native Azure capabilities scored as +significant or partial effectiveness for protecting against, detecting, or responding to +the TTP are included, resulting in a total of 83 mappings. Note: The TTPs with +strike-throughs are ones we did not score in Q2 due to time limitation but these would +typically be used too. .. collapse:: Table of Azure Capabilities Mappings by Technique @@ -92,7 +165,10 @@ Using Mappings Explorer data and looking at each of the specific TTPs identified | -The next table presents the Azure Security Capability mappings that can provide mitigation for the ATT&CK TTPs identified in Q2. The included capabilities were scored as being significant or partial effectiveness for each of the mapping categories of protect, detect, and respond in relation to the mapped technique. +The next table presents the Azure Security Capability mappings that can provide +mitigation for the ATT&CK TTPs identified in Q2. The included capabilities were scored +as being significant or partial effectiveness for each of the mapping categories of +protect, detect, and respond in relation to the mapped technique. .. collapse:: Table of Azure Capabilities Mappings by Capability @@ -113,8 +189,13 @@ Identify Areas of Risk Scales of Threat, Defense, and Risk -During this step of the process, we will be combining scored threat TTPs that were compiled from the evidence and theory sections with the defensive capabilities mapped in the previous section. The example will continue to focus on the Azure platform and the TTPs associated with possible threats against the AMPS device. This step results in three navigator layers, the layers are optional and can be chosen to be completed based on the needs of the organization. -Start by creating two navigator layers and overlaying them for a comprehensive view: +During this step of the process, we will be combining scored threat TTPs that were +compiled from the evidence and theory sections with the defensive capabilities mapped in +the previous section. The example will continue to focus on the Azure platform and the +TTPs associated with possible threats against the AMPS device. This step results in +three navigator layers, the layers are optional and can be chosen to be completed based +on the needs of the organization. Start by creating two navigator layers and overlaying +them for a comprehensive view: **Layer 1: A visualization of the threat scoring determined in Question 2 (Figure below). To create this layer within Navigator, the following numbering will be used:** @@ -136,9 +217,11 @@ Example: T1556: Modify Authentication Process = Some theory Some Evidence = 3 Example ATT&CK Navigator Layer for Scored TTPs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -**Layer 2: A visualization of the number of defensive controls determined in the Question 3 mappings (Figure below).** +**Layer 2: A visualization of the number of defensive controls determined in the +Question 3 mappings (Figure below).** -To figure out this range, you will count the amount of defensive capabilities for each TTP and take the highest amount and make that the maximum with the minimum being 1. +To figure out this range, you will count the amount of defensive capabilities for each +TTP and take the highest amount and make that the maximum with the minimum being 1. T1556: Modify Authentication Process # of defensive capabilities = 1 Maximum # of defensive capabilities = 15 (Password Spraying) @@ -165,7 +248,14 @@ Maximum # of defensive capabilities = 15 (Password Spraying) Example ATT&CK Navigator Layer for Number of Defensive Capabilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Once those two layers are completed, you overlay them to create a heat map that visualizes the overall risk. On the low end we have low threat high defense and on the high end we have high threat low defense. An easy way to determine this is by adding the maximum determined for layer 2 (in our case 15) to the maximum for layer 1 (which should always be 5). The resulting number will determine the range to set for the Navigator gradient (in our case 15 + 5 = 20). Then, for each TTP, the associated number for layer 1 and layer 2 will be combined. When these are plotted on the navigator layer, light purple is low risk and dark purple is high risk. +Once those two layers are completed, you overlay them to create a heat map that +visualizes the overall risk. On the low end we have low threat high defense and on the +high end we have high threat low defense. An easy way to determine this is by adding the +maximum determined for layer 2 (in our case 15) to the maximum for layer 1 (which should +always be 5). The resulting number will determine the range to set for the Navigator +gradient (in our case 15 + 5 = 20). Then, for each TTP, the associated number for layer +1 and layer 2 will be combined. When these are plotted on the navigator layer, light +purple is low risk and dark purple is high risk. .. collapse:: Example Defense Layer @@ -217,6 +307,8 @@ Once those two layers are completed, you overlay them to create a heat map that The video below walks through an example of building a scoring, defense, and risk layer. +.. TODO embed video #3 + .. raw:: html @@ -226,10 +318,32 @@ The video below walks through an example of building a scoring, defense, and ris Implementing Mitigations to Risks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -At this stage, by leveraging the Mapping Explorer or crafting mappings of our own, we understand the mitigations within our environment and the degree to which each addresses the threats we are likely to face. By implementing these specific Azure controls, that we’ve mapped to our relevant threat TTPs, we’ve significantly reduced the potential impact of an attack. - -By reviewing our overlayed Navigator layers, we can see that several TTPs, such as “Valid Accounts” (T1078), even with existing mitigations implemented within our Azure environment, remains a high risk to our system. Addressing these latent risks is a priority and your team may already have applicable controls they are aware of. If you and your team can’t think of additional fixes to these threats, we recommend using the Center’s mappings of NIST 800-53. 800-53 is a list of security and privacy controls for information systems that, if implemented, can address the latent risk posed by our remaining threats. - -The Valid Account technique T1078, for example, is mapped to several 800-53 controls. These include information Exchange, Usage Restrictions, Boundary Protection and many more. These controls represent best practices that can be adopted within your system to better protect against your remaining high risk TTPs. In our case, one mitigation might be changing existing policies within the environment to achieve “least functionality.” This can be done by ensuring component functionality is limited to a single function per component, removing unused or unnecessary software, or limiting unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. These mitigations can further be tailored to fit your given system by collaborating with your team on potential implementations. - -This mapping gives us best practices derived from NIST 800-53 to implement additional protections tailored to the risks within our system. Tailored changes constitute our best approach for securing our system against potential exploits. +At this stage, by leveraging the Mapping Explorer or crafting mappings of our own, we +understand the mitigations within our environment and the degree to which each addresses +the threats we are likely to face. By implementing these specific Azure controls, that +we’ve mapped to our relevant threat TTPs, we’ve significantly reduced the potential +impact of an attack. + +By reviewing our overlayed Navigator layers, we can see that several TTPs, such as +“Valid Accounts” (T1078), even with existing mitigations implemented within our Azure +environment, remains a high risk to our system. Addressing these latent risks is a +priority and your team may already have applicable controls they are aware of. If you +and your team can’t think of additional fixes to these threats, we recommend using the +Center’s mappings of NIST 800-53. 800-53 is a list of security and privacy controls for +information systems that, if implemented, can address the latent risk posed by our +remaining threats. + +The Valid Account technique T1078, for example, is mapped to several 800-53 controls. +These include information Exchange, Usage Restrictions, Boundary Protection and many +more. These controls represent best practices that can be adopted within your system to +better protect against your remaining high risk TTPs. In our case, one mitigation might +be changing existing policies within the environment to achieve “least functionality.” +This can be done by ensuring component functionality is limited to a single function per +component, removing unused or unnecessary software, or limiting unnecessary physical and +logical ports and protocols to prevent unauthorized connection of components, transfer +of information, and tunneling. These mitigations can further be tailored to fit your +given system by collaborating with your team on potential implementations. + +This mapping gives us best practices derived from NIST 800-53 to implement additional +protections tailored to the risks within our system. Tailored changes constitute our +best approach for securing our system against potential exploits. diff --git a/docs/question-4.rst b/docs/question-4.rst index c4d6f56..31961a8 100644 --- a/docs/question-4.rst +++ b/docs/question-4.rst @@ -10,28 +10,48 @@ Question 4: Did we do a good job? Question 4 Overview (Click to Enlarge) -As you continue with your system’s development or sustainment process, threat model in hand, your team can make use of a variety of approaches to evaluate the success of your Q3 mitigations. +As you continue with your system’s development or sustainment process, threat model in +hand, your team can make use of a variety of approaches to evaluate the success of your +Q3 mitigations. System Improvements ------------------- -The first approach reflects the degree to which your threat model has informed the development of your system. +The first approach reflects the degree to which your threat model has informed the +development of your system. -* For systems still in development, identify design decisions influenced by your threat modeling analysis. -* For systems already deployed, identify actionable outcomes where changes to your infrastructure may take place due to your threat modeling analysis. +* For systems still in development, identify design decisions influenced by your threat + modeling analysis. +* For systems already deployed, identify actionable outcomes where changes to your + infrastructure may take place due to your threat modeling analysis. -Alternatively, your team may call for a security assessment, in which an internal or external team could evaluate or probe your system to determine its security and whether the controls you’ve deployed across your system are effective. -While these sources of feedback, and others, can be drawn upon with varying degrees of complexity, the most effective means of evaluating your mitigations is with a secondary review. +Alternatively, your team may call for a security assessment, in which an internal or +external team could evaluate or probe your system to determine its security and whether +the controls you’ve deployed across your system are effective. While these sources of +feedback, and others, can be drawn upon with varying degrees of complexity, the most +effective means of evaluating your mitigations is with a secondary review. Secondary Review ---------------- -When performing periodic reevaluations, your team should ask key questions and review associated metrics to ensure existing implemented controls are reviewed and, if needed, updated to maintain effectiveness and currency with organizational objectives. -The purpose of a secondary review is to effectively reassess your threat model, determine remaining risks, and figure out what additional defensive actions need to be taken. Some valuable questions include: - -* Are your existing risk ratings correct? Should they be changed given new theoretical or evidence-based findings? -* Does your team have the right composition? Are you looping in stakeholders with a diverse range of backgrounds and perspectives? -* What additional changes have been made to your system since the last review? Does your existing model accurately reflect their state of deployment? -* Are the same critical assets being used to accomplish the system’s purpose? Have certain security controls become obsolete or redundant? - -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. 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. +When performing periodic reevaluations, your team should ask key questions and review +associated metrics to ensure existing implemented controls are reviewed and, if needed, +updated to maintain effectiveness and currency with organizational objectives. The +purpose of a secondary review is to effectively reassess your threat model, determine +remaining risks, and figure out what additional defensive actions need to be taken. Some +valuable questions include: + +* Are your existing risk ratings correct? Should they be changed given new theoretical + or evidence-based findings? +* Does your team have the right composition? Are you looping in stakeholders with a + diverse range of backgrounds and perspectives? +* What additional changes have been made to your system since the last review? Does your + existing model accurately reflect their state of deployment? +* Are the same critical assets being used to accomplish the system’s purpose? Have + certain security controls become obsolete or redundant? + +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. 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.