2. Security Guidance
2.1 Security Guidance
Before we go further, let's discuss what we mean by "security guidance" and some of its characteristics that matter to us as security (and automation!) practitioners.
Security guidance is documentation that defines what constitutes a secure configuration for a software component or category of components. It includes organizational requirements for security, best practices, and instructions on how to fix problems. It answers the important question that all developers and engineers ask when they want to secure their software -- "What counts as 'secure' for my system in the first place?"
Most software projects will (or at least should) align themselves to a particular source for security guidance and follow it as a baseline that answers this question. For example, many commercial companies (and even some civilian government agencies) use the Center for Internet Security Benchmarks (CIS Benchmarks) as their baseline, while software deployed by the US Department of Defense is required to comply with the Defense Information Systems Agency's Security Technical Implementation Guides (STIGs), broadly speaking.
There are many different types of guidance documentation available to software developers. Software vendors often publish best practices guides, administration guides, or business requirements documents to instruct their userbase on how to best make use of the product. Security guidance is ultimately just another type of guidance document for effectively using a piece of software.
Other Guidance Sources
Have you used security guidance documents from other sources besides the ones mentioned here?
Security Requirements Are Functional Requirements!
Software developers have a historical tendency to consider security as a completely separate activity from the basic process of building a software product. In a DevSecOps environment, however, security is just another functional requirement of your code.
You cannot ship code if it does not meet a functional requirement. Likewise, you cannot ship code that does not meet a security requirement!
This class content will be giving heavy focus to STIGs, since Vulcan was originally created to address pain points in the authorship process for STIG documents (which we will describe in detail a little later). We assume that most of the students who engage with this content will be working on government projects that require securing systems to "STIG standard," or that the students work for software vendors who need to write such guidance. However, the principles behind what makes a quality STIG can be applied to security guidance of all kinds, and we hope you can take the lessons here and apply them to whatever guidance you create for your software.
2.1.1 Organizational Policy vs. Baselines
Many organizations that use popular security guidance documents as their baselines have their own specific organizational security policies that conflict with that baseline. For example, consider the following requirement in the STIG for the Red Hat 9 operating system:
SV-258055 - RHEL 9 must automatically lock the root account until the root account is released by an administrator when three unsuccessful logon attempts occur during a 15-minute time period.Let's say that the organization that you work for wants to enforce STIG requirements on its systems, but it also has its own internal security policy that is even more stringent than the STIG -- the root account should lock after two unsuccessful logon attempts in 10 minutes. This is a common situation in the wild, where your system might fall under multiple overlapping (or conflicting!) requirements.
Consequently, many government agencies use baseline security guidance as foundations to create their own tailored content for in-house use. In addition to Vulcan's usual workflow for creating new baselines, you can use it to ingest a published baseline document and conduct this tailoring process to create security guidance tailored to your organization.
Automating Overlay Validation
You can check out the Beginner Security Automation Developer Class for examples of how to write automated validation code with InSpec that is tailored from a baseline.
2.2 Finding Security Guidance Documentation Baselines
Commonly used security guidance is often available on the open Internet.
- CIS publishes its popular Benchmarks for free with registration (in PDF form, other formats require a subscription to CIS's SecureSuite)
- DISA publishes all STIGs (and all the rest of its security documentation materials) for free on the DOD Cyber Exchange public web page.
- DISA distributes STIGs as a set of PDFs describing metadata like a changelog and cover sheets, where the underlying STIG itself is stored as an XML document.
- NIST's National Checklist Repository (NCP) is a repository of securit configuration benchmarks and are publicly available.
Your first question when planning for securing your software component should always be "is there already published guidance documentation available for it?"
2.2.1 What Do I Do If There Isn't Already Published Guidance Documentation Available For It?
If you need to secure a software component that does not have a published guidance document already, your best strategy is to find the next-closest guidance document and use it to inform the content you create. You can think of the process of writing security guidance as an open-book test; you should feel free to borrow the best ideas other from other baselines!
In the case of STIGs, DISA's official guidance (as per their FAQ) states to check for a STIG for an earlier version of the same software and modify it as necessary.
Therefore, where no guidance exists, use the closest reasonable baseline.
2.2.2 What If There Are No Reasonably Close Baselines?
Then use Vulcan to make some. Good news; you're already reading the instructions on how to do that.
2.3 Wait, Aren't These Classes About Automation? Why Are We Writing Documentation?
One of the overall goals of the Security Automation Framework is to get people writing quality security automation content, not just any old hardening scripts and test suites.
In formal government assessment settings, you will need to prove that you are covering particular categories of security controls with your activities. You can only do that if you build your automation content around a well-built security guidance document that itself heavily references all of your upstream requirements.
Therefore, the Planning capability of the SAF -- dealing with the selection and creation of security baselines for automation -- is a critical component of the overall framework, even though it itself is not automated.
The Plan capability comes first in the list because every other capability needs to refer back to it!