软件安全测试

安全测试实践涉及发布前测试,包括将安全举措整合到标准质量保证流程当中。该实践包括使用黑盒安全工具(包括模糊测试)作为 QA 的冒烟测试、风险驱动型白盒测试、攻击模型的应用,以及代码覆盖率分析。安全测试着重测量构造中的安全缺陷。

1 级安全测试

[ST1.1: 100] 确保 QA 支持边缘/边界值条件测试。

QA 不仅开展功能测试,还执行基础对抗性测试并搜寻简单的边缘情况和便捷条件,无需具备特定的攻击技能。当 QA 了解利用预期的新数据具有助力通过标准功能测试的价值时,就会慢慢开始从攻击者的角度思考问题。关于边界值测试的讨论自然会导致攻击者故意探究边缘(例如,确定某人为什么会反复输入错误密码)。

[ST1.3: 87] 推动进行安全需求和安全功能测试。

QA 旨在从需求和安全功能中衍生出宣告式安全机制。例如,测试可以尝试以非特权用户的身份访问管理功能,或者验证用户账户在多次尝试验证失败后是否遭到锁定。大多数情况下,安全功能可以采用类似于其他软件功能的方式进行测试;基于账户锁定、事务限制、权限等要求的安全机制也会利用预期和非预期的新数据接受测试。软件安全功能不是安全软件,但是测试安全特性是一种简单的入门方法。新的软件架构和部署模型(如,加入云)可能需要新的测试方法。

2 级安全测试

[ST2.1: 32] 在 QA 流程集成了黑盒安全工具。

该组织在 QA 流程中使用一个或多个黑盒安全测试工具。此类工具的价值在于它们概括了攻击者的视角(尽管较为宽泛);诸如 IBM Security AppScan 或 Fortify WebInspect 等工具与网络应用程序相关,而 Prowler 则与 AWS 部署相关。有时,其他群体可能会与 SSG 合作应用这些工具。例如,一个测试团队尽管能够运行该工具,但却求助 SSG 解读测试结果。凭借在敏捷开发方案中集成测试的方式,工程部可以将黑盒工具关联到工具链中,也可以直接使用。无论是谁运行黑盒工具,都应当将测试正确集成到 SSDL 的 QA 环节。

[ST2.4: 15] 与 QA 共享安全结果。

SSG 或其他拥有安全测试数据的人员会与负责测试的人员例行共享安全审查结果。使用测试结果作为依据,开展关于常见攻击模式或代码漏洞的潜在原因的对话,可以帮助 QA 概括信息,进而开发新的测试方法。CI/CD 跨部门团队集成测试的方式简化了这项工作。时间一长,QA 就习得了安全思维,并且组织能够受益于自身能力的增强,可以针对组织的代码度身定制安全测试。

[ST2.5: 9] 在 QA 自动化中纳入安全测试。

安全测试包含在自动化框架中,并与其他 QA 测试一起运行。虽然许多小组都会人工触发这些测试,但这些测试很可能包含在现代工具链的管道中,并通过自动化触发。安全测试可能衍生自生命周期早期识别的滥用案例,产生于功能测试、开发人员测试、安全特性测试的创造性调整,甚至始于渗透测试人员提供的关于如何重现问题的指南。

[ST2.6: 9] 执行专门为应用 API 定制的模糊测试。

针对组织的关键 API 运行定制的模糊框架也是 QA 的一项工作。他们可以从头开始运行,也可以使用现有的模糊工具包,但是常常需要超出创建自定义协议描述或文件格式模板进行必要的定制,才能让模糊框架从内部了解其调用的应用程序接口。针对特定应用明确开发的测试线束成为集成模糊测试的好地方。

3 级安全测试

[ST3.3: 2] 通过风险分析结果驱动测试。

测试人员使用架构分析结果(参见 [AA 2.1 定义和使用 AA 流程])来指导他们的工作。如果 AA 判定:例如,“系统的安全性取决于事务的原子性,而不是因为中途中断”,那么破碎的事务将成为对抗性测试的主要目标。此类对抗性测试可以根据风险状况进行开发,将高风险的缺陷列入名单之首。

[ST3.4: 1] 运用覆盖率分析。

测试人员测量其安全测试的代码覆盖率 (参见 [ST2.5 在 QA 自动化中纳入安全测试]),以确定未执行的代码。代码覆盖率分析反过来推动了安全测试深度的增加。标准型黑盒测试工具达到的覆盖率极低,使得大部分待测软件都未被发现,因而不是测试最佳实践。采用标准测量指标(如功能覆盖率、路径覆盖率或多个条件覆盖率)可以简化覆盖率分析。

[ST3.5: 2] 开始构建并应用对抗性安全测试(滥用案例)。

测试开始基于滥用案例纳入测试案例(参见 [AM2.1 构建与潜在攻击者相关的攻击模式和滥用案例]),因为测试人员不仅要验证功能,还要考虑攻击者的角度。例如,一种办法是系统地尝试复制组织以往发生的事件。基于攻击者视角的滥用和误用案例也可以从安全政策、攻击情报、标准和组织的重大攻击列表中派生出来(参见 [AM2.5 编制并维护最可能发生的攻击列表])。这项工作把测试的方向从测试功能转向了尝试破坏软件。