STIG-08 · EXPERIENCE
I harden Windows, Linux, and network systems to DoD STIG
I take systems from "probably fine" to "proven compliant." I apply DISA Security Technical Implementation Guides across Windows, RHEL, and network devices, run SCAP scans to confirm the settings actually landed, and leave behind evidence that maps each control to its source. No guesswork, no checklist theater, just hardened systems you can defend in an audit.
01 · What I do
The actual work
- Apply DISA STIGs to Windows Server and desktop, RHEL and other Linux, and network gear like Cisco routers, switches, and firewalls
- Run SCAP scans with the SCC tool and review results in STIG Viewer to confirm each control is actually set, not just assumed
- Triage findings into pass, fail, and not-applicable, with a written justification for every exception and open item
- Map STIG controls back to NIST 800-53 so the work lines up with your authorization and RMF requirements
- Write a documented change plan with rollback before touching anything in production, then apply controls inside a defined window
- Capture compliance evidence per control: scan output, screenshots, and config snippets tied to the specific finding ID
- Re-scan after remediation to prove drift is closed and the box meets the benchmark
02 · What you get
What you are left with
- Systems that pass a SCAP scan against the right STIG benchmark, not a partial pass with hand-waving
- A documented exception list where every not-applicable or open item has a written reason an auditor will accept
- Per-control evidence packaged and tied to finding IDs, ready to hand to an assessor or ISSO
- A clear before-and-after: what was failing, what I changed, and proof it is now compliant
- STIG settings mapped to NIST 800-53 so the work plugs straight into your authorization package
03 · Tools and knowledge
What I work with here
04 · How I approach it
Planned, scoped, and owned
It starts with a 30-minute scoping call and a same-day written fit assessment so we both know the scope, the target benchmarks, and the systems in play before any work begins. From there I build a documented change plan with a rollback for each system, since STIG settings can break things if applied blind. I apply controls inside a defined window, validate against the SCAP scan and the gates we agreed on, and I own the rollback if a control causes a problem in production. Every control that passes, fails, or gets marked not-applicable is recorded with its evidence, so the end state is something you can stand behind in an audit instead of a box someone "hardened" once and forgot.
05 · Questions
Good questions, straight answers
Which STIGs and platforms do you cover?
Windows Server and desktop, RHEL and common Linux, and Cisco network devices including IOS, NX-OS, and ASA. If there is a published DISA STIG for the system, I can apply and validate it. Application and database STIGs are doable too, just tell me the stack up front.
Will hardening break my systems?
Some STIG settings can, which is exactly why I do not apply them blind. I build a documented change plan with a rollback, apply inside a defined window, and validate against gates. If a control causes a real problem, I roll it back and document it as an exception with a written reason.
Do you leave evidence I can use for an audit or authorization?
Yes. That is the point. You get SCAP scan output, per-control evidence tied to finding IDs, and a justified exception list, with STIG controls mapped to NIST 800-53 so it drops into an RMF package.
06 · Related experience
Adjacent work I do
Need this handled?
Tell me what you are trying to move and where it is stuck. A few sentences is plenty to start, and it goes straight to my inbox.