微软SDL 2022年最新版学习笔记

maoguan121

已于 2022-07-17 21:25:50 修改

阅读量1.4k

点赞数

文章标签： microsoft 软件开发安全安全架构

于 2022-07-17 21:18:52 首次发布

本文链接：https://blog.csdn.net/maoguan121/article/details/125837195

版权

文章目录

微软SDL相关内容学习记录

说明:本文基于微软安全开发生命周期的简化实施和微软SDL官方文档 2022/7/1对微软SDL进行深入学习后，整理的学习材料，希望加深自身对微软SDL的理解，并且对同仁有所帮助。
概括起来，微软的SDL，就是:
一个目标: 安全和隐私三个核心: 教育、持续过程改善和责任五功能: 培训、政策和组织功能;要求和设计;实施;验证;发布和响应十六过程: 确定安全要求、创建质量门/Bug栏、安全和隐私风险评估、确定设计要求、分析攻击面、威胁建模、使用批准的工具、弃用不安全的函数、静态分析、动态分析、模糊测试、攻击面评析、事件响应计划、最终安全评析、发布存档、执行事件响应计划
四度量: 基本、标准化、高级、动态

微软SDL介绍

SDL核心概念

安全开发生命周期(SDL)是侧重于软件开发的安全保证过程。在微软，自2004起，SDL做为全公司(全世界100多个国家/地区的微软团队)的计划和强制政策，在将安全和隐私植入软件和企业文化方面发挥了重要作用，已应用于成百上千的微软产品。SDL主要目标减少软件中漏洞的数量和缓解漏洞影响(比较好理解，通过SDL安全左移了，让开发边写代码，边发现漏洞，边修复漏洞，自然漏洞就少了，在架构设或系统上线部署等环节的安全防御机制，让利用更难了，你原来写了一个SQL没有waf，可能直接就被脱裤了。有了waf就不是随便的攻击者都能攻击成功了，从某种意义上，缓解了漏洞影响)。SDL是在开发过程的所有阶段中均引入了安全和隐私
微软SDL基于三个核心概念 - 教育、持续过程改善和责任。安全是每个人的工作，每个人都背负着安全的职责是SDL基本前提，需要通过培训教育不断的传达给开发小组。安全风险是动态变化的需要研究分析安全漏洞的原因，定期评估SDL过程并随着新技术的发展和新威胁引入应对措施。

SDL优化模型

SDL的成功还是失败取决于组织规模、资源(时间、人才和预算)以及高层支持等因素。需要根据开发团队的成熟度水平确定实施优先级。SDL优化模型围绕五个功能领域构建:

培训、政策和组织功能
要求和设计
实施- 验证- 发布和响应
SDL优化模型还定义了四个成熟度水平 - 基本、标准化、高级和动态SDL优化模型从基本成熟度水平(几乎或完全没有任何过程、培训和工具)开始，发展到动态水平(整个组织完全遵循SDL)。完全遵循SDL包括高效的过程、训练有素的人员、专用工具及组织内部和外部各方的强烈责任感。

SDL适用性

按照官方文档，微软SDL可以适用于任何企业组织。在具体使用过程中，可以根据企业实际情况进行拆解，尝试，最终探索出，适合企业自身的安全开发流程，目标是一致的。组织各个相同，开发团队应以适合与可用的人才和资源的方式实施SDL, 但是不能危害组织的安全目标。

SDL角色分工

微软给出了一个SDL相关角色和分工，但不便于国内人员理解，具体角色分工大家可以参考美团分享的SDL实践 RASCI 美团:实践之后，我们来谈谈如何做好威胁建模
最核心内容是"Two-Pizza Teams"(团队应该以2个披萨就能吃饱的人数为最佳，一般是在10人左右), 保持沟通是构建安全产品的诀窍，实施威胁建模的效果。

简化的SDL安全活动

SDL最核心的目标是解决安全与隐私，给出的手段是微软的探索实践，所以企业在做SDL时，最核心的关注每个阶段产生的输出质量和**完整性**，不要过于强调过程，比如威胁建模,通过与开发团队进行白板会议产生威胁模型，在Word文档中以叙述形式描述威胁模型，或者使用专用工具(如SDL威胁建模工具)生成威胁模型。投资于高效的工具和自动化，的确会使SDL过程受益，但其实际价值在于可以获得全面而准确的结果。

必需的安全活动

培训

Security is everyone’s job. 第一句是多么的简单的英文，相信任何人都能看懂，“安全是每个人的工作”。而在国内的现实，几乎所有人(甚至包括安全自己人)都认为安全是安全部门的工作，其后的工作阻力，无法落地，就可想而知了。应该从全局的角度去思考，项目的团队每个成员的共同目标是开发安全、高效、可维护的系统，让这个系统一直活下去，让项目团队的人一直有工资拿，让大家有饭吃。这更像是一种企业文化，需要自上而下和自下而上的去推动。上到下是要确定规范，写入制度，是整个事件的前提，在实施的过程中，安全也需要能够真正为业务服务，帮助业务发现问题，给出合理的解决方案，体现自身价值。
整体的目标: 也充分体现了分级的思想，并不是每个人都想成为安全专家或渗透测试专家，所以培训课程应该是分层次的基础意识的:让大家都知道攻击者的观点、目标、可能使用的攻击方法等技能培训: 针对研发人员，的技能培训专家培训: 有很多优秀的人，希望学习更多微软强调培训应覆盖:安全设计(减小攻击面、深度防御、最小权限、安全默认设置)、威胁建模(概述、设计及编码约束) 、安全编码(缓冲区、整数算法、SQL注入)、弱加密安全测试(安全测试与功能测试区别、风险评估、安全测试方法)、隐私(隐私敏感数据的类型、隐私设计最佳实践、隐私测试最佳实践)

要求

定义安全需求意义:"预先"考虑安全与隐私，给项目预留足够的时间，确定关键里程碑和交付成果，不影响整体排期。
安全需求与隐私:法律法规、行业要求、内部标准、编码实践、以前出现过的安全事件、已知威胁
在这个阶段给了相对比较明确的方向，需要在开发之前就将安全需求在团队普及，这个是最佳宣传时间，成本与阻力最小。业务开始之前就要靠考虑业务的法律风险，信息数据是一个容易违法的功能。比如近几年频发的因使用网络爬虫获取数据而获刑的案件，网络爬虫业务已经是一个违法的业务了，应该及时遏制。个人违规收集遭到通报等我国相继出台了<网安法><数安法><关基条例>及<等级保护>，已经比较明确了相关保护要求。如果一个系统在开发初，就计划通过等保3级或就可能是关基系统，那在业务开始前，就要对照等保和关基进行建设。以便最终测评时，返工整改，浪费时间。外采服务是法律和安全的集合体，优选国产、规定安全义务是必备
企业自身制定的安全需求，上线红线制度
定义度量和合规报告（质量门/Bug栏)bug栏，应该就是我们日常说的红线(最低可接受级别)，有严重漏洞不允许上线这些，并且给了一个隐私参考文档，具体位置查看官方，防止链接失效
有高危漏洞禁止上线****代码符合编码规范(代码质量报警要修复)
安全与隐私风险评估安全风险评估(SRA)和隐私风险评估(PRA)是必需的过程，主要内容:哪些部分需要威胁建模?
哪些部分需要进行渗透测试?
隐私影响评级如何?

设计

设计要求
安全功能实现有时是非常复杂的，因此需要建立统一的标准，比如身份、认证、加密基础要求安全的功能为在安全方面进行了完善设计的功能，比如在处理之前对所有数据进行严格验证或通过加密方式可靠地实现加密服务库。安全功能描述具有安全影响的程序功能，如Kerberos身份验证或防火墙。
减小攻击面
减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问、应用最小权限原则以及尽可能进行分层防御。- 威胁建模"应在存在重大安全风险的环境中使用威胁建模。", 就是威胁建模应该有个前提，并不能所有项目都进行威胁建模，或者说不需要威胁建模。威胁建模是SDL的核心。5个核心步骤:定义安全需求、创建服务交互图、识别风险、缓解风险、验证所有威胁已经备处理。4部分:数据流图、威胁识别、缓解措施、安全验证

实施

使用批准的工具
保持开发环境比如编译器/连接器的更新，开启最新安全防护机制等- 弃用不安全的函数(定义和使用加密标准)
加密非常的重要，安全专家应该建立组织能够使用的加密标准，优选选择被认证过的加密算法
SAST对源代码进行扫描，确保安全。需要根据组织特性选择最佳的SAST检测点，可以是IDE插件，实时提醒研发使用不安全函数，给出替代方案，或者在提交代码到仓库时，进行代码增量扫描，或者上线前统一进行代码全量扫描。没有最好只有最适合。静态代码分析本身通常不足以替代人工代码评析。- 管理第三方组件安全风险(笔者添加的)
重要性不言而喻，微软官方还给了一些参考，比如分析组件、保持更新，建立应急计划

验证(对应的是测试阶段)

DAST与SAST一样，寻找最佳扫描时间
模糊测试
一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定以应用程序的预期用途以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试或扩大模糊测试的范围和增加持续时间。- 威胁模型和攻击面评析 (渗透测试笔者注)应用程序经常会严重偏离在软件开发项目要求和设计阶段所制定的功能和设计规范。因此，在给定应用程序完成编码后重新评析其威胁模型和攻击面度量是非常重要的。此评析可确保考虑到对系统设计或实现方面所做的全部更改，并确保因这些更改而形成的所有新攻击平台得以评析和缓解

发布

事件响应计划
受 SDL 要求约束的每个软件发布都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的程序也可能面临日后新出现的威胁。事件响应计划应包括：
单独指定的可持续工程 (SE) 团队；或者，如果团队太小以至于无法拥有 SE 资源，则应制定紧急响应计划 (ERP)，在该计划中确定相应的工程、市场营销、通信和管理人员充当发生安全紧急事件时的首要联系点。

与决策机构的电话联系（7 x 24 随时可用）。
针对从组织中其他小组继承的代码的安全维护计划。
针对获得许可的第三方代码的安全维护计划，包括文件名、版本、源代码、第三方联系信息以及要更的合同许可（如果适用）。

最终安全评析(FSR)通常要根据以前确定的质量门或 Bug 栏检查威胁模型、异常请求、工具输出和性能。
通过 FSR:在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解。通过 FSR 但有异常:在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题（例如，由以往的“设计水平”问题导致的漏洞）将记录下来，在下次发布时更正。需上报问题的 FSR:如果团队未满足所有 SDL 要求，并且安全顾问和产品团队无法达成可接受的折衷，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的 SDL 要求问题，或是上报给高级管理层进行抉择。- 发布/存档
必须对所有相关信息和数据进行存档，以便可以对软件进行发布后维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档、紧急响应计划、任何第三方软件的许可证和服务条款以及执行发布后维护任务所需的任何其他数据。

可选的安全活动

可选的安全活动通常在软件应用程序可能用于重要环境或方案时执行。这些活动通常由安全顾问在附加商定要求集中指定，以确保对某些软件组件进行更高级别的安全分析。本节中的实践可作为可选安全任务的示例，但不应将其视为详尽列表。- 人工代码评析
代码审计、敏感数据处理、功能检查(加密实现)- 渗透测试
模拟黑客发现威胁，修复漏洞
在 Internet 上可以找到许多声誉良好的有关软件漏洞的信息来源。在某些情况下，通过对在类似软件应用程序中发现的漏洞进行分析，可以为发现所开发软件中的潜在设计或实现问题获得一些启迪

相似应用程序的漏洞分析

其他过程要求

根本原因分析了解漏洞的确切本周，以防止不在出现同类错误
过程定期更新
软件威胁不是一成不变的。因此，用于保护软件安全的过程也不能一成不变。组织应从各种实践（如根本原因分析、策略更改以及技术和自动化改进）中汲取经验教训，并将其定期应用于 SDL。一般而言，更新按年度进行应该足矣。发现以前未知的新漏洞类型属于此规则的例外情况。如果出现此现象，则须立即对 SDL 进行非常规修订，以确保在继续进行时已应用缓解措施

应用程序安全验证过程

开发安全软件的组织自然会需要一种途径来验证是否遵循了 Microsoft SDL 所规定的过程。访问集中的开发和测试数据有助于在许多重要方案（如最终安全评析、SDL 要求异常处理和安全审核）中进行决策

结束语

本文是一个基本框架，开发团队应以本文为指导，实施SDL的时候结合考虑组织的时间、资源和业务运营方式。
也许有人会说，即使只对安全过程进行简单的综合，也可以在整体上改进安全和隐私，这些改进会超越独立执行的任务的价值。然而，当前计算环境中的威胁已从脚本小子以前对自我满足感的追求演进为大范围有组织的金融犯罪，最近甚至演化为国家战争的新战场。威胁所经历的这种演进强烈要求采用某种比典型零散方法可靠得多的方法实现软件安全。