择要
现在的网络安全风险管理实践很大程度上是由合规性要求驱动的，这使得公司/组织不得不在安全控制和漏洞上投入人力/物力。（风险管理涉及多个方面，包括资产、威胁、漏洞和控制，并根据事故发生的大概性及造成的影响进行评估。威胁会通过漏洞对信息系统造成损失，安全控制则是试图制止或缓解威胁源实行攻击的措施。）然而，由于致力于安全控制和漏洞，他们忽略了风险管理中最重要的因素——威胁。这种失衡的状态表现为服从既有的安全架构及工程实践中的尺度和原则，更加注意应急响应而不是风险管理。
一个功能完备的架构应该将威胁放在战略、战术及运营实践的主要位置，工程师和分析员们遵照常规的方法论，将威胁分析和凌驾多个职能系统的威胁情报整合到一起，而不是让它们彼此隔离。这保证了安全控制得到实行和评估，并随着不停出现的有影响力的威胁和攻击向量而不停调解。如许能使我们得到更加准确的信息，以一种更优的方式分配资源及控制其使用，从而生成一个敏捷、有弹性的网络安全实践。这种威胁驱动的方法和合规性并不冲突，对一个机构来说正如量身定制一样平常，践行这一方法可以是风险管理得到增强，机构最终得到一个既合规又更加安全的信息系统。
引言
现在，网络安全领域的架构、工程及运维实践主要聚焦于合规性——遵照一到多条规定、政策。一些机构整合了传统的信息安全理念及原则，并试图将安全植入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. 负担能力及本钱影响
众所周知时间线上越靠右，发现和修复一个问题的本钱便越高，对于网络/信息安全问题来说尤其云云。这突出了在生命周期中尽大概早囊括威胁建模、分析及情报数据的另一个主要利益：主要的计划缺陷及全局问题能尽早被发现和修正，减少了构建和维护系统的长期本钱。没有哪一款漏洞扫描器或合规性查抄列表可以发现全局计划缺陷。不幸的是，大多数安全相干的活动都只是从工程生命周期的靠后的阶段才开始，这会使面临的危险场景更加——更高的开发和运营费用，更加不安全的情况。
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 威胁分类，安全属性及控制
表1是STRIDE-LM分类模型，包括界说、相干安全属性及有关威胁范例的默认控制。这个威胁模型能识别大多数威胁范例，随即直接引用相干属性及控制范例。比方信息泄露的相干属性是秘密性，控制范例为加密或隔离。默认情况下，"控制"这一列会引勤奋能控制层（Functional Controls Hierarchy ）及相干的分类及实行清单。这种从威胁分类到控制的直接引用是threat-driven的根本理念。
9.2 威胁模型
威胁模型是以下四个元素的可视化表达：
1. 系统的资产（IDDIL）
2. 系统的攻击面（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 智能卡生态系统威胁模型示例
图8是一个智能卡生态系统的威胁模型，这个顶层的图表由大量更细粒度的下层图表支持，这个威胁评估的结果是情况基础设施的安全控制得到了明显提拔。此外，模型中也思量到了"man-in-the-manufacturer”的相干威胁和攻击向量，使得管理层在风险管理时可以做出明智的决定。
图9 经典DFD威胁模型
图9是一个财政审计系统的威胁模型，威胁驱动的控制由安全控制和过程控制的组成。这个模型在系统开发时便被整合到了系统中，工程团队能识别并处理最重要的威胁，证实了威胁模型作为工具使用的价值。原始模型建成的三年后，相干系统被迁徙到了一个新的情况，不再由原来的工程团队负责。然而由于这个威胁模型包含在系统文档库中，接班的工程师无需修改便能在新情况中指定相同范例的控制。作为汗青工具，威胁模型极具价值，它们建立了未来分析的基线，包括了系统、情况及系统面临的威胁和攻击的性质的变革。
图10 Web应用威胁模型
图10是一个常规多用户Web应用软件开发项目的威胁模型，这个图有IDDIL中的每一个元素。软件开发威胁模型能让开发团队识别关键资产在系统中的位置及它们是怎样活动的，如许就能在合理的位置进行合理的控制。图中缺少了假定的主机情况管理设施，这在应用层威胁模型中经常出现，也是横向移动威胁经常被忽略的原因之一，恰当地实行IDDIL/ATC可以防范这种致命疏忽的出现。
10. 攻击树
攻击树的概念源自其它工程学科中的错误分析树，于1999年首先被引入到信息安全界。攻击树是一个分解和辨认攻击向量的极佳工具。通常在当将威胁模型与攻击树进行比力时，威胁模型会说明”是什么"，而攻击树则提供”怎么做"的细节。在IDDIL/ATC模型中，威胁模型和攻击树应该是相辅相成的。
攻击树以一种有逻辑、条理化、图形化的方式分解攻击路径和实现特定威胁或攻击成功所必需的条件。树上的分支和节点代表攻击路径和完备攻击所需的链式变乱。安全控制可以直接定位到树上的分支/节点，在最佳的位置制止或缓解相应的攻击向量。攻击树的局限在于其规模：每一个顶层/端层节点都是某一个威胁或攻击造成的影响，需要分析的攻击越多所需的树也越多。虽然也有破例，但这些例子的资源和时间的分配都并非典型。
图11 OTP令牌的攻击树
图11的攻击树分解了成功攻陷OTP令牌根据所必须的条件，每个分支都包含一系列必须顺序出现的条件。多个单独的分支可以被布尔逻辑”与"串在一起，见图中的弧形箭头，没有弧形箭头”与"的分支则认为是”或"条件。完备的攻击树应遵照如下指导：由于树是向下的，每一个分支及随后的条件应说明变乱链是怎样一起构成顶层节点威胁条件的。
绿色方框是用于移除、阻断、缓解特定攻击路径的安全控制。如果一棵树有完备的分支但缺乏控制，则显着是一个待讨论的风险管理缺陷。通过这种方式分配的控制既有精度也有广度，是评估控制的有用性的根本方法。架构师借助攻击树可以发现不足和无效的地方，决定哪些设施、服务及线路图需要调解。
图12 VPN合作同伴连接攻击树
图12是水平攻击树，灰色节点是树的条件节点，红色节点是相干条件，绿色节点是安全控制，黄色节点是威胁源/攻击署理。这棵树可以和图11做一个对比，说明白攻击树的灵活性及创新性。
10.1 威胁画像
本文中威胁画像被界说为表格形式的威胁、攻击及相干特征的总结。表格格式允许以行、列的形式给出选中的画像，具备相当的灵活性。威胁画像是交流已完成的威胁模型和攻击树的非常棒的工具，允许整合、排序、旋转及其他常见的数据操纵功能，详细形貌了威胁及攻击向量的因果关系。
一些评估做法使用威胁画像这一术语形貌类似于攻击树的分解，其他的则和本文形貌的比力一致。最近，术语”威胁画像”已被用到了网络威胁情报中。
表2是一个通用的威胁画像模板，表3连同清单1一起，表4形貌了威胁画像的案例。表3和表4的差别之处在于，表3的画像精细，表4则是一个大范围、详细分析的案例的总结。这两个例子说明白威胁画像的灵活性和可扩展性。
表2 威胁画像模板
表3 威胁画像示例：概念阶段使用STRIDE-LM
表3的威胁画像是运营概念文档的一部门以支持新的外联网主机托管服务的计划，因此这个时间缺乏漏洞及控制。上层控制的分配基于使用STRIDE-LM模型发现的威胁范例，结果为：STRIDE–LM：
每一个主要的威胁范例都有相应的安全属性（如表1所示），协助工程师选择和实行相干的安全控制，威胁范例及相应的控制形貌如清单1所示：
清单1 威胁范例安全控制分配计划
表4为一个更大规模使用威胁画像的例子，所列出来的项是完备表的一个子集。这个画像是综合分析的结果，囊括了多个威胁模型及攻击树报表，可以作为管理者做风险管理决策和计划部署时的主要沟通工具。它还能用于跟踪问题直到其得到解决，或者用于其他有价值的数据分析功能。表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之前说过的几句话或许可以表达广大同仁的心声：
网络安全工程师企业级学习路线
末了我也整理了一些网络安全（黑客）方面的学习进阶资料
如果你想跟同道中人交流
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
