4月4日文 在探寻威胁模式的生命之旅中，人们正处于测试阶段。从分析需求、资产和威胁，到设计通用的可重用威胁模式，并在安全监控平台实现这种模式，人难免会犯错。

19世纪英国著名艺术家约翰·罗斯金曾说， “品质从来靠的就不是偶然机遇，唯有勤奋才能打造卓越品质”(Quality is never an accident，it is always the result of intelligent effort)。

因此，结构良好的精确测试过程对验证模式是否正确实现并确保有效解决攻击场景至关重要。

即使处于测试阶段，软件开发生命周期(Software Development Life Cycle，SDLC)的典型流程也能引领正确的方向。

软件测试方法同样适用于威胁模型以上这种验证攻击模式一旦实现，通常用于软件测试的黑盒测试及白盒测试两种互补的方法将如何应用到新实现的威胁模型之中?

白盒测试旨在验证威胁模式的逻辑，并确保实现(Implementation)与要求相符。如果正确进入设计阶段，构成该模式的不同组件应已被明确定义和记录。无论处于哪个阶段，都需要准备具体的输入和预期输出列表，以触发实现的各个部分。与任何软件一样，测试进度可以通过测试覆盖的代码百分比来量化，但这个过程可能会比较耗时。

在安全运维中心(SOC)，时间就是宝贵的资源，因此自动化是关键。所幸的是，在这个阶段，我们应该能拥有大量的历史数据，因为信息已经开始流入系统。因此，选择精确的样本至关重要，因为必须要具有良好的水平覆盖范围(例如测试组件的数量)和垂直覆盖范围(例如输入的种类)。可以借助测试组件映射每个选定的样本使逻辑验证和威胁模式逻辑有效。此外，为了确保输出仍与要求一致，变化之后，可以将相同的样本重新注入平台。

相反，黑盒测试检验的是威胁模式的功能，而无需仔细检查逻辑。

在这个阶段，建议从攻击场景(最初在分析阶段详细阐述的)开始，并确定攻击者可能会利用的方法。许多组织机构发现建立或参与到“红队”中(扮演攻击者的角色)是有益的，蓝队通过确保实现的威胁模式防御，并按预期行事。演习最后，两队会面审查结果，并罗列所有当前未被实现和需进一步审查的威胁模式而检测的所有情形。

安全运维中心除了惧怕攻击者，还应减少信噪比留下的疑问就是，如何根据测试结果衡量模式的有效性。最简单的方式是评估误报和漏报率。这两个参数便于理解威胁模式基于漏报率的有效性，以及该模式能根据误报率产生的潜在“噪声”。

每个安全运维中心目前为止应该学到了一个非常重要的教训：最危险的敌人可能不是隐蔽的攻击者，而是误报量淹没了分析师，阻止其响应事关重大的安全问题。在保护组织机构之前必须减少信噪比。

此流程结束时，企业必须着手从根本上分析识别到的每个问题，但要注意简单对实现进行更改，要是最终迷途未返，那就太可惜了。

接触代码之前，企业应从需求分析结果入手思考：是否完全错过了攻击场景?是不是存在没有考虑到的数据源?是不是实现过程出了差错?借助简单的清单进入该阶段能够减少或者杜绝对其它威胁模式造成负面影响。

但需要注意的是，要意识到所做的工作可能会在短时间内过时，也就是说，可能会出现新的测试威胁模式和攻击场景，当然，企业对策也在不断变化。