Instruction: How does Detection Engineering Lifecycle work?

Output:
Detection Engineering Lifecycle: Detection engineering follows an iterative lifecycle: (1) Threat Intelligence gathering to understand adversary TTPs, (2) Hypothesis formation about detectable behaviors, (3) Data source identification and validation, (4) Detection logic development, (5) Testing in lab environments, (6) Production deployment with tuning, (7) Continuous monitoring and refinement. This lifecycle ensures detections remain effective against evolving threats while minimizing false positives.

Use cases:
- Building new detection capabilities
- Maturing security operations
- Responding to threat intelligence


Instruction: When is Detection Engineering Lifecycle appropriate?

Output:
Use cases for Detection Engineering Lifecycle:

- Building new detection capabilities
- Maturing security operations
- Responding to threat intelligence

Detection engineering follows an iterative lifecycle: (1) Threat Intelligence gathering to understand adversary TTPs, (2) Hypothesis formation about detectable behaviors, (3) Data source identification and validation, (4) Detection logic development, (5) Testing in lab environments, (6) Production deployment with tuning, (7) Continuous monitoring and refinement. This lifecycle ensures detections remain effective against evolving threats while minimizing false positives.


Instruction: What are best practices for Detection Engineering Lifecycle?

Output:
Best practices for Detection Engineering Lifecycle:

- Document detection hypotheses before writing rules
- Version control all detection logic
- Measure detection effectiveness continuously
- Automate testing where possible

Avoid these mistakes:
- Skipping the hypothesis phase leads to unfocused detections
- Not testing in production-like environments
- Ignoring false positive feedback


Instruction: What goes wrong with Detection Engineering Lifecycle?

Output:
Common pitfalls with Detection Engineering Lifecycle:

- Skipping the hypothesis phase leads to unfocused detections
- Not testing in production-like environments
- Ignoring false positive feedback

To avoid these issues:
- Document detection hypotheses before writing rules
- Version control all detection logic
- Measure detection effectiveness continuously


Instruction: What is the detection engineering lifecycle?

Output: The detection engineering lifecycle is an iterative process for building and maintaining effective security detections. It consists of: (1) Threat Intelligence - gathering information about adversary tactics, techniques, and procedures (TTPs), (2) Hypothesis Formation - developing theories about what malicious behaviors can be detected, (3) Data Source Identification - determining what logs and telemetry are needed, (4) Detection Logic Development - writing Sigma, YARA, or SIEM rules, (5) Lab Testing - validating detections against simulated attacks, (6) Production Deployment - rolling out with appropriate tuning, (7) Continuous Refinement - monitoring effectiveness and adjusting based on feedback. This cycle repeats as new threats emerge and environments change.


Instruction: How do you start a detection engineering program?

Output: Starting a detection engineering program requires: (1) Assess current detection coverage using frameworks like MITRE ATT&CK, (2) Establish data collection priorities - ensure critical log sources are available, (3) Choose detection formats (Sigma for portability, native SIEM rules for advanced features), (4) Build a detection development workflow with version control (Git), (5) Create testing infrastructure using tools like Atomic Red Team, (6) Define metrics for success (detection rate, false positive rate, mean time to detect), (7) Start with high-confidence, low-noise detections for quick wins, (8) Gradually expand coverage based on threat intelligence and risk priorities.


Instruction: What skills does a detection engineer need?

Output: Detection engineers require a blend of technical and analytical skills: Technical Skills: (1) Query languages - SPL, KQL, EQL for SIEM platforms, (2) Sigma and YARA rule development, (3) Log analysis and parsing expertise, (4) Scripting (Python) for automation, (5) Version control (Git) workflows. Security Knowledge: (1) MITRE ATT&CK framework fluency, (2) Attack techniques and adversary tradecraft, (3) Malware analysis fundamentals, (4) Incident response experience. Analytical Skills: (1) Threat modeling and hypothesis development, (2) Statistical thinking for anomaly detection, (3) Root cause analysis for false positives. Soft Skills: (1) Communication with SOC analysts, (2) Documentation and knowledge sharing, (3) Prioritization under resource constraints. Career Path: Many detection engineers come from SOC analyst or threat hunting backgrounds.


Instruction: What is the difference between detection engineering and threat hunting?

Output: Detection engineering and threat hunting are complementary disciplines: Detection Engineering focuses on: (1) Building automated, persistent detections, (2) Rules that run continuously without human intervention, (3) Scalable coverage across known techniques, (4) Measurable, repeatable detection capabilities, (5) Reducing manual analyst workload. Threat Hunting focuses on: (1) Proactive, hypothesis-driven investigation, (2) Finding threats that evade existing detections, (3) Human-led analysis and intuition, (4) Discovering new attack patterns, (5) One-time or periodic investigations. Relationship: Hunting discovers new threats -> Detection engineering codifies findings into rules -> Rules catch future instances -> Hunting focuses on gaps. Feedback loop: Every hunt should produce detection opportunities, every detection miss should inform hunting hypotheses. Mature teams have dedicated resources for both functions.


Instruction: What is Detection-as-Code?

Output:
Detection-as-Code: Detection-as-Code (DaC) applies software development practices to security detection management. Detections are stored as code in version control (Git), reviewed through pull requests, tested automatically in CI/CD pipelines, and deployed programmatically. This approach enables collaboration, change tracking, rollback capabilities, and consistent deployment across environments. Popular formats include Sigma (vendor-agnostic), YARA (file/memory scanning), and native SIEM query languages.

Use cases:
- Managing detections at scale
- Enabling detection collaboration
- Auditing detection changes
- Automating detection deployment


Instruction: When is Detection-as-Code appropriate?

Output:
Use cases for Detection-as-Code:

- Managing detections at scale
- Enabling detection collaboration
- Auditing detection changes
- Automating detection deployment

Detection-as-Code (DaC) applies software development practices to security detection management. Detections are stored as code in version control (Git), reviewed through pull requests, tested automatically in CI/CD pipelines, and deployed programmatically. This approach enables collaboration, change tracking, rollback capabilities, and consistent deployment across environments. Popular formats include Sigma (vendor-agnostic), YARA (file/memory scanning), and native SIEM query languages.


Instruction: How do you properly use Detection-as-Code?

Output:
Best practices for Detection-as-Code:

- Store all detections in Git repositories
- Require peer review for detection changes
- Automate syntax validation and testing
- Use semantic versioning for detection packs

Avoid these mistakes:
- Treating detections as one-off scripts rather than managed code
- Not testing detections before deployment
- Lacking documentation and context


Instruction: What are common pitfalls with Detection-as-Code?

Output:
Common pitfalls with Detection-as-Code:

- Treating detections as one-off scripts rather than managed code
- Not testing detections before deployment
- Lacking documentation and context

To avoid these issues:
- Store all detections in Git repositories
- Require peer review for detection changes
- Automate syntax validation and testing


Instruction: What is Detection-as-Code and why is it important?

Output: Detection-as-Code (DaC) applies software engineering practices to security detection management. Key principles include: (1) Version Control - all detections stored in Git with full change history, (2) Code Review - detection changes reviewed by peers before deployment, (3) Automated Testing - CI/CD pipelines validate syntax and test against sample data, (4) Documentation - detections include context, references, and false positive guidance, (5) Deployment Automation - detections pushed to SIEMs programmatically. Benefits include: accountability through change tracking, collaboration across teams, rollback capabilities when detections cause issues, consistency across environments, and measurable improvement over time. Tools like Sigma enable vendor-agnostic detection definitions that convert to multiple SIEM formats.


Instruction: How do you implement Detection-as-Code?

Output: Implementing Detection-as-Code requires: (1) Repository Setup - create a Git repository with folder structure for different detection types (Sigma rules, YARA rules, SIEM queries), (2) Format Selection - choose Sigma for portability or native SIEM formats for advanced features, (3) CI/CD Pipeline - configure GitHub Actions or GitLab CI to validate syntax, run unit tests, and deploy, (4) Testing Framework - integrate tools like pySigma for Sigma validation, or custom test harnesses, (5) Deployment Automation - use APIs or configuration management to push detections to production, (6) Review Process - establish pull request templates with required fields (MITRE mapping, false positives, testing evidence), (7) Metrics Dashboard - track detection coverage, deployment frequency, and effectiveness.


Instruction: What are the benefits of storing detections in Git?

Output: Storing detections in Git provides: Change Tracking: (1) Complete history of who changed what and when, (2) Ability to diff changes between versions, (3) Blame functionality to understand rule evolution, (4) Audit trail for compliance requirements. Collaboration: (1) Multiple engineers can work on rules simultaneously, (2) Pull request reviews catch errors before deployment, (3) Comments and discussions preserved with changes, (4) Knowledge sharing through documented changes. Quality Control: (1) Require reviews before merging, (2) Automated testing in CI pipelines, (3) Branch protection prevents accidental changes, (4) Consistent deployment process. Operations: (1) Easy rollback if rule causes issues, (2) Tag releases for deployment tracking, (3) Fork and customize community rule sets, (4) Sync across multiple environments.


Instruction: Describe True Positives and False Positives for detection engineering.

Output:
True Positives and False Positives: In detection engineering, a True Positive (TP) is a correct alert identifying actual malicious activity. A False Positive (FP) is an incorrect alert triggered by benign activity. A False Negative (FN) is malicious activity that goes undetected. A True Negative (TN) is benign activity correctly not alerted on. Detection quality is measured by Precision (TP/(TP+FP)) and Recall (TP/(TP+FN)). High-quality detections maximize true positives while minimizing false positives to prevent alert fatigue.

Use cases:
- Measuring detection quality
- Tuning detection rules
- Prioritizing alert response


Instruction: When is True Positives and False Positives appropriate?

Output:
Use cases for True Positives and False Positives:

- Measuring detection quality
- Tuning detection rules
- Prioritizing alert response

In detection engineering, a True Positive (TP) is a correct alert identifying actual malicious activity. A False Positive (FP) is an incorrect alert triggered by benign activity. A False Negative (FN) is malicious activity that goes undetected. A True Negative (TN) is benign activity correctly not alerted on. Detection quality is measured by Precision (TP/(TP+FP)) and Recall (TP/(TP+FN)). High-quality detections maximize true positives while minimizing false positives to prevent alert fatigue.


Instruction: What are best practices for True Positives and False Positives?

Output:
Best practices for True Positives and False Positives:

- Track TP/FP rates per detection rule
- Document known false positive patterns
- Set acceptable FP thresholds by rule severity
- Regularly review and tune high-FP rules

Avoid these mistakes:
- Ignoring false positive feedback
- Not distinguishing between FP types (tunable vs inherent)
- Over-tuning rules to point of missing attacks


Instruction: What should you avoid when using True Positives and False Positives?

Output:
Common pitfalls with True Positives and False Positives:

- Ignoring false positive feedback
- Not distinguishing between FP types (tunable vs inherent)
- Over-tuning rules to point of missing attacks

To avoid these issues:
- Track TP/FP rates per detection rule
- Document known false positive patterns
- Set acceptable FP thresholds by rule severity


Instruction: What are true positives, false positives, and false negatives in detection?

Output: In security detection: True Positive (TP) - correctly detecting actual malicious activity (the goal), False Positive (FP) - alerting on benign activity mistakenly identified as malicious (causes alert fatigue), False Negative (FN) - failing to detect actual malicious activity (security gap), True Negative (TN) - correctly not alerting on benign activity (expected behavior). Detection quality metrics: Precision = TP/(TP+FP) measures how many alerts are real threats, Recall = TP/(TP+FN) measures how many real threats are caught. Ideal detections have high precision (few false positives) and high recall (few missed attacks), but there's often a tradeoff between these metrics.


Instruction: How do you reduce false positives without missing attacks?

Output: Reducing false positives while maintaining detection effectiveness requires: (1) Understand the FP source - is it a noisy data field, legitimate tool, or overly broad pattern? (2) Add context filters - exclude known-good processes, users, or systems with allowlists, (3) Use behavioral patterns - combine multiple indicators rather than single events, (4) Implement threshold logic - require multiple occurrences within a time window, (5) Leverage entity context - user role, system type, historical baseline, (6) Document FP patterns - maintain exclusion lists with justification, (7) Test tuning changes - verify the attack still triggers after adding exclusions, (8) Monitor FP/TP ratio - track metrics to catch over-tuning early. Never blindly suppress alerts without understanding root cause.


Instruction: What is precision and recall in detection?

Output: Precision and recall measure detection quality: Precision = True Positives / (True Positives + False Positives). Measures: What percentage of alerts are real threats? High precision means few false alarms. Goal: Minimize wasted analyst time on false alerts. Recall = True Positives / (True Positives + False Negatives). Measures: What percentage of real threats are caught? High recall means few missed attacks. Goal: Minimize security gaps from undetected threats. Trade-off: Increasing precision often decreases recall and vice versa. Making rules more specific reduces FPs but may miss attack variants. Making rules broader catches more attacks but increases noise. Balance: Critical systems may accept lower precision for higher recall. High-volume environments may prioritize precision to manage alert load. F1 Score combines both: 2 * (Precision * Recall) / (Precision + Recall).


Instruction: How does Alert Fatigue work?

Output:
Alert Fatigue: Alert fatigue occurs when security analysts become desensitized to alerts due to excessive volume, especially false positives. This leads to slower response times, missed true positives, analyst burnout, and degraded security posture. Causes include poorly tuned detections, lack of alert prioritization, insufficient context in alerts, and detecting on noisy data sources. Mitigation requires ruthless detection tuning, risk-based prioritization, alert aggregation, and automation of repetitive tasks.

Use cases:
- SOC operations improvement
- Detection tuning prioritization
- Security program maturity assessment


Instruction: What are the use cases for Alert Fatigue?

Output:
Use cases for Alert Fatigue:

- SOC operations improvement
- Detection tuning prioritization
- Security program maturity assessment

Alert fatigue occurs when security analysts become desensitized to alerts due to excessive volume, especially false positives. This leads to slower response times, missed true positives, analyst burnout, and degraded security posture. Causes include poorly tuned detections, lack of alert prioritization, insufficient context in alerts, and detecting on noisy data sources. Mitigation requires ruthless detection tuning, risk-based prioritization, alert aggregation, and automation of repetitive tasks.


Instruction: How should you implement Alert Fatigue?

Output:
Best practices for Alert Fatigue:

- Establish maximum acceptable alert volume per analyst
- Prioritize tuning highest-volume, lowest-value alerts
- Implement risk-based alerting scores
- Aggregate related alerts into incidents

Avoid these mistakes:
- Adding detections without considering analyst capacity
- Not measuring alert-to-incident ratio
- Ignoring analyst feedback on noisy rules


Instruction: What goes wrong with Alert Fatigue?

Output:
Common pitfalls with Alert Fatigue:

- Adding detections without considering analyst capacity
- Not measuring alert-to-incident ratio
- Ignoring analyst feedback on noisy rules

To avoid these issues:
- Establish maximum acceptable alert volume per analyst
- Prioritize tuning highest-volume, lowest-value alerts
- Implement risk-based alerting scores


Instruction: What is alert fatigue and how do you prevent it?

Output: Alert fatigue is when security analysts become overwhelmed and desensitized by excessive alert volume, leading to: slower response times as analysts deprioritize alerts, missed true positives buried in noise, analyst burnout and turnover, degraded security posture despite investment. Prevention strategies: (1) Tune ruthlessly - track and fix high-FP rules weekly, (2) Risk-based prioritization - score alerts by asset criticality, user risk, and threat severity, (3) Alert aggregation - group related alerts into single incidents, (4) Automation - auto-close known false positives, auto-enrich alerts, (5) Capacity planning - measure alerts-per-analyst and set sustainable limits, (6) Detection review - sunset detections that never produce true positives, (7) Context enrichment - provide enough information for quick triage decisions.


Instruction: How do you measure and manage SOC alert volume?

Output: Managing SOC alert volume requires metrics and continuous improvement: Key Metrics: (1) Alerts per day/week by severity and source, (2) Alert-to-incident ratio (how many alerts become real incidents), (3) Mean time to triage (MTTT), (4) False positive rate per detection rule, (5) Alerts per analyst capacity (sustainable: 50-100/day). Management Process: (1) Weekly review of top 10 noisiest rules, (2) Monthly detection effectiveness review, (3) Quarterly detection portfolio audit. Reduction Techniques: (1) Allowlist legitimate activity with documentation, (2) Raise thresholds on volume-based detections, (3) Add correlation requirements (multiple indicators), (4) Implement alert suppression for maintenance windows, (5) Automate closing of informational alerts with no required action.


Instruction: What causes alert fatigue in security operations?

Output: Alert fatigue results from multiple factors: Detection Issues: (1) Poorly tuned rules with high false positive rates, (2) Overly broad detection logic triggering on legitimate activity, (3) Duplicate detections from multiple tools alerting on same event, (4) Low-value detections that require action but provide little security benefit. Process Issues: (1) No prioritization system - all alerts treated equally, (2) Insufficient context in alerts for quick triage, (3) Manual processes for repetitive tasks, (4) No feedback loop to improve detections. Environmental Issues: (1) Noisy data sources with poor signal-to-noise ratio, (2) Legacy systems generating unusual but benign events, (3) Shadow IT creating unknown traffic patterns, (4) Inadequate baseline of normal activity. Solutions: Focus on detection quality over quantity, implement risk-based prioritization, automate repetitive tasks, establish feedback mechanisms.


Instruction: Explain Detection Coverage Mapping.

Output:
Detection Coverage Mapping: Detection coverage mapping visualizes which threats an organization can detect, typically aligned to MITRE ATT&CK. It identifies gaps where attacks would go undetected, enabling prioritized development of new detections. Coverage is assessed by mapping existing detections to ATT&CK techniques, validating detections through testing, and measuring detection confidence levels. Tools like ATT&CK Navigator visualize coverage heatmaps across the matrix.

Use cases:
- Identifying detection gaps
- Prioritizing detection development
- Reporting security posture to leadership
- Validating security investments


Instruction: When should you use Detection Coverage Mapping?

Output:
Use cases for Detection Coverage Mapping:

- Identifying detection gaps
- Prioritizing detection development
- Reporting security posture to leadership
- Validating security investments

Detection coverage mapping visualizes which threats an organization can detect, typically aligned to MITRE ATT&CK. It identifies gaps where attacks would go undetected, enabling prioritized development of new detections. Coverage is assessed by mapping existing detections to ATT&CK techniques, validating detections through testing, and measuring detection confidence levels. Tools like ATT&CK Navigator visualize coverage heatmaps across the matrix.


Instruction: What are best practices for Detection Coverage Mapping?

Output:
Best practices for Detection Coverage Mapping:

- Map all detections to ATT&CK techniques
- Validate mappings through actual testing
- Use confidence levels (low/medium/high) for each mapping
- Prioritize gaps based on threat intelligence

Avoid these mistakes:
- Claiming coverage without validation
- Mapping detections to techniques they don't actually detect
- Not considering sub-techniques


Instruction: What goes wrong with Detection Coverage Mapping?

Output:
Common pitfalls with Detection Coverage Mapping:

- Claiming coverage without validation
- Mapping detections to techniques they don't actually detect
- Not considering sub-techniques

To avoid these issues:
- Map all detections to ATT&CK techniques
- Validate mappings through actual testing
- Use confidence levels (low/medium/high) for each mapping


Instruction: How do you map detection coverage to MITRE ATT&CK?

Output: Mapping detection coverage to MITRE ATT&CK involves: (1) Inventory detections - catalog all Sigma rules, YARA rules, and SIEM queries, (2) Map to techniques - identify which ATT&CK technique(s) each detection covers, (3) Assign confidence - rate coverage as Low (theoretical), Medium (tested in lab), High (validated in production), (4) Visualize gaps - use ATT&CK Navigator to create coverage heatmaps, (5) Prioritize development - focus on high-impact techniques with no coverage, (6) Validate continuously - test detections with Atomic Red Team or similar tools. Example mapping: A Sigma rule detecting 'certutil -urlcache' maps to T1105 (Ingress Tool Transfer) with High confidence if tested. Coverage should be reviewed quarterly as ATT&CK updates and threats evolve.


Instruction: What tools help with detection coverage analysis?

Output: Detection coverage analysis tools include: (1) ATT&CK Navigator - web-based tool for creating technique coverage heatmaps, exportable as JSON/SVG, (2) DeTT&CT - Python framework for scoring detection and visibility coverage, (3) Sigma - rules include ATT&CK tags for automatic mapping, (4) MITRE ATT&CK Workbench - self-hosted ATT&CK knowledge base with customization, (5) Atomic Red Team - test library mapped to ATT&CK for validation, (6) Vectr - purple team tracking with ATT&CK integration, (7) Enterprise SIEM dashboards - Splunk ES, Elastic SIEM have built-in ATT&CK views. Best approach: Export Sigma rule tags to generate Navigator layers automatically, then validate coverage through actual attack simulation.


Instruction: How does Detection Maturity Model work?

Output:
Detection Maturity Model: Detection maturity models assess an organization's detection engineering capabilities across dimensions like coverage, automation, and effectiveness. Common models progress from reactive (signature-based, vendor rules only) through proactive (custom detections, threat-informed) to predictive (behavioral analytics, ML-assisted). Maturity is measured by detection coverage percentage, false positive rates, mean time to detect (MTTD), and automation level. Advancing maturity requires investment in people, process, and technology.

Use cases:
- Assessing current capabilities
- Planning security investments
- Benchmarking against peers
- Tracking improvement over time


Instruction: When should you use Detection Maturity Model?

Output:
Use cases for Detection Maturity Model:

- Assessing current capabilities
- Planning security investments
- Benchmarking against peers
- Tracking improvement over time

Detection maturity models assess an organization's detection engineering capabilities across dimensions like coverage, automation, and effectiveness. Common models progress from reactive (signature-based, vendor rules only) through proactive (custom detections, threat-informed) to predictive (behavioral analytics, ML-assisted). Maturity is measured by detection coverage percentage, false positive rates, mean time to detect (MTTD), and automation level. Advancing maturity requires investment in people, process, and technology.


Instruction: What are recommendations for Detection Maturity Model?

Output:
Best practices for Detection Maturity Model:

- Conduct annual maturity assessments
- Set realistic improvement goals
- Balance investment across people/process/technology
- Measure outcomes not just outputs

Avoid these mistakes:
- Focusing only on tool capabilities
- Not measuring actual detection effectiveness
- Comparing to unrealistic benchmarks


Instruction: What should you avoid when using Detection Maturity Model?

Output:
Common pitfalls with Detection Maturity Model:

- Focusing only on tool capabilities
- Not measuring actual detection effectiveness
- Comparing to unrealistic benchmarks

To avoid these issues:
- Conduct annual maturity assessments
- Set realistic improvement goals
- Balance investment across people/process/technology


Instruction: What are the levels of detection maturity?

Output: Detection maturity typically progresses through these levels: Level 1 - Reactive: Relies on vendor-provided signatures, no custom detections, limited visibility into what's detected, reactive to incidents. Level 2 - Defined: Basic custom detections exist, some documentation, manual deployment, limited testing. Level 3 - Managed: Detection-as-Code practices, version control, regular tuning, ATT&CK alignment, validation testing. Level 4 - Optimized: Automated CI/CD for detections, comprehensive ATT&CK coverage, behavioral analytics, continuous validation, metrics-driven improvement. Level 5 - Predictive: ML-assisted detection, proactive threat hunting feeds detections, near-real-time adaptation to new threats. Most organizations operate at Level 2-3; reaching Level 4+ requires dedicated detection engineering resources.


Instruction: How do you measure detection engineering maturity?

Output: Measuring detection maturity requires metrics across multiple dimensions: Coverage Metrics: ATT&CK technique coverage percentage, detection confidence scores, data source availability. Quality Metrics: False positive rate per rule, alert-to-incident ratio, analyst feedback scores. Speed Metrics: Mean time to detect (MTTD), time from threat intel to detection deployment. Process Metrics: Detections in version control percentage, automated testing coverage, documentation completeness. Operational Metrics: Detection validation frequency, tuning iteration cycle time, detection retirement rate. Assessment approach: Score each dimension 1-5, identify lowest-scoring areas for improvement, set quarterly goals, track progress over time. Tools like DeTT&CT provide structured scoring frameworks.


Instruction: What is Threat-Informed Detection?

Output:
Threat-Informed Detection: Threat-informed detection prioritizes detection development based on actual adversary behavior relevant to the organization. It uses threat intelligence about active campaigns, industry-targeting threat actors, and observed attack patterns to focus limited resources on the most likely threats. This approach contrasts with trying to detect everything, instead detecting what matters most. Sources include commercial threat intel, ISACs, government advisories, and internal incident data.

Use cases:
- Prioritizing detection development
- Responding to emerging threats
- Aligning security with business risk


Instruction: When is Threat-Informed Detection appropriate?

Output:
Use cases for Threat-Informed Detection:

- Prioritizing detection development
- Responding to emerging threats
- Aligning security with business risk

Threat-informed detection prioritizes detection development based on actual adversary behavior relevant to the organization. It uses threat intelligence about active campaigns, industry-targeting threat actors, and observed attack patterns to focus limited resources on the most likely threats. This approach contrasts with trying to detect everything, instead detecting what matters most. Sources include commercial threat intel, ISACs, government advisories, and internal incident data.


Instruction: What are recommendations for Threat-Informed Detection?

Output:
Best practices for Threat-Informed Detection:

- Subscribe to relevant threat intel feeds
- Track threat actors targeting your industry
- Review detections when new campaigns are reported
- Maintain threat actor profiles with TTPs

Avoid these mistakes:
- Chasing every threat without prioritization
- Ignoring threats because 'we're not a target'
- Not operationalizing threat intelligence


Instruction: What mistakes should you avoid with Threat-Informed Detection?

Output:
Common pitfalls with Threat-Informed Detection:

- Chasing every threat without prioritization
- Ignoring threats because 'we're not a target'
- Not operationalizing threat intelligence

To avoid these issues:
- Subscribe to relevant threat intel feeds
- Track threat actors targeting your industry
- Review detections when new campaigns are reported


Instruction: What is threat-informed detection?

Output: Threat-informed detection focuses detection development on threats most relevant to your organization rather than trying to detect everything. Key principles: (1) Know your adversaries - identify threat actors targeting your industry, geography, or organization size, (2) Understand their TTPs - study their specific techniques from threat intelligence reports, (3) Prioritize detection development - build detections for techniques these actors actually use, (4) Update based on intelligence - when new campaigns are reported, validate or create relevant detections, (5) Measure coverage against specific threats - not just generic ATT&CK coverage. Sources of threat intelligence: commercial feeds (Recorded Future, Mandiant), ISACs (FS-ISAC, H-ISAC), government (CISA advisories, FBI flash alerts), open source (MITRE ATT&CK groups), internal incidents. This approach maximizes detection value with limited resources.


Instruction: How do you operationalize threat intelligence for detection?

Output: Operationalizing threat intelligence for detection involves: (1) Intelligence Intake - establish feeds from commercial vendors, ISACs, CISA, and open sources, (2) Relevance Filtering - prioritize intel about actors targeting your industry, region, or technology stack, (3) TTP Extraction - identify specific techniques, tools, and indicators from reports, (4) Detection Mapping - check if existing detections cover identified TTPs, (5) Gap Analysis - identify techniques without detection coverage, (6) Development Sprint - write detections for high-priority gaps, (7) Validation - test new detections with attack simulation, (8) Deployment - push validated detections to production, (9) Feedback Loop - track if detections fire on real activity. Example: APT group report mentions use of certutil for downloads -> verify T1105 detection exists -> test with 'certutil -urlcache' -> confirm alert fires -> document validation.


Instruction: What is Data Sources and Visibility?

Output:
Data Sources and Visibility: Detection effectiveness depends entirely on data availability. No log data means no detection capability. Data sources include endpoint telemetry (process creation, file access, network connections), network data (firewall, proxy, DNS, NetFlow), authentication logs, application logs, and cloud audit trails. Visibility gaps are mapped to MITRE ATT&CK data sources to identify what attacks cannot be detected. Prioritizing data collection based on detection requirements is fundamental to security architecture.

Use cases:
- Planning data collection strategy
- Identifying visibility gaps
- Justifying logging investments
- Architecting SIEM data pipelines


Instruction: When is Data Sources and Visibility appropriate?

Output:
Use cases for Data Sources and Visibility:

- Planning data collection strategy
- Identifying visibility gaps
- Justifying logging investments
- Architecting SIEM data pipelines

Detection effectiveness depends entirely on data availability. No log data means no detection capability. Data sources include endpoint telemetry (process creation, file access, network connections), network data (firewall, proxy, DNS, NetFlow), authentication logs, application logs, and cloud audit trails. Visibility gaps are mapped to MITRE ATT&CK data sources to identify what attacks cannot be detected. Prioritizing data collection based on detection requirements is fundamental to security architecture.


Instruction: How should you implement Data Sources and Visibility?

Output:
Best practices for Data Sources and Visibility:

- Map data sources to ATT&CK techniques
- Validate log completeness regularly
- Prioritize high-value, low-volume sources
- Document data retention requirements

Avoid these mistakes:
- Assuming logs are complete without validation
- Collecting data without detection use cases
- Not considering log storage costs


Instruction: What are common pitfalls with Data Sources and Visibility?

Output:
Common pitfalls with Data Sources and Visibility:

- Assuming logs are complete without validation
- Collecting data without detection use cases
- Not considering log storage costs

To avoid these issues:
- Map data sources to ATT&CK techniques
- Validate log completeness regularly
- Prioritize high-value, low-volume sources


Instruction: What data sources are essential for threat detection?

Output: Essential data sources for comprehensive threat detection include: Endpoint: Process creation (Sysmon Event 1, Windows 4688), file creation/modification, registry changes, network connections, loaded DLLs, PowerShell/script logging. Network: Firewall allow/deny logs, proxy logs with URLs, DNS queries, NetFlow/IPFIX, IDS/IPS alerts, Zeek connection logs. Authentication: Windows Security logs (4624/4625/4648), Linux auth.log, VPN logs, SSO/IdP logs, MFA events. Cloud: AWS CloudTrail, Azure Activity Log, GCP Audit Logs, O365/M365 Unified Audit Log. Application: Web server access logs, database audit logs, email gateway logs. Priority order: Start with authentication and process creation - they cover the most ATT&CK techniques per data source.


Instruction: How do you assess detection visibility gaps?

Output: Assessing visibility gaps requires mapping data sources to detection capabilities: (1) Inventory current data - list all log sources ingested into SIEM with sample events, (2) Map to ATT&CK data sources - use ATT&CK's data source objects to categorize, (3) Identify detection requirements - for each prioritized technique, list required data sources, (4) Gap analysis - compare required vs available data sources, (5) Prioritize collection - rank gaps by technique importance and data collection feasibility. Tools: ATT&CK Navigator can visualize data source coverage, DeTT&CT scores visibility per technique. Common gaps: PowerShell script block logging disabled, Sysmon not deployed, DNS logging not centralized, cloud audit logs not forwarded. Closing gaps requires collaboration with IT operations for logging configuration changes.


Instruction: What is Detection Prioritization Framework?

Output:
Detection Prioritization Framework: With limited resources, organizations must prioritize which detections to develop first. Prioritization frameworks consider factors like threat likelihood (based on threat intel), potential impact (asset criticality, data sensitivity), detection feasibility (data availability, false positive risk), and existing coverage gaps. Common approaches include risk-based scoring matrices, ATT&CK technique frequency analysis, and threat actor TTP prioritization. The goal is maximum risk reduction per engineering hour invested.

Use cases:
- Planning detection development sprints
- Allocating detection engineering resources
- Justifying detection investments


Instruction: When should you use Detection Prioritization Framework?

Output:
Use cases for Detection Prioritization Framework:

- Planning detection development sprints
- Allocating detection engineering resources
- Justifying detection investments

With limited resources, organizations must prioritize which detections to develop first. Prioritization frameworks consider factors like threat likelihood (based on threat intel), potential impact (asset criticality, data sensitivity), detection feasibility (data availability, false positive risk), and existing coverage gaps. Common approaches include risk-based scoring matrices, ATT&CK technique frequency analysis, and threat actor TTP prioritization. The goal is maximum risk reduction per engineering hour invested.


Instruction: What are best practices for Detection Prioritization Framework?

Output:
Best practices for Detection Prioritization Framework:

- Use consistent scoring criteria
- Involve threat intel and risk teams
- Review priorities quarterly
- Document prioritization decisions

Avoid these mistakes:
- Prioritizing based on tool vendor marketing
- Ignoring feasibility constraints
- Not revisiting priorities as threats evolve


Instruction: What goes wrong with Detection Prioritization Framework?

Output:
Common pitfalls with Detection Prioritization Framework:

- Prioritizing based on tool vendor marketing
- Ignoring feasibility constraints
- Not revisiting priorities as threats evolve

To avoid these issues:
- Use consistent scoring criteria
- Involve threat intel and risk teams
- Review priorities quarterly


Instruction: How do you prioritize which detections to build first?

Output: Detection prioritization frameworks typically score these factors: (1) Threat Likelihood (1-5): Is this technique used by actors targeting us? How frequently is it seen in the wild? (2) Impact Potential (1-5): What could an attacker achieve? Does it target crown jewels? (3) Current Coverage (1-5, inverse): Do we have existing detections? How confident are they? (4) Detection Feasibility (1-5): Do we have required data? What's expected false positive rate? Priority Score = (Likelihood × Impact × Coverage Gap) / Feasibility. Example: Credential dumping (T1003) - High likelihood (common technique), High impact (enables lateral movement), Low coverage (no current detection), High feasibility (Sysmon available) = HIGH PRIORITY. Review and adjust scores quarterly based on new threat intelligence and detection effectiveness data.


Instruction: What techniques should every organization detect?

Output: High-priority techniques for universal detection coverage include: Initial Access: T1566 Phishing (email attachment/link execution), T1190 Exploit Public-Facing App (web shell detection). Execution: T1059 Command and Scripting Interpreter (PowerShell, cmd, bash anomalies), T1204 User Execution (Office macro execution). Persistence: T1053 Scheduled Task/Job, T1547 Boot/Logon Autostart. Privilege Escalation: T1068 Exploitation for Privilege Escalation (abnormal service behavior). Defense Evasion: T1562 Impair Defenses (security tool tampering). Credential Access: T1003 OS Credential Dumping (LSASS access), T1110 Brute Force. Discovery: T1087 Account Discovery, T1069 Permission Groups Discovery. Lateral Movement: T1021 Remote Services (anomalous RDP, SMB, WinRM). Collection: T1005 Data from Local System. Exfiltration: T1041 Exfiltration Over C2. These techniques appear across most attack chains regardless of threat actor.


Instruction: How does Detection SLAs and Metrics work?

Output:
Detection SLAs and Metrics: Detection SLAs (Service Level Agreements) define measurable commitments for detection engineering operations. Key metrics include Mean Time to Detect (MTTD) for different threat types, detection coverage percentage against ATT&CK, false positive rates by rule severity, and time from threat intel to deployed detection. Metrics enable data-driven improvement, justify resource allocation, and demonstrate security program effectiveness to stakeholders.

Use cases:
- Measuring detection program effectiveness
- Setting team performance goals
- Reporting to leadership
- Identifying improvement areas


Instruction: What are the use cases for Detection SLAs and Metrics?

Output:
Use cases for Detection SLAs and Metrics:

- Measuring detection program effectiveness
- Setting team performance goals
- Reporting to leadership
- Identifying improvement areas

Detection SLAs (Service Level Agreements) define measurable commitments for detection engineering operations. Key metrics include Mean Time to Detect (MTTD) for different threat types, detection coverage percentage against ATT&CK, false positive rates by rule severity, and time from threat intel to deployed detection. Metrics enable data-driven improvement, justify resource allocation, and demonstrate security program effectiveness to stakeholders.


Instruction: How do you properly use Detection SLAs and Metrics?

Output:
Best practices for Detection SLAs and Metrics:

- Define metrics before measuring
- Automate metric collection where possible
- Set realistic baselines before targets
- Review metrics monthly with the team

Avoid these mistakes:
- Measuring vanity metrics that don't reflect security
- Gaming metrics at the expense of actual security
- Not acting on metric insights


Instruction: What mistakes should you avoid with Detection SLAs and Metrics?

Output:
Common pitfalls with Detection SLAs and Metrics:

- Measuring vanity metrics that don't reflect security
- Gaming metrics at the expense of actual security
- Not acting on metric insights

To avoid these issues:
- Define metrics before measuring
- Automate metric collection where possible
- Set realistic baselines before targets


Instruction: What metrics should detection engineering teams track?

Output: Essential detection engineering metrics include: Coverage Metrics: ATT&CK technique coverage percentage, detection confidence distribution (low/med/high), data source coverage. Quality Metrics: False positive rate by rule and severity, true positive rate (validated detections), alert-to-incident conversion rate. Speed Metrics: Mean Time to Detect (MTTD) by attack type, time from threat intel to detection deployment, detection validation cycle time. Operational Metrics: Number of active detections, detections added/retired per month, detection review backlog. Efficiency Metrics: Analyst time per alert triage, automated vs manual alert handling ratio, detection development velocity. Business Metrics: Security incidents detected internally vs externally reported, dwell time trends. Start with 3-5 metrics, establish baselines, then set improvement targets.


Instruction: How do you calculate Mean Time to Detect (MTTD)?

Output: Mean Time to Detect (MTTD) measures the average time between when an attack begins and when it's detected. Calculation: MTTD = Sum of (Detection Timestamp - Attack Start Timestamp) / Number of Incidents. Challenges: Attack start time is often unknown; use compromise indicators like initial access time from forensics. Approaches: (1) Purple team exercises - measure time from red team action to blue team alert, (2) Breach simulations - track detection of simulated attacks with known start times, (3) Incident forensics - estimate initial compromise time from investigation findings. Segmentation: Calculate MTTD by attack type (ransomware, data theft, etc.), technique category (initial access, lateral movement), and detection source (EDR, SIEM, NDR). Industry benchmarks: Average dwell time (similar to MTTD for undetected breaches) ranges from weeks to months. Goal is continuous reduction toward real-time detection for critical techniques.


Instruction: How does Continuous Detection Improvement work?

Output:
Continuous Detection Improvement: Continuous improvement in detection engineering applies iterative refinement based on feedback loops. Sources of feedback include alert outcomes (true/false positive classification), incident investigations revealing detection gaps, threat intelligence about new TTPs, purple team exercises testing detection effectiveness, and analyst feedback on rule quality. The improvement cycle involves measuring current performance, identifying gaps, implementing changes, and validating results.

Use cases:
- Maturing detection capabilities
- Responding to detection failures
- Optimizing SOC efficiency


Instruction: When is Continuous Detection Improvement appropriate?

Output:
Use cases for Continuous Detection Improvement:

- Maturing detection capabilities
- Responding to detection failures
- Optimizing SOC efficiency

Continuous improvement in detection engineering applies iterative refinement based on feedback loops. Sources of feedback include alert outcomes (true/false positive classification), incident investigations revealing detection gaps, threat intelligence about new TTPs, purple team exercises testing detection effectiveness, and analyst feedback on rule quality. The improvement cycle involves measuring current performance, identifying gaps, implementing changes, and validating results.


Instruction: How should you implement Continuous Detection Improvement?

Output:
Best practices for Continuous Detection Improvement:

- Hold weekly detection review meetings
- Track feedback-to-improvement cycle time
- Celebrate detection successes
- Conduct blameless reviews of detection failures

Avoid these mistakes:
- Not closing the feedback loop
- Treating detections as 'done' after deployment
- Blaming analysts for detection failures


Instruction: What are common pitfalls with Continuous Detection Improvement?

Output:
Common pitfalls with Continuous Detection Improvement:

- Not closing the feedback loop
- Treating detections as 'done' after deployment
- Blaming analysts for detection failures

To avoid these issues:
- Hold weekly detection review meetings
- Track feedback-to-improvement cycle time
- Celebrate detection successes


Instruction: How do you continuously improve detection capabilities?

Output: Continuous detection improvement requires systematic feedback loops: (1) Alert Outcome Tracking - analysts classify alerts as TP/FP, feeding rule-level metrics, (2) Incident Gap Analysis - every incident triggers review of why detection succeeded or failed, (3) Purple Team Feedback - regular exercises identify detection blind spots, (4) Threat Intel Integration - new TTP reports trigger detection coverage review, (5) Analyst Feedback - regular input on rule quality, documentation, and false positives. Improvement Process: Weekly tuning reviews address top false positive generators, Monthly detection effectiveness reviews assess coverage metrics, Quarterly portfolio reviews retire ineffective rules and plan new development. Metrics to track: Detection improvement cycle time (feedback to fix), False positive reduction trends, Coverage gap closure rate. Culture: Treat detection failures as learning opportunities, not blame events.


Instruction: What should happen when a detection fails to catch an attack?

Output: When detection fails (attack not detected), conduct a blameless review: (1) Immediate Actions: Document what happened, identify how attack was eventually discovered, assess impact. (2) Root Cause Analysis: Did detection exist? If yes, why didn't it fire? (rule logic flaw, data gap, evasion technique). If no detection existed, was it a known gap? (3) Data Review: Was required telemetry available? Were logs complete? Any ingestion delays? (4) Detection Gap Closure: Develop or fix detection for the specific technique used, test with attack replay or simulation, deploy with monitoring. (5) Similar Gap Assessment: Are there related techniques also undetected? (6) Documentation: Update detection portfolio, record lessons learned, share with team. (7) Process Improvement: What systematic changes prevent similar failures? (better threat intel integration, expanded testing). Timeline: Complete initial review within 48 hours, deploy detection fix within 1 week.


Instruction: Describe Sigma Rule Format for detection engineering.

Output:
Sigma Rule Format: Sigma is a generic signature format for SIEM systems, allowing detection rules to be written once and converted to multiple platforms. Rules are written in YAML format with standardized fields: title, status, description, logsource, detection, and metadata fields. The format enables sharing detections across organizations and SIEM products. Sigma rules are converted to platform-specific queries using backends (Splunk, Elastic, Microsoft Sentinel, etc.).

Use cases:
- Cross-platform detection sharing
- Detection-as-Code workflows
- Community detection collaboration


Instruction: How do you write Sigma Rule Format?

Output:
Syntax for Sigma Rule Format:

```
title: Rule Title
status: experimental|test|stable
description: What this rule detects
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4688
    condition: selection
level: medium
tags:
    - attack.execution
    - attack.t1059
```

Sigma is a generic signature format for SIEM systems, allowing detection rules to be written once and converted to multiple platforms. Rules are written in YAML format with standardized fields: title, status, description, logsource, detection, and metadata fields. The format enables sharing detections across organizations and SIEM products. Sigma rules are converted to platform-specific queries using backends (Splunk, Elastic, Microsoft Sentinel, etc.).


Instruction: Give a practical example of Sigma Rule Format.

Output:
Example of Sigma Rule Format:

```
title: Suspicious PowerShell Encoded Command
status: test
description: Detects PowerShell execution with encoded command parameter
author: Security Team
date: 2024/01/15
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4688
        CommandLine|contains|all:
            - 'powershell'
            - '-e'
    condition: selection
falsepositives:
    - Legitimate administrative scripts
level: high
tags:
    - attack.execution
    - attack.t1059.001
```

Sigma is a generic signature format for SIEM systems, allowing detection rules to be written once and converted to multiple platforms. Rules are written in YAML format with standardized fields: title, status, description, logsource, detection, and metadata fields. The format enables sharing detections across organizations and SIEM products. Sigma rules are converted to platform-specific queries using backends (Splunk, Elastic, Microsoft Sentinel, etc.).


Instruction: What are the use cases for Sigma Rule Format?

Output:
Use cases for Sigma Rule Format:

- Cross-platform detection sharing
- Detection-as-Code workflows
- Community detection collaboration

Sigma is a generic signature format for SIEM systems, allowing detection rules to be written once and converted to multiple platforms. Rules are written in YAML format with standardized fields: title, status, description, logsource, detection, and metadata fields. The format enables sharing detections across organizations and SIEM products. Sigma rules are converted to platform-specific queries using backends (Splunk, Elastic, Microsoft Sentinel, etc.).


Instruction: What are recommendations for Sigma Rule Format?

Output:
Best practices for Sigma Rule Format:

- Use consistent naming conventions
- Include comprehensive metadata
- Test rules before sharing
- Map to MITRE ATT&CK

Avoid these mistakes:
- Inconsistent field naming
- Missing logsource specification
- Overly complex conditions


Instruction: What mistakes should you avoid with Sigma Rule Format?

Output:
Common pitfalls with Sigma Rule Format:

- Inconsistent field naming
- Missing logsource specification
- Overly complex conditions

To avoid these issues:
- Use consistent naming conventions
- Include comprehensive metadata
- Test rules before sharing


Instruction: What is Sigma and how does it work?

Output: Sigma is a generic and open signature format for SIEM systems, often called 'the YARA for logs.' Key features: (1) Platform-agnostic - rules written in YAML can be converted to Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, and 30+ other formats, (2) Standardized structure - consistent fields for title, logsource, detection logic, and metadata, (3) Community-driven - large repository of shared rules (SigmaHQ), (4) Version controlled - rules work in Detection-as-Code workflows. Workflow: Write rule in Sigma YAML -> Use pySigma or sigma-cli to convert -> Deploy converted query to target SIEM. Example: A rule detecting encoded PowerShell can be written once and deployed to Splunk, Elastic, and Sentinel without rewriting the logic for each platform.


Instruction: What are the required fields in a Sigma rule?

Output: Required Sigma rule fields are: (1) title - unique, descriptive name for the rule, (2) logsource - specifies what logs the rule applies to (product, service, category), (3) detection - the actual detection logic with selections and conditions. Strongly recommended fields: (4) status - rule maturity (experimental, test, stable), (5) description - human-readable explanation, (6) level - alert severity (informational, low, medium, high, critical), (7) author - rule creator, (8) date - creation/modification date. Optional but valuable: (9) tags - MITRE ATT&CK mappings, (10) falsepositives - known FP scenarios, (11) references - links to threat intel or documentation. Complete metadata improves rule quality, enables filtering, and helps analysts understand context.


Instruction: What do security professionals need to know about Sigma Title Field?

Output:
Sigma Title Field: The title field is a short, unique, descriptive name for the Sigma rule. It should clearly indicate what the rule detects without being overly long. Titles follow conventions like starting with the detection target (e.g., 'PowerShell', 'LSASS') followed by the suspicious behavior. Good titles enable quick understanding during alert triage and rule management.

Use cases:
- Rule identification
- Alert display
- Rule searching


Instruction: How do you write Sigma Title Field?

Output:
Syntax for Sigma Title Field:

```
title: Suspicious Process Creation from Office Application
```

The title field is a short, unique, descriptive name for the Sigma rule. It should clearly indicate what the rule detects without being overly long. Titles follow conventions like starting with the detection target (e.g., 'PowerShell', 'LSASS') followed by the suspicious behavior. Good titles enable quick understanding during alert triage and rule management.


Instruction: What are the use cases for Sigma Title Field?

Output:
Use cases for Sigma Title Field:

- Rule identification
- Alert display
- Rule searching

The title field is a short, unique, descriptive name for the Sigma rule. It should clearly indicate what the rule detects without being overly long. Titles follow conventions like starting with the detection target (e.g., 'PowerShell', 'LSASS') followed by the suspicious behavior. Good titles enable quick understanding during alert triage and rule management.


Instruction: How do you properly use Sigma Title Field?

Output:
Best practices for Sigma Title Field:

- Start with the detection subject
- Be specific but concise
- Use consistent naming patterns
- Avoid generic titles like 'Malicious Activity'

Avoid these mistakes:
- Overly generic titles
- Inconsistent naming conventions
- Titles that don't match actual detection


Instruction: What goes wrong with Sigma Title Field?

Output:
Common pitfalls with Sigma Title Field:

- Overly generic titles
- Inconsistent naming conventions
- Titles that don't match actual detection

To avoid these issues:
- Start with the detection subject
- Be specific but concise
- Use consistent naming patterns


Instruction: How should Sigma rule titles be written?

Output: Sigma rule titles should be: (1) Descriptive - clearly indicate what is detected (not just 'Suspicious Activity'), (2) Concise - typically 5-10 words, (3) Consistent - follow a pattern like '[Subject] [Suspicious Behavior]', (4) Specific - 'Encoded PowerShell via Scheduled Task' is better than 'PowerShell Detection'. Naming conventions: Start with detection target (tool/process/technique), Follow with suspicious characteristic, Include context if needed (e.g., 'via WMI'). Examples: Good: 'LSASS Memory Dump via Procdump', 'Certutil URL Download', 'Suspicious Parent-Child Process Relationship'. Bad: 'Malware Detection', 'Bad Activity', 'Rule 47'. Consistent titles enable efficient rule management and clear alert displays.


Instruction: How does Sigma Status Field work?

Output:
Sigma Status Field: The status field indicates the maturity and reliability of a Sigma rule. Values are: 'experimental' for new, untested rules; 'test' for rules being validated in production; 'stable' for production-ready, well-tested rules; 'deprecated' for rules being phased out. Status helps prioritize which rules to deploy and how much tuning to expect.

Use cases:
- Rule lifecycle management
- Deployment decisions
- Quality filtering


Instruction: How do you write Sigma Status Field?

Output:
Syntax for Sigma Status Field:

```
status: experimental|test|stable|deprecated
```

The status field indicates the maturity and reliability of a Sigma rule. Values are: 'experimental' for new, untested rules; 'test' for rules being validated in production; 'stable' for production-ready, well-tested rules; 'deprecated' for rules being phased out. Status helps prioritize which rules to deploy and how much tuning to expect.


Instruction: When should you use Sigma Status Field?

Output:
Use cases for Sigma Status Field:

- Rule lifecycle management
- Deployment decisions
- Quality filtering

The status field indicates the maturity and reliability of a Sigma rule. Values are: 'experimental' for new, untested rules; 'test' for rules being validated in production; 'stable' for production-ready, well-tested rules; 'deprecated' for rules being phased out. Status helps prioritize which rules to deploy and how much tuning to expect.


Instruction: What are best practices for Sigma Status Field?

Output:
Best practices for Sigma Status Field:

- Start new rules as experimental
- Promote to test after lab validation
- Only mark stable after production tuning
- Deprecate rather than delete

Avoid these mistakes:
- Deploying experimental rules to production alerts
- Never updating status as rules mature
- No process for status transitions


Instruction: What should you avoid when using Sigma Status Field?

Output:
Common pitfalls with Sigma Status Field:

- Deploying experimental rules to production alerts
- Never updating status as rules mature
- No process for status transitions

To avoid these issues:
- Start new rules as experimental
- Promote to test after lab validation
- Only mark stable after production tuning


Instruction: What do Sigma status values mean?

Output: Sigma status values indicate rule maturity: (1) experimental - newly created, not yet tested, may have high false positives, use for research/development only, (2) test - validated in lab, being tested in production environment, may need tuning, (3) stable - production-ready, well-tested, acceptable false positive rate, suitable for alerting, (4) deprecated - rule is being phased out, may be replaced or no longer relevant. Status workflow: New rule -> experimental -> test after lab validation -> stable after production tuning. Deployment guidance: Experimental rules can log but not alert, Test rules alert to detection engineers for validation, Stable rules alert to SOC for response. Status enables filtering: only deploy 'stable' rules for critical alerting, include 'test' for broader monitoring.


Instruction: How do you manage Sigma rule lifecycle?

Output: Sigma rule lifecycle management involves: (1) Creation (experimental): Write rule based on threat intel or incident findings, basic testing against sample logs. (2) Lab Validation (experimental->test): Test against attack simulations (Atomic Red Team), verify correct log source targeting, check for obvious false positives. (3) Production Testing (test): Deploy to production with logging (not alerting), collect true/false positive data, tune as needed. (4) Production Release (test->stable): After acceptable FP rate achieved, enable alerting, document known FPs. (5) Maintenance (stable): Regular review, tuning based on feedback, update for new evasions. (6) Retirement (stable->deprecated): When rule no longer relevant or replaced, deprecate with documentation. Track status changes in version control commit messages.


Instruction: How does Sigma Logsource Field work?

Output:
Sigma Logsource Field: The logsource field specifies which log data the Sigma rule should be applied to. It uses three sub-fields: 'product' (the system generating logs, e.g., windows, linux, aws), 'service' (the specific log type, e.g., security, sysmon, cloudtrail), and 'category' (abstract log type like process_creation, network_connection). Proper logsource specification ensures rules are converted correctly for different SIEM backends.

Use cases:
- Targeting specific log types
- Backend conversion accuracy
- Rule applicability filtering


Instruction: How do you write Sigma Logsource Field?

Output:
Syntax for Sigma Logsource Field:

```
logsource:
    product: windows
    service: sysmon
    category: process_creation
```

The logsource field specifies which log data the Sigma rule should be applied to. It uses three sub-fields: 'product' (the system generating logs, e.g., windows, linux, aws), 'service' (the specific log type, e.g., security, sysmon, cloudtrail), and 'category' (abstract log type like process_creation, network_connection). Proper logsource specification ensures rules are converted correctly for different SIEM backends.


Instruction: Show an example of Sigma Logsource Field.

Output:
Example of Sigma Logsource Field:

```
# Windows Security Event Log
logsource:
    product: windows
    service: security

# Sysmon Process Creation
logsource:
    product: windows
    service: sysmon
    category: process_creation

# Linux auditd
logsource:
    product: linux
    service: auditd

# AWS CloudTrail
logsource:
    product: aws
    service: cloudtrail
```

The logsource field specifies which log data the Sigma rule should be applied to. It uses three sub-fields: 'product' (the system generating logs, e.g., windows, linux, aws), 'service' (the specific log type, e.g., security, sysmon, cloudtrail), and 'category' (abstract log type like process_creation, network_connection). Proper logsource specification ensures rules are converted correctly for different SIEM backends.


Instruction: What problems does Sigma Logsource Field solve?

Output:
Use cases for Sigma Logsource Field:

- Targeting specific log types
- Backend conversion accuracy
- Rule applicability filtering

The logsource field specifies which log data the Sigma rule should be applied to. It uses three sub-fields: 'product' (the system generating logs, e.g., windows, linux, aws), 'service' (the specific log type, e.g., security, sysmon, cloudtrail), and 'category' (abstract log type like process_creation, network_connection). Proper logsource specification ensures rules are converted correctly for different SIEM backends.


Instruction: What are recommendations for Sigma Logsource Field?

Output:
Best practices for Sigma Logsource Field:

- Be as specific as possible
- Use category for abstract matching
- Test conversion with target backend
- Document log requirements

Avoid these mistakes:
- Missing logsource causes conversion failures
- Overly broad logsource matches wrong logs
- Inconsistent category usage


Instruction: What mistakes should you avoid with Sigma Logsource Field?

Output:
Common pitfalls with Sigma Logsource Field:

- Missing logsource causes conversion failures
- Overly broad logsource matches wrong logs
- Inconsistent category usage

To avoid these issues:
- Be as specific as possible
- Use category for abstract matching
- Test conversion with target backend


Instruction: How do Sigma logsource fields work?

Output: Sigma logsource fields specify which logs a rule applies to: (1) product - the system or platform generating logs: windows, linux, macos, aws, azure, gcp, etc. (2) service - specific log source within the product: security (Windows Security Event Log), sysmon (Sysmon events), powershell (PowerShell logs), cloudtrail (AWS CloudTrail), etc. (3) category - abstract log type that works across products: process_creation, network_connection, file_event, dns_query. Hierarchy: product is most general, service is specific, category enables cross-platform rules. Example: A process_creation category rule can match Windows Sysmon Event 1 and Linux auditd EXECVE. Backend converters use logsource to generate appropriate index/source filters in the target query language.


Instruction: What are common Sigma logsource combinations?

Output: Common Sigma logsource combinations include: Windows Process Creation: product: windows, category: process_creation (matches Sysmon 1 or Security 4688). Windows Security Events: product: windows, service: security (Security.evtx events). Windows Sysmon: product: windows, service: sysmon (all Sysmon events). Windows PowerShell: product: windows, service: powershell (Script Block Logging). Linux Process: product: linux, category: process_creation (auditd EXECVE). Linux Auth: product: linux, service: auth (auth.log/secure). AWS CloudTrail: product: aws, service: cloudtrail. Azure Activity: product: azure, service: activitylogs. Firewall: category: firewall (generic network allow/deny). Proxy: category: proxy (web proxy logs). DNS: category: dns (DNS query logs). Use specific service when targeting known log type, use category for portable rules.


Instruction: Describe Sigma Detection Block for detection engineering.

Output:
Sigma Detection Block: The detection block contains the actual detection logic in a Sigma rule. It consists of named selections (search criteria) and a condition that combines them. Selections define what to match using field names and values. The condition specifies how selections combine using boolean logic (and, or, not). This structure separates 'what to look for' from 'how to combine matches' for clarity and maintainability.

Use cases:
- Defining match criteria
- Combining multiple conditions
- Excluding false positives


Instruction: What is the syntax for Sigma Detection Block?

Output:
Syntax for Sigma Detection Block:

```
detection:
    selection:
        EventID: 4688
        CommandLine|contains: 'mimikatz'
    filter:
        User: 'SYSTEM'
    condition: selection and not filter
```

The detection block contains the actual detection logic in a Sigma rule. It consists of named selections (search criteria) and a condition that combines them. Selections define what to match using field names and values. The condition specifies how selections combine using boolean logic (and, or, not). This structure separates 'what to look for' from 'how to combine matches' for clarity and maintainability.


Instruction: What does Sigma Detection Block look like in practice?

Output:
Example of Sigma Detection Block:

```
detection:
    selection_process:
        EventID: 1
        Image|endswith: '\\powershell.exe'
    selection_commandline:
        CommandLine|contains|all:
            - '-enc'
            - '-nop'
    filter_legitimate:
        ParentImage|endswith:
            - '\\sccm.exe'
            - '\\intune.exe'
    condition: selection_process and selection_commandline and not filter_legitimate
```

The detection block contains the actual detection logic in a Sigma rule. It consists of named selections (search criteria) and a condition that combines them. Selections define what to match using field names and values. The condition specifies how selections combine using boolean logic (and, or, not). This structure separates 'what to look for' from 'how to combine matches' for clarity and maintainability.


Instruction: What problems does Sigma Detection Block solve?

Output:
Use cases for Sigma Detection Block:

- Defining match criteria
- Combining multiple conditions
- Excluding false positives

The detection block contains the actual detection logic in a Sigma rule. It consists of named selections (search criteria) and a condition that combines them. Selections define what to match using field names and values. The condition specifies how selections combine using boolean logic (and, or, not). This structure separates 'what to look for' from 'how to combine matches' for clarity and maintainability.


Instruction: How do you properly use Sigma Detection Block?

Output:
Best practices for Sigma Detection Block:

- Use descriptive selection names
- Separate positive matches from filters
- Keep conditions readable
- Test each selection independently

Avoid these mistakes:
- Overly complex conditions
- Mixing selection and filter logic
- Not testing filter effectiveness


Instruction: What mistakes should you avoid with Sigma Detection Block?

Output:
Common pitfalls with Sigma Detection Block:

- Overly complex conditions
- Mixing selection and filter logic
- Not testing filter effectiveness

To avoid these issues:
- Use descriptive selection names
- Separate positive matches from filters
- Keep conditions readable


Instruction: How does the Sigma detection block work?

Output: The Sigma detection block defines what to detect: (1) Selections - named sets of field:value pairs that define match criteria. Multiple selections can exist with descriptive names (selection_process, selection_cmdline). (2) Filters - selections used to exclude false positives (typically prefixed with 'filter_'). (3) Condition - boolean expression combining selections using 'and', 'or', 'not', and parentheses. Structure: detection: [selections] [filters] condition: [boolean expression]. Example: selection matches PowerShell execution, filter excludes known management tools, condition is 'selection and not filter'. The separation of selections from conditions enables: clear logic documentation, easy modification of individual criteria, reusable selection patterns. Keep selections focused on single concepts for maintainability.


Instruction: How do you write effective Sigma detection conditions?

Output: Effective Sigma conditions balance detection and precision: Simple condition: 'condition: selection' - fires when selection matches. AND logic: 'condition: selection1 and selection2' - requires both to match, more specific. OR logic: 'condition: selection1 or selection2' - fires on either match, broader coverage. Exclusions: 'condition: selection and not filter' - matches selection but excludes filter matches. Complex: 'condition: (selection1 or selection2) and not (filter1 or filter2)' - use parentheses for clarity. Aggregation: 'condition: selection | count() > 10' - threshold-based detection. Best practices: Name selections descriptively (selection_encoded_cmd not selection1), Put false positive exclusions in clearly named filters, Use parentheses even when not strictly required for readability, Test condition logic with sample events before deployment.


Instruction: What do security professionals need to know about Sigma Level Field?

Output:
Sigma Level Field: The level field indicates the severity or criticality of a Sigma rule alert. Values range from 'informational' (logging only, no action needed) through 'low', 'medium', 'high', to 'critical' (requires immediate response). Level helps SOC analysts prioritize alert response and enables automated alert routing. Level should reflect actual risk based on technique severity and confidence in detection accuracy.

Use cases:
- Alert prioritization
- SLA determination
- Automated response triggering
- Dashboard filtering


Instruction: What is the syntax for Sigma Level Field?

Output:
Syntax for Sigma Level Field:

```
level: informational|low|medium|high|critical
```

The level field indicates the severity or criticality of a Sigma rule alert. Values range from 'informational' (logging only, no action needed) through 'low', 'medium', 'high', to 'critical' (requires immediate response). Level helps SOC analysts prioritize alert response and enables automated alert routing. Level should reflect actual risk based on technique severity and confidence in detection accuracy.


Instruction: When is Sigma Level Field appropriate?

Output:
Use cases for Sigma Level Field:

- Alert prioritization
- SLA determination
- Automated response triggering
- Dashboard filtering

The level field indicates the severity or criticality of a Sigma rule alert. Values range from 'informational' (logging only, no action needed) through 'low', 'medium', 'high', to 'critical' (requires immediate response). Level helps SOC analysts prioritize alert response and enables automated alert routing. Level should reflect actual risk based on technique severity and confidence in detection accuracy.


Instruction: How should you implement Sigma Level Field?

Output:
Best practices for Sigma Level Field:

- Base level on actual risk, not detection complexity
- Consider both technique severity and detection confidence
- Be conservative - high FP rules should be lower level
- Review levels during tuning

Avoid these mistakes:
- Everything marked high/critical causes fatigue
- Not considering false positive impact
- Inconsistent level assignment across rules


Instruction: What are common pitfalls with Sigma Level Field?

Output:
Common pitfalls with Sigma Level Field:

- Everything marked high/critical causes fatigue
- Not considering false positive impact
- Inconsistent level assignment across rules

To avoid these issues:
- Base level on actual risk, not detection complexity
- Consider both technique severity and detection confidence
- Be conservative - high FP rules should be lower level


Instruction: How should Sigma rule levels be assigned?

Output: Sigma rule levels should reflect actionable risk: (1) informational - interesting for context, no action required, suitable for enrichment or hunting (e.g., successful admin login). (2) low - minor suspicious activity, routine review, low impact if true (e.g., unusual but not malicious process). (3) medium - moderate suspicion, should be investigated, potential security impact (e.g., encoded PowerShell execution). (4) high - strong indicator of malicious activity, prompt investigation required (e.g., credential dumping tool execution). (5) critical - high-confidence detection of severe threat, immediate response required (e.g., ransomware execution indicators). Factors: Technique severity (credential theft > recon), Detection confidence (specific IOC > behavioral pattern), False positive rate (high FP = lower level), Asset criticality (critical systems may warrant higher levels). Start conservative, increase level after tuning proves reliability.


Instruction: How do rule levels affect SOC operations?

Output: Rule levels drive SOC operational processes: Response SLAs: Critical - 15 minutes, High - 1 hour, Medium - 4 hours, Low - 24 hours, Informational - review during hunting. Alert Routing: Critical/High -> Tier 2/3 analysts directly, Medium -> Tier 1 initial triage, Low/Informational -> automated processing or batch review. Automation: Critical/High may trigger automated containment, Medium may trigger automated enrichment, Low/Informational may be auto-closed with logging. Dashboards: Filter views by level for focused monitoring. Escalation: Level determines initial escalation path. Metrics: Track alert volume and outcomes by level to identify tuning needs. Common issue: Too many high/critical alerts cause same fatigue as too many total alerts. Solution: Reserve high/critical for truly urgent detections, tune FP-prone rules to lower levels until stable.


Instruction: Explain Sigma Tags Field.

Output:
Sigma Tags Field: The tags field in Sigma provides metadata labels for categorization, primarily MITRE ATT&CK mappings. Tags use dot notation: 'attack.execution' for tactics, 'attack.t1059.001' for techniques. Tags enable filtering rules by ATT&CK coverage, generating coverage reports, and organizing detection portfolios. Additional tag namespaces include 'cve.' for vulnerability-based detections and custom organizational prefixes.

Use cases:
- ATT&CK coverage mapping
- Rule categorization
- Portfolio filtering
- Coverage reporting


Instruction: Show the format for Sigma Tags Field.

Output:
Syntax for Sigma Tags Field:

```
tags:
    - attack.execution
    - attack.t1059.001
    - attack.defense_evasion
    - attack.t1027
    - cve.2021.44228
```

The tags field in Sigma provides metadata labels for categorization, primarily MITRE ATT&CK mappings. Tags use dot notation: 'attack.execution' for tactics, 'attack.t1059.001' for techniques. Tags enable filtering rules by ATT&CK coverage, generating coverage reports, and organizing detection portfolios. Additional tag namespaces include 'cve.' for vulnerability-based detections and custom organizational prefixes.


Instruction: What problems does Sigma Tags Field solve?

Output:
Use cases for Sigma Tags Field:

- ATT&CK coverage mapping
- Rule categorization
- Portfolio filtering
- Coverage reporting

The tags field in Sigma provides metadata labels for categorization, primarily MITRE ATT&CK mappings. Tags use dot notation: 'attack.execution' for tactics, 'attack.t1059.001' for techniques. Tags enable filtering rules by ATT&CK coverage, generating coverage reports, and organizing detection portfolios. Additional tag namespaces include 'cve.' for vulnerability-based detections and custom organizational prefixes.


Instruction: What are best practices for Sigma Tags Field?

Output:
Best practices for Sigma Tags Field:

- Map to specific sub-techniques when possible
- Include all relevant techniques (multi-tag)
- Use lowercase consistently
- Validate tags against ATT&CK

Avoid these mistakes:
- Missing ATT&CK mappings
- Incorrect technique IDs
- Only mapping to tactics without techniques


Instruction: What are common pitfalls with Sigma Tags Field?

Output:
Common pitfalls with Sigma Tags Field:

- Missing ATT&CK mappings
- Incorrect technique IDs
- Only mapping to tactics without techniques

To avoid these issues:
- Map to specific sub-techniques when possible
- Include all relevant techniques (multi-tag)
- Use lowercase consistently


Instruction: How do you map Sigma rules to MITRE ATT&CK?

Output: Mapping Sigma rules to ATT&CK uses the tags field: Format: 'attack.[tactic]' for tactics, 'attack.t[technique_id]' for techniques. Examples: attack.execution (tactic), attack.t1059 (technique), attack.t1059.001 (sub-technique for PowerShell). Process: (1) Identify what behavior the rule detects, (2) Find matching ATT&CK technique(s), (3) Add tags for tactic and technique(s), (4) Prefer sub-techniques over parent techniques when specific. Multi-mapping: Rules often map to multiple techniques - include all relevant tags. Example encoded PowerShell rule: tags: attack.execution, attack.t1059.001 (Command and Scripting Interpreter: PowerShell), attack.defense_evasion, attack.t1027 (Obfuscated Files). Validation: Use ATT&CK Navigator to verify technique IDs, review mappings during rule reviews.


Instruction: What tag namespaces are used in Sigma?

Output: Sigma tag namespaces organize metadata: (1) attack.* - MITRE ATT&CK mappings: attack.initial_access (tactic), attack.t1566 (technique), attack.t1566.001 (sub-technique). (2) cve.* - vulnerability-based detections: cve.2021.44228 (Log4Shell), cve.2023.23397 (Outlook elevation). (3) detection.* - detection method classification: detection.emerging_threats, detection.threat_hunting. (4) car.* - MITRE Cyber Analytics Repository references. (5) Custom namespaces - organizations can add: org.critical_asset, org.pci_scope. Best practices: Always include attack.* tags for ATT&CK coverage, Add cve.* when rule detects specific vulnerability exploitation, Use consistent custom namespace prefixes. Tag queries: Sigma tools can filter rules by tags, enabling deployment of technique-specific rule sets or coverage analysis.


Instruction: Describe Sigma Falsepositives Field for detection engineering.

Output:
Sigma Falsepositives Field: The falsepositives field documents known scenarios that may trigger the rule without actual malicious activity. This guidance helps analysts quickly identify and dismiss benign triggers during triage. Good false positive documentation includes specific applications, user behaviors, or system processes that legitimately exhibit the detected behavior. This field improves rule usability and reduces time wasted investigating known benign patterns.

Use cases:
- Analyst triage guidance
- Tuning documentation
- Rule quality assessment


Instruction: How do you write Sigma Falsepositives Field?

Output:
Syntax for Sigma Falsepositives Field:

```
falsepositives:
    - Administrative PowerShell scripts
    - Software deployment tools (SCCM, Intune)
    - Legitimate use of certutil for certificate management
```

The falsepositives field documents known scenarios that may trigger the rule without actual malicious activity. This guidance helps analysts quickly identify and dismiss benign triggers during triage. Good false positive documentation includes specific applications, user behaviors, or system processes that legitimately exhibit the detected behavior. This field improves rule usability and reduces time wasted investigating known benign patterns.


Instruction: When should you use Sigma Falsepositives Field?

Output:
Use cases for Sigma Falsepositives Field:

- Analyst triage guidance
- Tuning documentation
- Rule quality assessment

The falsepositives field documents known scenarios that may trigger the rule without actual malicious activity. This guidance helps analysts quickly identify and dismiss benign triggers during triage. Good false positive documentation includes specific applications, user behaviors, or system processes that legitimately exhibit the detected behavior. This field improves rule usability and reduces time wasted investigating known benign patterns.


Instruction: How do you properly use Sigma Falsepositives Field?

Output:
Best practices for Sigma Falsepositives Field:

- Be specific about FP scenarios
- Update as new FPs are discovered
- Include affected systems/users if known
- Reference filter logic where applicable

Avoid these mistakes:
- Generic 'legitimate admin activity' without specifics
- Not updating after production deployment
- Documenting FPs but not adding filters


Instruction: What should you avoid when using Sigma Falsepositives Field?

Output:
Common pitfalls with Sigma Falsepositives Field:

- Generic 'legitimate admin activity' without specifics
- Not updating after production deployment
- Documenting FPs but not adding filters

To avoid these issues:
- Be specific about FP scenarios
- Update as new FPs are discovered
- Include affected systems/users if known


Instruction: How should false positives be documented in Sigma?

Output: Effective false positive documentation in Sigma includes: (1) Specific applications - name exact tools that trigger (e.g., 'SCCM client software deployment' not just 'admin tools'), (2) User contexts - which users/roles legitimately trigger (e.g., 'IT helpdesk running remote support tools'), (3) System contexts - specific systems where behavior is normal (e.g., 'Jump servers used for administration'), (4) Frequency guidance - 'common' vs 'rare' false positives, (5) Verification steps - how to confirm if alert is FP (e.g., 'verify parent process is legitimate management tool'). Example: falsepositives: - 'SCCM client (CcmExec.exe) deploying software packages' - 'Intune management extension performing compliance checks' - 'IT administrators using encoded PowerShell for complex scripts - verify with IT ticket'. Update falsepositives field when new FP patterns emerge in production.


Instruction: When should false positives be filtered vs documented?

Output: Decision framework for FP handling: Filter in rule (add to filter section) when: (1) FP source is highly consistent and predictable, (2) FP volume is high enough to cause alert fatigue, (3) FP can be precisely identified without over-excluding, (4) Risk of filtering malicious activity is low. Document only (falsepositives field) when: (1) FP is rare or inconsistent, (2) Cannot reliably filter without missing attacks, (3) Analyst judgment needed to verify benign, (4) Still want visibility for hunting purposes. Both (filter AND document): Filter common cases, document the filtering logic and edge cases. Example: Encoded PowerShell from SCCM -> filter by ParentImage containing 'ccmexec', document 'SCCM software deployment' in falsepositives. Rare encoded PowerShell from admin scripts -> document 'administrative scripts' but don't filter, let analysts verify.


Instruction: Explain Sigma References Field.

Output:
Sigma References Field: The references field provides URLs to external documentation supporting the detection rule. This includes threat intelligence reports, vendor advisories, attack technique documentation, and related Sigma rules. References help analysts understand the threat context, validate rule purpose, and investigate alerts effectively. Good references connect detection logic to real-world threats.

Use cases:
- Threat context for analysts
- Rule validation
- Investigation guidance
- Attribution to sources


Instruction: Show the format for Sigma References Field.

Output:
Syntax for Sigma References Field:

```
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://blog.example.com/threat-report
    - https://docs.microsoft.com/security-advisory
```

The references field provides URLs to external documentation supporting the detection rule. This includes threat intelligence reports, vendor advisories, attack technique documentation, and related Sigma rules. References help analysts understand the threat context, validate rule purpose, and investigate alerts effectively. Good references connect detection logic to real-world threats.


Instruction: What problems does Sigma References Field solve?

Output:
Use cases for Sigma References Field:

- Threat context for analysts
- Rule validation
- Investigation guidance
- Attribution to sources

The references field provides URLs to external documentation supporting the detection rule. This includes threat intelligence reports, vendor advisories, attack technique documentation, and related Sigma rules. References help analysts understand the threat context, validate rule purpose, and investigate alerts effectively. Good references connect detection logic to real-world threats.


Instruction: What are recommendations for Sigma References Field?

Output:
Best practices for Sigma References Field:

- Include ATT&CK technique links
- Reference original threat research
- Use stable URLs (avoid URL shorteners)
- Keep references current

Avoid these mistakes:
- Broken links over time
- Referencing paywalled content
- No references at all


Instruction: What should you avoid when using Sigma References Field?

Output:
Common pitfalls with Sigma References Field:

- Broken links over time
- Referencing paywalled content
- No references at all

To avoid these issues:
- Include ATT&CK technique links
- Reference original threat research
- Use stable URLs (avoid URL shorteners)


Instruction: What should be included in Sigma rule references?

Output: Sigma rule references should include: (1) MITRE ATT&CK links - technique pages provide context on adversary use (https://attack.mitre.org/techniques/T1059/001/), (2) Threat intelligence - reports describing campaigns using the technique (vendor blogs, government advisories), (3) Technical documentation - Microsoft docs, tool documentation explaining legitimate vs malicious use, (4) Related rules - links to complementary Sigma rules or detection strategies, (5) Original research - if rule is based on specific research, credit the source. Reference priorities: Always include ATT&CK link for mapped techniques, Include source that inspired the rule, Add investigation guidance resources. Example references for encoded PowerShell: - https://attack.mitre.org/techniques/T1059/001/ - https://www.fireeye.com/blog/threat-research/powershell-obfuscation - https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_powershell_exe


Instruction: How do references help during alert investigation?

Output: References accelerate alert investigation by providing: (1) Threat Context - understanding why behavior is suspicious, what attacks use this technique, what the attacker's goal might be, (2) Verification Criteria - knowing what legitimate use looks like vs malicious, specific indicators to check, (3) Pivot Points - additional IOCs to search for, related techniques to investigate, (4) Escalation Justification - documentation supporting why alert warrants escalation, (5) Historical Context - previous incidents, campaigns, or actors using the technique. Investigation workflow: Alert fires -> analyst reads description -> checks references for context -> uses ATT&CK link to understand technique -> reviews threat intel for campaign indicators -> makes informed triage decision. Well-referenced rules reduce investigation time and improve decision quality.


Instruction: What is Sigma Rule Organization?

Output:
Sigma Rule Organization: Organizing Sigma rules in a repository enables efficient management at scale. Common structures include folders by log source (windows/, linux/, cloud/), by ATT&CK tactic (execution/, persistence/), or by rule status (production/, testing/). Naming conventions, metadata standards, and documentation requirements ensure consistency. Large organizations may maintain thousands of rules requiring systematic organization.

Use cases:
- Managing large rule portfolios
- Team collaboration
- Deployment automation
- Rule discovery


Instruction: What is the syntax for Sigma Rule Organization?

Output:
Syntax for Sigma Rule Organization:

```
# Repository structure example
sigma-rules/
├── rules/
│   ├── windows/
│   │   ├── process_creation/
│   │   ├── security/
│   │   └── sysmon/
│   ├── linux/
│   │   ├── auditd/
│   │   └── syslog/
│   ├── cloud/
│   │   ├── aws/
│   │   ├── azure/
│   │   └── gcp/
│   └── network/
├── tests/
├── config/
└── README.md
```

Organizing Sigma rules in a repository enables efficient management at scale. Common structures include folders by log source (windows/, linux/, cloud/), by ATT&CK tactic (execution/, persistence/), or by rule status (production/, testing/). Naming conventions, metadata standards, and documentation requirements ensure consistency. Large organizations may maintain thousands of rules requiring systematic organization.


Instruction: What problems does Sigma Rule Organization solve?

Output:
Use cases for Sigma Rule Organization:

- Managing large rule portfolios
- Team collaboration
- Deployment automation
- Rule discovery

Organizing Sigma rules in a repository enables efficient management at scale. Common structures include folders by log source (windows/, linux/, cloud/), by ATT&CK tactic (execution/, persistence/), or by rule status (production/, testing/). Naming conventions, metadata standards, and documentation requirements ensure consistency. Large organizations may maintain thousands of rules requiring systematic organization.


Instruction: What are recommendations for Sigma Rule Organization?

Output:
Best practices for Sigma Rule Organization:

- Use consistent folder structure
- Include README documentation
- Maintain rule naming conventions
- Separate custom rules from community rules

Avoid these mistakes:
- No organization leads to duplicate rules
- Mixing production and test rules
- No documentation of structure


Instruction: What mistakes should you avoid with Sigma Rule Organization?

Output:
Common pitfalls with Sigma Rule Organization:

- No organization leads to duplicate rules
- Mixing production and test rules
- No documentation of structure

To avoid these issues:
- Use consistent folder structure
- Include README documentation
- Maintain rule naming conventions


Instruction: How should Sigma rules be organized in a repository?

Output: Effective Sigma repository organization: Folder Structure Options: (1) By log source (recommended for deployment): rules/windows/process_creation/, rules/linux/auditd/, rules/cloud/aws/. (2) By ATT&CK tactic: rules/initial_access/, rules/execution/, rules/persistence/. (3) Hybrid: rules/windows/execution/, combining both. Supporting folders: tests/ for rule validation test cases, config/ for backend conversion configs, documentation/ for guides. File Naming: descriptive_name.yml, use lowercase with underscores, include log source in name if not obvious from path. Metadata Files: Include README.md explaining structure, CONTRIBUTING.md for rule submission guidelines. Separation: Keep custom rules separate from community rules (SigmaHQ) for easier updates. Example: rules/windows/process_creation/encoded_powershell_execution.yml


Instruction: How do you manage Sigma rules from multiple sources?

Output: Managing Sigma rules from multiple sources requires: (1) Source Separation - maintain distinct folders: rules/sigmahq/ (community), rules/custom/ (internal), rules/vendor/ (commercial feeds). (2) Update Strategy - for SigmaHQ: git submodule or periodic sync with review, don't modify community rules directly. (3) Customization Layer - create custom versions in separate folder referencing original, document modifications. (4) Deduplication - check for overlapping detections between sources, prefer higher-quality version. (5) Metadata Tracking - add custom field indicating source: 'custom_source: sigmahq' or 'custom_source: internal-threat-intel'. (6) Version Tracking - track rule versions and updates, especially for community rules that change. (7) Quality Gates - apply consistent testing regardless of source before production. SigmaHQ integration: Fork repo, regularly merge upstream, maintain custom modifications in separate branch or folder.


Instruction: Explain Sigma String Matching.

Output:
Sigma String Matching: Sigma provides multiple string matching methods using modifiers appended to field names with the pipe character. The 'contains' modifier matches substrings anywhere in the field. The 'startswith' modifier matches prefixes. The 'endswith' modifier matches suffixes. Without modifiers, fields match exactly. These modifiers enable flexible pattern matching while maintaining readability.

Use cases:
- Matching process paths
- Finding command line arguments
- Detecting file extensions


Instruction: What is the structure of Sigma String Matching?

Output:
Syntax for Sigma String Matching:

```
# Exact match
CommandLine: 'whoami'

# Contains (substring)
CommandLine|contains: 'mimikatz'

# Starts with (prefix)
Image|startswith: 'C:\\Windows\\Temp\\'

# Ends with (suffix)
Image|endswith: '\\powershell.exe'
```

Sigma provides multiple string matching methods using modifiers appended to field names with the pipe character. The 'contains' modifier matches substrings anywhere in the field. The 'startswith' modifier matches prefixes. The 'endswith' modifier matches suffixes. Without modifiers, fields match exactly. These modifiers enable flexible pattern matching while maintaining readability.


Instruction: Give a practical example of Sigma String Matching.

Output:
Example of Sigma String Matching:

```
detection:
    selection:
        EventID: 1
        Image|endswith: '\\cmd.exe'
        CommandLine|contains|all:
            - 'whoami'
            - '/all'
    condition: selection
```

Sigma provides multiple string matching methods using modifiers appended to field names with the pipe character. The 'contains' modifier matches substrings anywhere in the field. The 'startswith' modifier matches prefixes. The 'endswith' modifier matches suffixes. Without modifiers, fields match exactly. These modifiers enable flexible pattern matching while maintaining readability.


Instruction: When should you use Sigma String Matching?

Output:
Use cases for Sigma String Matching:

- Matching process paths
- Finding command line arguments
- Detecting file extensions

Sigma provides multiple string matching methods using modifiers appended to field names with the pipe character. The 'contains' modifier matches substrings anywhere in the field. The 'startswith' modifier matches prefixes. The 'endswith' modifier matches suffixes. Without modifiers, fields match exactly. These modifiers enable flexible pattern matching while maintaining readability.


Instruction: How should you implement Sigma String Matching?

Output:
Best practices for Sigma String Matching:

- Use endswith for process names to avoid path variations
- Use contains for command arguments
- Be specific to reduce false positives

Avoid these mistakes:
- Forgetting case sensitivity varies by backend
- Overly broad contains patterns
- Not escaping backslashes in paths


Instruction: What mistakes should you avoid with Sigma String Matching?

Output:
Common pitfalls with Sigma String Matching:

- Forgetting case sensitivity varies by backend
- Overly broad contains patterns
- Not escaping backslashes in paths

To avoid these issues:
- Use endswith for process names to avoid path variations
- Use contains for command arguments
- Be specific to reduce false positives