HowTo: Track RMF and FedRAMP system packages with inherited common controls from cloud providers
To track RMF and FedRAMP system packages as you move them to your cloud, you first can use the new OpenRMF Professional v2.7 with Custom Checklists to create your base level infrastructure system package for your platform or cloud infrastructure. Then, use the new Inheritance feature (common controls) when generating and tracking compliance for applications, services, and platforms for your users that inherits these controls and your main infrastructure system package compliance. Read on for more…
Moving to “The Cloud”
With more organizations moving their applications from on premise data centers to cloud providers, there is a need to update the inherited common controls the cloud provider or broker is responsible for providing. This ensures your RMF or FedRAMP authorization is updated, truthful, and tracks the underlying infrastructure package correctly and easily.
Whether you are moving an infrastructure to the cloud, migrating users and applications to the cloud or developing brand new applications and services that are cloud-based, you may still need to track FedRAMP and RMF compliance. And cloud providers do not give you a set of “Checklists” to use in a base level system package.
Enter OpenRMF Professional v2.7, which now tracks inheritance / common controls. Combine that with current custom checklists functionality to match the cloud provider base level controls, and you can accomplish this difficult task easily with a structured, repeatable process.
Cloud platforms such as AWS and Azure DO have listings for the controls and rules you can implement if you search for them hard enough. They DO NOT have checklists you can download to track the compliance for this as far as RMF and FedRAMP processes and evidence. Following the steps below you can do this for your organization quite easily, have repeatable processes for it, and lessen the stress level on your cyber and administrative personnel!
Creating your Custom Checklists
Way back in version 2.4 we introduced custom checklists. This lets you create a checklist structure like the ones you are used to. The main thing being you can make them for whatever you need them to be. Processes and Procedures like the Incident Response or Program Management group of controls. A particular technology stack or piece of software/hardware you use.
Or in this case, a cloud provider and their security controls they are responsible for versus what YOU are responsible for filling out and providing. As an Administrator, follow the “Create Custom Checklist” help or Quicksheet PDF to create your checklist and vulnerability / question listing. A few screenshots are below.
You can add a vulnerability (call it a question, call it a check, call it whatever you want) and specify the control you want it to match. Pick the CCIs that belong to that entry and click the CCI link to add them. This will help link it to the controls or subcontrols within your system package.
Next add your title, severity, and the normal discussion, check content and fix text you want to specify for this particular vulnerability/question. When done click Save Changes. Repeat these processes to match all the items you wish on your custom checklist.
You can have one very long checklist for everything, although that is not very manageable in the long run. You could match a checklist up to each service (AWS S3, AWS VPC, Azure VNet, Azure Blob, etc.) and have the users fill out the answers based on the services they are using. And in the same way, have a set of base level inherited controls in an “infrastructure” or “broker” or “cloud” system package the rest inherit from for system compliance.
Add the Custom Checklist to your Infrastructure System Package
From the Template listing for Custom Templates you can click the checkbox next to your custom checklist you just made. Then click the bulk menu for “Create Checklist in System Package” and specify your package listed. Click the “Add” button and it is now added in there. Any boilerplate information is also transferred into the package for the brand new checklist.
Now when you list all checklists, you will see the new one there for your viewing / editing pleasure. All normal reports, compliance, listings, notifications, etc. all function as normal if this were any other DISA released checklist. And if you update the template later and update the version, the users will see the “Upgrade” button to upgrade to the latest version as well.
Tracking Inherited Controls for Applications, Platforms, and Users
Now when you run and save your system compliance in the main “broker” or “cloud” system package that is your base package to inherit from, this will include the new custom checklist. Anyone inheriting from you that inherits the controls or subcontrols as common controls will be able to run their own system compliance, and now include the cloud controls they inherit as well!
Automation on Updated Inherited / Common Controls
All controls you inherited are tied and linked to the underlying compliance of the inherited system package. As that system package updates and saves a NEW compliance listing, behind the scenes all controls inherited are updated for those other system packages inheriting the controls. And a notification of “Updated Inherited Controls” is generated for every system package that inherits from you.
Additionally, any inherited control listed whose status is not “Not a Finding” is added as an inherited control to the POAM automatically. Any update to the control status when updated is also reviewed. Any change to “Not a Finding” is marked completed in the POAM. And any control whose status is not “Not a Finding” is added or reopened to In Process.
