软件安全测试

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

1 级安全测试

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

QA 团队不仅开展功能测试,还执行基础对抗性测试并搜寻简单的边缘情况和便捷条件,无需具备攻击技能。当 QA 了解利用可接受的新数据具有助力通过标准功能测试的价值时,就会慢慢开始从攻击者的角度思考问题。讨论边界值测试时,自然会设想攻击者故意搜寻边缘的情况。密码反复输入错误会怎样?

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

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

2 级安全测试

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

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

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

SSG 定期与 QA 部门共享安全审查的结果。使用安全结果来启发和改善具体的测试模式是一套强大的机制,能够促成实现更优秀的安全测试。CI/CD 跨部门团队集成测试的方式简化了这项工作。时间一长,QA 工程师就会培养安全心态,并且这项活动会得益于以工程设计为中心的高度专业化 QA 职能。

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

将安全测试作为自动回归测试的一部分,与功能测试一起运行。事实上,两者采用同一自动化框架,并且安全测试是理性测试的一部分。在生命周期早期确定的滥用案例或功能测试的创造性改进衍生的测试均可以驱动安全测试。

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

测试自动化工程师或敏捷团队成员可以为组织的 API 定制模糊测试框架。他们可以从头开始或使用现有的模糊测试工具包,但定制不仅仅是创建自定义协议描述或文件格式模板。模糊测试框架本身已了解它所调用的应用程序接口。针对特定应用明确开发的测试线束成为集成模糊测试的好地方。

3 级安全测试

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

测试人员利用架构分析结果指导自己的工作。如果架构分析得出结论:例如,“系统的安全性取决于事务的原子性,而不是因为中途中断”,那么破碎的事务将成为对抗性测试的主要目标。此类对抗性测试可以根据风险状况进行开发,将高风险的缺陷列入名单之首。

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

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

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

测试开始基于滥用案例纳入测试案例(参见 [AM2.1 构建与潜在攻击者相关的攻击模式和滥用案例]),而且测试人员不仅要验证功能,还要考虑攻击者的角度。例如,一种办法是系统地尝试复制组织以往发生的事件。安全政策、攻击情报和操纵标准也能驱动创建基于攻击者的角度的滥用和误用案例。这样就把测试的方向从测试功能转向尝试破坏软件。