深入解析OSCAL-Compass:应对行业复杂性的Trestle实战指南

本文详细介绍了新加坡GovTech团队使用OSCAL和Trestle SDK解决合规性需求的实践案例,包括如何通过多层级Profile管理控制重要性,以及利用Markdown生成用户友好的SSP文档,实现自动化合规流程。

COMPASS第9部分:应对行业复杂性的OSCAL-Compass

在本系列博客的第2和第3部分中,我们介绍了实现NIST开放安全控制评估语言(OSCAL)标准框架的开源Trestle SDK。我们还涵盖了Trestle的敏捷编写能力,允许用户创建和编辑合规工件作为Markdown内容,并将其转换为OSCAL格式。此外,我们解释了敏捷编写GitOps工作流自动化工具如何支持整个合规过程中涉及的各种角色。

在本文中,我们将探讨新加坡政府技术团队(GovTech)在使用OSCAL时遇到的具体用例,以及Trestle如何帮助满足他们的需求。

新加坡GovTech团队的具体用例

现有系统安全计划(SSP)模型原生不支持两个主要要求,但对分发给新加坡政府机构的GovTech SSP模板至关重要。

第一个要求是能够记录OSCAL配置文件中包含并用于SSP的控制集中每个控制的重要性级别。虽然配置文件和/或系统安全计划包含来自目录的许多控制,但并非所有控制都同等重要。例如,级别0(L0)控制是“必须拥有”,级别1(L1)控制是“应该拥有”,级别2(L2)控制是“最好拥有”。支持此信息的一种方法是在配置文件或SSP中的每个控制中添加一个“重要性”OSCAL属性,并赋予正确的级别值。但这种方法需要配置文件或SSP作者手动编辑Markdown文件中的每个控制,以添加具有特定值的属性,这是一个繁琐且耗时的过程。

因此,GovTech为级别0、级别1和级别2使用了不同的配置文件。然而,由于SSP只能从单个配置文件导入,配置文件的聚合必须在SSP之外完成。通过设计由较低级别配置文件添加特定控制组成的配置文件,解决了这一不便。例如,级别1配置文件导入级别0配置文件。最终的级别2配置文件包括级别1和级别0控制。因此,虽然由于此导入链,级别0和级别1控制在技术上是级别2配置文件的一部分,但这些控制本身仍需要在输出SSP中标记为其原始配置文件或重要性级别。在下一节中,我们将描述如何使用Trestle的YAML头注入机制在各种编写任务中实现这一点。具体来说,我们将描述其在配置文件生成任务中的使用,以处理此要求。

第二个要求是生成用户友好的SSP视图以供分发,最好是Markdown格式。这实现了一个完全自动化的发布管道,其中对OSCAL文件的更新将反映在面向用户的静态生成网站上。

使用Trestle为控制集添加特定属性

为不同控制集添加特定属性和值的一种方法是创建多个配置文件,每个配置文件具有相同属性和相同值的控制。例如,在上述指定不同控制级别的要求中,我们可以创建3个不同的配置文件 - L0、L1、L2,仅包含该级别的控制,即L2配置文件应仅从目录中导入L2级别的控制,不应导入L1或L0级别的控制。这些配置文件可以称为L0_only、L1_only和L2_only,仅包含该级别的控制。

接下来,我们需要为配置文件中的每个控制添加“重要性”属性,并赋予相同的值。这可以使用Trestle在创建(生成)Markdown文件时为每个控制添加YAML头的能力,然后将它们组装回以创建OSCAL json。这可以通过使用命令轻松完成 -

1
trestle author profile generate

并使用–yaml-header选项指定包含该属性和值的YAML文件。这将为每个控制生成Markdown文件,并在Markdown文件的YAML头中添加“重要性”属性。然后可以将这些文件组装回以创建配置文件,并且此属性将包含在配置文件JSON中的每个控制中。

一旦创建了具有添加“重要性”属性的特定配置文件 - L0_only、L1_only和L2_only,我们可以通过导入来自L0_only和L1_only配置文件的所有控制来创建包含L0和L1控制的L1配置文件。类似地,L2配置文件可以从L1(或L0_only和L1_only)和L2_only配置文件创建。这样,即使控制来自L0,它们也将在L1和L2配置文件中保留其重要性值。

接下来,L2配置文件可以导入到SSP中,然后SSP将为每个控制具有正确的重要性级别。

下图显示了如何组织配置文件以实现此目标的示意图。

使用Trestle为机构创建模板SSP

为了促进基于OSCAL的合规性在新加坡政府机构中的更广泛采用,GovTech开发了模板SSP,帮助机构采用适合其特定风险级别或环境原型的控制。每个模板SSP导入相关配置文件(L0、L1、L2),对应于不同的风险级别(低、中、高风险),如前一节所述,为机构提供一个起点,已经包含了适合其系统风险配置的控制。

这些模板SSP作为更大编写存储库的一部分维护,其中包括完整的控制和配置文件集。对此存储库内任何模型的所有贡献都经过相关领域所有者的结构化审查过程,并由Trestle通过持续集成测试在合并到主存储库之前进行验证。为了帮助可能不熟悉OSCAL格式的审查者,审查过程包含一个临时预览环境,使用生成的Markdown内容在用户友好的静态网站上显示提议的更新。

GovTech采用持续部署方法,以鼓励机构之间的透明度和协作。这包括一个“测试”版本,在合并到主干分支时自动部署到主静态网站,以及一个稳定版本,仅在主要发布时更新。Trestle协助生成两个版本的分发。这种双重发布策略允许机构审查即将到来的更改,同时保持对稳定、生产就绪版本的访问。

主要发布的OSCAL文档还部署到治理、风险和合规平台,在那里它们与GovTech的更广泛控制实施和评估过程集成。OSCAL文档被解析并转换为面向用户的表单和验证标准。从这个平台,机构可以选择从适合其系统类型的SSP模板开始,通过提供预配置的控制和合规文档,显著加速其启动路径,这些文档与其特定的操作要求保持一致。

结论

在本博客中,我们描述了新加坡GovTech在使用OSCAL满足其合规需求时遇到的一些独特用例,并演示了Trestle如何支持这些要求。尽管Trestle能够在没有任何修改的情况下满足这些需求,但可能还有其他我们尚未预料的要求,可能需要增强。我们鼓励Trestle用户社区分享您如何在组织中使用Trestle,并如果您希望看到新功能添加,请在Trestle GitHub存储库上提交功能请求。

了解更多

如果您想使用我们的开源Trestle SDK和敏捷编写,请参阅CNCF的OSCAL-Compass项目,以了解各种trestle CLI及其用法。有关编写各种合规工件的Markdown格式和命令的更多详细信息,请参阅Trestle的本教程。

以下是本系列其他文章的链接:

  • 合规自动化标准解决方案(COMPASS),第1部分:角色和职责
  • 合规自动化标准解决方案(COMPASS),第2部分:Trestle SDK
  • 合规自动化标准解决方案(COMPASS),第3部分:工件和角色
  • 合规自动化标准解决方案(COMPASS),第4部分:合规策略管理中心的拓扑
  • 合规自动化标准解决方案(COMPASS),第5部分:缺乏网络边界导致缺乏合规性
  • 合规自动化标准解决方案(COMPASS),第6部分:多Kubernetes集群的合规到策略
  • 合规自动化标准解决方案(COMPASS),第7部分:使用Auditree的IT操作策略的合规到策略
  • 合规自动化标准解决方案(COMPASS),第8部分:使用提示声明语言进行合规自动化的代理AI策略即代码
comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计