COMPASS: Compliance Automated Standard Solution

These days, regulatory compliance is a business liability. The corporate world is moving from sporadic audits to continuous compliance realms, where the system’s posture is to be available at the touch of a dashboard. To achieve continuous compliance, we need both automation and standardization. Achieving automation is a challenging endeavor due to siloed governance processes, disconnect between organizational policies and their corresponding technical implementation and the complexity of compliance implementation and measurement.

Note that the closer we get to systems, APIs and programmatic data representation, the easier it is to drive digitization and automation. Meanwhile, the closer we are to manual processes and human format data representation, the more difficult it gets to drive digitization and transformation. Compliance lies in the second class — with its PDFs and Word docs for regulations, guidance and interpretations — and its manual procedures to gather sample evidence and generate spreadsheet reports. Therefore, to onboard on the compliance automation journey, we need to understand those manual, semi-automated and siloed procedures and their facilitators’ needs.

In this blog post, we survey the stakeholders and their roles and actions in the Governance, Risk and Compliance (GRC) management framework — from regulation authoring to evidence gathering to audit reporting. Since our focus in this series is on compliance, the risk aspects will be included at a later time. We then introduce compliance artifacts associated with these personas and exemplify their representation as compliance as code and policy as code to enable automation. A comprehensive coverage of the compliance artifacts will be the subject of our next blog post.

As we illustrate in Figure 1, the main compliance stakeholders involved in a Governance, Risk and Compliance (GRC) management framework and the flow of actions from these personas is as follows:

1. Regulators define regulations, laws and standards as catalogs with controls and parameters. They also establish predefined compliance requirements into baselines or profiles.
2. Control Providers — such as product vendors, service providers and OSS project maintainers — implement the controls from the regulation catalogs in their products (e.g., hardware, software, services, processes). In order to declare how the controls are implemented, they need to translate each control into technical rules applied to the product configuration parameters and behavior such as to reflect the control guidance. This translation is done by stating the mapping between the control and the technical rules. The Control Providers may also expose the nature of the evidence associated with each rule (e.g., schema, template, API payload).
3. The technical rules need to be tested or enforced to check or ensure that the regulated environments or reference architectures are configured and behave according to the regulation, baseline or predefined profiles of the Regulators. Control Assessors — such as assessment tool vendors, service providers, OSS project maintainers and compliance engineers — implement checks or products that host checks to test regulated environments or reference architectures for alignment with the expected compliance requirements. Their checks build on the evidence format declared by the Control Providers and have output states for the checks like “fail,” “pass,” “error” and “unable to perform.”
4. System Owners and CIOs are responsible for the overall procurement, development, integration, modification, operation, maintenance and disposal of their enterprise platforms, systems, OS, networks, databases and applications. They are responsible for ensuring compliance with the profiles selected by the CISO Security Engineers.
5. CISO enterprise architects, security engineers and compliance engineers are responsible for defining, customizing and associating profiles and controls with the owned regulated environments and reference architectures.
6. CISO enterprise architects, security engineers and compliance engineers are also responsible for creating new technical rules for their regulated enterprise and reference architectures to cover additional controls through cross-product combined capabilities and behaviors. Those new rules will result in new checks to further test that the regulated environments and reference architectures are configured and behave according to the profiles selected by CISO Security Engineers. These checks build on the evidence format declared by the Control Providers (or by the CISO in the case of custom tools and processes) and have output states like “fail,” “pass,” “error” and “unable to perform.”
7. CISOs are also the link between the System Owner and the Audit Officials for whom they need to prepare the package for the Authorization to Operate (ATO) (i.e., the System Security Plan (SSP) and the System Assessment Results (SAR) for the enterprise).
8. Based on the CISO’s selected profiles, SSP or System Assessment Plans (SAP), the Control Assessors test all applicable technical rules and generate System Assessment Results (SAR) that contain the compliance posture of the systems in the regulated environment or reference architecture. The SARs are shared with the CISO and the System Owners and/or Operation teams.
9. CISO and/or Systems Owners may generate plans of actions based on SAR posture failures. Systems Owners are responsible for ensuring the compliance with the profiles selected by the CISO. They retrieve the SAR from the Control Assessors and must take corrective actions to reduce or eliminate the risk of failure. They work with the Operations team to remediate the systems (for risk elimination) and with the CISO to adjust the profiles or SSP security plan (for risk mitigation).
10. Operations, Administrators and Developers need to focus on the day-to-day tasks of their respective jobs and minimize the involvement into regulations and audit. They need to understand how the technical controls of the systems for which they have expertise are impacting the compliance of their environment, reference architecture and apps, and, if failing to comply, to remediate them. They benefit from a plan of action and priorities to proceed with the remediations.
11. Audit Officials retrieve the SSP and SAR reports from the CISO in the recommended templated format of the audit. All the translations between the product native SAR formats and audit templated formats or standard formats (e.g., NIST OSCAL (link resides outside ibm.com) – Open Security Control Assessment Language) could benefit from the support of an SDK like Trestle, which was introduced in an earlier blog.

In the table below, we summarize the personas involved in the enterprise-wide compliance processes and their actions:

Figure 2: Illustrative examples for various compliance artifacts and their programmatic representation. Regulations in PDF format (top) vs. Controls and Rules expressed as Compliance as Code (middle) vs. Checks Scripts as Policy as Code to test the systems (bottom).

Figure 2 depicts key compliance artifacts with concrete examples and their representation in human language and as compliance as code or policy as code. It illustrates the following key aspects of the compliance artifacts:

1. The regulations and regulations controls on the governance side are expressed as broad statements in human language (e.g., “SC-28 The information system protects the [confidentiality; integrity] of [information at rest].”) while the technical rules on the technical side are expressed as specific statements for the products and processes implementing the controls (e.g., “Ensure Cloud Object Storage is encrypted with KYOK”). In most cases, the wording in the technical rule indirectly reflects the claim of the control, requiring a product expert to generate the rules and making it difficult for a non-expert or AI to evaluate the coverage of the control statement. We will show in a future blog how artificial intelligence (AI) can support the compliance expert to navigate the regulations statements via crosswalks.
2. The representation format of these compliance artifacts evolves from PDFs, free text and spreadsheets to compliance as code (e.g., NIST OSCAL) and policy as code (e.g., OPA – Open Policy Agent) (link resides outside ibm.com) to achieve automation. On one hand, while we still need PDFs, free text and spreadsheets to facilitate the users’ creation and consumption of catalogs, profiles and vendors’ products rules and parameters description, we need to shift to compliance as code to enable the compliance tools and services to exchange, apply and control those compliance artifacts continuously in the environments. On the other hand, we also need the manual evidence evaluation processes to shift to policy as code — such as scripts in Python, JavaScript or OPA Rego — to continuously test the technical rules of the products deployed in the regulated environment. In the next blog, we will show how the NIST OSCAL framework and its standard language can be used to represent the typical GRC artifacts as code.
3. The key to achieving compliance automation and continuous compliance is the programmatic representation of the mapping from broad control statements in human language to specific technical rules and their associated parameters and checks. The multiple-step process to generate this key artifact, register it with the GRC framework and use it to provide the compliance posture will be the subject of our blog post on the GRC Exchange Protocol.

In this first blog post of this multi-blog series, we covered the main personas expected in the Governance, Risk and Compliance (GRC) management framework. As you undoubtedly have noticed, we have defined a specific set of actions focusing on a theoretical separation of duties for each persona. However, in a real organization, an individual may cover multiple roles — in which case, she will perform the actions associated with all those personas.

In our next blog post, we plan to provide you with detailed coverage of the compliance artifacts handled in the end-to-end compliance flow — from representing regulations to compliance posture to auditor reports. We will also provide their representation as code using the NIST OSCAL standard (link resides outside ibm.com), with actual examples ready to use for your continuous compliance implementation of catalogs (link resides outside ibm.com) that represent standards (e.g., NIST 800-53) (link resides outside ibm.com), profiles (link resides outside ibm.com) that represent baselines, assessment results (link resides outside ibm.com) and more, together with their interdependencies in the Governance, Risk and Compliance framework and relationships to the persona’s roles and actions introduced in this blog.

If you would like to dig deeper, see IBM Cloud compliance programs and the IBM Cloud Security and Compliance Center to learn about the supported compliance programs and how to manage your compliance on IBM Cloud.