软件安全测试概述

2021-01-14 10:00:00
BSIMM
转贴:
BSIMM
289
摘要:安全测试实践一般情况下,会涉及到发布前测试,包括将安全集成到标准质量保证流程当中。为什么配置中要包含风险驱动这一条件?


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

安全测试:第 1 级

[ST1.1: 104] 确保 QA 执行边缘/边界值条件测试。


除功能测试外,QA 团队还需要开展基本对抗测试以及探查简单边缘情况和边界条件,这方面不需要特殊的攻击者技能。当 QA 理解了使用可接受的信息输入来超越标准功能测试的价值后,他们就可以逐渐开始像对手那样思考问题。


关于边界值测试的讨论会很自然地引导人们留意这一观念:攻击者故意探查边缘(例如,当某人一次又一次地输入错误密码时,将会发生什么情况)。

[ST1.3: 89] 推动结合安全性要求和安全性功能的测试。


QA 可以利用来自要求和安全功能的测试来对抗所声明的安全机制。例如,测试人员可以尝试以非特权用户的身份来访问管理功能,或者验证用户账户是否会在若干次身份验证失败后被锁定。


大多数情况下,安全功能可以像其他软件功能那样进行测试;同时,也可以使用衍生自要求的正常输入和异常输入对基于要求的安全性机制进行测试,这样的安全性机制包括账户锁定、交易限制、访问权限等等。


软件安全功能不是安全软件,但是测试安全特性是一种简单的入门方法。一些新型软件架构和部署模式(例如容器和云基础架构编排)可能需要新型测试方法。

安全测试:第 2 级

[ST2.1: 42] 整合黑盒安全性工具到QA流程中。


在 QA 流程中,企业可以使用一个或多个黑盒安全测试工具。这些工具是有价值的,因为一般情况下,它们是基于攻击者的角度的。传统的动态分析扫描仪与 Web 应用程序相关,而云环境、容器、移动应用程序和嵌入式系统等也有相关工具。


某些情况下,其他团队可能会与 SSG 合作来使用这些工具。例如,测试团队可能会使用该工具,但需要 SSG 来帮助解释所得的结果。如果测试工作被集成到敏捷开发方法中,则黑盒工具也可能结合到工具链中、由基于云的工具链提供、或者直接被工程部门使用。无论谁在运行黑盒工具,测试工作都应适当地集成到 SSDL 的质量保证 (QA) 周期中,并且经常同时涵盖经过验证和未经验证的审查。

[ST2.4: 20] 与 QA 共享安全性检查结果。


SSG 或者使用安全测试数据的其他团队可以与负责 QA 的部门共享安全审查结果。若将测试结果作为对话基础来讨论常见攻击模式或者代码漏洞的根本原因,将有助于 QA 将该信息概括为新的测试方法。


选择利用诸如 GitHub 之类的软件管道平台或诸如 Atlassian 堆栈之类的 CI/CD 平台的企业,可以从 QA 自动接收各种测试结果中受益,这将有助于及时与利益相关者对话。


某些情况下,这些平台可以通过为开发人员生成变更请求单而将 QA 集成到自动修复工作流和报告中,从而减轻 QA 的工作负担。随着时间推移,QA 工程师将掌握安全性思维方式,企业将受益于为组织代码定制安全测试计划带来的能力的提升。

[ST2.5: 16] 把安全性测试纳入到 QA 自动化中。


安全性测试包含在自动化框架中,可以与其他 QA 测试同时进行。虽然很多团队手动触发这些测试,但在现代工具链中,这些测试是管道中的一部分,并自动触发。


安全性测试可以由软件生命周期早期阶段所发现的滥用案例来驱动(参见[AM2.1 构建与潜在攻击者有关的攻击模式和滥用案例]),或者由功能测试方面的创造性调整所获得的测试方法来推动,甚至由渗透测试人员提供的关于如何重现问题的指导来驱动。

[ST2.6: 13] 开展为应用 API 定制的模糊测试。


针对组织的关键 API 运行定制的模糊框架也是 QA 的一项工作。定制可从头开始,也可以采用现有的模糊工具包,但必要的定制工作不仅仅是创建自定义协议描述或文件格式模板,还包括让模糊测试框架本身能够理解其所调用的应用接口。明确针对特定应用程序开发的测试工具是整合模糊测试的理想情况。

安全测试:第 3 级

[ST3.3: 5] 推动结合风险分析的测试。


测试人员使用架构分析结果(请参阅 [AA 2.1 定义和使用 AA 流程])来指导他们的工作。例如,如果 AA 决定“系统的安全性取决于交易的原子性而不会在中间被打断”,那么,被中断的交易将成为对抗性测试的主要目标。企业可根据风险特征来设计此类对抗性测试,把高风险缺陷置于列表的最顶端。与 QA 共享安全测试结果(参见[ST 2.4 与 QA 共享安全性检查结果])有助于将测试的重点放在潜在的漏洞区域上,从而帮助证明已识别出的高风险缺陷确实存在。

[ST3.4: 2] 利用(代码)覆盖分析。


测试人员评估其安全测试的代码覆盖情况(参见[ST2.5 把安全性测试纳入到 QA 自动化中])以便识别出未被执行的代码,然后调整自动化系统(参见[ST3.6 自动实施事件驱动的安全性测试])以逐步扩大覆盖范围。代码覆盖率分析反过来推动了安全测试深度的增加。标准问题的黑盒测试工具覆盖率极低,导致大部分被测试的软件未被覆盖,这不是一项良好的测试实践。使用函数 (function) 覆盖、行 (line) 覆盖或多条件覆盖等标准评估方法能够简化覆盖分析工作。

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


开始测试时,应当根据滥用案例整合测试用例(参见[AM2.1 构建与潜在攻击者有关的攻击模式和滥用案例]),而且测试人员不仅需要验证功能,而且还要从攻击者的角度去考虑问题。


实践的方法之一是系统性地尝试复现企业历史上发生的事件。从攻击者角度考虑的滥用和误用案例也可从安全策略、攻击情报、标准和最危险的N种攻击列表(参见[AM2.5 创建并维护最危险的N种攻击列表])中推导出来。这样测试工作的方向就从测试功能转向了尝试破坏软件。

[ST3.6: 0] 在自动化中实施事件驱动的安全性测试。


SSG 指导开展连续的、事件驱动的自动化应用安全测试。在 ALM 自动化中实施的事件驱动测试通常会使测试更接近测试要求的条件(无论是左移向设计还是右移向运维),在软件完成 ALM 流程期间,一有触发事件便重复测试,并确保在一组给定条件下执行正确的测试。这可能是对到达门控或检查点并触发时间点安全性测试的软件的替代或补充。


这种方法能否成功取决于广泛使用的传感器(例如,代理、机器人),这些传感器可监控工程流程、执行上下文规则,并为自动化提供遥测,从而在满足事件条件时启动指定测试。更成熟的配置还会包含风险驱动的条件。

发表评论
评论通过审核后显示。
联系我们
  • 联系人:郑女士
  • 联系方式: 13792883250
  • 地址:青岛开发区长江中路232号国贸中心C座