本篇是《网络安全架构 | 通过安全架构提升安全性》的续集。Gartner关于网络安全架构的整体方法和详细过程，主要反映在这两篇之中，是Gartner关于安全架构方法的集大成之作，不可多得。
实现安全架构能力，需要仔细准备。此指导框架可以帮助网络安全技术专家，熟悉那些有助于创建安全架构过程的关键概念和决策过程。
本文运用了设计安全架构的方法论（Methodology）方法和框架（Framework）方法。方法论方法是一系列关于“如何”做某事的步骤或指南；框架方法一组关于“什么”的项目清单。关于安全架构的基本概念和作用价值，方法论方法（如SABSA）和框架方法（如NIST CSF）的详细信息，请参见《网络安全架构 | 通过安全架构提升安全性》。
关键词：方法论方法（Methodological approach）、框架方法（Frameworkapproach）；SABSA（Sherwood应用业务安全架构）、CSF（网络安全框架，包含框架核心、框架实现层、框架概要）、概要（Profile）；战略架构（Strategic architecture）、逻辑架构（Logical architecture）、技术架构（Technical architecture）。
一、要点总结
关键发现
■ 架构框架使用集体见解来创建最佳实践，指导用户考虑组织风险和业务环境。这些方法的改编和定制，将帮助组织从中获得最佳价值。
■ 方法论提供了一种系统工程方法，使用业务输入和期望，来创建可重复、可跟踪（自下而上和自上而下）的安全架构定义。
■ 架构框架可与安全架构方法论成功结合使用，从而解决涉及框架（如合规义务）的业务安全上下文和需求。
■ 战略架构、逻辑架构、技术架构的变化速度不同，结果也不同。因为交付方法决定了技术组件是如何建立的，所以编程实现方法可以帮助在变更期间实现严密性。
主要建议
作为解决安全架构中的技术、信息和弹性风险的技术专家，您应该：
■ 规划您与组织高级干系人的互动，以积累业务上下文信息并促进安全架构的益处。
■ 使用框架方法（如NIST CSF）加速构建安全架构。您必须计划定制它，以满足您明确定义的业务和战略目标。
■ 使用安全方法论（如SABSA）定义业务上下文，并在架构层次之间提供系统工程级别的可追溯性和严密性。
■ 评估框架和方法论的组合（两者并非互斥）如何能“两全其美”地利用它们各自的好处。
问题陈述
安全架构方法论和框架方法为了实现它们的全部价值，执行起来可能很复杂。缺乏经过深思熟虑的安全架构，将导致部署无效的安全能力（要么部署过度，要么存在差距）。客户试图了解如何实现安全架构能力，以便更好地为其组织服务。有几种不同的策略，包括方法论和框架，每种策略都有优缺点。
对安全架构活动的一种批评是，它们通常被视为昂贵的一次性活动或阻碍敏捷交付的活动，并且很快就不能反映运行时的实际情况。本指南解释了如何开始构建您自己的以组织为中心的自定义的安全架构方法的过程，包括如何将安全架构嵌入到交付实践中。它提供了关于如何准备好将安全架构作为组织中正在进行的活动来实现的指导。
Gartner方法
安全架构是高度结构化的，无论是就第一原则使用方法论开发，还是定制一个架构框架。成功的实现，需要在选择、设计、集成到现有业务实践的整个过程中，进行仔细的管理。选择并在某些情况下合并方法，以提供最合适的安全架构流程，是实现业务目标所必需的。为了清楚起见，本指南帮助用户准备并为其组织选择最合适的路径。
该指南指导您完成应该计划的活动，以支持实现安全架构方法。阶段从具有确定步骤的战略需求到帮助形成逻辑安全。它建议为了设计过程的顺利进行做好准备，以帮助实现必要的安全组件和技术。实现战略技术目标，意味着安全架构必须是一个活的过程，而不是一次性事件。该方法提供了指导，帮助将安全架构嵌入到业务和ITT实践中，以确保其被接受和集成。
风险和陷阱
安全架构项目的常见风险包括：
■ 缺乏深思熟虑的安全架构将导致部署无效的安全能力（要么部署过度，要么存在差距）。要非常周密，并在安全架构实现的各个阶段，包括所有干系人，以确保安全能力没有被错误地部署。
■ 在实施安全架构过程时，未能定义范围将导致定义错误的安全架构。不完整的范围边界，与无范围边界或只是假设的范围边界一样糟糕。因此，应尽一切努力确保覆盖度和完整性。与IT领导一起确认并确保为您的安全架构过程定义了正确范围。
■ 如果在不了解风险的情况下开发安全架构，组织本质上是在开发一个上下文无关的通用控制模板。这将没有重点，也不会解决一个组织面临的真正风险。所有的安全架构活动都应该致力于管理风险。
■ 识别现有的安全和控制框架。如果忽视或忽略此步骤，则所需的控制框架需求与安全架构设计之间可能存在不一致。治理和设计之间缺乏一致性，将导致控制不足或缺失，这可能导致审计失败。与所有安全治理和风险团队合作，并使用组织安全策略和标准，以帮助构建安全架构。
■ 如果没有有效的沟通计划，重大风险将影响安全架构活动的整体成功。如果不计划让干系人，特别是高级职员参与进来，他们很可能不会在你需要的时候立即出现。制定干系人参与计划。
■ 不仔细规划和准备这一阶段的风险，将使我们无法定义有效的安全架构。关键的风险在于没有足够详细的组织和业务流程信息，来决定所需的逻辑安全服务。通过访问这类文档以及与整个组织中可以提供指导的干系人进行联系，可以缓解这些问题。
■ 始终检查分层防御。不要跳过它，因为那样会引入与安全架构缜密性相关的潜在风险。在纸面上看起来所有的要求都得到了满足。但是，应验证补偿控制是否充分满足了要求。
■ 需要定义足够的触发器，以促使安全架构师将现有安全架构应用于新项目。
■ 架构师必须努力确保当业务目标发生变化时，能够及时更新逻辑和技术安全架构。还必须维护和更新为DevOps创建的参考架构和编程组件等构件。
二、指导框架
这个指导框架有助于定义安全架构的方法，它包括五个阶段，与实现的重点领域相一致。阶段包括：
1. 界定范围，理解环境。
2. 获得战略级的安全洞察力。
3. 支持逻辑安全架构的开发。
4. 促进技术安全架构的设计。
5. 使安全架构成为一个动态的活跃的过程。
图1总结了这些阶段，提供了每个阶段的子阶段活动和可能的结果。
图1-安全架构方法指导框架
后文是对图中每一步骤的具体介绍。
0、预加工：框架 vs. 方法论
在设计安全架构过程时，熟悉安全架构的方法论和框架非常重要。在本指南中，我们区分了方法论方法和框架方法，其中方法论方法把大部分工作留给实践者，而框架方法在本质上更具规范性。本指南将这些术语定义为：
■ 框架：一份可用于开始工作的设定的控制和实践的列表，即一份洗衣单或一组关于“什么”的项目。此外，框架可以与内部指令（如标准、政策和指南）相关，以帮助定义安全架构。
■ 方法论：一条从初始点到设定的期望点的路径，也就是一系列关于“如何”做某事的步骤或指南。
方法论可以是指一个框架或该框架的一个或多个步骤，并且可以指导客户使用框架。一些框架本身包括实现指南，并且可能有一些步骤来帮助定制或改编以适应客户的业务需求。
1、首先让安全架构成为一个动态的、活的过程
安全架构应该是一个活的过程，而不是一次性的。本节提供了如何将安全架构流程嵌入到组织实践中的指导。
1.a. 干系人管理
本指南强调了干系人对安全架构的成功实现至关重要。
理解与干系人的互动，需要正式的活动和更多的信息交流。跟踪干系人参与的内容和性质的一种方法，是创建和分发一个RACI（负责-问责-咨询-知情）矩阵。RACI矩阵应该映射到组织角色。
如果没有干系人管理，安全架构师就可能无法与关键人员沟通，无法让关键人员参与安全架构的维护和发展。他们冒着只与不断减少的原始参与者交流的风险，而不是仔细管理来自组织内部的领导和专家，而这些领导和专家的输入是至关重要的。干系人的支撑和支持，对于确保安全架构的成功维护非常重要。
1.b. 将安全架构嵌入到业务中
对安全架构活动的一种批评是，它们通常被视为昂贵的一次性活动，并且很快就不能反映运行时的实际情况。这对于采用敏捷开发程序、云服务和CI/CD类型活动的企业来说尤其是一个问题，这些活动在一个持续的、有计划的基础上发生变化。
支持在多变环境中维护当前安全架构远景的方法包括：
■ 将安全架构活动嵌入开发和运营活动，以支持持续管理和控制。
■ 与组织中现有的架构功能保持一致——例如，企业架构。
■ 定义和维护参考安全架构。它们可以是高级的架构解决方案，也可以是实际构建的、随时（重新）使用的架构解决方案，以适应特定的用例、模式或其他逻辑需求。
如果安全架构流程要真正在敏捷和DevOps中工作，架构师需要寻找可以转换为工作流步骤的技术层流程，或者在代码提交、构建和应用程序交付中无缝进行检查/审核。在敏捷交付中，除非是在设计/规划期间与开发团队一起完成，或者作为带外活动执行，否则人工评审的空间很小。
为了支持这些对灵活性和敏捷性的战略需求，可能需要工具来适应集成、自动化和其他技术能力。自动化部署可以使用云功能以编程方式执行，它们可以为基础设施和身份组件提供“基础设施即代码”选项。
因此，对于某些人来说，安全架构确实可以是一种“纸上谈兵”的演练，在这种演练中，需要花时间向领导层了解业务方向和战略，从而根据内部安全治理和外部标准形成逻辑安全。它也可以是完全设计的技术参考组件，准备到项目的交付点，以便为其自身的独特需求进行配置（参见图2）。
图2-使架构可持续
1）将安全架构活动嵌入到日常开发和运营中
部署IT的每个组织都有某种类型的开发和发布周期。必须积极识别和管理风险。必须定义基于风险的触发器，以促使安全架构团队采取行动，帮助改进和改变安全架构，以应对新的挑战。
通过调查组织的影响和变更可能产生持续影响的地方，为持续的安全架构过程做好准备。用于评估对安全架构产生影响的典型信息源包括：
■ 变更管理
■ 风险管理
■ 新项目倡议/规划
■ 审计报告
■ 公开报道
一些活动可能需要由组织的安全组初始化，包括：
■ 识别安全系统和过程中的差距和漏洞
■ 定期审查安全架构的战略层（应进行此项审查，以确定范围是否发生变化，以及现在是否有新的战略要求改变了安全架构的重点；这项活动基本上会重复第2.c.子阶段中提到的围绕高级领导层的活动。
安全架构提供了一组从业务层、逻辑层和技术层开始的分层概念。每一层的“速度”或变化率根据不同的刺激因素而不同，必须谨慎管理：
■ 业务安全需求必须与业务战略保持一致。逻辑需求解决了这些业务需求，但一般来说，这些层不是快速移动的。但是，随着时间的推移，它们会导致业务需求的重大变化（例如，引入灵活性/可伸缩性/敏捷性）。
■ 安全架构需要人工流程来跟踪和关注逻辑安全架构的变化，而这些流程最终需要输入到架构的技术层。
■ 在技术层，其他因素和条件影响了安全架构的实例化方式。例如，对敏捷性的需求，意味着可能需要在交付中嵌入更多的安全自动化。因此，安全架构过程必须适应技术变化，并以SDLC的“速度”这样做。
组织可以使用敏捷交付方法论递增地部署新技术。在敏捷增量过程中，技术安全架构可能需要更改以响应或适应新技术的挑战。因此，安全架构师必须在敏捷团队中有代表。但是，逻辑安全架构和业务安全战略架构的变化可能要小得多，当它们发生变化时，安全架构师必须采取行动，确保将其影响过滤到技术架构中。
2）与现有架构功能保持一致
与企业架构功能密切合作，可能是一种很好的方式，用于让安全架构参与到项目中来，无论是常规运营还是使用敏捷方法。安全架构实践通常与企业和解决方案架构保持良好的一致。例如，SABSA有一份白皮书解释了与TOGAF的集成。
建议企业架构在集体领导下作为IT安全的对等组织工作。它更进一步，提供了一个分散的EA团队，由来自应用程序、基础设施、IT安全的架构师组成。
业务结果驱动的EA能力侧重于创建可操作的建议，以交付创新的方法，提供明确的架构指导，并使用完全支持业务工作的工具和实践进行运营。安全架构师应该与EA合作，以确保安全架构基于风险的部署建议与EA输出保持一致。
3）安全参考架构
设计和构建安全参考架构，是帮助项目团队理解其部署中对安全性的基本期望的好方法。由于模式是为项目设计的，所以架构师应该确定它们是否适合重复使用，并根据需要为将来的活动存储工件。
安全架构师在谈论参考安全架构时的含义是不同的。对某些人来说，参考架构是一个带有方框的大型图表，方框中包含了需要部署的组件名称。对其他人来说，它是可重用的技术设计模式。参考架构也可以是完整构建的部署，准确配置为满足安全治理的期望，并准备好为另一个项目（或再一次的同一个项目）重新部署！
1.c. 决定风险触发器和阈值，以审查和修订已建立的架构
为了帮助嵌入并确保活动成为可重复的流程，组织需要定义将启动安全架构团队活动的触发器。为此，与干系人一起制定计划，以确定活动、风险、项目规划信息和其他有助于指导安全架构持续参与的输入。
如果没有足够的触发器来提示安全架构师采取行动，将现有的安全架构应用于新项目是不可能的。实践者经常说安全架构是一个过程，而不是一个东西，使用触发器来调用架构师的动作是确保过程运行的关键部分。
2、界定范围并理解环境
本阶段指南旨在确保对范围界定、风险和现有控制信息的收集。
2.a. 获取现有风险概要
从业者需要全面了解组织的风险状况。这意味着获得战略风险、风险管理目标和控制目标，并包括获得跟踪技术风险的企业风险管理工具。
如果开发安全架构时不了解风险，那么组织实际上是在开发一个与上下文无关的通用控制模板。这将缺乏重点，也无法解决组织面临的真正风险。
此外，安全架构必须与组织治理（即内部策略、标准、流程和过程）保持一致，因为它提供了安全架构的权威企业边界。编写内部政策和标准是为了解决已经确定的风险，但需要通过明确的行动和步骤来减轻这些风险。
SABSA和NIST CSF方法都使用了已识别的风险（和机会）。它们都利用风险管理过程，来通知和指导将安全功能嵌入到安全架构中的方式。因此，能够访问风险信息源，是顺利进行安全架构设计和持续实施的关键因素。
这些步骤不是风险评估，而是指导您在构建安全架构期间应该访问哪些风险信息。当然，如果在收集过程中发现风险评估尚未执行，建议您执行安全风险评估。
一旦您有权访问所有关键风险源，此活动即告完成。
2.b. 确定架构的范围
边界需要应用于安全架构范围，以便只审查/实现必要的区域。这个范围很可能是整个组织企业，也可能是一个确定的业务功能或进一步的细分，这取决于活动的目标。
使用范围界定来明确安全架构要覆盖的系统，并避免用户之间的混淆。
界定范围有助于创建一个坚实的基础来支持阶段3，它检查安全架构的战略级决策。
如果在实现安全架构过程时未能界定范围，则会导致安全架构定义不当。干系人系统可能缺失，可能在安全能力方面存在真正的差距，也可能被排除在外的同事剥夺原有权利。
范围界定是一个相当短的活动，在定义总体安全架构方法之前，它与业务主管和干系人一起执行。
几乎所有后续活动都依赖于范围界定。不完整的范围，与没有范围或只是假定的范围一样糟糕。因此，应尽一切努力确保覆盖度和完整性。范围可以由整个企业或特定安全策略域和底层标准的覆盖范围来定义。
2.c. 确定现有的安全标准和内部控制框架
许多组织以合规为导向，具有安全能力，能够履行审计师、监管者和立法者规定的义务。受监管行业尤其如此。一种常见的方法是依赖控制框架作为选择控制的源或起点。公开控制框架通常形成一长串可能的控制，组织应该考虑在退出的基础上实施这些控制。ISO 27002和NIST SP 800-53是控制框架的例子，它们被特别期望用作“购物清单”。用户需要执行资产风险评估，以确定所需的控制及其实施水平和范围。
如果忽视或忽略此步骤，则所需的控制框架需求与安全架构设计之间就可能存在不一致。治理、保证和设计之间缺乏一致性，将导致控制不足或缺失，从而可能导致审计失败。这可能导致额外的返工和控制补救，甚至名誉受损和监管罚款。
2.d. 确定现有的安全系统和能力
一些现有的安全系统和功能可能存在于大多数组织中。需要对现有的安全系统、能力和过程进行调查。
一些架构师将选择对现有的安全部署执行成熟度评估，以更好地了解嵌入式程度以及安全能力相对于各自任务的执行情况。收集尽可能多的关于安全能力的信息，不仅仅是工具化的一般描述。
安全架构师必须在整个组织中轮询多个团队以收集安全能力信息。不要低估这项任务在现实世界中的重要性和难度。
您必须与应用程序所有者、企业安全控制区域、安全团队、安全运营团队、DevSecOps和开发团队进行沟通。
当架构师确认所有组都提供了信息或断言他们没有安全能力时，此任务就完成了。对组织安全能力有一个良好的、最新的了解，是安全架构的一个重要资源。在组织中创建和维护良好的IT可见性，是成功的关键。
3、决定安全架构的策略
此阶段包含重要的上下文活动，包括确定要采取的安全架构策略和获取关键上下文信息的方法，以及安排沟通和会议。
3.a. 决定安全架构策略
本指南的第一阶段对于将要使用的方法论或安全架构框架是不可知的。此阶段支持选择和创建组织将使用的安全架构方法。
在本指南中，如前一阶段所总结的，我们提供了方法论方法（如SABSA）和框架方法（如NIST CSF）之间的比较，以帮助支持决策。尽管还有其他方法，但它们属于这些广泛的方法类别。
安全架构方法论为逻辑架构和底层技术安全架构创建上下文和概念基础。这使得业务期望与安全性更紧密地结合起来。框架使用一组假定的相似性和跨用户的共同期望来确定安全架构。CSF等框架方法为方法论提供了支撑。
安全架构方法为逻辑安全架构创建上下文和概念基础。框架使用一组假定的相似性和跨用户的共同期望来确定安全架构。
方法论方法有助于定义一个清晰的业务上下文，在此基础上可以创建概念架构。然后使用它来了解和构造逻辑安全架构。在这种情况下，该方法论成功地定义了满足业务需求的架构。
另一方面，框架是根据安全专业人员和贡献组织的经验构建的，以提供一套“最佳实践”指南和控制措施。幸运的是，安全架构框架设计者认识到了业务需求，并在其方法中嵌入了一些定制化，以帮助满足各个业务需求。
然而，在实践中，方法论可以在其方法中使用安全架构框架、最佳实践指南和安全标准，以适应业务的需要。这为架构师提供了一些选择。然而，他们需要充分研究并熟悉安全架构方法和框架，以便为组织做出正确的决策。
图3显示了选择一种方法背后的挑战和原理。说明了在使用框架或方法论以及使用组合方法的选项之间的选择。
图3-方法论和框架
必须在开始之前决定如何实现您的安全架构方法。如果未选择该方法，则在安全架构的实际工作开始之前，许多子阶段活动将保持不完整或无法开始。
这显然是一个定性的决定。然而，有关安全架构框架方法是否合适的证据，可以通过查看合规性和法律义务等来源来收集。
如果您不确定，或者对资源和能力有顾虑，并且没有其他特定需求，那么迈向安全架构的第一步应该是使用NIST CSF，对其进行调整，使其符合您本地的标准和实践。随着安全架构程序的成熟，您可能希望更好地与业务需求保持一致，并且可以使用方法论方法，在“按需”的基础上将它们与框架一起引入。
3.b. 确定获得相关组织见解的方法
安全架构计划的某些上下文，只能从高级管理人员和执行人员处获得。任何框架都有一个额外的步骤：为运行框架准备所需的输入。在大型分布式组织中，这一步骤可能非常繁重，因为许多竖井和单元将拥有必要的信息。但是，获取业务驱动的一个关键信息源，是通过您的安全治理功能。
必须收集有关安全性的业务见解。为了促进这一点，计划与高层领导的互动。在确定需要从哪些高级领导人员那里获得见解时，请记住他们必须对范围内的业务和技术领域负责。为了获得最大的利益和洞察，领导人员必须扩展到业务职能的范围。
如何利用SABSA获取战略信息
为了帮助决定不仅是采取哪些方法，而且需要收集哪些信息，我们看看SABSA如何获取业务数据并形成战略架构元素。
像SABSA这样的方法论，分解了业务上下文并帮助利用了一组业务属性示例——每个属性都有一个明确的含义。这就创建了概念架构。架构师必须获得并生成业务安全需求。它能够根据业务安全需求直接解释逻辑安全需求。
安全架构框架在其特定领域有需要满足的目标（例如，金融服务控制期望、风险管理目标和政府要求）。因此，它们可能会提供一个更具规范性的途径。然而，SABSA一开始就选择性忽视这些目标。
一个类比是建模工具包。框架是一个Airfix飞机建模工具包，包含构建飞机的说明。你可以忽略小模块，选择不同的颜色等等，但最终，你得到的是一个飞机。方法论是一盒乐高积木和一本“乐高创意计划书”——也就是说，它提供了一些你能做什么的好主意和如何做的指南，但是你究竟把什么搭建在一起，却完全是你自己创造的。
领导层的洞察力有助于创建一组优秀的驱动因素，从业务角度来看，这些驱动因素需要安全措施的支持。这些信息将从与领导层互动和战略文件审查（如商业计划和投资者数据信息）中获得。这为安全的必要性提供了重要的上下文。一旦这些驱动因素被确认，它们就被用作下面的安全架构的基础。一些例子（来自面谈或战略文件）：
业务目标示例：
■ 确保业务灵活性和敏捷性，以实现增长
■ 建立高效的数据处理
■ 确保业务服务对所有用户/客户在任何时候都能获得
■ 符合所有道德和相关法律框架
与业务目标相关的业务安全目标示例：
■ 跨扩展企业，保护业务数据
■ 在所有员工需要时可以提供
■ 确保业务流程的可靠性
■ 遵守道德、法律和监管义务
SABSA帮助定义业务属性，以形成“业务属性概要”。这直接映射回安全目标。安全属性是一组战略项，它们本身暗示着安全需求。SABSA方法论提供了一组可利用的示例安全属性，但也可以使用自定义创建的属性。
图4显示了一个示例，其中业务安全目标映射到一组安全属性以形成业务属性概要。
图4-识别安全属性以满足业务目标
注意，对于那些寻求SABSA和NIST CSF之间正式整合的人，SABSA研究所已经发起了SENC项目“SABSA增强的NIST网络安全框架”。该项目的基本原理是，为NIST CSF提供了基于SABSA的业务属性分析的“前端”方法。
3.c. 计划沟通和会议
在适当的治理和监督下，将安全架构作为组织内的一组持续过程来实施，以在技术层提供一种全面和不断发展的安全风险管理方法。
这一阶段在实践中是一个项目管理活动，以确保与所有应该参与的人取得联系。它应该计划在安全架构创建和维护活动期间执行。
必须制定该计划，以保持与主要干系人的沟通和接触。在本指南的第一阶段，有一个称为“干系人管理”的子阶段，作为“使安全架构成为动态的、活的过程”阶段的一部分。这两个阶段有着显著的联系——那个子阶段是关于识别和管理哪些干系人需要参与，而这个阶段是关于安全架构活动和与它们的交互。
如果没有有效的计划，就存在影响安全架构活动总体成功的重大风险。如果没有计划让干系人，特别是高级职员参与进来，他们不大太可能在你需要的时候立即给予帮助。沟通也有助于促进安全架构的理念被干系人群体所接受。这避免了安全架构在完成之前就已经成为冷板凳的风险。这项活动的时间安排很重要。这些计划应该在开发安全架构之前制定。同时，这也是一个行动计划，将在整个过程中进行修改和变更。
4、支持逻辑安全架构的开发
此阶段包含了支持生成逻辑安全架构的活动的指南，包括方法的识别、支持控制分配活动、与标准保持一致。
4.a. 确定开发逻辑安全架构的方法
框架和方法论以不同的方式处理逻辑安全性，因此，在开发这个架构层之前，您需要考虑这些偏差。
本指南的这一步，为您所选择的方法创建必要的逻辑安全架构构件做好了准备。不仔细规划和准备这一阶段的风险，将使我们无法定义有效的安全架构。确保您能够获得必要的文档，并与整个组织中能够提供指导的干系人保持联系。
方法1：使用NIST CSF定义逻辑安全架构
对于NIST CSF，创建逻辑安全的过程，是使用框架概要执行的。框架概要（Framework Profile）是根据组织的业务需求构建的。框架概要比逻辑层扩展得更远，并且还解决了更多的技术问题。
本指南的前几个阶段，帮助您获取有关组织的安全态势、当前风险状况、战略业务的关键信息。这些信息源被组合起来，用于在架构师构建当前概要（Current Profile）时告知架构师。
可以使用相同的框架概要来开发目标概要（Target Profile）——这将考虑到组织风险和管理目标，以及应该如何处理它们。
请记住，在构建当前概要和目标概要时，它们是用实现层度量来定义的，这些度量既受业务需求的指导，又受风险管理指导的通知。为此，来自框架核心的控制和实现层的选择，应该完全可以被追溯到：
■ 特定的已识别的业务需求：可以执行一个过程，如SABSA对业务上下文的识别和前一阶段描述的业务属性概要的创建，以使业务需求与控制能力系统性保持一致。请记住，框架是可扩展的，可以根据需要进行修改。
■ 目标概要层的选择，需要直接解决已识别的风险。不要仅仅把这个过程作为一个雄心勃勃的步骤来使用；看看风险评估信息，并决定需要改进哪些控制措施，来缓解已发现的问题。
使用目标概要并将其与当前概要进行比较，可以提供详细信息，帮助定义逻辑安全架构所需的内容、其结构及其组件（甚至更多的技术安全架构需求）。图5描述了这种比较以及风险评估是如何居于核心地位的。它展示了如何使用核心CSF框架来度量控制的实现层，包括子类别。创建当前状态概要。评估风险敞口，并确定未来状态概要需要什么。方框颜色表示实现层的级别。
图5-当前和目标框架概要设计的比较
一旦组织的框架概要准备好，就可以检查现有的部署，并将它们与该概要进行比较。
使用名为“框架实现层”的度量，您可以为已审查的控制的操作，指定一个严格性级别。层的级别从1（局部）上升到2（知悉风险）、3（可重复）和4（自适应）。层并不意味着成熟度评估度量。然而，NIST CSF框架指南建议，评估为1级的任何控制措施，至少应寻求转移到2级。
方法2：使用SABSA方法论创建逻辑安全架构
通过框架方法，定义了逻辑安全架构的基础。图5显示了NIST CSF的核心功能。然而，在SABSA中，定义逻辑架构实际上是一项系统工程任务，用于定义整个系统的关键方面、其组件子系统以及这些子系统如何交互和控制。控制本身来源于业务目标和由业务属性概要定义的概念架构。
准备使用SABSA定义逻辑安全架构，需要了解架构范围内的组织。SABSA确定了在这一级别需要明确的要素，包括了解哪些信息资产需要保护、政策架构（用于风险管理）、关键业务流程、信任框架和域映射。逻辑安全架构本质上表示安全服务，用于在定义的风险策略中保护域内和域间的信息资产和流。
在SABSA中，安全域是帮助定义逻辑架构的基本构建块。安全域是“被单个安全策略颁发机构定义和拥有的通用安全策略所约束的一组元素”。
一旦定义了所辖范围的策略域，进而定义了支持这些策略域的安全标准，下一个关键领域就是理解业务流程和功能需求，以便可以映射域相互关系和信任。通过这样做，逻辑安全架构所需的安全服务可以明确定义。
在决定必须应用控制的位置时，一个重要步骤是检查逻辑安全架构范围内的参与者组之间的相互关系。参与者按照组织策略控制进行分组，称为“域”。可以根据信任关系来考虑控制。内部安全标准将至少定义为最低基线。
SABSA认为，“重要的信任概念涉及在域内管理信任的各种策略权威、设置用于管理每个域中实体行为的策略，以及域间信任关系。”
在逻辑安全架构中，策略架构和域被映射。通过构造基于策略域的架构，域之间必要的信任可以通过关联进行分配。策略域信任是为支持业务活动而建立的，并且存在于业务事务中的所有各方之间。这些信任与业务安全属性相关联，这些属性提供了在业务中的域之间成功定义逻辑安全控件的方法。
4.b. 促进控制分配
如何执行控制分配，取决于构造的方法（即方法论、框架或两者的组合）。控制分配（Control assignment）是为满足组织的业务需求而选择的逻辑安全服务。
此步骤的目的是以非技术性的方式（即不明确指出如何满足控制），清楚地传递安全服务。执行此步骤，有助于为技术安全架构提供明确的需求。如果没有这一步，就无法使业务需求与技术安全保持一致。
根据您的方法，它们将被向前映射，以创建构件，捕获必要的安全服务以满足期望。这一阶段的成果必须与干系人分享和审查，因此要相应地进行计划。
在此阶段可能出现的风险包括，干系人的输入没有得到充分考虑。这导致在分配逻辑安全控制时，未考虑干系人的责任领域。
4.c. 将安全框架、指南、最佳实践纳入逻辑安全架构
如前一个子阶段所述，使用安全框架是创建逻辑安全架构的一个组成部分。框架方法和方法论方法是有区别的。
例如，NIST CSF构建了外部安全框架、指南和最佳实践的使用，称之为“信息参考”。NIST CSF的附录A提供了参考资料，其中涉及通用框架，如COBIT 5、ISO/IEC 27001:2013、NIST SP 800-53版本4和其他（详见NIST CSF附录A）。但是，请注意，NIST CSF的信息参考组件可以根据任何本地需求进行扩充，无论它们是额外的外部框架、指南和最佳实践，还是内部安全政策和标准。
该活动为架构师准备好合并可能影响逻辑安全架构的安全标准、指南和其他最佳实践。忽视这些输入，将带来与合规义务不符的风险。
SABSA方法要求，架构必须满足业务需求，而且标准的纳入是实例化业务需求的一种形式。SABSA与NIST CSF一样，并没有取代标准，相反，它需要能够与标准保持一致。这有助于部署满足所有业务领域（包括合规性和治理）的所有需求的控制。
5、促进技术安全架构的设计
这个阶段的关键活动包括支持技术设计需求，确保防御是分层的，确保可追溯性，以及帮助供应商选择过程。
5.a. 支持技术安全架构设计
准备技术安全架构的设计。这将要求架构师深入理解将在其中实例化控制的技术环境。它还将要求架构师与技术领导层和干系人进行更多的交互。
逻辑安全架构的服务需求和期望是通用的，与技术无关。它需要那些负责所有相关IT环境的安全从业人员和技术干系人的洞察和经验。这种方法将有助于产品和能力的选择。当控制可能受到兼容性或集成方法的影响时，甚至存在性能问题的情况下，这一点尤其重要。
SABSA和NIST CSF创建安全架构的方法，都要求安全过程、工具、供应商能力与逻辑安全架构要求一致。
您必须收集有关技术企业的相关信息，以帮助了解在何处以及如何应用技术安全。从收集的详细技术信息，转移到技术安全架构，需要映射到逻辑安全架构需求。这可以使用SABSA或NIST CSF方法进行。
图6所示的示例，使用了由CSF类别和子类别定义的NIST CSF安全服务映射，显示了从更广泛的映射活动中提取的内容。
在定义了逻辑安全架构之后，SABSA致力于定义两个架构层，作为我们在本研究中广泛描述的技术安全架构的一部分：
■ 第一个是物理架构：该层定义了过程机制、需要保护的资产，包括基础设施系统。
■ 第二个是组件架构：进一步详细说明技术服务，如供应商工具、特定流程、用户身份和低级别的能力应对。
在定义这些时，可以将安全能力进行分组以实现。这就制定了SABSA的行动计划，并根据能力解决的风险，确定了路线图的优先级。
将控制需求与能力进行映射，允许测试能力的总体覆盖范围——确保所有控制需求都具有某种解决它们的能力。这种映射方法还允许进行选项分析——可以测试控制方法的候选分组（例如，不同的模式或不同的补偿控制集），以确定覆盖需求的程度，从而做出决策。
图6-从NIST CSF安全服务映射到技术安全架构组件
5.b. 确保分层防御（纵深防御）
纵深防御是任何安全架构都要展示的重要特性。因此，架构师应该准备好测试技术安全架构控制（包括组装的供应商工具）是否确实提供了主要的和补偿的分层防御，来保护范围内的企业。
NIST CSF在组中使用核心功能和类别来组装控制，这些组（假设控制部署在这些组中并用于相同的受保护资产）将提供该层的控制集并相互补偿。这是使用CSF结构的一个显著好处，并且帮助了架构师有意地对控制集进行分层。
由于SABSA在组装逻辑和技术安全架构方面更加开放，因此它使用了不同的方法来确保分层防御。SABSA提供了“多层控制策略”，其中包含与NIST CSF中固有的核心功能结构相似的元素。因此，它有助于确保，已确定的控制措施确实能够起到分层和补偿其他控制措施的作用。
SABSA多层控制策略如图7所示，并显示了如何使用不同的策略（威慑、预防、检测等）来应对风险。在应对特定风险的策略中，控制措施的组合提供了分层和补偿能力集。
图7-SABSA多层控制策略
5.c. 将可追溯性管理纳入策略
可追溯性是框架和方法论方法的固有能力。这是任何好的安全架构思想的一个特点。确保可追溯性，使架构师能够：
■ 为审计师和风险经理提供证明符合架构和风险管理期望的方法。
■ 为高层领导提供有关安全支出如何专注于业务需求的见解。这有助于证明安全能力部署的合理性。
■ 评估安全架构提供的“完整性”程度。
■ 将控制与解决特定风险的需求关联起来，并分配风险所有权。负责任的业务领导人，将有能力查看风险是如何解决的。
可追溯性是框架和方法论方法中的一种固有能力，从逻辑需求一直追溯到技术和过程控制，并且可以反过来，因为它是一种双向特性。
在战略层面，NIST CSF没有明确指导架构师，如何考虑战略业务需求之间的关系，以及这些需求如何影响框架。因此，为了确保从业务上下文到技术控制的可追溯性，框架的用户将需要使用一种方法，例如SABSA的业务属性概要。如第2阶段所述，SABSA研究所启动了SENC项目“SABSA增强的NIST网络安全框架”，该项目的基本原理是为NIST CSF提供了基于SABSA的业务属性概要的方法。
可追溯性是为不同的干系人定义具有多个视图的架构的重要部分。没有它，技术架构可能与业务目标和战略需求不一致。随着时间的推移，这种不匹配将带来无法预见的风险，这是由于无法将逻辑需求与技术部署协调起来所造成的。
5.d. 支持组件和供应商选择的决策
组件和供应商选择的准备工作，包括积极熟悉可能需要的安全工具。架构师应该调查新技术和方法，以确定它们的有效性。
通过使用逻辑安全架构中的需求，可以定义一组与技术无关的期望。这可用于评估满足需求的不同技术和过程选项。有几种不同类型的评估，可用于支持组件和供应商评估。组件、过程和供应商产品的组合可以相互评估，以确定是否适合满足要求。或者，可以比较各种方法，甚至是解决安全需求的供应商工具。
供应商选择的最后也是最重要的支持来源，将是参与供应商选择的其他干系人。与技术干系人建立良好的工作关系，包括设计权威和领域专家。这将有助于支持在选择和构造解决安全需求的选项时所做的努力。他们的见解将有助于解决重要的方面，例如性能影响和规模影响，以及工作负载影响如安全软件部署、处理速度和潜在延迟、与基础架构和应用程序组件的兼容性、集成路径等。
声明：本文来自网络安全观，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
