This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
A review is a file you may open
Configuration review is reading a file you are allowed to read: a DMARC report for your domain, a Dockerfile, a Kubernetes manifest, a Terraform file, a GitHub Actions workflow. The auditors on this site flag patterns. A flag is a question. You do not fetch a repository you do not own, and you do not scan the internet for misconfigurations.
DMARC reports are mail about your domain. The email guide is how the record was published. The analyser helps you see who sent. A report is not a reason to jump to p=reject in the same hour.
A container or a workflow finding is fixed in the repository you own, with the pipeline gate from the DevSecOps guide if you want the build to fail next time. One finding. The previous file stays in version control.
A world-open security group or a secret in a workflow is a stop. The fix is a named prefix and prompt-for-this in the note, with the real secret in the store, rotated if it was committed.
One file, one finding, one commit
Choose a lab file. Run the matching auditor. Pick one finding you understand. Fix it. Run the auditor again and see that finding gone. If a new finding appears, it waits.
For a DMARC aggregate report you are allowed to hold, list the sources you recognise and the ones you do not. Unknown sources are an email-guide task, not a reject policy by reflex.
Do not open a forensic report in a hurry on an untrusted machine if your policy says it may contain the original message. The analyser output is still data. Treat it under the privacy guide.
Commit the fix with the previous revision easy to restore. A review that edits production by hand and leaves no diff is a review you cannot repeat.
A change you can finish
The change is one fix in one file you own. The report informs the email guide. It does not auto-edit DNS.
Rollback is the previous revision.
- Confirm you may read the file or the report.
- Run the matching auditor.
- Fix one finding you can explain.
- Re-run and see it clear.
- Leave new findings for later.
- Rotate a secret if the finding was a real secret.
- Keep the previous revision.
Mistakes that outlive the command
a security configuration review fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Reviewing a repository you do not own.
- Setting p=reject because a report looked bad.
- Fixing every finding in one commit you cannot explain.
- A secret left in the workflow after the ticket.
- Opening a forensic dump on a casual laptop against policy.
- A world-open rule kept because the app broke once.
- No previous revision.
- Calling the auditor a certification.
Decisions to write down before the window
One decision for a security configuration review: The file is one you may read. One finding is fixed and rechecked. DNS policy changes stay on the email guide. Secrets are rotated and not printed. World-allows are removed or explicitly refused. The previous revision is the rollback. The pipeline guide owns the lasting gate. Privacy rules cover report contents. The auditor is not a certification. And a second person read the diff.
The hour you stop
Write the hostname or the system name, the owner, and the clock time before you change anything for a security configuration review. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.
Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.
prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.
One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.
A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.
Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.
Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.
Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.
If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.
When the checks pass, the next system waits until someone else can repeat the proof from the notes. a security configuration review is done for this window when the proof is written, not when the tool printed a file.
This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.
Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.
Review checks before the fix is called the new baseline
Confirm this before you call the change done: You administer the file or the domain. One finding is explained. The re-run is clean for that finding. Other findings are still listed. The previous revision restores. No secret is in the diff. No world-allow remains from this fix. DMARC policy was not changed in this window. The report was one you are allowed to hold. A second person read the diff. The ticket does not say certified. The next finding has a date or is explicitly parked. The hostname in the prompt matches the hostname in the ticket for a security configuration review. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for a security configuration review happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
- DMARC Aggregate Report Analyzer
- DMARC Forensic Report Analyzer
- Dockerfile Security Auditor
- Kubernetes Manifest Security Auditor
- Terraform Security Auditor
- GitHub Actions Workflow Security Auditor
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- Checklist: How to Read DMARC Aggregate Reports
- Checklist: How to Read DMARC Forensic Reports
- Checklist: Dockerfile Security Review Checklist
- Checklist: Kubernetes Manifest Security Review Checklist
- Checklist: Terraform Security Review Checklist
- Checklist: GitHub Actions Security Review Checklist
- Checklist: Conditional Access Policy Review Checklist
- Checklist: JWT Security Review Checklist
- Checklist: TLS Configuration Review Checklist
- Checklist: Security Policy Gap Review Checklist
- Checklist: How to Evaluate Vendor Security Questionnaire Responses
- Checklist: Sysmon Configuration Review Checklist
- Checklist: Sigma Rule Quality Checklist
- Checklist: How to Improve Microsoft Secure Score
- Checklist: OAuth App Permissions Review Checklist
Companion: System: Server Hardening & Audit Guide.