Introducing openRMF — Managing your RMF Compliance
When documenting your security and risk of DoD and Federal systems and applications, the process of managing your STIG checklists, artifacts, SCAP scans, NESSUS scans, and other manual checklists is a massive PITA. Having a bunch of XML files, checklist (CKL) files, Excel spreadsheets, and emails combined with the looming deadline of submission combine to make things tense. And the manual way this is currently done across industry and government agencies makes it even worse. openRMF aims to alleviate that headache by allowing all groups to manage their security findings, import scan results, report on findings and status, generate RMF compliance, and be the single-source-of-truth for system information when it comes to RMF. All available from a web browser on your local system! (The enterprise version is on its way, read below)
Defining the Problem we are Solving
About 14+ years ago my great friend and colleague Dave (@tutelasec) and I were working on a project where we had to do this new application security and development (ASD) checklist. There were a bunch of questions asked, a status of “not a finding”, “open”, “n/a”, and the default “not reviewed”. And it had this HORRIBLE Java user interface (UI) that was clunky at best. But we had to do it. So we filled in findings and comments, updated status, and then exported to CSV and then imported to MS Excel to send around to management. What a manual PITA!
Fast forward to today: people are still doing that! I did that last summer and it bugged me! And I knew there had to be a better way. If you want the play by play of how this unfolded you can check our website. The challenge here is that managing all these artifacts for even a single system takes a lot of time and manual processes. A cybersecurity person in charge of a system or systems has to track multiple checklists per machine and application in their system. A “system” usually involves multiple servers, network devices, applications, and technologies. And for each of these there are usually multiple checklists!
Try managing that for a small system of 10 servers. And remember each server will have an average of 5 checklists per host/server, applications that that run on those servers (database, web, service application, file server), and network devices they communicate through (F5, router, switch). So that is 50 checklists not counting any additional custom application ASD checklists that you have to add in. For a smaller system you could be managing 75 checklists. In that Java UI tool from DISA that requires the right version of Java and the JAR file to run. For every single person that wants to view the raw data from those 75 checklists.
Now for each of those, picture the work involved to summarize the data and manage the updates as things move from Not Reviewed, to Open, to Not a Finding. And in the middle of that, for each checklist, respond to many managers and customers asking “where are we on our RMF process” so you have to export information to Excel. Or WORST, update-by-hand the number of counts of items and the last updated date so they know the status of their system accreditation process. All manually. Granted I have heard of people here and there making Powershell scripts or Excel macros. However, that is not an enterprise-ready way to do all of this and the people doing that are few and far between. And when a security assessor asks for your information, even they need your checklist raw data! You see the challenge here: vast amounts of information, all in files, manually thrown together and managed individually.
This description above is the challenge that openRMF is working to alleviate. Through automation, consolidation, and management of information quickly and easily.
Who this tool is for
This tool is for cybersecurity personnel who have to track all these checklists, compare them to scans, export reports to MS Excel, and do this across a large set of data for 1 or more systems. It can be overwhelming.
This tool is for the security assessors who have to take all these checklists, and comb through them to find out if the scans match the checklists and the documentation given them. And then ask for a POA&M on reducing the open findings for a lower risk of a system.
This tool is for IT personnel who have to fill out these checklists and email multiple people to ask where the latest CKL file is so they do not use old data.
And this tool is for managers of people who are filling out these checklists and running these scans. So they understand the scope of the work, the current status, and the areas that need the most help and improvement. And so they stop bugging the other 3 types of people above and can do their reports, emails, and meetings with the most up-to-date information available.
Benefits of openRMF
Tired yet? Shaking your head? Ticked off that it is 2019 and people are doing this manual work? That major systems across the US government have to go through this process to accredit systems? That a recent colleague of Dave had a team member go across 75 of these types of checklists to generate compliance against the NIST Controls by relating vulnerabilities to CCI to NIST controls and it took him 2 1/2 weeks? (And when we ran the same checklists through openRMF for comparison we found things he missed manually!) You should be upset, especially if you have been a part of these. I was and still am. And Dave is for sure as he is living this day in and day out. So around December 2018 we started developing this tool in its current form. It is still in beta (as of this article we are working on v0.7), and we welcome you to pull down the latest release and run it. Better yet, go to https://github.com/Cingulara/ and check out all the openRMF repos and jump on in!
The benefits here are automation. I started Cingulara because I really detest doing things manually when there are ways to automate the mundane and focus on value-added steps when performing processes like this. So we automated a few things and created several more benefits as openRMF morphed into what it is currently. The main functions and uses of the current openRMF tool are listed below. And this tool is open source under GPL-3.0 right now for you to use. Today. As you read this line right here! (There is a quick video intro and demo at the end of this.)
- Upload your CKL checklist files to a single source of truth, and download when you need
- Automatically export your checklist to XLS and have things color coded by status (matches the web UI)
- List all your active checklists by system
- Export your count of items per checklist by status and by category (CAT 1, 2, 3) which people do not even do really now with large systems as it takes too long manually
- View your checklist individually and filter by status on the vulnerability listings which are color coded
- Generate your current Compliance with NIST 800–53 per system by running all checklists against the major controls, and list out the checklists per Major Control color coded by overall status (see image above)
- View a checklist from your compliance listing and only show the vulnerabilities for that Major Control to know what has to be worked (Big deal here as doing this manually causes you to miss things!)
- Do all this with a web browser only (the CKL files, for now, have to be done in the Java UI tool from DISA and then uploaded)
- Allow managers, project leads, tech leads, and even customers (if you dare!) have a view into your current progress without interrupting your work to get things done
How openRMF works
As I said earlier on our website, the summer of 2018 on my vacation saw me sit down and focus on this problem here for a few days. When I saw what I had done on my laptop in VS Code with .NET Core I was happy I had finally started, but knew it was not right. I just did not know why. Then in December last year I rebooted that idea with a more distributed architecture using APIs, containers, NATS (I love that tool!), and a web frontend using HTML/CSS/JS. I liked this much more and saw power in it to scale pieces I need, update small pieces at a time, use messaging and eventual consistency, and allow growth incrementally as needed to allow it to morph into what is today openRMF.
Currently openRMF is launched with a docker-compose command in a shell script (or command file if on Windows). It uses about 9 microservice APIs, a web frontend using NGINX, a few MongoDB databases for 3 of the APIs, and the NATS messaging server (not streaming as of yet) to communicate on a few things. It launches this locally using http://localhost:8080/ and lets you right in. There is no AuthN/AuthZ as of yet. There is persistence of data with Docker volumes for the databases. All our latest images are up in DockerHub for you to pull down. And there is a “development” version using the latest images up on DockerHub as we release updates toward our next version.
It would be easy to modify this to run in k8s or OpenShift which I have on our soon-to-be roadmap up in GitHub, subject to change. We have several things coming up by the end of the year to make it a solid enterprise offering which I outline at the end of this. However, we are where we are now on a side-project I am working with Dave to make this time-wasting problem go away. And get people to the point of focusing on the act of actually securing their systems and networks.
Secondary Reason for openRMF
Full disclosure: there was also a selfish reason I made this tool. I wanted to get better at automating and deploying a microservice architecture such as this. With multiple APIs, a static HTML/JS/CSS website (eventually with a JS framework like VueJS), and a NoSQL database like Mongo. However, I wanted to do this while solving a real world problem. And get better at that type of architecture and learn its quirks, pitfalls, benefits, and hidden pieces you need to know for a closer-to-12-factor application. So, this is an application that the company will use to learn and test new technologies where it fits. Not just for technology sake, but where it makes the most sense. For instance, right now all pieces are in .NET Core. I plan to rework some in Golang and Rust and NodeJS to get better acquainted with those languages and possible replace the .NET Core APIs/messaging with those where it makes the most sense. I also need to export logs and stats to Prometheus and add that in here as well. And I need to possibly use Request/Reply in NATS or use the NATS streaming engine. I really am excited to see NATS 2.0 with JWT and security features coming and implement pieces of that as well.
The one thing I did not have in my tool belt was a distributed architecture with eventual consistency and a real world example to use it. And that bugged me. So I fixed that. And now I do even if with a simple example. It is very eye opening on how you architect these and how you can use messaging with something like NATS to grow your application without a lot of heartache and rework.
Where we are Headed
This tool right now is usable for an individual group or system. Really, it is. I know people even right now using it to save hours of manual work on reporting their system status on RMF compliance up the management chain. However, to make this truly a solid tool and get to an enterprise ready tool, we need to add a few more pieces.
- Deleting checklists / systems
- AuthN
- AuthZ
- Defined Roles and actions
- K8s and OpenShift YAML configuration for automating deployment
- Importing of NESSUS scans for updating checklists / system compliance
- Importing of SCAP scans for updating checklists / system compliance
- Export the Compliance Generator (which runs in seconds! I am glad to report) to Excel
- Eventual consistency of the compliance generator as you build and add your system checklists behind the scenes
- Editing the Checklists via the web, with AuthN/AuthZ and RBAC to only allow edits by certain groups
- Template/Wizard to ask questions and have a starting point for your checklist (i.e. “Do you have SOAP/XML” and if no, the ASD checklist has 15 items that are N/A)
- Archiving system checklists over time
- Much, much more…
Where to go from here
Want to try it out? Go to the release tab in GitHub and pull it down to run. Test it out. Run it locally. See what you like and don’t like. Add issues, questions, suggestions, etc. up in GitHub in the proper repo. Or just add to the openrmf-docs repo and we can update where it needs to be.
If you are a developer and want to jump in please do! Check the project board, grab something, fork the proper repo, and go! If you need something please ask. I also have a Slack channel you can use. I just need you to send me a note on wanting in. I need to make a sign-up like others have done using the not-documented Admin API for Slack as well. That will be coming up soon for sure.
I look forward to hearing about people using this tool and how much time and frustration it saves them. How it can help people do more and manage more projects while maintaining a view into the current status in an instant. How it sped the progress to their submission for an ATO or approval for their organization or company. And how it led them to a better security footprint on their system and their network.
I hope you find a way to use it and pass it along to others. It is a tool whose time has been coming for a long while!
