Project 12: Enterprise SELinux Security Platform

Build a centralized platform that collects SELinux telemetry, detects drift, and recommends remediation at fleet scale.

Quick Reference

Attribute Value
Difficulty Level 4: Expert
Time Estimate 4-8 weeks
Main Programming Language Python or Go
Alternative Programming Languages Rust
Coolness Level Level 5
Business Potential 4
Prerequisites Projects 1-9, log pipeline basics, distributed systems fundamentals
Key Topics telemetry pipelines, policy drift, remediation automation, analytics

1. Learning Objectives

By completing this project, you will:

  1. Collect and normalize SELinux AVC logs from multiple hosts.
  2. Build a policy drift and compliance detection pipeline.
  3. Provide remediation recommendations with risk scoring.
  4. Design a dashboard that summarizes SELinux health at scale.
  5. Implement a safe, auditable remediation workflow.

2. All Theory Needed (Per-Concept Breakdown)

Distributed Log Collection and Normalization

Fundamentals

A fleet-wide SELinux platform requires reliable log collection and normalization. AVC logs are produced on each host and must be shipped to a central system. Because log formats and policy versions vary, raw logs must be normalized into a common schema. This enables consistent analysis and aggregation across the fleet. Understanding log pipelines, buffering, and schema normalization is essential for this project.

Deep Dive into the concept

Distributed log collection is an engineering discipline. Each host emits AVC records to a local file or journald stream. To aggregate them, you need an agent that reads the logs, applies basic parsing, and forwards them to a central pipeline. The pipeline must be reliable: logs should not be lost during network failures, and duplicates should be handled gracefully. This requires buffering on the host (spooling to disk) and acknowledgment-based delivery. You can implement this with lightweight agents that batch logs and send them to a message broker like Kafka or to a centralized log service. For this project, a simpler approach is to use a queue with local persistence, but the principles are the same.

Normalization is critical because AVC records include policy-specific type names, varying field orders, and optional fields. Your platform should parse key fields (scontext, tcontext, tclass, perms, comm, path, pid, host) and store them in a structured schema. Normalize contexts into separate fields (user, role, type, level). Store a canonical “denial key” that can be used to group identical denials across hosts. Include the policy version and SELinux mode in each record so you can filter by configuration.

Once normalized, the log stream becomes a dataset you can query. You can compute top denials by domain, identify new denials introduced after a deployment, and detect hosts with unusual patterns. But normalization must also handle missing fields. For example, some AVCs do not include a path. Your schema should allow path to be null and still group by type and class. This is why a structured schema is better than raw text search.

Finally, you need a retention strategy. Storing all AVC logs forever is expensive and not always necessary. Define a retention policy (e.g., 30 days raw logs, 1 year aggregated metrics). Your platform should separate raw event storage from aggregated metrics. This allows long-term trend analysis while controlling storage costs.

Additional operational notes on Distributed Log Collection and Normalization: In real systems, this concept interacts with policy versions, distribution defaults, and local overrides. Always record the exact policy version and runtime toggles when diagnosing behavior, because the same action can be allowed on one host and denied on another. When you change configuration related to this concept, capture before/after evidence (labels, logs, and outcomes) so you can justify the change, detect regressions, and roll it back if needed. Treat every tweak as a hypothesis: change one variable, re-run the same action, and compare results against a known baseline. This makes debugging repeatable and keeps your fixes defensible.

From a design perspective, treat Distributed Log Collection and Normalization as an invariant: define what success means, which data proves it, and what failure looks like. Build tooling that supports dry-run mode and deterministic fixtures so you can validate behavior without risking production. This also makes the concept teachable to others. Finally, connect the concept to security and performance trade-offs: overly broad changes reduce security signal, while overly strict changes create operational friction. Good designs surface these trade-offs explicitly so operators can make safe decisions.

How this fit on projects

Log collection is central to §3.2 and §3.7. It builds directly on P02-avc-denial-analyzer-auto-fixer.md.

Definitions & key terms

  • agent -> host-level log shipper
  • normalization -> mapping raw logs to canonical schema
  • denial key -> canonical grouping key for AVCs
  • retention -> log storage lifecycle

Mental model diagram

host AVC logs -> agent -> queue -> normalizer -> analytics store

How it works (step-by-step, with invariants and failure modes)

  1. Agent tails AVC logs and batches events.
  2. Events are shipped to a queue.
  3. Normalizer parses and writes to storage.
  4. Analytics queries aggregated data.

Invariants: events are immutable; normalization produces stable keys. Failure modes: dropped logs, duplicate delivery, schema drift.

Minimal concrete example

{"host":"web-01","scontext_type":"httpd_t","tcontext_type":"user_home_t","tclass":"file","perms":["read"]}

Common misconceptions

  • “Raw logs are enough.” -> Without normalization, aggregation is unreliable.
  • “Centralized logging is just storage.” -> It requires delivery guarantees and schema design.

Check-your-understanding questions

  1. Why is normalization required for fleet analytics?
  2. What is a denial key?
  3. How do you handle missing fields in AVC logs?

Check-your-understanding answers

  1. Because log formats vary and consistent queries require structured fields.
  2. A canonical representation of a denial (domain, target, class, perms).
  3. Allow nulls and group using other fields.

Real-world applications

  • Enterprise security operations and monitoring.
  • Compliance reporting for SELinux enforcement.

Where you’ll apply it

References

  • “Fundamentals of Software Architecture” (observability)
  • Red Hat SELinux Guide (audit logs)

Key insights

Fleet-scale SELinux analysis starts with reliable log normalization.

Summary

Distributed log collection requires agents, queues, and normalized schemas to make AVCs analyzable at scale.

Homework/Exercises to practice the concept

  1. Define a JSON schema for normalized AVC logs.
  2. Write a parser for three AVC log examples.
  3. Design a retention policy for raw vs aggregated logs.

Solutions to the homework/exercises

  1. Include host, timestamp, scontext type, tcontext type, class, perms, path.
  2. Parse key=value pairs into the schema.
  3. Keep raw logs 30 days, aggregated metrics 1 year.

Policy Drift and Compliance Detection

Fundamentals

Policy drift occurs when SELinux settings diverge from the approved baseline. This includes changes in booleans, custom modules, and file context rules. A fleet platform must detect drift by comparing each host’s state to a baseline and reporting deviations. This is the compliance core of the platform.

Deep Dive into the concept

Drift detection requires baseline definition. A baseline includes the expected SELinux mode, policy version, booleans, and critical fcontext rules. Your platform should capture this baseline once and use it as a reference. For each host, you collect current state: sestatus, boolean list, module list, and key fcontext mappings. You then compare to the baseline and record differences. For example, if a host is in permissive mode or has httpd_can_network_connect enabled when the baseline says it should be off, that is a drift event.

Detecting drift is not only about booleans. Policy modules can be added or removed, and their priorities can override base rules. Your platform should store module lists and compare them to baseline. It should also use policy diffing (as in P08) to detect changes in allow or neverallow rules for critical domains. This gives a deeper insight into security posture beyond simple configuration toggles.

File context drift is also important. A host might have custom semanage fcontext rules or mislabeled files. While scanning entire filesystems across a fleet is expensive, you can target critical paths (e.g., /etc, /var/www, /var/log). Use periodic scans or integrate with your selctxcheck tool. The results should be aggregated and compared to baseline expectations.

A good compliance engine produces three outputs: a per-host compliance status, a list of deviations with severity, and a remediation suggestion. Severity should be based on the risk of the drift. For example, permissive mode is critical; a minor file label mismatch might be medium. This helps operations prioritize fixes. Compliance results should also be timestamped and versioned, so you can track trends over time.

Operational expansion for Policy Drift and Compliance Detection: In real systems, the behavior you observe is the product of policy, labels, and runtime state. That means your investigation workflow must be repeatable. Start by documenting the exact inputs (contexts, paths, users, domains, ports, and the action attempted) and the exact outputs (audit events, error codes, and any policy query results). Then, replay the same action after each change so you can attribute cause and effect. When the concept touches multiple subsystems, isolate variables: change one label, one boolean, or one rule at a time. This reduces confusion and prevents accidental privilege creep. Use staging environments or fixtures to test fixes before deploying them widely, and always keep a rollback path ready.

To deepen understanding, connect Policy Drift and Compliance Detection to adjacent concepts: how it affects policy decisions, how it appears in logs, and how it changes operational risk. Build small verification scripts that assert the expected outcome and fail loudly if the outcome diverges. Over time, these scripts become a regression suite for your SELinux posture. Finally, treat the concept as documentation-worthy: write down the invariants it guarantees, the constraints it imposes, and the exact evidence that proves it works. This makes future debugging faster and creates a shared mental model for teams.

Supplemental note for Policy Drift and Compliance Detection: ensure your documentation includes a minimal reproducible example and a known-good output snapshot. Pair this with a small checklist of preconditions and postconditions so anyone rerunning the exercise can validate the result quickly. This turns the concept into a repeatable experiment rather than a one-off intuition.

How this fit on projects

Log collection is central to §3.2 and §3.7. It builds directly on P02-avc-denial-analyzer-auto-fixer.md.

Further depth on Policy Drift and Compliance Detection: In production environments, this concept is shaped by policy versions, automation layers, and distro-specific defaults. To keep reasoning consistent, capture a minimal evidence bundle every time you analyze behavior: the policy name/version, the exact labels or contexts involved, the command that triggered the action, and the resulting audit event. If the same action yields different decisions on two hosts, treat that as a signal that a hidden variable changed (boolean state, module priority, label drift, or category range). This disciplined approach prevents trial-and-error debugging and makes your conclusions defensible.

Operationally, build a short checklist for Policy Drift and Compliance Detection: verify prerequisites, verify labels or mappings, verify policy query results, then run the action and confirm the expected audit outcome. Track metrics that reflect stability, such as the count of denials per hour, the number of unique denial keys, or the fraction of hosts in compliance. When you must change behavior, apply the smallest change that can be verified (label fix before boolean, boolean before policy). Document the rollback path and include a post-change validation step so the system returns to a known-good state.

Definitions & key terms

  • agent -> host-level log shipper
  • normalization -> mapping raw logs to canonical schema
  • denial key -> canonical grouping key for AVCs
  • retention -> log storage lifecycle

Mental model diagram

host AVC logs -> agent -> queue -> normalizer -> analytics store

How it works (step-by-step, with invariants and failure modes)

  1. Agent tails AVC logs and batches events.
  2. Events are shipped to a queue.
  3. Normalizer parses and writes to storage.
  4. Analytics queries aggregated data.

Invariants: events are immutable; normalization produces stable keys. Failure modes: dropped logs, duplicate delivery, schema drift.

Minimal concrete example

{"host":"web-01","scontext_type":"httpd_t","tcontext_type":"user_home_t","tclass":"file","perms":["read"]}

Common misconceptions

  • “Raw logs are enough.” -> Without normalization, aggregation is unreliable.
  • “Centralized logging is just storage.” -> It requires delivery guarantees and schema design.

Check-your-understanding questions

  1. Why is normalization required for fleet analytics?
  2. What is a denial key?
  3. How do you handle missing fields in AVC logs?

Check-your-understanding answers

  1. Because log formats vary and consistent queries require structured fields.
  2. A canonical representation of a denial (domain, target, class, perms).
  3. Allow nulls and group using other fields.

Real-world applications

  • Enterprise security operations and monitoring.
  • Compliance reporting for SELinux enforcement.

Where you’ll apply it

References

  • “Fundamentals of Software Architecture” (observability)
  • Red Hat SELinux Guide (audit logs)

Key insights

Fleet-scale SELinux analysis starts with reliable log normalization.

Summary

Distributed log collection requires agents, queues, and normalized schemas to make AVCs analyzable at scale.

Homework/Exercises to practice the concept

  1. Define a JSON schema for normalized AVC logs.
  2. Write a parser for three AVC log examples.
  3. Design a retention policy for raw vs aggregated logs.

Solutions to the homework/exercises

  1. Include host, timestamp, scontext type, tcontext type, class, perms, path.
  2. Parse key=value pairs into the schema.
  3. Keep raw logs 30 days, aggregated metrics 1 year.

Remediation Workflow and Risk Scoring

Fundamentals

A platform should not only detect issues but also recommend safe fixes. Remediation must be risk-aware: label fixes are safer than policy changes; booleans are safer than new allow rules. This concept focuses on building a remediation workflow that prioritizes low-risk fixes and requires review for high-risk ones.

Deep Dive into the concept

Remediation is a pipeline: detect, classify, propose, approve, and apply. The classification step uses the same taxonomy as P02: label, boolean, or policy. The platform should first look for labeling mismatches using expected labels. If found, propose semanage fcontext and restorecon fixes. If not, search for relevant booleans and recommend enabling them. Only if neither applies should the platform suggest a policy module change, and those should be marked as high risk and require human approval.

Risk scoring should be deterministic and explainable. For example, access to shadow_t or security_t should be critical. Allowing write permissions is higher risk than read. Domains such as unconfined_t or init_t should be treated as higher risk sources. Combine these factors into a score and map to categories (low, medium, high, critical). This score should be visible in the UI and used for alerting thresholds.

Approval workflows are essential. The platform should generate remediation recommendations but not apply them automatically unless explicitly approved. You can implement a simple approval flow: recommendations are created with status pending, and an operator can approve them, after which an agent applies the change. Every step should be logged for auditability. This aligns with change management best practices in enterprise environments.

Your platform should also support “simulation” mode: show the expected effect of a change (e.g., which denials would be resolved) without applying it. This can be done by replaying AVC logs against the proposed fix. It is not perfect, but it provides a safety check before applying changes.

Operational expansion for hange a boolean and record expected vs actual.: In real systems, the behavior you observe is the product of policy, labels, and runtime state. That means your investigation workflow must be repeatable. Start by documenting the exact inputs (contexts, paths, users, domains, ports, and the action attempted) and the exact outputs (audit events, error codes, and any policy query results). Then, replay the same action after each change so you can attribute cause and effect. When the concept touches multiple subsystems, isolate variables: change one label, one boolean, or one rule at a time. This reduces confusion and prevents accidental privilege creep. Use staging environments or fixtures to test fixes before deploying them widely, and always keep a rollback path ready.

To deepen understanding, connect hange a boolean and record expected vs actual. to adjacent concepts: how it affects policy decisions, how it appears in logs, and how it changes operational risk. Build small verification scripts that assert the expected outcome and fail loudly if the outcome diverges. Over time, these scripts become a regression suite for your SELinux posture. Finally, treat the concept as documentation-worthy: write down the invariants it guarantees, the constraints it imposes, and the exact evidence that proves it works. This makes future debugging faster and creates a shared mental model for teams.

Supplemental note for : ensure your documentation includes a minimal reproducible example and a known-good output snapshot. Pair this with a small checklist of preconditions and postconditions so anyone rerunning the exercise can validate the result quickly. This turns the concept into a repeatable experiment rather than a one-off intuition.

How this fit on projects

Drift detection is central to §3.2 and §3.7. It reuses outputs from P06-file-context-integrity-checker.md and P08-selinux-policy-diff-tool.md.

Further depth on hange a boolean and record expected vs actual.: In production environments, this concept is shaped by policy versions, automation layers, and distro-specific defaults. To keep reasoning consistent, capture a minimal evidence bundle every time you analyze behavior: the policy name/version, the exact labels or contexts involved, the command that triggered the action, and the resulting audit event. If the same action yields different decisions on two hosts, treat that as a signal that a hidden variable changed (boolean state, module priority, label drift, or category range). This disciplined approach prevents trial-and-error debugging and makes your conclusions defensible.

Operationally, build a short checklist for hange a boolean and record expected vs actual.: verify prerequisites, verify labels or mappings, verify policy query results, then run the action and confirm the expected audit outcome. Track metrics that reflect stability, such as the count of denials per hour, the number of unique denial keys, or the fraction of hosts in compliance. When you must change behavior, apply the smallest change that can be verified (label fix before boolean, boolean before policy). Document the rollback path and include a post-change validation step so the system returns to a known-good state.

Definitions & key terms

  • baseline -> approved SELinux configuration
  • drift -> deviation from baseline
  • compliance status -> pass/fail state per host
  • severity -> risk level of a deviation

Mental model diagram

baseline -> compare -> deviations -> severity -> report

How it works (step-by-step, with invariants and failure modes)

  1. Capture baseline SELinux state.
  2. Collect current state from each host.
  3. Compare and compute drift events.
  4. Assign severity and report.

Invariants: baseline is fixed for a given period; drift events are immutable records. Failure modes: incomplete data collection, inconsistent baselines.

Minimal concrete example

{"host":"web-01","drift":"mode","expected":"enforcing","actual":"permissive","severity":"critical"}

Common misconceptions

  • “Compliance is just enforcing mode.” -> Booleans, modules, and labels matter.
  • “Drift detection is a one-time check.” -> It must be continuous.

Check-your-understanding questions

  1. Why is baseline definition critical?
  2. What types of drift should be detected?
  3. How do you prioritize drift events?

Check-your-understanding answers

  1. Without a baseline, you cannot define compliance.
  2. Mode, booleans, policy modules, and file contexts.
  3. Use severity based on risk and impact.

Real-world applications

  • Regulatory compliance for hardened systems.
  • Security posture monitoring at scale.

Where you’ll apply it

References

  • “Foundations of Information Security” (governance)
  • Red Hat SELinux compliance guides

Key insights

Compliance is a continuous comparison against an explicit baseline, not a one-time checkbox.

Summary

Policy drift detection compares hosts against a baseline and produces severity-ranked deviations.

Homework/Exercises to practice the concept

  1. Define a baseline for a web server.
  2. Simulate a drift event and record it.
  3. Design a severity rubric for drift types.

Solutions to the homework/exercises

  1. Baseline: enforcing mode, defined booleans, known policy version.
  2. Change a boolean and record expected vs actual.
  3. Critical: permissive/disabled; high: missing policy module; medium: label drift.

3. Project Specification

3.1 What You Will Build

A centralized SELinux security platform with:

  • Agent-based log collection
  • Normalized AVC storage
  • Drift detection and compliance reports
  • Remediation recommendations with risk scoring
  • Web dashboard for fleet health

3.2 Functional Requirements

  1. Log Ingestion: Collect AVC logs from multiple hosts.
  2. Normalization: Convert logs into canonical schema.
  3. Drift Detection: Compare host state to baseline.
  4. Remediation: Generate safe recommendations with risk.
  5. Dashboard: Show fleet status, top denials, compliance.

3.3 Non-Functional Requirements

  • Scalability: Support 100+ hosts.
  • Reliability: No data loss under transient network issues.
  • Security: Authenticated access to dashboard and APIs.

3.4 Example Usage / Output

Fleet Status:
- Enforcing: 120
- Permissive: 4
- Disabled: 1

Top Denials:
1. httpd_t -> user_home_t (read) [Fix: httpd_enable_homedirs]

3.5 Data Formats / Schemas / Protocols

API error shape:

{"error": {"code": "INVALID_REQUEST", "message": "missing host"}}

3.6 Edge Cases

  • Hosts with missing audit logs
  • Policy versions that differ across distributions
  • High cardinality category labels (MCS)

3.7 Real World Outcome

3.7.1 How to Run (Copy/Paste)

./platform-agent --host web-01 --ship /var/log/audit/audit.log
./platform-server --config config.yml

3.7.2 Golden Path Demo (Deterministic)

Use fixture logs from three hosts and a fixed baseline. Freeze timestamps in the UI for demo mode.

3.7.3 If API: endpoints table

Method Path Description
GET /api/hosts List hosts and SELinux status
GET /api/denials List top denials
POST /api/recommendations Create remediation recommendation
POST /api/approve/{id} Approve a remediation

Example request/response:

curl -X GET http://localhost:8080/api/hosts

Response:

{"hosts":[{"name":"web-01","mode":"enforcing"}]}

Error response:

{"error":{"code":"NOT_FOUND","message":"host not found"}}

4. Solution Architecture

4.1 High-Level Design

Agents -> Queue -> Normalizer -> Storage -> API/Dashboard

4.2 Key Components

Component Responsibility Key Decisions
Agent Ship logs and state Local spool for reliability
Normalizer Parse AVCs Canonical schema
Storage Store logs and metrics Time-series + document store
Dashboard Fleet view Web UI with filters
Remediation Engine Recommend fixes Risk-scored taxonomy

4.3 Data Structures (No Full Code)

HostState:
  mode, policy, booleans, drift_count

4.4 Algorithm Overview

Key Algorithm: Drift Pipeline

  1. Ingest host state.
  2. Compare to baseline.
  3. Emit drift events with severity.
  4. Update host compliance status.

Complexity Analysis:

  • Time: O(n) hosts
  • Space: O(n) host states

5. Implementation Guide

5.1 Development Environment Setup

# install dependencies for your chosen stack

5.2 Project Structure

platform/
├── agent/
├── server/
├── ui/
└── schemas/

5.3 The Core Question You’re Answering

“How do I operationalize SELinux security at scale?”

5.4 Concepts You Must Understand First

  1. Distributed log collection and normalization.
  2. Policy drift detection.
  3. Risk-scored remediation workflow.

5.5 Questions to Guide Your Design

  1. How will you ensure log delivery reliability?
  2. How will you define and manage baselines?
  3. What approvals are required for remediation?

5.6 Thinking Exercise

Design a dashboard widget that highlights the top three SELinux risks across the fleet.

5.7 The Interview Questions They’ll Ask

  1. “How would you scale SELinux monitoring to 1000 hosts?”
  2. “What are the key SELinux KPIs?”
  3. “How do you reduce false positives?”

5.8 Hints in Layers

Hint 1: Start with log ingestion and normalization

Hint 2: Add baseline and drift detection

Hint 3: Add remediation recommendations with risk scoring

5.9 Books That Will Help

Topic Book Chapter
Architecture “Clean Architecture” Architecture chapters
Observability “Fundamentals of Software Architecture” Observability sections
Security ops “The Practice of System and Network Administration” Compliance and ops

5.10 Implementation Phases

Phase 1: Foundation (2-3 weeks)

Goals:

  • Build agent and log ingestion pipeline.

Tasks:

  1. Implement log shipping with spooling.
  2. Normalize AVC logs into schema.

Checkpoint: Events from 3 hosts appear in storage.

Phase 2: Core Functionality (2-3 weeks)

Goals:

  • Add drift detection and compliance reporting.

Tasks:

  1. Collect host state snapshots.
  2. Compare against baseline and store drift events.

Checkpoint: Dashboard shows compliance status per host.

Phase 3: Polish & Edge Cases (2-3 weeks)

Goals:

  • Add remediation workflow and approvals.

Tasks:

  1. Generate recommendations with risk scores.
  2. Implement approval UI and apply pipeline.

Checkpoint: Approved recommendations can be applied and verified.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Transport HTTP vs message queue queue reliable delivery
Storage SQL vs log store mixed metrics + raw events
Remediation auto-apply vs approve approve safety

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests parsing and normalization AVC parser
Integration Tests agent->server pipeline fixture logs
End-to-End Tests dashboard workflows simulated hosts

6.2 Critical Test Cases

  1. Logs are ingested and normalized correctly.
  2. Drift detection flags a host in permissive mode.
  3. Remediation approval workflow enforces safety.

6.3 Test Data

fixtures/host1_audit.log
fixtures/host2_audit.log

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
No buffering log loss on network failure add local spool
No schema versioning parsing breaks on changes version schemas
Auto-apply fixes unintended changes require approvals

7.2 Debugging Strategies

  • Replay fixture logs through the pipeline.
  • Compare normalized records to raw input.

7.3 Performance Traps

  • High-cardinality labels can explode metrics; aggregate by domain.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add CSV export of compliance status.
  • Add summary email reports.

8.2 Intermediate Extensions

  • Integrate policy diffing (P08) into dashboard.
  • Add per-domain risk dashboards.

8.3 Advanced Extensions

  • Add machine-learning-based anomaly detection.
  • Support multi-region data replication.

9. Real-World Connections

9.1 Industry Applications

  • Enterprise security monitoring platforms.
  • Compliance dashboards in regulated industries.
  • Loki/Promtail for log shipping (conceptual reference).
  • OpenSCAP for compliance.

9.3 Interview Relevance

  • Distributed systems design and security operations.

10. Resources

10.1 Essential Reading

  • “Clean Architecture” (system design)
  • “Fundamentals of Software Architecture” (observability)

10.2 Video Resources

  • Security operations platform talks

10.3 Tools & Documentation

  • ausearch, semanage, sesearch

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain log normalization and why it matters.
  • I can define a baseline and detect drift.
  • I can justify remediation risk scores.

11.2 Implementation

  • Logs are ingested reliably.
  • Drift detection works across hosts.
  • Remediation workflow is auditable.

11.3 Growth

  • I can discuss scaling and retention strategies.
  • I documented the approval workflow.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Ingest AVC logs from multiple hosts and display them.

Full Completion:

  • Add drift detection and risk-scored remediation.

Excellence (Going Above & Beyond):

  • Add anomaly detection and multi-region support.

13 Additional Content Rules (Hard Requirements)

13.1 Determinism

  • Use fixture logs and frozen timestamps in demo mode.

13.2 Outcome Completeness

  • Provide API success and error responses with JSON shapes.

13.3 Cross-Linking

  • Link to P02 and P08 for AVC and policy analysis.

13.4 No Placeholder Text

  • All sections are fully specified.