接着上篇：威胁驱动的网络安全方法，本文取自洛克希德·马丁公司的另一篇论文：Defendable Architectures。
翻译时间和水平有限，理解不是很准确或词不达意之处还请谅解或阅读原文，转载请注明来自博客园r00tgrok。
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
摘要
传统的安全架构方法主要通过系统加固应对攻击，这样做的潜台词是一旦系统部署上去就有责任拦截所有攻击。然而过度依赖加固的系统在其生命周期中无法从攻击者那学到什么，也没法适应其的技术、能力和目标中的改变，更不用说当攻击者偶尔成功时能处理好这一现实。复杂的敌方的持续努力如APT攻击要求系统能以一种旗鼓相当的复杂方式进行主动防御。通过各种来源的情报如系统自身的交互，建立的能理解攻击者的模型使得防御者能适应和预测敌方攻击中的改变。
防御型体系描述了一种可选的系统架构方法，它通过明确地设计、实现及维护系统以践行情报驱动的防御（IDD）。防御型体系的结果是一个良性的循环，系统有着良好的可见性以收集情报，能够快速地将情报转换为防御方法，以及将这些方法部署到系统安全控制时更高的效率。威胁情报在构建系统时也能派上用场，确保设计的系统能很好地适应当前及将出现的威胁。这一概念也能作为一个整体扩展到企业（层面），描述在情报驱动防御这一理念下，组织该如何计划和部署它们的系统及基础架构。通过践行这一方法组织能打造一个具有弹性的系统应对网络攻击，并创建对攻击者的技巧和目标具有弹性的系统设计。
1. 引言
经典的信息安全准则致力于加固系统以应对潜在的攻击，即设计者预测系统将受到的攻击然后指定能阻止攻击的安全控制。意味着一旦付诸实施，系统就应该能拦截任何对它的攻击。这一方法无法反映当代信息安全防御的真实情况：首先系统没法保证自身的安全，数周、数月甚至数年前设计的静态控制无法拦截每一起攻击，再者系统也不能适应敌人行为上的变化。简而言之，如果一个聪明人策划一起攻击，则必须有一个聪明人指导相关的防御。
本文描述了一种能更清楚地反映网络系统该如何进行防御的可选方案。基于这一体系，使用情报驱动防御（IDD）技术的系统能更好地适应敌人的变化，包括其目标和TTP。通过展示可见性、可管理性及可存活性，系统能更好地抵抗威胁，而对威胁情报的使用也将贯穿于系统的设计、开发和运营期间。
企业的所有系统，包括接口和临近系统都需要纳入考虑，理解系统环境对于设计（安全体系）和防御（攻击）来说至关重要。公司可以在其全部范围搜集威胁情报，并在计划和实现通用安全基础设施时使用这些情报，这样防御型体系架构的概念便被扩展到了防御型企业（Defendable Enterprise）。
2. 利用系统知识和威胁情报
人类智力在系统防御中发挥着积极作用，构建防御型体系不仅需要防御者的知识和情报，也需要设计者、开发人员、测试人员及维护系统的管理员参与其中。这些角色涉及系统的整个生命周期：设计、构建、运行、防御，都提供了独特的机会来共享他们的知识并将其合并到一起整合进系统中。
图1 防御型安全体系生命周期
设计阶段，工程师申明系统的概念、要求及设计，此时会确定很多基本的系统安全特性。防御型体系不同于传统安全架构之处在于，它不仅试图设计一个加固过的系统，还使用威胁情报和系统威胁分析来指导架构决策，并设计情报驱动的防御系统。基于防御型体系的系统展现出了可见性、可管理性及可存活性。在设计时工程师会分析可用的威胁情报判断哪种安全控制是最有效的。
构建阶段，工程师通过代码和配置实现系统功能和安全控制。测试人员验证系统的安全特性及设计时采用的安全控制的有效性，他们会使用不同的方法，如检查配置项、进行安全控制演示、静态和动态漏洞测试，甚至进行渗透测试。测试方法不尽相同，通常由风险及相关待测试功能的重要性决定。
运行阶段，管理员管理系统，终端用户使用它。管理员一直维护系统，包括打补丁及系统管理。他们也会支持开发和防御人员对系统进行诊断，并基于防御者的新发现对安全控制进行调整。
防御阶段，情报分析生成具有可见性的情报，据此检测和响应攻击，包括保护生产、测试、开发环境及相关源代码。防御者将自己的发现转换为保护及防御规则，并将这些规则用于主动防御系统中，此外他们也会和设计者、开发人员及管理人员沟通攻击向量的变化。
每一个阶段以及对应的角色都有重要的情报和知识可以分享、融合，如下总结揭示了信息从一个阶段到另一个阶段的传输。
图2 信息流示例
虽然图2中有很多通信在经典的安全工程方法中也有，但以下几点是防御型安全体系中独有的：
图3展示了组织能持续整合系统知识及相关威胁到系统设计、构建、运行及防御的各个阶段。
图3 防御型体系的循环知识流
对系统的威胁分析在系统设计、开发和修改的阶段生成。这些分析始于识别重要资产（如数据及系统功能），系统威胁则是不受欢迎的、可能影响这些资产的事件和条件。只要资产存在，威胁就会一直存在，比如系统的交易数据可能会被窃取、篡改、无法使用或抵赖。这些威胁对组织的任务和业务需要有着不同的潜在影响，设计者和开发人员需要权衡威胁对组织的影响并采取控制措施减轻他们。分析的结果是能够理解系统的资产、面临的威胁及使用的控制措施，与管理员及防御者分享分析结果能让他们洞悉系统中什么资产是最重要的，以及采用控制措施能产生什么作用。
除了威胁分析，设计者及开发人员会指定系统配置及预期的行为。这能帮助防御者理解系统的设计与实现，这在事件分类与恢复期间是至关重要的。防御者同样能根据预期的系统行为校准他们的检测机制，例如系统设计仅允许从指定的网络路径登录管理员，防御者就知道其他网络发生的管理活动是可疑的，需要做进一步的侦查。防御者也有重要的信息和设计者、开发人员及管理员共享，通常收集到的威胁情报会标识为三种不同的抽象，不同层次的威胁会以不同的方式影响设计、实现及运营。
第一层，新的发现用于开发规则，这些规则应用于基于企业级攻击分析和威胁情报共享的已有（安全）控制。这通常意味着敌人正在改变他们的部分工具包或基础设施，这些变化由防御者管理并添加到已有的安全控制配置和规则中。
第二层，比第一层更抽象。敌人TTPs的改变使得有必要实施新的控制以应对新的攻击，比如从Email转变为基于Web的攻击标志着新活动或新攻击方式的存在。由于攻击者改变TTP时会付出一定的代价，这些会成为比单个指示器更可靠的检测和保护控制。有些TTP的变化需要基础设施或系统的修改，因此一个灵活的基础设置能让防御者适应TTP的不同变化。观察到TTP的变化同样会导致一些现有控制的淡化，以便重新分配运维和开发资源给新的、更有效的关节措施。
第三层，理解敌人的目标与意图。不同于指示器和一些TTP的改变，它们都可以更加敏捷地应付这一状况，敌人目标的变更主要影响系统设计和控制的选取。将敌人目标与系统的完整性、机密性及可靠性需要相比较，设计者能制定适当的决策并选择最能有效缓解预期威胁的安全控制。比如一个必须能顶住DDOS攻击的系统和没有这一需求的系统在设计上是不同的，这也让开发、测试及管理员也可以实现必要的控制并选择适当的测试场景。根据给定的威胁情报分析当前系统安全需求给出了一幅更完整的系统风险状态图。
对于已经根据防御型安全体系理念部署了安全设施的组织而言，防御者能根据新的指标及TTP的变更进行直接、快速的响应。基于新的威胁情报，调整控制所需的步骤越少，组织就能越快应对敌人的变化。这些信息流创建了一个很好的闭环，威胁情报影响系统设计与实现，反过来也提升了系统自身的运维和防御水平。通过在系统生命周期中的知识共享，团队能更好地保护系统，结果是系统及系统架构在应对攻击时具备更好的弹性。
3. 支持情报驱动的防御
借助上文的知识流，组织可以将他们具有适应性的系统投入使用。对于组织而言，能更好地理解正常条件下的操作同样可以帮他们更有效地保护系统。信息交换驱动着设计决策、权衡实现及系统的运维需要。除此之外，防御型体系架构还展示了一些常见特征，具备这些特征的系统为IDD而设计，管理员和防御者能更好地进行主动防御，这些特征总结为：可见性、可管理性及可存活性。
可见性对于IDD分析来说至关重要。操作员和防御者能看到网络/操作系统中及应用层的活动。它还提供了活动历史记录，用于将来的情报侦察。
可管理性确保了系统可一直维持下去。维持系统的安全状况包括给系统补丁和配置，它同样使得可以根据新的威胁情报更新系统环境或安全控制。部署更新的速度和精度会极大地影响到防御能做得多好。
可存活性允许系统在遭受攻击、被攻陷或恢复时仍能提供预期的服务。经典的安全准则致力于在遭受攻击时加固系统，而防御型体系还能让系统承受横向渗透并支持系统从攻击中恢复。
4. 创建防御型系统
安全是系统的固有特性，并非后来才加上去的。基于防御型体系的系统会综合衡量任务需要与威胁情报，展示出它的可见性、可管理性及可存活性。下面的章节将说明基于防御型体系的系统要如何进行设计、构建、运行及防御。
4.1 设计防御型系统
设计者有责任将防御型体系的特征植入到系统中去。传统的安全设计方法致力于选择控制，但设计者必须先理解系统中的资产及面临的威胁，以及这些威胁对组织任务及业务的影响。系统的主要安全目标是保护资产，因此在设计时应将对资产的威胁放在首要位置。不同于漏洞及设计缺陷，系统威胁代表着一种相对稳定的系统安全目标。正如上文所说的，只要资产存在，威胁就一定会存在，这就提供了评估和选择集成到系统设计中的控制的基调。
遵循结构化的威胁分析方法可以帮助设计者识别对系统和资产的潜在威胁，也能提供评估哪种控制和设计选择能更好地缓解威胁和攻击向量的方式。例如数据加密能缓解未授权的信息泄露，但具体的实现决定了能有效地对抗哪种类型的数据窃取。在这个例子中，硬盘层的加密仅能对付物理窃取，而应用层的加密能缓解系统层的攻击。每一个选项都会以不同方式影响系统性能及维护需要，这意味着设计者在缓解威胁及管理其他系统影响时需要做一个权衡。
即便是中等复杂的系统也有很多资产，因此有很多潜在的威胁。设计者根据他们的对于组织任务及业务需要的理解帮助梳理资产和威胁。威胁情报实践已经比较成熟的组织能够将这些信息整合到威胁分析过程中，例如IDDIL/ATC方法就提供了相关步骤，图4是对这一过程的描绘：
图4 系统威胁分析时任务需要和威胁情报的整合
使用这一联合分析，设计者能就设计的权衡和有效的安全控制做出明智的决策。设计者必须仔细评估他们构建的控制能将威胁阻止到哪个程度。图5描绘了在缺乏现有威胁情报的情况下，对系统的威胁必须得到缓解，尤其是当严重影响到了系统、业务及组织时。
图5 使用系统威胁、任务需要及威胁情报
选择控制（措施）时，设计者既要处理单个系统威胁，也要从整体上考虑主动防御的需求。图6中的安全控制目录确保了设计者会注意到安全基础设施及系统的可用服务。通过定义基于功能的控制，这个目录给设计者提供了一个清晰的指导——每个控制为系统更提供了什么，而是不是阻止了什么。设计者主要借助”保护”一栏的控制缓解系统威胁，其他功能则用于弥补”保护”功能中的不足。
然而，单纯地减轻系统资产的单个威胁并不会产生一个防御型系统，IDD的设计要求有对系统活动及行为的可见性，系统更新部署、基于新情报的可管理性及在遭受攻击与恢复期间可持续提供服务的可存活性。因此，设计者根据功能群的广度控制来建立关键的防御型体系特征，下面的章节讲述了如何将这些特征整合到系统设计中。
图6 功能控制层的顶层控制功能
如图7所示，组织可以在不同层传递控制，安全基础设施由植入到系统中的功能组成。安全集成服务是那些系统能使用但必须整合的东西，例如日志收集与认证服务。重用的安全控制从被管理的库中部署到了系统中，比如操作系统镜像和加密库一样。最后，应用层安全控制是应用层必须自己实现的，如输入认证、内存检查及事件日志记录。设计者在可能的情况下使用基础设施和服务，系统开发及管理员能致力于系统的核心功能。这也导致了一个更加持续的控制实施，通过在公共基础设施层提供可见性提升了整体的防御能力。
图7 安全控制的多个层次
4.1.1 可见性设计
可见性设计的目标是让防御者能综合监控系统中当前及历史活动。防御者和管理员能重建事件序列，尽管它们交叉于各个组件之中。可见性控制必须置于系统中的有利位置，记录的事件也必须包含足够的信息来关联日志入口。图8展示了设计者在判断可见性要求时要考虑的问题和活动样本。
图8 不同系统层的可见性目标
用于整体系统架构的系统威胁分析也能用于决定可见性控制在系统中的位置。威胁模型中的信任边界代表着系统中的一条重要防线，对信任边界和系统资产的监控为管理员提供了有用的诊断信息，也给了防御者关于敌人行为的极为重要的认知。最有可能的情况是，设计者会借助植入到系统中的可见性基础设施和系统中可用的集成服务（达到自己的目的）。
考虑到可见性的实时和历史使用状况，区分事件收集、检测、存储及分析的概念是很重要的。收集网络数据和系统日志的程序随后会反馈关联的检测机制，并伴随着处理、存储和分析，如图9所示。企业的全盘可见性设计保证了重要的攻击面处于监控之中，此外也确保了从不同传感器收集来的数据能关联起来使用。
图9 可见性基础设施
可视性数据的收集与存储对组织的计算、网络和存储能力提出了要求，设计者、管理员、防御者共同合作排列可见点、收集率和保留期限。典型的可见性从网络层开始，上移动到操作系统和应用层。随后的每一层都丰富了收集到的事件语义，但也增加了将数据正常化的数量和难度。不同的可见性来源，如应用日志通常不太好正常化，通常这种日志在分析处理时最好是保持原始的格式。
可见性扩展超出了对主动攻击的监控，例如，知道敌人什么时候以什么方式进行侦查就能够将其与后面的攻击关联起来，这提供关于敌人操作的重要情报。作为设计者，意识到在攻击的每个阶段系统是如何被侵入的，以及确保对这些行为的可见性是构建防御型体系的重要部分。
4.1.2 可管理性设计
一个可管理系统的能主动防御当前和将出现的攻击，设计之初便要能支持基本编目、配置、漏洞管理，根据威胁情报进行更新。漏洞管理要求能及时为系统的所有组件打补丁。虽然补丁设施（patching infrastructure）能满足大部分需要，但设计者必需意识到到有些组件是不被企业的补丁系统支持的，这些补丁必须有管理员手动下载并安装。仅为软件打上补丁无法确保其安全，管理员还得进行配置和维护。
因此，可管理性设计应包含管理员手动安装、补丁及配置组件机制。防御型体系包含了管理员访问系统、下载更新及管理系统配置的受控和监控的路径。可见性和可存活性特性同样会被应用于管理路径中。监控管理接口的活动提供了关于系统的洞察力——谁于什么时候在哪里做了什么事情？这些信息对于从事故中重建事件序列至关重要。
矛盾的是，许多可管理性功能要求一些附加的外部接口，这反而会增加系统的攻击面。在实现这些功能时，必须放在系统上下文及威胁中考虑需求与其实现方式。例如大多数情况下自动化的补丁接口是一种恰当的实现，然而在一些不联网的系统中，有偿控制减少补丁的频次实际上会降低整个系统的风险。
可管理性设计的第二部分是将新的威胁情报整合到系统的安全控制中，做到这一点的组织在网络安全防御中明显有别于那些遵循经典信息安全准则的企业。基于防御型体系的系统使用应用于不同系统架构层的通用安全设施和服务来实现可管理性这一部分。
可管理性意味着对网络、操作系统、平台及应用层进行控制，防御者能在系统的适当层次更新控制措施。例如关于敌人设施的情报可能让相关控制阻塞某些IP，然后在IP防火墙中实现。而关于C&C协议的情报则会导致基于HTTP头和内容的规则，并在Web代理中实施。这一在跨越多个系统并在系统不同层更新控制的能力，让防御者可以实先更精确的规则，极大地提高了应对攻击的效率。组织控制目录间的交叉引用，为设计者和防御者提供重要的情报/洞察力。
通过校准保护控制的可见性有利位置，防御者可以测试并调整基于网络流量和系统日志的规则。这使得防御者有把握部署新的规则却只需承担更少的误报和意外的业务影响风险。进一步说，基于防御型体系的基础设施可以适应TTP甚至敌人目标的变化。在已有的可见性收集能力的顶端进行保护，提供了一个灵活的架构，提高了添加新规则、拦截的效率。
防御型体系有别于经典的纵深防御方法，但它们之间并不互斥。传统的纵深防御使用相似的多层控制弥补彼此的缺陷，将控制当作一个静态的过滤层并期望它们中至少有一个配置正确，能拦截攻击。然而纵深防御强加的全局性降低了系统的可管理性，管理员得娴熟地使用多个工具并花大量时间维护它们。防御型体系架构则致力于创建一个基于威胁情报和威胁分析的系统，能跨越多个系统层实现主动控制。
4.1.3 可存活性设计
可存活性是系统在遭受攻击、沦陷或恢复时仍能正常提供服务的能力，必需在设计系统时占据一席之地。想进行计算机网络利用（computer network exploitation，CNE）的攻击者旨在从目标系统中偷出（exfiltrate ）信息，这种情况下系统被攻陷很少会引起系统失败。另一些入侵者则希望不被检测到，他们会采取迂回手段绕过检测。在CNE中，对系统来说最混乱的不是初始的沦陷，而是发现和恢复过程——组织一旦检测到攻击便会将系统下线进行分析和恢复。
与CNE相反，如果攻击者的目标是计算机网络攻击（CNA），则他们更倾向于中断系统或破坏组织的部分资产。此时被攻击的系统就是他们的目标，常见的例子是拒绝服务（DOS）攻击。CNA也可能是在不被发现的情况下获取对系统的访问，随后进行横向渗透。 遭受这种攻击向量的系统如同CNE攻击下的一样，受相同的可存活性影响。
在CNE和CNA场景中，系统设计者必须将可用的敌人目标威胁情报与威胁分析结果做比较，详细描述见4.1节。设计者可以根据攻击对象和业务重要性选择满足系统需要的防御方法。敌人目标的改变也会使系统设计及相关控制进行必要的改动。如果新的威胁情报暗示系统可能遭受篡改攻击，那么细粒度审计和完整性控制就会具备较高的优先级，而这一需要在使用威胁情报分析技术时就能预料到。即便安全控制没有在系统刚完成时就植入其中，在将来的整合中也会设计进去。
最常见的事故恢复方式是将整个系统下线，进行取证分析，搞清楚什么时候、哪个组件是如何被攻陷的，然后从备份中恢复配置和数据。尽管这种设计和运维方式对许多系统来说都可以接受，但对于一个更加重要的系统来说就需要更复杂的方法了。更高级的存活性设计能让系统在分析和恢复时继续运行，取决于：（1）提供彻底的可见性，对系统组件的当前及历史状态进行分析。（2）组件能在不影响正常操作取下或放回。
这个案例中的可见性是上述特性的扩展，为了发现和分析的攻击者行为，可见性必须从深度和广度上覆盖到系统的各个层次及应用中的组件。它还必须跨越各个时间段，从按需的取证捕捉到系统中的历史活动，这些操作包括网络流量捕捉、记录文件系统改变、操作系统、应用配置及应用活动。最后它还要求能全面捕捉系统状态，包括内存和网络流量。这些对于评估当前系统状态的入侵分析及关联指示器和其他来源的情报来说十分必要。基于这一分析，判定哪个组件被攻陷及发生多久了便成为了可能，随即基于系统备份等方法可以恢复系统。
图10 入侵分析和恢复的可见性
高级的可存活性设计的第二个要求是：组件容错设计——可以随时下线、上线。一些设计模式不允许组件出现故障，而很多现代的系统架构则设计为可以忍受少许组件故障。这样在失去可用性的时候还能存活下来——不管是由于偶然的系统崩溃还是故意的拒绝服务攻击。通过有意设计——持续承受故障，整个系统在可用性上具有高度的弹性。设计者会评估系统单点故障或沦陷的情况来了解系统作为整体的可存活性。
组件故障设计只能用于可用性丢失，不能应对组件遭受攻击时的沦陷，因此设计者也需要考虑组件的可信性。无论是在CNE还是CNA中，单个组件都能持续运行，但我们不应认为它们会正确实现应有的功能。防御型系统设计允许管理员有选择地改变系统中组件的可信状态，在一些设计中这一点可以通过基础设施控制如停用服务账号或进行网络隔离实现，其他系统则要求应用层控制以实现必要粒度的控制。
4.1.3.1 横向移动
很多攻击者使用攻陷的系统作为立足点，扩大在系统内的可访问范围，或者选择更脆弱的目标。除了能够优雅地从入侵中恢复过来，可存活系统在设计时也要考虑到一开始的系统沦陷。水平移动暗示了设计者要仔细审查系统内的信任边界，组件间的接口应只有极少数能给予完全的信任。缓解水平移动不仅要了解接口组件用于做什么，还要清楚地理解它能做什么。
评估水平移动时，设计者要考虑正常情况下彼此不会对接但也不被阻止的组件。在主机托管环境中，邻近的系统经常会遇到这个问题。 即便它们不是被设计作为接口，毗邻系统间默许的信任也可以让攻击者建立直接连接，或者通过认证或备份服务这样的公共设施建立连接。威胁情报能为此提供一种很好的洞见，帮助设计者优先采取补偿措施。
抵抗横向渗透可以从传统的系统加固和最小权限原则入手，以限制系统间的攻击面。然而，防御型体系还能通过日志和网络监控确保横向渗透的可见性。
系统切分的设计决策能极大的影响其可存活性，基本的耦合和聚合设计原则对系统抵抗横向移动有很大的影响。紧耦合的组件倾向于共享高度的信任，这有利于进行横向移动。考虑图11中所描述的设计情景，系统运行了两个软件服务，一组简化的设计方案平衡账户与服务器共享。配置A中服务是紧耦合的，通过操作系统和服务账户共享信任。当攻击者已经控制了其他服务时，服务本身是对抗攻击的唯一边界。另一（极端）方面，配置D使用了单独的账户和服务器，攻击者（横向渗透）必须拿下其他账户和服务器才行。
图11 不同组件分割方案中的攻击面比较
通过分析一个攻击面该如何防御以及能防御到何种程度，有助于设计帮助者做出系统配置方面的明智决定。设计者考虑了如何提供可见性和可存活性后，能恰当的分割系统，并判定对单个组件能信任到何种程度。设计者会对系统面临的威胁、横向移动的威胁情报及系统的可管理性约束进行加权，在大多数设计决策中这些权衡会被纳入整体考虑中，计算它们会对系统功能、安全及运营成本造成的影响。
4.2 构建防御型系统
开发人员、工程师及测试人员负责整合并实现防御方法，开发使用设计者的威胁分析和防御者的威胁情报可以正确地实现控制，而测试人员则能基于真实世界的攻击给验证方法划分优先级。
开发者和测试人员同样必须知道系统中有哪些可用的安全设施和集成服务。重用已有的实践能减少实现的工作量，团队能集中精力在核心的系统功能上。在跨企业交互时，重用也能为管理员和防御者提供更好的持续性。
4.2.1 打造可见性
开发和工程师提升系统可见性最有效的做法是实现具有鲁棒性的应用日志记录，记录了任务相事件和安全相关事件。富安全事件不同于传统的允许/拒绝和成功/失败事件，提供了展示应用面对各种输入和条件时是如何反应的洞见。例如用户输入是SQL语句的参数时，它们应当被记录到日志中，引发的应用行为也要记录下来。这样防御者就能知道哪个注入尝试被成功拦截、哪个拦截失败。进一步说，随着时间推移我们可以根据事件日志的内容复盘系统活动。这意味着需要包含相关事件的必要属性，如事件ID、用户ID、及时间戳，防御者在必要的日志内容上能为开发者提供指导以有效地进行复盘（reconstruction）。
4.2.2 打造可管理性
要实现防御型体系中的可管理特性，开发者得明确定义和分离所有的管理员功能。区分管理员和普通终端用户的流量能让防御者更好地识别攻击和权限提升的尝试。同时管理接口的控制也会加强，如使用双因素认证和限制对可信网络的访问路径。
系统防御不仅是保护生产服务器，源代码、编译的可执行文件、配置文件及操作系统镜像都是需要保护的一部分。如果敌人将恶意软件嵌入到了源代码中，就可以有恃无恐地进行操作，恐怕大多数系统设计者都没有预料这一点。
因此，防御型体系的原则也运用到了源代码控制组件、系统搭建脚本及开发测试环境中。在将代码、配置及数据迁移到生产环境时同样需要密切关注，防止可能植入的恶意代码。这种可管理的形式必须对传递和验证部署到生产环境的组件时采取的种种步骤负责。
4.2.3 打造可存活性
打造生命力好的系统，首先要是识别重要数据、功能及服务，通常我们将其视作威胁分析的一部分。基于此，开发团队应用恰当的实现模式和原则，如冗余、封装、解耦来确保系统在单个组件故障时仍能继续运行。即便在入侵分析和恢复期间关键组件不可用，这样的系统仍能以一种得体的方式继续使用。
开发人员会仔细检查内部的可信边界，看是否存在横向移动的机会。很少有接口要求涉及的组件彼此完全信任，因此开发者会定义接口信任的用途和关于该用途的约束。举例来说，相比数据库服务器完全信任Web服务器，数据库管理系统则信任Web服务器的服务账户，允许在给定的数据库实例中查询特定的表。
测试对于系统的可存活性而言贡献极大，相比防御型系统中的其他特性都大。根据大多数系统的可存活性要求，测试人员会验证系统是否能从故障中恢复过来，或是在组件故障时是否能提供可接受功能。测试人员还会验证系统在线时防御者能执行哪些必要的入侵分析，例如收集取证的系统镜像、提取文件和备份、恢复系统日志的详情等。测试还能确认系统在未中断的情况下将组件放回到线上的能力。
测试对于理解系统在遭受攻击时的表现机器重要。由于防御型体系是一个整体，其设计也必须要使用可用的威胁情报。测试计划会结合系统威胁分析及威胁情报，并模拟系统会面临的攻击。这些场景能初次的攻击尝试和系统内的横向移动，目的是测试系统的主动防御能力。测试不仅是要看系统加固得有多好，还要看可见性、存活性和可管理性如何。测试并不能证明系统是安全的，但可以验证主动防御的控制机制。
4.3 运行防御型系统
系统运行期间，操作员和管理员负责维护其完整性，他们有着系统方面的第一手经验，处于协助防御者侦查、分析的最有利位置。在确认系统沦陷之前，初次的检测告警有助于进一步的分析，管理员在系统方面的知识可以帮助防御者更好的理解配置及系统中的”正常”行为，以确认哪个组件可能已经被攻陷。在这个意义上，系统编目、设计及配置都是可见性的一种形式，在快速分析潜在被成功入侵的组件时是至关重要的。
管理员同样还要负责系统的漏洞管理，一些活动如打补丁可能基于系统设计会自动化实现。然而在大多数系统中，有些软件需要手工管理，这要求管理员按时对软件升级和打补丁，这还要求他们有一个流程，验证引入到系统中的可执行文件的可靠性。代码签名是管理员验证可执行文件的常见方法，然而当分发的代码没有签名时还有必要采取其他的措施。对可执行文件的验证（普遍）适用于商业、开源及定制软件，它们无一例外地呈现了针对系统的攻击向量，尽管缓解的方法可能不尽相同。
最后，基于防御型体系的系统管理员必须遵循系统设计时定义的管理路径，偏离这些路径的软件接口或认证机制都有可能触发误报。
4.4 保卫防御型系统
防御型系统的实际设计特性由对敌人的了解及主动防御的需求驱动，防御者在这一体系中的最大贡献是威胁情报。通过分享从网络威胁中获取的情报，防御者帮助组织在选择和实施安全控制时做出实际的选择，使得团队能致力于实现最有效的控制。强大的情报管理程序让防御者能合计TTPs、敌人目标并共享给设计者和开发者。更重要的是，具备高级情报分析能力的组织能意识到TTP、敌人目标的改变及新对手的出现，这些改变会导致基础设施及防御型体系设计决策的改变。
防御者从内容和有利位置两方面沟通他们的可见性需求，如可以读取历史日志分析入侵意图。这对其他系统层的相关活动如括网络、操作系统、平台及应用也是同样的。
防御者使用更好的可见性，根据其指标测试和将精确调节过的安全控制规则部署到系统上。历史数据能让他们找到新攻击和过去活动间的关联，揭露了敌人目标和活动的新变化。防御者也会根据历史数据测试检测和拦截规则提高规则的可靠性。防御型体系的可管理性让防御者可以快速、准确地将这些新规则部署到合适的控制机制上去。
防御者最重要的职责是入侵检测及响应，防御型体系为防御者提供了更深层的对系统的认知，提升了他们入侵分析和响应的能力。这让对系统在线分析及缩短线下取证分析的时间成为可能。例如，能够快速获取并通过网络传输取证镜像，而不是花几小时或几天时间来安装代理软件。此外，做了存活性设计的系统在入侵分析和恢复期间能持续提供服务，最小化对业务及终端用户使用的影响。
5. 防御型企业
单个系统无法保证自己的安全，当组织中有大量系统时IDD是最有效的，并通过在业内共享情报得到加强。同样，防御型体系存在于他们所处环境的上下文中。防御型企业应用众多的可见性、可管理性及可存活性控制，使得防御型体系不同于传统的信息安全方法。防御型企业同时增大了防御者在他们的位置的可见性范围，减少了系统成本和复杂性。
正如打造单个系统一样，管理防御型企业始于威胁分析和威胁情报的交叉。威胁建模和分析能用于企业，也能以同样的方式用于单个系统，下表描述了如何将IDDIL/ATC方法论用到企业分析中去。
图12 企业级威胁分析
这个分析让安全设施投资以一种客观的方式，基于风险进行排序。攻击类型的新趋势能产生新的基础设施服务类型，它也能让企业不再坚持或下架那些基于过时价值观的已有安全服务，一些系统初始化部署时非常有效（也昂贵）的安全功能则会回落到商品状态（不再使用）。那些经常使用的安全控制应该纳入组织常规预算内。威胁情报也提醒基础设施部署的时机，例如一些无尽的敌人活动可用于确定基础设施的实现顺序。
正如系统中所有架构都必须对系统上下文负责，系统的安全控制同样必须对企业的防御性基础设施负责。使用可用的设施确保了跨系统的持续性控制的实现，并为防御者提供了企业的综合性可见性与可管理性。显然，通用基础设施能让大量系统立即从新的指标和产生的规则中受益，因为它们被部署到基础设施控制中。最高效的防御型企业能以最少的步骤将新发现的指标转变为更新的控制。这对于战术缓解来说尤其有用，特别像HeartBleed和Shellshock这种广为人知的漏洞。
防御型企业基础架构的价值很大程度上是由可见性的丰富度提供的。防御型企业保证了设计者、开发者及管理员能理解可用的基础设施和服务，它们的功能、接口以及如何定位系统以最好的利用它们。例如如果NIDS能以解密后的形式检查所有流量，系统便能从网络入侵检测系统中受益。一些系统设计能实现这一目标，设计者和开发必须了解系统所涉及的选择和权衡。一个安全设施及服务目录有助于促进他们理解和使用企业中的系统。
设计者、开发者及管理员使用相同的安全服务目录，它同样也被管理员用于评估哪种类型的控制最适合哪个指标。这种设计、构建、运行及防御阶段的持续性对于追踪安全控制有额外的好处。防御者在每次敌人活动中都会分析控制器是否检测到或拦截了入侵尝试，洞悉敌人行为，知道哪些控制是有效的，哪些控制是缺失的，让企业能评估他们的安全控制的价值并制定后续计划。结果就是企业层的可管理能力以部署新规则的速度、精度及防御者评估规则的效率来衡量。
广阔的可见性是防御型企业的基础，网络及系统活动的收集和保留为检测控制排序提供了必要的洞察力，并建立了从检测到拦截的业务案例。这种转变由对检测和拦截规则的可靠性激活，它们基于实践经验，将鲜活数据和历史数据对比评估。图13描述了一个灵活架构，它在收集和检测流的最高层建立主动拦截控制。检测规则可以内联部署或集中部署，取决于规则的复杂性及分布式传感器的能力。通过将拦截和检测规则放到相同的管道中并在现有的管道上部署新的检测和拦截模块，同样使得企业能提前适应TTP的改变。
图13 收集、检测及拦截设施的联合
企业可存活性作为一个整体使用了许多系统层的相同规则。聚合、耦合及分割对于设计时的考虑来说是至关重要的，横向移动引入了一定程度的共享风险，这可能是单个系统设计者没有想到的。企业系统的分割对应了业务结构最稳定的方面，减少了组织变更、合并、收购及拆分时的影响。分割技术同样用到了多种层面的技术，包括网络、虚拟化、操作系统、身份和访问管理及应用功能。
企业的整体安全性取决于它遭受攻击及应对攻击者的弹性。无论是对单起攻击的响应，还是随着敌人意图变化对基础设施进行投资都有可能将组织拖垮。防御型企业通过其威胁情报和威胁分析，打造了一个灵活的安全基础设施及可存活的IT基础设施。这让组织在设计、开发、运营及防御他们的系统和资产时能做出更好的决策。
