Policy Engine Module

The Policy Engine receives classification verdicts from the ML Classifier and executes enforcement actions. Currently it logs verdicts to the console; the architecture supports extending it with quarantine, alerting, and blocking capabilities.

Related: ML Classifier Module · Scanner Module · Scan Pipeline Flow · Adding Detection Rules

1. Source Files

2. Pipeline Position

flowchart LR
    ML["Classify()\n→ SCAN_RESULT"]
    POL["ApplyPolicy(\n  path,\n  verdict)"]
    
    subgraph Actions["Current Actions"]
        Log["Console Output"]
    end
    
    subgraph Future["Future Actions"]
        Quarantine["Quarantine File"]
        Alert["Send Alert"]
        Block["Block Execution"]
    end
    
    ML --> POL
    POL --> Log
    POL -.-> Quarantine
    POL -.-> Alert
    POL -.-> Block

    style POL fill:#e07a5f,color:#fff
    style Actions fill:#2d6a4f,color:#fff
    style Future fill:#6c757d,color:#fff

3. Current Implementation

flowchart TD
    Input["ApplyPolicy(path, verdict)"]
    
    Input --> Switch{"verdict?"}
    
    Switch -->|SCAN_MALICIOUS| PrintMal["wprintf('[MALICIOUS] %s')"]
    Switch -->|SCAN_CLEAN| PrintClean["wprintf('[CLEAN] %s')"]
    Switch -->|default| NoOp["No action"]

    style PrintMal fill:#e63946,color:#fff
    style PrintClean fill:#2d6a4f,color:#fff
    style NoOp fill:#6c757d,color:#fff

Function Signature

void ApplyPolicy(const wchar_t* path, SCAN_RESULT verdict);

Current Actions

4. Extension Architecture

The policy engine is the natural extension point for adding response actions. The current switch statement can be extended with any of the following patterns:

flowchart TB
    subgraph PolicyActions["Potential Policy Actions"]
        direction TB
        
        subgraph Logging["Tier 1: Logging"]
            Console["Console Output ✅ (current)"]
            FileLog["File Logging"]
            EventLog["Windows Event Log"]
        end
        
        subgraph Response["Tier 2: Response"]
            Quarantine["Move to Quarantine\nFolder"]
            Rename["Rename with\n.quarantine extension"]
            Restrict["Set restrictive\nACLs"]
        end
        
        subgraph Active["Tier 3: Active Defense"]
            Kill["Terminate Process\n(using PID)"]
            Block["Prevent Execution\n(driver callback)"]
            Network["Network Alert\n(SIEM integration)"]
        end
    end

    style Logging fill:#2d6a4f,color:#fff
    style Response fill:#e07a5f,color:#fff
    style Active fill:#e63946,color:#fff

Adding a New Policy Action

See Adding Detection Rules for the complete guide. The minimal change is:

1. Add a new case to the switch in ApplyPolicy()
2. Implement the action function
3. Optionally add new SCAN_RESULT values to the scanner_api.h enum

5. Design Considerations

Important: Active blocking (preventing file execution) requires changes to the kernel driver. The current driver is observe-only — all pre-operation callbacks return FLT_PREOP_SUCCESS_*, never FLT_PREOP_COMPLETE with STATUS_ACCESS_DENIED. Implementing blocking would require:

1. Adding a reply mechanism to FltSendMessage (enable reply buffer)
2. Having the scanner send a BLOCK/ALLOW verdict back through the port
3. The driver’s pre-op callback waiting for the reply before returning

Next Steps

• Add new detection rules: Adding Detection Rules
• Understand the classification input: ML Classifier Module
• Full scan pipeline context: Scan Pipeline Flow