Eye of HorusSTIG Validator

Every result carries its own evidence

Most scanners hand you a verdict. This is one rule as Eye of Horus reports it — the same structure appears in the HTML report, the CKL finding details, and the JSON. Open it.

Win32_DeviceGuard.SecurityServicesRunning contains 1
(Credential Guard active)

SecurityServicesRunning = {0}
VirtualizationBasedSecurityStatus = 2
Credential Guard running = False

The collected evidence did not satisfy the automated
conditions for this rule.

Method: Supplemental PowerShell
Collector status: Completed
Evidence items: 1

No human answer was applied.

Evidence SHA-256  9f2c1e…  Catalog SHA-256  b74a99…
Engine SHA-256    7e8377…  Proof SHA-256    b71a08…

{ "TraceType": "SupplementalEvaluation",
  "Check": "Verify Credential Guard is running…",
  "Observation": "Credential Guard running=False",
  "Outcome": "Fail" }

[{ "SecurityServicesConfigured": [1],
   "SecurityServicesRunning": [0] }]

What this release assesses

Rule catalogs are generated from official DISA Cyber Exchange STIG packages and embedded in the engines. Nothing is fetched at runtime.

The Server 2022 engine resolves standalone, member-server, domain-controller, Desktop Experience, and Server Core applicability before it evaluates anything. It also inventories installed features and names the additional product STIGs that apply — Active Directory, DNS, IIS, SQL Server, AD FS — rather than implying an OS baseline covers them.

A separate product engine inventories installed software, records which product STIGs apply, and runs 13 targeted controls for software such as Microsoft Edge, Firefox, Adobe Acrobat Reader, Java 8, and IIS 10.

Assessment never changes what it measures

The assessment is a detective control. It never writes a registry value, policy setting, or ACL that a STIG rule evaluates. Changes happen only in the separate remediation command, and only when you ask for them.

Fix what can be fixed safely

Invoke-EyeOfHorusRemediation.ps1 starts from a fresh assessment. It plans by default and changes nothing until you run it with -Apply, a change ticket, and the name of the person who authorized the change.

Automatic

Applied with -Apply. DISA's own OVAL definition pins the value, and the change is local and reversible: registry policy values, the required flag for each advanced audit subcategory, password policy, the Guest account, and anonymous SID/name translation.

Guarded

Applied only when you name the rule with -IncludeGuarded. Automatable, but people or other systems may depend on the current behavior: SMB signing, NTLMv2-only, Kerberos AES, FIPS mode, UAC, WinRM authentication, account lockout, user rights, and removing SMBv1, Telnet, TFTP, or PowerShell 2.0. Each rule states its operational impact.

Manual

Never changed. Hardware and firmware, certificates, file and registry permissions, account names, per-user settings, domain policy, irreversible removals, and site decisions. Each rule states why.

Every rule's tier, fix, value basis, and reason are listed in Remediation/REMEDIATION-CLASSIFICATION.csv in the package.

How a change is made

Commands

.\Invoke-EyeOfHorusRemediation.ps1

.\Invoke-EyeOfHorusRemediation.ps1 -Apply -ChangeTicket CHG0012345 -AuthorizedBy 'J. Smith, ISSM'

.\Invoke-EyeOfHorusRemediation.ps1 -Apply -ChangeTicket CHG0012345 -AuthorizedBy 'J. Smith, ISSM' -IncludeGuarded WN11-SO-000100,WN11-SO-000120

.\Invoke-EyeOfHorusRemediation.ps1 -RollbackJournal <journal.json> -ChangeTicket CHG0012346 -AuthorizedBy 'J. Smith, ISSM'

Each run writes the findings that are still non-compliant — with the reason each one was not fixed and the DISA fix text — plus the plan, the change journal, an HTML summary, and an Excel workbook under STIG-Results\Remediation.

0

Plan written, or nothing left to fix

1

Fixes applied, and findings remain

2

A fix failed, a regression appeared, the reassessment reported errors, or a rollback step failed

3

Stopped before completing

Six assessment outputs from one run

One assessment run produces all of these, plus a SHA-256 manifest.

• XLSXExcel workbook, the main deliverable: run information, all results, product applicability, installed software, and errors on separate tabs.
• CKLImports into STIG Viewer. Finding details carry expected, observed, decision logic, collector health, and integrity hashes.
• JSONComplete per-rule proof object with raw evidence, OVAL decision traces, and answer attribution.
• HTMLSelf-contained report with the expandable proof shown above on every rule.
• CSVProof ledger for filtering and bulk review across a fleet.
• XCCDFResults in standard XCCDF for downstream tooling.

Quick start

Four steps to your first assessment. No installer, no dependencies, no configuration file.

1. Extract the whole ZIP

   Do not launch it from inside Explorer's ZIP view. The launcher checks for both engine folders and stops if they are missing.

2. Run Run-Eye-Of-Horus.cmd

   Double-click it. It requests elevation on its own, so right-click is optional. From a prompt you can call the orchestrator directly instead:

   .\Invoke-EyeOfHorus.ps1

3. Read the exit code

   The console states the outcome in plain language before it closes.

   0

   Complete, no open findings

   1

   Complete, open STIG findings exist

   2

   Incomplete — assessment errors occurred, do not treat the report as a full validation

   3

   Engine-fatal failure

4. Open the results

   Everything lands in STIG-Results. Start with the Excel workbook, or open the HTML report and expand any rule to see how the answer was reached. To fix findings next, start with the remediation plan above.

Requirements

Everything it needs is already on a Windows 11 or Server 2022 system.