加固计划书
SDL介绍
安全开发生命周期(SDL)是一种软件开发方法论,旨在通过将安全性纳入软件开发的各个阶段来创建更安全、更健壮的软件。SDL 由一系列阶段和活动组成,涵盖了从需求分析到维护的整个软件开发生命周期。以下是SDL的主要阶段和相关活动:
-
需求分析阶段:
-
安全需求收集:确定软件所需的安全功能和安全性要求。
-
威胁建模:识别可能的威胁和攻击向量,以及潜在的安全漏洞。
-
风险评估:评估各种威胁的潜在影响和风险级别。
-
-
设计阶段:
-
安全架构设计:设计安全的软件架构,包括安全边界、访问控制和身份验证机制等。
-
安全设计审查:对系统设计进行审查,以确保安全需求得到满足并且没有安全漏洞。
-
-
编码阶段:
-
安全编码指南:制定安全编码标准和最佳实践,以确保开发人员编写安全的代码。
-
代码审查:对编写的代码进行审查,以发现和修复安全漏洞。
-
-
测试阶段:
-
安全测试计划:制定安全测试策略和计划,包括静态分析、动态测试和渗透测试等。
-
漏洞扫描:使用自动化工具扫描代码和系统,以发现可能存在的安全漏洞。
-
安全测试:执行各种安全测试,包括认证、授权、加密和异常处理等方面的测试。
-
-
部署和维护阶段:
-
安全部署指南:制定安全部署流程和指南,确保在部署过程中保持软件的安全性。
-
安全更新和修补:及时修复已发现的安全漏洞,并持续监控和更新系统以应对新的威胁。
-
安全设计核心原则
-
Attack Surface Reduction:攻击面最小化
-
Basic Privacy: 基本隐私
-
Least Privilege: 权限最小化
-
Secure Defaults: 默认安全
-
Defense in Depth:纵深防御
-
Threat Modeling:威胁建模
-
攻击面最小化:
攻击面是指程序任何能被用户或者其它程序所访问到的部分,这些暴露给用户的地方往往也是最可能被恶意攻击者攻击的地方。
攻击面最小化即是指尽量减少暴露恶意用户可能发现并试图利用的攻击面数量。软件产品的受攻击面是一个混合体,不仅包括代码、接口、服务,也包括对所有用户提供服务的协议。尤其是那些未被验证或者远程的用户都可以访问到的协议,安全人员在攻击面最小化时首先要对攻击面进行分析,攻击面分析就是枚举所有访问入库、接口、协议一剂可执行代码的过程,从高层次来说,攻击面分析着重于:
- 降低默认执行的代码量
- 限制可访问到代码的人员范围
- 限定可访问到代码的人员身份
- 降低代码执行所需权限特征 Higher Attack Surface Lower Attack Surface 默认启用 开启 关闭 开放的套接字 开启 关闭 UDP 是 否 匿名访问 是 需要认证的用户 始终启用 是 根据需要启用 可通过互联网访问 是 仅本地子网可访问 -
基本隐私
用户使用软件时无可避免个人信息被收集、使用甚至分发,企业则有责任和义务建立保护个人信息的保护措施,抵御敌对攻击行为,确保用户基本隐私的安全性。隐私安全是建立可信任应用程序的关键因素。
在软件设计时考虑用户基本隐私的必要性及意义有: - 履行法律规定和义务 - 增加客户的信赖 - 防止堵塞部署
对于特殊的软件或者全球性的产品,设计人员需要明确软件的行为及针对人群。尤其要考虑当地国家的法律法规,如美国儿童网路隐私保护法COPPA(Children’s Online Privacy Protection Act)等,企业在开发产品、服务时有必要制定明确的隐私准则,对获取、记录用户隐私的相关产品需有明确的要求和指导建议。
-
权限最小化
如果一个应用程序或网站被攻击、破坏,权限最小化机制能够有效的将潜在损害最小化。常见的权限最小化实践如:
-
普通管理员/系统管理员等角色管理
-
文件只读权限/文件访问权限等访问控制
-
进程/服务以所需最小用户权限运行
在进行软件设计时,安全设计人员可以评估应用程序的行为及功能所需的最低限度权限及访问级别,从而合理分配相应的权限。如果程序特定情况必须要较高级别的权限,也可以考虑特权赋予及释放的机制。即便程序遭到攻击,也可以将损失降到最低。
Tips:
-
Windows系统中网络进程、本地服务、用户进程的权限都较低且互相独立,分别为NETWORK SERVICE、LOCAL SERVICE、user权限,只有核心的重要进程实用SYSTEM权限;
-
最新版本的Office程序打开不可信来源的文档时,默认时不可编辑的,同时也是默认不可执行代码的,即使存在缓冲区溢出漏洞,也不会执行shellcode等恶意代码;
-
-
默认安全
默认安全配置在客户熟悉安全配置选项之前不仅有利于更好的帮助客户掌握安全配置经验,同时也可以确保应用程序初始状态下处于较安全状态。而客户可根据实际使用情况而决定应用程序安全与隐私的等级水平是否降低。
Tips:
-
在Win 7之后的Windows操作系统中,DEP(数据执行保护)默认是开启的。用户可设置选项改变DEP的状态;
-
Win 10默认启用安全防护软件Windows Defender,用户可选择关闭;
-
-
纵深防御
与默认安全一样,纵深防御也是设计安全方案时的重要指导思想。纵深防御包含两层含义:首先,要在各个不同层面、不同方面实施安全方案,避免出现疏漏,不同安全方案之间需要相互配合,构成一个整体;其次,要在正确的地方做正确的事情,即:在解决根本问题的地方实施针对性的安全方案。
纵深防御并不是同一个安全方案要做两遍或多遍,而是要从不同的层面、不同的角度对系统做出整体的解决方案。
Tips:
-
针对XSS的防护,除了要对用户输入的特殊符号进行过滤,还要区分是否是富文本进而进行相应编码操作,在输入时过滤的同时在输出时也进行过滤操作。
-
即使做了十足的过滤、编码等安全防护,为了更一步确保缓解XSS攻击,Web站点也可以对Cookie启用HTTP-Only属性,确保即使发生XSS攻击,也可以阻止通过脚本访问Cookie的操作。
-
-
威胁建模
威胁建模是一种分析应用程序威胁的过程和方法。这里的威胁是指恶意用户可能会试图利用以破坏系统,和我们常说的漏洞并不相同。漏洞是一个特定的可以被利用的威胁,如缓冲区溢出、sql注入等。
作为SDL设计阶段的一部分安全活动,威胁建模允许安全设计人员尽在的识别潜在的安全问题并实施相应缓解措施。在设计阶段把潜在的威胁发现有助于威胁的全面和更有效的解决,同时也有助于降低开发和后期维护的成本。威胁建模的一般流程如下:
-
与系统架构师及设计人员沟通,了解设计详情
-
使用成熟的威胁建模方法分析当前设计潜在的安全问题
-
提出安全建议及对潜在威胁的缓解措施
-
对安全设计进行验证并对整个设计方案进行回顾并再次确认
微软使用的威胁建模方法是STRIDE威胁建模方法。为了便于安全人员快速便捷的进行威胁建模,微软开发基于STRIDE威胁建模方法的SDL Threat Modeling Tool[2]威胁建模工具,该工具可以帮助安全人员画数据流图、分析威胁、生成并导出威胁建模报告。
-
STRIDE威胁建模方法
-
STRIDE介绍
STRIDE威胁建模是由微软提出的一种威胁建模方法,该方法将威胁类型分为Spoofing(仿冒)、Tampering(篡改)、Repudiation(抵赖)、Information Disclosure(信息泄漏)、Denial of Service(拒绝服务)和 Elevation of Privilege(权限提升)。这六种威胁的首字母缩写即是STRIDE,STRIDE威胁模型几乎可以涵盖目前绝大部分安全问题。此外,STRIDE威胁建模方法有着详细的流程和方法。
-
威胁建模流程
-
绘制数据流图
-
识别威胁
-
提出缓解措施
-
安全验证
-
数据流图(Data Flow Diagrams)包含外部实体(External Entity)、处理过程(Process)、数据流(Data Flow)、数据存储(Data Store),安全人员与系统架构师及设计人员沟通,了解设计详情并画出数据流图后还需要标注信任边界(Trust Boundary),针对简单的Web应用的数据流图如下:
-
识别威胁
STRIDE威胁建模方法已经明确了每个数据流图元素具有不同的威胁,其中外部实体只有仿冒(S)、抵赖(R)威胁,数据流只有篡改(T)、信息泄露(I)、拒绝服务(D)威胁,处理过程有所有六种(STRIDE)威胁,存储过程有篡改(T)、信息泄露(I)、拒绝服务(D)威胁,但如果是日志类型存储则还有抵赖(R)威胁。具体可以对照如下表格进行威胁识别:
类型 元素 S T R I D E 外部实体 √ 处理过程 √ √ √ √ √ √ 数据存储 √? √ √ 数据流 √ √ -
缓解措施
根据不同的数据流图元素及威胁,相应的缓解措施也不相同。如本文示例数据流图中外部实体用户的仿冒威胁,其缓解措施简单来说就是对用户身份进行认证。对于一个Web应用来说,缓解仿冒威胁不仅需要较强的认证机制,还需要防止恶意攻击者用暴力破解、口令猜测等方法绕过认证从而造成仿冒用户的威胁。如果笔者来提出该用户仿冒威胁的缓解措施的话,详细措施如下:
-
对用户访问进行帐号密码、证书等身份认证;
-
用户帐号密码认证过程中,如果出现三次密码错误,则增加验证码机制。输入验证码且正确再进行身份认证;
-
当用户认证5次后仍然验证失败,则在30分钟内禁止该帐号登录;
-
用户密码必须包含数字、字母及特殊字符,且长度在8位以上,如果业务安全需要则增加密码过期机制,每隔6个月提醒用户修改密码; 在提出缓解措施时,有的时候不仅要考虑安全问题,同时也要考虑软件的易用性,所以不同的威胁,不同的应用场景。其缓解措施也要随之而改变以提高应用安全的同时也能给用户带来较好的交互体验。
-
-
| 威胁类型 | 缓解措施 | 技术方案 |
|-----------|-----------|----------|
| 仿冒(S) | 认证 | Kerberos认证, PKI系统如SSL/TLS证书, 数字签名 |
| 篡改(T) | 完整性保护 | 访问控制, 完整性校验 |
| 抵赖(R) | 日志审计 | 强认证, 安全日志、审计 |
| 信息泄露(I) | 保密性 | 加密, 访问控制列表 |
| 拒绝服务(D) | 可用性 | 访问控制列表, 过滤, 热备份 |
| 权限提升(E) | 授权认证 | 输入校验, 用户组管理, 访问控制列表 |
4. 安全验证
在威胁建模完成后,需要对整个过程进行回顾,不仅要确认缓解措施是否能够真正缓解潜在威胁,同时验证数据流图是否符合设计,代码实现是否符合预期设计,所有的威胁是否都有相应的缓解措施。最后将威胁建模报告留存档案,作为后续迭代开发、增量开发时威胁建模的参考依据。
加固措施
根据不同的数据流图元素及威胁,相应的应对也不相同。如本文示例数据流图中外部实体用户的仿冒威胁,其应对措施简单来说就是对用户身份进行认证。对于一个 Web 应用来说,应对仿冒威胁不仅需要较强的认证机制,还需要防止恶意攻击者用暴力破解、口令猜测等方法绕过认证从而造成仿冒用户的威胁。如果笔者来提出该用户仿冒威胁的缓解措施的话,详细措施如下:
-
对用户访问进行帐号密码、证书等身份认证;
-
用户帐号密码认证过程中,如果出现三次密码错误,则增加验证码机制。输入验证码且正确再进行身份认证;
-
当用户认证 5 次后仍然验证失败,则在 30 分钟内禁止该帐号登录;
-
用户密码必须包含数字、字母及特殊字符,且长度在 8 位以上,如果业务安全需要则增加密码过期机制,每隔 6 个月提醒用户修改密码;
在提出措施时,有的时候不仅要考虑安全问题,同时也要考虑软件的易用性,所以不同的威胁,不同的应用场景。其缓解措施也要随之而改变以提高应用安全的同时也能给用户带来较好的交互体验。
微软对于常用的威胁给出了其常用的标准缓解措施,并在具体实施时已将常用的缓解方案及措施集成为独立的解决方案或者代码模块。可以方便同类应用直接使用。
以下是你提供的威胁类型和缓解措施的原始数据转换成 Markdown 格式的内容:
威胁类型 | 缓解措施 | 技术方案 |
---|---|---|
仿冒(S) | 认证 | Kerberos认证, PKI系统如SSL/TLS证书, 数字签名 |
篡改(T) | 完整性保护 | 访问控制, 完整性校验 |
抵赖(R) | 日志审计 | 强认证, 安全日志、审计 |
信息泄露(I) | 保密性 | 加密, 访问控制列表 |
拒绝服务(D) | 可用性 | 访问控制列表, 过滤, 热备份 |
权限提升(E) | 授权认证 | 输入校验, 用户组管理, 访问控制列表 |
DREAD风险评估模型
DREAD是原来微软的风险评估威胁系统的一部分。这里有一篇微软的论文 link。由于此模型不稳定,比如可发现性难衡量、可复现性很多场景下不重要等,实际使用过程中有时评分十分不准确,所以微软在2008年可能弃用了此模型,例如,在ASRC中,微软使用Bug Bar来定义威胁风险。
DREAD提供了5个维度,进行威胁评级,每个维度0-10分。通过最后的评分确定威胁的严重程度。
维度 | 描述 | 评分 |
---|---|---|
Damage 危害程度 | 风险会造成怎样的危害?包括:系统受危害程度,泄露信息的数据敏感性,资金资产损失,公关法律风险。 | 0:无损失;5:一般损失10:巨大损失 |
Reproducibility 可复现性 | 重现攻击是否容易,风险是否可以稳定复现。 | 0:管理员也难以复现。5:授权用户需要复杂步骤。7:身份验证用户可通过简单步骤复现。10:只是一个Web浏览器即可复现。 |
Exploitability 利用难度 | 需要多少成本才能实现这个攻击,关注的重点是利用难度。 | 0:无法利用2:利用条件非常苛刻,难以利用4:利用有一定难度,利用非常复杂6:高级攻击者资质工具利用3分:中级攻击者利用10:新手可在简单工具下轻松利用 |
Affected users 影响面 | 可理解为系统业务的重要程度,重要业务好边缘业务对用户的影响是不同的。 | 0:无影响2.5:影响个别个人/雇主。6:一些个人或雇主权限的用户,非全部。8:影响管理用户。10:影响所有用户 |
Discoverability 发现难度 | 是否能被外界轻易发现,外界发现此风险是否需要较高成本。 | 0:需要源代码或管理访问权限。5:可通过监听HTTP请求发现。8:已公开poc,可轻松发现。10:在Web浏览器地址栏或表单中可见。 |
加固计划书
-
攻击面最小化安全设计核心原则
-
降低默认执行的代码量
-
限制可访问到代码的人员范围
-
限定可访问到代码的人员身份
-
降低代码执行所需权限
-
后端代码对用户输入的数据进行了校验
-
统一登录认证,所有业务都在认证中心登录,避免反复登录
-
-
基本隐私安全设计核心原则
- 在数据库中存储用户的密态个人信息,我们拟通过盐值对用户的密码进行加密,并在数据库中分别存储盐值与密态密钥
- 对出入方向的流量都要识别、控制和进行检验
- 日志和监控
-
权限最小化安全设计核心原则
-
用户只有发送请求和接受文件的权限
-
服务器只需要访问网络、读取数据库和向日志服务器写日志的权限
-
管理员可以随时调整用户的权限,为用户赋予相应的角色,这里的权限包括:
-
文件管理:
-
列表
-
新增
-
删除
-
-
接受文件列表:
-
列表
-
新增
-
删除
-
-
-
默认安全安全设计核心原则
-
会话管理:登录后建立新的会话,确保会话数据安全,确保会话数据传输安全,应及时终止会话,应设计合理的会话存活时间,避免跨站请求伪造
-
审核与日志检查
-
身份认证
-
输入与输出验证:对所有来源不明的数据进行验证,对用户输入采用多种验证方法(白名单、特殊字符、正确的数据类型、和克里的数据长度等)
-
配置管理:确保配置存储的安全,应使用最小特权进程和服务账户,确保管理界面的安全,避免调用系统低层资源,应单独分配管理特权。
-
参数操作:避免使用包含敏感词汇的查询参数,加密查询字符串参数,不信任任何HTTP头,确保用户没有绕过检查
-
-
威胁建模安全设计核心原则
-
绘制数据流图,识别定义威胁、处置威胁、验证风险得到正确处理
-
确立安全目标
-
可以尝试使用Nginx等反向代理软件, 使攻击者不能通过request.getRemoteAddr()获取IP地址
-
日志和监控
-
制定缓解措施来对预定好的威胁进行缓解
-
-
纵深防御安全设计核心原则
-
应用对输入数据进行有效性验证或进行参数化查询。
-
数据加密存储。
-
对数据库进行安全配置或关闭不必要的强大功能。
-
数据库连接账户隔离以及权限最小化
-
-
安全漏洞修复和漏洞管理
-
实施定期的漏洞扫描和评估以识别潜在的安全风险
-
及时应用补丁和更新以修复已知的漏洞
-
建立一个安全漏洞报告和响应流程,以便及时响应发现的漏洞
-
持续改进我们的代码审查流程,以确保新代码不会引入新的漏洞
-
-
应急响应计划
我们将建立一个完善的应急响应计划,以应对可能发生的安全事件,该计划将包括以下关键步骤:
-
确定安全事件的类型和严重程度
-
隔离受影响的系统或资源,以阻止进一步损害
-
收集和保护相关的日志和证据,以便进行后续调查和分析
-
通知相关方,包括管理层、内部团队和相关的法律和监管机构
-
恢复受影响系统的正常运行,并采取预防措施,防止类似事件再次发生
-
-
培训与意识提升
我们将建议使用本系统的贵公司开展定期的安全培训和意识提升活动,以提高所有员工对安全问题的认识和警惕性,培养良好的安全习惯和行为,包括:
-
有针对性地针对不同岗位的员工提供安全培训,以满足其特定的安全需求
-
定期举办模拟演练和应急响应演练,以提高员工应对安全事件的能力和效率
-
向员工提供及时的安全更新和警报,以增强其对当前安全威胁的认识和理解
-