Merge pull request #56 from center-for-threat-informed-defense/websit…

…e-final-touches

Website final touches

docs/capability-abstraction.rst

@@ -32,7 +32,7 @@ the same registry key within the Registry Service Database. If an adversary want
 interacting with the Windows API, RPC, or Registry. This is not a hypothetical, but has actually been seen in the wild. Threat group APT41 has utilized Windows service 
 creation within their attacks not only through the utilization of the service creation tool (sc.exe), but also by directly modifying the registry itself [#f3]_. 
 
-The Summiting the Pyramid team is utilizing capability abstraction mappings to map certain observables to :ref:`Analytic Robustness Categories` and :ref:`Sensor Robustness Categories` outlined by our methodology. As observables are assigned, further research can be conducted to identify detections based off those observables, especially for observables which might cover part or all of a technique. For example, if a kernel call is detected, is there a specific Windows Event ID that is fired? Are there registry keys that are updated? Does a registry key change over all implementations of a technique? This gives the defender a broader perspective of not only the tools that use similar behaviors towards the lower-levels of the operating system, but also how to think of detecting behaviors the closer an adversary gets to the kernel.
+The Summiting the Pyramid team is utilizing capability abstraction mappings to map certain observables to :ref:`Analytic Robustness Categories` and :ref:`Event Robustness Categories` outlined by our methodology. As observables are assigned, further research can be conducted to identify detections based off those observables, especially for observables which might cover part or all of a technique. For example, if a kernel call is detected, is there a specific Windows Event ID that is fired? Are there registry keys that are updated? Does a registry key change over all implementations of a technique? This gives the defender a broader perspective of not only the tools that use similar behaviors towards the lower-levels of the operating system, but also how to think of detecting behaviors the closer an adversary gets to the kernel.
 
 .. rubric:: References
 

docs/changelog.rst

@@ -1,5 +1,8 @@
 Changelog
 =========
+0.0.21
+    Changed sensor robustness to event robustness, changed LSASS score from 5 to 4, updated ATT&CK Technique page
+
 0.0.20
     Final cleanup and feedback for website materials
 

docs/datasources.rst

@@ -1,7 +1,7 @@
 .. _Data Sources:
 
-ATT&CK Technique Mappings
-===========================
+Example ATT&CK Technique Mappings
+=================================
 
 `T1003: LSASS Memory <https://attack.mitre.org/techniques/T1003/001/>`_
 -----------------------------------------------------------------------

docs/definitions.rst

@@ -83,13 +83,13 @@ Analytic Robustness Categories
 
 The Summiting the Pyramid methodology is focused on scoring analytics based on the difficulty for adversaries to evade them while still executing the Technique of interest, and without tampering with the defensive sensors. Different observables are more or less evadable than others. Summiting the Pyramid has defined five categories of observable robustness. The categories organize observables starting with the most easily evaded observables towards the bottom of the table, to the least easily evaded observables at the top of the table. To read more about how the categories are currently outlined, refer to our :ref:`Model Mapping Pages`.
 
-.. _Sensor Robustness Categories:
+.. _Event Robustness Categories:
 
-Sensor Robustness Categories
+Event Robustness Categories
 ----------------------------
 **Columns in the Summiting the Pyramid methodology model group observables and events based on where they are generated, and therefore what an adversary would need to avoid triggering them while executing the same functionality.**
 
-Analytics are constrained by the sensor data that is being used to log observables. The sensor robustness category columns look to create groups of sensor data observables based on how evasive they are in the OS. In this release, the generation locations are all different layers of the application and OS stack. In future releases, we may add locations elsewhere in cyber such as internet access point, or intra-enclave network traffic collection to extend this model to other types of observables. To read more about how the columns are currently outlined, refer to our :ref:`Model Mapping Pages`.
+Analytics are constrained by the sensor data that is being used to log observables. The event robustness category columns look to create groups of event data observables based on how evasive they are in the OS. In this release, the generation locations are all different layers of the application and OS stack. In future releases, we may add locations elsewhere in cyber such as internet access point, or intra-enclave network traffic collection to extend this model to other types of observables. To read more about how the columns are currently outlined, refer to our :ref:`Model Mapping Pages`.
 
 **References**
 

docs/levels/application.rst

@@ -6,7 +6,7 @@ Column A: Application
 
 **Description**: Observables associated with the use of applications available to defenders before adversary use and difficult for the adversary to modify.
 
-The Application sensor robustness category groups observables which are collected closest to applications and are potentially modifiable by the user. For example, Windows provides developers the opportunity to create service providers for tools and applications, which can be used to create detection analytics. Other frameworks can be implemented by a user for needs within their environment. While users might need to download and configure application sensor data, they are available to the defender before an adversary conducts their attack.
+The Application event robustness category groups observables which are collected closest to applications and are potentially modifiable by the user. For example, Windows provides developers the opportunity to create service providers for tools and applications, which can be used to create detection analytics. Other frameworks can be implemented by a user for needs within their environment. While users might need to download and configure application sensor data, they are available to the defender before an adversary conducts their attack.
 
 .. note:: 
     Other efforts within the Center for Threat-Informed Defense are conducting research on sensor data generation, and will be expanding and adding sensor data to robustness categories in the future.

docs/levels/implementations.rst

@@ -23,12 +23,19 @@ Observables
 |                               |                                                   | value used by the system for       |
 |                               |                                                   | authentication [#f1]_              |
 +-------------------------------+---------------------------------------------------+------------------------------------+
-| Indicator Removal: File       | Event ID 524                                      | While this is a sensor robustness  |
+| Indicator Removal: File       | Event ID 524                                      | While this is a event robustness   |
 | Deletion (T1070.004)          | Provider Name: Microsoft-Windows-Backup           | category, the utilization of this  |
 |                               |                                                   | event is indicative of this        |
 |                               |                                                   | technique.                         |
 +-------------------------------+---------------------------------------------------+------------------------------------+
+|  OS Credential Dumping:       |  TargetImage = lsass.exe                          | There are multiple access masks    |
+|  LSASS Memory (T1003.001)     |  GrantedAccess: 0x1010 OR 0x1410                  | which can be used. This analytic   | 
+|                               |                                                   | covers two of those access masks.  |
+|                               |                                                   | Anything that has the right bits   |
+|                               |                                                   | are wildcards essentially [#f2]_   |
++-------------------------------+---------------------------------------------------+------------------------------------+
 
 .. rubric:: References:
 
-.. [#f1] https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/
+.. [#f1] https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/
+.. [#f2] https://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html

docs/levels/index.rst

@@ -19,8 +19,8 @@ There are five levels which are grouped based on how difficult it is for an adve
     adversary_tool
     ephemeral
 
-**Columns: Sensor Robustness Categories**
-There are currently three columns which describe sensor data based on their visibility into the OS.
+**Columns: Event Robustness Categories**
+There are currently three columns which describe event data based on their visibility into the OS. These may be similar to a sensor. However, due to where they are triggered in the OS, these are currently focusing on event robustness. This can change in the future due to ever growing sensors and the type of data they gather.
 
 .. toctree::
     :maxdepth: 1

docs/levels/quicklevels.rst

@@ -19,7 +19,7 @@ Observables Quick Search
      - Hashes (Sysmon), md5_hash (CAR), sha1_hash (CAR), sha256_hash (CAR), target_address (CAR), dest_ip (CAR), src_ip (CAR), dest_port (CAR), src_port (CAR), image (Sysmon), parent image (Sysmon), current directory (Sysmon), extension (CAR), file_name (CAR), file_path (CAR), image_path (CAR), current_working_directory (CAR), exe (CAR), parent_exe (CAR), app_name (CAR), auth_target (CAR), fqdn (CAR), ad_domain (CAR), target_ad_domain (CAR), process GUID (Sysmon), process ID (Sysmon), parent process GUID (Sysmon), parent process ID (Sysmon), Subject SID (Windows), target SID (Windows EID), new process ID (Windows EID), creator process ID (Windows EID), pid (CAR), ppid (CAR), user (Sysmon), logon GUID (Sysmon), logon ID (Sysmon), subject name (Windows EID), subject domain (Windows EID), subject logon ID (Windows EID), target domain (Windows EID), target logon ID (Windows EID), new process name (Windows EID), creator process name (Windows EID), gid (CAR), group (CAR), owner_uid (CAR), owner (CAR), user (CAR), uid (CAR), guid (CAR), hostname (CAR), target_guid (CAR), target_uid (CAR), target_user (CAR), target_user_role (CAR), target_user_type (CAR), target_name (CAR), target_pid (CAR), login_id (CAR), user_agent (CAR), user_role (CAR), contents (CAR), creation_time (CAR), mode (CAR), previous_creation_time (CAR), env_vars (CAR), data (CAR), new_content (CAR), value (CAR), response_time
 
 
-.. list-table:: Sensor Robustness Categories
+.. list-table:: Event Robustness Categories
    :widths: 30 70
    :header-rows: 1
 

docs/levels/technique.rst

@@ -20,14 +20,8 @@ Observables
 |                           |  SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\       |  regardless of implementation [#f1]_ |
 |                           |  Schedule\\TaskCache"                                    |                                      |
 +---------------------------+----------------------------------------------------------+--------------------------------------+
-|  OS Credential Dumping:   |  TargetImage = lsass.exe                                 | The Splunk team outlines their       |
-|  LSASS Memory (T1003.001) |  GrantedAccess: 0x1010 OR 0x1410                         | research for LSASS Dumping covers    | 
-|                           |                                                          | multiple implementations of the      |
-|                           |                                                          | technique [#f2]_                     |
-+---------------------------+----------------------------------------------------------+--------------------------------------+
 
 
 .. rubric:: References
 
-.. [#f1] https://posts.specterops.io/abstracting-scheduled-tasks-3b6451f6a1c5
-.. [#f2] https://www.splunk.com/en_us/blog/security/you-bet-your-lsass-hunting-lsass-access.html
+.. [#f1] https://posts.specterops.io/abstracting-scheduled-tasks-3b6451f6a1c5

docs/methodology.rst

@@ -114,7 +114,7 @@ Let's step through an example. The below analytic looks for specific command lin
    level: medium
 
 
-First, we have to understand and score this analytic's sensor robustness category. The data source for this analytic is ``process_creation``, so it could potentially trigger Windows Event ID 4688 or Sysmon Event ID 1. 
+First, we have to understand and score this analytic's event robustness category. The data source for this analytic is ``process_creation``, so it could potentially trigger Windows Event ID 4688 or Sysmon Event ID 1. 
 This analytic references the Image field which does not exist in Event ID 4688, but it does exist in Sysmon Event ID 1 [#f3]_. 4688 has the field 
 NewProcessName, though it could be mapped to another field name in your SIEM of choice. As a result, we assume 
 the intent of this analytic is to identify command line activity in Sysmon Event ID 1s.

docs/scoringanalytic.rst

@@ -13,7 +13,7 @@ This walkthrough will highlight scoring `suspicious pipe creation from CobaltStr
 
 Step 1: Scoring the analytic's sensor data
 ------------------------------------------
-Just as not all analytics are created equal, not all sensors are created equal. Our sensor robustness categories identify the different layers within the OS in which observables can be collected. Each of the different sensors within each column provide different insight into the OS.
+Just as not all analytics are created equal, not all sensors are created equal. Our event robustness categories identify the different layers within the OS in which observables can be collected. Each of the different events within each column provide different insight into the OS.
 
 In the pipe creation example, the sensor data identified is Windows, and the category is ``pipe_created``. Based on the types of Event IDs Windows provides and a list of field names which belong to Event IDs, we know that the analytic is made for Sysmon logs. Based on past research, emulation, and Microsoft documentation, we understand that Event ID 17 is fired after ImpersonateNamedPipeClient is called, which is a :ref:`User-Mode` function. [#f2]_ However, after some additional research, it was found that certain Sysmon events are triggered with a minifilter. [#f3]_ Minifilters are executed by the Filter manager, operating in kernel-mode. [#f4]_ Because of this, the data sensor placement of this analytic will be in :ref:`Kernel-Mode`.