Configuration compliance and golden-config drift
Configuration compliance checks the configuration a device is actually running against the configuration it is supposed to run — a golden config you have approved, or a published benchmark such as CIS, PCI DSS or NIST SP 800-171. Drift is any divergence between the two. Done continuously, it turns compliance from an annual attestation into a live property of the estate: every failing rule points at a specific line on a specific asset, and stays visible until someone fixes it or approves the exception.
Every compliance program has a moment where the paperwork and the hardware disagree. The control says “deny lateral SMB between tiers.” The firewall has had a permit rule for port 445 since a maintenance window in March — temporary, ticketed, never reverted. The spreadsheet is green. The network is not.
Configuration compliance exists to catch that moment before an auditor or an attacker does. It is less glamorous than threat intelligence and more useful than most of it.
Golden configurations
A golden configuration is the approved state of a device or service: the firewall policy as it should read, the TLS policy a load balancer should enforce, the logging and NTP settings every switch should carry. It is a baseline you own, not a vendor default. Once it exists, “is this device compliant?” becomes a mechanical question — diff the running config against the golden one.
Benchmarks and frameworks as rules
Published benchmarks are golden configurations somebody else wrote. CIS Benchmarks say what hardened looks like for a platform; PCI DSS says TLS 1.2 is the floor on anything touching card data; NIST SP 800-171 says audit records go to a central store. Each of those is expressible as a rule over configuration text: a string that must appear, a string that must not, a pattern that must or must not match.
Expressing controls as rules has a useful side effect. The control is no longer an opinion recorded in a GRC tool; it is a test that runs, with a pass or fail per asset and a line number when it fails.
Drift: the gap between intent and reality
Drift is what happens between audits. Someone opens a port for a vendor and forgets. A listener gets downgraded to TLS 1.2 “temporarily” for an old client. A WAF is switched from prevention to detection while a false positive is investigated and never switched back. None of these are attacks. All of them are the conditions attacks need.
Detecting drift means pulling configuration from devices on a schedule, versioning it, and re-evaluating every policy against every new snapshot. When a device drifts, two things should happen at once: the compliance view flips to failing with the offending line highlighted, and an event is raised so the operations team sees it alongside everything else.
Closing the loop
A drift finding is only valuable if it leads somewhere. The natural destination is a remediation proposal: revert to golden, show the diff, estimate the blast radius and the value-at-risk reduction, and route it for approval. Compliance, operations and risk stop being three conversations and become one.
How Onek.ai does configuration compliance
Onek.ai pulls device configuration through its connectors, versions it, and evaluates your policies against every snapshot — then hands failures to the remediation layer.
Available today
- Policy engine with required / forbidden strings and regular expressions, scoped by asset kind, tagged to a framework (NIST 800-171, CMMC, PCI DSS, CIS, OWASP) and a severity.
- Continuous evaluation against versioned configuration snapshots, with pass/fail per asset and the exact matching line in each finding.
- Drift raised as an event the first time a policy fails on an asset — not on every re-run — alongside the golden-config diffs in the Configuration view.
- One-click remediation proposals from a drift finding: revert to golden, blast radius and value-at-risk reduction estimated, approval-gated, fully audited.
- Alert rules on the same signals (thresholds and log patterns) so a drift or a failing policy can page someone.
On the roadmap
- Vendor-specific config parsers (Cisco IOS/NX-OS, PAN-OS, Terraform state) for structural rather than textual rules.
Frequently asked questions
- What is configuration drift?
- The gap between the configuration a device is supposed to run — your golden config or a benchmark — and the configuration it is actually running. Drift accumulates through temporary changes that are never reverted, and it is detected by pulling and re-evaluating configuration on a schedule.
- Is configuration compliance the same as vulnerability scanning?
- No. A vulnerability scanner looks for known-bad software versions and exposures. Configuration compliance checks whether a device matches an approved state — hardening, logging, segmentation, TLS policy. A fully patched firewall with a permit-any rule passes a vulnerability scan and fails configuration compliance.
- Can one policy apply to many kinds of device?
- Yes, if it is written against something every device exposes — centralized logging, NTP authentication, a login banner. Policies that are specific to a kind of device (TLS policy on load balancers, segmentation rules on firewalls) are scoped so they only evaluate where they make sense.
Related platform capabilities
Learn the concepts