安全响应管理:不完美世界中的风险、成本和最佳实践
由David Reyna.
确保我们的产品安全是生存的要求，需要保持警惕，以尽可能及时的方式寻找、应用和分发工作补丁给我们的客户。虽然人们对设备漏洞的认识有所提高，但经常缺少对管理安全响应过程本身的认识。
社区安全漏洞数据可用，但信息在质量，完整性和适用性方面有很大差异。管理安全缺陷可能是非常效率的，从而高成本和延迟组织和客户。
在这个博客中，我会讨论：
- 安全响应管理资源和挑战
- 必要的成本，不必要的成本
- 就最佳做法提供意见
- 新的SRTool(安全响应工具)是风河公司解决成本和最佳实践的开源答案
安全响应管理资源和挑战
安全响应管理是当今产品开发过程中必不可少的一部分。有许多可用的资源;然而，仍有一些挑战需要克服。
上游CVE来源
CVES（常见漏洞枚举）是社区跟踪安全漏洞的枚举。CVES列表由仲裁公司管理。CVES通过国家标准和技术研究所（NIST）管理的美国国家漏洞数据库（NVD）。这些努力由美国 - 证书在美国国土安全部的网络安全和通信办公室赞助。这些是主要的社区CVE数据库，两者都可供公众使用，并且可以自由使用。
在实践中，Mitre公布分配的CVE编号，但只包括基本数据。NIST收集并发布详细的CVE信息，但它只包括公共CVE。此外，NVD中的状态更新可能明显滞后于MITRE。
许多单独的供应商和维护人员跟踪和共享与他们的产品相关的cve，但是访问和覆盖在不同的站点之间差异很大，这使得实现编程访问工具非常困难。相反，CVE聚合器试图为CVE源提供一个公共接口，但是聚合器内容在覆盖范围、可访问性和质量上也各不相同。
最后，还有许多公共和私人的邮件列表、网站和论坛。这些是主动发现和跟踪问题的必要部分，但它们需要持续跟踪和交互才能有效使用。
上游CVE质量和完整性
虽然cve试图尽可能准确，但在这一目标上有许多差距:
- cve可能只有一个简短或不完整的描述
- CIVE可能缺少受影响的产品列表（CPE），具有间隙，具有错误，或在版本编号中具有意外偏差
- CVE内容可能会引起误解，当它实际上影响开发人员系统中的另一个包时，它会提到一个包
- cve可能有很少的、不准确的或缺少的内容链接(讨论、复制器、补丁)
- 随着发现和共享的新信息，CVE状态不断更改
- 维护者，思维和NIST之间可能存在延迟内容更新
最近创建的cve(在最近几个月)特别容易出现上述问题，但不幸的是，这些通常都是组织在其待发布版本中必须处理的所有问题。
每个CVE的质量和完整性肯定会随着时间的推移而提高，但是捕获和重新评估每个CVE的每个改进版本的代价是昂贵的。
对于用于处理和检查CVE漏洞的工具，它们还必须考虑上述所有限制。工具必须:
- 灵活处理漏洞信息
- 区分强大和弱数据
- 对于不完美的数据流，设置适当的期望
- 在评估过程中适当地包括人类投入
上游CVE体积
每月现在有超过一千个新的CVE，并且卷只会增加。
每个新的CVE都必须进行评估。随着cve数量的增加以及为了弥补上游信息的质量限制而需要的评估时间的增加，评估成本持续上升。
尽管评估成本高，但评估cve是必要的。减少评估时间和成本——以及丢失或错误地对漏洞进行分类的风险——代价将更大，会影响产品完整性、发布时间和客户信任。
安全响应管理过程挑战
安全响应的内部管理有其自身的需求和问题。
数据访问性：文档通常不会以可访问方式汇总。它可以跨多个组分布，存储在多个位置，仅存在于电子邮件中，并且/或可以仅在组织的缺陷和敏捷工具中部分捕获。如果系统有机内置，可能基于为以前的CVE卷和团队人员配置设计的流程，这是真的。
数据聚合：还有一个有效地查找和分享CVE状态的问题，涉及一般的缺陷，产品，发布和计划。没有聚合，它可能需要大量时间来不断纪念客户，管理，公开披露和法律遵从性。
供应商:一些公司将此过程转给外部供应商。这些供应商可以提供缺少的专业知识和资源，但是这种传递可以减少客户响应时间，而且这种外部支持可能非常昂贵。
扫描工具：有许多工具（商业和开源）可以提供CVE分析和支持。一些工具专注于运行系统（例如Nesus），以及一些DO源或构建时间分析（例如Blackduck，Yocto Project“CVE-Check”）。所有此类工具在捕获产品问题并提供保护性止回阀时可能非常有价值。然而，所有内容都有内置的限制，因为他们依靠可用的CVE信息（加上或减去秘密酱），因此容易受到所有上述问题的影响，从而减少结果的质量或提供需要继续评估的模糊结果。此外，这些系统都没有满足组织的较大过程。
缺陷系统:一个组织的缺陷跟踪系统通常不是管理安全响应的最佳场所。漏洞通常跨多个产品，可能对不同版本有不同的影响和解决方案。此外，这种系统很难或不可能正确地存储被禁止的信息，特别是考虑到每个保留的CVE可能需要不同的许可工程师访问列表。
安全管理成本:必要与不必要
一些任务只是做生意的成本，虽然可能是复杂的，但绝不是越来越多的理解和执行。
必要费用的例子：
- 跟踪上游cf
- 创建和修复缺陷
- 为客户提供更新，管理
- 为客户提供补丁
许多其他潜在成本没有得到很好的理解或管理。虽然公司可能只是简单地吸收了过去较低的成本，但如今较高的CVE数量和复杂性的成本已经或将成为难以承受的巨大成本。
不必要成本的例子：
- 重复手动轮询上游数据，初始报告和所有更新
- 重复手动轮询缺陷状态
- 人工分析每个CVE的漏洞状态，跨产品
- 手动重新评估每个更新的CVE的漏洞状态
- 手动跟踪和共享补丁、报告、文档等等
- 手动恢复客户的状态信息，管理
- 手动跟踪禁运数据，需要知道的信息，以及“谁知道什么时候”的合规
- 为组织的公共数据库手动重新打包数据
最佳实践和解决方案
这里列出了一些可以帮助解决上述问题的最佳实践。
- 尽可能多地自动化
- CVE数据收集
- CVE更新轮询，带有过滤的更改通知
- 缺陷更新轮询，带有过滤的变更通知
- 缺陷创建，填充，更新
- 报告管理和客户的工具
- 历史记录和审计跟踪
- 使用多个来源
- MITRE/NIST:这是开始的地方，但是它不是，也永远不会完成
- 替代来源有时可以提供缺失或不完整信息的线索，并且可能通常是更新的
- 汇总数据
- 维护安全管理的中央特定数据库
- 在中心位置维护文件、补丁、链接等，并在中心数据库中提供链接
- 灵活处理数据。不要认为它是决定性的。
- 使用CVE数据作为咨询，而不是假设它永远是最终的
- 不要专注于分析期间版本编号的小细节，以保持小意外差异导致大隐藏的未命中
- 让人们更容易发现和检查歧义
- 允许工程师添加注释，甚至覆盖CVE值，以便他们可以添加智能数据和纠正上游错误
- 提供工具，以帮助高成本的CVE流入分流
- 提供一个简单的界面来浏览和评估传入的cve
- 提供启发式和帮助工具，以帮助管理CVE内容中的差距
- 分析所有可用数据，帮助cve与产品/包装匹配
- 通过简单的关键字或CPE命中逐组进行分类CVES，例如，删除明显的漏洞和非漏洞，因此可以花在真正需要调查的CVE上
最终，将人们花在实际问题上，而不是这个过程。
SRTool(安全响应工具)介绍
为了帮助减轻不必要的成本并实现最佳实践，Wind River开发了一个名为SRTool的新工具，并与Yocto项目和一般开源社区共享。
以下是一些特性以及它们如何实现最佳实践:
- 基于中央的基于SQL的数据库聚合了数据
- 由Cron作业触发的许多备用源收集CVE批量和增量数据的后端脚本
- 基于浏览器的GUI前端允许一般开发人员和管理人员轻松地遍历数据、添加数据并生成视图、报告和导出(如果授权)
- 一般数据关系模型管理信息。该模型包括CVES，“漏洞”的记录，以跟踪产品的高级问题，“调查”跟踪特定版本的漏洞，并将“缺陷”映射到组织的缺陷系统。每个记录都支持特定的注释，附件，可选访问列表和更改审核戳
- 能够将内容和关键字添加到记录中以捕获本地知识，以及在上游不正确时清除覆盖CVE值的能力
- 模块化设计，使其易于扩展到（a）新的CVE数据源，（b）本地缺陷和/或敏捷系统，以及（c）其他网站流程
- 用于Trijing和管理传入CVES的增强工作页
从多年的CVE与包的匹配中获得了丰富的知识，从而形成了一个“for”和“against”关键字表，可以帮助指导分类工程师决定输入的CVE是漏洞、非漏洞还是需要调查。
这个特性特别有价值。它通过结合启发式和获得的知识来提供缺失的指导，明确地解决了不完整的cve问题。
结论
有很大的安全漏洞信息可用。问题成为该信息的质量，数量，及时性和成本效益管理。凭借知识，意识，适应性和自动化，我们可以管理增加的洪水信息。
风河公司的新型SRTool是一种很有价值的工具，可以帮助管理cve，降低过程中的成本。我们邀请开源社区使用这个新工具，并加入我们，使它更有帮助。
使用这些链接来学习更多关于这个主题和关于在你自己的项目中使用SRTool:
- 参见Wind River的嵌入式Linux会议报告:
- https://sched.co/HOLr
- 联系人:
- https://lists.yoctoproject.org/listinfo/yocto-security
- david.reyna@windriver.com(SRTool维护者)
获取我们的RSS源