Top Related Projects
Quick Overview
OSSEM (Open Source Security Events Metadata) is a community-driven project focused on the documentation and standardization of security event logs. It aims to improve the understanding and utilization of security event logs across different platforms and technologies, facilitating better threat detection and incident response processes.
Pros
- Provides a comprehensive framework for standardizing security event logs
- Enhances interoperability between different security tools and platforms
- Offers detailed documentation and mappings for various data sources
- Supports the cybersecurity community through open-source collaboration
Cons
- May require significant effort to implement in existing security infrastructures
- Documentation can be overwhelming for newcomers due to its extensive nature
- Adoption may be limited by the willingness of vendors to conform to the standard
- Requires ongoing maintenance and updates to keep pace with evolving technologies
Getting Started
To get started with OSSEM:
- Visit the OSSEM GitHub repository
- Explore the documentation in the
docsfolder - Review the
attack_data_sourcesdirectory for MITRE ATT&CK data source mappings - Check out the
detection_data_modelfolder for the detection data model schema - Contribute to the project by submitting pull requests or opening issues for improvements
Note: OSSEM is primarily a documentation and standardization project, not a code library. Therefore, there are no code examples or quick start instructions in the traditional sense.
Competitor Comparisons
Cyber Threat Intelligence Repository expressed in STIX 2.0
Pros of CTI
- Comprehensive MITRE ATT&CK framework data in STIX format
- Regular updates aligned with ATT&CK releases
- Widely adopted and integrated into many security tools
Cons of CTI
- Focused solely on ATT&CK, lacking broader cybersecurity data models
- Steeper learning curve for those unfamiliar with STIX format
- Limited customization options for specific organizational needs
Code Comparison
CTI (STIX 2.1 JSON):
{
"type": "attack-pattern",
"id": "attack-pattern--7e150503-88e7-4861-866b-ff1ac82c4475",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"created": "2017-05-31T21:30:54.927Z",
"modified": "2020-03-30T01:59:46.726Z",
"name": "Rundll32",
"description": "Adversaries may abuse rundll32.exe to proxy execution of malicious code...",
}
OSSEM (YAML):
title: Process Creation
description: Event generated when a new process is created
platform: Windows
log_source:
product: windows
service: security
log_type: windows security event log
event_code: 4688
event_fields:
- name: NewProcessName
type: string
description: Name of the process being created
OSSEM provides a more flexible and extensible data model for various security events, while CTI focuses on structured threat intelligence data specific to ATT&CK. OSSEM is better suited for organizations looking to standardize their security event logs across different platforms and tools.
Automated Adversary Emulation Platform
Pros of CALDERA
- Active development with frequent updates and new features
- Comprehensive adversary emulation platform with built-in TTPs
- Extensible plugin architecture for customization
Cons of CALDERA
- Steeper learning curve due to complex functionality
- Requires more setup and configuration compared to OSSEM
- May be overkill for organizations primarily focused on data standardization
Code Comparison
CALDERA (Python):
class Operation(BaseObject):
@property
def state(self):
return self.AccessOperation(self).state
@state.setter
def state(self, state):
self.AccessOperation(self).state = state
OSSEM (YAML):
- name: process_creation
platform: windows
type: event
description: Windows process creation events
data_dictionaries:
- process_creation_1
- process_creation_2
While CALDERA focuses on adversary emulation and operation execution, OSSEM primarily deals with data standardization and documentation. The code snippets reflect their different purposes, with CALDERA implementing operational logic and OSSEM defining event schemas.
Main Sigma Rule Repository
Pros of Sigma
- Widely adopted and supported by many SIEM and security tools
- Extensive rule set covering various attack techniques and threat actors
- Flexible rule conversion for different target systems
Cons of Sigma
- Primarily focused on detection rules, less comprehensive in data modeling
- May require additional tools or scripts for full integration into some environments
- Learning curve for writing complex rules and understanding syntax
Code Comparison
OSSEM (Data Dictionary example):
name: process_creation
platform: windows
description: Windows process creation events
event_fields:
- standard_name: process_name
name: NewProcessName
type: string
description: Name of the process
Sigma (Rule example):
title: Suspicious Process Creation
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\suspicious.exe'
condition: selection
While OSSEM focuses on standardizing data models and documentation, Sigma provides a framework for writing detection rules. OSSEM's approach helps in understanding and normalizing log data, whereas Sigma enables the creation of shareable, platform-agnostic detection rules.
TheHive: a Scalable, Open Source and Free Security Incident Response Platform
Pros of TheHive
- Fully-featured incident response platform with case management capabilities
- Integrates with various security tools and threat intelligence platforms
- Active community and regular updates
Cons of TheHive
- Steeper learning curve due to its comprehensive feature set
- Requires more resources to set up and maintain
- Less focused on standardization of security data models
Code Comparison
TheHive (Scala):
def createCase(caseTemplate: String, caseTitle: String, caseDescription: String): Future[Case] = {
val newCase = Case(title = caseTitle, description = caseDescription)
caseRepository.create(newCase)
}
OSSEM (Markdown):
# Data Source: Windows Security Event Log
## Event ID 4624: An account was successfully logged on
| Field Name | Type | Description |
|------------|------|-------------|
| LogonType | Integer | The type of logon which was performed |
While TheHive provides a full-fledged incident response platform with code for managing cases, OSSEM focuses on documenting and standardizing security event logs and data models using markdown files. OSSEM aims to create a common language for security events, while TheHive offers practical tools for handling security incidents.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Open Source Security Events Metadata (OSSEM)
A community-led project focused primarily on the documentation, standardization and modeling of security event logs.
https://ossemproject.com/intro.html
Goals
- Define and share a common data moel in order to improve the data standardization and transformation of security event logs
- Define and share data structures and relationships identified in security events logs
- Provide detailed information in a dictionary format about several security event logs to the community
- Learn more about security event logs (Windows, Linux, MacOS, Azure, AWS, etc)
Project Structure
- Data Dictionaries (DD):
- Contains specific information about several security event logs organized by operating system and their respective data providers.
- Each dictionary describes a single event log and its corresponding field names.
- It provides the foundational concepts to create a data wiki in an organization.
- Common Data Model (CDM)
- Facilitates the normalization of data by providing a standard way to parse security event logs.
- The project is organized by schema entities identified in several data sources.
- The definitions of each schema entity and its respective attributes (field names) are mostly general descriptions that could help and expedite event logs parsing procedures.
- The project also provides the concept of schema tables to aggregate common entities and parse similar data sources. For example, HTTP, Port and User Agent entities can be used to normalize network traffic metadata captured in a network environment.
- Detection Model (DM):
- Focuses on identifying relationships among security events to facilitate the development of data analytics and help validate the detection of adversary techniques.
Sponsors
Author
- Roberto Rodriguez @Cyb3rWard0g
Current Committers
- Jose Luis Rodriguez @Cyb3rPandaH
- Nate Guagenti @neu5ron
- Ricardo Dias @hxnoyd
Projects Using OSSEM
Resources
- Ready to hunt? First, Show me your data!
- What's new in Windows 10, versions 1507 and 1511
- Download Security Audit Events for Windows (Spreadsheet)
- Advanced Security Audit Policy Settings
- Monitoring Active Directory for Signs of Compromise
- Audit Policy Recommendations
- Use Windows Event Forwarding to help with intrusion detection
- Minimum recommended minimum audit policy
- Windows ITPro Docs - Threat Protection
- MITRE ATT&CKcon 2018: Hunters ATT&CKing with the Data
- MITRE ATT&CKcon 2.0: Ready to ATT&CK? Bring Your Own Data (BYOD) and Validate Your Data Analytics!
- Defining ATT&CK Data Sources, Part I: Enhancing the Current State
- Defining ATT&CK Data Sources, Part II: Operationalizing the Methodology
Top Related Projects
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot