Skip to content

OTRF/OSSEM-DM

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

OSSEM Detection Model (DM)

Open Source Love Open_Threat_Research Community Twitter

This part of the project focuses on defining the required telemetry to gather security context of different behaviors that happen in a network environment. Network behaviors are described using data entities and the interaction or relationships among them. These relationships and its metadata may facilitate the creation of data analytics and validate detection of adversary techniques. We have also extended this concept to the MITRE-ATT&CK framework.

Projects Using the OSSEM Detection Model

Documentation Format and Schema

We document relationships metadata in YAML format (.yml extension) using the following schema:

a) General Metadata

  • Metadata that help to identify and describe the relationship
Field Mandatory Data Type Description Example
relationship_id Yes String ID that uniquely identifies a relationship. It considers three components: string REL + creation year + sequence number (4 digits) that is restarted every year.This field is not required when contributing a relationship yaml file because it is added using a Python script. REL-2022-0175
name Yes String Name of the relationship that describes the activity around data entities. Usually, entities' names have the first character of earch word capitalized. Process created Process
contributors Yes List of Strings People that helped with the creation or update of yaml files. Additional context can be provided such as Twitter handle. Jose Rodriguez @Cyb3rPandaH
references No List of Strings Any web link that could provide more context about the relationship and\or security events mapped to it. https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4688
notes No List of Strings Any comment or note that could help to get a better understanding of the relationship YAML file and/or security events mapped to it. For event 4688 - You must enable "Administrative Templates\System\Audit Process Creation\Include command line in process creation events" group policy to include command line in process creation events.

b) ATT&CK Data Sources Mapping (attack)

  • Metadata that describes the mapping of relationships to Data Sources and Data Components from the MITRE-ATT&CK framework.
  • This section of the YAML file is not mandatory, and it should be described using a Dictionary.
Field Mandatory Data Type Description Example
data_source No String ATT&CK data source process
data_component No String ATT&CK data component process creation

c) Network Environment Behavior (behavior)

  • Metadata that describes the interaction among entities. It considers three components: source entity, relationship, and target entity. Entities' names are aligned with the OSSEM Common Data Model project.
  • This sections of the YAML file is mandatory, and it should be described using a Dictionary.
Field Mandatory Data Type Description Example
source Yes String Usually the entity that performs the activity. process
relationship Yes String Action or activity performed or related to source entity created
target Yes String Usually the entity affected by the activity process

d) Security Telemetry Mapping (security_events)

  • Metadata that describes the mapping of security telemetry to relationships.
  • This section of the YAML file is mandatory, and it should be described using a List of Dictionaries, where each dictionary represents a specific event log or source of data.
  • Even though this section is mandatory, some of the fields within this section are not since they only apply for specific telemetry sources.
    • We use fields audit_category, audit_sub_category, and channel when mapping Microsoft Windows Security Auditing events.
    • We use field audit_category in Windows Sysmon events in order to populate the Enable Commands columns of the ATT&CK CSV file
    • We use field filter_in to provide additional context when an event log or telemetry source describes multiple objects or actions using the same schema. A good example of this is Windows Security Auditing event 4656, where the object context varies based on the ObjectType field (Process, Key, Service, etc).
Field Mandatory Data Type Description Example
event_id Yes String ID uniquely identifies and differentiate events from the same source. '4688'
name Yes String Name of the event. Is some cases, it might be similar to its ID. A new process has been created.
platform Yes String Operating system or application where the event can be collected. Windows
audit_cateogry No String Windows related field. It describes the audit policy subcategory an event belongs to. Detailed Tracking
audit_sub_category No String Windows related field. It describes the audit policy subcategory an event belongs to. Process Creation
channel No String Windows related field. It describes a group of events for a target audience. They belong to one of the four types: admin, operational, analytic, and debug. Security
log_source Yes String Describes the source that provides an event or we can collect the event from. In Windows environments, for ETW-based events, this field represent the Provider. Microsoft-Windows-Security-Auditing
filter_in No List of Dictionaries For events that use the same schema and provide different security context based on the activity or the object they are describing. For example: DeviceProcessEvents from Microsoft Defender for Endpoint provides different context based on field ActionType. Another example would be event 4656 from Microsoft Windows Security Auditing because the context is different based on field ObjectType. ActionType: ProcessCreated
event_version No List of Strings This information help us when relating OSSEM-DM with OSSEM-DD. If event metadata contains a version, this means that there is an OSSEM dictionary available. For now, this field is not required when contributing a relationship yaml file. '2'

Contribution Example

Here is YAML example that you can use as a reference when contributing relationships:

name: Process created Process
contributors:
- Jose Rodriguez @Cyb3rPandaH
attack:
  data_source: process
  data_component: process creation
behavior:
  source: process
  relationship: created
  target: process
security_events:
- event_id: '4688'
  name: A new process has been created.
  platform: windows
  audit_category: Detailed Tracking
  audit_sub_category: Process Creation
  channel: Security
  log_source: Microsoft-Windows-Security-Auditing
  event_version:
  - '2'
- event_id: DeviceProcessEvents
  name: DeviceProcessEvents
  platform: windows
  log_source: Microsoft Defender for Endpoint
  filter_in:
  - ActionType: ProcessCreated
  event_version:
  - '1'
- event_id: '1'
  name: Process Creation.
  platform: windows
  audit_category: ProcessCreate
  channel: Microsoft-Windows-Sysmon/Operational
  log_source: Microsoft-Windows-Sysmon
  event_version:
  - '4.32'
references:
- https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4688
- https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#event-id-1-process-creation
notes:
- For event 4688 - You must enable "Administrative Templates\System\Audit Process Creation\Include command line in process creation events" group policy to include command line in process creation events.

Available documents

File Description
OSSEM Event Mappings in YAML Security event logs mapped to OSSEM relationships in YAML format. (Includes ATT&CK data sources metadata)
OSSEM Event Mappings in JSON Security event logs mapped to OSSEM relationships in JSON format. (Includes ATT&CK data sources metadata)
ATT&CK Event Mappings in YAML Security event logs mapped to ATT&CK Data Sources Objects in YAML format.
ATT&CK Event Mappings in CSV Security event logs mapped to ATT&CK Data Sources Objects in CSV format.

References

Presentations:

Related Projects:

ATT&CK:

Other: