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

2019独角兽企业重金招聘Python工程师标准>>>

获得安全测试要求

要获得成功的测试程序，必须知道测试目标是什么。这些目标由安全要求指定。本节详细讨论了如何通过从适用的标准和法规以及正面和负面的应用程序要求中获取安全测试的要求来记录安全测试的要求。它还讨论了安全要求如何在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步：使用和滥用案例描述功能和负面情况：下图中的图形示例描述了通过使用和误用情况推导的安全要求。功能方案包括用户操作（输入用户名和密码）和应用程序操作（验证用户并在验证失败时提供错误消息）。滥用案例包括攻击者的行为，即试图通过字典攻击强制密码并通过猜测错误消息中的有效用户名来破坏身份验证。通过以图形方式表示对用户操作（滥用）的威胁，可以将对策导出为缓解此类威胁的应用程序操作。

转载于:https://my.oschina.net/u/3447023/blog/3017482