Compliance Automated Standard Solution (COMPASS), Part 9: Taking OSCAL-Compass to Industry Complexity Level

(Note: A list of links for all articles in this series can be found at the conclusion of this article.)

In parts 2 and part 3 of this blog series, we introduced the open-source Trestle SDK, which implements the NIST Open Security Control Assessment Language (OSCAL) standard framework. We also covered Trestle’s agile authoring capabilities, allowing users to create and edit compliance artifacts as Markdown content and convert them to OSCAL format. Additionally, we explained how the Agile Authoring GitOps workflow automation tool supports the various personas involved throughout the compliance process.

In this post, we will explore specific use-cases encountered by the Singapore government technical team (GovTech) in their use of OSCAL, and how Trestle helped address their needs.

Specific Use-Cases of the Singapore GovTech Team

There were two main requirements not natively supported in the existing System Security Plan (SSP) model but deemed of main importance for GovTech SSP template distributed to Singapore government agencies. 

The first requirement points to the ability to document the level of importance for each control within a set of controls incorporated in the OSCAL Profile and used in the SSP. While the Profiles and/or System Security Plans have many controls from the catalog, not all controls are equally important. For example - Level 0 (L0) controls are “Must haves”, Level 1 (L1) controls are “Should haves”, and Level 2 (L2) controls are “Good to have”. One way to support this information would be to add an “importance” OSCAL property to each control in the profile or SSP with the right level value. But, this approach would require the profile or SSP author to manually edit each control in the Markdown file to add this property with the specific value for that control which is a laborious and time-consuming process.

As such, GovTech used distinct Profiles for Level 0, Level 1, and Level 2. However, as SSPs can only import from a single profile, the aggregation of the profile has to be done outside the SSP. By designing the Profiles to be composed of the lower level Profile with added specific controls, this inconvenience was addressed. In this way, for example, Level 1 Profile imports Level 0 Profile. The final Level 2 Profile includes Level 1 and Level 0 controls. As such, while Level 0 and Level 1 controls were technically part of the Level 2 profile due to this import chain, the controls themselves still needed to be marked under their original profile, or importance level, in the output SSP. In the next section we will describe how this could be achieved using Trestle’s YAML header injection mechanism in the various authoring tasks in Trestle. Specifically, we will describe its use in the Profile generation task to handle this requirement.

The second requirement was to produce user-friendly views of SSPs for distribution, preferably in Markdown. This enabled a fully automated publication pipeline where updates to the OSCAL files would be reflected on a user-facing statically-generated website. 

Using Trestle to Add Specific Properties to a Set of Controls

One way to add specific properties and values to different sets of controls is to create multiple profiles, with each profile having the controls with the same properties with the same values. For example, in the requirement described above to specify different controls levels, we can create 3 different profiles - L0, L1, L2 containing controls only at that level i.e., L2 profile should only import controls from catalogs that are at L2 level and should not import controls at L1 or L0 level. These profiles can be called L0_only, L1_only, and L2_only having controls only at level. 

Next we need to add the "importance" property to each control in a profile with the same value. This can be done using Trestle’s capability to add a YAML header to each control during the creation (generation) of Markdown files and then assembling them back to create the OSCAL json. This can be done easily by using the command -

trestle author profile generate

and using the --yaml-header option to specify a YAML file containing that property and value. This will generate markdown files for each control with the "importance" property added to the YAML header in the markdown file. These can then be assembled back to create the Profile and this property will be included in the profile JSON for each control.

Once specific profiles - L0_only, L1_only, and L2_only have been created with “importance” property added, we can create the L1 profile containing both L0 and L1 controls by importing all controls from L0_only and L1_only profiles. Similarly, L2 profile can be created from L1 (or L0_only and L1_only) and L2_only profiles. This way the controls will retain their importance value in L1 and L2 profiles even if they are coming from L0. 

Next, the L2 profile can be imported in the SSP which will then have the right importance level for each control.

The figure below shows a schematic representation of how the profiles need to be organized to achieve this objective. 

Use of Trestle To Create Template SSPs for Distribution to Agencies

To facilitate broader adoption of OSCAL-based compliance across Singapore government agencies, GovTech developed template SSPs that help agencies adopt the appropriate controls for their specific risk-level or environment archetype. Each template SSP imports the relevant profiles (L0, L1, L2) corresponding to different risk levels (Low-, Medium-, High-Risk) as described in the previous section, providing agencies with a starting point that already incorporates the controls appropriate for their system's risk profile.

These template SSPs are maintained as part of a larger authoring repository that includes the complete set of controls and profiles. All contributions to any of the models within this repository undergo a structured review process by relevant domain owners and are validated by Trestle via Continuous Integration tests before merging into the main repository. To assist reviewers who may not be familiar with OSCAL format, the review process incorporates an ephemeral preview environment that displays the proposed updates in a user-friendly static website using generated Markdown content.

GovTech adopted a continuous deployment approach to encourage transparency and collaboration among agencies. This includes a "beta" version that is automatically deployed to the main static website upon merge to the trunk branch, alongside a stable version that is updated only during major releases. Trestle assists in generating the distribution for both versions. This dual-release strategy allows agencies to review upcoming changes while maintaining access to stable, production-ready releases.

The major release OSCAL documents are also deployed to a Governance, Risk, and Compliance platform where they integrate with GovTech's broader control implementation and assessment processes. The OSCAL documents are parsed and transformed into user-facing forms and validation criteria. From this platform, agencies can opt to start from an SSP template tailored to their system type, significantly accelerating their path to launch by providing pre-configured controls and compliance documentation that align with their specific operational requirements.

Conclusion

In this blog, we described some unique use-cases Singapore GovTech encountered while using OSCAL for their compliance needs and demonstrated how Trestle supported those requirements. Although Trestle was able to meet these needs without any modifications, there may be other requirements we have yet to anticipate that could call for enhancements. We encourage the Trestle user community to share how you have used Trestle in your organizations and to submit feature requests on the Trestle GitHub repository if  would like to see new capabilities added.

Learn More

If you would like to use our open-source Trestle SDK and Agile Authoring then see the CNCF’s OSCAL-Compass project to learn about various trestle CLIs and their usage. For more details on the Markdown formats and commands for authoring various compliance artifacts, see this tutorial from Trestle.

Below are the links to other articles in this series:

• Compliance Automated Standard Solution (COMPASS), Part 1: Personas and Roles
• Compliance Automated Standard Solution (COMPASS), Part 2: Trestle SDK
• Compliance Automated Standard Solution (COMPASS), Part 3: Artifacts and Personas
• Compliance Automated Standard Solution (COMPASS), Part 4: Topologies of Compliance Policy Administration Centers
• Compliance Automated Standard Solution (COMPASS), Part 5: A Lack of Network Boundaries Invites a Lack of Compliance
• Compliance Automated Standard Solution (COMPASS), Part 6: Compliance to Policy for Multiple Kubernetes Clusters
• Compliance Automated Standard Solution (COMPASS), Part 7: Compliance-to-Policy for IT Operation Policies Using Auditree
• Compliance Automated Standard Solution (COMPASS), Part 8: Agentic AI Policy as Code for Compliance Automation With Prompt Declaration Language