In part one of this three part series, we’ll cover some term and meaning as they relate to STIGs and SRGs
DISA (Defense Information Systems Agency) is a Department of Defense Combat Support Agency charged with providing information technology and communication support to the President and Vice President of the United States, all the different US military services and other systems and organizations that help to provide for the defense of the United States.
STIGs (Security Technical Implementation Guide) are the guidelines that DISA publishes for certain components of information technology and communication infrastructure used by the defense community that DISA supports. STIGs are a cybersecurity method for securing network protocols, computers, servers and applications which are used to maximize overall security. Or said more simply, they’re collection of lots of specific settings that should be employed to make a specific IT system, application or network component more secure; or less insecure if you prefer.
SRG is short for Security Requirements Guide. They’re used as a sort of overarching security methodology for a type of technology, such as a web browser. They’re full of general statements and recommendations on how to secure a type of technology, without calling out a specific flavor or vendor.
While a STIG would tell you specific settings to lockdown, say for Windows Server 2016, an SRG would provide a guideline for how to secure an operating system in general. So in the absence of a relevant STIG, an SRG would be used.
Now that we’re familiar with these acronyms, why do we care? Why did you just read all this? Because DISA works in coordination with the NSA, NIST and others to determine settings and configurations in commercial products that either have defects or vulnerabilities that could be exploited if not set to a tighter configuration, or are deemed so risky that they should be turned off altogether.
STIG’s and SRG’s are excellent ways to secure your environment no matter how big or small your organization. The second biggest reason you should use them is that they’re free to use. All the work that goes into almost any federal program is tax payer funded, so why not check them out and see if your environment is as secure as the DoD’s.
In the next post I’ll go over how you can get ahold of these tools and get something back for your tax dollars. I’ll also explain how you can get these settings for many of the Microsoft products in a prebuilt GPO that you can download right from their site and import to a test environment to put through the paces and see how they can work for you.