第1节
持续安全简介

阅读指南

本节介绍“持续安全”这一章的目的、定位和结构。

一、目标

本章的目标是讲述持续安全的基本知识以及应用持续万物这一领域的技巧和窍门。

二、定位

持续安全是持续万物概念的一个方面。本章包含了持续实施合规性的各种技术，这些技术可以在开发过程中不断提高信息系统的质量。持续安全是DevOps 8字环的组成之一，在如第一页的图0.1.1所示，贯穿整个流程。“持续”一词指的是采用增量和迭代的方式开发软件，形成一个代码流，并通过CI/CD安全流水线持续过渡到生产环境。这个代码流就如同一条价值流，需要不断优化。

持续安全是一种敏捷方法，我们可以在设计信息系统的过程中定义它的行为、功能和质量，用来实现所需要的控制，从而减轻或消除已识别的风险。持续安全与DevOps8字环的所有方面有直接或间接的关系，因为它是整体设计的。这意味着持续安全涵盖了信息系统（技术）、生产过程（流程）以及知识和技能（人员）等多个方面。因此，持续安全提供PPT层面的设计。

信息系统的设计是确保系统控制安全的重要基础。近年来，许多组织质疑信息系统的设计。将信息系统的信息捆绑起来并让所有利益相关方参与进来的传统做法被敏捷的工作方式和三人组开发策略视为已经过时的理念。这个做法意味着要从业务、开发和测试三个方面提前考虑一个要构建的增量。这样就能更好地解决“怎么做”和“做什么”的问题，并能就增量的DoD达成共识。但是，这忽略了设计另一个重要的功能：控制功能。该功能旨在通过实施适当的对策来防止因缺乏措施而导致的风险，包括但不限于违反法律和监管义务的风险。信息安全也是至关重要的控制要素，它涵盖信息的安全性、完整性和可用性。

从持续安全角度来看，DevOps领域的发展至关重要。目前，一些组织仍在采用瀑布式项目的工作方式，这种工作方式需要进行大量的设计工作；而另一些组织则发现仅仅使用用户故事并不是最佳方案，某种形式的设计仍然是必要的。因此，系统开发领域再次趋于平衡，为持续安全提供了坚实的基础。

当然，问题在于是否所有类型的信息系统都应该采用同样的工作结构。随着Gartner的BI模型的出现，区分SoR和SoE变得至关重要。除了SoE，现在人们还谈论SoI。图2.1.1概述了这三种类型的信息系统（SoR、SoE和SoI）之间的关系。

（1）SoR

SoR是后台办公室的信息系统，完成财务、物流、库存和人力资源管理任务。这些系统必须满足信息安全方面的CIA要求。这意味着，除了其他事项外，需要设计方案来表明财务数据是如何产生的，以及不同相关信息系统的接口是什么。这些系统通常是信息系统链的一部分。

这些系统需要经过深思熟虑，于是合规性在设计中发挥着重要作用。

（2）SoE

销售渠道，特别是网络商店和智能手机应用程序，是面向消费者的SoE的主要目标。这些应用程序可以轻松地提供新版本、补丁和更新。这些信息系统通常不是信息系统链的组成部分，而是链条的终点。在敏捷开发和DevOps的相关出版物中，它们也经常被用作案例。对于这些信息系统而言，显然事先经过考虑的设计（前置设计）是不太必要的，通常它们可以用成长式设计（新兴设计）来满足需求。

然而，将这些端点视为信息安全泄漏的潜在点非常重要。这就是为什么SoE除了用户故事集合之外，还需要更多内容的原因。信息安全也必须成为这些信息系统的一个组成部分。单独的用户故事并不能形成对信息系统的可访问描述。因此仍然需要一种能够提供系统功能、质量、操作和信息安全概览和洞察的设计方案。尤其重要的是，用户界面和数据源接口是安全和持续安全的重要方面。

（3）SoI

除了上述系统，还存在BI解决方案，具体指各式报告、数据分析工具等。与SoE类似，BI能基于SoR的信息进行呈现，并且更易于修改。然而，数据泄露和入侵始终是潜在风险。风险的高低取决于所提供信息的价值。因此，必须准确评估信息风险并采取相应的防范措施。

（4）持续安全的必要性

对于三种类型的信息系统（SoR、SoE和SoI），都需要一定程度的控制，因此我们需要进行持续安全。

单靠一组用户故事并不能全面了解和监控信息系统所承受的控制要求，也难以及时准确地识别出信息系统适应和扩展所带来的风险和影响。然而，必须避免风险应对措施（控制）的实施破坏生产过程的敏捷性。这意味着，不仅控制的设计和监控要增量迭代地进行（持续安全），而且控制的选择也必须基于加权风险进行，既不能太多，也不能太少。控制设计定义的程度可随信息系统类型而变化，从SoR的详细定义到SoE的精简定义，再到SoI的近乎无定义。即使对于SoR，控制设计也可以分为前置定义（提前）和新兴出现（迭代）的两个层面。

三、结构

本章介绍了如何使用ISVS模型来塑造持续安全。在讨论该模型之前，首先将讨论持续安全的基本概念和基本术语、定义、基石和架构，然后再深入探讨该模型。

1．基本概念和基本术语

本书的这部分阐述了持续安全涉及的基本概念和基本术语。

2．持续安全定义

有一个关于持续安全的共同定义是很重要的。因此，本书的这部分界定了这个概念，并讨论了信息系统设计和管理不当所造成的潜在问题及其成因。

3．持续安全基石

本书的这部分讨论了如何通过变更模式来定位持续安全，在此我们将得到以下问题的答案：

·　持续安全的愿景是什么（愿景）？

·　职责和权限是什么（权力）？

·　如何应用持续安全（组织）？

·　需要哪些人员和资源（资源）？

4．持续安全架构

本书的这部分介绍了持续安全的架构原则和模型。架构模型包括以下方面：

·　ISVS模型（ISO 27001）。

·　SVS模型（ITIL 4）。

·　DVS模型（敏捷Scrum）。

·　DevOps 8字环模型（DevOps流程模型）。

5．持续安全设计

ISVS由信息安全价值链组成，为信息安全价值流提供实质内容。价值流将基于用例进行描述。用例之间的关系将通过用例图展示。

6．持续安全最佳实践

本书的这部分介绍了如何构建ISVS，并讨论了一些持续安全最佳实践。

7．治理安全实践

本书的这部分讨论了治理安全实践。这些是管理ISVS价值链的最佳实践。它涉及获得高层管理层的承诺、确定利益相关方、确定范围、确定目标和确定信息安全政策等实践。对于每个安全实践，都将讨论用例、定义、目标以及应用示例。

8．风险安全实践

风险安全实践包括ISVS的操作最佳实践。这涉及确定问题、风险标准和信息资产，识别风险，进行风险评估和风险应对以及实现控制等实践。对于每个安全实践，都将讨论用例、定义、目标以及应用示例。

9．质量安全实践

质量安全实践包括内部审计和ISVS最佳实践的持续改进。对于每个安全实践，都将讨论用例、定义、目标以及应用示例（如有）。

10．持续安全与敏捷Scrum

孤立地实施持续安全毫无意义。系统开发（敏捷开发）与安全之间存在着太多的接口，因此学科之间的整合是必要的。本书的这部分将描述这种联系的本质。

11．持续安全与DevOps

信息安全与敏捷Scrum之间的联系是一个非常重要的改进。然而，为了实现持续安全，还需要与运维建立联系。本书的这部分讨论了如何使用持续万物的概念将持续安全与DevOps集成。 z4U+oi7C5aB8zubFjNPNkKXT1qB46ce65orlnw0elczIjHBPjUNQLcrr77pmoYla