安全软件生命周期之规范性安全软件生命周期流程

规范性安全软件生命周期流程

安全软件生命周期流程是将安全性构建到产品中的主动方法，从源头上处理设计不佳、不安全软件的“疾病”，而不是“应用创可贴”通过反应性来阻止症状渗透和修补方法。这些流程将软件安全深入到整个产品开发过程中，并结合人员和技术来解决和预防软件安全问题。本节将提供有关三个突出的安全软件生命周期过程的信息，然后在表1中反思它们之间的共性。

2.1安全的软件生命周期流程

本节总结了三个示例规范性安全软件生命周期过程。这些过程是规范性的，因为它们明确推荐软件实践。之所以选择这三个流程，是因为这些流程的实践是集成的，涵盖了从软件需求到发布/部署和软件维护的广泛生命周期阶段。其中两个过程是在关于软件开发生命周期中安全方法的系统映射研究[25]中确定的。因此，实践涵盖安全缺陷的预防、安全缺陷的检测以及产品进入现场后缓解安全缺陷。选择这三者也是因为它们存在的年数和在行业中的广泛接受度方面具有成熟度。正如将在2.2节中讨论的那样，不存在“最佳”安全软件生命周期过程。从业者应考虑将这些过程中的每一个实践合并到他们自己的安全软件过程中。

2.1.1 Microsoft安全开发生命周期（SDL）

如第1节所述，Microsoft使用内部开发流程（安全开发生命周期（SDL））来提高其产品的安全性。霍华德和利普纳[3]在2006年传播了这一过程的快照。从那时起，Microsoft 继续发展其SDL，并为社区提供最新资源[11]，包括更加关注正在强加给行业。

目前[11]，SDL Microsoft包含12个实践，如下所示。对于每种实践，可能会提及实施实践的技术，尽管SDL没有规定具体的技术。

1. 1.提供培训。开发人员、服务工程师、项目经理、产品经理和项目经理等一系列专业人员参与安全产品的开发，同时仍能满足业务需求并提供用户价值。软件开发人员和架构师必须了解预防和检测漏洞的技术方法。整个开发组织应该认识到攻击者的观点、目标和技术;以及不构建安全产品的业务影响。

通常，这些专业人员的正规教育不包括网络安全。此外，攻击媒介、安全工具、安全编程语言和体验也在不断发展，因此必须更新知识和课程材料。持续的网络安全培训对软件组织至关重要。

1. 2.定义安全要求。应在初始设计和规划阶段定义安全要求。影响这些要求的因素包括系统的特定功能要求、法律和行业合规性要求、内部和外部标准、以前的安全事件和已知威胁。

已经开发了系统地开发安全需求的技术。例如，安全质量要求工程（SQUARE）[26]是一个九步过程，可帮助组织在生产生命周期的早期阶段构建安全性。如第2.1.2节第5点所述，滥用情况是指定安全要求的另一种方法。van Lamsweerde扩展了基于目标的需求规范语言的保持所有目标满足（KAOS）框架，以包括反模型[27]。反模型是通过解决攻击者为威胁系统的安全目标而设置的恶意障碍（称为反目标）来构建的。障碍否定了系统的现有目标。Securei*[28]通过对安全权衡的建模和分析扩展了i*建模框架，并使安全需求与其他需求保持一致。

必须不断更新安全要求，以反映所需功能、标准和威胁形势的变化。

1. 3.定义指标和合规性报告。引用开尔文勋爵的话说，“如果你不能衡量它，你就无法改进它”。管理团队应该理解并使用安全指标对可接受的最低安全级别负责[13]。这些指标的子集可以设置为管理报告的关键绩效指标（KPI）。缺陷跟踪应清楚地标记安全缺陷和安全工作项，以便准确确定安全工作的优先级、风险管理、跟踪和报告。此外，产品越来越必须符合监管标准，例如支付卡行业数据安全标准（PCI DSS）4或欧盟通用数据保护条例（GDPR）5，这些标准可能会施加额外的流程步骤以及合规性、报告和审核指标。

2. 4.执行威胁建模。通过使用威胁建模[14，22]，团队在其计划的操作环境中以结构化的方式考虑，记录和讨论设计的安全影响。团队应考虑对手的动机以及系统的优势和劣势，以防御相关的威胁场景。一种方法是考虑（1）与系统的恶意和仁慈的交互者;（2）系统及其组件（即流程和数据存储）的设计，（3）系统的信任边界;（4）系统在信任边界内和跨信任边界进出其交互者的数据流。可以使用考虑每个系统组件（欺骗、篡改、否认、信息泄露、拒绝服务、特权提升）的系统方法枚举威胁[9]威胁：

(a)欺骗身份。欺骗威胁允许攻击者伪装成其他用户或允许恶意服务器伪装成有效服务器。

(b)篡改数据。数据篡改威胁涉及恶意修改数据。

(c)休核。否认威胁与拒绝执行操作而其他方无法证明其他操作的用户相关联。

(d)信息披露。信息泄露威胁涉及将信息暴露给不应访问信息的个人。

(e)拒绝服务。拒绝服务（DoS）攻击通过使系统不可用或不可用来拒绝向有效用户提供服务。

(f)特权提升。非特权用户获得特权访问权限，从而具有足够的访问权限来破坏或破坏系统。

威胁建模可帮助团队枚举威胁，以便可以加强系统设计并选择安全功能。除了STRIDE之外，还存在其他模型来制定威胁模型，例如12方法6，包括攻击树[29]，它们是系统上威胁的概念图以及可能的攻击。威胁。与威胁建模密切相关的实践是架构风险分析，将在第2.1.2节第2点中讨论。

创建游戏是为了帮助团队协作（和竞争）进行威胁建模：

(a)特权提升

(b)安全卡

(c)保护扑克 

1. 5.建立设计要求。设计要求指导“安全功能”（即在安全性方面精心设计的功能）的实现。此外，体系结构和设计必须能够抵御预期操作环境中的已知威胁。

安全功能的设计涉及遵守Saltzer和Schroeder[16]在1975年提出的永恒安全原则，并在2002年由Viega和McGraw[6]重申。索尔策和施罗德的八项原则是：

•机制经济。保持系统的设计尽可能简单和小巧。

•故障安全默认值。根据权限而不是排除做出访问决策;默认条件是缺少访问权限，保护方案标识允许访问的条件。设计安全机制，以便故障将遵循与禁止操作相同的执行路径。

•完成调解。必须检查对每个对象的每次访问是否授权。

•开放式设计。设计不应依赖于攻击者的无知，而应依赖于密钥或密码的拥有。

•特权分离。当必须在授予访问权限之前做出两个或多个决策时，需要两个密钥才能解锁的保护机制比需要单个密钥的保护机制更可靠。

•最小特权。每个程序和每个用户都应使用完成作业所需的最少权限集进行操作。

•最不常见的机制。尽量减少多个用户通用且所有用户所依赖的机制数量。

•心理上的可接受性。人机界面的设计应易于使用，以便用户定期自动正确安全地应用机制。

另外两个重要的安全设计原则包括：

•纵深防御。提供多层安全控制，以便在出现安全漏洞时提供冗余。

•更新设计。软件安全性必须针对更改进行设计，例如安全修补程序和安全属性更改。

设计要求还涉及选择安全功能，例如加密、身份验证和日志记录，以减少通过威胁建模识别的风险。团队还采取措施减少其系统设计的攻击面。攻击面是Howard[15]在2003年提出的一个概念，可以被认为是攻击者可以尝试向系统输入数据或从系统中提取数据的点的总和[24，23]。

2014年，IEEE安全设计中心[17]列举了十大安全设计缺陷，并提供了避免这些缺陷的技术指南。这些准则如下：

(a)赢得或给予，但永远不要假设信任。

(b)使用无法绕过或篡改的身份验证机制。

(c)身份验证后进行授权。

(d)严格分离数据和控制指令，切勿处理从不受信任来源接收的控制指令。

(e)定义一种确保显式验证所有数据的方法。

(f)正确使用加密。

(g)确定敏感数据及其处理方式。

(h)始终考虑用户。

(i)了解集成外部组件如何改变攻击面。

(j)在考虑对象和参与者的未来变化时要灵活。

1. 6.定义和使用加密标准。使用加密技术是系统的一项重要设计功能，可确保在传输或存储时保护安全和隐私敏感数据免遭意外泄露或更改。但是，使用加密技术时的错误选择可能会使预期的保护变得薄弱或无效。在使用明确的加密标准时，应咨询专家，这些标准提供有关加密实现的每个元素以及仅使用经过适当审查的加密库的细节。系统的设计应允许在需要时轻松替换加密库，以防库被攻击者破坏，例如通过“Deep Crack”9对数据加密标准（DES）所做的操作。，由密码学研究总裁Paul Kocher设计的对每个可能的密钥进行暴力搜索。

2. 7.管理使用第三方组件的安全风险。绝大多数软件项目都是使用专有和开源的第三方组件构建的。黑鸭按需审计服务小组[18]对1，100多个商业应用程序进行了开源审计，并在95%的应用程序中发现了开源组件，每个应用程序平均有257个组件。这些组件中的每一个在采用时或将来都可能存在漏洞。组织应该拥有第三方组件的准确清单[32]，持续使用工具扫描其组件中的漏洞，并在发现新漏洞时制定响应计划。免费提供的专有工具可用于识别项目组件依赖关系，并检查这些组件中是否存在任何已知的、公开披露的漏洞。

3. 8.使用批准的工具。组织应发布已批准工具及其相关安全检查和设置的列表，例如编译器/链接器选项和警告。工程师应使用这些工具的最新版本（如编译器版本），并利用新的安全分析功能和保护。通常，生成的软件必须向后兼容以前的版本。

4. 9.执行静态分析安全测试（SAST）。SAST工具可用于自动匹配的安全代码审查，以查找不安全编码模式的实例，并帮助确保遵循安全编码策略。SAST可以作为签入门集成到提交和部署管道中，以便在每次构建或打包软件时识别漏洞。为了提高效率，SAST工具可以集成到开发人员环境中，并由开发人员在编码期间运行。一些SAST工具会发现某些实现错误，例如存在不安全或其他被禁止的功能，并在开发人员积极编码时自动替换（或建议）更安全的替代方案。另请参阅软件安全CyBOK知识领域[1]。

5. 10.执行动态分析安全测试（DAST）。DAST对编译或打包的软件执行运行时验证，以检查仅在所有组件集成并运行时才明显的功能。DAST通常涉及使用一套预构建的攻击和格式错误的字符串，这些攻击和格式错误的字符串可以检测内存损坏、用户权限问题、注入攻击和其他关键安全问题。DAST工具可以采用模糊测试，这是一种在应用程序中输入已知无效和意外测试用例的自动化技术，通常数量很大。与SAST类似，DAST可以由开发人员运行和/或作为签入门集成到构建和部署管道中。DAST可以被认为是自动渗透测试。另请参阅软件安全CyBOK知识领域[1]。

6. 11.执行渗透测试。手动渗透测试是对正在运行的系统进行黑盒测试，以模拟攻击者的行为。渗透测试通常由熟练的安全专业人员执行，他们可以是组织内部或顾问，机会性地模拟黑客的行为。渗透测试的目的是发现任何形式的漏洞-从小的实现错误到由编码错误、系统配置错误、设计缺陷或其他操作部署弱点导致的主要设计缺陷。测试应尝试未经授权滥用和访问目标资产以及违反假设。构建渗透测试的一个广泛参考的资源是OWASP十大最关键的Web应用程序安全风险10。因此，渗透测试可以发现最广泛的漏洞，尽管与SAST和DAST相比通常效率较低[19]。渗透测试人员可以称为白帽黑客或道德黑客。在渗透和补丁模型中，渗透测试是部署系统之前唯一的安全分析线。

7. 12.建立标准事件响应流程。尽管软件生命周期安全，但组织必须为不可避免的攻击做好准备。组织应主动准备事件响应计划（IRP）。该计划应包括在发生安全紧急情况时与谁联系，建立有效缓解漏洞、客户响应和沟通以及快速部署修复程序的协议。IRP应包括从组织内其他组继承的代码和第三方代码的计划。IRP应在需要之前对其进行测试。通过响应实际攻击而吸取的经验教训应重新纳入SDL。

原文始发于微信公众号（河南等级保护测评）：安全软件生命周期之规范性安全软件生命周期流程