An email hits your inbox that immediately makes you feel dread wash over your entire body. Its from your PCI auditor, and they want to book the first meeting to discuss the new requirements of PCI 4.0.1. I'm talking about you, of course. Me? I actually like Audit work. I know, I'm weird.
There are many, MANY new requirements with PCI 4.0.1, too many for me to cover off in a single blog post, but there was one requirement that piqued my interest, the Hardening Requirement. In discussing with my auditor last year, the essential premise of the requirement is that your systems have to be hardened against an actual standard, not just the "industry standard" guideline most companies try to follow, but something from ITIL, NIST, or your vendor's recommended configuration.
A while ago, I came across STIG's, which isn't just a mysterious Professional Racing Driver.
It stands for Security Technology Information Guidelines, which is a series of recommendations published by someone who knows what they're talking about. A more rigid definition is as follows:
A Security Technology Information Guideline (STIG) is a documented set of best practices, standards, and recommendations for configuring and securing information systems, applications, and networks. These guidelines are designed to minimize vulnerabilities, enforce security policies, and ensure compliance with security frameworks such as PCI DSS, NIST, or ISO 27001.
Key Characteristics of a Security Technology Information Guideline:
- Standardized Security Configurations – Defines how systems should be configured to reduce risks.
- Compliance-Oriented – Aligns with regulatory and industry security requirements.
- Risk Mitigation – Provides guidelines for mitigating known security threats and vulnerabilities.
- Applicable to Various Technologies – Covers hardware, software, operating systems, databases, and cloud environments.
- Regularly Updated – Adapts to emerging threats and technological advancements.
A well-known example of security technology guidelines is the DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) used by the U.S. Department of Defense.
That last example is what piqued my interest even more, as I not only had never dealt with a STIG before, but I was curious what the US DoD would have to do with it. It didn't take me long to have my mind blown.
The DoD Cyber Exchange site has a surprising volume of information that can help almost anyone harden their Infrastructure; Linux Servers, Cisco Router's, Browsers, even .Net applications. Wow! The thing that impressed me the most is the tooling the DoD site has to get up and running quickly, to start running baseline comparisons against servers in your environment.
The tinkerer in me couldn't help it, so I got into my home lab and started working away, and before I knew it, I had a working automation pipeline using Ansible that was securing every server I had against a DoD baseline. My Desktops, Windows and Linux Servers, all being secured by the same tool.
I decided to make my 1st multi-part blog series, where I go a lot more into the technical side of things to show how you can set this up in your own environment from scratch, the tools you can use to make your life a bit easier, and give you everything I learned going through the process in an easy to follow format.
If you've made it this far, and you're interested, then get strapped in, because this is going to go by fast!
