Rip out compensating-controls framework (#359)
## Summary Removes the compensating-controls (CC) framework. Prowler and Kingfisher continue to run weekly and produce reports; the Prowler mutelist YAML files stay in place but no longer carry \`CC: <id>\` prefixes — each entry now just keeps a free-form \`Description\` of why it's muted. The CC review cadence proved to be more process overhead than this single-operator homelab needed. ## What changed **Deleted** - \`compensating-controls.yaml\` — the CC registry - \`mise-tasks/review-compensating-controls\` — the staleness-review task - \`docs/how-to/operations/review-compensating-controls.md\` - \`docs/how-to/operations/record-review-evidence.md\` (was aspirational) - \`docs/explanation/compliance-mute-categories.md\` (proposed-future CC/NA/RA work) - 5 orphan \`+review-cc-*\` / \`+compliance-mute-categories\` changelog fragments **Modified** - 6 mutelist YAML files: stripped \`CC: <id>.\` prefix from every \`Description\` / \`statement\` field, kept the free-form text - \`mise-tasks/review-compliance-reports\`: removed CC mentions from docstrings, panel text, and the node-verification table title. Node-verification logic itself is unchanged. - \`docs/reference/operations/security.md\`: removed the "Compensating controls" section - \`docs/how-to/operations/read-compliance-reports.md\`: rewrote step 3 of "Acting on findings" to point at the mutelist YAML directly - \`docs/changelog.d/prowler-iac-mutelist.infra.md\`: rewrote to drop the "two new compensating controls" framing ## What did not change - All Prowler manifests (cronjobs, RBAC, PVs, kustomization) — scans still run on the same schedule - The Kingfisher deployment - The trivy-shim in the Prowler container — that's about Trivy ignorefile plumbing, independent of the CC concept - The mutelist entries themselves — each \`Resources\` list is unchanged; only the prose of \`Description\` was edited - \`CHANGELOG.md\` — historical releases are left as-is ## Test plan - [ ] Wait for human review before deploying — once merged, re-point ArgoCD: \`argocd app set prowler --revision main && argocd app sync prowler\` (no manifest changes besides the ConfigMap, so impact is limited to muted-finding descriptions in next week's report) - [ ] Confirm next weekly Prowler K8s CIS run (Sunday 3am) still completes and produces a report on sifaka - [ ] Confirm next weekly Prowler IaC run still honors \`trivyignore.yaml\` (the trivy shim is untouched but the ignorefile content was rewritten) - [ ] \`mise run review-compliance-reports\` — verify node-verification block still runs and prints the renamed table title Reviewed-on: #359
This commit is contained in:
parent
2fae0f7161
commit
ee51bcafb4
21 changed files with 72 additions and 758 deletions
|
|
@ -80,7 +80,7 @@ Not all failures require action. Common expected failures in our minikube cluste
|
|||
|
||||
1. **Triage** — review new failures, distinguish real issues from expected noise
|
||||
2. **Remediate** — fix what you can (pod security contexts, RBAC tightening)
|
||||
3. **Mutelist** — suppress expected/accepted failures via Prowler's `--mutelist-file` to reduce noise in future scans
|
||||
3. **Mutelist** — suppress expected/accepted failures by adding a Resource entry under the matching Check in `argocd/manifests/prowler/mutelist/*.yaml` with a free-form `Description` explaining why
|
||||
4. **Track** — compare reports over time to spot regressions
|
||||
|
||||
## Related
|
||||
|
|
|
|||
|
|
@ -1,50 +0,0 @@
|
|||
---
|
||||
title: Record Review Evidence
|
||||
modified: 2026-04-01
|
||||
last-reviewed: 2026-04-01
|
||||
tags:
|
||||
- how-to
|
||||
- security
|
||||
- compliance
|
||||
---
|
||||
|
||||
# Record Review Evidence
|
||||
|
||||
How review evidence *would* be captured after a [[review-compensating-controls|compensating control review]], to make the review auditable under a compliance framework.
|
||||
|
||||
blumeops does not currently collect review evidence. This card documents the target process for reference and practice.
|
||||
|
||||
## Why Record Evidence?
|
||||
|
||||
Reviewing a control and updating `last-reviewed` proves the review *happened* but not *what was checked*. Under frameworks like PCI DSS v4.0, a QSA needs to see dated, immutable evidence that the reviewer verified the control and that an appropriate party accepted the residual risk. Compliance platforms like Drata automate this collection, but the underlying artifacts are the same whether you use a platform or a directory of files.
|
||||
|
||||
## What Evidence Would Be Captured
|
||||
|
||||
For each control reviewed, artifacts should answer:
|
||||
|
||||
1. **Who reviewed it** — reviewer name, date
|
||||
2. **What was verified** — the specific checks performed (e.g., Tailscale ACL policy snapshot, `tailscale status` output, kubectl auth checks)
|
||||
3. **What was found** — the outcome: control still in effect, circumstances changed, or control invalidated
|
||||
4. **Residual risk** — what the control does *not* cover (the gap a QSA will ask about)
|
||||
5. **Acceptance** — formal sign-off that the residual risk is accepted by an appropriate party (reviewer + approver, typically a manager or CTO)
|
||||
|
||||
Supporting artifacts would include command output, policy snapshots, screenshots, or API responses — anything that demonstrates the verification was actually performed.
|
||||
|
||||
## PCI DSS Context
|
||||
|
||||
Under PCI DSS v4.0, compensating controls require a **Compensating Control Worksheet (CCW)** that maps each control to the original requirement it substitutes for. The CCW fields are:
|
||||
|
||||
- **Original requirement** — the specific PCI DSS requirement not directly met
|
||||
- **Constraint** — why direct compliance isn't feasible
|
||||
- **Compensating control definition** — what is done instead
|
||||
- **Risk addressed** — how the control mitigates the original threat
|
||||
- **Residual risk** — what remains unmitigated
|
||||
- **Validation procedure** — steps to verify (what `notes` captures in `compensating-controls.yaml`)
|
||||
|
||||
Req 12.3.2 mandates review **at least annually** (quarterly is typical for Level 1 Service Providers). In a platform like Drata, these map to Controls with uploaded Evidence and review workflows requiring sign-off from both the reviewer and an approver.
|
||||
|
||||
## Related
|
||||
|
||||
- [[review-compensating-controls]] — The technical review process
|
||||
- [[security]] — Security posture overview
|
||||
- [[read-compliance-reports]] — Interpreting Prowler/Kingfisher reports
|
||||
|
|
@ -1,80 +0,0 @@
|
|||
---
|
||||
title: Review Compensating Controls
|
||||
modified: 2026-03-30
|
||||
last-reviewed: 2026-03-30
|
||||
tags:
|
||||
- how-to
|
||||
- security
|
||||
- maintenance
|
||||
---
|
||||
|
||||
# Review Compensating Controls
|
||||
|
||||
How to periodically review compensating controls that justify suppressed security findings.
|
||||
|
||||
## Review by Staleness
|
||||
|
||||
Show controls sorted by when they were last reviewed (most stale first):
|
||||
|
||||
```bash
|
||||
mise run review-compensating-controls
|
||||
```
|
||||
|
||||
This reads `compensating-controls.yaml` (repo root), sorts by `last-reviewed`, and displays the most stale control with all codebase references. It also searches for every file that references the control ID, so you can see exactly which suppressed findings depend on it.
|
||||
|
||||
To show more entries:
|
||||
|
||||
```bash
|
||||
mise run review-compensating-controls --limit 20
|
||||
```
|
||||
|
||||
## What is a Compensating Control?
|
||||
|
||||
A compensating control is a security measure that mitigates the risk a finding was designed to detect, when the finding itself cannot be directly remediated. For example:
|
||||
|
||||
- **Finding:** API server does not enable AlwaysPullImages admission plugin
|
||||
- **Risk:** Untrusted users could run pods using cached images they shouldn't have access to
|
||||
- **Compensating control:** `single-user-cluster` — only the operator has kubectl access; no untrusted users can create pods
|
||||
|
||||
Controls are documented in `compensating-controls.yaml` and referenced from security tool configurations (Prowler mutelist files, Kingfisher config, etc.) using the format `CC: <control-id>`.
|
||||
|
||||
A compensating control is only one of three structurally distinct ways to suppress a finding — see [[compliance-mute-categories]] for when to reach for a CC versus a not-applicable (`NA:`) or risk-accepted (`RA:`) tag instead.
|
||||
|
||||
## Review Process
|
||||
|
||||
For each control up for review:
|
||||
|
||||
1. **Understand the risk.** Read each suppressed finding that references this control. What attack or misconfiguration does the original check guard against?
|
||||
|
||||
2. **Verify the control is in effect.** Follow the verification steps in the control's `notes` field. For example, for `tailscale-network-isolation`, check that the cluster is not directly internet-exposed and Tailscale ACLs are enforced.
|
||||
|
||||
3. **Assess whether the control actually mitigates the risk.** A compensating control should address the same threat the check was designed to catch, not just be a vaguely related security measure. If it doesn't hold up, either:
|
||||
- Fix the underlying finding and remove the suppression
|
||||
- Document a stronger or more specific compensating control
|
||||
|
||||
4. **Check for changed circumstances.** Has the cluster gained new users? Has a service been exposed publicly? Has an operator added native support for the missing feature? Any of these could invalidate the control.
|
||||
|
||||
5. **Update the review date.** Edit `compensating-controls.yaml` and set `last-reviewed` to today's date. Commit alongside any changes.
|
||||
|
||||
## Adding a New Control
|
||||
|
||||
When suppressing a new security finding, either map it to an existing control or add a new one:
|
||||
|
||||
```yaml
|
||||
- id: my-new-control
|
||||
description: >-
|
||||
What this control does and how it mitigates the specific risk.
|
||||
created: 2026-03-30
|
||||
last-reviewed: 2026-03-30
|
||||
notes: >-
|
||||
How to verify this control is still in effect.
|
||||
```
|
||||
|
||||
Then reference it in the suppression configuration with `CC: my-new-control`.
|
||||
|
||||
## Related
|
||||
|
||||
- [[record-review-evidence]] — Capturing evidence artifacts for audit (aspirational)
|
||||
- [[security]] — Security posture overview
|
||||
- [[read-compliance-reports]] — Accessing and interpreting Prowler reports
|
||||
- [[review-services]] — Periodic service version review (similar staleness pattern)
|
||||
Loading…
Add table
Add a link
Reference in a new issue