Simplified Compliance Infrastructure
This project provides a model to describe the categories of compliance activities, how they interact, and the schemas to allow for interoperability between them.
In order to better facilitate cross-functional communication, Simplified Compliance Infrastructure seeks to outline the categorical layers of activities related to automated governance.
Background & Introduction
Simplified Compliance Infrastructure (SCI) is the product of conversations spanning years in highly regulated industries, with input from experienced developers, security, operations, and GRC engineers.
The model is particularly focused on creating a shared language to increase clarity and streamline conversations relating to the interactions between different activities.
As such, the SCI has both philosophical and technical components. Both are maintained in the SCI open source repository under an Apache 2.0 license.
The content below details the philosophical components of SCI, which are used to inform the technical components. The technical components include a CUE schema to define the relevant data structures, and a go library that enables automated interoperability between conformant objects.
All improvements made in the open source repository will subsequently be reflected on this page.
The SCI Model
Let's begin by establishing the overall model, and then the following sections will contain detailed breakdowns of each categorical layer, with examples.
1: Guidance
High-level rulesets on cybersecurity measures
4: Evaluation
Inspection of code, configurations, and deployments
2: Controls
Technology-specific, threat-informed security controls
5: Enforcement
Prevention or remediation based on assessment findings
3: Policy
Risk-informed governance tailored to an organization
6: Audit
Review of all organizational policy and conformance
Each activity type reflected in the SCI model will produce assets, but there is a subtle distinction in what these look like.
Layers 1, 2, and 3 all take place before the implementation phase of the software development lifecycle. The outputs from these layers will be non-code assets, intended to guide development of applications and infrastructure.
The higher layers — 4, 5, and 6 — focus on ensuring proper compliance with organizational policy. As such, these activities are well-suited for automation. The outputs of layers 4 and 5 will be machine readable artifacts, while the outputs of layer 6 will be more focused on human readability to assist in improving lower level activities.
The highest level, Audit, is well-positioned to act as a feedback mechanism to all other activities. This can enable a cycle to form when built into a mature automated governance ecosystem.
The SCI Layers
Layer 1:
Guidance
The Guidance layer is the lowest level of the SCI Model. Activities in this layer provide high-level rules pertaining to cybersecurity measures. Guidance is typically developed by industry groups, government agencies, or international standards bodies. They are intended to be used as a starting point for organizations to develop their own cybersecurity programs.
Guidance frameworks or standards occasionally express their rules using the term "controls" — these should be understood as Layer 1 Controls in the event that the term appears to conflict with Layer 2.
These guidance documents are high-level, abstract controls that may be referenced in the development of other Layer 1 or Layer 2 assets.
Examples include the NIST Cybersecurity Framework, ISO 27001, PCI DSS, HIPPA, GDPR, and CRA.
Layer 2:
Controls
Activities in the Control layer produce technology-specific, threat-informed security expressions of cybersecurity guidelines. Controls are the specific guardrails that organizations put in place to protect their information systems. They are typically informed by the best practices and industry standards which are produced in Layer 1.
Layer 2 Controls are typically developed by an organization for its own purposes, or for general use by industry groups, government agencies, or international standards bodies.
Assets in this category may be refined into more specific Layer 2 controls, or combined with organizational risk considerations to form Layer 3 policies.
The recommended process for developing Layer 2 Controls is to first assess the technology's capabilities, then identify threats to those capabilities, and finally develop controls to mitigate those threats.
Examples include CIS Benchmarks, FINOS Common Cloud Controls, and the OSPS Baseline.
Layer 3:
Policy
Activities in the Policy layer provide risk-informed governance rules tailored to an organization. They are typically informed by risks or based on best practices and industry standards.
Layer 3 controls are typically developed by an organization for its own purposes, to compile into organizational policies. Policies cannot be properly developed without consideration for organization-specific risk appetite and risk-acceptance.
These policy documents may be referenced by other policy documents, or used as a starting point for Layer 4 assessments.
Layer 4:
Evaluation
Activities in the Evaluation layer provide inspection of code, configurations, and deployments. Those elements are part of the _software development lifecycle_ which is not represented in this model.
Evaluation activities may be built based on outputs from Layers 2 or 3. While automated assessments are often developed by vendors or industry groups, proper evaluation should also be able to ingest organizational policies to custom-tailor the assessment to the needs of the compliance program.
Layer 5:
Enforcement
Activities in the Enforcement layer provide prevention or remediation based on assessment findings.
Enforcement actions should be dictated by Layer 3 policies, and act on information gathered by Layer 3 evaluations.
This layer ensures that the organization is complying with policy when evidence of noncompliance is found, such as by blocking the deployment of a resource that does not meet the organization's policies.
Layer 6:
Audit
Activities in the Audit layer provide a review of organizational policy and conformance.
Audits consider information from all of the lower layers. These activities are typically performed by internal or external auditors to ensure that the organization has designed and enforced effective policies based on the organization's requirements.
Information from audits may be used to improve activities from all other layers in the SCI model.