DevSecOps, RMF, and OpenRMF

OpenRMF can fit into your DevSecOps process in several unique ways to help you with Risk Management Framework (RMF) and your ATO (Authority to Operate) process. It helps you manage security, compliance, reporting, scans and data calls in a much more automated fashion. This article takes the view of Risk Management Framework (RMF), looking at DevSecOps, through the lens of OpenRMF Professional.

DevSecOps, RMF, and OpenRMF working together to automate cyber compliance.

RMF view of DevSecOps

Thinking of RMF and DevSecOps as continuous processes, the use of OpenRMF Professional (or even the OSS version) helps you frame parts of the DevSecOps process for RMF in particular. In this article, we lay out the various places we see OpenRMF Professional fit into DevSecOps that can help you in your RMF processes and documentation as well. And we explain the DevSecOps side, the RMF side, and then the merging of those through the lens of OpenRMF Professional.

Honestly this works for RMF, FedRAMP and a host of other frameworks as it pertains to cybersecurity and compliance. And remember, (enter soapbox stage right…) compliance is not the same as being cyber secure. Do not get me wrong. It is important to do. And usually you are contractually obligated or policy obligated to do so.

However, if you are cyber secure more than not you are compliant (plus more). This article and OpenRMF in particular helps you get there. Cyber compliance is not the end goal…a secure system is! (Off my soapbox…)

Now let’s break down the parts of the DevSecOps process and see how OpenRMF Professional helps you in each area!

Plan

During planning as a software engineer or anyone on that side (project manager, scrum master, cyber personnel) you are thinking what is my application stack now and future. What are my software pieces I need to update or upgrade. What does my network look like for servers, devices, and ports/protocols used. What impact level is my data. What classification is my system. What is the mission category of my application (who uses it, allowable downtime, workarounds when offline). Things along those lines.

And then bring in RMF: what STIG checklists (new or updated) do I need to fill out to document those things. What NIST Control families and controls / subcontrols do I have to comply with. How do I need to track all of that. That is a lot of stuff to manage in scans, files, Excel reports, PDFs, and file folders to keep it all structured and organized.

This is where OpenRMF Professional comes in. To help you manage the information that you need to collect while doing the next steps in DevSecOps. You can merge RMF and DevSecOps through the lens of OpenRMF Professional in a few ways to make your life easier and automate the planning and staging of your RMF artifacts. Get this correct up front, and the rest of the processes are much easier to track and manage for sure!

Use OpenRMF to do the following:

• Create (or update) your system package as far as title, description, C-I-A level, milestones to track, etc.
• Create a list of default or tailored controls as well as overlays
• Add checklists or templates of checklists with pre-filled data, boilerplate information, and locked vulnerabilities to match your controls and overlays you decided upon

Now you are ready to house all your cyber compliance data easily, in a web-based interface, where we automatically track changes, total open vulnerabilities, and allow reporting for presentations, data calls, status, and laying out tasks to work.

Code

During the coding process you are tracking your code changes, OS changes, server changes, and software changes, while (hopefully) noting the security requirements to make your software work correctly. You are working with your DBAs and system administrators as well as network administrators to set least privilege access, control data, control security and audit your data changes. And you are noting what services, accounts, ports/protocols/services (PPSM) you need to use. (At least you should be!) This is just to get your software to work correctly, then work correctly under a secure environment.

Again bring in RMF: you have to note this data in design documents, network diagrams, and scripts for deployment and setup. And you must note the security pieces against the Application Security & Development STIG, database STIG, server STIGs and network device STIGs. Even some of the manual processes in RMF have to be documented here for proper RMF compliance.

Using OpenRMF Professional you can do the following Code functions of DevSecOps wrt RMF:

• Track the checklist updates required from above in the application through editing the checklists manually
• Track checklist updates through SCAP scans turned into checklists automatically
• Through tracking patch scans that generate your ports and protocols information automatically
• And through running compliance reports and data reports to note vulnerabilities, non-compliance against controls
• Starting or updating your POAM automatically to track the work required

Test

For the testing phase, we are required to make sure the software works from a DevSecOps perspective. And make sure it works as documented, as required, within the security guardrails we have in front of us.

With RMF you are still testing compliance against your default RMF controls or tailored controls, adding in any overlays you require. And if you are doing this by hand (SMDH) then you are tracking checklists and CCIs from vulnerabilities against a list of CCIs that map back to controls and subcontrols. And this process is PAINSTAKING to say the least. I pity those that still do this manually. It is very tedious. Please stop. Use one of the OpenRMF versions to help you here!

Enter OpenRMF Professional. Here you can perform the following Test functions of DevSecOps wrt RMF:

• Track your checklists
• Make changes to checklists
• Automated history engine tracks all changes to checklists and who/what/where/why they were done
• Run compliance against your known control set
• Turn on/off overlays to see the impact of controls against what you have within your checklists as well

You can even use the Custom Checklist Template engine to make checklists that are not available by DISA and get more out of the compliance engine. Think about having a Program Management checklist or Incident Response checklists and being able to track compliance in an automated fashion versus manual documentation only. Now the PM and IR controls you need can be shown as compliant or non-compliant and the areas you need to work on. Imagine that!

Release

The mapping of this concept to the Release in DevSecOps is similar to the Test phase. I won’t bore you with repeating it. In addition, you can have this compliance run and look for it to come up clean (whatever that definition is to you) with proper mitigations and POAM entries before you allow code to be released and/or deployed. It is almost a manual gate that has to be complied with before the cyber personnel sign off on the changes that are going to production.

Using OpenRMF Professional you can do the following Release functions of DevSecOps wrt RMF:

• make sure your cyber personnel review the POAM and dates for changes, compliance generation, mitigation statements as well as the PPSM listing to know what ports and protocols have changed (if any) before pushing to production
• Run this compliance and reporting on POAM items, vulnerabilities, and PPSM once software is released through the reporting mechanisms within OpenRMF
• Run reports and compliance for data calls and questions from cyber personnel

Deploy

For deployment of applications and configuration, you have to track changes with auditing. You need to deploy and make sure your automated deployment matches your plan and code as well as security. And you must answer questions asked from management, data calls, cyber personnel, as well as regulation and policy questions as they arise.

You also may need to answer questions against known or new CVEs and vulnerabilities as well as ports and protocols open and used across boundaries. And your POAM items must be tracked, updated, and reported on to various personnel as well.

OpenRMF Professional helps you here by performing the following for the Deploy stage of DevSecOps wrt RMF:

• Auditing of all changes of RMF related information through OpenRMF
• Reporting mechanisms for tracking vulnerabilities, performing data calls, and tracking POAM items as they are worked, mitigated, and completed automatically

Operate

Operation of the application and tracking/supporting it is front and center in DevSecOps. “Ops” is right there in the name! You have to support what you build, test, and deploy. And your security posture needs to remain even after deployment, even with new CVEs and security requirements and customer support requests come in.

RMF is (supposed to be) continuous just like the DevSecOps process is continuous (it is in an infinity symbol on purpose). It is not supposed to be a “once a year” or “once every three years”. With RMF you should be scanning your system for patches. Tracking changes in PPSM and software versions. Tracking your hardware and software bill of materials (BOM). And showing your compliance is still where it needs to be.

In the Operate area, OpenRMF Professional supports with several features that help toward RMF:

• Uploading SCAP and Patch scans to track security — in v2.6 coming out in October our external API lets you automate ingest of those into OpenRMF Professional as well!
• Managing vulnerabilities
• Reporting on data within scans and checklists easily
• Tracking changes in PPSM, security, patches, software listing, hardware listing
• Running compliance as you go so you are not caught off guard on security issues while your software is in use!

Monitor

Monitoring your applications is still important in DevSecOps. It is on the operations side and must be done to make sure your application is doing what it is supposed to do. The way it is supposed to. With the correct security in mind while performing its mission. This is no less important than any of the other pieces in DevSecOps even though we list it last in this article.

With RMF you must do continuous monitoring. That means tracking your changes. Tracking your patches. Tracking your known open vulnerabilities. And showing that you are working to patch them and fix them as time goes on. You do not just “set it and forget it” in DevSecOps or RMF.

For the Monitor area, OpenRMF Professional performs these key functions in addition to the great ones already mentioned just above in the Operate area wrt RMF:

• Automated notifications of updated checklists, vulnerabilities, scans, and PPSM changes
• Automated POAM as patches and checklists/SCAP scans open and close vulnerabilities to show their status as they change (without a human having to manually do it)

Conclusion

As you can tell from above, using OpenRMF Professional around RMF and DevSecOps helps you save time and money. It also lessens anxiety around storing checklists and scans and tracking changes. It helps you know what you have to do at what stage. And it stays with you toward continuous monitoring, continuous development with security, and even works toward a more continuous ATO process (more on that in a later article).

What about the Build part of DevSecOps you say?!? We will be adding that in a future upcoming release of OpenRMF Professional so that also can help RMF look into DevSecOps through the lens of OpenRMF. Don’t worry! We will update you on that also.

Check out OpenRMF Professional and see if it fits your group or organization’s goals of reduced time, reduced cost, and automation around the RMF and FedRAMP processes. Test out what I put above for yourself.

I think you will be glad you did!