软件质量保障

目标

软件质量保障的目标是保障私人用户数据在其数据被处理，被存储，被传输的过程中的完整性，机密性是被保护的。质量评价测试也应该确认这个应用不能被攻击，破坏，被霸占，或者被拒绝服务式攻击搞瘫痪，在可接受的风险水平里。这表示可接受的风险水平和威胁模型场景被建立了，所以开发者和质量保障工程师知道该期待什么，为了什么工作。

影响的平台

所有平台

最佳实践

• 可获得的资源手段像：OWASP前10列表，或者第5章中描述的政策性顺从框架，和第7章中描述的威胁过程模型。这些实践将帮助识别设计参数，建立可测量的目标，并保证在系统的，全盘的，量化的样式里的安全测试过程。
• 有效的软件质量保证包括互为支撑的因素：过程，指标和自动化。
• 测试和量化应用安全表现的计划在质量保证过程中，仅仅类似任何其他系统功能。
• 将以下因素包含在你的测试计划里：
  • 政策审计框架需求
  • 安全测试方法，工具，训练，和资源分配的总览
  • 操作预算和行程考量
  • 选择一个首选漏洞得分系统（CVSS，OVAL等）和一个管理/跟踪系统（Bugzilla，一个第三方漏洞管理包或者服务等）
  • 创建和收集有用的质量指标将促进决策制定（例如，严重程度和分类的开放漏洞数量，基于时间的达到时间，紧密比率，总的测试范围等）
  • 识别测试活动，这会是自动化候选并且讨论该怎么做。
• 有一系列质量保障的入口条件，这标志了测试开始必须做的项目：
  • 政策审计认证需求
  • 可利用的威胁利用模型场景
  • 测试计划，资源列表和预算
  • 度量标准和漏洞计分系统选择
  • 一个组织意义上的认证，这将向质量保障组展示特定的设计评论，并保证和系统的安全参数保持和谐。
  • 一个完整的测试计划
• 质量保障出口标准应该包括证明应用安全集成性和敏捷性，包括：
  • 一个总结性报告，包括总结收集的度量的总结
  • 一个安全测试报告，描述应用与行政审计需求和威胁模型场景相比的运行情况，和与建立的安全基线的可靠性的对比
  • 没有高危安全漏洞（例如，一个简单的展现所有安全bug已经被解决和验证的列表）
  • 一个运用软件度量学去评估应用安全刚刚到达或者超过已有的基线的评估报告，所有的安全相关的设计目标已经被实现（就是去证明任务已经被很好地完成了）
    注意：理想化情况下，这个报告应该运用可视化的展现技术尽可能，比如通过图表，和其他一些方法去可视化地展示信息，所以这个数字很容易被理解，而且促进决策过程。

过程

描述

利用测试计划，测试结果和量化的数据去量化应用安全达到或者超过了政策审计和风险管理目标。

怎样去识别你是否易受攻击

工作进程结果的展现文化，有一个特别突出的特征。确保你看到了其中一些或者所有的这些操作在你的开发中。例如：

• 开发团队成员会定期更新他们的源代码
• 设计评论的合作和鼓励安全考量
• 质量保障过程包括安全评价的计划和测试时间，而不是事后才想起它们或者特设方式
• 安全相关的bug被特别跟踪，并已经建立了增长机制

怎样去保护你自己

• 使得“安全”成为工程师团队字典里的一个可操作性单词，鼓励训练机会，讨论，代码示例，和持续的兴趣。
• 选择并采用一个漏洞评分系统，比如CVSS（通用漏洞评分系统），OVAL系统，或其他类似的系统。或者至少确保安全相关的弱点有一些特殊的跟踪方法或标签。
• 确保类似“能够安全吗？”这样的问题在设计审计时被提出来
• 为安全相关的漏洞建立一个工作升级程序

度量标准

描述

质量保障组将要识别，选择，采用有意义的度量标准去提供基本的应用安全管理方案。这个基线也是未来比较评估的一个点

怎样去识别你是否易受攻击

一个好的系统度量标准有以下基本的几个点：

• 总结图表，展现基于时间的安全相关的bug计数，它们的开放和关闭比率，和面向政策审计和风险管理目标的努力。
• 回答有关“应用有多安全？”或者“风险是在随时间增长还是在下降？”的管理问题的必需数量。
• 一个已知的安全缺陷密度（也就是，被监控的每一块代码安全bug的平均数量和方向正确的比率。）

怎样保护你自己

• 建立一个度量的工作集。例如，首先计算高，中，低三个等级的安全bug数。接下来是比率评估，这将回答类似以下问题：“在质量保障测试中与安全相关的bug被发现有多快？”，“被检测到的bug有多严峻？”，“依据我们的政策性审计和风险管理目标，测试覆盖的覆盖面的完成优先级与程度怎么样？”
• 确保所有的安全相关的测试已经被检测到(一个简单的表格可以做)
• 尽可能地自动化度量计算和制图，因此需求的精确地信息可以被获得，甚至是以表格总结的方式。
• 确保所有的高优先级安全bug已经被修复和回归检测，优先是软件版本。

测试活动

怎样识别应用是否有漏洞

不是每一个质量保障组都会采用下面的测试框架，但是战略上采用的越多，你的应用的安全保障将越好：

• 跨站脚本和SQL注入测试
• 关于用户输入的评估，包括特殊字符和多字节字符，过长字符串，Null输入，或者无效值
• Cookie或者证书操控测试已经完成
• 服务场景的拒绝已经被检测，连接，登录或者交互式洪流的压力测试已经被验证

怎样去保护自己

• 运行用户端的注入测试（跨站脚本，SQL查询注入，数据操控检测）
• 检测应用怎样处理错误的用户输入，太短或者太长，或者包含特殊字符或多字节字符
• 检测应用对与cookie和session的管理有多敏感
• 验证应用在加载下的表现，比如：如果1000个用户同时登录会发生什么？或者如果TCP/IP连接的洪流已经被建立，但是没有接收到SYN信号？（即DDOS攻击模拟）

测试数据

支付行业数据安全标准（PCIDSS） 6.3.4， 国际标准化组织（ISO）27002：2005 12.4.2，COBIT4.0， 所有需求的数据包含个人的识别信息，而且不是测试目的。

• 需求数据和应用所有者的请求产品数据的许可
• 替换邮件地址，电话号码，IP地址，邮寄地址等，尽可能地解剖数据
• 例子：取代一部分邮件地址的名字，以一个单向哈希值的方式，保留域名
• 其他技巧：如字符干扰，数学变化（如：一个随机数字+或者-原始值的10%），置空，截断，编码，聚集
• 如果可能，让你的操作团队在恢复数字顺序时混乱
• 确保这对于每一个独特的个人的任何数据都已经执行
• 考虑数据被提取，存储，传输，和清洁的过程，确保活的数据是被保护的状态
• 考虑运用正则表达式去人造数据，和预定义的范围里值去生成现实但假的测试数据
  • 对于没有历史数据的新功能，这大概是唯一的选择
  • 这是最好的选择
• 完整的数据集可能太大以至于不能在缓慢测试硬件中高效运用。一个小的人造数据集或者一个模糊的子集数据可能是必需的
• 招募数据库管理员的辅助，SQL语句包含的命令包括RAND，REPLICATE和REPLACE之类
• 开源数据产生工具例如：
  • dbMonster - http://dbmonster.kernelpanic.pl/
  • Generate Data - http://www.generatedata.com