安全软件生命周期之规范性安全软件生命周期流程：接触点

接触点

国际软件安全顾问GaryMcGraw通过编纂构建安全产品的安全安全丰富行业经验 ，提供了七个软件安全接触点 。软件软件McGraw使用术语接触点来指代可以纳入安全软件生命周期的生命生命软件安全最佳实践。McGraw区分了作为实现错误的周期之规周期漏洞和那些是设计缺陷的漏洞。实现错误是范性单段代码中的局部错误，例如缓冲区溢出和输入验证错误，流程使发现和理解更容易。接触设计缺陷是安全安全代码设计级别的系统性问题，免费模板例如以不安全的软件软件方式失败的错误处理和恢复系统或错误地包含传递信任问题的对象共享系统
。Kuhn等人[32]分析了来自美国国家漏洞数据库（NVD）的生命生命2008-2016年漏洞数据，发现67%的周期之规周期漏洞是实施错误。七个接触点有助于预防和检测错误和缺陷 。范性

下面描述了这七个接触点 ，流程并根据McGraw多年来对每种实践的接触效用的经验按有效性顺序提供 ，因此具有规范性：

1.   代码审查（工具）。安全安全

代码审查用于检测实现错误。模板下载可以使用手动代码审查，但要求审核员在严格检查代码之前了解安全漏洞。“使用工具进行代码审查”（又名使用静态分析工具或SAST）已被证明是有效的，可供工程师使用没有专家安全知识。有关静态分析的进一步讨论  ，请参见第2.1.1节第9点。

2.   架构风险分析。

架构风险分析，也称为威胁建模（请参阅第4节） ，用于预防和检测设计缺陷。设计人员和架构师提供目标系统的高级视图和假设文档 ，并识别可能的云计算攻击。通过架构风险分析，安全分析师可以发现架构和设计缺陷并进行排序 ，以便开始缓解。例如 ，风险分析可以识别可能的攻击类型，例如拦截和读取数据的能力。这种识别将促使设计人员查看其所有代码的流量  ，以查看拦截是否令人担忧，以及是否有足够的保护（即加密）。服务器租用分析提示的审查是发现设计缺陷的原因 ，例如敏感数据被明文传输。

没有系统是完全安全的
，因此必须使用风险分析来确定安全工作的优先级，并将系统级问题与对构建软件的业务至关重要的概率和影响措施联系起来
。风险敞口的计算方法是将不良事件发生的源码库概率乘以与该事件相关的成本。

McGraw提出了架构风险分析的三个基本步骤 ：

•抗攻击性分析 。攻击抵抗分析使用清单/系统方法考虑每个系统组件与已知威胁的关系，如第2.1.1节第4点中讨论Microsoft威胁建模中所做的那样。在分析过程中使用有关已知攻击和攻击模式的信息，识别体系结构中的风险并了解已知攻击的可行性 。如第2.1.1节第4点所述，合并基于STRIDE的攻击的高防服务器威胁建模是执行攻击抵抗分析的示例过程 。

•   歧义分析
。模糊性分析用于捕获发现新风险所需的创造性活动 。模糊性分析需要两个或更多经验丰富的分析师在同一系统上并行执行单独的分析活动
。通过统一对多重分析的理解  ，分析师之间的分歧可以发现歧义
、不一致和新的缺陷。

•弱点分析。弱点分析侧重于了解与其他第三方组件中的安全问题相关的风险（请参阅第2.1.1节第7点）。这个想法是了解对第三方软件的假设，以及当这些假设失败时会发生什么。

风险识别 、排名和缓解是贯穿整个软件生命周期的持续过程，从需求阶段开始。

3.    渗透测试
。

渗透测试可以由架构风险分析的结果指导（请参阅第2.1.2节第2点）。有关渗透测试的进一步讨论
，请参见第2.1.1节 ，第11点 。

4.    基于风险的安全测试
。

安全测试必须包含两种策略
：（1）使用标准功能测试技术测试安全功能;（2）基于攻击模式和架构风险分析结果的基于风险的测试（参见第2.1.2节第2点）和滥用案例（参见第2.1.2节第5点）。对于Web应用程序，安全功能的测试可以由OWASP应用程序安全验证标准（ASVS）项目12开放标准指导，用于测试应用程序技术安全控制。ASVS还为开发人员提供了安全开发的要求列表 。

利用软件架构和构造、常见攻击和攻击者的心态知识指导测试非常重要。使用架构风险分析的结果 ，测试人员可以适当地关注攻击可能成功的代码区域。

基于风险的测试和渗透测试之间的区别在于方法的级别和测试的时间。渗透测试是在软件完成并安装在操作环境中时完成的。渗透测试是由外而内的黑盒测试
 。基于风险的安全测试可以在软件完成甚至预集成之前开始
，包括使用白盒单元测试和存根。两者的相似之处在于 ，它们都应该以风险分析、滥用案例和功能安全要求为指导 。

5.    滥用案例

这个接触点编纂了“像攻击者一样思考”。用例描述了仁慈参与者对所需系统的行为 。滥用案例[20]描述了系统在受到恶意行为者攻击时的行为 。为了开发滥用案例 ，分析师列举了有动机攻击系统的恶意行为者的类型 。

对于每个不良行为者 
，分析师为不良行为者希望从系统中获得的功能创建一个或多个滥用案例 。然后 ，分析师考虑用例和滥用案例之间的交互，以加强系统。考虑一个汽车的例子 。参与者是汽车的驾驶员 ，这个参与者有一个用例“驾驶汽车” 。恶意行为者是偷车贼 ，其滥用案件是“偷车”。此滥用案例威胁到用例。为了防止盗窃，可以添加新的用例“锁定汽车”，以减轻滥用情况并加强系统。

人为错误是造成大量违规行为的原因。系统分析师还应考虑善意用户的行为，例如成为网络钓鱼攻击的受害者，从而导致安全漏洞
 。这些行为可以被视为滥用案例[21]，应该像滥用案例一样进行分析 ，考虑滥用案例威胁的用例以及对系统进行强化以减轻滥用案例 。

滥用和误用案例分析确定的攻击和缓解措施可用作安全要求的输入（第2.1.1节第2点） 。渗透测试（第2.1.1节第11点）;以及基于风险的安全测试（第2.1.2节第4点） 。

6.    安全要求。

有关安全要求的进一步讨论，请参见第2.1.1节第2点
。

7.    安全操作
。

网络安全可以与软件安全集成，以增强安全态势 。无论其他接触点的应用如何，攻击都不可避免地会发生。了解攻击者行为和成功攻击的软件是一种基本的防御技术。通过了解攻击获得的知识可以反馈到其他六个接触点。

七个接触点旨在随着软件产品的发展而多次循环。接触点也是与过程无关的，这意味着实践可以包含在任何软件开发过程中。