20181215实验报告——实验二：电子公文传输系统安全性设计方案与实现

目录

实验二 电子公文

密码功能要求

在openEuler(推荐)或Ubuntu或Windows(不推荐)中完成下面任务

浏览附件中的《Core.Software.Security.Security.at.the.Source.CN.软件安全.从源头开始》，《The.Security.Development.Lifecycle.CN.软件安全开发生命周期》两本图书，总结读书笔记，重点是SDLsecurity development lifecycle，安全开发生命周期），小组每人要提交一份自己的笔记（markdown文档，每人一份）

小组讨论电子公文传输系统，如何应用SDL对电子公文系统进行加团，给出一份加固计划书，其中重点要包含系统资源的分析，基于STRIDE模型的威胁分析以及基于DREAD模型的风险分析，人员分工，开发计划（每周至少提交一份进展报告），提交安全性设计方案（markdown文档，每组一份，不要发网上）

参考 《GMT 0007 2012 电子政务电子认证服务应用指南》, GMT 0054-2018 《信息系统密码应用基本要求》和 国家标准GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》提交一份系统安全性设计报告，重点是密码方案的应用（markdown文档，每组一份，不要发网上）

密码算法库：

龙脉uKey
Bouncy Castle(支持Java )(https://www.bouncycastle.org/latest_releases.html)
GMSSL 的API（支持Java，Go，PHP） http://gmssl.org/docs/docindex.html
OpenSSL

1.系统密码功能要求

? 安全性要求是无纸化电子公文传输系统首先要满足的要求。由于网络环境的广泛性和复杂性等特点，普通电子文件很容易在网络传输过程中被截取或篡改。而电子公文文件必须具有保密性、严肃性和不可抵赖性的特性，绝对不允许出现此类安全漏洞。为此我们采用了RSA不对称加密方法，借助通过国家商业密码委员会认证的硬件加密产品，实施电子公文文件的加密操作。具体来说，公文的生成和制作首先要运用公文制作单位的加密狗，通过该单位的硬件私钥密码，以时间戳方式进行电子数字签名，确保该公文的合法性、可识别性、严肃性和法律性。在公文的发送过程中，根据收文单位，获取对应收文单位的公钥，以该公钥对公文文件进行加密，输出给收文单位。收文单位获取收文后，首先通过自己加密狗的私钥对收文进行RsA解密，再对解密后的收文，以发文单位的公钥进行收文的电子签名验证，确定来文的合法性。整个过程可简单表示为:公文草件一(电子签名)。电子公文一(RSA加密)斗传输一(RSA解密)一收文一(电子签名验证)。阅读时，对所有公章等关键信息进行矢量化操作，确保这类关键信息不被非法截获和使用，具体要做以下操作:读入BMP图片文件，接着解读BMP点阵，构造矢量数据，存贮矢量数据。以本单位加密狗私钥对存储的矢量数据进行电子签名，使矢量章具备可识别性和法律严肃性。用本单位加密钩公钥及时间戳对已签名公章文件实施RS八加密，从而构造获得加密后的公章文件。
2.密码技术应用要求
? 要保障电子公文的畅通传输，必须尽可能地降低网络传输的数据量，以适应复杂的网络环境。因此在数据加密之前，首先要利用Lzw算法进行数据压缩处理，使文本文件的压缩率将近1/1000从而有效控制公文传输的数据量。
3.应用和数据安全
由于电子公文传输系统的使用对象涉及政府部门及相关单位实际操作人数较多，因此其操作必须力求简洁、方便。为此在设计上仿照电子邮件的操作模式，由收件箱·发件箱、系统设置等模块构成，操作人员只要学会电子邮件的收发，就能立即掌握无纸化电子公文传输系统的基本操作。
公文接收方浏览器如同WEB浏览器，其运行环境是复杂和多样的，优秀的公文接收浏览软件必须能适应多种多样的软件环境。为此无纸化电子公文传输系统提供了图档化的电子公文传输模式，从而使公文接收端可以无须与公文的发送端具有相同的软件环境，如不需要相同的字体环境、不需要相同的操作系统(要求是WIN9X以上操作系统)、不需要相同的字处理软件等。
优秀的软件系统一定是一个开放的系统，必须能够提供有效的途径，与用户的其他相关系统之间进行数据交换。无纸化电子公文传输系统提供了以复印件图片文件形式输出公文的能力，使其他系统可以直接引入、利用所接收的公文数据。
第三级密码应用基本要求
1.物理和环境安全
1.真实性：物理访问控制的身份鉴别信息，重要区域进入人员身份
2.完整性：电子门禁系统进出记录
3.完整性：视频监控音像记录
4.宜使用硬件密码产品实现密码运算和密钥管理，符合GM/T0028三级以上密码模块或通过国家密码管理部门核准
2.网络和通信安全
1.机密性+真实性：通信双方进行身份认证，防截获，防假冒，防重用，保证传输过程中的鉴别信息的机密性，网络设备实体身份的真实性
2.完整性：网络边界和系统资源访问控制信息
3.完整性：通信过程中的数据
4.机密性：通信过程中的敏感数据信息字段或整个报文
5.建立安全信息传输通道，集中管理安全设备、组件
6.宜使用硬件密码产品实现密码运算和密钥管理，符合GM/T0028三级以上密码模块或通过国家密码管理部门核准
3.设备和计算安全
1.对登陆的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度且定期更换
2.机密性：远程管理是实现鉴别信息防窃听
3.完整性：系统资源访问控制信息
4.完整性：重要资源信息敏感标记
5.可信计算技术：系统到应用的信任链保护重要程序或文件完整性
6.完整性：日志记录
7.宜使用硬件密码产品实现密码运算和密钥管理，符合GM/T0028三级以上密码模块或通过国家密码管理部门核准
4.应用和数据安全
1.真实性：应用系统用户身份——对登陆的用户进行身份标识和鉴别，实现身份鉴别信息的防截获防假冒和防重用
2.完整性：业务应用系统访问控制策略，数据库表访问控制信息，重要信息资源敏感标记
3.机密性：传输中的鉴别数据，重要业务数据和重要用户信息
4.机密性：存储中的鉴别数据，重要业务数据和重要用户信息
5.完整性：传输中的鉴别数据，重要业务数据，重要审计数据，重要配置数据，重要视频数据和重要用户信息
6.完整性：存储中的鉴别数据，重要业务数据，重要审计数据，重要配置数据，重要视频数据和重要用户信息和中药可执行程序
7.完整性：日志记录
8.安全控制：重要应用程序的加载和卸载
9.宜使用硬件密码产品实现密码运算和密钥管理，符合GM/T0028三级以上密码模块或通过国家密码管理部门核准
5.密钥管理
信息系统密钥管理应包括对密钥的生成，存储，分发，导入，导出，使用，备份，恢复，归档与销毁等环节进行管理和策略制定的全过程。
1.生成：
密钥生成使用的随机数应符合GM/T0005要求，密钥应在符合GM/T0028的密码模块内部产生，不得以明文方式出现在密码模块外；
应具备检查和剔除弱密钥的能力。
2.存储：
密钥应加密存储，并采取严格的安全防护措施，防止密钥被非法获取；
密钥加密密钥应存储在符合GM/T0028的二级及以上密码模块中。
3.分发：
应采取身份鉴别、数据完整性、数据机密性等安全措施，能抗截取、假冒、篡改、重放等攻击
4.导入与导出：
应采取安全措施，防止密钥导入导出时被非法获取或篡改，并保证密钥的正确性存疑
5.使用：
密钥应明确用途，并按正确用途使用；
使用公钥密码体系之前应验证公钥；
应有安全措施防止迷药的泄露和替换；
密钥泄露时，应停止使用，病启动相应的应急处理和响应措施；
按照要求定期更换密钥，并保证密钥更换时的安全性
6.备份与恢复
应制定明确的密钥备份策略，采用安全可靠的秘钥备份恢复机制；
备份或恢复时要记录，并生成审计信息，包括备份或恢复的主体、时间等
7.归档
采取有效的安全措施保证归档密钥的安全性和正确性
归档密钥只能用于解密该秘钥加密的历史信息或验证该秘钥签名的历史信息；
记录并生成审计信息
归档密钥进行数据备份并保护
8.销毁
应具有在紧急情况下销毁密钥的措施如何定义紧急情况？
6.安全管理
制度
1.密码安全管理制度及操作规范：包括密码建设，运维，人员，设备，密钥等
2.定期重审修订上文的不足之处
3.明确相关管理制度发布流程
人员
1.了解并遵守密码相关法律法规
2.正确使用密码产品
3.建立岗位责任制度，明确职责和权限，对关键岗位建立多人公关机制；密钥管理，安全审计，密码操作人员职责互相制约互相监督，相关设备和系统的管理账号不得多人共用
4.建立培训制度，对密码和密钥管理人员专门培训
5.建立关键岗位人员保密制度和调离制度，签订保密合同
6.建立人员考核制度，建立奖惩制度
实施
1.规划：
信息系统规划阶段，责任单位应依据密码相关标准，制定密码应用方案，组织专家进行评审，评审意见作为项目规划立项的重要材料。
通过专家审定后的方案应作为建设，验收和测评的重要依据。
2.建设：
应按照国家相关标准制定实施方案，至少包含：信息系统概述，安全需求分析，密码系统设计方案，密码产品清单（资质，功能，性能列表，生产单位），密码系统安全管理与维护策略，密码系统实施计划等。
应选用经过国家密码管理部门核准的密码产品、许可的密码服务。
3.运行：
运行前：经密评机构评估通过后方可正式运行
运行后：每年开展密码应用安全性评估并进行整改；重大安全隐患需停止系统运行，整改通过后再投入
应急
1.制定应急预案，做好应急资源准备
2.事件发生后应及时向信息系统的上级主管部门进行报告
3.处置完成后，应及时向同级 的密码主管部门报告事件发生情况及处置情况
电子公文传输系统应用基本要求
1.范围
? 本标准规定了信息系统第一级到第四级的密码应用的基本要求，从信息系统的物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个技术层面提出第一级到第四级的密码应用技术要求并从管理制度、人员管理、建设运行和应急处置四个方面提出第一级到第四级的密码应用管理要求。
注：第五级密码应用仅在本标准中描述通用要求.第五级密码应用技术要求和管理要求不在本标准中描述。
2.规范性引用文件
? 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件.仅注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
3.术语和定义
（1）机密性 ：保证信息不被泄露给北授权实体的性质。
（2）数据完整性 ：数据没石遭受以非授权方式所作的改变的性质。
（3）真实性：一个实体是其所声称实体的这种特性。真实性适用于用户、避程、系统和信息之类的实体。
（4）不可否认性：证明一个已经发生的操作行为无法否认的性质。
（5）加密 ：对数据进行密码变换以产生密文的过程。
（6）密钥：控制密码算法运算的关键信息或参数。
（7）密钥管理 ：根据安全策略，对密钥的产生、分发、存储、使用、更新、归档、撤销、备份、恢复和销毁等密钥全生存 周期的管理。
（8）身份鉴别 ：证实一个实体所声称身份的过程。
（9）消息鉴别码利用对称密码技术或密码杂凑技术.在秘密密钥参与下，由消息所导出的数据项任何持有这一秘密密钥的实体，可利用消息鉴别码检查消息的完整性和始发者身份。
（10）动态口令：基于时间、事件等方式动态生成的…次性口令。
（11）访问控制 ：按照特定策略?允许或拒绝用户对资源访问的一种机制。
4.概述

4.1信息系统密码应用技术框架

4.1.1框架概述

? 本标准从信息系统的物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个层 而提出密码应用技术要求.保障信息系统的实体身份真实性、重要数据的机密性和完整性、操作行为的 不可否认性;并从信息系统的管理制度、人员管理、建设运行和应急处置四个方面提出密码应用管理要求为信息系统提供管理方面的密码应用安全保障。

4.1.2密码应用技术要求维度

? 技术要求主要由机密性、完整性、真实性、不可否认性四个密码安全功能维度构成.具体保护对象或 应用场景描述如下：
a）机密性技术要求保护对象
? 使用密码技术的加解密功能实现机密性.信息系统中保护的对象为：
1）身份鉴别信息；
2）密钥数据；
3）传输的重要数据；
4）信息系统应用中所有存储的重要数据。
b）完整性技术要求保护对象
? 使用基于对称密码算法或、基于公钥密码算法的数字名机 制等密码技术实现完整性信息系统中保护的对象为：
1）身份鉴别信息；
2）密钥数据；
3）日志讪录；
4）访问控制信息；
5）重要信息资源安全标记；
6）重要可执行程序；
7）视频监控音像记录；
8）电子门禁系统进出记录；
9）传输的重要数据；
10）信息系统应用中所有存储的重要数据。
c）真实性技术要求应用场景
? 使用动态口令机制、基于对称密码算法或密码杂凑算法的消息鉴别码机制、基于公钥密码算法 的数字签名机制等密码技术实现真实性?信息系统中应用场景为：
1）进入重要物理区域人员的身份鉴别；
2）通信双方的身份鉴别；
3）网络设备接入时的身份鉴别；
4）重要可执行程序的来源真实性保证；
5）登录操作系统和数据库系统的用户身份鉴别；
6）应用系统的用户身份鉴别。
d）不可否认性技术要求保护对象
? 使用基于公钥密码算法的数字签名机制等密码技术来保证数据原发行为的不可否认性和数据 接收行为的不可否认性。

4.1.3密码应用管理要求维度

? 管理要求由管理制度、人员管理、建设运行、应急处置等四个密码应用管理维度构成?具体如下：
a）密码应用安全管理相关流程制度的制定、发布、修订的规范性要求；
b）密码相关安全人员的密码安全意识以及关键密码安全岗位员T?的密码安全能力的培养.人员 工作流程要求等；
c）建设运行过程中密码应用安全要求及方案落地执行的?致性和石效性要求；
d）处理密码应用安全相关的应急突发事件的能力要求。

4.2密码应用基本要求等级描述

? 本标准对信息系统密码应用划分为自低向高的五个等级,参照GB/T 22239的等级保护对象应具 备的基本安全保护能力要求,本标准提出密码保障能力逐级增强的要求,用一、二、三、四、五表示。信息系统管理者可按照业务实际情况选择相应级别的密码保障技术能力及管理能力，各等级描述如下：
——第一级，是信息系统密码应用安全要求等级的最低等级.要求信息系统符合通用要求和最低限 度的管理要求，鼓励使用密码保障信息系统安全；
——第二级，是在第一级要求的基础上增加操作规程、人员上岗培训与考核、应急预案等管理要求并要求优先选择使用密码保障信息系统安全；
——第三级，是在第二级要求的基础上，增加对真实性、机密性的技术要求以及全部的管理要求；
——第四级，是在第三级要求的基础上，增加对完整性、不可否认性的技术要求；
5.通用要求
? 第一级到第五级的信息系统应符合以下通用要求：
a）信息系统中使用的密码算法应符合法律、法规的规定和密码相关国家标准、行业标准的有关 要求；
b）信息系统中使用的密码技术应遵循密码相关国家标准和行业标准；
c）信息系统中使用的密码产品、密码服务应符合法律法规的相关要求。
电子公文传输系统安全性设计方案
1.安全需求
身份认证
身份认证体现在数据库登录时连接数据库的用户所具有的角色，管理员和普通用户所属的数据库角色是不一样的，对于特定的表项，普通用户是没有查看和修改的权限的。
数据机密性
在数据传输过程中，要根据实现协商好的密码协议进行通信，在数据的传输过程中不能被中间黑客截获未加密的数据。通信双方需要实现配置好安全协议、分配好密钥。
数据完整性
在文件传输时，需要生成相应的MAC值，接收方再次生成MAC与发送方的MAC比对，比对成功时数据才算有效。
数据不可抵赖性
数据传输的过程中，发送方需要用私钥对文件进行签名，接收方用公钥进行验签，验证成功才能确定发送方的身份。签名和摘要可以同时进行。
2.认证协议
? 身份认证协议包括服务器和客户梯两方完成服务器对客户押的身份认证及访问脸制。具体要求客户境持有加密卡既保存RSA私钥又支持随机数生成、SHA1SHA-256摘要、RSA签名等密码运算功能服务器持有RSA公钥,具有随机数生成、SHA-1/SHA-256摘要、RSA签名验证功能(可通过挂接密码运算软、硬件产品获得相关支撑)。协议流程如图所示

该协议特点:
（1）在初始阶段,可生成若干对RSA密钥对灌入加密卡,每个应用可选用其中的一对密钥.而加密卡则可为多个应用提供密码服务;
（2）应用中私钥不会流出加密卡,也不会被暴力破解,具有高的安全性;
（3）加密卡发卡过程简单,部署应用简便。

2.1密码设备访问接口技术

? 目前,对于商用密码设备的功能访问和开发存在多种接口,包括专用接口和通用接口(也称为规范性接口)。通常密码设备厂商会提供涵盖两种形式的接口,供开发调用。专用接口对应特定密码功能,将密码应用中技术专业性较强的部分封装起来.开发者无须花费较大的时间成本,即可进行业务开发,但基于专用接口开发的系统在扩展性及移植性上会受到限制。对于通用接口,国际和国内均推出了商用密码领域被广泛接受的技术规范和标准,国际上有RSA组织推出的PKCS#11标准(Cryptographic Token Interface Standard,密码令牌接口标准[2),我国国家密码管理局颁布的《密码设备应用接口规范》(GM/T 0018-2012标准)。遵循通用接口规范开发的系统.在扩展性、可移植性、底层设备兼容性等方面有很大的灵活度。但通用接口并不能包涵密码应用的所有方面,如通用接口规范对密钥管理部分未提出较多定义.对于密钥的安全备份和恢复等操作还需借助专用接口。本文采用专用接口与通用接口相结合的方式。

2.2身份认证协议的安全性设计

2.2.1密码设备访问接口技术

? 目前,对于商用密码设备的功能访问和开发存在多种接口,包括专用接口和通用接口(也称为规范性接口)。通常密码设备厂商会提供涵盖两种形式的接口,供开发调用。专用接口对应特定密码功能,将密码应用中技术专业性较强的部分封装起来.开发者无须花费较大的时间成本,即可进行业务开发,但基于专用接口开发的系统在扩展性及移植性上会受到限制。对于通用接口,国际和国内均推出了商用密码领域被广泛接受的技术规范和标准,国际上有RSA组织推出的PKCS#11标准(Cryptographic Token Interface Standard,密码令牌接口标准[2),我国国家密码管理局颁布的《密码设备应用接口规范》(GM/T 0018-2012标准)。遵循通用接口规范开发的系统.在扩展性、可移植性、底层设备兼容性等方面有很大的灵活度。但通用接口并不能包涵密码应用的所有方面,如通用接口规范对密钥管理部分未提出较多定义.对于密钥的安全备份和恢复等操作还需借助专用接口。本文采用专用接口与通用接口相结合的方式。

2.2.2身份认证协议的安全性设计

? 本文提出的协议是基于RSA算法的签名与验证原理,是公钥密码算法的一个应用。公钥密码算法意味着公钥在一定程度上是可以公开的,很可能受到选择密文攻击[3].这意味着不能让私钥拥有者对任何接收到的随机消息都执行数字签名。本文提出在签名过程中由加密卡产生另一预处理数据,以保证签名消息来源的可靠性,对两项数据进行处理后再进行数字签名,可有效防止选择密文攻击。在实际应用中或对于安全性要求更高的业务应用,可将RSA密钥长度升级为更长的RSA2048/4096,或者将RSA算法替换为ECC算法或SM2算法(安全性及密钥长度可参考ECC算法)。
3.数据库加固
4.安全传输
安全的电子公文传输要求：
数据加密和解密
应该使用安全的密码协议进行通信、
保护系统和用户的密钥
在数据的传输过程中不能被中间人截获未加密的数据。
信息摘要计算
传输中使用安全的摘要算法生成相应的MAC值
MAC值需要附在传输的数据后面进行验证
数字签名及验证
数字签名保证数据的不可抵赖性
生成高质量随机数
通过高质量随机数对系统进行抗重放攻击保护
其它与安全有关的系统功能的实现

《The.Security.Development.Lifecycle.CN.软件安全开发生命周期》

第1章 适可而止∶ 威胁正在悄然改变

1.1 遍布安全和隐私冲突的世界

	隐私与安全
	很多人将隐私和安全看做是对同一问题的在不同角度的理解。然而，隐私可以看做是遵守策略的一种方式，而安全则看做是一种执行策略的方式。假如以休息室（Restroom）来作类比，房间门上的标识规定谁能够进入，但可能并没有安全措施阻止任何试图进入的人员。房间门上加把锁则能够确保安全，有助于隐私策略的落实。
	备注 隐私问题的核心是符合监管部门的要求（Security Innovation 2006）、公司策略和 客户期望。
	备注 风险管理能够为数据泄漏所带来风险进行赋值（可货币衡量 ）。
	警告，有些人抱怨他们无法默认以管理员或根账户的身份运行系统。我们对此的答复是;设置这一策略有助于在 Windows Vista中强制实施基本变更（change）;默认情形下，用户仅意味着普通用户而非系统管理员。本地管理员组成员都是用户，除非需要提升权限以执行管理任务。虽然以普通用户身份运行可以获得一定安全保障，但就隐私保护而言，成效仍有限。事实上，以用户身份运行的恶意代码仍然可以访问任何敏感数据，只要这些数据能被用户读取。

1.2 影响安全的另一因素∶ 可靠性

	备注 微软可信计算最初关注四个方面，其中三个属于技术方面，可以解决我们之前讨论过的问题∶安全、隐私和可靠性（第四个是业务实践活动）。选择这三个技术方面并非偶然。

1.3 事关质量

	●安全和隐私 例如，使用加密机制来减少隐私类问题，这本身就是一种安全技术。
	● 安全和可靠性 例如，DoS 威胁本身就是可靠性问题。
	●可靠性和隐私 例如，如果应用软件崩溃或失效后，在返回的错误消息中记录了敏 感信息。这也是一种安全问题。范围∶你可能也已觉察到，隐私、安全和可靠性方面的内容已经超出了图中质量环的所在
	●安全 如果用户将恶意软件装入计算机，这属于安全问题，并不是安全质量问题。 ●隐私 如果用户主动向不可信的攻击者透漏个人数据，例如在"钓鱼"攻击的情形 下，这便不属于隐私质量问题。
	●可靠性 如果用户无意中摔倒并带掉了电源线，这也不属于软件可靠性质量问题。
	我们想说的是，安全不应被视为一个孤立的问题。只有将其与隐私、可靠性和质量作 为整体进行思考，安全才具有商业价值。从这点出发，你才有充分得理由向高层管理者们 "推销"安全软件改进的理念。
	重要 导致敏感、机密或个人身份数据泄漏的安全 bug 属于隐私类问题，并可能导致法律后果。引发可靠性问题的安全 bug 则可能减少系统正常运行时间，并致使系统违反服务水平协议 (SLA )

1.4 主要的软件开发商为什么需要开发更安全的软件

	如果你的软件拥有众多用户，那么改善软件安全就是理所当然的事情;采用安全更新所带来的高昂成本则会促使安全、隐私以及可靠性问题得以尽早解决，而不是将这一包袱留给用户去承受。坦白地说，如果你拥有大量用户，产品的每一个安全 bug 都会将众多的用户置于遭受攻击或更严重的非法利用的风险之下，因为确保补丁百分百的部署程度是完全不可能的，这就意味着大量用户仍将面临风险。

1.5 内部软件开发人员为什么需要开发更安全的软件

	对于内部开发人员而言，实施 SDL 的主要获益在于降低隐私和可靠性泄露的风险。尽管有直接的安全收益，但正如我们之前提到的，内部应用软件的安全收益难以被量化。隐私是高层管理者和风险管理者所关注的风险因素，可靠性则事关正常运行和服务水平协议，将安全与隐私、可靠性捆绑"推销"，才能获得安全收益。
	面向客户的电子商务应用软件存在高风险组成部分，在开发时应当予以特别的关注。

1.6 小型软件开发者为什么需要开发更安全的软件

	平心而论，大多数人并不讨厌辛劳工作，只是会厌恶重复劳动。修复安全 bug 确实既困难又耗时。你可以选择立刻投入成本以增加产品安全的概率，也可选择在后期为此付出 更多代价。作为小型开发者或个人开发者，你可能并没有太多的闲暇时间，所以在前期落 实较多的安全措施则能够在后期节省更多的宝贵时间。质量良好的软件意味着更少的重复 劳动，就会有更多的时间享受滑雪、健身、陪同孩子玩耍、读书（并非软件书籍!），或和心仪已久的另一半享受约会的乐趣。在微软，我们意识到较少的安全漏洞，就意味着可以投入更多的时间关注客户需要的产品的其他实用特性，并最终赢得更多客户。

1.7 总结

	威胁正在悄然改变，安全和隐私的情形也与 2001 年时大为不同。在互联互通的今天，利益驱使下的犯罪者充斥着网络社会，因为这里就是"存放金钱的地方"。没有任何迹象表明这一趋势会迅速减缓。

第 2 章 当前软件开发方法不足以生成安全的软件

2.1 "只要给予足够的关注，所有的缺陷都将无处遁形"

2.1.1 审核代码的动力

	本章的作者（Michael）曾与数以千计的开发人员进行协作，指导开发人员如何审核代码和设计上的安全 bug。Michael 审查过无数的代码。如果说从中获取了一点经验的话，那就是他发现大多数人并不喜欢审核代码中的 bug 和漏洞。在审核代码以查找 bug（包括安全 bug 在内），与开发后续软件产品的最新特性之间，开发人员更愿意选择后者——编写新的代码。开发人员都极具创新意识，而开发新的特性是表现其创造力的最好方式。另一个不想审核代码的原因则是代码审核过程相当缓慢、枯燥并容易令人厌烦。
	备注 微软进行的分析表明，一名普通开发人员平均每天能够审核大约 1500 行 C 代码或

2.1.2 理解安全 bug

	理解安全 bug 是非常重要的，在第 5章"第 0阶段∶教育和意识"将对此进行详细论述。如果你的工程师对安全 bug 的组成一无所知，在审核组件的设计或基于该设计的代码时势必会一无所获。举例来说，除非你了解 HTTP响应分割攻击（HTTP Response Splitting attack）（Watchfire 2005），否则你就将无法察觉如下代码中的安全 bug∶<@ LANGUAGE=VBSCRIPT CODEPAGE = 1252 6> <!--#include file="constant.inc"_-> <!--#include file="1lib/session.inc"--> <6 SendHeader 0,1 *> <!--#include file="1ib/getrend.inc·--> <!--#include file="1ib/pageutil.inc"--><号'<!-- Microsoft Outlook web Access--> '<!-- Root.asp: Frameset for the Inbox window --> '<!-- copyright(c)Microsoft Corporation 1993-1997.All rights reserved.--> On Error Resume Next If Request.QueryString("mode") <>"" Then Response,Redirect bstrVirtRoot + _End If"/inbox/Main_fr.asp?" + Request.QueryString ()这一编码 bug 存在于微软 Exchange Server 5.5 的 Outook Web Access 组件中，微软曾为此发布安全公告 MSO4-O26（Microsoft 2004）。此类 bug 可能引发诸多安全问题。顺便指出，该编码 bug 起始于 Response.Redirect 行。

2.1.3 人员数量

	接下来的问题就是人员数量问题∶ 必须有足够多的具备相关知识的人员才能够对代码 进行充分的审核。是的，可能有很多具备安全专业知识的人员已经参与了一些诸如 Apache 和 Linux 内核等的大型项目，但相比较而言，能够对正在开发的软件实施代码审核的人员却出奇的少。 假设我们已经拥有众多的具备相关能力的人员，他们不仅理解安全 bug 也能对代码中的安全错误进行审核。或许你就开始认为可以将"足够的关注"的说法换为"只要存在大量拥有经验并乐于找出所有 bug 的人员，就会使得所有 bug 浮出水面"，但是，上述说法 仍然与软件工程的各项过程毫无关系，这也正是我们的下一个话题。

2.1.4 "关注越多"越容易失去要点

	能够缔造优良软件的开发过程，其目标在于减少设计人员、架构师或者软件开发人员在最开始引入 bug 的几率。当然在开发过程之外引入的 bug 也仍然属于 bug，只是不必移除也不会对客户造成任何负面影响。毫无疑问，代码审核是绝对必要的，但简单的"查找bug"并不能形成一个安全软件的完整过程。将代码"扔给"其他人员进行审核很显然是在 白费精力。SDL 的目标是减少某人在开发过程中引入安全 bug 的几率。

	开源软件中的许多安全缺陷已存在数年之久，列举如下几个例子∶
	●15 年 Sendmail E-mail 服务器（CVE-2003-0161）
	●10年 MIT的 Kerberos 认证协议（CVE-2003-0060）
	●7 年 SAMBA 文件与打印服务（CVE-2003-0085）
	●5 年 MIT 的 Kerberos 认证协议簇（CVE-2005-1689）
	●5 垢 年 Eric Raymond 的 Fetchmail e-mail服务器（CVE-2002-0146）

2.2 专利软件开发模式

	DL 与 CMMI/TSP /PSP 主要差别在于 SDL 专注于安全和隐私方面，而 CMMI/TSP / PSP 则主要关注提升质量和保持开发过程的一致性，通常并不包含特别规定或安全要求。 尽管这确实是一个值得为之努力的目标，但其潜在的逻辑是"如果质量全面提高，安全质 量理所当然就会提高"。无论正确与否，我们都找不到充分的商业开发案例来证实或反驳这 个观点。以我们从 SDL 中积累的经验表明，专用于减少安全和隐私类漏洞的过程和工具的 确能够提供一致性并提升安全质量，这一点是经过实践检验的。尽管我们对 CMMI/TSP / PSP与 SDL 相比，能在提高软件安全质量方面究竟有多大效用仍无法给出最终结论，但我 们可以断言，SDL 最起码是一个提升安全质量的最优途径。

2.3 敏捷开发模式

	诸如极限编程之类的敏捷开发模式（Wikipedia 2006），尝试通过以快速迭代方式（又 称为时间窗或者 sprint），来构建软件以降低软件开发项目中的全局风险。这些简短的周期 性过程则有助于客户更有效地进行反馈、交互、时间管理以及日程预期。

2.4 通用评估准则

	重要 较高的评估等级，例如 EAL4 较之 EAL3 来说，并不意味着"更安全"。
	重要 设计规范往往会遗漏那些仅在代码中才会出现的重要安全细节。

2.5 总结

	当前的软件开发模式缺乏足够的安全意识、规定、最佳实践和规则，历年来软件厂商所发布的安全补丁数量就是最好的证明。为了改变这种状况，业界必须对当前的工程方法进行改进以缔造出更安全的软件。

第 3 章 微软 SDL 简史

3.1 前奏

	安全评估
	在 20 世纪 80 年代初，美国国家安全局（NSA）就开始编写一系列评估准则，以描述抵御针对操作系统软件所发起的攻击的安全特性，以及安全保障措施。这些准则，如可信计算机系统评估准则（TCSEC），即以其封面颜色而命名的橘皮书（DOD 1985），在 20 世纪的 80 年代到 90 年代间，指导了各个厂商操作系统开发团队的工作。大多数那个时期的商用操作系统都达到了"C2"安全评估级别。更高级别，如 B2、B3 和 A1，则要求在设计阶段进行更高级别的模块化以及结构 化，配备详尽的文档，并且实现满足国防和国家安全用户需求的访问控制模型，本书的作者之一（Lipner）就曾在上世纪 80 年代初期参与过对 NSA TCSEC 草案的评审工作，并后来负责 Digital Equipment 的一个项目，该项目就是开发一个达到 TCSEC A1 级别的系统（Karger 1991）。到 20 世纪 80 年代后期，其他一些政府，包括加拿大和几个欧洲国家，也都着手编写本国的、适用于操作系统软件以及其他类型软件安全评估的准则。这些国家评估过程大多与欧洲信息技术安全评估准则，又称 ITSEC（ITSEC 1991），一致。ITSEC 的结构与TCSEC 有所不同，其安全 特性需求与保障需求是分开进行处理的。到了 20世纪 90 年代中期，形势发生了一些变化。对厂商来说，商业客户或者政府客户都不愿意仅仅因为产品是否符合 TCSEC 或者 ITSEC 的某个较高级别而草率做出采购决策，而且商业产品的安全评估事实上仍局限于在TCSEC C2 级别，（大致）相当于ITSEC 的 E3 级别。美国政 府以及欧洲 ITSEC 的支持者们为了形成一个更为广泛的评估产品市场并提高效率而不懈努力，双 方终于在 90 年代后期达成一致，通过了信息技术安全评估通用准则（Common Criteria for Information Technology Security Evaluation），或简称为通用准则（Common Criteria2005）。如今， 通用准则已经被国际社会正式认可了，代号为 ISO 15408。微软产品曾经历过众多评估体制下的评估。因为对于不同的行业来说，客户可能并不需要也不想购买那些具有TCSEC B2 级别所提供的特性的产品，微软曾将 Windows NT3.51和4.0 分别提交以评估其是否达到TCSEC C2和ITSEC E3 级别。微软 SQL Server 2000 也已达到 TCSEC 的"数据库解释"中的C2 级别。微软近年的产品，包括Windows2000、Windows XP、Microsoft WindowsServer 2003、ISA Server 2004，以及 Exchange Server 2003 都已经完全达到通用准则的 EAL4 级别，这也是如此众多的商业产品所达到的最高级别（Common Criteria2006）。其他微软产品在本书编写时仍在评估中。

3.2 新威胁，新对策

	与此同时，微软组建了内部的安全任务组（Security Task Force）检查漏洞发生的根本原因，并着手策划开设培训课程帮助于减少漏洞。STF 所采用的"建议"（recommendations）机制便成为 SDL 的雏形。当我们在7年之后再度回顾时，会发现当初 STF 的报告具有惊的预见性。这些建议的一些关键组成部分包括如下几点。
	●专注于管理层承诺的需求。
	●专注于工程师意识与培训需求。
	● 采用过程，即现在的威胁建模的前身。
	●运用工具和代码审核，以检测并移除可能导致潜在安全漏洞的常见编码错误。
	● 强调安全测试的重要性，包括"像黑客一样思考"。
	●专注于产品正式发布（post-release）后安全响应过程的需求。
	● 建议重组产品部以提升安全性，包括∶

在产品部中建立专门的安全团队。
定义一个持久的"安全 bug 标准"（security bug bar），以对潜在安全漏洞的严重
程度进行评估。
》 追踪已发现的和已修复安全漏洞，以及从新的安全漏洞中吸取教训。

3.3 Windows 2000 和 Secure Windows Initiative

	PREfix 是微软的第一个静态分析工具。PREfix 相关技术来自于微软收购的一家名为Intrinsa 创业公司。该公司的多数员工进入到微软程序员生产力研究中心（ProgrammerProductivity Research Center ，PPRC）。在 20世纪 90年代后期，PREfix 就能够通过对从非受信源到堆栈缓冲器的输入流进行跟踪，而检测出一些基于堆栈的缓冲区溢出漏洞。尽管PREfix 在 Windows 2000 上的运用产生了作用，它使某些种类的安全漏洞被移除出去，但微软研究团队和 SWI 团队仍然耗费了数年时间对其进行了再次开发，又发现了一些新型漏洞，才使 PREfix 成为编写安全代码最有效的工具之一。即便如此，从 Windows 2000获得的经验告诉 Windows 开发人员，虽然能够对代码进行自动化的分析，但他们仍要对这些自动分析出来的"安全漏洞"加以分析和纠正。

3.4 追求可度量性∶贯穿 Windows XP

	备注 PREfix 和 PREfast 的主要区别在于，PREfix 能够发现存在于多个程序或组件之间的错误，而 PREfast 则在单一程序查找错误时更为有效。PREfix 由核心团队进行维护，并用于周期性扫描所有产品代码基。PREfast 则适用于开发人员自行对其代码检测之前进行扫描。PREfast 已经集成在微软 Visual Studio 2005 的/Analyze 选项中。

3.5 安全推进和最终安全评审（FSR）

	2003 年的大部分时间里，SWI 团队都一直在为产品部培训，帮助组织安全推进活动，和开展预发布产品的审核（最初被称为"安全审计"，现在则命名为 Final Security Reviews，FSR，以避免与对即将发布的软件进行的财务审计或操作审计相混淆）。所有的这些努力终有回报，此间发布的产品漏洞率都有不同程度的下降，但 SWI团队所采用的方式仍然是非正式的。指导该团队工作的文档在 Windows Server 2003 安全推进的末期已经基本成型（主要由 Michael Howard 完成），当然，SWI 团队中行之有效的实践方法，以及所需要注意的问题更多的是成员之间口口相传。这种方式的有效性有目共睹，只是其本身不太有条理!

3.6 形成软件安全开发生命周期

	向 SDL 2.0 的转换活动于2004 年 7月1日完成。此时，超过半数的微软工程人员完成 了 SDL 所强制要求的新安全培训，符合 SDL 的正式需求也被公开发布在内部 Web 站点上	SWI团队的成员数在 2004年1月到 6 月间也进一步扩张，以满足下列职责需求∶
	●实施安全培训;
	●开发和更新 SDL自身定义;
	●开发和支持实施 SDL 约束所需的支持工具;
	●为产品团队提供 SDL 相关建议和咨询服务;
	●在产品发布前实施 FSR。

3.7 持续的挑战

	我们知道采用 SDL 中的技术增加了攻击者的入侵难度，这一点从基于 SDL 过程（以及其前身）所开发的软件中的漏洞统计得到证明。没有最好，只有更好。我们还知道，新型漏洞的发现会刺激新的攻击技术和工具的产生。为此我们需要不断对 SDL 进行更新，并在此过程中将安全响应机制整合在内。我们编写本书的目的就在于为其他开发机构提供一个可以提高软件抗攻击性的框架，并使其能够组织好自己的过程，以应对软件安全所带来的持续挑战。

第 4 章 管理层的 SDL

4.1 成功的承诺

4.1.1 微软的承诺

	本书的作者们在"日常工作"中，经常会向微软客户以及合作伙伴介绍 SDL 的内部运行机制，并解释微软如何利用该过程缔造更安全的产品。我们经常听到的一个问题是∶"SDL的哪个部分或方面对于最终的成功是最重要的?"这个问题实在难于回答，因为 SDL 是由大量相对独立而又同等重要的阶段有机组成的一个整体。在类似微软这样的组织中，是否

4.1.2 你是否需要 SDL?

	实施 SDL 需要投入大量资金，在管理者们问 SDL 是否必要时，我们也一再强调 SDL并不是廉价工程。事实上，这应该"视情况而定"。如果客户依赖于你所开发的软件的安全性，你就有必要确保你所提供的软件能够应对种种挑战。很显然，平台类产品、操作系统、数据库系统、电子邮件和协作服务器（collaboration servers）都可被归入此类，因为这些产品必须保护客户数据的保密性和完整性，而且平台提供的计算资源即使在遭受恶意攻击时也应该仍然可用。安全对于其他类型的产品也一样重要，包括电子商务（Web）应用和与组织内用到的特定应用（在这种应用中必须处理敏感数据，而且不是所有用户都可信或经过授权）。政府指定的供应商所开发的处理敏感信息的诸多应用也要求采用更苛刻的安全措施。尽管这些应用的安全机制可能会因所依赖平台的不安全而被绕过，但是如果突破平台级的安全措施机制使得攻击成本上升或不可执行，攻击者们仍然会将目标对准应用本身。

4.1.3 有效承诺

	如果决定在你的组织开发的某些或全部的软件中采用 SDL，作为管理者，如何确保你的组织的各项投入都有所回报?下面几段总结了一个管理人员为支持在组织内应用SDL所应采取的行动。口 作出声明如果你认为对于开发团队而言实施 SDL 以缔造更安全的软件是非常重要的，就必须明确地表达出来。在微软，Bill Gates 发出了关于可信计算的电子邮件，但这并不是全部。在我们开始鼓励各个团队管理者们加入 Windows 安全推进活动时，Jim Allchin（当时的平台集团副总裁）就亲自启动了简要/培训课程，Brian Valentine（Windows 部门高级副总裁）也在全部门范围发送电子邮件，告诉员工我们究竟在做什么，为什么这样做是至关重要的。类似的事情在 Microsoft Exchange 和 SQL Server 产品上也发生过。

4.2 管理 SDL

4.2.1 资源

	依据以往经验，我们知道，决定一种资源是否能被用来实施 SDL 的可变因素很多，而且我们十分了解这些因素影响成功实施 SDL 所需资源的方式。然而，目前我们仍无法给出一套等式来明确说明，例如;"对于既定代码量、实现语言和在互联网上的暴露程度等来说，这就是你在实现 SDL 符合性（compliance）时所应采用的预计开发资源水平的相关因素。"原因之一是在微软我们并没有实际地收集更精确的资源数据。与那些以小时计时来进行开发的国防承包商、服务巨头有所不同，微软典型的做法是指定某一团队负责一个或多个产品，然后将整个团队的成本分摊到产品之中。微软不会将开发过程中的个体活动所产生的更精细的成本计算在内。所以，当前的 Windows 发布中都已支付过 Windows 测试人员的薪水，无论这些测试人员是在测试应用兼容性，抑或是在进行 SDL 过程中的安全"模糊测试"（fuzztesting)。

4.2.2 项目是否步入正轨?

	从第 5 章"第 0阶段∶ 教育与意识"开始，贯穿于整个第 2 部分的"安全开发生命周期过程"，我们将详尽讨论 SDL 各个阶段所需要执行的活动。在 SDL，的每一阶段都要求进行特定的活动，并产生特定的输出，无论是以文档形式（某些情况下）还是项目作流系统中的 bug 形式，对这些过程输出都必须进行调查并（多数情况下）加以修复。承担在产品中实施 SDL 的管理者或负责人应当密切关注输出成果，以判断究竟投入过多还是不足。下面列出了一些有助于评估 SDL 的实施质量的关键度量指标，使管理者不会在产品交付之时才感到诧异。

4.3 总结

	负责人和管理者们在软件开发组织实施 SDL 的过程中扮演了极为关键的角色。管理层的承诺对于团队成功实施 SDL 和缔造更安全的软件而言，至关重要。对 SDL 的成本和收益进行度量是颇为艰难的。尽管没有任何权威性的指南阐述对 SDL 对项目开销和日程安排的影响进行精确度量的方法，但是通过对交付物以及 SDL 各个阶段的相关活动实施必要监控，则能够使管理者更清楚地了解项目是否正按照既定轨道进行，SDL 的成本有多少。通过对外部度量指标，比如客户对安全的满意度，以及安全事件对产品和服务的影响程度的持续追踪，可以使管理者类比性地理解实施 SDL 所获得收益。

第 5 章第 O 阶段∶教育和意识

5.1微软安全教育简史

5.2 持续教育

5.3 培训交付类型

5.4 练习与实验

5.5 追踪参与度与合规度2

5.6 度量知识3

5.7 实现自助培训

5.8 关键成功因子与量化指标4

5.9 总结

第 6章 第 1阶段∶项目启动

6.1 判断软件安全开发生命周期是否覆盖应用7

6.2 任命安全顾问8

6.2.1 担任开发团队与安全团队之间沟通的桥梁

6.22 召集开发团队举行SDL 启动会议

6.2.3 对开发团队的设计与威胁模型进行评审

6.2.4 分析并对 bug 进行分类，如安全类和隐私类

6.2.5 担任开发团队的安全传声简

6.2.6 协助开发团队准备最终安全审核

6.2.7 与相应安全团队协同工作

6.3 组建安全领导团队

6.4 确保在 bug 跟踪管理过程中包含有安全与隐私类 bug

6.5 建立"bug 标准"

6.6 总结

第7 章 第 2 阶段∶定义并遵从设计最佳实践

7.1 常见安全设计原则

7.2 受攻击面分析与降低

7.2.1 第一步∶该特性真的有那么重要么?

7.2.2 第二步∶究竟谁需要从哪里访问这些功能?

7.2.3 第三步，降低特权

7.2.4 其他受攻击面组成部分

7.3总结

第 8 章 第 3 阶段∶产品风险评估

8.1安全风险评估

8.1.1安装问题4

8.1.2 受攻击面问题

8.1.3 移动代码问题

8.1.4 安全特性相关问题

8.1.5 常规问题

8.1.6 分析问卷

8.2隐私影响分级

8.2.1 隐私分级1

8.2.2 隐私分级2

8.2.3 隐私分级3

8.3 统一各种因素（Pulling It All Together）

8.4 总结

第9章第4 阶段∶风险分析

9.1 威胁建模产物（Artifact）

9.2 对什么进行建模

9.3 创建威胁模型

9.4 威胁建模过程

9.4.1 定义应用场景

9.4.2 收集外部依赖列表

9.4.3 定义安全假设

9.4.4 创建外部安全备注

9.4.5 绘制待建模应用的一个或多个数据流图（DFD）

9.4.6 确定威胁类型

9.4.7 识别系统威胁

9.4.8 判断风险

9.4.9 规划消减措施

9.5 利用威胁模型辅助代码评审

9.6 利用威胁模型辅助测试

9.7 关键成功因子和指标

9.8 放结

第 10 章 第 5 阶段∶创建安全文档、工具以及客户最佳实践

10.1 为什么需要文档和工具?

10.2 创建指导性安全最佳实践文档

10.2.1 安装文档

10.2.2 主线产品使用文档

10.2.3 帮助文档

10.2.4 开发人员文档

10.3 创建工具

10.4 总结

第 11章 第 6 阶段∶安全编码策略

11.1 使用最新版本编译器与支持工具

11.2 使用编译器内置防御特性

11.2.1 缓冲区安全检查∶/GS

11.2.2 安全异常处理∶/SAFESEH

11.2.3 数据执行防护兼容性∶/NXCOMPAT

11.3 使用源代码分析工具

11.3.1 源代码分析工具陷阱

11.3.2 源代码分析工具的益处

11.4 切勿使用违禁函数

11.5 减少潜在可被利用的编码结构或设计

11.6 使用安全编码检查清单

11.7 总结

第12 章 第 7阶段∶安全测试策略

12.1模糊测试

12.1.1 模糊操作文件格式

12.1.2 网络协议模糊操作

12.1.3 零散模糊测试

12.1.4 通过模糊测试修复发现的 bug

12.2渗透测试

12.3 运行时验证

12.4 必要时审核并更新威胁模型

12.5 重估软件的受攻击面

12.6总结

第 13 章 第 8 阶段∶安全推进活动

13.1 准备安全推进活动…………………………………………………………………………170
13.2 培训………………………………………………………………………………………………………171
13.3 代码评审……………………………………………………………………………………………………… 172
13.4 威胁模型更新…………………………………………………………………………………………174
13.5 安全测试…………………………………………………………………………………………………………… 175
·XX.
仅供个人科研教学使用
13.6受攻击面 Scrub……………………………………………………………………………175 13.7 文档 Scub…………………………………………………………………176 13.8 是否已足够?…………………………………………………………………………………………177 13.9 总结……………………………………………………………………………………………………178 参考文献………………………………………………………………………………179

第 14 章 第9 阶段∶最终安全评审

14.1 产品团队协调………………………………………………………………………………… 182 14.2 威胁模型评审………………………………………………………………182 14.3 未修复的安全 bug 评审……………………………………………………………………………………183 14.4 工具有效性验证……………………………………………………………………………………………………184 14.5 在最终安全评审完成之后…………………………………………………………………………….184 14.6 总结………………………………………………………………………………………………………………185

第 15 章 第 10 阶段∶安全响应规划

15.1 为什么准备响应?…………………………………………………………………………………………187 15.1.1 你的开发团队一定会出错………………………………………………………………………187 15.1.2 新漏洞一定会出现…………………………………………………………………………188 15.1.3 规则一定会发生变化………………………………………………………………………189 15.2 准备响应…………………………………………………………………………………190 15.3 安全响应与开发团队……………………………………………………………………………208 15.3.1 组建你的响应团队……………………………………………208 15.3.2 支持你的全线产品……………………………………………………………………209 15.3.3 支持你的所有客户…………………………………………………………………210 15.3.4 使你的产品具备更新能力…………………………………………………211 15.3.5 在研究人员之前找到漏洞…………………………………………………212 15.4 总结…………………………………………………………………………………………213 参考文献………………………………………………………………………………………………………………213

第 16 章第 11 阶段∶产品发布

第 17 章 第 12 阶段∶安全响应执行

17.1 遵从你的计划……………………………………………………………217
·XXI.
仅供个人科研教学使用-
17.1.1 保持冷静………………………………………………………………………………………………………217
17.1.2 欲速则不达……………………………………………………………………………… 218 17.1.3 留意可能改变计划的事件………………………………………………………………219
17.1.4遵从你的计划……………………………………………………………………………………………………220
17.2 尽你所能补救…………………………………………………………………………………………………220
17.2.1 知道该联络何人……………………………………………………………………………………220
17.2.2 能创建更新…………………………………………………………………………………………220
17.2.3 能安装更新………………………………………………………………………………………………221
17，2.4 明确轻重缓急…………………………………………………………………………… 221
17.3 深谙取舍之道……………………………………………………………………………………………………221
17.4 总结……………………………………………………………………………………………………………………222
参考文献………………………………………………………………………………………………………………………………… 222
第 3 部分 SDL 参考资料

第 18 章 在敏捷模式中集成 SDL

18，1 在敏捷模式中进行 SDL 实践活动…………………………………………………………………………226
18.1.1 安全教育……………………………………………………………………………………………………………226
18.1.2 项目开始……………………………………………………………………………………………………………226
18.1.3 建立并遵从设计最佳实践………………………………………………227
18.1.4 风险分析………………………………………………………………………………………………227
18.1.5 创建安全文档、工具以及客户最佳实践……………………………………………229
18.1.6 安全编码与测试策略…………………………………………………………………………………229
18.1.7 安全推进……………………………………………………………………………………………………………231
181.8 最终安全评审………………………………………………………………………………………………232
18.1.9 产品发布……………………………………………………………………233
18.1.10 安全响应执行……………………………………………………………………………………………233
18.2 利用SDL 实践增强敏捷模式………………………………………………………………234
18.2.1 用户 story………………………………………………………………………………………………………235
18.2.2 小发布与迭代……………………………………………………………………………236
18.，2.3 人员轮换…………………………………………………………………………………………………236
18.2.4简化 …………………………………………………………………………………………………………236
18.2.5 冲刺（Spike）解决方案…………………………………………………………………………236
18.2.6 重构
18.2.7 常规客户可用性
18.2.8 依据标准编码………………………………………………………………………………237 18.2.9 优先编写单元测试………………………………………………………………………238
18.2.10 配对编程………………………………………………………………………………………238 18.2.11 多次集成…………………………………………………………………………………………238 18.2.12 将优化留到最后………………………………………………………………………………………238
18.2.13 一旦发现一个bug，就创建一个测试…………………………………………………239 18.3 总结…………………………………………………………………………………………………………… 239 参考文献…………………………………………………………………………………………………… 239

19 章 SDL 违禁函数调用

19.1 违禁API………………………………………………………………………………………………………………242 19.2 为什么"n"函数会被禁止………………………………………………………………245 19.3 重要告诫……………………………………………………………………………………………246 19.4 选择 StrSafe ys.Safe CRT…………………………………………………………………246 19.5 使用StrSafe…………………………………………………………………………………………………246 19.6 使用Safe CRT……………………………………………………………………………………247 19.7 其他替代函数………………………………………………………………………………………248 19.8 工具支持………………………………………………………………………………………………248 19.9 ROI和成本影响……………………………………………………………249 19.10 度量和目标…………………………………………………………………………………………249 参考文献…………………………………………………………………………………………………… 249

第 20 章 SDL 最低加密标准

20.1 高级加密需求…………………………………………………………………………………251 20.1.1 加密技术 ys 低级加密算法…………………………………………………251 20.1.2 使用加密库…………………………………………………………………………………252 20.1.3 加密敏捷度………………………………………………………………………252 20.1.4 默认安全加密算法……………………………………………………………………253 20.2 加密算法的用法……………………………………………………………………………………253 20.2.1 对称块密码与密钥长度……………………………………………………254 20.2.2 对称流密码与密钥长度……………………………………………………………………254
·XXIl
_仅供个人科研教学使用
20.2.3 对称算法模式 …………………………………………………………………………………………255
20.2.4 非对称算法与密钥长度……………………………………………………………………………………255
20.2.5 哈希函数…………………………………………………………………………255
20.2.6 消息认证码……………………………………………………………………………………256
203 数据存储以及随机数生成………………………………………………………………………………………256
20.3.1 存储私钥以及敏感数据………………………………………………………………………………256
20.3.2 生成随机数与密钥………………………………………………………………………257
20.3.3 使用密码或者其他密钥来生成随机数和加密密钥……………………………………………257
参考文献……………………………………………………………………………………………………… 257

第 21 章SDL 必备工具以及编译器选项

21.1 必备工具
21.1.1 PREfast
21.1.2 FxCop
21.1.3 应用验证器（Application Verifier）
21.1.4 最小编译器与 Build 工具版本

第 22 章 威胁树模式

22.1 假冒一个外部实体或过程
222 算改—个过程
22.3 篡改一个数据流
22.4 篡改一个数据存储
22.5 抵赖
22.6 过程信息泄露
22.7数据流信息泄露
22.8 数据存储的信息泄露
22.9 针对过程的拒绝服务
22.10 针对数据流的拒绝服务
22.11 针对数据存储的拒绝服务
22.12 特权提升

第1章

引 论

1.软件安全的重要性和相关性。软件是我们在现实世界中做任何事情的关键，同时，

软件也分布在最关键的系统中。基于此，软件的安全设计是至关重要的。大多数信息技术

（Information Technology，IT）相关的安全解决方案已经能够有效地降低不安全软件带来的风

险。为了证明一个软件安全程序的合理性，必须知晓没有构建安全软件带来的金钱成本和其

他风险的重要性与相关性，以及构建安全软件的重要性、相关性和成本。总而言之，软件安

全同样是一个商业决定，因为它关注避免安全风险。

2.软件安全和软件开发生命周期。在这里，重要的一点是要区分在软件开发中我们熟知

的软件安全（software security）和应用程序安全（application security）。尽管这两个术语经常

互用，但是我们仍然需要区分它们。因为实现这两个目的的程序在管理过程中存在明显的不

同。在模型中，软件安全表示在 SDLC中，应用SDL 构建安全的软件，而应用程序安全表示

发布后运行过程中软件和系统的保护。

3.高质量和安全代码。尽管安全代码未必是高质量代码，同时高质量代码也未必是安全

代码，但是软件的开发过程是基于高质量和安全代码原则的。你不能拥有不安全的高质量代

码，更不能拥有劣质的安全代码，它们相辅相成。至少，质量和软件安全程序应该在开发过

程中紧密结合;理想情况下，它们应该是同一组织的组成部分，以及软件开发工程部门的一

部分。这将在本书中后面的章节中从组织和操作角度进一步讨论。

\4. 三个最重要的 SDL 安全目标。所有软件安全分析和构建的核心是三个最重要的安全因

素∶ 保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），也称为C.I.A.模型。

为了确保软件开发是安全的，上述三个特性必须一直作为整个 SDL 过程中的主要组成部分。

\5. 威胁建模和攻击界面验证。威胁建模和攻击界面验证是 SDL 中最耗时和难以理解的部

分。在当今的敏捷软件开发中，必须正确处理这个问题，否则无法保证软件安全。SDL 中的

威胁建模和攻击界面验证，将最大限度地避免软件产品发布后发现安全漏洞。我们认为这个

功能非常重要，因此本书将专门用一节和一章来关注这个主题。

1.2 软件安全和软件开发生命周期

多年来，安全业界对于软件安全和应用安全存在着一个严重的误解。Gary McGraw 提供

了关于两者之间差异的一个清晰描述∶

一方面，软件安全是关于构建安全软件的∶将软件设计成安全的; 确保软件是

安全的;培训软件开发人员、架构师和用户如何构建安全到软件中。另一方面，应

用程序安全是关于保护软件和该软件发布后运行的系统，当且仅当开发完成后。15】

从第一个大规模针对软件的攻击开始，到20世纪 80年代后期，软件安全已经走过了漫

长的道路。当时软件并没有过多地考虑安全问题（如 UNLX 代码、TCP/IP 协议栈）。随着微软

Windows 以及网页（Web）的出现，攻击开始变得复杂和频繁，因此软件的安全性才逐渐得到

重视。工业界开始通过各种辅助手段短期修复安全问题。这些因素推动了杀毒软件、防火墙、

反间谍软件的出现。然而，真正的问题——代码是如何开发和编写的——并没有得到重视。

这个问题直到最近十年来出现了SDL 实践才得到重视。许多企业（如微软）由于软件安全缺

陷的影响开始意识到通过改善软件开发实践，以确保安全的软件代码的重要性。这导致学术

界和软件巨头都推荐 SDL 实践，如微软等。现在我们有理论和指导原则来帮助我们从软件开

发一开始就构建安全的代码，从而降低出现可能被攻击者利用的软件漏洞的可能性。

1.3 代码的质量与安全

开发应用软件的流程，是基于代码质量和代码安全共同的最佳原则的。这些最佳原则是

软件行业最佳实践的概念和设计背后的成因。为了开发经得起时间考验的安全代码，你必须

学会如何将这些原则纳入到开发过程中。请记住，安全的代码不一定是高质量的代码，高质

量的代码不一定是安全的代码。

1.4 SDL 三个最重要的安全目标

任何一个合格的开发人员都可以编写非常高效的、可维护的和易于重用的代码;但是，

如果该代码允许未经授权的用户访问应用程序管理的资源，该代码就是不安全的。遗憾的是，

在软件开发生命周期中，安全性仍然是经常被忽视或者投入最少的方面。信息安全界认为

SDL 最低也是最为重要的三个目标是∶

1.机密性

2.完整性

3.可用性

这三个目标统称为 C.I.A（Confidentiality， Integrity， Availability）。人们普遍认为，在软件

开发生命周期中，开发者通过公认有效的方法对C.I.A.进行保证、增强、保护，就认为代码

是高可信和安全的。

信息安全性、机密性、完整性和可用性在《44 U.S.C，Sec.3542》中的定义如下所示。

信息安全性∶保护信息和信息系统，避免未经授权的访问、使用、泄露、中断、修改或

破坏，以确保信息的机密性、完整性和可用性。

机密性∶ 对信息的访问和泄露进行限制，包括保护个人隐私和专有信息的手段。

完整性∶ 防止不正确的信息修改或销毁，包括确保信息不可抵赖性和真实性。

可用性∶ 保证信息可以实时使用。

1.5 威胁建模和攻击面验证

威胁建模和攻击面验证也许是 SDL 中最耗时、最不易理解和困难最大的部分。它需要软

件安全架构师———安全团队中经验最为丰富的专家来完成。简而言之，威胁建模的目的是理

解系统的潜在威胁，确定风险，建立适当的应对措施（有什么风险?风险严重性有多大? 如

何消除风险?）。当在项目生命周期的早期正确地进行威胁建模后，就可以在代码提交前发现

软件设计的安全问题。威胁建模使问题在软件开发生命周期的早期就得到了解决，从而节省

了大量成本。威胁建模还有助于企业管理软件风险，并提供将技术风险转换为业务影响的能

力。基本原则是，在软件生命周期中越早识别和管理安全风险越好。

第2章

Core Software Security: Security t the Source

安全开发生命周期

2.1 克服软件安全中的挑战

如第1章所述，SDL 是软件安全演化的关键步骤，有助于人们重视构建安全的软件开发

生命周期。过去，软件产品的利益相关者并不把软件安全作为—项高度优先的事项。人们认

为，一个安全的网络基础设施将会提供针对恶意攻击所需的保护级别。然而，最近几年，已

经证明单纯的网络安全不足以防止这种攻击。用户已经可以通过相关技术成功渗透有效的渠

道认证，相关技术包括跨站点脚本（Cross-Site Scripting，XSS）、结构化查询语言（Structured

Query Language，SQL）注入和缓冲区溢出漏洞利用技术等。在这种情况下，系统资产被泄露，

数据和组织的完整性也遭到破坏。安全行业一直试图尝试通过应急措施来解决软件安全问题。

首先是平台安全（OS 安全），然后是网络/周边安全，以及现在的应用程序安全。我们确实需

要深度防御来保护我们的资产，但从根本上它是一个软件安全漏洞，需要通过 SDL 方法进行

修复。

2.2 软件安全成熟度模型

近年来，两个非常流行的软件安全成熟度模型已先后开发并继续快速地成熟。 一个是

Cigital 的内置安全成熟度模型（Building Security in Maturity Model， BSIMM）m，另一个是

OWASP（Open Web Application Security Project，开放 Web 应用安全项目）的开放软件保证成

熟度模型（Software Assurance Maturity Model， SAMM）1。BSIMM是一项面向真实软件安全

措施的研究，帮助你确定软件安全措施和如何组织工作时间。BSIMM是 Cigital开发的一系

列最佳实践，分析 9个领先的软件安全措施的真实数据，并基于成功的公共区域创建框架。

有 12个实践组织为4个域。这些实践都用于组织109 个BSIMM活动（BSIMM4共有111 个

活动）。

.3 ISO/IEC 27034∶ 信息技术、安全技术、应用安全

2011 年，国际标准化组织（International Standards Organization，ISO）/国际电工委员会

（International Electrotechnical Commission，IEC）发布 ISO/IEC27034-1∶2011中6个应用安全

标准的第 1部分。l该标准提供了一个简洁并且国际公认的方式来获得厂商/ 供应商软件安

全管理流程的透明性。为了配合不同的工程组织，该标准设计具有足够的灵活性，但为了解

决现实世界的风险，它又足够具体。

2.4 其他 SDL最佳实践的资源

还有其他 SDL 最佳实践的资源，下面介绍其中几种最流行的资源∶

2.5 关键工具和人才

如同所有的安全任务一样，无论它们的方法是攻击还是防御、总要有成功所需的过程、

技术和人力的一个融合。迄今为止，可用于软件安全的过程和模型已在本节中讨论了。有两

个要素∶一个是技术（工具）方面，它在软件安全方面提供帮助或制造麻烦;另一是人力（人

才）方面。

2.6 最小特权原则

在信息安全、计算机科学以及其他领域，最小特权原则

限制特权提升是威胁建模的重要部分，其也是 SDL 架构（A2）阶段的一个核心组成部

分，这将在第 4 章讨论。特权提升的概念是非常重要的，它是微软安全开发生命周期卡片游

戏的主题。旨在培养开发人员和安全专业人员快速、轻松地找到软件或计算机系统的威胁。【5

未经授权的权限提升攻击利用程序错误或设计缺陷，赋予攻击者访问网络及其相关的数据和

应用程序的提升权限。这些攻击可以是垂直的（攻击者赋予自已特权），或水平的（攻击者使

用已经赋予的相同水平的特权），但假设他拥有具有相似权限的另一个用户的身份。

2.7 隐私

保护用户的隐私是 SDL 过程的另一个重要组成部分，应被视为 SDLC 所有阶段重要的系

统设计原则。用户隐私安全出了问题将导致信任危机。由于在未经授权访问的用户越来越多

的情况下，个人信息在媒体中公开，在软件和系统中使得客户的数据得到可靠保护的状况日

益恶化。此外，许多新的隐私法律法规强调了在软件和系统的设计和开的包含隐私的重要性。

至于安全性，已经通过的软件开发生命周期的进度的变更是成本很高的，就是把高成本的隐

私保护方法和技术融入 SDLC的适当阶段，以维护个人的隐私，并保护个人身份信息（PII）

的数据。包含在微软 SDL 中的一些关键的隐私设计原则，包括提供有关数据收集、存储或者

共享的适当通知，使用户可以对自己的个人信息做出明智的决策;使用户策略和控制可用;

最小化数据收集和敏感性; 以及存储保护和数据传送。【5

至关重要的是，隐私保护措施通过 SDL 实现的最佳实践构建到了 SDLC中。忽略用户的

隐私问题可能会导致诉讼、媒体负面报道和不信任。我们已经将隐私保护最佳实践方案部署

到 SDL 中，这将在以后的章节中详细叙述。

2.8 度量标准的重要性

Lord Kelvin 曾说过，"如果你不能衡量它，就不能改进它。" 【这句格言今天也是如此，

因为它适用于产品的安全性和满足软件开发组织的安全状况精准度量的需求。有意义的安全

指标是至关重要的，因为企业要合作努力应对监管和风险管理要求，

2.10 软件开发方法

本章前面已经讨论了各种 SDLC 模型，并提供了SDL 模型和一般 SDLC 之间映射关系的

直观概述。应当指出，多个软件开发方法在各种 SDLC模型中使用。每一个软件开发方法都

作为应用特定框架开发和维护软件的基础，不太关心技术方面，相反关心创建软件过程的组

织方面。这些开发方法主要是瀑布模型、敏捷及其变种和衍生模型。瀑布模型是最古老和最

知名的软件开发方法。瀑布模型的显著特点是它从需求按顺序循序渐进的过程。尽管它们包

括传统和新型的软件开发实践的混合，但是敏捷方法在行业中越来越受欢迎。你会发现敏捷、

传统瀑布或者两者的混合体。我们将详细介绍瀑布和敏捷开发模式，并选择每一个模式对应

的一个或两个变体用于介绍软件开发方法。鉴于存在的模型数量，对于 SDL 模型不仅有一个

通用模型，还将按第 9章的具体介绍进行操作。第 9 章描述了 SDL 模型应用到一些最流行的

软件开发模型中，这些模型你可能会在未来几年接触到。

第3章

Core Software Security; Scurity t the Source.

安全评估（A1）∶ SDL 活动与最佳实践

.1 软件安全团队提早参与项目

SDLC 通常有正式的启动会议，把软件安全团队包括在内是非常重要的，以确保安全是

SDLC 的重要元素，并内置于整个过程。现场会议或网络会议给了与会者和利益相关者来大

致认识和了解的重要机会。

3.2 软件安全团队主持发现会议

发现会议基本上是一个 SDL启动会议，在会上关键的 SDLC 利益相关者在过程开始时聚

在一起，使安全成为内置的而不是附加的。在发现会议安全规划中应包括筹备整个系统生命

周期，包括关键安全里程碑和可交付成果以及工具和技术的鉴定。特别应考虑到可能需要进

行采购的项目，比如软件安全性测试和评估工具，以及第三方软件安全架构师或工程师潜在

的使用可能，（如果需要扩充员工或有客户要求第三方认证）。其他资源的影响，如主动测试、

认证以及所需的培训，必须加以考虑。

.3 软件安全团队创建 SDL项目计划

这实际上可以被认为是最初的项目规划，因为正式的计划将作为设计阶段的成果呈现，

这将在下一章描述。

3.4 隐私影响评估计划启动

有许多隐私保护和管理方法。然而，在过去，隐私保护工具是普遍以自组织的方式应用

的，或者是以零碎的方式解决眼前的问题;通常在这些问题解决后发布。正如安全性，在系

统设计时把隐私作为次要的考虑因素，或者把它作为一个未来探讨的问题处理，并不能提供

有效的隐私保护。只考虑解决隐私问题的组件，而不是通过一个全面的设计和实施将导致进

一步的潜在隐私问题。隐私必须是一个基本的设计因素，它要集成到 SDLC 的各个阶段。

3.5 安全评估（A1）成功的关键因素和度量标准

3.5.1 成功的关键因素

设定成功的标准在 SDL 的任何阶段都会使其更有效，并有助于在事后了解什么工作有帮

助而什么没有。表3-1列出了作者认为成功的标准。然而，每个环境都是不同的，安全团队

都需要在自己的环境中理解成功的标准。

.5.2 可交付成果

在每一个 SDL 阶段，我们将概述该阶段可交付成果的关键集。这样做是为了确保所有必

需的活动有一个有形的记录结果。我们常常看到创建并保存一个项目管理团队只是口头或非

官方的文件。我们认为，正式文件应建立并保存在一个中央存储库，并且有适当的签名和版

本控制。

第4章|

Core oftware Securty: Securty t the Source

架构（A2）∶ SDL 活动与最佳实践

4.1 A2 策略一致性分析

软件的安全策略的目的是确定哪些需要加以保护以及它如何受到保护，包括审查和结合

SDL 外可能会影响开发进程的策略。这些措施可能包括治理软件或开发或应用在组织中的任

何地方的策略。在这个阶段，SDL 的策略域外存在的任何策略都将被审阅。企业安全与隐私

策略可能会指示设计和开发人员必须有什么样的安全和隐私功能及它们该如何实现。其他策

略可能包括那些支配使用第三方和开源软件或组织内部和外部的保障与控制源代码以及其他

知识产权。

4.2 SDL 策略评估和范围界定

SDL 还提供了一个非常宝贵的指南为软件开发人员设置其组织的安全标准，应该提供一

个实现路线图而无需中断生产高质量软件应用的核心业务。除非开发组织和管理团队的高层

领导支持这种模式，否则 SDL 可能会失败。它必须由签订、出台的政策来驱动，并最好由

CEO 和软件开发管理团队提供支持。一个组织本应该有一个书面的和可重复的 SDL 的策略与

方针，以支持 SDLC，其中包括其业务需求，并作为它支持的工程和开发文化的补充。该组

织的文化和成熟度在 SDL 策略的制定中是非常重要的，这样可以确保它会同时实现可行性和

实用性。管理风格、人员、流程和技术需求（包括产品的整体架构）的复杂性，将有助于确定

怎样的粒状或目标来作为重点指导方针。外包开发量，如果有的话，也需要作为这个过程的

一部分被评估。一个内部的开发团队需要更详细的程序，而一个外包功能将需要更多的合同

对象、服务水平，以及详细的可交付物。这些漏洞以及利用外包资源开发的风险将在本书后

面讨论。

4.3 威胁建模/ 架构安全性分析

4.3.1 威胁建模

如前所述，威胁建模需要一套特殊的技能、经验和心态∶团队内的人不论是谁做这个一

定要像对手一样思考。资深软件安全架构师或更丰富的软件安全冠军之一通常深谙这个方面。

参与这个过程的开发者或团队成员不仅必须要懂得怎样开发软件，而且要了解如何解构或拆

卸软件及其架构，同时像对手一样思考。

微软首次于1999 年记载了威胁建模方法，自那时以来，它的方法已经发展成为一个行业

标准'。当然，这不是微软第一次由人来威胁建模，而是第一次将方法形式化或视为一个抽象

的工程活动。

潜在损害

低（值=1）∶泄露琐碎的信息。

中（值=2）∶泄露敏感信息。

高（值=3）∶攻击者可以颠覆安全体系;得到充分信任的授权;以管理员身份运行;上传

内容。

可重复性

低（值=1）∶这种攻击是非常难以再现的，即使有安全漏洞的知识。

中（值=2）∶该攻击可以重复，但只有一个计时窗口和一个特定的竞争情况。

高（值=3 ）∶该攻击每次都可重复，并不需要一个计时窗口。

可利用性

低（值=1）∶攻击需要一个非常熟练技能的人，并深入了解每一次可以利用漏洞攻击

的知识。

中（值=2）∶一个熟练的程序员就可以攻击，然后重复上述步骤。

高（值=3 ）∶一个初学者在很短的时间内就可以攻击。

受影响的用户

低（值=1）∶ 很小比例的用户，模糊的功能;影响匿名用户。

中（值=2）∶一些用户，非默认配置。

高（值=3）∶ 所有用户，默认配置，重点客户。

可发现性

低（值=1）∶ 这个 bug 是模糊的，而用户是不可能计算出潜在损害的。

中（值=2）∶ 该漏洞位于产品中一个很少使用的部分，只有少数用户会碰到它。这需要一

些思考，看看是否有人恶意使用。

Web 应用程序安全框架分类和评估问题【12】

·输入和数据验证

你怎么知道应用程序接收的输入是有效和安全的?输入验证是指额外的处理之前，应用

程序如何过滤、清洁或拒绝输入。考虑通过入口点限制输入，并通过出口点编码输出。你是

否信任你的数据来源，如数据库和文件共享数据?

·身份验证

你是谁?身份验证是一个实体证明另一个实体的身份的过程，通常通过证书来实现，例

如用户名和密码。

·授权

你能做些什么?授权是应用程序的资源和操作是如何提供访问控制的。

·配置管理

应用程序以什么身份运行? 它连接到哪个数据库?应用程序是如何管理的? 这些设置如

何保证安全?配置管理是指应用程序如何处理这些业务问题。

·敏感数据

应用程序如何处理敏感数据? 敏感数据是指应用程序如何处理必须加以保护的数据，不

论是在内存中，在网络上，还是在持久性存储中。

·会话管理

应用程序如何处理和保护用户会话? 会话是用户和 Web 应用程序之间的一系列关联交互。

·加密

如何保持机密（保密性）? 如何防止篡改数据或数据库的（完整性）? 对于必须强加密的

随机值如何提供种子?加密是指应用程序如何强制执行机密性和完整性。

·异常管理

在应用程序中，当一个方法调用失败时，应用程序是怎么做的呢? 你透露了多少? 你向

最终用户返回友好的错误信息了吗?你把有价值的异常信息传递回调用者了吗?应用程序优

雅地出现故障

4.4 开源选择

目前软件行业有日益增加的趋势，在过去几年中开源软件和专有软件以最低的成本提供

最高价值的服务。两者的融合称为"混源"，这已经成为行业的主导做法。因为开源成为软件

开发领域越来越大的部分，所以了解和管理软件资产的授权将是至关重要的，但是这超出了

我们的讨论范围，这将会被别的软件开发团队处理。

4.5 隐私信息收集和分析

考虑到系统是否能够传输、存储、创建隐私信息在 SDLC早期是很重要的。信息收集、

辨识以及规划实施适当的保障措施和安全控制（包括解决隐私信息事件处理和报告需求的流

程）都是在这个阶段决定的。SDL 的这个阶段就是对隐私影响评估（PIA）的信息收集和分析

的开始。分析阶段决定了PII将如何处理，以确保其符合有关隐私的法律、法规和政策规定;

软件和开发的整个系统中，收集、维护、以可识别的形式传播隐私信息的风险和影响，或在

云或 SaaS 环境中与它交接的风险和影响。检查和评估保护和处理用于减轻潜在的隐私风险的

信息的替代过程。

4.6 成功的关键因素和度量标准

4.6.1 成功的关键因素

SDL 第二阶段的成功取决于 SDLC 如何同步识别威胁、要求，约束功能和集成，以及减

轻风险。第二阶段的关键成功因素见表4-1。

表 4-1 关键成功因素

描 述

关键成功因素

1.确定业务需求和风险

按 CIA 定义的业务需求和风险的映射

识别软件威胁

\2. 有效的威胁建模

\3. 有效的架构威胁分析

分析软件威胁和威胁出现的概率

4.有效的风险缓解策略

每二个业务需求的风险接受、容忍和缓解计划

\5. DFD的准确度

威胁建模中使用的数据流图

成功因素 1∶确定业务需求和风险

在这个阶段，关键的利益相关者，包括软件安全团队明确了业务风险和要求。业务需求

通过信息安全的 CIA 支柱定义。成功 SDL 周期的当务之急是，尽可能确定所有的要求并日捕

获需求。

成功因素 2∶有效的威胁建模

有效的威胁建模中是—个复杂和艰巨的任务。威胁建模的整个风险缓解计划取决干这个

任务。威胁模型的任何间隙会导致软件和/或部署中缺乏有效的安全控制。

|第5章

Core Sofware Security: Security at the Source

设计和开发（A3 ）∶ SDL 活动与最佳实践

5.1 A3 策略一致性分析

如第 4 章所述，A3 的策略一致性分析是对 A2 策略一致性分析的延续。在这个阶段，会

对 SDL 域外部的所有策略进行评估。这是为了保证公司外部的开发机构在软件开发过程中遵

守公司内部的安全和隐私需求以及开发指南。公司的安全和隐私策略会对需要达到的安全和

隐私特征进行描述，并指导设计人员和开发人员如何实现这些特征。其他策略可能针对公司

内部或公司外部在软件中使用的第三方或开源软件的管理，控制源代码以及其他智力成果。

假如软件安全组是与集中的信息安全组是分开的，那么两个组都要基于所有的原则和策略进

行协作是很重要的，包括开发、版本发布后的安全支持以及产品的反馈。同样重要的是在隐

私功能上的合作，无论是集中式组还是外部法律决策。

5.2 安全测试计划构成

测试活动用来验证产品发布后的安全措施是否能有效降低客户或恶意用户发现安全问题

的可能。软件通过安全测试、工件（artifact）、报告和工具对软件的安全性进行验证。我们的

目的不是为了证明产品不安全，而是在产品提供给客户前保证软件的健壮性和安全性。这些

安全测试方法确实能发现安全 bug，尤其是在那些没有经历关键的安全开发流程变更的产品

中。安全测试和评估的结果也可能在安全控制中发现缺陷，安全控制用于保护正在开发的软

件。因此需要制定详细的行动计划和里程碑进度，以记录计划的整改措施，进而增强安全控

制的有效性，并在软件发布之前提供必要的安全措施。

●定义测试脚本。脚本是非常详细且包括测试逻辑步骤的指令集，用于告诉测试人员或

测试工具在测试期间做什么。功能测试脚本是一步一步的指令，描绘了一个特定的场

景或情景，包括将会遇到的情况和预期的结果。安全测试脚本是专门用于测试应用程

序安全性的脚本。这些脚本的依据来源于在设计阶段生成的威胁模型。误用用例定义

那些需要保护（资源），什么类型的攻击可以访问这些资源。安全测试脚本定义了执行

这些攻击的行为。

●定义用户社区。定义用户社区帮助测试人员识别错误和风险的可接受程度。

●识别项目障碍物。用例中需要定义必备的和"如果可用"的情景。如果没有定义，就

需要重新审视测试需求，从而使这些规范文档化。

●识别内部资源。内部资源来自于公司的组织，包括开发商、分析师、软件工具，有时

还可能有项目经理。

●识别外部资源。外部资源是为了测试应用系统和提交报告而临时加入项目的人员或工

具。外部资源最适合安全测试，因为他们一般都在安全编程技术方面受过严格的训练，

同时他们远离代码和任何内部策略。如果需要外部资源，测试计划需要回答以下问题;

（1）他们测试什么?（2）他们的报告提交给谁?（3）他们与谁一起工作? P

我们将软件的安全属性和行为划分为外部实体的和内部实体的∶外部实体包括用户、环

境和其他软件; 内部实体包括软件自身有交互行为并且作为主要测试对象的内部组件。具体

来说，应该验证软件以下的属性和行为∶

●它的行为是可预测和安全的。

●它不暴露漏洞或者缺陷。

5.3 威胁模型更新

在通过第 4 章介绍威胁模型构建过程之后，知道构建过程何时完毕是很重要的。需要回

答以下几个问题，答案可能取决于商业竞争与安全风险之间的取舍。

\1. 你开发的软件是否能符合所有相关政策、法规、条例的规定?并且对于每个需求获得

各个层次的批准?

2.所有的利益相关方是否对威胁建模过程中识别出的安全和风险进行了检查?相关的架构

师、开发人员、测试人员、项目经理以及其他所有了解软件的人员都应为威胁模型构建做出责

献并进行核查。为了保证威胁模型覆盖全面，应广泛征求各方意见。所有相关人员在威胁和风

险的认识上达成一致是很重要的。否则，针对威胁模型实现相关措施的落实会面临很多困难。

\3. 你是否就建立威胁模型和针对威胁模型采取的应对措施、测试所需的时间和资源与相

关方达成一致?

\4. 你对风险和威胁的排名是否与相关人员达成了共识?如果你是一个软件购买者，是否

会同意这个排名?

5.4 设计安全性分析和检查

在 1974年的一篇文章中，来自弗吉尼亚大学的 Saltzer 和 Schroeder，提供了通过保护存

储信息所需的软件和硬件来保护信息的方法。14文章提出了以下 11 个安全设计原则。

\1. 最小权限。最小权限原则主张，对于完成一项任务的个人、进程或其他实体，只在可

完成该任务的最短时间内分配给该实体能够完成该任务的最小权限和资源。这种方法避免了

未经授权访问敏感信息的情况。

\2. 职责分离。该原则要求，必须满足多个条件，

5.5 隐私实现评估

笔者认为，最简洁、清晰并且经过现场检验的软件开发隐私措施评估现场测试流程、指

南来自微软的三篇重要的文档。

1.开发软件产品和服务的微软隐私指南，版本 3.1;2008年9月（Microsof's Privacy

Guidelines for Developing Sofware Products and Services, Version 3.1;September 2008)I

2.微软 MSDN的 SDL——过程指南——附录C;SDL 隐私问卷调查（Microasof MSDNs

SDL—Process Guidance—Appendix C: SDL Privacy Questionnaire)l1]

3.微软 SDL的简单实现（Microsofts SimplijhedImplementarion ofthe Microsof SDL）1

要确定隐私影响等级以及评估相关工作的流程和指南，请参考"开发软件产品和服务的

微软隐私指南"，版本 3.1;2008年9月P和"微软 MSDN 的 SDL——过程指南——附录C∶

SDL 隐私问卷调查"P。评级（P1、P2 或 P3）从隐私的角度表现了软件的风险等级。你只需

要按照指南的步骤就可以完成评估。

·P1∶高级隐私风险。特征、产品或服务对个人身份鉴别信息（personally identifiable

information， PI）进行存储或传输，更改相关的配置或文件类型，或安装软件。

●P2; 中级隐私风险。影响特征、产品或服务的隐私的独立行为是一次性的、用户发起

的、匿名数据传输的（如，用户点击—个链接软件就跳转到—个外部网站）。

·P3; 低级隐私风险。特征、产品或服务内部没有影响隐私的行为。不传输匿名或个人

数据，不存储 PII，没有配置改变用户的利益，不安装软件

第6 章

Core Software Security; Security at the Souree

设计和开发（A4 ）∶ SDL 活动与最佳实践

6.1 A4 策略一致性分析

这部分工作是之前章节所讲的 A3 策略依赖检查的延续。我们会在不同阶段重复地做策略

分析和检查工作。策略依赖分析是最为重要的工作，你要坚持通过实际的工作检查之前的迭

代是否覆盖了所有策略，而不是通过假设。在这个步骤中，你会惊奇地发现之前的阶段和迭

代中会遗漏多少东西。

在这个阶段，任何存在于 SDL 域之外的策略都要被检查（或重新检查）。这些策略可能包

含当在组织中开发软件或应用时来自开发组织之外的策略，这些组织维护要遵守的安全与隐

私需求以及指导方针。在开发过程中策略更新以及需求增加也是经常发生的事。因此你最好

能够对照策略更新列表并确认策略中已经包含了新的需求。

6.2 安全测试用例执行

安全测试是一个耗时的过程，需要适当的准备，确保前后一致，并协调所有利益相关方，

以及对什么是真正测试内容的深刻理解。安全测试很早就开始，并贯穿整个 SDLC过程。安

全测试方法不同于其他形式的测试，因为安全测试的目的是确认软件设计中由于不合理的设

计或代码编写问题而暴露的各种安全漏洞。本书的前提是确保源代码的安全，通过这个层面

的测试，软件能够防止许多只能在网络层面才会暴露的典型安全问题。安全，特别是在设计

层面的安全分析，能够帮助我们在程序成为大型系统的一部分并且需要高昂的修复代价之前，

发现潜在的安全问题和可能造成的影响。软件安全是一个动态的风险管理过程，需要平衡修

复安全问题的花费，以对抗攻击者拥有的技术与资源———直会有聪明的攻击者把精力投入

在挖掘你软件的安全漏洞并对软件造成破坏上。因此，安全测试必须基于利用漏洞以及可能

造成的相关的安全风险评估每个事件的发生概率。

6.3 SDLC/SDL过程中的代码审查

代码审查对于发现软件开发过程中的安全缺陷非常有效。适当地执行代码审查对于代码

安全起到的效果甚至比所有其他活动加起来还要多。代码审查可以让你在代码测试或安装之

前就找到和修复大量安全问题。有 4种分析软件应用安全性的基本技术∶自动扫描、人工渗

透测试、静态分析，以及人工代码审查。当然，所有这些方法都有各自的优点、缺点、擅长

的方面，以及无法胜任的方面。

6.4 安全分析工具

代码安全审查的最终目的是提升产品整体的安全性，使开发组提升安全开发的能力从而

减少代码中犯的错误。本节讨论各种测试方法在整个过程中的功能和角色的细节，包括静态

分析、动态分析、模糊测试以及人工代码检查。但是在开始前，我们需要认识到每种方法都

有各自的优点和局限性。

代码静态分析的优点

\1. 使用现有的命令可以使软件执行

●不需要猜测和解释行为。

●能够产生所有软件可能产生的行为。

\2. 能够找到代码缺陷的精确位置。

3.能够被培训过的完全理解代码的软件保障开发人员使用。

\4. 允许快速修复发现的问题。

.4.1 静态分析

静态程序分析是在计算机软件实际上不执行的情况下进行的测试。静态分析主要用在某

一版本程序源代码的分析上，它也会用在对象代码上。相比较，动态分析实际上是在软件程

序执行后进行测试的。静态分析是使用自动化工具进行测试的，不要与人工分析或软件安全

架构检查混淆，后者一般包括人工代码审查，需要对程序有一定理解。当静态分析使用得当

时，它相比人工静态分析的显著优势就会显现出来，它可以使用比开发者更多的安全知识更

频繁地进行测试。而当确实需要时再使用专业的安全架构师或工程师。

.5 成功的关键因素

SDL 第 4 阶段的成功依赖于遵从策略，执行安全测试用例，完成不同类型的安全测试，

以及验证隐私需求。表 6-1 列出了这个阶段成功的关键成功因素。

表 6-1 关键成功因素

描 述

关键成功因素

覆盖所有相关的测试用例

\1. 安全测试用例执行

完成所有类型的安全测试，修复找到的问题

2.安全测试

\3. 隐私验证和修复

隐私相关控制的有效性，修复找到的问题

按照阶段 4更新策略

4.策略合规性检查

成功因素1∶ 安全测试用例执行

6.2 节提到了安全测试执行计划成功的标准。

成功因素 2∶安全测试

完成所有类型的安全测试——人工代码审查、静态分析、动态分析、渗透测试和模糊测

试———是很关键的。

第7 章

Core Software Security: Security at the Source

发布（A5）∶ SDL 活动与最佳实践

.1 A5 策略一致性分析

就像 SDL 的阶段（A1）～（A4）讨论的那样，SDL 策略一致性覆盖了所有有价值的安全

和隐私风险，并且在每个阶段都进行分析与更新以覆盖新的威胁和活动。特别是，策略中的

活动和标准已经在每个 SDL 阶段更新，从安全事件根本原因的分析中学习合并的课程，适应

改变的威胁环境，促进工具与技术升级。在随后的阶段，跟踪 SDL 策略的遵守情况，如果需

要也会跟踪有高风险问题的项目。从 SDL 的开始阶段，正式定义需要遵守的 SDL 项目质量

授权和需求。这个策略变成了管理 SDL 过程的重要部分，包括∶

●归入标准化 SDL 授权和活动的项目类型

●定义每个 SDL/SDLC 项目阶段必须遵守的策略和过程

●设置版本发布必须满足的需求

在最后的策略一致性分析中，需要对策略进行检查从而保证可以支持基于不同开发标准，

如产品类型、代码类型和平台的特殊需求

.2 漏洞扫描

尽管现在没有人工审查源代码的替代方法，但是自动化工具依旧有着节省时间和资源的

优势。安全漏洞扫描特别适合用于执行这个过程的回归测试，作为双重检查任何可能的安全

漏洞，检查因为不注意将之前已经确定并修复的安全漏洞又重新引人代码。也有这样的可能，

即其他简单功能的产品在 SDL 的开始阶段有了已经披露的安全漏洞，这些也能够在最后的安

全审查中发现。软件产品一般包含 5000 行甚至更多的代码，安全漏洞扫描可以作为性价比

高的、节省时间的方法做最后的 SDL 检查。这些扫描器能够执行大规模的复杂数据流分析从

而确定人工审查过程中遗漏的安全漏洞点。这些产品通过编译代码库来分析每条可能路径以

找到根源级别漏洞，比起人工审查更快更高效。它们也是很好的"检查检查者"工具，即对

软件安全架构师已经进行过人工审查的程序进行审查。

7.3 渗透测试

渗透测试是模拟黑客行为对软件系统进行的白盒安全分析，以发现由代码错误导致的

潜在安全漏洞、系统配置错误或其他操作环境下的部署缺陷。渗透测试也会用来验证代码

是否按照预期设计实现，验证是否实现了安全功能，并发现可利用的安全漏洞。白盒测试

需要了解系统是怎样实现的，从而确保软件产品的健壮性，以对抗预期和非预期

7.4 开源许可审查

尽管开源软件是免费的、创新的、高效的，并且使得软件产品富有竞争力，但是它也必

须按照资产进行管理，遵守许可证，必须像内部开发软件标准一样满足安全需求。有时这些

独特和复杂的许可可以延期，并防止发布过程中不适当管理导致的潜在商业风险。遵守开源

要求是很重要的，能避免花费很多金钱和时间的起诉。当产品的一部分使用了开源软件时，

在 SDL 中管理许可的遵守和安全性上，有两个主要的部分需要关注。

1.开源软件协议的遵守。不遵守开源软件许可要求会导致价格高昂和耗时的起诉，

开庭时间，侵犯版权，媒体披露，不良的公众形象，不遵守许可会带来风险和消极的商

业关系。不当的管理和不遵守开源许可也会导致无法对软件产品提供支持，版本发布延

期或停滞。

2.开源软件安全性。SDL、开发团队以及投资者需要意识到并理解与开源软件代码相关

的安全漏洞会在他们的产品中出现。就像自己开发软件一样，所有开源软件已知的安全漏洞

以及在安全社区公布的安全漏洞必须在 SDL 过程中使用相同的威胁模型进行确认，评估以及

修复，架构性的安全和隐私审查，风险评估。

第8 章

Core Software Scurity: Security t the Source

发布后支持（PRSA1～ 5）

8.1 合理调整软件安全组

首先，我们需要把握每个安全组之间的关系，以及它们对于构建成功的软件安全程序的

重要性。这样做意味着∶

●正确的组织定位

·正确的人

·正确的过程

8.1.1 正确的组织定位

尽管在过去几年里软件安全技术已取得了巨大的进步，但是我们依然坚信人是一个成功

的软件安全程序中最重要的因素，其中包括活动和最佳实践的实施和管理。为了让负责软件

安全的人人尽其用，他们一定是正确的组织的一部分（见图 8-2）。据报道，本书合著者之一，

James Ransome先生曾经担任过七个首席安全官（Chief Security Officer， CSO）和首席信息安

全官（Chief Information Security Oficer，CISO）。基于他的工作经验和与业内同行的交流，很

显然，软件安全功能在理想情况下应该属于工程（软件开发）功能，尤其是质量功能。普遍的

共识是，应用程序安全任职人员通常报告给中心信息安全负责人（CSO/CISO），不能混淆软件

安全功能。通常情况下，那些在 IT安全团队中担任应用程序安全职位的人，善于使用工具进

行测试，但缺乏必要的软件开发背景来充分解释运行结果。为了搞清楚这一点，区分软件和

应用程序安全是至关重要的。也许明晰这种区别的最好方法就是引用 Gary McGraw 的说明∶

.1.2 正确的人

第2 章讨论了为了使 SDL 模型成功所需要的人员配置。这包括至少一个主要的软件安全

架构师，几个高级和一般的软件安全架构师，理想情况下，在每个软件产品的安全组中，至

少拥有一个软件安全架构师。这种关系如图 8-3 所示。这样的人员配置提供了扩展的能力，

在每1级软件产品的每个工程软件产品开发小组中将有理想的一款软件安全冠军（Software

Security Champion，SSC）。人才的另一个要素是组织中的软件产品传道者（Software Security

Evangelist，SSE），即组织大到足以有额外的候选人扮演 SSC 的角色，他们在成为 SSC 之前作

为SSE 的候选人存在。SSE 有两个角色，一个是训练中的 SSC，另一个作为传道者的整体软

件产品安全程序出台政策、执行政策，以及传道整体的 SDL 流程。

8.1.3 正确的过程

正确的过程就是到目前为止本书描述的和图 8-4 总结的核心 SDL 活动与最佳实践。除

了核心活动和最佳实践外，我们在图 8-1中高亮显示了活动和最佳实践。迫于压力，大多数

的公司都要求用最少的资源做最多的事，我估计大多数公司都不会奢侈地将 PRSA 1～5 的

大多数元素作为单独的组织，而是创新性地将其纳入整个软件的安全方案中，以实现现有

资源的优化利用。

.2 PRSA1∶ 外部漏洞披露响应

产品发布后的管理关键是要建立产品安全事件响应小组（Product Security Incident

Response Team，PSIRT），并与我们推荐的机构在产品发布后发现安全与隐私问题时共同承担

责任。无论你的软件在安全方面和相关的 SDL方面做得多么好，都会忽略一些问题，因此你

需要做一个计划以对此作出回应。重要的是，如果在软件发布后经常发现软件安全漏洞和隐

私问题，就说明通过类 SDL 的过程将"安全"构建到 SDLC中的做法是有缺陷的。这样的缺

陷会导致各种问题∶发布后软件存在的漏洞被披露和利用，从而破坏公司名誉;产品名誉的

破坏导致市场份额的损失; 合同违约或被诉讼，等等。

8.6 PRSA5∶ 安全架构审查和基于工具评估当前、遗留以及并购的产品和解

决方案

8.6.1 遗留代码

虽然它们可能曾经被视为不必要的成本负担，但是我们在 SDL 中强调的最佳活动和最佳

实践是发现后的结果，即安全并不总是软件开发过程中的关键因素，有时会导致安全漏洞，

以及与待开发软件的初始成本相媲美的风险缓解成本。遗留代码的验收基于所预期发生的假

设，即必须证明该软件在功能上是正确的、在操作上是可行的。然而，当涉及软件安全时，

意想不到的事通常会导致漏洞。这些安全漏洞不仅在费用上是不可接受的，而且从操作性、

功能性和整体风险的角度来看也是不能被接受的。当该软件支持嵌入式关键系统和应用程序

时这一点特别真实，如在国家和地区基础设施、交通运输、国防、医药和金融中发现的安全

漏洞。在这些应用中，与意想不到的安全软件和系统漏洞相关的责任、成本、使命和业务影

响，被认为是不可接受的。除了遗留软件的架构可以被正确评估，并从安全角度分析，否则

变化的影响无法预测，也不能更有效地应用。这就是为什么在 SDL 中随后的同样测试和严格

审查必须在遗留代码审查中随后进行∶作为减轻意想不到错误的手段。如果按照合适的流程

严谨来做，这将在确保安全的代码实现方面意义深远，这在遗留和新的代码之间是一致的。

8.7 成功的关键因素

外部漏洞信息披露响应过程

在 SDL 周期的发布后阶段，拥有一个明确定义和记录的外部漏洞信息披露响应过程是至关

重要的。利益相关者应该明确，职责分配和责任分配矩阵（可靠的、负责任的、可咨询的和知

情的（Responsible，Accountable，Consulted， and Informed，RACI）矩阵）应创建。更重要的是，只

有一支团队应有责任与客户洽谈漏洞和修复。所有其他团队和利益相关者应该与团队一起工作，

并确保没有其他沟通途径或者任何信息选择性地披露给客户。通常情况下，大客户或者企业客

户会被给予优惠待遇，并获知中小规模企业无法得到的信息。这不是一个良好的安全习惯。漏

洞信息或者全部透露给大家，或者全部都不透露。选择性的披露不是一个好主意，喜欢与客户

玩保密，在某些情况下可能是非法的或影响什么是对于所有客户来说是公平和公正的待遇。

第9章

Core Software Security: Security at the Source

将 SDL 框架应用到现实世界中

9.2 安全地构建软件

在安全软件开发的核心，有三个关键的活动。图 9-2描述了在敏捷和瀑布开发中的这三

个关键活动及它们的关系。每一个程序员必须尝试编写安全的、防御性的和自我保护的代码。

对于程序员来说，不需要安全路径也可以理解以他们使用的编程语言必须做些什么。不同的

编程语言和不同的执行环境需求的侧重点不同。实际上，某一种编程语言存在的问题对于另

一种语言可能不值得考虑;程序员仅仅需要了解 C/C++ 和 Java 之间的区别即可理解这个事实。

C/C++语言允许内存的误处理，事实上，程序员非常容易做一些不安全的操作。相反，Java

语言负责所有的内存处理，程序员不再需要担心内存的分配和回收。

作时会产生副作用（可以被利用）;漏洞是 bug。最终安全从业人员必须评估风险，这是漏

洞的一部分，它是一个自然的职业。但是，开发人员不关注漏洞。他们只关注正确性。算法

写得正确吗?这段代码实现的规范准确吗?这段逻辑生成正确的路径吗?这段代码对于之前

从未见过它的人足够清晰吗?这段代码拒绝无效输入吗?这段代码会崩溃吗?崩溃的项目可

以恢复吗?这些类型的问题使开发人员思考。漏洞通常是错误的副产品，通常不是错误本身。

9.5 测试

设计和编写软件是一门创造性和创新性的艺术，并且也包含相当多的自律性。当尝试写

出有安全保障的无漏洞代码时，创造性和自律性之间的矛盾是尤其真实的。错误是无可避免

的。

SDL 的安全性测试方法的彻底性是关键，测试是 SDL 纵深防御的关键所在。测试方法必

须重叠。由于没有一种测试方法可以满足所有要求的安全保证，所以用彼此重叠的方法来帮

助确保完备性和对所有代码以及会蠕变的漏洞类型进行包装。图 9-11 描述了 SDL 中测试方法

的高层次类型。根据经验，测试方法也是有缺陷的并且可用的工具远远说不上完美。不把安

全保证这些"鸡蛋"放在一个篮子里是很重要的。

9.5.3 攻击和渗透测试

攻击和渗透测试（A&P）—般是由像最熟练的攻击者一样的测试人员完成的。这些测试人

员会侦查目标系统，识别攻击表面。同时这些测试人员将利用那些专家级的攻击者常用的工

具去识别那些明显的错误以及隐藏在系统中的微妙的逻辑错误。相比较而言，逻辑错误是最

难以辨别的。所有错误（除了最简单的逻辑错误）都需要人去识别。

第10章

Core Software Security: Security at the Source

集成∶ 应用 SDL 防止现实的威胁

0.1 战略、战术和特定于用户的软件攻击

既然我们已经描述了安全软件的开发实践，重要的是在这本书末尾，提醒读者使用这些

实践的重要性，以防止今天的网络攻击。在引用几个行业领导者的话之后，对于以基线保护

为核心的安全软件开发实践，我们将给出这种网络威胁的一个深度概述。

10.1.1 战略攻击

通常情况下，战略软件的目标是对于政府、经济和社会必不可少的基础设施功能的应用

程序。关键基础设施的组件包括高速公路、机场与飞机、火车与铁路、公交系统、船舶、运

输系统，基础物资发电厂、电力线的供应网络，以及各种油气管道和设施，这其中又包括供

水和排污系统、土地和手机系统、计算机网络、电视和电台（不仅仅是公开的，还有在特殊

网络中或特殊频率下被私人或政府实体控制的）、银行和其他金融机构、安全、消防、医院，

以及应急服务机构。这些关键基础设施的每个组成元素都必不可少，即使是暂时地停止工作，

也会对整个国家造成巨大的影响。即使某一个领域的基础设施受到威胁，其结果也是灾难性

的。这其中包括电信、能源、交通、供水系统和应急服务系统。当然，战略攻击也包括对于

政府部门必不可少的部分，包括国防、情报机构和其他被竞争对手认为具有极高价值的机构。

0.1.2 战术攻击

网络战术威胁通常非常精确并且在技术上很复杂，同时有高度精确的目标。考虑到这种

攻击战术的特殊本质，开发成本相当高。与战略攻击相比，战术攻击的重要性有所降低。在

一些情况下，战术攻击可以用于增强攻击力或增强其他活动，如军事战役或者其他特殊利益

行动小组的一个补充活动。考虑到战术攻击的精确性，它也可以应用到一系列的破坏活动中。

鉴于战术攻击的成本，它们通常由资金充足的私人实体和政府提供资助，这些资助者往往是

全球性受欢迎的国家、企业或特殊利益集团。

10.1.3 特定于用户的攻击

指定于用户的网络威胁本质上可以是战略性的，战术性的，或者针对个人，针对个人设

备（要么是消费性的要么企业所有的）。使用战略、战术或公开可用的方法来利用特定的个人

或者金融、政治、私人利益的一般用户，将它们作为特定的目标，或作为到达另一个目标的

一种手段，或用户随机破解的目标。

在许多方面，绝大多数的战略和战术

10.2 应用适当设计、管理和集中的 SDL 克服组织与业务挑战

我们概述了一个带有相关角色和责任的组织架构，这些角色和责任特定于在 SDL 模型里

概述的任务，本书的作者已经实地检验和优化了这些任务。本书先前描述的结构能够有效地

创建，实现和控制本书中的最佳范例，同时它也能够通过 SDL 模型中的 A1～ A5 来实现成

功的买进和任务的管理。

实验二 电子传输系统安全-进展

  • 上周任务完成情况（代码链接，所写文档等）
  • 本周计划

上周任务完成情况（代码链接，所写文档等）

  • 小组成员每个人读完《Core.Software.Security.Security.at.the.Source.CN.软件安全.从源头开始》和《The.Security.Development.Lifecycle.CN.软件安全开发生命周期》，并写好相应的读书笔记
  • 根据具体需求集体讨论本小组的安全性设计方案
  • 明确安全性设计方案的分工
  • 集体讨论本小组的系统安全性设计报告，并根据分工进行报告的攥写
  • 细化数据库加固方案

本周计划

  • 将小组的安全性设计方案和系统安全性设计报告编写完毕

  • 确定代码风格和设计规范

  • 小组每位成员掌握国密SM2,SM3,SM4的python实现方式

  • 代码审计，每位成员分别完成自己负责的加固项目

实验二验收-1

任务详情
0. 使用git从码云或github下载小组代码，提交过程截图

  1. 在你的电脑上编译小组项目，提交 截图。
  2. 在你的电脑上运行小组项目，提交 截图。





实验二验收2

任务详情

  1. 你们小组项目要保护的信息资产都有哪些数据？
    (1)用户信息，包含：账号、密码等身份信息，以及权限分级
    (2)文件信息，包含：存储位置、收发部门、签名信息等
  2. 这些数据在数据库中的什么表中？提交数据库相关表的截图。



实验二验收3

任务详情

  1. 你们小组项目中为了保护数据资产用了什么密码算法？
    我们小组项目中为了保护数据资产用了sm2密码算法
  2. 如果用到了对称算法，提交相关生成密钥和对数据加密的代码截图
  3. 如果用到了非对称算法，提交相关生成密钥对和对数据加密，签名验签的代码截图
  4. 如果用到了其他算法，提交相关的代码截图


posted @ 2021-06-20 22:29  Acmer_xsh  阅读(785)  评论(0)  编辑  收藏  举报