2019测试指南-安全测试数据分析和报告

2019独角兽企业重金招聘Python工程师标准>>>

安全测试指标和度量
的目标定义安全测试指标和度量的目标是将安全测试数据用于风险分析和管理流程的先决条件。例如，诸如安全测试中发现的漏洞总数之类的度量可能会量化应用程序的安全状态。这些测量还有助于确定软件安全测试的安全目标。例如，在将应用程序部署到生产环境之前，将漏洞数量减少到可接受的数量（最小值）。

另一个可管理的目标可能是将应用程序安全状况与基准进行比较，以评估应用程序安全流程的改进。例如，安全度量基准可能包含仅使用渗透测试进行测试的应用程序。从编码期间进行安全测试的应用程序获得的安全数据与基线相比应显示出改进（例如，漏洞数量减少）。

在传统的软件测试中，软件缺陷的数量（例如应用程序中发现的错误）可以提供软件质量的测量。同样，安全测试可以提供软件安全性的衡量标准。从缺陷管理和报告的角度来看，软件质量和安全测试可以对根本原因和缺陷修复工作使用类似的分类。从根本原因的角度来看，安全缺陷可能是由于设计错误（例如，安全漏洞）或由于编码错误（例如，安全漏洞）造成的。从修复缺陷所需的工作的角度来看，安全性和质量缺陷都可以根据开发人员的小时数来衡量，以实现修复，修复所需的工具和资源以及实施修复的成本。

与质量数据相比，安全测试数据的特征是对威胁，漏洞暴露以及漏洞确定风险可能带来的潜在影响进行分类。测试安全性应用程序包括管理技术风险以确保应用程序对策达到可接受的水平。因此，安全测试数据需要支持SDLC期间关键检查点的安全风险策略。例如，源代码分析中的漏洞代表了风险的初始衡量标准。可以通过确定暴露和可能性因素以及通过渗透测试验证漏洞来计算漏洞的风险度量（例如，高，中，低）。

在评估应用程序的安全状态时，重要的是要考虑某些因素，例如正在开发的应用程序的大小。统计数据证明，应用程序大小与测试期间应用程序中发现的问题数量有关。应用程序大小的一种度量是应用程序的代码行数（LOC）。通常，软件质量缺陷的范围是每千行新代码和更改代码中大约7到10个缺陷[21]。由于单独进行一次测试，测试可以将总体数量减少约25％，因此对于较大尺寸的应用程序而言，与较小尺寸的应用程序相比，测试更为合理。

当在SDLC的几个阶段中进行安全测试时，测试数据可以证明安全测试在引入漏洞后立即检测漏洞的能力。测试数据还可以通过在SDLC的不同检查点实施对策来证明消除漏洞的有效性。此类型的度量也被定义为“包含度量”，并提供在开发过程的每个阶段执行的安全评估在每个阶段内维护安全性的能力的度量。这些遏制指标也是降低修复漏洞成本的关键因素。在SDLC的相同阶段处理漏洞比在它们被发现时更便宜，而不是稍后在另一个阶段修复它们。

安全测试指标可以在与有形和定时目标相关联时支持安全风险，成本和缺陷管理分析，例如：

• 将漏洞总数减少30％
• 在特定截止日期前解决安全问题（例如，在测试版发布之前）

安全测试数据可以是绝对的，例如在手动代码审查期间检测到的漏洞数量，以及比较，例如与渗透测试相比在代码审查中检测到的漏洞数量。要回答有关安全过程质量的问题，确定可接受和良好的基线非常重要。

安全测试数据还可以支持安全分析的特定目标。这些对象可以符合安全法规和信息安全标准，安全流程管理，安全根本原因和流程改进的识别以及安全成本效益分析。

报告安全测试数据时，必须提供支持分析的指标。分析的范围是对测试数据的解释，以找到有关正在生产的软件的安全性以及该过程的有效性的线索。

安全测试数据支持的线索的一些示例可以是：

• 漏洞是否会降低到可接受的发布水平？
• 该产品的安全质量与同类软件产品相比如何？
• 是否满足所有安全测试要求？
• 安全问题的主要根源是什么？
• 与安全漏洞相比，安全漏洞有多少？
• 哪种安全活动最有效地发现漏洞？
• 哪个团队在修复安全缺陷和漏洞方面更有效率？
• 哪些百分比的总体漏洞是高风险？
• 哪些工具在检测安全漏洞方面最有效？
• 哪种安全测试最有效地发现漏洞（例如，白盒与黑盒）测试？
• 安全代码审查期间发现了多少安全问题？
• 在安全设计审核期间发现了多少安全问题？

为了使用测试数据做出合理的判断，重要的是要充分了解测试过程以及测试工具。应采用工具分类法来决定使用哪些安全工具。安全工具可以被认定为善于发现针对不同工件的常见已知漏洞。

问题是未测试未知的安全问题。安全测试没有问题这一事实并不意味着软件或应用程序是好的。一些研究[22]已经证明，工具最多只能找到45％的总体漏洞。

即使是最复杂的自动化工具也不适合经验丰富的安全测试人员。仅依靠自动化工具的成功测试结果将给安全从业者带来虚假的安全感。通常，安全测试人员使用安全测试方法和测试工具的经验越多，安全测试和分析的结果就越好。重要的是，对安全测试工具进行投资的管理人员也应考虑投资雇用熟练的人力资源以及安全测试培训。

报告要求
应用程序的安全状态可以从效果的角度来描述，例如漏洞的数量和漏洞的风险评级，以及从原因或来源的角度来看，例如编码错误，架构缺陷和配置问题。

漏洞可以根据不同的标准进行分类。最常用的漏洞严重性度量标准是事件响应和安全团队论坛（FIRST）常见漏洞评分系统（CVSS），该系统目前处于发布版本2，版本3即将发布。

报告安全测试数据时，最佳做法是包含以下信息：

• 按类型对每个漏洞进行分类
• 该问题所面临的安全威胁
• 安全问题的根本原因（例如，安全漏洞，安全漏洞）
• 用于发现问题的测试技术
• 漏洞的修复（例如，对策）
• 漏洞的严重等级（高，中，低和/或CVSS评分）

通过描述安全威胁是什么，可以了解缓解控制是否以及为何在减轻威胁方面无效。

报告问题的根本原因有助于确定需要修复的问题。例如，在白盒测试的情况下，漏洞的软件安全根本原因将是违规的源代码。

报告问题后，向软件开发人员提供有关如何重新测试和查找漏洞的指导也很重要。这可能涉及使用白盒测试技术（例如，使用静态代码分析器进行安全代码审查）来查找代码是否易受攻击。如果可以通过黑盒技术（渗透测试）找到漏洞，则测试报告还需要提供有关如何验证漏洞暴露给前端（例如，客户端）的信息。

有关如何修复漏洞的信息应该足够详细，以便开发人员实施修复。它应该提供安全的编码示例，配置更改，并提供足够的参考。

最后，严重等级有助于计算风险等级，并有助于确定补救措施的优先顺序。通常，为漏洞分配风险评级涉及基于影响和暴露等因素的外部风险分析。

业务案例
为使安全测试指标有用，他们需要为组织的安全测试数据利益相关者提供价值。利益相关者可以包括项目经理，开发人员，信息安全办公室，审计员和首席信息官。价值可以是每个项目利益相关者在角色和责任方面的业务案例。

软件开发人员查看安全测试数据，以显示软件编码更安全，更有效。这使他们能够使用源代码分析工具以及遵循安全编码标准和参加软件安全培训。

项目经理根据项目计划查找允许他们成功管理和利用安全测试活动和资源的数据。对于项目经理而言，安全测试数据可以显示项目按计划进行，并在交付日期的目标上移动，并且在测试期间变得更好。

如果该计划来自信息安全官（ISO），则安全测试数据还有助于安全测试的业务案例。例如，它可以提供证据表明SDLC期间的安全测试不会影响项目交付，而是减少了在生产后期解决漏洞所需的总体工作量。

对于合规性审计人员，安全测试指标提供了一定程度的软件安全保障，并确保通过组织内的安全审查流程解决安全标准合规性问题。

最后，负责预算需要在安全资源中分配的首席信息官（CIO）和首席信息安全官（CISO）寻求从安全测试数据中推导出成本效益分析。这使他们能够就投资的安全活动和工具做出明智的决策。支持此类分析的指标之一是安全性投资回报率（ROI）[23]。要从安全测试数据中获取此类指标，重要的是量化由于漏洞暴露导致的风险与安全测试在降低安全风险方面的有效性之间的差异，并将此差距与安全测试活动的成本相关联或采用的测试工具。

转载于:https://my.oschina.net/u/3447023/blog/3017485