信息安全从业人员在参加我们TOGAF 培训时，经常会问上海信息化培训中心老师一个问题：数字化转型过程中，如何将风险和安全整合到企业架构之中？ TOGAF 如何在企业建设信息安全时发挥作用？作为企业安全架构师怎么用TOGAF来指导工作？
一、业务驱动方法将安全架构与企业架构关联起来
企业架构EA（其中包括安全架构）通过调整业务系统与信息支持系统的一致性，可以有效且高效地实现业务目标的架构。
安全架构 （ Security Architecture ） 是由组织、概念、逻辑和物理组件组成的结构体（Structure），这些组件以一致的方式交互，从而实现并保持管理风险和安全（或信息安全）的状态。
企业安全架构ESA在这里是一个通用的安全架构概念，包括了安全架构师们经常所使用的信息安全管理（Information Security Management , ISM）和企业风险管理（Enterprise Risk Management , ERM）概念和过程。
下图展示了企业架构和企业安全架构如何相互关联，重点介绍中的ISM和ERM核心概念。这些概念已在图1的中间部分列举出来，并形成了一系列可以补充和增强TOGAF标准的基础概念，带有下划线的概念是由ISM或ERM引入的对于TOGAF框架的补充。
由业务驱动（Business-driven）并支持ISM和ERM这两个过程的整合。这种过程导向 （ Process Orientation ） 通过TOGAF架构开发方法（Architecture Development Method , ADM）增进对不同阶段安全概念和活动的理解。业务导向（Business Orientation） 将有助于证明安全组件的合理性。业务驱动方法（Business-driven Approach）是安全架 构的关键所在：业务驱动程序为风险评估提供上下文；定义是否需要遵守某些控制框架，并证明采取安全控制措施的必要性。
安全是一个跨领域横切面的关切
TOGAF标准中，安全架构是一个跨领域的关切（ Cross-Cutting Concern ） ，贯穿整个企业架构。安全架构可以描述为视图、视角和制品的一致集合，包括安全、隐私和运营风险角度，以及相关主题，如安全目标和安全服务。安全架构不仅仅是一个数据集；安全架构包括ISM和ERM两个部分。 TOGAF ADM 涵盖了作为企业架构子集的业务、数据、应用和技术架构这四类架构域的开发工作。安全架构与这四类架构相互作用，因此，组织也需要从跨领域横切面（Cross-cutting）的角度全盘考虑。
作为一个跨领域关注点，安全架构也将冲击并影响企业的业务、数据、应用和技术架构域。安全架构可能经常位于组织的架构范围之外，但是某些部分需要与架构以集成的方式开发。
控制措施检查清单的选择与SABSA安全架构
首先，集成安全性不只是从检查清单（Checklist）中选择控制措施。The Open Group提倡对安全采取更加全面的方法，以便交付一个值得信赖的、稳健的、可靠的、安全的和可受风险管理的架构。为实现这个目标，企业安全架构确保ADM与ISM和ERM过程之间紧密协作。因此，本指南中大多数安全概念都涉及正确建设安全所需的内容。
然而，运营安全设计也是架构的一部分。在架构的环境中，安全控制措施绑定到安全服务之中。安全服务可以看作是架构构建块（Architecture Building Block , ABB）。在TOGAF标准中，ABB收集架构需求，这些需求将指导解决方案构建块（Solution Building Blocks , SBBs）的开发。此方法可以应用于TOGAF的所有四个领域架构：业务架构（Business）、数据架构（Data）、应用架构（Application）和技术架构（Technology）。同样，安全服务将收集安全需求并指导子服务和组件的开发。 安全服务的实例包括： • 身份和访问控制管理（Identity & Access Management） • 连续性管理（Continuity Management） • 安全情报（Security Intelligence） • 数字取证（Digital Forensics） • 审计（Audit） • 网络持续监测（Network Monitoring） • 合规性管理（Compliance Management） • 培训和安全意识宣贯项目（Training & Awareness Programs） • 等等
安全服务位于SABSA®架构框架的逻辑层中，该框架在TOGAF ADM的阶段C信息系统架构（Information Systems Architecture）中开发。安全服务目录提供了这些安全服务的实际描述（Actual Description）。
为了支持安全从业人员实际设计和使用安全服务，需要一套“安全服务目录（Security Services Catalog , SSC）”。对于安全架构师而言，安全服务目录是一张登记表。安全服务目录支持用安全控制措施实现SABSA架构框架的逻辑层。与包含需求的现有控制框架不同，安全服务目录描述了实际提供保护的安全构建块（Security Building Blocks，SBBs）。这种架构 方法使信息安全在企业架构中顺利集成变为可能。
标准化方法有助于安全管理组织的专业化，并有助于形成更有效、更具成本效益的工作方式。安全服务目录的一个主要优点是为安全管理领域提供了一个通用术语和参考框架，从而有助于各相关方之间更好地合作。
二、安全架构工作可以参考的信息安全和风险标准
ISO / IEC 27001：2013：信息安全管理标准
ISO / IEC 27001：2013是国际标准，规定了在组织范围内建立、实施、维护和持续改进信息安全管理体系ISMS的要求。该国际标准还包括评估要求和为组织需求而量身定制的信息安全风险应对控制措施。” 可将ISO / IEC 27001：2013的核心概念作为ISM过程的基础。
ISO 31000：2009：风险管理标准‒原则和准则
ISO 31000：2009 列出了适用于任何类型组织的风险管理原则、框架和过程。ISO 31000：2009 没有强制采用统一方法，而是强调必须根据特定组织的特定需求和架构定制风险管理。可将ISO 31000：2009的核心概念作为ERM过程的基础。
NIST网络安全框架
2014年推出的NIST网络安全框架（Cybersecurity Framework）旨在帮助关键基础架构领域内的组织降低风险并保护其关键性基础架构。NIST网络安全框架将安全功能分为以下五个领域：识别（Identify）、保护（Protect）、检测（Detect）、响应（Respond）和恢复（Recover）。对于在关键基础架构领域中希望将安全和风险纳入其TOGAF标准实践以及企业架构中的架构师们来说，NIST是个很好的参考。
COBIT 治理框架
COBIT （Control Objectives for Information and related Technology，信息及相关技术的控制目标）提供了一个全面的框架，可帮助企业实现其对企业IT治理和管理的目标。通过在实现收益与优化风险水平和资源使用之间保持平衡帮助企业使用信息技术（Information Technology , IT）创造最佳价值。COBIT可为企业各个级别的信息安全专业人员和其他相关方提供了更详细、更实用的指导。
MoR 风险管理框架
旨在帮助组织建立有效的框架，以便就影响所有组织活动（包括战略、项目群、项目、运营等四方面）的绩效目标的风险做出明智的决策。
COSO企业风险管理ERM
企业风险管理的基本前提是每个实体的存在都是为了为其利益相关者提供价值。所有实体都面临不确定性，管理层面临的挑战是确定在努力提高利益相关者价值时，应接受多少不确定性。不确定性既带来风险，也带来机会，有可能侵蚀或提升价值。企业风险管理使管理层能够有效应对不确定性以及相关的风险和机会，从而增强了创造价值的能力。
O-ESA
The Open Group在2011年发布的开放式企业安全架构（The Open Enterprise Security Architecture , O-ESA）标准是安全架构（Security Architecture）和构建安全程序的参考指南。O-ESA包含安全架构中所需的信息安全治理、安全性原则以及技术组件和服务等有用信息，且该参考架构也可以用于支持使用TOGAF标准在企业架构（Enterprise Architectures）中确保安全和规避风险。
O-ISM3
The Open Group在2011年发布的开放式信息安全管理成熟度模型（The Open Information Security Management Maturity Model，O-ISM3）标准描述了一种基于过程的方法构建和操作信息安全管理体系（Information Security Management System ，ISMS）。 ISMS的成功运行通常是企业架构（Enterprise Architecture）达成组织所设安全目标的先决条件。《安全架构从业人员指南（Security Architecture Practitioners Guide）》的一章将专门讨论企业架构、TOGAF标准和ISMS之间的关系。O-ISM3标准将安全服务定义为企业的战略战术或运营流程，并提供基于度量的方法进行持续改进。预计O-ISM3标准中描述的许多服 务或流程也将在安全服务目录项目（Security Services Catalog Project）中引用。
Open FAIR
Open FAIR知识体系包括风险分类法（Open FAIR Body of Knowledge comprises the Risk Taxonomy , O-RT）标准和风险分析（Open FAIR Body of Knowledge comprises the Risk Analysis , O-RA）标准。这些标准可帮助组织更好地衡量其信息安全和运营风险。Open FAIR定量风险分析方法在威胁评估中非常实用，有助于了解ADM周期中缓解威胁方法所带来的影响。Open FAIR也可被视作分析整个TOGAF ADM风险的工具或技术。
SABSA®
SABSA，即舍伍德商业应用安全架构( Sherwood Applied Business Security Architecture，SABSA)是一种用于风险驱动（Risk-driven）的企业信息安全和信息保证架构的开发方法，也是提供支持关键业务计划的安全基础架构解决方案。SABSA是一个包括多种框架、模型、方法和过程的开放标准。作为企业安全架构（Enterprise Security Architecture）框架， SABSA允许使用现有的标准和实践（例如ISO / IEC 27001：2013、COBIT和ISO31000：2009）。SABSA可供所有人免费使用，适用于在开发和实施架构和解决方案中使用该标准的最终用户组织，且无需许可。
SABSA 模型基于Zachman框架，适用于安全架构。SABSA包括6层，其中安全服务管理架构层纵向贯穿其他5层。
SABSA®Blue Book 中对SABSA进行了详尽的描述。另外，新的SABSA思路也发布在网站 www.sabsa.org 。SABSA背后的基本思想是使用安全架构（Security Architecture）促进业务发展，这也符合TOGAF的理念。
三、企业安全架构
安全架构是一个由组织、概念、逻辑和物理组件组成的结构体，这些组件以一致的方式交互，实现和维护对风险状态的管理。安全架构是企业安全性、防护性、弹性及可靠性提升的推动者/驱动者，并负责在整个企业的风险范畴内维护隐私性。
安全架构组件总是与架构中的其他元素存在各种关系。因此，尽管安全架构（Security Architecture）本身可能被视为一套架构，但安全架构绝不是一套孤立的架构。
安全架构管理的风险种类很多。其中两个重要的风险是业务风险（Business Risk）和运营风险（Operational Risk）。安全架构提出了平衡风险观（Balanced View on Risk）：将负面后果保持在可接受水平，并最大限度地利用正面机会。业务驱动方法（Business-driven Approach）是安全架构的关键所在：业务驱动程序为风险评估提供上下文；定义是否需要遵守某些控制框架，并证明采取安全控制措施的必要性。
为了在架构中真正集成安全，应该使用系统工程方法（System Engineering Approach）。这意味着应在所讨论主题的系统工程开发生命周期的前期考虑安全和风险。在开发生命周期的每个阶段，都会开展适当的安全和风险相关活动。这些活动可能从早期阶段的顶层建议和指导到结束阶段的详细安全检查不等。这样，一个安全的运营体系就得以实现，这个运营体系是可靠的、安全的、有弹性的，并且尊重隐私问题。此外，这些活动还会持续提升安全性。
在运营阶段，应该监测、评估和报告架构安全的各方面。虽然运营阶段通常要等到TOGAF ADM的第一次迭代完成才开始，但是在ADM阶段G和H中，需要设计和集成安全性度量功能。
“企业（Enterprise）”表示安全架构所处理的抽象层。“企业”的概念意味着在组织最高级别而不是在普通级别进行业务 调整。TOGAF标准将“企业”定义为组织的最高级别，通常涵盖所有任务和职能。
企业安全架构寻求安全控制措施与业务目标的业务一致性（Business Alignment）。通过定义不同架构层上的组件之间的关系实现，从而提供可追溯性（Traceability ）和合理性。企业安全架构师们通常使用ISM和ERM过程开发可交付成果并与利益相关方互动。
企业风险管理
基于ISO 31000:2009定义风险。风险是不确定性对企业目标实现的影响。企业如果有更高质量的信息，那么可以做出更高质量的决策。每一个决定都是基于评估在潜在机会和威胁，有利结果与有害结果的可能性，这些潜在积极或消极事件的规模，以及与每一个确定结果相关的可能性之间的平衡。识别（Identifying）和评估（Assessing）这些因素被称为“风险评估”或“风险分析”。“风险管理”是将这些概念应用于决策过程的艺术和科学。风险存在于长期战略层面（业务的总体方向）、中期战术层面（转型项目和计划）以及短期运营层面（日常运营决策、过程和实践）之中。风险管理的目标是优化业务成果，实现业务价值最大化和业务损失最小化。风险可以在业务堆栈的任何级别上看到（参见图2），但总是根据业务价值评估及其优化自上而下驱动的。
不确定性通常包括信息的缺失，导致知识或理解的不足或不完整。在风险管理的背景下，对事件、后果或可能性的认识或理解不足或不完全时，就存在不确定性。
这种平衡风险观也植根于SABSA模型，包括实现机会带来的利益以及控制威胁的影响。可以说，企业架构师的独特作用是创建一个运营环境，在这个环境中，可以优化运营风险，实现最大的业务收益和最小的业务损失。
运营风险是指企业在经营活动中所面临的威胁和机遇。SABSA是一个架构和运营框架，用于抓住机会，实现积极成果，达成既定的业务目标，并在企业对风险的承受能力（即风险偏好）范围内管理损失事件的消极后果。
企业风险管理的核心概念
根据ISO 31000:2009标准的阐述，风险管理过程通过考虑不确定性和未来事件或情况（预期或非预期）的可能性及其对商定目标的影响辅助决策。ISO 31000:2009标准还提供了一个风险管理过程模型，如图4所示。ISO 31000:2009标准明确指出，风险管理应深入并牢固地嵌入所有业务活动之中。此外，ISO 31000:2009标准还宣称风险管理是一个不断循环的生命周期，而不是一次孤立的活动。这个定义的核心是有效的风险管理是对预期目标（Expected Objective）的管理。每个步骤都有需要管理的风险因素，每一个结果都是不确定的。企业风险管理就是关于减少不确定性的活动。
以下概念对ERM很重要： • 关键风险领域（Key Risk Area） • 业务影响分析（Business Impact Analysis，BIA） • 风险评估（Risk Assessment） • 业务风险模型/风险登记表（Business Risk Model/Risk Register） • 风险偏好（Risk Appetite） • 风险缓解计划/风险处理计划（Risk Mitigation Plan/Risk Treatment Plan）
信息安全管理
信息安全管理（Information Security Management，ISM）是定义安全目标、分配信息安全风险所有权以及实施安全控制措施的过程。安全管理过程包括风险评估、安全控制措施的定义及妥善部署、安全状态（已定义、到位和有效的安全控制措施）的报告和安全事件的处理。
信息安全
对于许多安全从业人员来说，信息安全有三个核心支柱：机密性、完整性和可用性，也称为CIA三元组。在需要对信息系统进行分级以确定适用的安全性要求的技术环境中，这些方法非常有效。可根据保密方案（高-中-低）分级。特别是在金融行业，基于CIA三元组的安全分级方案遍及整个组织。
CIA三元组的定义如此广泛，这也是CIA三元组的弱点所在：在两种不同的场景中，CIA三元组可能意味着完全不同的事务。 例如，“可用性”可以代表： • 运行时间（Up-time）‒系统的最小运行时间覆盖99.9%的营业时间 • 响应度（Responsiveness）‒每个事务的最小响应时间为0.01毫秒 • 已归档（Archive）‒医疗数据的保证留存时间为7年 • 已删除（Erased）-服务器上的所有数据在发送到垃圾箱之前都应不可恢复 • 可恢复（Recoverable）-如果系统因灾难而发生故障，应在24小时内恢复
为此，本文从狭隘的CIA三元组转移到一个广义的术语，既具体又有利于商业环境。这是由SABSA业务属性模型提供的，如“需求管理”一节所述。业务属性提供了一种灵活而强大的方式表达企业所有方的安全问题。
业务属性模型（Business Attribute Model）还提供功效度量能力。安全控制措施的有效性与其所减轻的风险有关。企业往往在了解资产价值之前，无法确定企业愿意在确保资产安全上面花费多少金钱。例如，在应用程序中使用该资产以及资产因此而面临的连带风险，将决定对安全性的真正要求。此外，组织对风险的容忍度也是一个因素。换言之，提出的问题不应该是：“安全吗？”而是：“足够安全吗？”。后者是一个最终需要通过执行风险评估活动才能回答的问题。 • 资产保护（Asset Protection）- 保护信息资产免受损失或意外泄露，保护资源免受未授权和意外使用 • 风险评估（Risk Assessment）-识别面临的风险，测量以确定风险可能性和影响，然后根据组织的风险偏好接受、缓解或转移风险 • 访问控制（Access Control）-用户是谁，在什么条件下用户可以做什么活动？ • 审计（Audit ）-运营环境是否按照要求运行？ • 可用性（Availability ）—即使发生异常或恶意事件，也可以在不中断或未耗尽服务的情况下正常工作
隐私保护
隐私是指个体或群体将自身或自身信息隐藏起来的能力。隐私可被认为是私人事物的界限，在不同的文化和个人之间内容是不同的，但有共同的主题。隐私领域与安全部分重叠，例如，包括合理使用的概念，以及信息保护。 一般来说，隐私大多有指引的要求，除非满足透明度（Transparency）、合法目的（Legitimate Purpose）和恰当性（Proportionality）等三类条件，否则绝对不应处理个人数据。
信息安全管理的核心概念
根据ISO/IEC 27001:2013标准[4]，ISM体系通过应用风险管理过程来保护信息的安全性，并使相关方确信风险已得到了充分管理。ISM体系是组织过程和总体管理结构的一部分，并与之集成。 以下核心安全概念与ISM过程相关。这里列出这些核心安全概念是为了列举应该成为TOGAF标准一部分的核心信息安全概念。ISO/IEC 27001:2013标准的主要类别用于更好地理解概念之间的关系。
组织环境中的上下文背景（Context）指： • 安全域模型（Security Domain Model） • 业务驱动因素/业务目标（Business Drivers/Business Objectives） • 适用法律法规登记表（Applicable Law and Regulation Register） • 适用控制框架登记表（Applicable Control Framework Register） • 信任框架（Trust Framework）
领导力（Leadership） • 安全策略架构（Security Policy Architecture）
规划（Planning） • 安全原则（Security Principle） • 业务属性概述（Business Attribute Profile） • 控制目标/安全目标（Control Objectives/Security Objective） • 数据质量（Data Quality） • 业务风险模型/风险登记表（Business Risk Model/Risk Register） • 安全服务目录（Security Services Catalog，SSC）
支持（Support） • 安全资源计划（Security Resource Plan） • 安全培训和信息安全意识宣贯（Security Training & Awareness） • 安全标准（Security Standard）
运营（Operation） • 安全分级（Security Classification）
绩效评价（Performance Evaluation） • 安全审计（Security Audit）
改进（Improvement） • （无新的安全概念）
运营安全过程
运营阶段的控制措施是在TOGAF ADM阶段B、C、D和E期间设计的。ADM阶段F和G为以后在项目运营期间使用的指标定义提供指导。这就是为什么在设计阶段将运营安全过程作为安全服务目录的一部分而引入的原因。 其结果是，运营安全过程（如数字取证、安全情报或安全分析）将作为安全服务目录的一部分存在于架构之中。安全情报提供了分析和测量大量数据的方法，并将有意义的事件信息传递给整个组织中需要该信息的人员。
四、将安全和风险嵌入 TOGAF ADM过程推动安全架构
TOGAF ADM 包含的“ 制品 (Artifact) ”（工作成果）概念在每个阶段消耗或产生，为此用TOGAF术语表示企业安全架构的核心概念，并与TOGAF的概念关联，确保在适当的ADM阶段正确嵌入相关的安全和风险概念。图1展示了所有选定的SABSA制品的完整概述。
以下分别在TOGAF ADM 的每一阶段对这些核心安全概念进行详细说明，还给出其在“架构框架 （ Architecture Framework ） ”中的位置。这些概念同时存在于TOGAF企业架构标准和企业安全架构之中。
1.预备阶段
预备阶段（Preliminary Phase）建立指导安全架构设计所需的安全上下文。为了构建安全上下文，在本阶段需要确定下列安全制品，这些制品可以集成到现有架构文档之中。
1.1 业务驱动因素/业务目标
在TOGAF架构框架中的位置：这是会对安全产生影响的TOGAF业务驱动的子集，作为整体架架构业务驱动的组成部分一起提供（TOGAF标准9.2版§32.2.9）。
O-ISM3 中称业务驱动因素为业务目标。每个组织都由于特定的目的而存在，要求设定目标并履行某些义务。理想目标或合规等业务目标可能是内部产生的，也可能是由外部（例如，政府）强加的。组织的成就取决于许多因素，其中之一就是信息安全。
1.2 安全原则
在TOGAF架构框架中的位置：安全原则(Security Principle)是解决安全架构的业务原则的子集，作为整体架构交付物（TOGAF标准9.2版§32.2.4）的组成部分呈现。 安全原则与其他架构原则一样，为制定符合企业风险承受能力的业务决策提供有价值的指导。
1.3风险偏好
在TOGAF架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ERM。
风险偏好（Risk Appetite）描述企业对风险的态度，并为组织提供决策指导，平衡为达到预期结果承担的风险。风险偏好可以表示为风险/业务影响以及可能性网格，对利润和损失的度量或定性度量（对人员伤亡或违反法律法规行为零容忍）的边界。风险偏好也可以用适当的“安全原则”表示。如果存在需要特别批准的主要利益相关方，也可以作为独立的交付物产生。风险偏好定义组织愿意接受的风险水平以及定义该水平的策略，也定义高于可接受水平时的风险缓解措施，如转移或规避。
1.4 关键风险领域/业务影响分析
在TOGAF架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ERM。
注意：风险分类分级（Risk Classification）在TOGAF标准9.2版的§27.2和§27.3中进行了描述，描述侧重于架构项目的风险。这里扩展了风险和风险评估概念。 预备阶段提出的关键风险领域为架构项目提供了上下文。在架构项目的阶段A应予以确认。
业务影响分析（Business Impact Analysis, BIA）可以应用于所有域，也可应用于架构路线图，是确定架构和路线图适用性的强大工具。业务影响分析指出，不适当且不充分的信息安全可能会对业务造成潜在的损失（或利润）。业务影响分析仅定义应该避免哪些与业务流程相关的影响，而不是发生这种影响的可能性。业务影响分析的交付物是架构范围内的关键风险领域列表，这些信息是风险评估的输入。
1.5 安全资源计划
在架构框架中的位置：TOGAF标准9.2版，ADM，预备阶段和阶段A。
在定义和建立企业架构团队时，将在预备阶段解决整个架构团队的架构工作资源计划，在阶段A就架构项目评估架构团队的能力。 根据企业架构团队的职责范围和架构项目范围，将确定提供架构安全要素所需的安全资源。 定义企业架构团队的关键环节是确定安全架构师的期望角色和职责。安全架构最佳实践将安全和风险集成在所有领域，其中的一个重要内容是在企业架构治理过程中建立安全架构的治理过程。 回答以下问题有助于确定团队和架构项目所需的安全和风险资源： • 安全或风险相关的常见问题是什么？ • 是否存在需要特定安全视图的与安全或风险相关的关键且有影响力的利益相关方？ • 架构是否仅针对于高风险领域？风险偏好是否过低？ • 安全支持是否可以根据需要向现有安全团队提出请求，还是作为整体架构团队的一部分需要专门的安全架构资源？ 预备阶段将确定企业架构中需要哪些安全制品以及由谁创建。正确地解决安全问题可能不需要交付所有安全制品，反之亦然。交付所有制品并不能保证安全性得到妥善地处置，反而可能还需要更多制品。 企业级架构中创建制品需要根据与关键利益相关方的讨论、架构团队的初步评估，对相关条例、适用的司法管辖区和对法律法规的评估。 现有资源可能用于能力级架构。例如，企业级安全策略或风险评估描述了特定情况下的安全原则、风险偏好和关键风险领域。
2 阶段A：架构愿景
总体而言，阶段A：架构愿景 （ Architecture Vision ） 对TOGAF ADM 阶段B、C和D中内容进行初步充分描述，以确保关键利益相关方可以认同最终状态的愿景。该愿景代表已定义问题的解决方案。
在阶段A将进行足够的与安全相关的架构设计，达到： • 使安全利益相关方满意，表明最终状态不会有任何未知或不可接受的风险，并且与公司策略、标准和原则保持一致 • 使业务利益相关方（尤其是那些控制预算的利益相关方）满意。安全架构有助于实现和支持所需的整体架构，在风险、合规和业务利益之间提供了适度平衡的商业机会和利益。
阶段A中，至关重要的是识别所有利益相关方、这些利益相关方的疑虑焦点以及批准架构相关要求的完整列表。所有利益相关方都会有安全和风险方面的顾虑及要求。将安全利益相关方分离开可确保该架构将满足部分利益相关方和部分需求。 收集利益相关方的需求，以确定解决利益相关方关心的各种问题所需的安全蓝图。安全蓝图（Security Blueprint）定义的水平可以向利益相关方充分保证最终的制品和交付物将妥善解决他们的顾虑。蓝图与架构描述相关的ADM阶段完成并添加了所需的详细信息。 利益相关方通常会关注与安全架构有关的价值。价值可能是衡量降低风险和实现总体架构中的一个项目。业务属性概述（Business Attribute Profile）1可用作业务案例的基础。特定的业务属性概述可能还没有，因此可以将SABSA提供的业务属性概述作为出发点。可以采用基于场景的方法获得利益相关方的批准。 视角和业务案例必须建立在安全原则、驱动因素、关键风险和风险承受能力基础之上，并且应成为整体架构愿景交付物的组成部分。
3 阶段B：业务架构
阶段B：业务架构的安全元素包括业务级别的信任、风险和控制措施，独立于特定架构范围内特定的IT或其他系统。
与安全相关的业务架构制品列举如下。
3.1 安全策略架构
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）：ISM。
安全策略架构（或框架）包含一组安全策略,为安全和风险管理分配所有权和责任。安全策略架构一般通过不同的安全度（如业务连续性、信息安全、系统安全或物理安全）解决运营风险管理中的关联性（Linkage）和体系化问题。
3.2 安全域模型
在架构框架中的位置：TOGAF标准9.2版§A.24（信息域）。全文如下：“按照一组诸如安全等级、所有权、位置等准则分组后的信息（或数据实体）。在安全背景环境中，信息域被定义为一组用户、用户信息对象以及一种安全策略。”
注意：信息域（Information Domain）概念等同于下述安全域（Security Domain）的定义。 安全域表示一组可以用相似业务属性描述的资产。换而言之，安全域是一个安全策略管辖范围内具有相同安全水平的资产组。此外，安全域模型有助于定义与外部各方交换责任的责任区域，也可用于区分不同安全或信任水平区域。安全策略机构负责在域内设置和实施安全策略。 如果组织的业务模型的确包含与其他组织的联盟，则应在流程运行时确定安全联盟范围。拥有共同数据对象或活动的组织就是这种情况。应检查联盟合同协议对安全和协议的影响。如果联盟的其他成员同属一个安全域，则可能有必要与他们建立联合架构会议。
3.3 信任框架
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ISM。 信任关系（Trust Relationship）是与另一方开展业务的基础。信任框架描述了架构域中各个实体间的信任关系以及该信任存在的基础。信任关系可以是单向或双向的，甚至可以不建立信任关系。评估信任是决定签订合同的人士及其法律顾问的责任。需要特别注意，数字证书等技术并不能建立信任，而只能把现实世界中已经存在的信任通过业务关系、法律协议和安全策略一致性传递到电子世界之中。
3.4 风险评估
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ERM。
尽管TOGAF标准9.2版§27.4（初始风险评估）描述了一种管理风险评估结果的方法，但并未描述评估风险的实际行动和方法。因此，本文对该概念给予补充，与TOGAF标准一起使用。 风险评估（Risk Assessment）是确定与资产或目标相关的风险的活动。定性风险评估（Qualitative Risk Assessment）以“高-中-低”优先级形式提供相关风险场景的概要列表。定量风险评估（Quantitative Risk Assessment）方法则寻求量化风险，通常是基于已识别的威胁、威胁发生的可能性及事件的影响。风险评估的交付物是业务风险模型（Business Risk Model）。
3.5 业务风险模型/风险登记表
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ERM。 业务风险模型可被看做是风险登记表（Risk Register），确定在故障时发生资产损失/影响的定性或定量成本,根据已识别的威胁、发生的可能性及事件的影响进行风险评估的结果。业务影响应与作为伪资产的业务属性概述中的定义保持一致。此阶段应根据已识别的风险对安全进行分级。业务风险模型是组织风险策略的明细化。信息的分级决定企业愿意接受的最大风险，信息所有者决定哪种安全缓解控制措施能够保护其信息的安全需求水平。
3.6 适用法律法规登记表
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）：ISM。 适用法律法规登记表包含根据业务功能清单在企业架构涉及范围内适用的特定法律法规，并随着法律法规变化而保持最新状态。适用法律法规登记表对合规工作至关重要。 业务功能是否受监管取决于整个系统的功能及收集或维护的数据。此外，相关信息包括支持系统或服务部署在的或用户所在的法律司法管辖区等。明智的做法是在活动开始时就获得这些法律建议。
3.7 适用控制框架登记表
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）: ISM。 适用控制框架登记表包含一组适当的控制框架，最能满足要求并解决与涉及范围和上下文 （ Context ） 有关的风险。控制框架包含要求和 / 或强制性安全措施，示例有 ISO / IEC 27001：2013 [4]、ISO / IEC 27002：2013、COBIT、PCI-DSS以及通用标准等。
4. 阶段C：信息系统架构
阶段C：信息系统架构的安全要素包括功能性安全服务及安全分级（Security Classification）。 信息系统架构相关制品（Artifact）将在下面详述。
4.1 安全服务目录
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）：ISM。 注意：TOGAF标准有一个“业务服务目录（Business Services Catalog）”，列出了企业的业务服务及其功能性和非功能性需求以供分析。安全服务目录存储并提供每种服务进一步的信息，因此需要进行介绍。
安全服务目录是一个服务列表，其服务作为整体架构中特定于安全功能的部分。与包含需求的控制框架不同，安全服务目录描述实际用于实现安全目标的安全构建块，为安全管理领域提供通用的术语和参考框架。安全服务目录包含服务的概念定义以及有关实现和使用的运营信息。
安全服务的实例包括： •身份和访问控制管理（Identity & Access Management） • 连续性管理（Continuity Management） • 安全情报 （Security Intelligence） •数字取证 （Digital Forensics） • 安全分析 （Security Analytics） • 审计、网络持续监测 （Audit, Network Monitoring） • 合规性管理 （Compliance Management） • 培训和安全意识宣贯计划 （Training & Awareness Programs） 这是大多数安全从业人员都认可的安全领域划分方式。安全服务目录的主要优点之一 在于其是安全管理领域的通用术语和参考框架，便于相关各方之间更好地合作。
4.2 安全分级
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）：ISM。 安全分级（Security Classification）是根据分级方案附加在资产上的标签。大多数情况下，该方案在公司信息安全策略中定义和描述，并且分级基于资产的一个或多个特征。 资产可以是架构的任何相关组件。资产包括业务服务、功能、信息、信息系统服务、物理数据组件或物理技术组件。安全分级确定适用于资产的安全要求，如访问控制、机密性或可用性。这些都是实施安全策略的常用手段。
4.3 数据质量
注意：从企业安全架构角度看，数据质量要求是安全需求的组成部分，同样与风险评估和安全控制措施的选择相关。 数据质量（ Data Quality ）是运营风险管理的关键因素。影响数据质量的一些关键属性有准确性（Accuracy）、相关性（Relevance）、及时性（Timeliness）、时效性（Currency）、完备性（Completeness）、一致性（Consistency）、可用性（Availability）和可访问性（Accessibility）。保障数据质量始于对相关数据集的清晰概述。对每个数据集都需要分配所有权和对数据质量的责任。在某些情况下对数据采取特定活动的受信任的人员或流程由所有者授权。 为了正确处理数据，可能还需要更改信息系统。最后，应基于日志和性能数据衡量每个关键属性。
5 阶段D：技术架构
在大多数情况下，没有必要开发特定的技术架构安全制品，因为它包含在早期阶段定义的相关安全控制和机制之中。安全架构师必须确保所需的控制措施包含在技术架构中，并验证控制是否以有效高效的方式工作。控制措施包括用于提供和规范系统资源（如电力功率、处理能力、网络带宽和内存）的技术。 安全利益相关方可以要求创建特定的技术架构安全视图或交付物，描述所有与安全相关的技术组件以及它们之间的相互关系。该视图应说明使用哪种技术可以减轻哪些业务风险，从而可对该技术进行评价。
6 阶段E：机会和解决方案
确定路线图要就需要解决得差距确定先后次序，就需要评估安全和风险。确保在分析中解决相关方的安全和风险顾虑，并确认已咨询风险所有者。期望工作包提供的价值应包括与安全和风险价值有关的安全控制措施，确保路线图满足完整的业务目标和驱动因素。 前一阶段中定义的安全构建块在此阶段中演变为SBBs，用以定义更具体的面向实现的需求和规范。在此阶段可能需要一个完整的解决方案设计。 基准安全架构的安全服务目录可能包含满足要求的已有安全服务或安全构建块。例如，如果存在对应用程序访问控制的要求，则已有的中央身份验证服务可用。必须验证重用的已有安全服务和控件的功效，确保最终状态包含安全控制措施，且这些控制措施可以正常地工作和集成。
6.1 风险缓解计划
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）：ERM。 TOGAF标准9.2版中，风险缓解用于过渡风险，但未说明如何创建风险缓解策略或存在哪些可能的风险缓解策略，因此本指南提供了该问题的额外指南。 风险缓解计划（Risk Mitigation Plan）包含减缓风险的活动。这是风险缓解策略的实施，旨在提高控制水平、将风险转移给第三方、通过更改业务活动规避风险、延迟风险或补偿风险等。 在此阶段，ERM过程解决更多的风险，范围包括在ADM中较早（阶段B）进行的风险评估确定的最新信息安全风险。这是风险得以“解决”或“处理”的抓手。风险缓解计划还应考虑采用新型架构所带来的风险。
7 阶段 F：迁移规划
迁移（Migration）本身就是需要保护的业务流程。迁移策略应包括风险评估和风险缓解计划。在阶段F，风险缓解计划仅限于过渡。这些概念已在ADM的早期阶段提及。实时环境的迁移应始终包括回归计划，以便有方法可以撤消失败的迁移。这是风险管理的重要组成部分。 此外，迁移计划应包括安全影响分析，以了解变更目标状态的任何安全影响。
8 阶段 G：实施治理
安全架构实施治理确保详细设计以及已实施的过程和系统遵循总体安全架构。这样确保与架构原则和实施准则的差异不会带来任何无法接受的风险。 以下制品与此阶段相关。
8.1 安全审计
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ISM。
安全审计（Security Audit）包括对实施的流程、技术设计、开发的代码以及针对策略和要求的配置就安全进行的审计，还包括安全测试。安全测试包括功能性安全测试、性能测试和渗透测试(Penetration Testing)。
8.2 安全培训和安全意识宣贯
在架构框架中的位置：企业安全架构（Enterprise Security Architecture）:ISM。
安全培训和安全意识宣贯意味着提供足够的培训，确保与安全相关的子系统和组件正确地部署、配置和操作，也包括对所有用户和非特权操作员就系统和/或其组件的安全意识宣贯。这对于适当、连续和安全的性能至关重要。 许多控制框架中，必须履行安全培训并记录结果以证明履行了职责。漏洞利用或错误损害安全目标时需要采取有力的纠正或惩处措施。上海信息化培训中心SITC是国内信息安全培训和安全意识宣贯头部专业机构。
9 阶段 H：架构变更管理
阶段H没有产生实际的安全输出，但定义了两个对持续满足业务需求和架构至关重要的过程：风险管理和架构治理。即使这两个过程不是正式的制品，将他们放在此处也强调了他们的重要性。 ERM是就业务机会和安全威胁带来的变化对现有架构持续评估的过程。根据此过程的结果，当前架构可能认为不再适合缓解已更改的或全新的风险，或者可能会过多限制业务利用新机会。 这种情况下就必须决定更改架构。 架构治理是一个过程，决定通过对当前迭代进行较小更改或通过全新迭代对现有架构进行变更。TOGAF架构治理框架（TOGAF标准9.2版§44.2）对此进行了说明。与风险和安全相关的变更应该是该框架明确包括的部分。对架构的重大更改应包括安全影响分析。
变更是由新需求或环境变化驱动的。例如，威胁环境的更改、合规要求的更改、或者现有流程和解决方案中发现的脆弱性导致的更改都需要更改安全需求。由于安全相关的原因需要进行的更改通常比简化或增量更改更具破坏性。 在确定安全更改是否触发TOGAF ADM周期的新迭代时必须格外小心。例如，企业风险偏好发生变化时，看似很小的安全需求更改很容易触发新的架构开发周期。 现有架构发生更改的一个例子是安全标准或要求发生更改。风险评估基于变更的价值，是业务改善机会与以安全术语表达的对业务的威胁之间的权衡，因此通常不会造成太大破坏。而变更本身带来的威胁可能会造成极大的破坏并导致付出昂贵代价。这是SABSA平衡风险观概念可用于决策的一个很好的例子。
10 需求管理
需求管理在架构工作中起着核心作用。需求管理的目的是通过一个可控制且可重复的过程，在架构开发的不同阶段识别、存储、维护和沟通业务需求。此外，还需要根据目标需求监测运营绩效，这在TOGAF ADM中没有明确说明，但在H阶段：架构变更管理和需求管理的持续验证中有描述。 可用TOGAF方法在架构开发项目的每个阶段验证和更新业务需求。然而，TOGAF标准并没有提供一个描述或记录需求的技术，这项技术在SABSA中有所呈现，将独特的业务属性分析技术作为有效描述需求的手段。本节描述了在安全需求管理方面如何使用业务属性分析，以及总体上此技术为需求管理提供的好处。
10.1 业务属性概况
架构框架中的位置：企业安全架构（Enterprise Security Architecture）：ISM
业务属性概述分析（Business Attribute Profiling）是一种SABSA需求工程技术，业务属性概述使用基于风险的方法，将业务目标和驱动因素转换为需求。这种技术的主要优点包括：
•基于非IT术语的管理层沟通 • 业务驱动因素和需求之间的可追溯映射 • 依照业务定义目标的绩效衡量 • 对需求进行分组和结构化，有助于架构师对需求的理解和监管
SABSA业务属性概述（Business Attribute Profile）是SABSA方法的核心。正是这种需求工程技术使SABSA非常独特，并在业务需求和技术(流程)设计之间建立了联系。参见SABSA®蓝皮书。
图6示例的分类法中每个SABSA业务属性都有一个详细的通用定义和一些建议的准则，用于将度量标准应用于该属性。架构师使用分类法作为指导原则构建一个业务属性概况，目标是记录现有业务用例的相关属性，根据业务用例重新定义每个选定的属性，开发与业务用例相关的度量方法、特定度量标准和绩效目标。该模型具有灵活性和自适应性，在需要时可以添加新属性和新定义满足业务需求。因此，该方法定义得很好，而且可以尽可能扩展业务属性分类法。根据架构团队正在考虑的业务用例，每个业务属性概述文件都是由架构团队根据业务用例进行高度定制的。
SABSA业务属性概况中一个必不可少的部分是选择用于设定目标的度量标准，以便在运营阶段对绩效进行度量（“组织达到目标了吗？”)。业务分析师可以选择在详细的示例中使用建议的度量标准，或者如果更合适的话可以创建新的度量标准。最终可能需要创建实时的运营风险仪表盘，可以根据预设的绩效目标监测运营能力的绩效，同时对即将发生并可能需要管理干预的风险事件提供预警。
O-ISM3 将绩效目标称为“安全目标 （ Security Target ） ”。除了根据重要业务表达安全目标外，O-ISM3还定义了可容忍的偏差。所有O-ISM3目标（业务和安全）中必须包括其对应的安全目标。在采取纠正措施之前，这是管理上所能容忍的与预期结果的最大偏差。O-ISM3可以支持任何指定的偏差。这使得O-ISM3项目能够支持和管理期望目标（其允许偏差可能非常高）及关键目标（通常合规范围非常窄）。
安全目标通常根据发生频率和阈值成本定义。缺失目标的可允许业务影响（Allowable Business Impact），反映了其他优先事项与目标之间的权衡。安全目标表明了组织对其信息安全投资的期望。在某种程度上，通过管理行为定义安全目标，并明确其风险偏好。
10.2 控制目标/安全目标
架构框架中的位置：企业安全架构(Enterprise Security Architecture)：ISM 一个控制目标（有时称为安全目标）是指特定流程、人员、活动、系统或数据集的安全期望状态。控制目标不同于安全需求，因为一个控制目标是ISM过程旨在实现的目标。该控制目标可能与安全需求不完全匹配。控制目标与业务属性关联。 O-ISM3使用依赖性分析（ Dependency Analysis ） 记录信息安全对实现业务目标的贡献。依赖性分析的输出是一个安全目标列表，这些目标构成了信息安全管理体系（ISMS）的设计、实现和监测基础。在规划企业架构时，这些目标还构造了安全组件的业务目标。安全目标（源自业务目标）明确说明信息安全是如何对业务目标做出贡献的。
一些安全目标源自业务目标的实例 ，例如“为所有提供的产品和服务记账”： • 发票只对会计和收款团队开放 • 已支付发票需保存三年，并在第四年之前销毁
10.3 安全标准
架构框架中的位置：TOGAF标准9.2版第37.4节（标准信息库）提供了储存库，用于存放架构必须遵循的一组规范。这些标准可以应用于TOGAF标准中的每个架构领域。安全标准也可以添加到现有目录中。 安全架构提供了在哪些情况下使用哪些安全标准的指导。业务负责人或业务分析师决定该安全标准是否适用。如果适用，则通过需求管理过程将该标准应用于架构工作中。该标准可以规定业务、数据、应用或技术架构的安全控制措施。 标准是用来确保许多不同的组件可以无缝集成，从而形成一个更大的系统。存在不同类型的标准，如监管标准、技术标准等，例如，适用于支付卡行业的PCI-DSS标准、适用于电信行业的ETSI标准等。同样值得注意的是，安全标准可能是外部施加的或者是内部开发的。
11 TOGAF架构内容元模型
TOGAF架构内容元模型（Architecture Content Metamodel）包括ISM和ERM建模所必需的概念。现有的实体（例如业务服务和信息系统服务）通过具有ISM和ERM特定的属性进行适配。
12 ArchiMate®建模语言的使用
ArchiMate语言支持ISM和ERM建模。这在 The Open Group 白皮书中有所描述：使用ArchiMate®语言对企业风险管理和安全建模[12]。图7给出了ArchiMate语言中的风险模型示例。
本文主要内容来自The Open Group®安全论坛与SABSA® Institute合作撰写《在TOGAF®企业架构中集成风险和安全白皮书》，为方便中文读者理解在编辑时略有删改补充，原文PDF下载https://www.opengroup.org.cn/api.php?id=107
上海信息化培训中心SITC是中国首家TOGAF授权培训机构，TOG地区认证合作伙伴，黄金会员，TOGAF首选培训机构。在TOGAF 本土化化进程中，发挥着关键引领作用。
上海信息化培训中心SITC是国内信息安全培训头部专业机构，提供本文中提到的所有信息安全和风险管理框架的专业培训，同时也提供CISSP, CISA, CISM, CCSK, CIPM等等信息安全专业资格认证培训。
