实验二 电子公文传输系统安全--读书笔记

一、《Core.Software.Security.Security.at.the.Source.CN.软件安全.从源头开始》

安全开发生命周期

      最著名的SDL模型是可信计算安全开发生命周期，受欢迎的SDL模型有微软的SDL、Cigital的软件安全触点模型、OWASP SDL、思科的安全开发生命周期。两个非常流行的软件安全成熟度模型：Cigital的内置安全成熟度模型（BSIMM）和OWASP。BSIMM建立了一个最佳实践模型，氛围软件制造商可以遵循的12类。

• 策略和度量标准
• 符合性和政策
• 培训
• 攻击模型
• 安全特征和设计
• 标准和要求
• 架构分析
• 代码审查
• 安全测试
• 渗透测试
• 软件环境
• 配置和漏洞管理

      可用于软件安全的过程和模型有两个要素：技术（工具）和人力。

      三个主要的工具是SDL的基础：模糊测试、静态和动态分析工具。模糊测试是一种自动或半自动化的黑盒软件测试技术，他为某一计算机软件程序输入提供了无效、意外或者随机数据。必须嵌入到SDL中。静态分析（SAST）是指在不实际运行程序的条件下，进行计算机软件分析的方法。主要针对特定版本的源代码，也有些对象是目标代码。有三个好处：

• 可以缩短时间
• 不会感到疲惫
• 帮助开发人员了解安全漏洞

动态分析（DAST）是指在真实或者虚拟处理器中运行程序的条件下，进行计算机软件分析的方法

      两类人才分别是软件安全架构师和软件安全从业者。合格的高级软件架构师会创造或破坏软件安全计划，级别为3或4的高级软件架构师是极为重要的。软件安全从业者不仅要知道如何开发软件，还要了解如何“像黑客一样思考”并拆解软件。

      最小特权原则：在计算环境特定的抽象层中，每一个模块仅仅能访问合法目的所必需的信息和资源。限制特权提升是威胁建模的重要部分，也是SDL架构A2阶段的一个核心组成。保护用户的隐私是SDL另一个重要组成部分，应被视为SDLC所有阶段重要的系统设计原则。

      软件开发方法：瀑布开发：下一阶段开始之前每个阶段结束，并且需要大量的文档。高风险高成本低效率。迭代瀑布开发：整体项目分为不同的阶段，每一阶段采用传统的瀑布方法各自执行，比传统的瀑布方法风险小。敏捷开发：基于迭代和增量的开发方法。需求和解决方案通过自组织、跨职能的团队之间的协同推进，并且从每一代迭代中产生的解决方案在整个过程中定期回顾和提炼。Scrum是一种迭代和增量敏捷软件开发方法，用于管理软件项目、产品或应用程序开发。精益是另外一种日益普及的方法，包括七个精益原则

安全评估(A1)

      安全评估是安全开发生命周期的第一个阶段，在这个阶段中，要解决四项原则问题：

• 软件满足客户任务和关键程度如何？
• 软件所必需的安全目标是什么？
• 那些法规和政策是适用于确定什么需要保护的？
• 在给软件运行的环境中又可能存在什么威胁？

      在这一阶段，软件安全团队提早参与项目并主持发现会议，创建SDL项目计划。启动隐私影响评估（PIA），PIA主要包含以下要点：

• 立法摘要
• 所需的工艺步骤
• 技术和技巧
• 其他资源

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

      度量标准

• 软件安全团队循环的时间
• 参加SDL的利益相关者的百分比
• SDL活动映射到开发活动的百分比
• 安全目标满足的百分比

架构（A2）

      在安全开发生命周期的第二阶段，安全方面的考虑被带入软件开发生命周期，以确保所有的威胁、要求、功能和集成方面的潜在制约因素均被考虑到。

      威胁建模五个步骤：

• 确定安全目标
• 调查应用程序
• 分解它
• 识别威胁
• 确定漏洞

      DREAD模型：潜在损害、可重复性、可利用性、受影响的用户和可发现性，1-10用于建立风险评级，数字越高，风险越严重。DREAD算法用来计算风险值，是DREAD类别的平均值

      成功的关键因素

      度量标准

• 业务微威胁、技术威胁和威胁参与者的列表
• 这个阶段之后不满足的安全目标个数
• 遵守公司政策的百分比
• 软件入口点的数量
• 风险接受、减轻和容忍的百分比
• 重新定义的初始软件需求百分比
• 产品中计划的软件体系结构的变化数量
• 根据安全要求所需的软件体系结构更改数量

设计和开发（A3）

      设计和开发是软件最终用户最为关心的部分。在这个阶段你会做策略一致性分析，创建测试计划文档，更新威胁模型(根据需要)，进行安全性设计分析和总结，以及做隐私实施评估等，帮助你安全地部署软件、建立开发最佳实践，从而在开发阶段的早期消除安全问题和隐私问题。你将会在SDL的设计和开发(A3)以及发布(A4)阶段进行静态分析。

      安全测试的通用步骤：定义测试脚本、定义用户社区、识别项目障碍物、识别内部资源、识别外部资源。测试技术主要分为白盒、灰盒或黑盒。

• 白盒：从内部的角度测试软件，包括：源代码分析、基于属性、源代码错误注入
• 灰盒：设计测试用例的目的是分析源代码，同时也使用黑盒技术，包括：源代码错误注入、动态代码分析、二进制错误注入
• 黑盒：从外部的角度测试软件，没有关于软件的任何知识，包括：二进制错误注入、模糊测试、二进制代码分析、字节码分析、黑盒调试、漏洞扫描、渗透测试。

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

设计和开发（A4）

      A4策略一致性分析是A3策略依赖检查的延续，在这个阶段，任何存在于SDL域之外的策略都要被检查或者重新检查。安全测试是一个耗时的过程，需要适当的准备，确保前后一致，并协调所有利益相关方，以及对什么是真正测试内容的深刻理解。安全测试贯穿整个SDLC过程，在典型的SDLC周期中，软件需要通过QA（质量保证）测试，包括单元测试、性能测试、系统测试和回归测试。安全测试用例执行主要从两个方面开展：安全机制和安全测试。对软件产品和相关系统采取的三种特定的测试类型：基准测试、预定测试和探索测试。

      代码审查对于发现软件开发过程中的安全缺陷非常有效，代码审查可以让我们在代码测试或安装之前就找到和修复大量安全问题。有四种分析软件应用安全性的基本技术：自动扫描、人工渗透测试、静态分析、人工代码审查

      安全分析工具包括静态分析、动态分析、模糊测试和人工代码检查。每种方法各有优缺点。静态分析是在计算机软件实际上不执行的情况下进行的测试，也称为静态应用程序安全分析（SATA）。动态分析是通过再真实或虚拟处理器上运行程序进行计算机软件分析的方法，也称为动态应用软件安全检测（DAST），用来确认应用软件产品中的漏洞。模糊测试是一种自动化或半自动化的黑盒软件测试技术，他为计算机软件输入提供非法的、非预期的数据或随机数据。必须嵌入在SDL中。人工代码审查是通常对软件产品进行逐行检查以发现安全漏洞的方法，有更高的精确性和质量，但是最耗费资源

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

发布（A5）

      这是软件开发生命周期的最后阶段，需要确保软件是安全的，隐私问题已经被解决到软件发布时可以接受的程度。该阶段需要进行漏洞扫描，利用应用程序和数据库签名尝试确认应用程序缺陷的存在。渗透测试是模拟黑客行为对软件系统进行的白盒安全分析。开源软件必须按照资产进行管理，遵循许可证，必须像内部开发软件标准一样满足安全需求，所以要进行开源审查。最后要进行最终安全性审查，对所有安全活动进行重新评估以确认软件产品是否为发布做好准备。还要进行最终隐私性审查**。

      成功的关键因素

      度量标准

• 遵守公司策略的百分比
• 安全漏洞扫描和渗透测试发现的安全问题的数量、类型和严重性
• 发现的安全问题的修复数量
• 发现的严重问题的数量、类型、严重性
• 遵守安全和隐私需求的百分比

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

对SDL的需求

      隐私与安全：隐私可以看作是遵守策略的一种方式，安全则看做是一种执行策略的方式。隐私问题的核心是符合监管部门的要求、公司策略和客户期望。关于安全还需要考虑的一个因素是与客户签订的服务水平协议（SLA）和维护时间。安全与可靠性存在显著差别，但有时候可能会产生冲突。微软可信计算最初关注四个方面，其中三个是技术方面：安全、隐私和可靠性。下图为质量、安全、隐私和可靠性之间的关系

      当前的软件开发方法不足以生成安全的软件，主要有以下四种：

• “只要给予足够的关注，所有的缺陷都将无处遁形”
• 专利软件开发模式
• 敏捷软件开发模式
• 通用评估准则

      “只要给予足够的关注，所有的缺陷都将无处遁形”不行的原因：大多数人并不喜欢审核代码中的bug和漏洞，因为过程缺乏创新性且缓慢枯燥令人厌烦。有一个简单的原则：代码审核的质量，完全取决于待审核的代码的多少；必须有足够多的具备相关知识的人员才能够对代码进行充分的审核；“关注越多”越容易失去要点。

      专利软件开发模式不行的原因：现在有许多开发模式，没有任何证据表明，这些模式中的任何一种能比其中的另外一种缔造出更安全的软件。多数软件开发模式在文档中很少提及“安全”和“质量”。

      敏捷开发模式不行的原因：安全最佳实践不够深入。

      通用评估准则不行的原因：CC所提供的知识表明安全相关的特性已经按照预期执行的证据，他的目标并不是确保监控程序不出现任何实现上的安全bug。

软件安全开发生命周期过程

第0阶段：教育和意识

      微软的bug bush本身是为了找出安全bug，但他的娱乐性远远高于其本身涉及的技术。奠定了微软整个安全教育的根基。还有安全意识演讲，应包含可信计算概述、SDL简介、安全设计基础、威胁建模、模糊测试介绍、安全编码最佳实践。微软所有工程人员每年必须至少参加一次安全培训，也可将在线培训拍下来放到公司内网中。成功的安全教育与意识培训需要三点

• 管理层明确支持
• 富有经验演讲者
• 持续进行的教育

第1阶段：项目启动

      首先判断软件安全开发生命周期是否覆盖应用。原则上来说，所有的软件都能从SDL过程中受益。接着指定一个在SDL过程中指引开发团队安全活动的安全人员，其主要职责是确保最终安全审核能够完成。这个员工叫做安全顾问。安全顾问是开发团队与安全团队之间沟通的桥梁，安全顾问需要召集开发团队举行SDL启动会议，对开发团队的设计与威胁模型进行评审，分析并对bug进行分类。接着是组建安全领导团队，确保在bug跟踪管理过程中包含有安全与隐私类bug。最后建立“bug标准”。

第2阶段：定义并遵从设计最佳实践

      常见安全设计原则：

• 经济机制：保证代码与设计尽可能简单、紧凑。
• 默认失效保护：对任何请求默认应加以拒绝。
• 完全中介：每一个访问受保护对象的行为都应当被检查
• 公开设计：与“不公开即安全”的原则相对而言，认为设计本身不应具有神秘感。
• 权限分离：切勿允许基于单一条件的操作过程
• 最小特权：只授予执行操作所必需的最小特权
• 最少公共机制：使诸如文件以及变量等类似的共享资源尽可能少。
• 心理可接受程度

      进行受攻击面分析与降低，不仅要理解应用的受攻击面组成，而且还要理解如何才能有效地降低受攻击面，从而阻止利用潜在的缺陷代码进行攻击的攻击者。ASR主要有一下几步：确定该特性是否真的很重要、谁需要从哪里访问这些功能、降低特权。

第3阶段：产品风险评估

      安全风险评估被用于判断系统中易受攻击的漏洞级别。需要考虑以下几个问题：安装问题、受攻击面问题、移动代码问题、安全特性相关问题、常规问题、分析问卷。

      隐私影响分级是产品风险评估的第二部分，这个分级包括三个策略值：隐私分级1，隐私分级2和隐私分级3。如果应用满足以下任何一项，就具有最高可能性隐私分级，因而要求具有最高隐私保护职责。

      应用传输匿名数据给软件开发人员或者第三方，则被划分为隐私分级2.如果应用不包含1和2中任何一种行为，则被划分为隐私分级3.

      统一各种因素：一旦确定应用程序的安全与隐私风险，就必须在日程表排出响应时间，以确保应用相应的技能以及努力来减少客户所面临的全面风险。

第4阶段：风险分析

      威胁建模产物是描述应用背景信息并定义高层应用模型的文件，通常包括：应用场景、外部依赖性、安全假设、外部安全备注。威胁建模过程如下：

• 定义应用场景
• 收集外部依赖列表
• 定义安全假设
• 创建外部安全备注
• 绘制数据流图
• 确定威胁类型
• 识别系统威胁
• 判断风险
• 规划消减措施

      威胁模型可以用来辅助代码评审和测试。

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

      创建指导性安全最佳实践文档，主要包括以下几类：安装文档、主线产品使用文档、帮助文档、开发人员文档

第6阶段：安全编码策略

      使用编译器内置防御特性，这些保护性的代码是由编译器自动添加，无需开发人员进行干预，主要的防护选项：

• 缓冲区安全检查：/GS
• 安全异常处理：/SAFESEH
• 数据执行防护兼容性：/NXCOMPAT

      使用源代码分析工具本身并不能使软件变得更安全，很容易落到陷阱中。但源代码分析工具也有益处。切勿使用违禁函数，减少潜在可被利用的编码结构或设计，使用安全编码检查清单。

第7阶段：安全测试策略

      模糊测试最初用于发现可靠性bug，后来证明其也可以发现某类安全bug。模糊操作旨在通过反复解释代码分析数据结构，也可称之为解析器，有三种：文件格式解析器、网络协议解析器、API和其他零散解析器。渗透测试是一个用于在信息系统在中发现脆弱性的测试过程。还有一种测试方式就是运行时验证。

第8阶段：安全推进活动

      一次成功的推进活动需要周密的计划以及从一开始就被列入日程计划中的时间投入。软件开发团队最低程度也需要接受专门的培训，以使其对安全推进活动的期望值以及推进流程等有所了解。计算机上运行的所有代码或成为你软件的一部分的代码都必须被评审，而且该评审与代码年限没有关系。架构师和程序经理们需要对威胁模型进行不止一次的评审。在安全推进活动期间的程序化管理方式推动重估受攻击面的任务完成，会获得两个主要的收益：好的安全习惯和有助于推动代码评审任务的优先程度评级。最终，编写终端用户文档的作者和编辑们都应当对他们所有的草稿文档进行评审，以验证安全最佳实践是正确无误的，且文档中没有述及潜在有危害的实践。

第9阶段：最终安全评审

      完整的最终安全评审过程有四个步骤，一是产品团队协调，这一部分不是纯技术性的活动，团队必须填写一个调查问卷。二是再次评审威胁模型，三是未修复的安全bug评审，验证那些标记为“暂不修复”的安全bug是否可真正对其不予理睬。四是工具有效性验证。

第10阶段：安全响应规划

      为什么准备响应？因为开发团队一定会出错，新漏洞一定会出现，规则一定会发生变化。准备安全响应包含两个过程，第一是建立一个安全响应过程，第二就是每一个产品开发团队的责任，组建一个安全响应中心

      产品团队有效的执行响应过程是十分必要的，有两个指导原则，一是准备安全响应的时间应位于漏洞被上报之前；二是每一个软件团队都必须做好安全响应准备。主要步骤：组建相应团队、支持全线产品、支持所有客户、使产品具备更新能力、在研究人员之前找到漏洞。

第11阶段：产品发布

      如需软件被签字通过，安全与隐私团队就必须认可以下事实：SDL过程被正确无误地贯彻落实了。

第12阶段：安全响应执行

      遵从你的计划，如果有新上报的漏洞，保持冷静，记住欲速则不达，留意可能改变计划的事件，遵从你的计划；尽你所能补救，深谙取舍之道