本节主要介绍可用于组织或企业进行应用测试的典型的测试框架。它可以被看作是包含技术和任务的一个参考框架,适用于软件开发生命周期(SDLC)的各个阶段。公司和项目团队可以使用这个模式,为自己或服务供应商开发测试框架和范围测试。这个框架不应该被看作是指令性的,但作为一个灵活的做法,可以延长和变形,以适应一个组织的发展进程和文化。
本节的目的是帮助组织或企业建立一个完整的战略测试过程,而不是帮助一些顾问或从事策略性的具体测试工作的代理商。
至关重要的是理解为什么建立一个端到端的测试框架对评估和改善软件的安全至关重要。 Howard 和 LeBlanc 在安全代码开发中指出微软安全公告发布的费用至少在 10 万美元,同时,他们的客户的损失远远超过安全补丁实施。他们还指出,美国政府的网络犯罪网站对详细列举了各组织机构最近的刑事案件和所造成的损失。典型的损失远远超过 10 美元。根据这样的经济损失状况,不难理解为什幺软件厂商不再只在软件开发后进行黑盒安全测试,而是转向软件开发的早期,如定义阶段,设计阶段和发展阶段 。
许多安全从业人员对安全测试的认识仍然停留在渗透测试的范围内。正如之前讨论,渗透测试虽然发挥了一定的作用,但它的作用不足以发现所有的漏洞,同时它过分依赖测试者的技巧。渗透测试只能当做是一种执行技术或者是用来提高对产生问题的意识。要改善应用程序的安全,必须提高软件的安全质量。这意味着需要在软件开发的定义,设计,发展,部署和安装阶段测试其安全,而不是依靠等到代码完成建立才进行测试这样的昂贵的策略。
正如该文档中所介绍的,有很多相对先进的开发方法,如 Rational Unified Process,eXtreme and Agile development以及传统的瀑布方法。该指南并没有建议特定的开发方法,也没有坚持以任何特定的方法提供具体的指导。相反,我们提出了一个通用的发展模式,读者应当根据自己公司的进程遵循它。
该测试框架应当包括以下内容:
开发开始前进行测试
定义和设计过程中进行测试
开发过程中进行测试
部署过程中进行测试
维护和运行

0X01 第 1 阶段:开发开始前进行测试

阶段 1.1: 定义一个 SDLC

      在应用开发前，必须先部署一个合适的SDLC过程来使安全贯穿与各个阶段。

阶段 1.2: 审查策略和标准

      确保有适当的政策,标准和文件。文件是极为重要的,它给了开发团队可以遵循的指导方针和政策。人只能做正确的事情,如果他们知道什幺是正确的。如果应用程序师在 Java 中开发的,那幺有一个 Java 安全编码标准是十分重要的;如果应用程序要使用加密技术,那幺有一个加密标准是十分重要的;如果应用程序在 Java 中开发 ,重要的是有一个 Java 安全编码标准。如果应用是使用加密技术,重要的是有一个加密标准。没有任何政策或标准可以涵盖开发团队面临的所有情况。通过记录的共同的和可预测的问题,在开发过程中就可以少做决定。

阶段 1.3: 开发衡量标准及指标(保证可追溯)

      在软件开发开始之前,计划衡量标准项目。 通过定义需要被测量的标准,它在过程和产品中提供可见性的瑕疵。在开发开始之前定义度是很重要的,因为为了获取数据或许会需要修改开发的过程。

0x02 第 2 阶段:定义和设计过程中进行测试

阶段 2.1: 安全需求审查

       安全需要从安全角度定义了应用程序如何工作。对安全要求进行测试时很重要的。在这种情况下,测试意味着测试安全要求中的假设,并测试在安全要求定义中是否存在的缺陷。例如,如果有一个安全要求指出用户必须注册才能访问网站白皮书部分,这是否意味着用户必须是系统注册的用户,或者证明用户是真实用户?尽可能确保安全要求明了清晰。当寻找安全要求缺陷时,需考虑寻找安全机制,如:
用户管理
认证
授权
数据保密
完整
问责制
会话管理
传输安全
层次系统分离偏析
法律规范

阶段 2.2: 设计和架构审查

       应用应该有设计和架构文档。 这里所说的文档,指的是模型、原文文件和其他相似的工件。 测试这些工件是对保证开发设计强制执行安全需求中适用的安全水平具有非凡的意义。在设计阶段进行安全漏洞检测不仅是检测漏洞最省钱的阶段之一,同样也是做修改最有效的地方之一。 例如,如果证实设计需要在多个地方作出授权决定,那幺应适当考虑一个中央授权部分。如果应用在多个地方进行数据有效性检验,应适当考虑开发一个中央检验框架(在一个地方定向输入检验比在数百个地方输入更加便宜)。如果发现弱点,系统架构师能通过多种方法找到他们。

阶段 2.3: 创建并审查 UML 模型

       设计架构一旦完成,建立统一建模语言(UML)模型,描述应用工程如何工作。在某些情况下,这些模型可能已经可用。使用这些模式,以确认系统设计者提供了一种准确地理解应用工程如何工作。如果发现弱点,系统架构师能通过多种方法找到他们。

阶段 2.4: 创建并审查威胁模型

       有了设计架构审查,以及UML模型解释究竟系统如何工作,还需要进行威胁建模工作。制定切合实际的威胁模型。分析设计架构,以确保这些威胁已经减少至企业或第三方团体如保险公司所能接受的程度。当确认威胁没有缓解策略时,系统设计师重新访问设计构架以重新修改设计。没有任何威胁的减灾战略,建筑设计师应重新设计和修改系统设计

第 3 阶段: 开发过程中进行测试

               理论上,开发是设计的实施。然而,实际上在代码发展期间需要做许多决策设计。有许多因为过分细节化而没有写入设计架构的问题需要自行决定,或者在某些情况下,某些问题并没有策略或标准的指导。 如果设计架构不是充分的,开发者面对许多决定。如果策略和标准有不足,开发者将面对更多的决定。

阶段 3.1: 代码浏览

         安全小组应该与开发者一起进行代码浏览,某些情况下,系统构架师也应该一同参与。代码浏览过程中,开发者能解释清楚被实施的代码的逻辑和流程。它使得代码审查团队获得对代码的一般理解,同时开发者能够解释他们采用某种特定的开发方式的原因。这个目的并不是执行代码审查,而是在了解高级流程、布局以及应用代码的结构。

阶段 3.2: 代码审查

        充分理解代码的结构以及采取特定方式进行编码的原因,测试者能检验实际代码可能存在的安全瑕疵。进行静态代码审核,需确认代码遵循一系列清单,包括:对有效性
,保密性和完整性的业务要求。
OWASP 指南或 OWASP top 10 中的 (根据回顾的深度)技术曝光清单。
与使用语言或框架相关的具体问题,例如 PHP 红皮书或微软安全编制的红皮书或微软 ASP.NET 安全编码的检查清单。
任何专门性的行业要求,例如Sarbanes-Oxley 404, COPPA, ISO 17799, APRA、HIPAA、Visa Merchant指南,或者其他管理办法。根据投资的资源(一般指时间)回报,静态代码审查比其他安全审查方法具有更加优质的回报,并且所依赖的审核者的专业技能最少。然而,它并不是万能的,在代码审查中,需要在充分的考虑后小心使用。
欲了解关于 OWASP 清单的更多信息,请查询OWASP Guide for Secure Web Applications, 或最近发表的OWASP Top
10.

第 4 阶段: 发展过程中进行测试

阶段 4.1: 应用程序渗透测试

       通过需求测试,设计架构分析和代码审查,也许可以假设所有可能的存在的问题都已被发现。然而,这只是一种假象,渗透测试通过在应用部署完成后采取一系列的检查可以确保没有任何遗留问题。

阶段 4.2: 配置管理测试

     应用渗透测试应包括对基础设施的部署以及安全检查。即使应用是安全的,有些小方面配置可能还处在默认安装阶段,同样存在漏洞。

第 5 阶段: 维护和运行

阶段 5.1: 进行操作管理审查

       需要一个详细介绍应用程序和架构操作端管理的流程。

阶段 5.2: 进行定期的健康状态检查

      对应用和基础设施进行以月或者季度为单位的巡检,以确保没有任何新的安全风险产生,该级别的安全性仍然不变。

阶段 5.3: 确保变更验证

      在每个变化被批准了并且在在QA环境进行适当的更改和测试并应用到正式环境后,最重要的是,作为变更管理进程的一部分,确认后的变更行为应确保对该安全级别没有任何影响。