DDLC - Discovery Phase
The Detection Engineering Lifecycle begins with gathering detection requirements — a crucial phase influenced by threat intelligence, red team exercises, business security demands, and insights from security operations. A successful requirements gathering phase ensures valuable input from various departments, making detection development more efficient and minimizing time spent tracking down information.
Components of a Detection Requirement
When gathering detection requirements, it's essential to include several key elements to ensure clarity and completeness:
User Persona: Identify the individual, department, or organization requesting the detection. Examples include departments like Corporate Security, specific individuals such as John Henry, or third-party services like Okta.
Threat Persona: Define a hypothetical adversary, including their motivations, capabilities, and typical actions. Examples of such adversaries could be groups like APT1 (Comment Crew), APT34 (OilRig), APT37 (Reaper), the Lazarus Group, or Charming Kitten (Phosphorus).
Description: Clearly state what needs to be detected and the reason behind it. This should outline the goal of the detection, such as identifying specific malware behaviors or monitoring unauthorized access attempts.
Source: Detail what initiated the collection of this detection requirement. This could be driven by a particular business need, a security gap identified through threat intelligence, or insights from a red team exercise.
Exceptions: Consider any known behaviors that should be excluded to minimize false positives. For example, you might want to whitelist specific employee IP addresses that are known and trusted.
Data Sources: Specify the telemetry or data sources that the detection will rely on. Common examples include cloud platforms like AWS, Azure, or GCP, which may provide logs and other relevant data.
Evidence: Include any available resources that support the need for the detection. This might be threat research, indicators of compromise (IoCs), logs, or other data points such as SHA-256 hashes, IP addresses, or links to relevant research blogs.
Requirement Sources
Detection requirements typically emerge from:
Threat intelligence: Insights from company-specific and public threat data.
Business security requirements: Security goals rooted in organizational needs.
Red team exercises: Simulated attacks to test existing defenses.
SOC requests: Requirements from the Security Operations Center based on observed threats.
Continuous activities: Routine tasks for security maintenance and improvement.
Tools and Processes for Detection Engineering
Detection engineering relies on a mix of tools and processes to streamline and standardize workflows. Here’s a look at some of the key tools and processes that facilitate this work:
Tools
Ticketing System
Description: Serves as a centralized platform for tracking detection requirements, development progress, and completion history.
Example: JIRA allows detection requirements to be logged, tracked, and archived. It provides an overview of all ongoing, pending, and completed tasks, enabling efficient management.
Communication Platform
Description: Supports real-time communication and integrates with the ticketing system for instant updates.
Example: Slack, with dedicated channels for detection engineering, can notify team members of new JIRA tickets, facilitating prompt collaboration.
Wiki
Description: A repository for documentation on workflows, technical specs, best practices, and processes.
Example: Confluence hosts in-depth documentation on detection methods, tools, and standard operating procedures.
Processes
Detection Requirement Discovery
Description: Identifies new detection requirements from sources like threat intelligence reports or red team findings.
Example: A report on a new malware variant targeting financial institutions initiates the need for a specialized detection mechanism.
Ticket Submission
Description: Documents the detection requirement in the ticketing system, setting the stage for development.
Example: A SOC analyst creates a JIRA ticket detailing the new malware’s characteristics and relevant indicators of compromise.
Notification to Engineers
Description: Alerts engineers to new detection requirements through the communication platform.
Example: A Slack notification is sent to the "detection-engineering" channel about the newly created ticket.
Ticket Review and Triage
Description: Engineers review ticket details to verify completeness, triage based on urgency, and prioritize for development.
Example: After reviewing a ticket on a new malware variant, an engineer deems it a high-priority threat and assigns it accordingly.
Leveraging Industry Standards
Standard cybersecurity frameworks guide detection engineering processes, helping teams adopt consistent, structured approaches to threat detection and response.
MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge)
Description: A global knowledge base categorizing adversary tactics and techniques observed in real-world attacks.
Example:
Tactic: Initial Access — methods adversaries use to gain entry into networks.
Technique: Spearphishing Attachment — targeted emails with malicious attachments to gain network access.
Utility: Enables defenders to create detection rules and response measures aligned with observed adversary behavior. For instance, detecting spearphishing might lead an organization to improve email security and train employees on recognizing phishing tactics.
CVSS (Common Vulnerability Scoring System)
Description: Provides a standardized score reflecting a vulnerability’s severity.
Example: A vulnerability with a CVSS score of 9.8 would indicate a critical issue demanding immediate attention.
STIX (Structured Threat Information eXpression)
Description: A structured language for representing and exchanging cyber threat intelligence.
Example: After a cyber incident, an organization might create a STIX document detailing indicators of compromise, threat actor behaviors, and recommended mitigations.
Conclusion
Incorporating the Detection Engineering Lifecycle into your security operations can vastly improve your organization’s threat detection capabilities. By following a structured approach — from gathering requirements and using collaborative tools to leveraging industry standards like MITRE ATT&CK — teams can create targeted, effective detection mechanisms that keep up with the latest threats.