Config Drift Checker

Source format:

Auto detect reports both resolved parsers in the summary and evidence package.

Baseline name:

Use a short traceable name; it labels exports without changing drift classification.

Intended config:

Use the approved state from version control, a policy export, or a reviewed change record.

Observed config:

Use a fresh export from the environment or device being reviewed.

Key matching:

Use strict matching when key case is meaningful to the target system.

Value handling:

Exact trimmed is safer when spaces inside a value affect behavior.

Priority keys:

Examples: ssh_version, snmp, aaa*, /secret|password/.

Ignored keys:

Leave blank for a full comparison. Example: generated_at, last_seen, session_*.

Evidence package name:

Leave blank to use the baseline name in export labels.

Include unchanged rows:

Adds aligned evidence to the ledger without changing the summary, risk score, remediation queue, or chart.

Key	Status	Severity	Intended	Observed	Evidence	Copy
{{ row.key }}	{{ row.status }}	{{ row.severity }}	{{ row.intended }}	{{ row.observed }}	{{ row.evidence }}

Priority	Key	Drift	Owner action	Evidence	Copy
{{ row.priority }}	{{ row.key }}	{{ row.drift_type }}	{{ row.action }}	{{ row.evidence }}

Ordered remediation queue

Priority matches and higher weighted findings appear first. Confirm source scope before applying any change.

Finding count and weighted risk by drift type

Counts show evidence volume; weighted risk reflects the declared priority-key triage rules.

A reviewed configuration is a promise about how a system should behave. The running configuration is evidence of how it behaves now. Drift is the difference between those two states, whether the change came from an emergency fix, a manual command, an incomplete deployment, a vendor update, or an undocumented exception.

Not every difference carries the same meaning. A missing authentication setting can weaken a control, a changed logging destination can hide evidence, and an extra banner may be harmless. Good drift review therefore needs both a dependable comparison and enough context to decide which keys deserve attention first.

Intended configuration: The approved baseline from version control, policy, or a reviewed change record.
Observed configuration: A fresh snapshot from the environment, service, or device being checked.
Priority key: A setting whose absence or change should be escalated because it protects security, availability, or auditability.
Ignored key: A deliberately excluded value, often volatile metadata such as a collection timestamp. An ignore rule should itself be reviewed and traceable.

Text comparison is only as trustworthy as the snapshots. Different export scopes, stale observations, secrets that were redacted inconsistently, or a parser that interprets the two inputs differently can create apparent drift. A clean result means the parsed keys align under the chosen rules; it does not prove that the entire system matches policy.

How to Use This Tool:

Compare snapshots taken from the same configuration scope and close enough in time to support a fair review.

Choose Source format. Auto detect recognizes a JSON object, INI sections, or key/value lines and reports the parser resolved for each input.
Give the baseline a traceable name, then paste or load the approved text into Intended config and the fresh snapshot into Observed config.
Select Key matching and Value handling. Use strict keys when letter case matters; choose Exact trimmed when internal spaces must remain significant.
Add only reviewed Priority keys and Ignored keys. Entries can be exact names, patterns containing *, or regular expressions enclosed by slashes.
Check the summary for parser warnings and the Drift evidence rows for changed, missing, extra, and ignored keys. Correct a parse error or invalid pattern before treating the remediation queue as complete.

Interpreting Results:

Critical findings are priority keys that changed or disappeared. Non-priority missing keys are High, changed keys are Medium, and extra keys are Low; a priority extra key rises to High. Start with the remediation queue, but inspect its intended and observed evidence before changing a live system.

Compliance is the share of intended keys that are unchanged. It excludes extra observed keys from the denominator, so a high percentage can coexist with consequential additions. Risk score is a triage total based on finding severity, not a probability or a standardized risk measure.

A Clean summary means no changed, missing, or extra parsed keys remain after ignore rules. Verify that both parser labels, key counts, snapshot sources, and ignore rules are the ones intended before accepting that conclusion.

Technical Details:

Configuration drift is reduced to a deterministic comparison of normalized key-to-value sets. That makes the result repeatable, while keeping the chosen parsing and normalization rules visible enough to audit.

Transformation Core

Each input follows the same path: parse the selected format, flatten it to keys, normalize keys and values, consolidate duplicates into sorted value sets, and compare the union of intended and observed keys.

Configuration source transformations
Source	Key construction	Important behavior
Key/value lines	Text before the first `=` or `:`	Blank and comment lines are skipped; a line without a separator becomes a presence key.
JSON object	Nested object paths use dots; array positions use brackets	The top level must be an object. Empty arrays and objects remain explicit values.
INI sections	Section and key join as `section.key`	Lines without a separator remain presence keys and raise a parser warning.

Strict key matching preserves case; case-insensitive matching lowercases comparison keys. Both value modes trim surrounding whitespace. Collapse whitespace also reduces every internal whitespace run to one space, while Exact trimmed preserves internal spacing. Repeated keys are compared as unique sorted value sets and produce a warning.

Rule Core

Ignore patterns run first and override every other status. Remaining keys are classified in this order:

Drift classification and severity rules
Condition	Status	Normal severity	Priority severity
Matches an ignore pattern	Ignored	Info	Info
Intended exists; observed absent	Missing	High	Critical
Observed exists; intended absent	Extra	Low	High
Both exist; normalized value sets differ	Changed	Medium	Critical
Both exist; normalized value sets match	Unchanged	None	None

Wildcard patterns are anchored to the whole key. A slash-wrapped pattern is treated as a regular expression. When case-insensitive matching is selected, pattern matching is case-insensitive too.

Formula Core

Compliance counts unchanged intended keys and divides by the number of parsed intended keys. The displayed percentage keeps six decimal places in the underlying result.

C = \frac{N_{unchanged-intended}}{N_{intended}} \times 100

The risk score adds severity weights for changed, missing, and extra rows only: Critical 5, High 3, Medium 2, and Low 1. Ignored and unchanged rows add zero.

R = \sum_{i = 1}^{n} w (s_{i})

The score has no universal pass threshold. Any Critical row makes the summary critical; otherwise any actionable row produces drift, and zero actionable rows produce clean.

Each configuration input is limited to 262,144 characters and 5,000 parsed keys. Priority and ignore text is limited to 4,000 characters each; baseline and evidence labels are limited to 120 characters.

Limitations and Privacy Notes:

The comparison runs in the browser and does not send pasted configuration text to a checker service. Keep secrets out of screenshots, copied evidence, and downloaded reports, and follow the handling rules for the system being reviewed.

Only JSON objects, INI sections, and simple key/value text are modeled. Order, comments, complex vendor syntax, and semantic relationships between settings are not evaluated.
Auto detection can resolve the intended and observed inputs differently. Review both parser labels before accepting a result.
Ignored keys are excluded by policy, not proven harmless. Over-broad wildcards or regular expressions can hide real drift.
A difference identifies evidence to investigate; it does not decide whether the baseline or the live setting is correct.

Worked Examples:

Network baseline with four findings

An intended six-key baseline and a six-key observation contain three aligned keys. The observation changes snmp and logging_buffered, omits priority key aaa_mode, and adds banner. With snmp and aaa* marked priority, the result is two Critical findings, one Medium, and one Low. Compliance is 3 ÷ 6 = 50%, and the risk score is 5 + 5 + 2 + 1 = 13.

References:

NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, National Institute of Standards and Technology, 2011 with 2019 updates.
Detect unmanaged configuration changes to stacks and resources with drift detection, Amazon Web Services.