威胁驱动的网络安全方法论

本文主要内容取自洛克希德·马丁公司的论文：A Threat-Driven Approach to Cyber Security，想要全面准确了解论文内容的朋友建议阅读原文。希望能够抛砖引玉，为相关领域的相关工作人员带来一点不同的思路或启发，从而更好地维护企业/组织的网络安全。欢迎交流与指正，转载请注明来自博客园 r00tgrok。

摘要

目前的网络安全风险管理实践很大程度上是由合规性要求驱动的，这使得公司/组织不得不在安全控制和漏洞上投入人力/物力。（风险管理涉及多个方面，包括资产、威胁、漏洞和控制，并根据事故发生的可能性及造成的影响进行评估。威胁会通过漏洞对信息系统造成损失，安全控制则是试图阻止或缓解威胁源实施攻击的措施。）然而，由于致力于安全控制和漏洞，他们忽略了风险管理中最重要的因素——威胁。这种失衡的状况表现为坚守既有的安全架构及工程实践中的标准和原则，更加注重应急响应而不是风险管理。

一个功能完备的架构应该将威胁放在战略、战术及运营实践的首要位置，工程师和分析员们遵循常规的方法论，将威胁分析和跨越多个职能系统的威胁情报整合到一起，而不是让它们彼此隔离。这保证了安全控制得到实施和评估，并随着不断出现的有影响力的威胁和攻击向量而不断调整。这样能使我们得到更加精确的信息，以一种更优的方式分配资源及控制其使用，从而生成一个敏捷、有弹性的网络安全实践。这种威胁驱动的方法和合规性并不冲突，对一个机构来说正如量身定制一般，践行这一方法可以是风险管理得到加强，机构最终得到一个既合规又更加安全的信息系统。

引言

目前，网络安全领域的架构、工程及运维实践主要聚焦于合规性——遵循一到多条规定、政策。一些机构整合了传统的信息安全理念及原则，并试图将安全植入 IT 系统的开发过程来补充这些实践。成熟的运营者遵循网络杀伤链（Cyber Kill Chain）或类似实践及情报驱动防御（Intelligence Driven Defense）方法来同网络威胁抗争。

目前的实践存在以下不足，因而限制了其有效性：

1.  过多的资源被用于合规性要求，行为和文化都以和合规性为导向；

2. 缺乏可伸缩（横向和纵向）的格式化威胁建模及分析实践；

3. 制度上缺乏架构/工程职能及运营/分析职能之间的整合；

除此之外，合规性驱动的战略大多数情况下会导致控制第一的观念，即系统架构及基础程序由已知安全控制及控制框架驱动。这种践行方法的结果如下：

• 合规性（即来自权威机构的控制列表）并不能保证系统是安全的，反而容易助长一种看似安全的假象；

• 资源被浪费在不能处理实际威胁的控制上

• 经常以二元论评估控制的有效性

• 未做能够发现问题的分析

• 残留的风险增加了

此外，漏洞驱动的方法常会过多强调在处理漏洞上的努力，这种方法存在以下缺陷：

• 暗示了一个高反应操作环境

• 漏洞和事故在一个微观的层面得到处理，而不是将之置于一个更大的威胁场景中

• 仅已知漏洞能被修复，未知漏洞及全局的设计缺陷会被忽略

• 没有上下文环境，漏洞指标被曲解，引发不必要的行为及资源分配

• 聚焦失衡导致架构和运营域在检测、响应及恢复上的不足

威胁（可以是人，也可以是事件）能对系统及资产造成伤害，因此应作为设计良好的应用、系统、任务、环境及合理防御时的首要驱动力，本文称之为威胁驱动的方法。

威胁驱动的方法

威胁驱动的方法是一个方法论，一个实践与思维模式的集合。它的主要目的是使组织能分配相称的资源保护自己的资产，开发支持这些工作需要的必备技能，通过践行这一方法整合不同职能的团队。图 1 中架构和运营职能彼此是隔离的，阻碍了有效的情报共享，未能提供足够的标记来驱动路线图和战略方案，想培养一种渴望迎头而上解决网络威胁的文化却不具备这样的条件。  

图 1      被切割的职能域

图 1 展示的是存在于职能和机构中典型的硬边界，这中边界必须打破，代之以一种整合的方法链接各自领域最相关的威胁元素到互补域。图 2 描述了这种最佳状态，理论上该交叉链接要通过企业内部的组织结构和功能调整来完成，并得到各级管理人员的支持。

图 2      整合的威胁驱动方法

图 2 展示了必要的交叉元素及他们的职能域来源。操作域反馈相关的威胁情报给架构及工程实践，架构和工程域消费情报并添加威胁模型和分析以促进基础设施、运营能力及整体安全状况的提升。运用这一概念桥接了被分割的职能域并激发了健壮、灵活、主动的网络安全能力，好比是网络安全里的"DevOps"方法。

1. 威胁驱动方法的要素

我们已经知道，以合规性为导向的实践在抵御当前或未来网络威胁的冲击时其效果是微乎其微的，因此我们需要调整自己的观念来推动网络/信息安全行业的改变。本文描述的实践将提供威胁分析指导，以支持系统开发、威胁/风险评估项目、事件分析及评估系统控制的有效性。我们最终的目标是构建一个安全且合规的系统，在这个系统中所有层面的风险都将得到有效的管理。 

2. 威胁-资产-控制相关模型

威胁驱动的方法其概念基础是一个威胁、资产、控制之间的关系模型。这个关系模型如图 3 所示：威胁的目标是组织内的资产，它们普遍存在于一个或多个组件中。威胁源通过攻击向量和组件（持有资产或能提供对目标资产的直接访问）中的漏洞获得对资产的访问。安全控制作用于组件，旨在阻止或缓解威胁源使用的漏洞及攻击向量，进而达到保护资产的目的。同时，这一关系也突出了该模型中威胁视角的意义（"未知攻，焉知防"）。

图 3      威胁、资产及控制的关系模型

在这个关系中，威胁源并不/很少直接访问目标资产，获取目标资产既要和系统中的其他元素交互也要在适当的时候避开它们。控制并非直接作用于资产，相反，控制措施必须提供安全功直作用于识别的威胁、攻击向量及漏洞——能提供对含有资产的组件访问能力。

一个基本的原则是：选择和实施的控制需要具备一个或多个功能以处理威胁和攻击向量。当这个模型包含威胁情报时，架构师、工程师及分析员可以协同工作，发现潜在的不足并评估控制的有效性，进而持续提升系统和基础设施的安全状况。当威胁建模及分析被引入到这个模型中是，可能曝光的领域及其影响都得到了强调，这会优化控制的选择与实施。

3. 常规威胁分析方法论

威胁分析有两个主要目标：

1.  清楚、彻底的了解拥有的资产及其面临的威胁与攻击，基于风险等级与风险管理实践制定相关决策。

2. 确定在应用、系统、基础设施和企业层面，选择、实施和评估安全控制时的不足。

现已有大量的威胁分析实践及工具，大多都有较强的针对性，有些适合开发、有些适合评估工作。本文的方法论是根据近二十年收集和完善的经验开发出来的，这些经验包括难以计数的信息安全体系架构/工程项目、软件开发中项目中的威胁与风险评估、复杂的 IT 系统、大范围的数据中心及非 IT 网络系统。

4. There Are No Idle Threats – They Attack

我们可以使用助记符来记住本文提出的方法论：“There are no idle (IDDIL) threats – they attack (ATC)”。这个方法论有两个工作阶段：IDDIL 是发现阶段，ATC 是实施阶段，相应行为如下：

图 4　　IDDIL/ATC

　　背景知识：

• 业务/任务上下文：确保理解了业务/任务上下文环境，及执行这项工作时对其产生的影响。

• 思维观念：团队在进行威胁分析时必须具备足够的能力，可以像攻击者一样思考。这一特点至关重要，对应 threat-driven 方法中的 mindset 元素。

• 迭代：推荐使用迭代方法但并不一定要顺序进行，多个任务可以是并行执行，所有任务的完成比它们执行的顺序更重要。从企业/组织的角度看一个不相关项目时，迭代意味着一个更长的生命周期及更深层的分析与整合。

• 头脑风暴：方法论只有在集体演练的情况下才能变得有效及彻底，来自业务、任务及技术上的利益相关人适当地表达（自己的观点）。假设是有必要的，而且应该随后记录在案。捕捉关于攻击和脆弱性的所有建议，之后列出它们的优先级。

• 有限制的时间：为最大化时间利用效率及确保项目管理的有效性，设置个人会话及整体评估的时限，实际时间长度因项目范围及重要性各有不同。

4.1 发现阶段（IDDIL）

• 识别资产：资产主要有两种，1）对系统业务十分重要的数据、组件及功能，即业务资产；2）引发攻击者特殊兴趣的数据、组件及功能，即安全资产。这两种资产并不总是相同，可以通过相关角色那里索要业务上下文输入识别系统的资产，资产识别还包括获取对手目标的威胁情报，记录系统和环境中的资产类型并指明其所在位置。

• 定义攻击面：完成资产识别后， 从宏观层面标出应用/系统中的组件及元素，它们包含于系统中或彼此通信，甚至提供某些方式对资产进行访问。攻击面能帮助定义系统/信任边界及控制/责任范围，并搞清楚某一项工作是否超出了范围。这个阶段生成的数据流图表（或任何相当于图表的类型）能极好地呈现分析中的系统和环境。

• 分解系统：使用前两步收集到的信息将应用/系统分解为层次化的视图。需要涵盖设备、接口、库、协议、函数(functions)、API 等技术，随后审查工作范围内现有安全控制的有效性。

• 识别攻击向量：借助记录的攻击面、分解后的系统及主要的使用案例来记录攻击途径。捕捉包含在这些路径中的组件及功能范围，已有的安全控制及服务也不例外。除了物理路径和逻辑路径，还需要考虑到使用同一路径的不同攻击方法。确保当前阶段的的信息和情报考虑到了 exploits、漏洞及威胁源，攻击树是完成这一工作的理想工具。完成前述工作后，现在可以使用分类学将系统及组织中的威胁与攻击进行分类了。

• 列出威胁源和攻击代理：确定谁想攻击系统，及为什么他们想攻击它？要了解的特征包括攻击动机、技能水平、分析需要的资源与目标，随后分别将他们列出来。思考攻击源的类型有什么不同，因为现在的威胁情报对于这一步来说十分重要。

4.2 实施阶段

发现阶段识别了资产、威胁及攻击，实施阶段则使用发现阶段捕捉到的数据对其进行透彻、详尽的分析。分析的结果是产生一个待处理事物的优先级列表，并有一个全面的关于业务环境和影响总数的描述。所有的发现、分析及排序都会对我们采取合适的安全控制形成反馈，以阻止或缓解识别的威胁和攻击，或发现控制有效性的不足。

• 分析与评估：明确最有可能出现的攻击及攻击成功后产生的影响，回顾并更新发现阶段获得的猜想。说明业务上下文中的影响及相关条件，这样关于风险的讨论才能顺利进行。在讨论时要确保考虑到了最坏的情况会造成的影响，分析花费的时间和精力是系统资产与业务影响的临界参数（ is on par with the critically of the assets and business impact of the system under analysis ）。

• 分类：分类操作紧接着分析与评估，单独提出来是为了强调优先排序的重要性。根据对业务资产及功能造成的影响，这一步会排出一个最重要的攻击向量、威胁源及攻击成功引发的后果的清单。在这里造成的影响其权重要高于事故发生的可能性，可能性是整个风险管理中的一个重要因素，风险管理一节会对此进行讨论。需要注意的是，在这里可能性被视作一个不变量，主动威胁情报被当做可能性变量的主要反馈源。

• 控制：IDDIL/ATC 最终的结果是选择并实施安全控制，移除、阻止或缓解（开发与工程工作中）发现的威胁与攻击向量，或提升已有控制的有效性。合规性要求是强制性的，从事先的列表中选择，没有本方法中讨论的前述步骤，无法保证处理威胁时控制机制的有效性。相反，遵循本方法能确保适当的控制措施得到使用，或许更重要的是能根据威胁情报分析输入与威胁分析输出处理实际面临的威胁。此外，控制会展示出某些功能及其特性，有助于工程师和分析员确定给定控制的有效性。本文中所说的控制功能指的是：列出清单、收集、检测、保护、管理及响应。最后，践行本方法更可能发现控制覆盖面的不足之处，标识这些不足可以加强对潜在风险的识别，将之转化为更好的风险管理实践。

5. Integrating IDDIL/ATC

本节描述了从 IDDIL/ATC 方法论合到标准工程及运营程序的整合，包括与架构师、工程师、分析师职能相关的任务调整。提供了详细的实践及过程，如图 2 中交叉整合的元素所示。鉴于已有大量对特定领域的研究，本文不再多此一举，转而呈现这些实践方法整合的叠加并对这些整合点进行详细描述。

6. 开发及工程的整合

图 5 展示了一个普通工程的生命周期，该生命周期无关任何单个的工程方法论（例如瀑布、螺旋、敏捷模型），但包含了组成任何工程学科的典型阶段。IDDIL/ATC 叠加在生命周期上以描绘工程阶段的整合。威胁建模 &分析始于概念阶段并贯穿于所有直到运营阶段。威胁情报在运营期间获得，并在可能的情况下反馈给工程阶段。包含威胁情报体现了 threat-driven 方法是如何强化系统工程及架构实践的。由于组织及其所面临的威胁在不断演变，威胁建模 &分析实践及威胁情报实践也在不断进化。

图 5 威胁驱动方法的整合及生命周期各阶段的实践

IDDIL 方法对应工程的概念、需求及设计阶段。为生成高质量的分析输出物有必要进行相应工程阶段的全面 IDDIL 整合。除非进行大量修改，否则操作无法在将来的某个阶段向后填充。ATC 则对应设计、构建、测试阶段，安全架构已固化和细化，集成的安全控制和服务被指定、构建和测试。分类会形成严格的等级体系，优先设计、控制决策及安排讨论时要有风险接受能力及设计上的权衡。如图 5 所示，威胁情报被整合到了这一阶段中。

图 5 中有几点需要强调：

• 控制活动（模型中的 C）被整合到设计、构建及测试阶段，但没有参与到需求中去，控制本身会被设计与构建，但它们并不是需求。

• 威胁模型指导安全测试和渗透测试，一个好的威胁模型是渗透测试的蓝图。此外相关的技术、策略及过程（TTPs，techniques, tactics and procedures），还有威胁情报中可用的目标数据都必须添加到测试中。

• 将当前的威胁情报数据融入到概念、需求和设计中是威胁驱动方法中至关重要的一环。

7. 负担能力及成本影响

众所周知时间线上越靠右，发现和修复一个问题的成本便越高，对于网络/信息安全问题来说尤其如此。这突出了在生命周期中尽可能早囊括威胁建模、分析及情报数据的另一个主要好处：主要的设计缺陷及全局问题能尽早被发现和修正，减少了构建和维护系统的长期成本。没有哪一款漏洞扫描器或合规性检查列表可以发现全局设计缺陷。不幸的是，大多数安全相关的活动都只是从工程生命周期的靠后的阶段才开始，这会使面临的危险场景加倍——更高的开发和运营费用，更加不安全的环境。