Automatically relate NIST Families and Controls to your DISA STIG Checklists with OpenRMF
If you have ever spent time on a team that was going after an Authority to Operate (ATO) to run their system on a Department of Defense (DoD) network in recent years, you probably have seen (or heard about) the Risk Management Framework (RMF). This is put out by the National Institute of Standards and Technologies (NIST). It is a common security framework to improve information security, strengthen the risk management of systems, and encourage agencies to trust ATOs to shorten timelines of systems in use.
And if you have been a part of any of these teams even in a small way, you know it is a very painful and manually-intensive process of checklists, documentation, and fact checking to make sure you implement the NIST controls. And you must validate them by showing relevant documentation and DISA security checklists. In addition, you continuously monitor this information over time to ensure compliance. It is very time consuming to do all of this.
In this article we explain the process of relating NIST Controls to DISA checklists, how a lot of groups do it manually, and how our 100% open source tool helps to automate this process to shorten your timelines.
The Problem: Relating STIGs and CCIs to NIST Families and Controls
When you have a system that needs to be authorized on DoD networks, you have to follow the high level process outlined just above in the diagram shown at a high level. For those of us that are in the IT industry for DoD this sounds all too familiar. First you categorize your system in eMass (High, Moderate, Low, does it have PII?) and then you select the NIST control families you must implement. This is the left side of the diagram above. You are left with a list of controls to implement for your system.
Then a separate process is started, defining what technology stack(s) you have in your system so you know what DISA STIG checklist(s) you have to use along with other documentation to show compliance with all the NIST controls you need to implement.
Based on the technologies/software in your systems you have to go the STIG download area and pull down the checklists for your software stack such as Windows, Linux, Oracle, .NET, Java, and the like. This is the right side of the diagram above. Unzip those files, pull out the relevant checklist files, load them into the Java-based STIG viewer and then start to create your checklists via the STIG viewer.
Then comes the hard part: you have to relate them. You link the individual checklist items to the NIST controls to ensure you are implementing them correctly. If you have had any part in doing this for DoD authorization on systems you know the pain and black magic involved in these processes all too well!
Ok, so you have your controls and you have your checklists. We need to relate the two. So how do you do this? To relate the DISA STIG checklists to the NIST Families and Controls you need to visit the https://public.cyber.mil website and download the CCI XML file. That XML file has a list of all Control Correlation Identifier (CCI) items and their corresponding Control Family items. NIST has the control families. DISA has the checklists. This file relates them and shows you the relationships between them.
Each DISA STIG checklist has multiple items, and each item has one or more CCI items listed for that checklist entry. See the screenshot below showing an example of an Application Security & Development STIG. The highlighted entry shows the CCI and NIST Controls that checklist item covers. This item has one CCI 001453 and it points to the AC-17 control. And that is for that one item in that one checklist! Repeat this a few hundred times or so and you see the manual process we are talking about.
Once you start to put together all your checklists for the software and servers in your system, you now need to report on them to your NIST controls to show which are satisfied and which still have work left to be done. How do you show a control is satisfied? Well, for each control (i.e. AC-2 Account Management) you must show how any checklist that has a CCI which relates to AC-2 is either “Not a Finding” or “Not Applicable”. If any of the checklist items that relates to AC-2 is either “Open” or “Not Reviewed” then the control is not yet satisfied. If it has to remain open, then you need documentation as to why and a possible plan on eventually satisfying the control.
For many of the teams I have worked with over the last few years (including a small team in 2019), this is a manual process that takes weeks to do! And then you have to keep up with the controls and the checklist items as you update systems, software, patches, and processes. <Insert face palm emoji here!>
If you are not exhausted in just reading all that, try doing it! Do this for a small system that has 15 servers (or virtual machines) and an average of 5 checklists (Windows, Java, .NET, IIS, SQL Server, Webserver, etc.) per server. Relate those individual checklist items to the controls and make sure they are all valid and accounted for as your system approval depends on that information. You will be in checklist hell with some Excel spreadsheets, emails, and a custom grown application or two trying to make sense of this all. With a looming deadline and project managers asking the status as the date for delivery draws closer.
There HAS TO be a better way! This is too slow. There are too many things to relate manually. There is no single place to manage all the information. And management cannot see the status without bothering us. That is why we made and keep improving the fully open source OpenRMF tool.
The Solution: How to Automate Parts of the NIST Control to STIG Process — OpenRMF
When my buddy Dave Gould (white hat hacker, cybersecurity guru, system and network admin) at Tutela and I (software engineer, computer geek) began talking on this horribly manual process about a decade ago (2004) we knew someone had to automate it to make it more manageable. When no one stepped up to do that, we decided to stop complaining and do it ourselves. That is where the OpenRMF tool comes in.
The impact of OpenRMF is shown in the diagram below. We greatly influence the areas highlighted in the purple color. You know, the highly manual parts of the process here! You can import your checklists, manage them by system, see the number of items Open v. N/A v. Not Reviewed v. Not a Finding per STIG Category (1, 2, 3). And you can generate a compliance report that automatically correlates the high/moderate/low and PII information to the relevant controls you need to satisfy by default. We are working on more automation of the processes involved (see later in this article) to help take the mundane work out of this. And work on keeping the value added steps where you relate the open items, the risk assessment report (RAR), the plan of actions and milestones (POA&M), and similar information to secure your systems.
With this tool you have a 100% open source solution to help you manage all this information in one place. A single source of truth that is not a mix of email, checklist files, excel, shared folders, and reports. It can automatically relate DISA STIGs to NIST RMF Control Families, and automatically organize checklists by system. All from a web browser with role based access control.
This tool can be installed locally on a laptop (using Docker), on premise, or in any of the main cloud providers that support containers. This tool helps remove the IA mystery and easily find errors and deltas across checklists in minutes. We have done this very thing at Tutela, showing a self-contained system had duplicate server names in their workgroup setup.
Here is a great example on use of OpenRMF: One user of this tool spent over 2 1/2 weeks manually aligning those CCI items and DISA STIG checklist statuses to get their final documentation created. As a test, we had them spend 5 minutes loading their 75 checklists, run the OpenRMF Compliance Generator (add 1 more minute in there) and it found an error in one of the control status entries that was incorrectly marked “satisfied”. They still had an open issue in the access management area of one part of their software.
They were both frustrated and happy all at the same time! And they corrected their issue and moved forward more confident in their system. That is a big deal. And a huge time saver. And lends value and trust between the creators of the system and the assessors of the system.
Next Steps Toward more Automation of this Process
So where else are we going to squeeze out more automation? Well, there are a few areas below we are currently working to move this much-needed-but-far-too-manual process into the current decade:
- Importing SCAP scans to create or update checklists
- Storing the SCAP scans in one single source of truth
- ACAS (patch management) uploads to show results
- Logging and Auditing across the system for compliance and history
- More detailed reports
- Exporting a Risk Assessment Report (RAR) automatically
- Generating an POA&M on fixes and dates proposed for compliance on “Open” items
- much more as this process unfolds…
Test it out yourself!
If you want to see how this tool works you can certainly visit the website for more information or jump right to the GitHub repos for this tool. Or you can go to the demo site, make an account, and get a read-only test of the software.
It is still in beta now and we are updating it as we go. If you want a more thorough demo of the tool please do not hesitate to reach out on Twitter to ask. Or put in GitHub issues for much better documentation. We are working on the tool’s documentation, the logo, the functionality as well as API endpoints for integration with other tools.
We hope this helps you shrink your timeline and automate away some of the headaches in managing your STIG Checklists and documentation toward a successful DoD ATO using the RMF process. Yes I put all those acronyms in there on purpose!
