下载掌阅APP，畅读海量书库
立即打开
提要：
· 对风险的控制措施最好用标准化格式来定义，如Gherkin语言（Given - When - Then）。
· 对于一个功能齐全的CA工具，必须设置对风险管理、管理对象、控制措施和证据进行CRUD（Create-Read-Update-Delete,创建-读取-更新-删除）操作的功能。
· 控制定义中既可以定义证据值和阈值，也可定义包含更复杂运算符的规则表达式。
阅读指南
本节首先介绍了CA工具的实施，然后在介绍了MVP的基础上讨论了实施情况，并做出详细说明，最后给出了研究结果和结论。
本文介绍了基于“持续审计概念”（第八节）和“CA工具设计”（第九节）的CA工具原型。第一篇“持续审计概念”阐述了持续审计的概念，第二篇“CA工具设计”则给出了实现这种概念的设计方案。本文进一步将该设计具体化，开发出一个可运行的解决方案，即MVP。
这篇技术性较强的文章面向架构师、开发人员、工程师和技术审计员。文章从一个具体案例展开，演示了如何持续监控控制并通过仪表板实时呈现业务规则（测试控制与标准的符合程度）的结果。这个MVP是开发完整CA工具的第一步（工作原型），为进一步扩展和完善奠定了良好基础。该MVP使用了Flask、Python、ProgreSQL和Azure等技术和平台。
本文于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工具的MVP旨在构建一个持续信息流，以评估控制措施的有效性。该MVP的功能选择与CA设计相契合，但仅针对一个受管对象（SQL Server）、一个风险（容量短缺）、一个控制措施（容量监控）和一系列容量测量数据（证据）进行测试。
为了确保所有受管对象得到一致对待，我们将使用审计工具进行测试，保证检测过程的标准化。该MVP旨在打造一个可行的概念，并最终以开源形式供更多企业使用。当更多企业采用相同的方法测试控制措施时，我们将获得对各种风险及其控制措施的有效性的更深入的理解，这些信息可以在CA工具社区内共享。
未经授权访问（R101）是一个示例风险。这个示例的风险控制措施包括：
· 密码控制，强制所有用户每90天更改一次密码，避免长时间使用同一密码（C101-1）。
· 为每个用户启用MFA（C101-2）。
· 监控网络入侵者（SSH流量）（C101-3）。
如第一篇文章所述，风险控制措施最好以标准格式定义，例如Gherkin语言。
#Control：C101-1（ISO 27001:2013附录A）
Given鉴于用户需要至少每90天更改一次密码
When 90天期限到期
Then用户会收到一个弹出窗口以重置密码
该控制措施可以通过CA工具进行监控，方法是检索证据来证明C101-1确实对所有用户有效。实现方式是调用一个Azure REST API，该API返回密码的过期日期。
表1.10.1提供了MVP的工具、技术、功能和对象的概览。这些在下面的部分中进行解释。
表1.10.1 CA工具的功能
1．用户界面
本节将探讨并评估用户界面的功能、路线图和技术层面。
（1）界面功能
用户界面目前仅限于最基本功能。界面左侧显示带有控制ID、控制定义和控制阈值的控制项。中间部分显示通过REST API从监控系统获取的证据值，右侧则显示控制阈值与证据值的比较结果。如图1.10.1所示。
图1.10.1 CA工具的用户界面
（2）界面路线图
目前的用户界面是初稿，仅适用于演示用途。要打造完善的CA工具，必须建立风险管理、受管对象、控制和证据的CRUD功能。这些对象必须能够相互关联，并具备报告功能。
此外，还应提供仪表板，以便从价值流和用例深入受管对象都带有细化查询的界面，包括展示交通灯式的风险指示。
用例只有在所有相关的受管对象也为绿色时才会呈现绿色状态。信息的呈现应主要集中在一目了然地看到价值流被控制的程度。同时，界面应能够建立起控制措施与诸如ISO 27001:2013等标准框架之间的关联，并清晰呈现控制措施的掌握程度。所以我们需要定义清晰的导航路径，以便于针对每个附录A控制，能够立即根据该控制措施获得的证据，核查已控制的风险及其控制程度。
（3）图形化技术
Flask GUI提供了一个简洁但功能强大的Web界面，可快速简便地构建。它拥有预定义的组件，能够快速开发出美观的界面。
2．应用
本节将探讨并评估应用程序的功能、路线图和技术层面。
（1）应用程序功能
app.py应用程序用于发布index.html中的内容。这些内容是通过Flask的SQLAlchemy接口从Postgressql数据库（ca_db）中获取信息来接收的。app.py的伪代码如下：
· 定义控制表和证据表的控制模型。
· 定义用于检索成功和失败的函数。
· 返回render_template index.html。
（2）应用程序路线图
这是一个非常基本的CA工具实现，表明可以快速创建仪表板。为了谈论可以快速部署的CA工具，有许多内容需要添加。有以下几个方面：
· 规则引擎：阈值和证据值的评估必须扩展到控制值中的表达式。因此，不仅要定义阈值，还要定义表达式，例如“<=”“==”“>=”。规则必须使用这些表达式和阈值。表达式必须足够丰富，才能触发多个控制。这意味着必须有许多运算符，并且还可以有更多的值。必须能够通过app.py中的REST API轻松输入新规则。
· 证据：证据现在是未格式化的，由阈值组成。为了评估复杂规则，必须定义证据结构，例如以JSON格式。需要处理来自JSON格式的值以及来自规则的信息要求。可以为每行设计一个独特的JSON结构。
· 模式：规则基于受管对象和风险。为了限制规则的数量，有必要定义适用于同一风险的多个受管对象的模式。例如，适用于SQL Server和Postgresql托管对象的规则。同样，一个规则可以用于多种风险。
（3）应用技术
Flask不仅提供Web界面，还提供称为SQLAlchemy的对象关系模型（Object Relation Model, ORM）。该接口建立了ProgreSQL中的表和Python中的类之间的关系。为此必须提供一个控制模型，尽管SQLAlchemy也提供了使用模块“automap_base”自动执行此操作的选项。db.session.query函数允许使用查询的内容填充列表，其中也允许连接。正如你所知，Python是一种简单的编程语言，这对于CA工具代码的编程也是如此。
3．数据库
本节将探讨并评估数据库的功能、路线图和技术层面。
（1）数据库功能
数据库的功能保持了精简。共有两个Python脚本用于实现相关功能：
· CA_schema.py脚本：该脚本负责创建数据库表格以及相关的测试案例。
· CA_population.py脚本：该脚本为数据模型提供基础性填充，包括风险、受管对象以及管控措施等数据。
· 证据的填充是通过调用Azure REST API来实现的。
图1.10.2展示了CA工具实体关系图。
图1.10.2 CA工具实体关系图
（2）数据库路线图
为了实现数据模型的管理，为数据库提供标准迁移脚本是有必要的。由于数据库工具具有迁移需求，我们无法在数据模型中定义业务规则，但是，仍然需要创建参照完整性和索引。
（3）数据库技术
目前，PostgreSQL完全符合CA工具的各项要求和期望。企业组织可以选择具有故障回退选项的集群技术。实体关系图是在MySQL工作台中创建的。但是，该工具只能通过商业ODBC适配器连接到PostgreSQL。然而，将CA工具迁移到MySQL的过程非常简单，只需要在Python中以不同的方式编程连接即可。
· 寻找合适的REST API相当困难。尽管Azure和AWS都提供了此类API，但需要对这些环境有深入的了解才能快速找到合适的接口。
· 利用开源工具可以相对快速地构建自定义工具，但需要密切关注系统软件的兼容性，尤其是在硬件设备老化的情况下。
· CA工具需要有比REST API采集器更多的功能。例如，必须配备能够将证据与标准进行比对的规则引擎，还应支持对基础对象（包括受管对象、风险、控制措施、规则和证据集合）进行灵活定义。可以考虑为此构建一个JSON接口，并通过REST API进行调用。
· 必须连接S-CMDB工具，以确保被管理对象的完整性。
· 采用控制模式以减少控制数量。为实现控制重用，应选用相应的约定规范。
· 开源CA工具是理想的解决方案。如果社区能够推广开源CA工具，将会为业界带来巨大裨益。