For years, we have drawn boundaries around our systems and generated static documents in Word or Excel that we audit periodically to try and maintain compliance. This approach provides an approachable document that is easier for auditors to follow, but there are serious underlying problems with this methodology. Due to complexity, controls are often pulled up to the boundary level which masks potential security issues within the boundary. Second, each security control’s implementation is subject to change over time which may not be detected until the next audit—this results in unmanaged risks within the environment.
This legacy approach to boundary protection and static compliance documents is not maintainable in today’s cloud-first and mobile-native world. Things simply change too fast; boundaries are more imaginary than real and the need to deliver new capabilities as part of organizational digital transformation strategies are pushing the pace of innovation faster than our compliance paperwork can keep up. The old way isn’t working anymore and a new strategy must be developed.
We are advocates for composable and real-time compliance that shifts compliance left to align with and support the needs of the business. This approach is not dissimilar to what I do with my kids when playing Legos. When you look at the seemingly endless list of pieces necessary to put together that new star destroyer model, it seems overwhelming and daunting. However, Lego does a great job of breaking the task down into its individual components and including detailed instructions that show you how to assemble the overall model. With this approach, you get a detailed understanding of how the entire thing works by assembling it one piece at a time from the ground up. Cybersecurity compliance should work exactly the same way.
The NIST Open Security Control Assessment Language (OSCAL) team has developed a new component model that allows you to layer controls onto each capability in your system to build a composable system security plan (SSP) from its individual pieces. Instead of one giant SSP at the boundary, you get an SSP that consists of its various components such as load balancers, network switches, web servers, databases, storage, etc. Because the plan is built bottom-up, you get a more detailed understanding of how each component of the system works, how it is secured and how you might assess it in the future. In addition, this approach will allow vendors to publish hardening guides that align to OSCAL for better out-of-the-box security when configuring their products.
Best of all, the new OSCAL model is machine-readable. This means that in the future tools will be able to automate assessments, integrate with scanners and update paperwork in real-time. Not only can the security hardening of the system be improved using composability, but the life cycle costs reduced using automation while risks are identified closer to real-time versus waiting on manual assessment processes that are always lagging behind indicators of risk.
By implementing every layer of the OSCAL framework (catalogs, profiles, SSPs, components, etc.), we are able to quickly compose and secure new systems, tie them to existing investments our customers have made in their existing security products and self-update paperwork using an API-centric approach. Best of all, by leveraging a standard from NIST, the artifacts produced in our platform should interoperate and be portable with other OSCAL-enabled technology providers.
