20181215 实验报告--实验室 2：电子文件传输系统的安全设计方案与实施

实验二 电子公文

密码功能要求

在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 创建外部安全备注

上一篇： 密码学与加密：代码破解和密钥管理

下一篇： 基于java+springboot+vue实现的药店管理系统（文末源码+Lw）285

推荐阅读

• 20181215 实验报告--实验室 2：电子文件传输系统的安全设计方案与实施