Active Protection
Formal Perspective
The whitelisting philosophy within the First Watch® platform is rooted in deterministic trust — the assurance that only known, validated, and authorised software components can execute within the protected environment.
This philosophy aligns with the key principles of industrial cybersecurity frameworks such as:
- IEC 62443-3-3 — System Security Requirements and Security Levels
- NIST SP 800-82 — Guide to Industrial Control System Security
Unlike traditional antivirus or heuristic approaches that reactively identify malicious behaviour, First Watch applies a positive selection model:
If a binary is not explicitly trusted, it cannot run.
This "default deny" principle eliminates the uncertainty of reactive detection and ensures consistent protection, even against zero-day vulnerabilities or insider threats.
Core Principles
1. Determinism over Heuristics
All security decisions are based on verifiable attributes, not behavioural guesses. The same input always produces the same enforcement result.
2. Multi-Layered Trust Evaluation
Whitelisting decisions are made based on multiple parameters (hash, signature, etc.) through a hierarchical validation process that maintains integrity, even when files are updated or recompiled.
3. Traceable Justification
Every allowed executable must have a clear justification — its inclusion in the whitelist must be auditable and approved.
4. Controlled Dynamism
The system allows legitimate dynamic operations (e.g., .NET assemblies, signed updates) but only under predictable, controlled conditions.
5. Fail-Secure Behaviour
In cases of corruption, missing configuration, or uncertain attributes, the system defaults to blocking execution rather than risking compromise.
6. Audit and Transparency
Every policy decision (allow or block) is logged, timestamped, and tied to a specific rule — ensuring full accountability and compliance traceability.
Engineering Perspective
Within the First Watch® platform, whitelisting is implemented as a deterministic rule evaluation engine operating under the supervision of the Controller. This engine evaluates each process or module according to a layered trust hierarchy, providing flexibility where required but enforcing strict validation where necessary.
Trust Evaluation Mechanisms
When a new process or module is encountered, ControlGuard evaluates it through the following sequence:
| Priority | Validation Criterion | Description | Comment |
|---|---|---|---|
| 1 | Exact Hash Match (SHA-2) | Provides the strongest identity for an individual file — the file must match an approved binary hash exactly | Only files with the specified hash can execute. If the executable is overwritten or modified, its hash changes and execution is denied |
| 2 | Digital Signature Verification | If the hash differs (e.g., due to a vendor update), the system verifies the signature against an approved certificate subject or issuer | For example, a valid Microsoft Corporation signature. Allowing execution by trusted digital signature permits all files signed by the legitimate vendor |
| 3 | File Metadata Matching | Validates Product Name, File Description, and Company Name against policy | Example: Product Name = Windows Command Processor. This method must be combined with signature validation, as resource attributes can be easily modified |
| 4 | Parent Process Trust | Validates the execution chain — a process is allowed only if launched by a trusted parent | Example: svchost.exe launching services.exe. This check can also evaluate the command line for additional context verification |
| 5 | Executable Path / Directory Rule | Verifies that the file resides in an approved directory | Example: %SystemRoot%\System32\. Ensures the file has not been moved to an unexpected location |
| 6 | Behavioural Context | Verifies runtime behaviour or mode (e.g., PowerShell in Restricted mode) | The kernel hook for this mechanism is under development, but workarounds exist for effective control |
| 7 | Dynamic Assembly Control | Validates runtime-generated files by checking parent process hash and storage path | Example: .NET temporary DLLs created by a signed compiler. This is one of the most challenging aspects, as each compilation can yield a different hash |
| 8 | Complex Policies | Allows advanced rules written in the ControlGuard policy language that use contextual data from the parent process, file attributes, or calculated conditions | Example: If a blocked executable runs under a specific account (e.g., AllowToRun), the policy can temporarily whitelist it. Disabling the policy restores the block |
The evaluation engine applies these validation layers deterministically. If a module fails all applicable checks, it is blocked (in enforcement mode) or logged as suspicious (in audit mode).
This layered trust model provides both security determinism and operational flexibility — two qualities that are often considered mutually exclusive in OT systems. In First Watch, they coexist under a unified and provable trust evaluation framework.