Project 18: MITRE Coverage Mapping

Map detection coverage to MITRE rootkit techniques.

Quick Reference

Attribute Value
Difficulty Level 2
Time Estimate Weekend
Main Programming Language Python (Alternatives: Python, PowerShell)
Alternative Programming Languages Python, PowerShell
Coolness Level Level 3
Business Potential Level 2
Prerequisites OS internals basics, CLI usage, logging familiarity
Key Topics MITRE mapping, coverage

1. Learning Objectives

By completing this project, you will:

  1. Build a repeatable workflow for mitre coverage mapping.
  2. Generate reports with deterministic outputs.
  3. Translate findings into actionable recommendations.

2. All Theory Needed (Per-Concept Breakdown)

Kernel Telemetry and Detection Engineering

Fundamentals Detection engineering turns low-level system events into actionable alerts. For rootkit defense, the highest-value signals are kernel events: driver loads, module signature failures, boot integrity changes, and kernel tampering indicators. Telemetry must be normalized across platforms to support consistent detection logic. The key challenge is balancing sensitivity with noise: rules must trigger on real risk without causing alert fatigue.

Deep Dive into the concept Kernel telemetry differs from application logging because it is closer to the trust boundary. Events like a driver load or a signature verification failure are rare in healthy systems and often indicate privilege boundary changes. Detection engineering starts with identifying these high-signal events and then mapping them to actionable rules. For example, a rule might trigger when an unsigned driver loads or when Secure Boot is disabled.

Normalization is critical in cross-platform environments. Windows provides events via ETW, Sysmon, and the Windows Event Log. Linux offers auditd, kernel logs, and eBPF-based sensors. macOS exposes unified logs and endpoint security framework events. A detection pipeline should map these diverse sources to a common schema: event type, subject, object, outcome, and context. This enables rule reuse and consistent reporting.

Rule quality depends on context. A driver load during patch windows may be benign; the same event outside a maintenance window may be suspicious. Detection logic should incorporate context such as time, known update processes, and asset criticality. For rootkit defense, rules should focus on integrity violations: signature failures, unexpected boot configuration changes, or kernel module loads from unusual paths.

Testing is mandatory. In a lab, you should simulate the target events (e.g., attempt to load an unsigned driver) and verify that your rules detect them without excessive false positives. Rules should be versioned, documented, and accompanied by response playbooks. The final output is not just alerts but an operational detection program that can be audited.

How this fit on projects You will apply this in Section 3.2 (Functional Requirements), Section 6.1 (Test Categories), and Section 7.2 (Debugging Strategies). Also used in: P11-network-stealth-detection, P15-kernel-event-monitoring-rules, P18-mitre-coverage-mapping.

Definitions & key terms

  • Telemetry: Collected system events used for detection and monitoring.
  • Normalization: Mapping diverse events into a consistent schema.
  • Rule: A detection condition that triggers an alert when matched.
  • Alert fatigue: Operational risk of too many low-quality alerts.

Mental model diagram

[Kernel Event Sources] -> [Normalizer] -> [Rule Engine] -> [Alert] -> [Response]

How it works (step-by-step)

  1. Collect kernel-level events from OS-specific sources.
  2. Normalize fields into a common schema.
  3. Apply detection rules for high-signal events.
  4. Tune rules based on noise and maintenance context.
  5. Validate with lab simulations and document playbooks.

Minimal concrete example

rule: unsigned_driver_load
if event.type == DRIVER_LOAD and event.signature == "unsigned" then alert

Common misconceptions

  • “More rules mean better coverage.” Quality and context matter more than quantity.
  • “Kernel events are always malicious.” Many are normal during updates or drivers installation.
  • “Normalization removes detail.” It should preserve original fields for context.

Check-your-understanding questions

  • Why is normalization essential in cross-platform detection?
  • What makes a kernel event high-signal?
  • How do you validate a new detection rule?

Check-your-understanding answers

  • It allows consistent rules across different event sources.
  • It is rare, tied to privilege boundaries, and strongly correlated with risk.
  • Simulate the event in a lab and verify alert behavior and noise.

Real-world applications

  • EDR detection rules for kernel module loads.
  • Security operations playbooks for boot integrity changes.

Where you’ll apply it You will apply this in Section 3.2 (Functional Requirements), Section 6.1 (Test Categories), and Section 7.2 (Debugging Strategies). Also used in: P11-network-stealth-detection, P15-kernel-event-monitoring-rules, P18-mitre-coverage-mapping.

References

  • MITRE ATT&CK detection guidance
  • Sysmon and auditd documentation

Key insights Detection rules are only as good as their signal quality and validation.

Summary Normalize kernel events, focus on high-signal conditions, and test thoroughly.

Homework/Exercises to practice the concept

  • Map two kernel events from different OSes into a common schema.
  • Write a rule for unsigned driver load and test it in a lab.

Solutions to the homework/exercises

  • Your mapping should preserve actor, object, and outcome fields.
  • A lab test should show an alert when an unsigned module is loaded.

Policy and Governance for Boot Integrity

Fundamentals Policy turns technical controls into enforceable expectations. Secure Boot and integrity checks are only effective when an organization defines who must enable them, how compliance is verified, and what exceptions are allowed. Governance adds accountability: changes to boot policies require approval and documentation. Rootkit defense depends on this because boot integrity is a systemic property; one weak system can compromise the whole fleet.

Deep Dive into the concept A Secure Boot policy should specify required states, validation procedures, and exceptions. For example, the policy may require Secure Boot enabled on all production endpoints, with exceptions for lab systems that are isolated. The policy should define how compliance is verified: scripts, MDM checks, or periodic audits.

Governance means defining ownership. Who approves disabling Secure Boot? Who reviews exceptions? A strong policy includes controls such as time-limited exceptions, compensating measures (e.g., additional monitoring), and documented approvals. Without governance, exceptions accumulate and become the default.

Policy must also address updates and key management. Secure Boot relies on key databases; if these are not updated, revoked binaries may still be accepted. An effective policy defines how key updates are applied, how revocations are tracked, and how new devices are onboarded. It should also consider cross-platform differences: Windows, Linux, macOS, and BSD implement boot integrity differently. The policy should reflect those nuances rather than being overly generic.

Finally, policy should be auditable. Reports must show compliance at a point in time, with evidence. These reports are not only for security teams; they are also for auditors, risk managers, and leadership. A policy that cannot be measured is not enforceable.

How this fit on projects You will apply this in Section 3.3 (Non-Functional Requirements), Section 9.1 (Industry Applications), and Section 10.1 (Essential Reading). Also used in: P18-mitre-coverage-mapping, P19-secure-boot-policy-review.

Definitions & key terms

  • Policy: Documented rules that define required security controls and exceptions.
  • Governance: Oversight processes that ensure policies are followed and reviewed.
  • Compliance evidence: Artifacts that prove a system meets policy requirements.
  • Exception: Approved deviation from policy with compensating controls.

Mental model diagram

[Policy Requirements] -> [Verification Process] -> [Compliance Report]
           |                              |
           v                              v
    [Exceptions + Approvals]       [Audit / Review]

How it works (step-by-step)

  1. Define required boot integrity states for each platform.
  2. Implement verification checks and reporting scripts.
  3. Document exception criteria and approval workflow.
  4. Review compliance regularly and update policy when needed.

Minimal concrete example

Policy: Secure Boot must be enabled on all Windows endpoints.
Exception: Lab VMs isolated from production may disable Secure Boot with CISO approval.
Evidence: Monthly compliance report exported to CSV.

Common misconceptions

  • “Policy is just documentation.” Without enforcement and evidence, it is ineffective.
  • “One policy fits all OSes.” Platform differences require tailored checks.
  • “Exceptions are rare.” Without governance, exceptions accumulate quickly.

Check-your-understanding questions

  • Why are exceptions risky if not time-limited?
  • What evidence proves Secure Boot compliance?
  • How do you handle platforms with different boot integrity models?

Check-your-understanding answers

  • They become permanent weak points and erode the policy’s effectiveness.
  • Reports showing firmware state, key databases, and verification logs.
  • Define platform-specific checks and map them to a unified policy goal.

Real-world applications

  • Enterprise compliance programs for device security baselines.
  • Audit preparation for regulated environments.

Where you’ll apply it You will apply this in Section 3.3 (Non-Functional Requirements), Section 9.1 (Industry Applications), and Section 10.1 (Essential Reading). Also used in: P18-mitre-coverage-mapping, P19-secure-boot-policy-review.

References

  • NIST SP 800-53 (Security and Privacy Controls)
  • CIS Benchmarks for platform-specific boot integrity settings

Key insights Policy without verification is a suggestion, not a control.

Summary Define requirements, verify compliance, and govern exceptions.

Homework/Exercises to practice the concept

  • Draft a Secure Boot policy for two OSes in your environment.
  • Define evidence you would present to an auditor.

Solutions to the homework/exercises

  • Your policy should specify required states and exception criteria per OS.
  • Evidence should include scripts outputs and inventory reports.

3. Project Specification

3.1 What You Will Build

A tool or document that delivers: Map detection coverage to MITRE rootkit techniques.

3.2 Functional Requirements

  1. Collect required system artifacts for the task.
  2. Normalize data and produce a report output.
  3. Provide a deterministic golden-path demo.
  4. Include explicit failure handling and exit codes.

3.3 Non-Functional Requirements

  • Performance: Complete within a typical maintenance window.
  • Reliability: Outputs must be deterministic and versioned.
  • Usability: Clear CLI output and documentation.

3.4 Example Usage / Output

$ ./P18-mitre-coverage-mapping.py --report
[ok] report generated

3.5 Data Formats / Schemas / Protocols

Report JSON schema with fields: timestamp, host, findings, severity, remediation.

3.6 Edge Cases

  • Missing permissions or insufficient privileges.
  • Tooling not installed (e.g., missing sysctl or OS query tools).
  • Empty data sets (no drivers/modules found).

3.7 Real World Outcome

A deterministic report output stored in a case directory with hashes.

3.7.1 How to Run (Copy/Paste)

./P18-mitre-coverage-mapping.py --out reports/P18-mitre-coverage-mapping.json

3.7.2 Golden Path Demo (Deterministic)

  • Report file exists and includes findings with severity.

3.7.3 Failure Demo

$ ./P18-mitre-coverage-mapping.py --out /readonly/report.json
[error] cannot write report file
exit code: 2

Exit Codes:

  • 0 success
  • 2 output error

4. Solution Architecture

4.1 High-Level Design

[Collector] -> [Analyzer] -> [Report]

4.2 Key Components

Component Responsibility Key Decisions
Collector Collects raw artifacts Prefer OS-native tools
Analyzer Normalizes and scores findings Deterministic rules
Reporter Outputs report JSON + Markdown

4.3 Data Structures (No Full Code)

finding = { id, description, severity, evidence, remediation }

4.4 Algorithm Overview

Key Algorithm: Normalize and Score

  1. Collect artifacts.
  2. Normalize fields.
  3. Apply scoring rules.
  4. Output report.

Complexity Analysis:

  • Time: O(n) for n artifacts.
  • Space: O(n) for report.

5. Implementation Guide

5.1 Development Environment Setup

python3 -m venv .venv && source .venv/bin/activate
# install OS-specific tools as needed

5.2 Project Structure

project/
|-- src/
|   `-- main.py
|-- reports/
`-- README.md

5.3 The Core Question You’re Answering

“Where are your detection blind spots?”

This project turns theory into a repeatable, auditable workflow.

5.4 Concepts You Must Understand First

  • Relevant OS security controls
  • Detection workflows
  • Evidence handling

5.5 Questions to Guide Your Design

  1. What data sources are trusted for this task?
  2. How will you normalize differences across OS versions?
  3. What is a high-confidence signal vs noise?

5.6 Thinking Exercise

Sketch a pipeline from data collection to report output.

5.7 The Interview Questions They’ll Ask

  1. What is the main trust boundary in this project?
  2. How do you validate findings?
  3. What would you automate in production?

5.8 Hints in Layers

Hint 1: Start with a small, deterministic dataset.

Hint 2: Normalize output fields early.

Hint 3: Add a failure path with clear exit codes.

5.9 Books That Will Help

Topic Book Chapter
Rootkit defense Practical Malware Analysis Rootkit chapters
OS internals Operating Systems: Three Easy Pieces Processes and files

5.10 Implementation Phases

Phase 1: Data Collection (3-4 days)

Goals: Collect raw artifacts reliably.

Tasks:

  1. Identify OS-native tools.
  2. Capture sample data.

Checkpoint: Raw dataset stored.

Phase 2: Analysis & Reporting (4-5 days)

Goals: Normalize and score findings.

Tasks:

  1. Build analyzer.
  2. Generate report.

Checkpoint: Deterministic report generated.

Phase 3: Validation (2-3 days)

Goals: Validate rules and handle edge cases.

Tasks:

  1. Add failure tests.
  2. Document runbook.

Checkpoint: Failure cases documented.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Report format JSON, CSV JSON Structured and diffable
Scoring Simple, Weighted Weighted Prioritize high risk findings

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Parser logic Sample data parsing
Integration Tests End-to-end run Generate report
Edge Case Tests Missing permissions Error path

6.2 Critical Test Cases

  1. Report generated with deterministic ordering.
  2. Exit code indicates failure on invalid output path.
  3. At least one high-risk finding is flagged in test data.

6.3 Test Data

Provide a small fixture file with one known suspicious artifact.

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Noisy results Too many alerts Add normalization and thresholds
Missing permissions Script fails Detect and warn early

7.2 Debugging Strategies

  • Log raw inputs before normalization.
  • Add verbose mode to show rule evaluation.

7.3 Performance Traps

Scanning large datasets without filtering can be slow; restrict scope to critical paths.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a Markdown summary report.

8.2 Intermediate Extensions

  • Add a JSON schema validator for output.

8.3 Advanced Extensions

  • Integrate with a SIEM or ticketing system.

9. Real-World Connections

9.1 Industry Applications

  • Security operations audits and detection validation.
  • osquery - endpoint inventory

9.3 Interview Relevance

  • Discussing detection workflows and auditability.

10. Resources

10.1 Essential Reading

  • Practical Malware Analysis - rootkit detection chapters

10.2 Video Resources

  • Conference talks on rootkit detection

10.3 Tools & Documentation

  • OS-native logging and audit tools

11. Self-Assessment Checklist

11.1 Understanding

  • I can describe the trust boundary for this task.

11.2 Implementation

  • Report generation is deterministic.

11.3 Growth

  • I can explain how to operationalize this check.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Report created and contains at least one finding.

Full Completion:

  • Findings are categorized with remediation guidance.

Excellence (Going Above & Beyond):

  • Integrated into a broader toolkit or pipeline.