第9节
第二篇　CA工具设计

提要

·　无论是获取还是实现持续审计（Continuous Audit, CA）工具，都必须定义一个具体的最终结果，包括CA工具的要求。

·　设计CA工具需要定义一个价值流，包括用例图和用例。

·　为了支持CA工具简单和渐进式地交付，需要定义一个数据模型。

阅读指南

本节讨论了如图1.6.1所示的持续审计价值流中每个步骤的最佳实践，包括摘要、简介以及本文讨论的持续审计的概念。

一、摘要

持续审计的概念要求信息系统像任何其他IT解决方案一样进行构建或设计。如今，IT解决方案通常以敏捷的方式实现或购买，并集成到现有的应用架构中。这同样适用于CA工具。本节介绍了实现CA工具的步骤以及需要回答的相关问题。

二、简介

持续审计概念如图1.9.1所示，有关背景的更多信息请参阅第8节中内容。

本文于2021年4月19日在《IT经理》杂志中发表，标题为“持续交付需要持续设计”。由“安全设计联盟”出品，Jan-Willem Hordijk授权发布。作者包括：

·　Bart de Best

·　Dennis Boersen（ArgisIT）

·　Freeke de Cloet（smartdocuments）

·　Jan-Willem Hordijk（Nordcloud，IBM公司）

·　Willem Kok（ArgisIT）

·　Niels Talens（www.nielstalens.nl）。

三、问题说明

实施CA工具需要解决3个问题：

·　第一个问题是需要回答一系列关键问题。

·　第二个问题是CA工具的设计（如果不采用现成的）。

·　第三个问题是CA工具的开发、运行和维护。

1．CA工具问题

本系列文章的第一部分提出了启动CA工具实现或采购的一系列必要条件，并将其转化为以下问题：

·　问题1：CA工具的愿景是什么？

·　问题2：应该参考哪些法律、法规或内部信息安全要求？

·　问题3：如何定义这些要求？

·　问题4：如何在特定环境下将这些要求转化为控制措施？

·　问题5：哪些信息资产需要被纳入控制范围并进行管理？

·　问题6：我们如何从信息资产中提取、转换和加载（extract, transform and load, ETL）信息到CA工具中？

·　问题7：如何决定购买或自行开发CA工具？

2．CA工具的要求

无论采用何种方式（购买或自行开发），都必须对最终成果（包括CA工具需求）有一个具体的规划。本节将介绍如何设计CA工具以及如何定义其需求，并提供一系列可供参考的CA工具需求。

3．CA工具的实现方法

最终，还应该研究工具的具体实施方式。实现CA工具有多种方法，本文将对一些常见方法进行介绍。

四、CA工具问题答案

对于CA工具的问题没有通用答案。CA工具必须根据每个实施项目的业务背景量身定制。下面的答案可以作为参考。

1．CA工具的愿景是什么？

传统年度审计难以有效应对信息提供动态变化带来的风险。随着企业不断创建和更新服务和产品，原先识别出的风险可能失去管控。因此，新服务和产品需要提供数据接口，以提取必要证据，并结合CA工具进行持续监控，以确保风险可控。

2．应考虑CA工具要求的哪些来源？

制定CA工具需求时，需考虑多种来源，具体取决于所需的控制级别。本文将ISO 27001:2013作为最低要求，并辅以基于内部风险分析的补充要求，这些额外要求通常以CIA矩阵的形式呈现。

3．如何定义这些需求？

CA工具的需求体现在其行为上。本文采用Gherkin语言来描述该行为，当然也可以使用其他格式。Gherkin语言是一种强大的描述性符号，能够以简单直观的语法表达出系统预期的可观察行为。

4．如何在本地环境中将CA工具要求转化为控制措施？

在本地环境中转化CA工具要求需要综合考虑工具要求、本地情况和控制措施的有效性等方面。下面以访问管理中的“多因素身份验证”（Multi Factor Authentication, MFA）要求为例进行说明。不同组织的具体实施方式可能有所差异，但控制措施的有效性可以通过满足MFA要求的账户比例来衡量。该框架可以涵盖不同组织的控制措施，并将有效性度量以JSON格式进行表达。基于JSON格式的有效性度量，可以实现API接口，便于获取和共享控制措施的有效性信息。

5．如何定义和映射范围内的资产到控制措施？

（1）CIA矩阵作为资产过滤器

尽管要求仅限于由ISVS管理的用于提供信息服务的资产的信息安全要求，但该范围涵盖了所有可能存在风险的资产。因此，应使用CIA矩阵筛选出高风险资产，并将其纳入CA工具。

（2）资产映射

CIA矩阵中这些资产与控制措施的连接是双重的，因为存在两种类型的控制措施：外部控制（ISO 27001:2013/法律法规）和内部控制（组织本身识别风险的对策）。这些控制措施可能会重叠。

6．如何提取、转换和加载资产信息到CA工具？

为实现已实施控制措施与CA工具之间的信息交换，必须对必要的ETL功能进行标准化。为了使证据可收集（见图1.9.1），需要从受管对象中提取数据。但是，必须将这些信息转换为证据收集器的统一格式。最后，转换后的数据必须加载到审计证据数据库中。如今，JSON是一种常用的接口定义，但XML也可以做到这一点。市场上有许多技术和工具可以以受控的方式实现这一点。

7．如何决定购买或自行开发CA工具？

构建或购买CA工具的选择取决于要监控的对象数量以及具有标准化接口以提取与要购买的CA工具兼容的信息的对象百分比。两种选择都有优点和缺点，如表1.9.1所示。每个组织都必须在这两种解决方案中找到平衡。

五、CA工具需求

CA工具需求分为两部分：第一部分是基于敏捷设计技术，描述全球范围内CA工具操作的设计；第二部分是使用Gherkin语言，更详细地定义CA工具的行为，涵盖需求、验收标准和测试用例。

1．如何设计一个CA工具？

本书的这部分所遵循的步骤是：

·　第1步：定义CA工具的价值流。

·　第2步：定义用例图。

·　第3步：定义用例。

（1）第1步：定义CA工具的价值流

价值流是一系列创造结果的步骤。多个价值流相互关联，形成价值系统。在本例中为CA价值系统（CA Value System, CVS），其价值流如图1.9.2所示。CVS可用于ISVS中自动化ISVS价值流内部审计。

第一个价值流根据图1.9.1创建控制定义数据库（Control Definition Database, CDD）。该数据库包含所有需要自动检查的控制措施。第二个价值流定义了控制证据数据库的数据结构。该数据库通过从范围内的受管对象中提取数据，填充控制有效性的证据。实现这一目标的ETL功能也在这个价值流中定义。最后同样重要的是，确定可视化并计算聚合信息。数据是使用REST API导出的。

（2）第2步：定义用例图

每个价值流必须至少定义一个用例图。图1.9.3显示了VS-020的示例。这里的步骤被转化为用例。每个用例也给出了参与者。这是定义CA工具用例的中间步骤。

（3）第3步：定义用例

我们需要为用例图的每个深色椭圆定义一个用例。

如果用例非常清晰，则可以只创建一个用例来定义整个用例图。这样可以节省定义用例的时间。

表1.9.2显示了控制证据管理的用例。

六、如何设计需求

CA工具的要求是以Gherkin语言描述的，下面是是对UC-20第4步的要求。

七、CA工具设计示例

为了让CA工具更具像化，下面给出了一些提示。

1．界面

CA工具的界面与其他监控仪表盘没有多大区别，但必须具备以下核心功能：

·　信息安全目标在保密性、完整性和可访问性方面的总体状况的可视化。

·　细化查询功能可以找到异常、警告或信息事件的详细信息。

·　对整体质量的差异化视图，如：

◎ISVS的价值流。

◆ 每个价值流的事件。

◎资产。

◆ 按资产分类的事件。

◎人。

◆ 按人员类型划分的事件。

2．数据模型

图1.9.4显示了CA数据模型的一个示例。实体类型“Risk”表示风险。但是，风险并不一定适用于每个受管对象。此外，对于所有受风险影响的受管对象，风险并不具备相同的特征。

因此，风险和受管对象的组合决定了CIA评级和相关控制和证据的基础。

八、CA工具方法

实施CA工具的最佳实践：

·　制定并版本控制控制检查的常规手动操作计划。

◎这加快了CA工具的设计和需求的形式化。

·　根据史诗定义所有设计功能的路线图。

◎史诗是需要四分之一完成时间的任务块。

◎每个史诗都是为组织增加价值的最小化可行产品（Minimal Viable Product, MVP）。

◎采用渐进式方法，优先实现最重要且耗时最短的功能。

◎使用80/20规则：在20%的时间内实现80%的检查，将最难构建的部分留到最后。

·　使设计和需求与市场上的工具（治理风险合规）保持一致。

·　COTS。

◎敏捷开发是自制CA工具的最佳解决方案，而COTS CA工具则可以通过安装程序实施。

九、市场上的CA工具示例

以下工具在一定程度上提供CA工具的功能：

·　Idea。

·　ACL。

·　Bwise。

·　ARIS。

·　SAP GRC。

·　Oracle GRC。

·　Approva Bizrights。

·　Synaxion。

·　Oversight。 Nxl+fVX7jzPHkQcGT6WxcCL70fOVm3icYrlgqczD4JFkJMcPEM2mgzhYXBq3rbjE