2019测试指南-推导安全测试要求

得到安全测试要求

要得到成功的测试程序，必须知道测试目标是什么。这些目标由安全要求指定。本节详细讨论了如何经过从适用的标准和法规以及正面和负面的应用程序要求中获取安全测试的要求来记录安全测试的要求。它还讨论了安全要求如何在SDLC期间有效推进安全测试，以及如何使用安全测试数据来有效管理软件安全风险。

测试目标
安全测试的目标之一是验证安全控制是否按预期运行。这经过描述安全控件功能的安全要求进行记录。从较高的层面来讲，这意味着要证实数据和服务的机密性，完整性和可用性。另外一个目标是验证安全控制是在不多或没有漏洞的状况下实现的。这些是常见的漏洞，例如OWASP Top Ten，以及以前在SDLC期间经过安全评估肯定的漏洞，例如威胁建模，源代码分析和渗透测试。

安全要求文档安全要求文档
的第一步是了解业务要求。业务需求文档能够提供有关应用程序的预期功能的初始高级信息。例如，应用程序的主要目的多是向客户提供金融服务或容许从在线目录中购买商品。业务要求的安所有分应强调保护客户数据以及遵照适用的安全文档（如法规，标准和策略）的必要性。

适用法规，标准和策略的通常清单是Web应用程序的良好初步安全合规性分析。例如，能够经过检查有关业务部门以及应用程序将运行的国家或州的信息来识别合规性法规。其中一些合规性指南和法规可能转化为安全控制的特定技术要求。例如，在财务应用程序的状况下，遵照FFIEC认证准则[15]要求金融机构经过多层安全控制和多因素身份验证来实施缓解弱认证风险的应用程序。

通常安全要求清单也须要捕获适用的安全行业标准。例如，对于处理客户信用卡数据的应用程序，符合PCI DSS [16]标准禁止存储PIN和CVV2数据，并要求商家经过加密保护磁带数据进行存储和传输。经过掩蔽显示。能够经过源代码分析验证此类PCI DSS安全要求。

清单的另外一部分须要强制执行符合组织信息安全标准和策略的通常要求。从功能需求的角度来看，安全控制的要求须要映射到信息安全标准的特定部分。此类要求的一个示例多是：“必须经过应用程序使用的身份验证控件强制执行六个字母数字字符的密码复杂性。” 当安全要求映射到合规性规则时，安全性测试能够验证合规性风险的暴露程度。若是发现违反信息安全标准和政策的行为，则会产生能够记录而且业务必须管理的风险。因为这些安全合规性要求是可执行的，

安全要求验证
从功能角度来看，安全性要求的验证是安全性测试的主要目标。从风险管理的角度来看，安全要求的验证是信息安全评估的目标。从较高层面来讲，信息安全评估的主要目标是肯定安全控制方面的差距，例如缺少基自己份验证，受权或加密控制。更深刻的是，安全评估目标是风险分析，例如肯定安全控制中的潜在弱点，以确保数据的机密性，完整性和可用性。例如，当应用程序处理我的身份信息（PII）和敏感数据时，要验证的安全要求是遵照公司信息安全策略，要求在传输和存储中加密此类数据。假设加密用于保护数据，加密算法和密钥长度须要符合组织加密标准。这些可能要求只能使用某些算法和密钥长度。例如，能够进行安全性测试的安全性要求是验证仅容许使用容许的密码（例如，SHA-256，RSA，AES）以及容许的最小密钥长度（例如，对称性超过128位，非对称性超过1024）加密）。加密算法和密钥长度须要符合组织加密标准。这些可能要求只能使用某些算法和密钥长度。例如，能够进行安全性测试的安全性要求是验证仅容许使用容许的密码（例如，SHA-256，RSA，AES）以及容许的最小密钥长度（例如，对称性超过128位，非对称性超过1024）加密）。加密算法和密钥长度须要符合组织加密标准。这些可能要求只能使用某些算法和密钥长度。例如，能够进行安全性测试的安全性要求是验证仅容许使用容许的密码（例如，SHA-256，RSA，AES）以及容许的最小密钥长度（例如，对称性超过128位，非对称性超过1024）加密）。

从安全评估的角度来看，能够经过使用不一样的工件和测试方法在SDLC的不一样阶段验证安全性要求。例如，威胁建模侧重于识别设计过程当中的安全漏洞，安全代码分析和评估侧重于在开发过程当中识别源代码中的安全问题，而渗透测试侧重于在测试或验证期间识别应用程序中的漏洞。

在SDLC早期发现的安全问题能够记录在测试计划中，以便稍后经过安全测试进行验证。经过结合不一样测试技术的结果，能够得到更好的安全测试用例并提升安全要求的保证级别。例如，当渗透测试和源代码分析的结果相结合时，能够区分真正的漏洞和不可利用的漏洞。例如，考虑到SQL注入漏洞的安全性测试，黑盒测试可能首先涉及扫描应用程序以指纹漏洞。能够验证的潜在SQL注入漏洞的第一个证据是生成SQL异常。SQL漏洞的进一步验证可能涉及手动注入攻击向量以修改SQL查询的语法以进行信息泄露。这可能涉及大量的试错分析，直到执行恶意查询。假设测试人员有源代码，她能够从源代码分析中学习如何构建能够利用漏洞的SQL攻击向量（例如，执行将机密数据返回给未受权用户的恶意查询）。

威胁和对策分类法
甲威胁和对策的分类，其中考虑到漏洞的考虑根本缘由，是在验证安全控制设计，编码，并内置于减轻这种漏洞的暴露的影响的关键因素。对于Web应用程序，安全控件暴露于常见漏洞（例如OWASP Top Ten）多是得到通常安全要求的良好起点。更具体地说，Web应用程序安全框架[17]提供了漏洞的分类（例如，分类），这些漏洞能够记录在不一样的准则和标准中，并经过安全测试进行验证。

威胁和对策分类的重点是根据威胁和漏洞的根本缘由定义安全要求。可使用STRIDE [18]将威胁分类为欺骗，篡改，否定，信息泄露，拒绝服务和特权提高。根本缘由可归类为设计中的安全漏洞，编码中的安全漏洞或因为不安全配置致使的问题。例如，弱身份验证漏洞的根本缘由多是当数据跨越应用程序的客户端和服务器层之间的信任边界时缺少相互身份验证。在架构设计审查期间捕获不能否认威胁的安全要求容许记录对策的要求（例如，

针对漏洞的威胁和对策分类也可用于记录安全编码的安全要求，例如安全编码标准。身份验证控件中的常见编码错误的示例包括应用哈希函数来加密密码，而不将种子应用于值。从安全编码的角度来看，这是一个影响用于身份验证的加密的漏洞，其中包含编码错误中的漏洞根本缘由。因为根本缘由是不安全编码，所以能够在安全编码标准中记录安全要求，并在SDLC的开发阶段经过安全代码审查进行验证。

安全测试和风险分析
安全要求须要考虑漏洞的严重性，以支持风险缓解策略。假设组织维护应用程序中发现的漏洞存储库（即漏洞知识库），则能够按类型，问题，缓解，根本缘由报告安全问题，并将其映射到找到它们的应用程序。此类漏洞知识库还可用于创建度量标准，以分析整个SDLC中安全性测试的有效性。

例如，考虑一个输入验证问题，例如SQL注入，它是经过源代码分析识别出来的，并报告了编码错误根本缘由和输入验证漏洞类型。能够经过渗透测试来评估这种漏洞的暴露，经过使用几个SQL注入攻击向量探测输入字段。此测试可能会验证在访问数据库以前是否过滤了特​​殊字符并减轻了漏洞。经过结合源代码分析和渗透测试的结果，能够肯定漏洞的可能性和暴露程度，并计算漏洞的风险评级。经过报告调查结果中的漏洞风险评级（例如，测试报告），能够决定缓解策略。例如，

经过考虑利用常见漏洞的威胁情景，能够识别应用程序安全控制须要进行安全性测试的潜在风险。例如，OWASP Top Ten漏洞能够映射到诸如网络钓鱼，隐私侵权，识别盗窃，系统危害，数据更改或数据破坏，财务损失和声誉损失等攻击。这些问题应记录为威胁情景的一部分。经过考虑威胁和漏洞，能够设计一组模拟此类攻击场景的测试。理想状况下，组织漏洞知识库可用于派生安全风险驱动的测试用例，以验证最可能的攻击方案。例如，若是身份盗窃被认为是高风险，

推导功能和非功能测试要求

功能安全要求
从功能安全要求的角度来看，适用的标准，政策和法规既须要一种安全控制，也须要控制功能。这些要求也称为“积极要求”，由于它们陈述了能够经过安全测试验证的预期功能。积极要求的示例是：“应用程序将在六次登陆尝试失败后锁定用户”或“密码必须至少为六个字母数字字符”。正面要求的验证包括断言预期的功能，而且能够经过从新建立测试条件并根据预约义的输入运行测试来进行测试。而后将结果显示为失败或经过条件。

为了经过安全测试验证安全性要求，安全性需求须要由功能驱动，而且须要突出显示预期的功能（什么）和隐式实现（如何）。验证的高级安全性设计要求的示例能够是：

• 保护传输和存储中的用户凭据和共享机密
• 屏蔽显示中的任何机密数据（例如，密码，账户）
• 在必定次数的登陆尝试失败后锁定用户账户
• 因为登陆失败，请勿向用户显示特定的验证错误
• 仅容许使用字母数字的密码，包括特殊字符和最小长度为六个字符，以限制攻击面
• 经过验证旧密码，新密码和用户对质询问题的回答，仅容许对通过身份验证的用户进行密码更改功能，以防止经过密码更改强制输入密码。
• 密码重置表单应验证用户的用户名和用户的注册电子邮件，而后经过电子邮件将临时密码发送给用户。发出的临时密码应该是一次性密码。密码重置网页的连接将发送给用户。密码重置网页应验证用户临时密码，新密码以及用户对质询问题的回答。

风险驱动的安全要求
安全测试还须要风险驱动，即他们须要验证应用程序是否存在乎外行为。这些也称为“否认要求”，由于它们指定了应用程序不该该执行的操做。

负面要求的例子是：

• 应用程序不该容许更改或销毁数据
• 恶意用户不该对应用程序进行未经受权的金融交易进行攻击或滥用。

负面要求更难以测试，由于没有预期的行为要寻找。这可能须要威胁分析师提出不可预见的输入条件，缘由和影响。这是安全测试须要由风险分析和威胁建模驱动的地方。关键是将威胁情景和对策的功能记录为减轻威胁的因素。

例如，在身份验证控件的状况下，能够从威胁和对策角度记录如下安全要求：

• 加密存储和传输中的身份验证数据，以下降信息泄露和身份验证协议攻击的风险
• 使用非可逆加密来加密密码，例如使用摘要（例如，HASH）和种子来防止字典攻击
• 在达到登陆失败阈值后锁定账户并强制执行密码复杂性以下降强力密码攻击的风险
• 验证凭据时显示通用错误消息，以下降账户获取或枚举的风险
• 相互验证客户端和服务器，以防止不能否认和中间人（MiTM）攻击

威胁树和攻击库等威胁建模工具可用于推导负面测试场景。威胁树将假定根攻击（例如，攻击者可能可以读取其余用户的消息）并识别安全控制的不一样漏洞（例如，因为SQL注入漏洞而致使数据验证失败）和必要的对策（例如，实施数据）验证和参数化查询）能够被验证为有效减轻此类攻击。

 

经过使用和滥用案例获取安全测试要求

描述应用程序功能的先决条件是了解应用程序应该执行的操做以及操做方式。这能够经过描述用例来完成。用例以软件工程中经常使用的图形形式显示演员及其关系的交互。它们有助于识别应用程序中的参与者，他们的关系，每一个场景的预期行动顺序，替代操做，特殊要求，前提条件和后置条件。

与用例相似，滥用和滥用案例 [19]描述了应用程序的非预期和恶意使用场景。这些滥用案例提供了一种描述攻击者如何滥用和滥用应用程序的方案的方法。经过浏览使用场景中的各个步骤并思考如何恶意利用它，能够发现未明肯定义的应用程序的潜在缺陷或方面。关键是描述全部可能的或至少是最关键的使用和误用场景。

滥用方案容许从攻击者的角度分析应用程序，并有助于识别潜在的漏洞以及须要实施的对策，以减轻潜在暴露于此类漏洞所形成的影响。鉴于全部使用和滥用案例，分析它们以肯定哪些是最关键的而且须要记录在安全要求中很是重要。肯定最严重的滥用和滥用案例能够记录安全要求以及应减轻安全风险的必要控制措施。

为了从使用和误用案例[20]中得到安全性要求，定义功能场景和负面场景并将其以图形形式放置是很重要的。例如，在推导认证的安全要求的状况下，能够遵循如下逐步方法。

• 步骤1：描述功能场景：用户经过提供用户名和密码进行身份验证。应用程序根据应用程序对用户凭据的身份验证授予用户访问权限，并在验证失败时向用户提供特定错误。

• 步骤2：描述负面场景：攻击者经过对应用程序中的密码和账户收集漏洞的强力攻击或字典攻击来破坏身份验证。验证错误向攻击者提供特定信息，以猜想哪些账户其实是有效的注册账户（用户名）。而后攻击者将尝试暴力破解这样一个有效账户的密码。经过有限次数的尝试（即10 ^ 4），对四个最小长度的全部数字密码的暴力攻击均可以成功。

• 第3步：使用和滥用案例描述功能和负面状况：下图中的图形示例描述了经过使用和误用状况推导的安全要求。功能方案包括用户操做（输入用户名和密码）和应用程序操做（验证用户并在验证失败时提供错误消息）。滥用案例包括攻击者的行为，即试图经过字典攻击强制密码并经过猜想错误消息中的有效用户名来破坏身份验证。经过以图形方式表示对用户操做（滥用）的威胁，能够将对策导出为缓解此类威胁的应用程序操做。