本文主要内容取自洛克希德·马丁公司的论文：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. 常规威胁分析方法论

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

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. 负担能力及成本影响

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

8. 项目整合

除了整合工程过程，IDDIL/ATC方法的各个阶段也可以推动项目任务、里程碑及可交付物的进程。图6和图7描绘了基于IDDIL/ATC的示例项目模板，图6是基本模板，图7则是一种可能的实现。

 

图6      IDDIL/ATC方法项目计划模板

图7是一个项目可能的第二阶段，包含了IDDIL/ATC模型中的DILAT（分解、识别攻击向量、列出威胁者、分析评估及分类）。这里第一阶段已经识别了资产、定义了攻击面，最终阶段将包含设计并分配任务。IDDIL/ATC的灵活性使得各个阶段及活动几乎能用于任意工程及评估项目，例如阶段一可以包含IDDIL/ATC而阶段二可以实行IDDIL/ATC。项目活动也可以根据发现（IDDIL）和实现（ATC）阶段进行划分，根据实际项目需要进行调整。

 

图7      可能的第二阶段项目集成

9. 威胁分析实践及工具

IDDIL/ATC是一个包罗万象的威胁分析方法论，它覆盖了无论哪种实践、技术及工具都必须使用的常规行为。这些实践、技术及工具包括：威胁模型、攻击树、威胁画像（profile）及网络杀伤链（CKC），下文给出的案例及描述可以加深对这一概念的理解。

9.1 威胁分类

威胁建模/分析的一个常见实践是将威胁分类，微软开发出了STRIDE模型，许多组织则遵循经典的机密性、完整性、可靠性的CIA三角形信息安全模型。除了这两个最著名的模型，大量出版物及分类学也都试图将威胁和攻击特征进行归因。STRIDE模型考虑到了每种威胁类型（可能产生）的影响，并假设每一种威胁都会在分析过程中被发现。与之相反的是MITRE的CAPEC，它给出了许多常见攻击的原因，但不怎么关心攻击产生的影响。进行威胁建模和分析需要唯一的系统上下文环境，当发现威胁及攻击向量时我们有责任说明其因果关系。

论文原作者及其团队在很多项目中成功使用过STRIDE模型，并增加了一个威胁类型进行扩展：横向移动（Lateral Movment）。STRIDE主要关注软件工程及开发，因此横向移动的概念并没有包含其中——LM主要是系统-系统的威胁类型。这种新的威胁分类我们称之为STRIDE-LM。

 

表1是STRIDE-LM分类模型，包括定义、相关安全属性及有关威胁类型的默认控制。这个威胁模型能识别大多数威胁类型，随即直接引用相关属性及控制类型。例如信息泄露的相关属性是机密性，控制类型为加密或隔离。默认情况下，"控制"这一列会引用功能控制层（Functional Controls Hierarchy ）及相关的分类及实施清单。这种从威胁分类到控制的直接引用是threat-driven的基本理念。

9.2 威胁模型

威胁模型是以下四个元素的可视化表达：

1. 系统的资产（IDDIL）

3. 组件和资产如何进行交互的描述（IDDIL）

4. 可能攻击系统的威胁源及攻击如何出现（IDDIL）

使用威胁建模是为了获取业界的支持，许多企业、组织及政府机构都使用了这一实践的某个版本。然而至今并没有标准格式的威胁模型，如何将威胁模型运用到不同类型的项目也没有一致意见，例如软件开发vs.数据中心。此外，有大量的工具帮助开发威胁模型。本文不倾向任何技术、工具或分类学，任何工具的选择使用及学习都会约束威胁建模和分析的有效性。IDDIL/ATC方法提供了威胁分析时所需的灵活性和扩展性，每一个组织/团队都应该从IDDIL/ATC方法出发，使用最符合自身业务需要的技术、工具和分类学。

结构上来说，威胁模型可以使用各种各样的格式，这些格式由以下组合决定：a）用于构建模型的工具  b）模型输出的固有范围及上下文。图8、9、10为威胁模型的研究案例，图8是一个更大范围系统（system of system）的顶层威胁模型，图9是使用标准数据流图（DFD）构建的系统层模型，使用了一个或多个威胁建模工具，图10则是一个软件应用的威胁模型。尽管这些威胁模型看起来各不相同，但存在如下共同点：

• 资产表述清晰
• 敏感数据/资产流决定图表结构
• 清楚地标识了信任边界、攻击面及攻击向量
• 图8及图10中，枚举出了威胁源

图8是一个评估项目，图9是一个系统设计期间的系统整合项目，图10是一个敏捷开发的软件项目。这几个图表都不像网络图或其他系统架构图，在收集相关信息完善威胁模型时，虽然其他架构图十分有价值但并非首选，因为实际用于记录和交流威胁及攻击向量的工具在系统内部。

威胁模型提供了极大的价值标识系统中主要组件的内部通信，描绘了重要数据在系统中保存的位置。通过标识组件的功能、逻辑接口，攻击向量的枚举就变得容易了。当要分解复杂算法和状态的改变时，会使用UML（统一建模语言）开发威胁模型。我们需要记住的是：为需要实施的威胁分析使用最合适的图表工具，确保IDDIL/ATC中的所有活动都完成了。

 

图8是一个智能卡生态系统的威胁模型，这个顶层的图表由大量更细粒度的下层图表支撑，这个威胁评估的结果是环境基础设施的安全控制得到了显著提升。此外，模型中也考虑到了"man-in-the-manufacturer”的相关威胁和攻击向量，使得管理层在风险管理时可以做出明智的决定。

 

图9      经典DFD威胁模型

图9是一个财务审计系统的威胁模型，威胁驱动的控制由安全控制和过程控制的组成。这个模型在系统开发时便被整合到了系统中，工程团队能识别并处理最重要的威胁，证实了威胁模型作为工具使用的价值。原始模型建成的三年后，相关系统被迁移到了一个新的环境，不再由原来的工程团队负责。然而由于这个威胁模型包含在系统文档库中，接班的工程师无需修改便能在新环境中指定相同类型的控制。作为历史工具，威胁模型极具价值，它们建立了未来分析的基线，包括了系统、环境及系统面临的威胁和攻击的性质的变化。

 

图10 Web应用威胁模型

图10是一个常规多用户Web应用软件开发项目的威胁模型，这个图有IDDIL中的每一个元素。软件开发威胁模型能让开发团队识别关键资产在系统中的位置及它们是如何流动的，这样就能在合理的位置进行合理的控制。图中缺少了假定的主机环境管理设施，这在应用层威胁模型中经常出现，也是横向移动威胁经常被忽略的原因之一，适当地实施IDDIL/ATC可以防范这种致命疏忽的出现。

10. 攻击树

攻击树的概念源自其它工程学科中的错误分析树，于1999年首先被引入到信息安全界。攻击树是一个分解和辨认攻击向量的极佳工具。通常在当将威胁模型与攻击树进行比较时，威胁模型会说明”是什么"，而攻击树则提供”怎么做"的细节。在IDDIL/ATC模型中，威胁模型和攻击树应该是相辅相成的。

攻击树以一种有逻辑、层次化、图形化的方式分解攻击路径和实现特定威胁或攻击成功所必需的条件。树上的分支和节点代表攻击路径和完整攻击所需的链式事件。安全控制可以直接定位到树上的分支/节点，在最佳的位置阻止或缓解相应的攻击向量。攻击树的局限在于其规模：每一个顶层/端层节点都是某一个威胁或攻击造成的影响，需要分析的攻击越多所需的树也越多。虽然也有例外，但这些例子的资源和时间的分配都并非典型。

 

图11的攻击树分解了成功攻陷OTP令牌凭据所必须的条件，每个分支都包含一系列必须顺序出现的条件。多个单独的分支可以被布尔逻辑”与"串在一起，见图中的弧形箭头，没有弧形箭头”与"的分支则认为是”或"条件。完整的攻击树应遵循如下指导：由于树是向下的，每一个分支及随后的条件应说明事件链是如何一起构成顶层节点威胁条件的。

绿色方框是用于移除、阻断、缓解特定攻击路径的安全控制。如果一棵树有完整的分支但缺乏控制，则明显是一个待讨论的风险管理缺陷。通过这种方式分配的控制既有精度也有广度，是评估控制的有效性的基本方法。架构师借助攻击树可以发现不足和无效的地方，决定哪些设施、服务及线路图需要调整。

 

图12是水平攻击树，灰色节点是树的条件节点，红色节点是相关条件，绿色节点是安全控制，黄色节点是威胁源/攻击代理。这棵树可以和图11做一个对比，说明了攻击树的灵活性及创新性。

10.1 威胁画像

本文中威胁画像被定义为表格形式的威胁、攻击及相关特征的总结。表格格式允许以行、列的形式给出选中的画像，具备相当的灵活性。威胁画像是交流已完成的威胁模型和攻击树的非常棒的工具，允许整合、排序、旋转及其他常见的数据操作功能，详细描述了威胁及攻击向量的因果关系。

一些评估做法使用威胁画像这一术语描述类似于攻击树的分解，其他的则和本文描述的比较一致。最近，术语”威胁画像”已被用到了网络威胁情报中。

表2是一个通用的威胁画像模板，表3连同清单1一起，表4描述了威胁画像的案例。表3和表4的不同之处在于，表3的画像精细，表4则是一个大范围、详细分析的案例的总结。这两个例子说明了威胁画像的灵活性和可扩展性。

 

表2 威胁画像模板

 

表3 威胁画像示例：概念阶段使用STRIDE-LM

表3的威胁画像是运营概念文档的一部分以支持新的外联网主机托管服务的设计，因此这个时候缺乏漏洞及控制。上层控制的分配基于使用STRIDE-LM模型发现的威胁类型，结果为：STRIDE–LM：

• 篡改

• 信息泄露

• 权限提升

• 横向迁移

每一个主要的威胁类型都有相应的安全属性（如表1所示），协助工程师选择和实施相关的安全控制，威胁类型及相应的控制描述如清单1所示：

 

表4为一个更大规模使用威胁画像的例子，所列出来的项是完整表的一个子集。这个画像是综合分析的结果，囊括了多个威胁模型及攻击树报表，可以作为管理者做风险管理决策和计划部署时的主要沟通工具。它还能用于跟踪问题直到其得到解决，或者用于其他有价值的数据分析功能。表4中第一列标识了问题的起因，第二列阐述了问题造成的影响。因果链是威胁分析工作中一个必要的因素，威胁画像为之提供了一个有效的沟通工具。

 

当通信、跟踪、排序及其他数据旋转分析结果是必选项时，显而易见的灵活性使得威胁画像经常成为首选。

10.2 实践总结

目前为止，我们已经讨论了威胁模型、攻击树和威胁画像，简要总结如下：

 

表5 威胁分析实践总结

接下来讨论IDD方法论和CKC实践的整合，正式它们的整合产生了威胁情报。

11. 威胁情报

IDD模型基于CKC实践，在业内已广为接受。为了提炼出CKC的最大价值，我们应该把它当做一个综合分析的框架而不仅限于应急响应。当CKC作为一个分析和综合平台使用时，组织成为情报生产者，将情报其传给关键程序处理，用于核心基础设施的改进，然后从威胁驱动的方法中受益。这样，组织对于网络攻击的适应能力得到最大化，企业保护的资金和资源也得到了合理分配。

表13是扩大杀伤链阶梯交叉多个威胁是获得的综合分析能力，相比在阻塞发生时暂停分析，分析员会继续分解TTPs，然后引用它们前向识别可能发生的其他阻塞，当然也可以用于后向识别。没有可能产生阻塞的步骤表明存在着不足，需要加大相关投入。分析期间发现的TTPS、属性及其他特征会被反馈到情报管理中心加强报告、历史分析及预测的能力。

 

图13 情报驱动防御框架：网络杀伤链

CKC不仅适用于分析员做应急响应和情报管理，也可以被架构师和工程师使用。架构师/工程师在理解了杀伤链7个步骤的影响后，他们可以开发出更全面、更好的的威胁分析工具。一旦架构师/工程师接收并处理威胁情报输入，便形成了一个更加敏捷的工程环境，架构上的缺陷也变得更容易识别和解决（这一概念将在论文中控制一节进行回顾，并阐述相同的分析如何被用于评估控制和塑造系统架构）。分析与运营人员都能从威胁建模和分析工具中收益，尤其是在情报很少的新技术环境中帮助发现潜在的新型攻击向量。协调这些互补的实践会产生一个敏捷、有弹性的安全实践并推动组织到达一个更加成熟的安全水平。

11.1 战术分析整合

CKC已经成为了计算机网络应急响应事实上的标准，也是威胁情报分析的平台。在缺乏威胁情报或威胁源使用新的TTPs时，IDDIL/ATC模型已被证明是杀伤链的有效补充。以心脏滴血漏洞为例，由于事先没有关于心脏滴血漏洞的提示和情报，当心脏滴血利用首先被检测到时就有一个必要的发现时期。洛克希德·马丁调动了响应团队使用IDDIL/ATC方法加强全局响应成果，描述如下:

• 识别资产：结合现有的系统管理工具、之前的扫描报告（编目和管理控制功能）及主动扫描，团队能快速发现那个系统存在有漏洞的OpenSSL版本。
• 定义攻击面：定位到发现有漏洞的OpenSSL系统并判断它们部署了哪些应用及服务（编目和管理控制功能）。在确认发现的早期过程联系业务经理、系统持有人及管理员，使得将来的活动能更有效的进行。
• 分解：确定漏洞系统使用/提供了哪些接口，这些系统的类型是什么——VPN服务器，Web服务器、浏览器等，及这些接口和系统可用的数据/账户类型。这样，结合资产识别可以颗粒化地枚举可能泄露的敏感信息。
• 标识攻击向量：联合威胁情报数据和红队研究的开源信息能帮助发现其他的攻击向量，包括验证公开的披露报告及获取攻实际的攻击详情。这些信息能大大加强高度压缩的时间范围内对其他漏洞资产的识别。
• 列出威胁因子/攻击代理：使用上述步骤得到的信息，主动监控相关已知对手、安全研究员及未知个体。
• 分析：确认基于IDDIL发现阶段的全部范围，将标识的所有脆弱资产及可能泄露的敏感数据记录在案。分析时要注意任何成功的攻击或重要/敏感数据的提取行为。
• 分类：从IDDIL/ATC中捕获到的发现能让我们可以快速行动，实施对抗杀伤链中侦查跟踪、载荷传递、突防利用、达成目标等步骤的控制。这些控制以发现的攻击面、分解及攻击向量为依据，在合适的位置实施。补救措施排出了优先级，先用于对外系统，其次是与合作伙伴对接的系统，最后是内部系统。
• 控制：IDDIL/ATC方法在高度压缩的时间范围内提供了详细可行的（方案）信息，使得不同安全控制功能可以在多个地方实施。这些控制功能包括：保护、收集、检测及响应。已有的恰当编目和管理控制功能提高了IDDIL/ATC的效率和有效性。相同的编目和管理功能作为心脏滴血漏洞应急响应的一部分同样在这一过程中得到了加强。战术上来说，如果能够完全理解攻击面和攻击向量，就可以在合适的架构层部署多个控制（机制）强化对（心脏滴血活动的）相关检测。提取的情报作为确保控制合理实施的方式，可用于对抗（竞争）对手的扫描行为。

总的来说，围绕心脏滴血漏洞的完整周期，威胁驱动方法论及可防御体系概念得到了验证。

11.2 聚焦最大威胁

威胁驱动方法的另一种应用方式是：聚焦于环境中最大的威胁，持续使用IDDIL/ATC方法论对抗这些威胁。在这样的上下文中，威胁是和人/集团对抗的不利影响。正如之前讨论过的，一个较大的威胁是横向移动。横向移动（lateral movement）有若干变种，最有害的一种情况是对手已经获得了立足点，并具备以此为支点扩大在环境中影响的能力。这对应着CKC中的第七步（actions on objectives），横向移动的一个主要机制是Windows中的pass-the-hash攻击。

洛克希德·马丁组建了一个跨职能团队，成员们来自于洛克希德·马丁计算机应急响应中心、红队及安全架构/工程组。如果新的或更好的收集、检测及控制措施能被开发，他们就能够理解这些攻击并进行探索。通过联合威胁情报及IDDIL/ATC实践，使用开源工具及进行额外的研究，该团队发现了从内存中提取哈希值的多个威胁因子的根本原因：以一种非预期的方式滥用部分系统API；反病毒、内存保护及其他终端控制已经被证实在阻止这类攻击时效果十分有限。重新设计管理员/有权限的账户程序，添加管理员访问网关，保护有权限账户的密码提供了一般程度的保护。微软最近在操作系统上做了不少努力，以减少攻击面、缓解一些攻击向量。然而只要密码的哈希之保存在Windows系统中，这个威胁就会一直存在。因此，”联合团队"开发出了如下新的控制措施：

• 定制化的主机入侵防御系统规则，用于记录（log）并拦截lsasrv.dll、lsass.exe对CreateRemoteThread()及NtCreateThreadEx()的调用。
• 在重要的、影响重大的服务器上移除调试库：symsrv.dll及dbghelp.dll。
• 记录并跟踪到微软符号服务器（Symbol Server）的带外请求。

这些控制的确能缓解，甚至在很多情况下能阻止提取密码哈希值的尝试。最起码当威胁源试图横向移动的时候，它们为威胁情报处理提供了高精度的可见性。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

小结

以笔者实际接触过的案例来看，国内重视网络安全的公司/组织绝大多数是由合规性驱动的，结果投入了很多人力物力，整体的安全状况却并没有得到改善。举个很现实的例子，在乌云漏洞报告平台发展到今天的程度之前，很多厂商会忽略在乌云平台上提交的漏洞，虽然现在仍有部分厂商这么做，但笔者看到的一个现象却是这样的：当乌云平台上报告了某个厂商的漏洞，由于该漏洞会通知到监管机构，厂商变得对此非常重视并赶紧验证和修复漏洞。以前是采取不理会的做法，现在则是害怕自己的相关漏洞曝光。有时候一个很小的问题都需要折腾一番，花费了大量人力去修复。但漏洞会不断的出现，厂商"疲于奔命"，所做的工作最终只是治标不治本。

缺乏对网络安全足够的理解，即便渗透测试、白盒审计也只是能部分解决组织结构所面临的威胁，控制的有效性仍待提高。最后，网络安全之路任重而道远，腾讯应急响应中心负责人@flyh4t之前说过的几句话或许可以表达广大同仁的心声：