CIS benchmark waivers when a legacy application requires root SSH
You manage compliance for 800 RHEL 7 nodes using an InSpec CIS Level 1 profile executed through Chef Automate. Fourteen percent of nodes fail control sshd-05 because a legacy application requires PermitRootLogin yes on 112 nodes. Thirty additional nodes fail several controls because their InSpec agent version is older than the profile expects, and the failures do not match the actual sshd_config on disk. The compliance officer wants a blanket waiver for the 142 nodes so the next audit report is clean. Security wants full remediation in 60 days. The application team says it needs nine months and cannot change the root login requirement without a vendor patch. The auditors have asked for evidence that exceptions are scoped, justified, and time-bound, not hidden.
1. How do you determine which of the 142 failing nodes are real noncompliance versus scanning artifacts? What specific InSpec and Chef Automate evidence would you inspect?
Read the worked answer
Separate control failures by cause before discussing waivers. For the 30 suspected artifacts, compare the InSpec version and profile version on the node with the version used by the Automate scan job. Then run the same profile locally against one affected node and inspect the control result: the resource used, the observed value, and the expected value. If the control reports an OS family or package version mismatch that contradicts sshd -T and the on-disk config, treat it as a scanner/tooling defect, not a compliance failure.
For the 112 sshd-05 failures, verify the effective configuration with sshd -T and confirm that the control is reading the same file the daemon uses. Check whether the failure is a single control on all 112 nodes or a broader drift pattern. In Chef Automate, filter by control, profile version, and node, and export the individual resource results rather than the summary percentage. The 30 artifact nodes should be fixed by upgrading the agent or pinning the profile version, then rescanned; they should not be waived. The 112 real failures can then be evaluated as an exception with a known scope.
2. Design a waiver or exception process that satisfies the auditor without hiding risk. Include scope, expiry, justification, and evidence.
Read the worked answer
Do not use a blanket waiver. Create a waiver scoped to control sshd-05, to the 112 named nodes or a node attribute that identifies the legacy application, and to a fixed expiry date. The justification should name the vendor dependency, the compensating controls in place, and the owner. Compensating controls might include network restriction to a bastion, key-only authentication, session recording, and a tighter sudo policy; state which are verified by another control.
InSpec supports waiver files with a control name, expiration, and justification. Keep the waiver in version control, reference the risk ticket, and make the expiration visible in the Automate report. The report should show failed, waived, and not-applicable counts separately so the auditor can see the residual risk. Set the waiver to expire before the vendor patch date and require a re-review at 30 and 60 days. The 30 artifact nodes get a tooling fix, not a waiver. Security's 60-day goal should apply to the real failures; if the application team needs nine months, the exception must be reviewed and re-approved in shorter intervals, not granted once for nine months.
3. How would you shift this compliance check left into the cookbook pipeline so the 112 nodes do not drift while remediation is pending?
Read the worked answer
Add the CIS profile as a verify step in Test Kitchen for the cookbook that manages sshd_config, and run it after converge on the supported platforms. In ChefSpec, unit-test the template and attribute logic that writes PermitRootLogin so a pull request cannot silently change the default. In CI, run inspec exec against the kitchen instance and fail the build if a new node would be noncompliant without a matching exception.
For the existing 112 nodes, encode the exception as data, not as a changed profile: a data bag or attributes keyed by application and node, consumed by the pipeline to allow only the known exception. That keeps the profile honest and makes new drift fail. Run a scheduled InSpec scan against production and compare results with the waiver list; any node that is noncompliant and not on the list should open a ticket. Before remediation, add a chef-client audit-mode or post-converge check on those nodes so a manual edit is caught before the next scheduled scan.