Synopsis
The Open Security Controls Assessment Language (OSCAL) provides many benefits from providing a standardized machine-readable format for compliance documentation to establishing a foundation for the automated assessment of security controls. However, perhaps OSCAL’s greatest benefit is often overlooked. In this article, Tom Volpe, Vice President of Cybersecurity Compliance for C2 Labs, discusses how the OSCAL Component Definition Model provides an opportunity to re-imagine the Authority to Operate (ATO) process.
The Challenge:
Information Systems are complex, satisfying security controls requirements often involves leveraging multiple system components/services.
Security compliance documentation must provide coverage for all components of an information system across hundreds of security controls.
Authoring compliance documentation is a massive undertaking and often involves multiple organizational stakeholders who own the implementation of the various system components.
Background (taken from pages.NIST.gov/OSCAL)
National Institute of Standards and Technology (NIST), in collaboration with industry, is developing the OSCAL, which is a set of formats expressed in XML, JSON, and YAML. These formats provide machine-readable representations of control catalogs, control baselines, system security plans, and assessment plans and results.
The OSCAL architecture is organized in a stack of layers. Each lower layer in the stack provides information structures that are referenced and used by each higher layer. Each layer is composed of one or more models, which represent an information structure supporting a specific operational purpose. Each model in OSCAL is intended to build on the information provided by the lower layer’s model(s).
The OSCAL component definition model exists as part of the OSCAL implementation layer. It represents a description of the controls that are supported in each implementation of a hardware, software, service, policy, process, procedure, or compliance artifact. The component definition model allows grouping related components into capabilities and documenting how the combination of components in a capability together can satisfy specific controls not fully satisfied by a single component on its own.
These component definitions can provide a significant amount of implementation details needed when documenting a system's control implementation in a system security plan. The system security plan author can use this information as a starting point for their work, saving time and cost.
The Solution:
Implement a capabilities-based approach to ATO
Use the OSCAL Component Definition Model to group related components into capabilities and document how the combination of components in a capability together can satisfy specific security controls.
Save time and cost by leveraging component definitions, providing a starting point for documenting a system's control implementations in a security plan.
A Real-World Application
Let’s look at a real-world example. Consider the capability of Identity and Access Management (IAM). The successful deployment of an IAM capability requires the implementation of many components including:
Identity Management – Managing the entire lifecycle of digital identities, including creation, maintenance, and deletion of identities.
Access Management – Determining what resources an authenticated user is allowed to access based on roles, policies, and permissions.
Directory Services – Providing a central repository for storing user identities and related attributes, commonly implemented with systems like Active Directory or LDAP.
Self Service Capabilities – Enabling users to reset passwords and manage their credentials without administrative assistance.
Integration with Other Systems – Connecting IAM systems with other enterprise applications to enforce consistent identity and access controls.
Each of the components of a robust IAM capability might be managed by different organizational stakeholders and can satisfy a different sub-set of security controls. By leveraging OSCAL, the organizational owners of each IAM component can maintain their individual component definitions. Then the OSCAL component definition model can be used to group related components into an IAM capability. Next, this IAM capability can be made available for consumption into the system security plans of every information system that leverages that organizational capability. This approach eases the documentation burden by implementing a “document once – reuse many times” approach.
NOTE: The diagram above is intended to demonstrate the relationship between controls, components, and capabilities. The mapping of controls to components is not exhaustive. In reality, many more controls may map to each of the components listed above.
Conclusion
It’s time to re-imagine the Authority to Operate Process (ATO)! The legacy approach to creating security authorization documentation is largely manual, inefficient, and creates redundant copies of information across multiple systems. The OSCAL Component Model presents an opportunity to change this by enabling a capabilities-based approach to cybersecurity compliance programs. Through this approach, stakeholders can document a description of the controls that are supported in each implementation of a hardware, software, service, policy, process, or procedure. These definitions can then be used by any system that leverages that component as a starting point to the system security plan. This eliminates redundant copies of information, accelerates the development of the system security plan, and saves organizations time and money.
ความคิดเห็น