SDL

SDL安全设计核心原则

1．攻击面最小（Attack Surface Reduction）

攻击面是指系统任何能被用户或者其它系统所访问到的部分，这些暴露给用户的地方往往也是最可能被恶意攻击者攻击的地方。

攻击面最小化即是指尽量减少暴露恶意用户可能发现并试图利用的攻击面数量。

系统的受攻击面是一个混合体，不仅包括代码、接口、服务，也包括对所有用户提供服务的协议。尤其是那些未被验证或者远程的用户都可以访问到的协议，安全人员在攻击面最小化时首先要对攻击面进行分析，攻击面分析就是枚举所有访问入库、接口、协议一切可执行代码的过程，从高层次来说，攻击面分析着重于:

• 降低默认执行的代码量（非必要功能默认未开启）

• 限制可访问到代码的人员范围（部分功能仅对内部开放）

• 限定可访问到代码的人员身份（认证鉴权）

• 降低代码执行所需权限（使用低权限用户运行程序）

2．基本隐私（Basic Privacy）

用户使用软件时无可避免个人信息被收集、使用甚至分发，企业则有责任和义务建立保护个人信息的保护措施，抵御敌对攻击行为，确保用户基本隐私的安全性。隐私安全是建立可信任应用程序的关键因素。

在软件设计时考虑用户基本隐私的必要性及意义有:

• 履行法律规定和义务

• 增加客户的信赖

对于特殊的软件或者全球性的产品，设计人员需要明确软件的行为及针对人群。尤其要考虑当地国家的法律法规，如美国儿童网路隐私保护法COPPA(Children’s Online Privacy Protection Act)等，企业在开发产品、服务时有必要制定明确的隐私准则，对获取、记录用户隐私的相关产品需有明确的要求和指导建议。

基本隐私的案例：

• 只收集程序必须用到的隐私数据，并明确告知用户并征得用户同意；

• 对于用户隐私数据如密码、口令等均需要加密存储，最低要求是sha256+salt，对于更高要求的则使用PBKDF2算法加密存储。

3．权限最小化（Least Privilege）

如果一个应用程序或网站被攻击、破坏，权限最小化机制能够有效的将潜在损害最小化。

常见的权限最小化实践：

• 普通管理员/系统管理员等角色管理

• 文件只读权限/文件访问权限等访问控制

• 进程/服务以所需最小用户权限运行

在软件设计时，安全设计人员可以评估应用程序的行为及功能所需的最低限度权限及访问级别，从而合理分配相应的权限。如果程序特定情况必须要较高级别的权限，也可以考虑特权赋予及释放的机制。即便程序遭到攻击，也可以将损失降到最低。

权限最小化的案例：

• Windows系统中网络进程、本地服务、用户进程的权限都较低且互相独立，分别为NETWORK SERVICE、LOCAL SERVICE、user权限，只有核心的重要进程实用SYSTEM权限；

• 最新版本的Office程序打开不可信来源的文档时，默认时不可编辑的，同时也是默认不可执行代码的，即使存在缓冲区溢出漏洞，也不会执行shellcode等恶意代码。

4．默认安全配置（Secure Defaults）

在客户熟悉安全配置选项之前，默认安全配置不仅有利于更好的帮助客户掌握安全配置经验，同时也可以确保应用程序初始状态下处于较安全状态。之后再让客户可根据实际使用情况而决定应用程序安全与隐私的等级水平是否降低。

默认安全配置的案例：

• 在Win 7之后的Windows操作系统中，DEP(数据执行保护)默认是开启的。用户可设置选项改变DEP的状态；

• Win 10默认启用安全防护软件Windows Defender，用户可选择关闭。

5．纵深防御（Defense in Depth）

纵深防御包含两层含义：首先，要在各个不同层面、不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要相互配合，构成一个整体；其次，要在正确的地方做正确的事情，即在解决根本问题的地方实施针对性的安全方案。

纵深防御并不是同一个安全方案要做两遍或多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。与默认安全一样，纵深防御也是设计安全方案时的重要指导思想。

纵深防御的案例：

• 针对XSS的防护，除了要对用户输入的特殊符号进行过滤，还要区分是否是富文本，是则进行相应编码操作，在输入端过滤的同时在输出端也进行过滤操作。

• 即使做了十足的过滤、编码等安全防护，为了更一步确保缓解XSS攻击，Web站点也可以对Cookie启用HTTP-Only属性，确保即使发生XSS攻击，也可以阻止通过脚本访问Cookie的操作。

6．威胁建模（Threat Modeling）

威胁建模是一种分析应用程序威胁的过程和方法，通过识别目标和漏洞来优化系统安全，然后定义防范或减轻系统威胁的对策的过程。使开发者能够识别，量化和解决与应用程序相关的安全风险。

例如下图，通过威胁建模，使审阅者更好地理解系统，便于分析系统的入口点以及每个入口点的相关威胁。

                                                                         威胁建模示例

威胁建模可以在软件设计和在线运行时进行。威胁建模在新系统/新功能开发的设计阶段，通过威胁建模可帮助安全设计人员识别潜在的安全问题并实施相应缓解措施，也有助于降低开发和后期维护的成本；如果系统已经上线运行，威胁建模可作为渗透测试的辅助工作，帮助测试人员尽可能的发现所有的漏洞。

威胁建模的一般流程如下:

• 与系统架构师及设计人员沟通，了解设计详情；

• 使用成熟的威胁建模方法分析当前设计潜在的安全问题；

• 提出安全建议及对潜在威胁的缓解措施；

• 对安全设计进行验证并对整个设计方案进行回顾并再次确认。

微软在过去的几年里一直是威胁建模的强有力的倡导者。他们已经将威胁建模作为其SDLC的核心组件，使用的威胁建模方法是STRIDE威胁建模方法。参考链接：https://xz.aliyun.com/t/2061

为了便于安全人员快速便捷的进行威胁建模，微软开发基于STRIDE威胁建模方法的SDL Threat Modeling Tool[2]威胁建模工具，该工具可以帮助安全人员画数据流图、分析威胁、生成并导出威胁建模报告。

SDL流程框架

SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段：需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。

安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

                                                         SDL安全开发生命周期流程框架

SDL的安全实践要求

1．培训

开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员、测试人员、项目经理、产品经理等。

2．安全要求（基准）

1）确定安全计划。在项目确立之前，需要提前与项目经理进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。

2）设立安全基线和安全分级。安全基线用于确定安全风险的最低可接受级别，安全分级用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。安全基线和安全分级一经设定，便绝不能放松。

3）安全和隐私风险评估。对系统可能面临的威胁、存在的弱点、造成的影响，以及三者综合作用所带来风险的可能性的评估，量化系统遭受攻击带来的影响或损失的可能程度。

3．设计

1）确定设计安全要求。在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。

2）威胁建模。为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面。

3）减少攻击面。减小攻击面与威胁建模紧密相关，通过减小攻击者利用潜在弱点或漏洞的机会来降低风险，减小攻击面包括：关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能进行分层防御。

4．实施（开发）

1）使用指定的工具。开发团队使用的编辑器、链接器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。

2）弃用不安全函数。许多常用函数可能存在安全隐患，应当禁用不安全的函数和API，使用安全团队推荐的函数。

3）代码静态分析（SAST）。代码静态分析可以帮助软件开发人员、质量保证人员查找代码中存在的结构性错误、安全漏洞等问题，从而保证软件的整体质量。

5．验证（测试）

1）程序动态分析（DAST）。动态分析是静态分析的补充，用在程序运行时，测试验证程序的安全性，也称作“黑箱测试”。通过模拟黑客行为对系统进行动态攻击，分析系统的反应，从而确定该系统是否易受攻击。

2）模糊测试（Fuzzing Test）。模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。

3）威胁模型和攻击面评析。项目经常会因为需求等因素导致最终的产出偏离原本设定的目标，因此在项目后期对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。

6．发布

1）制定事件响应计划。SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。需要注意的是，如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。

2）最终安全评析（FSR）。指在产品发布前，对比安全基准确定产品不符合安全基准、缺少功能和其他要求的区域，然后进行以下三种决策：

1、通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解；

2、通过FSR但有异常。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来，在下次发布时更正。

3、需上报问题的FSR。如果团队未满足所有SDL要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可解决的问题，或者上报高级管理层进行抉择。

3）发布/存档。在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档，为紧急响应和产品升级提供帮助。

7．响应

当软件发布后遭受攻击时，根据制定的应急响应计划快速采取措施，把事件造成的损失降到最小。这里还可以加入应急响应演练，以加强公司对抗信息安全攻击的能力。