安全开发生命周期
软件安全开发周期
第0阶段：教育和意识
微软安全教育简史
基本的安全培训：
疏于修复安全bug的常用借口 参考文献中列出了在“Writing Secure Code, Second Edition一书（Howard and LeBlanc 2003 ） 所提及的"我们听说过的最滑稽可笑的 借口”。当然这更像是一个诙谐的矛与盾的故事集，但诙谐是必要的，因为这有助 于人们加深印象。
能够导致威胁设计问题 诸如默认端口开放、注册键值存储有误、绕过认证与授权 机制、欺骗性登录方式等设计错误比比皆是，应该引起更多的重视。
理解软件所面对的种种威胁 根据长达五年的威胁建模研究过程所得经验、我们将 在第9章“第4阶段：风险分析"中详细讨论软件所面临的威胁。
不安全的编程技术 对缓冲区溢出、跨站脚本、SQL注入以及弱加密等常见编码错 误进行简单分析。因为早期很少出现整型数值错误，因此当时也少有人谈及。
持续教育
安全的软件设计、开发与测试基础
模糊测试精要
威胁建模精要
实施威胁消减措施
安全设计与架构：久经考验的设计原则
SDL介绍与最终安全评审过程
安全工具概述
实战安全代码评审
安全编程实觸
安全bug精要
受攻击面分析
漏洞开发
打包过程需求
安全响应
加密范例
客户隐私
培训交付类型
开发一个新课程的一般参考性过程：
课程特定对象以及目标听众。
一个安全专家创建该新课程。
其他专家对课程资料就技术准确度以及可应用性进行多次审核。
培训专家(非安全)查找一致性以及排版错误，并校对课程资料。
我们提交一个beta课程，该课程的目的在于对时间进度进行微调并获得初步内容反 馈。
我们根据初步反馈意见更新课程资料。
我们在六个月内至少每月交付一次该课程。
六个月后，我们对该课程进行录像并将其放入内网。
练习与实验
练习与实验在帮助学员巩固新的概念方面起着难以置信的重要作用。
追踪参与度与合规度
微软在开发一个符合SDL的产品前，所有工程师必须参加过相应的安全培训。当学员 参加培训课程时，他们需要在入口处出示自己的员工ID卡，该信息会被自动输入到一个与 员工教育记录有关的培训参与者数据库中。我们可以利用该数据对安全课程的参与度进行 统计，如经理级与副总裁级别各占多少比例。
度量知识
度量知识，从字面意义上来看非常简单，但对于一个开发软件的公司来说，事实上是 一个相当复杂的词汇。之所以复杂，原因就在于难以对如何处理结果作出新决断。譬如决 定员工是否胜任代码跨平台移植任务，如果某员工一而再、再而三的失败，是否应该炒他 觥鱼等难以抉择的问题都会出现。正如你所想的那样，既然有大量的法律条文来衡量员工 的安全方面达标与否，同样当然也应该有条文来衡量员工的知识程度。那么究竟是用培训 之后的即时考试方式还是以阶段考试方式？在线还是离线方式考试？开卷还是闭卷？如何防止作弊等诸多问题。这里需要强调的是，微软是一个软件公司，而并非大学。
实现自助培训
对软件开发相关的所有人员来说，为他们开设一门关于“好”的安全以及隐私保护 实践的基础安全课程实属当务之急。这正是形成微软“安全基础"培训的初衷。我们要求 所有的工程人员必须参加该培训，并在此基础之上建立一个最小安全基准。此类课程的目 的并不是要将普通雇员转变为安全专家，最根本的目的无非是为了提高雇员的安全意识，并为工程师传授最基本的安全知识，让他们知道他们应该去哪里获得更多关于安全、隐私 相关的信息，以及接下去该做些什么，仅此而已。另外，我们还告诉工程师在出现麻烦的 时候知道需要去联络谁，并及时获得帮助，这是非常重要的。
关键成功因子与量化指标
成功的安全教育与意识培训需要三点：
管理层明确支持
富有经验演讲者
持续进行的教育
第1阶段：项目启动
判断软件安全开发生命周期是否覆盖应用
至少符合以下列出标准中任何一条的软件必须服从软件开发过程。
·常被使用或部署某项业务的任何产品，如电子邮件服务、数据库服务器等。
·定期存储、处理或交换个人身份识别信息（Personally Identifiable Information, PII）, 如金融、医疗以及更为敏感的客户信息的任何产品。根据一项针对儿童在线保护的COPPA法案要求(COPPA 1998),尤其是针对儿童的任何产品或服务更需受到特别 关注。
·定期连入互联网或在互联网上响应请求的任何产品。
＞始终在线：诸如即时消息软件之类的，始终接入互联网提供服务的产品。
＞设计要求在线：如Web浏览器或者邮件客户端等展示互联网信息功能的产品。
＞展示性在线：如移动代码或多人手机游戏等通过访问互联网获得在线支持类的产 品组件。
·具备自动下载更新机制的任何产品。
任命安全顾问
安全顾问的任务包括：
·担任开发团队与安全团队之间沟通的桥梁。
·召集开发团队举办SDL启动会议。
·对开发团队的设计与威胁模型进行评审。
·分析并对bug进行分类，如安全类、隐私类。
·担任开发团队的安全传声筒。
·协助开发团队准备最终安全审核。
·与相应安全团队协同工作。
我们将对所有任务逐一进行分析。但在分析前，我再次提醒大家不要忘记安全顾问的 最终目标是：帮助产品团队在安全方面做得出色并实现安全。
担任开发团队与安全团队之间沟通的桥梁
在SDL过程形成前，产品团队与安全团队之间的沟通是毫无章法，甚至容易产生误解。 为了解决这个问题，担任开发团队联络中枢的安全顾问应运而生。值得一提的是，在开发 小组中已经选择了一个人充当该开发小组的安全专员，该专员与安全顾问共同构成安全信 息的沟通渠道。因此，安全顾问与安全专员至少要对所有安全、隐私类的沟通保持高度的 重视，当然在必要时开发团队中的任何人都可以与安全顾问进行直接沟通，反之亦然。
召集开发团队举行SDL启动会议
在整个开发项目正式进行之前，安全顾问应该为所有参与工程人员阐述SDL的目的以 及SDL过程中的关键点。通常情况下，该讲解过程时长约一个小时。当务之急，是确保最 起码所有开发、测试、程序管理的主管都参加该会议。当然对于管理者以及安排日程的人 员来说，理解将SDL工作任务以及交付物都必须归入开发过程之中也是十分重要的。
对开发团队的设计与威胁模型进行评审
当设计阶段的所有设计接近完成时，安全顾问应当与开发团队共同讨论设计以及系统 架构。这一过程中，安全顾问应仔细分析设计以求尽早发现其中的安全问题。安全顾问应 确保如下：
•该应用具有低受攻击面。
•该应用利用相适应的开发最佳实践。
•该应用服从安全设计最佳实践。
•相应威胁模型完备且能够切实反映系统的防御机制。
•具备适应的测试与检验覆盖面。
分析并对bug进行分类，如安全类和隐私类bug
一般情况下，我们在开发阶段就可以检测到大部分bug,并依据安全、隐私类别对其 进行重新分类。对于这类bug来说，为确保能够对每一个bug釆取正确的应对措施，安全 顾问应该具备大量的安全技能。其中一部分通过代码或设计变更可以修复，而另外一部分 可能因为风险级别很低，或者修复所需工作量可能过大而暂时不予修复。对于安全顾问来 说，无论采取哪种方式，仔细审核每个未修复的安全、隐私bug是十分重要的
担任开发团队的安全传声筒
安全顾问应当对产品团队中提出的任何与安全、隐私有关的问题做出回答。更进一步 来说，顾问应当鼓励这种言论方式，并对其评估和尽可能地验证有效性。在微软内部，该 过程通常可以用图6 1来表示，但是许多软件开发厂商并没有足够的成本来维护一个集中 的、专门的安全团队。这种情况下，顾问很可能不仅要充当所有安全问题的安全联络人， 而且还要成为问题解决者。
因此作为软件开发团队的安全顾问应当掌握大量安全知识以及教育方面的资源。
协助开发团队准备最终安全审核
在产品交付之前，其必须要成功通过第14章，“第9阶段：最终安全审核'‘中所定义 的最终安全审核。安全顾问的一个重要职责就是确保所有SDL要求的任务都顺利完成，以 便最终安全审核能够顺利进行。因为最终安全审核是最终产品提交给客户的最后一道门槛, 所以最终安全审核要求严格也就不足为过了。
与相应安全团队协同工作
一旦开发的产品中发现一个已经公开报道过的安全bug,这对安全顾问来说将缩短分 析问题的周期，同时有大量的背景知识有助于顾问选择最合适的修复方式。
组建安全领导团队
对于所有的软件开发厂商来说，一定有一个人或者一个团队负责领导开发过程。在微 软，有一个中心项目管理团队日趋一日地推动不同团队间的沟通、计划任务等工作。该团 队理所应当对项目负起安全领导责任。该团队的任务包括：
・定期通过电子邮件等方式与开发团队沟通安全、隐私方面的bug数量。
・及时更新安全与隐私策略。
这个角色与开发团队负责联络的人员有所不同；开发团队的安全联络人员通常情况下 以技术方面问题为主，而该安全领导团队中该角色以处理策略以及沟通方面的问题为主。
确保在 bug 跟踪管理过程中包含有安全与隐私类bug
在bug跟踪管理软件中需要增加以下 SDL必需的bug跟踪域：
安全/隐私bug后果
安全/隐私bug原因
安全/隐私bug后果域应包含如下预定义值：
非安全类bug
假冒
篡改
抵赖
信息泄漏
信息泄漏
拒绝服务
特权提升
受攻击面降低
安全/隐私bug域应包含以下预定义值：
非安全类bug
缓冲区溢出或下溢
算数类错误（如整型溢出）
SQL/脚本注入
目录遍历
竞争状态
跨站脚本
密码弱点
弱身份认证
弱身份授权/不匹配ACL
无效秘密隐藏
资源消耗（拒绝服务DoS）
错误/无出错信息
错误/无路径名
其他
建立 “bug 标准"
应该确定在项目开发生命周期中的哪些类型的bug,包括安全与隐私类bug, 亟需修复。建立bug标准有助于降低对该修复哪些bug,该消减哪些bug,甚至哪些bug仍 未被修复等所产生的混淆。SDL的任务就是在产品发布之前修复关键、重要以及中等程度 的安全和隐私类bug。
第2阶段:定义并遵从设计最佳实践
常见安全设计原则：
•经济机制保证代码与设计尽可能简单、紧凑。软件愈复杂，代码中出现bug的几 率愈高。如果代码尽可能简短，那么出错几率也少。
•默认失效保护对任何请求默认应加以拒绝。因此，如果用户请求失败，系统仍可 保障安全。
・完全中介每一个访问受保护对象的行为都应当被检査。按照最佳实践对受保护对 象要进行尽可能细粒度的检査。举例来说，如果你基于Web的应用保护了一个文件, 操作系统的文件系统访问控制列表(Access Control Lists, ACL)相对于在Web代码 中单一的访问检查而言，是一种更为强大的保护机制。
•公开设计 公开设计，与“不公开即安全”的原则相对而言，认为设计本身不应具 有神秘感。这一原则的具体表现可以参见应用于加密设计的Kerchoff定律，“系统不应单纯依赖私密性，若落入敌人手中则毫无优势可言”(Wikipedia 2006)o
•权限分离切勿允许基于单一条件的操作过程。如双因子身份认证或者更高层次上 进行的职责分离。
•最小特权只授予执行操作所必需的最小特权。本章稍后将对该原则进行阐述。
•最少公共机制使诸如文件以及变量等类似的共享资源尽可能少。当对同一个文件 进行修改操作时，单独控制一个操作过程比并行控制两个过程要更容易一些。
•心理可接受程度 安全的产品是否易于使用？如果不是，没有人会用。你应该经常 询问自己，“我能用一种产品更便于使用的方式实现整个系统么？切记不要忘记你 的用户。心理可接受程度需要大量的技能与UI (User Interface)设计专长。
受攻击面分析与降低：
软件产品的受攻击面是一个混合体，不仅包括代码、接口、服务，也包括对所有用户 提供服务的协议，尤其是那些被未经验证或远程的用户都可以访问到的协议。ASA就是枚举所有接口、协议以及可执行代码的过程。本章剩余部分将给出ASR阶段应该考虑到的一 些元素，如位于远程可访问套接字（Socket）后的代码与位于关闭的套接字之后的代码相 比，其受到攻击的风险比后者更高一些。
从更高层次上来说，ASR着重于
・降低默认执行的代码量。
・限制可访问到代码的人员范围。
・限定可访问到代码的人员身份。
・降低代码所需权限。
第一步：该特性真的有那么重要么？
第二步：究竟谁需要从哪里访问这些功能？
第三步：降低特权
其他受攻击面组成部分
UDP vs. TCP
弱权限VS.强权限
,NET Code vs. ActiveX Code
ActiveX "脚本安全”
ActiveX SiteLocked 控件
第3阶段：产品风险评估
安全风险评估：
安装问题
受攻击面问题
移动代码问题
安全特性相关问题
常规问题
分析问卷
隐私影响分级：
隐私分级1
如果你的应用满足以下任何一项，其具有最高可能性隐私分级，因而要求具有最高隐 私保护职责。
该应用储存pii或将pn传输给软件开发人员或第三方人员。
该应用的目标是针对儿童或者对儿童产生吸引力，或者包含任何可以了解年龄的用 户体验。了解儿童可能使用的应用在线隐私政策是相当重要的，因为按照Children's Online Privacy Protection Act (COPPA 1998)法案要求收集PII需要成人权限，此类 应用必须保护13岁以下儿童。
该应用不间断监控用户行为。
该应用安装新软件或改变用户文件类型关联(例如，其修改处理JPEG文件的默认 . 程序)、主页或搜索页。
隐私分级2
如果你的应用传输匿名数据给软件开发人员或者第三方，该应用被划分为隐私分级。
隐私分级3
如果你的应用不包含隐私分级1、2中任何一种行为，该应用被划分为隐私分级3。
统一各种因素(Pulling It All Together)
一旦已经确定应用程序的安全与隐私风险，就必须在日程表中排出响应时间，以确保应用相应的技能以及努力来减少客户所面临的全面风险。例如，如果你的软件产品有 多个安全风险，你就必须对其进行评估，并对每个风险进行分析，以确保为保护客户而做 出正确安全决策。
第4阶段：风险分析
威胁建模的好处：
有助于整个风险管理过程，因为软件和基础架构中所面临到的威胁正是用户以及软 件部署环境面对的风险。
在系统进入编码阶段之前发现系统威胁。
开发团队通过威胁建模可以重新验证其架构和设计。
强制开发人员从安全、隐私的角度再次审视整个设计，以理解最具风险的功能组件。 为了理解最具风险的功能组件，开发人员将注意力集中于那些具有高攻击概率的组件。
有助于进一步明确针对应用以及环境釆取相应的解决对策。
有助于软件的受攻击面降低过程。
有助于指导整个代码审核过程。
指导整个渗透测试过程。
威胁建模产物 （Artifact）
相关的背景信息应包含如下内容：
应用场景 部署配置以及广泛客户使用。
外部依赖性 应用或者系统所依赖的外部产品、功能或者服务。
安全假设 采用来自其他功能组件所提供的安全服务假设。
外部安全备注 对产品终端用户或管理员安全的操作系统有用的其他信息。
对什么进行建模
最开始，应该考虑你的应用的可信任边界，并且对该信任边界范围之内的所有功能组 件进行建模。其次，关注边界之外以明确应用的最实际部分是什么。如果答案是“没有”， 那么你就成功地确定了数据流图的范围。
创建威胁模型
我们听说的最多的一个问题就是“谁该创建威胁模型？ ”威胁建模过程应该由一个设 计人员负责，可能是一个架构师、程序经理或者分析人员。具备深厚安全背景的设计人员 可能更适合这一角色。其他诸如软件开发、用户教育以及测试等工程部门都应配合提供重 要的设计信息，但他们并不致力于推动整个过程，这一任务是留给设计人员的。毕竟，威 胁建模是设计过程不可分割的一部分。
站在更高的层次上看，整个建模过程步骤如下：
•准备系统设计人员负责准备过程，并从开发团队中得到输入以绘制数据流图。结 果应在核心威胁建模分析过程开始之前被发送给其他团队成员审核。
•分析整个分析过程中发现的威胁都应被记录在威胁模型文档中。在这一阶段，分 析过程将涉及更多的人。因此，在人数多于10时，要尽可能保证参与人员处于有序 管理状态之中。另外，谨记该阶段讨论的重点是威胁，而不是消减措施。
・定义消减措施产品团队则更多地半精力集中于识别消减措施上。在威胁模型基本 完成后就应该进行这一步骤。团队应仔细分析模型以决定最适宜的消减措施。毫无 疑问，从未参与早期分析阶段的人员中会得到重要的反馈，这恰恰是整个过程所需 要的。
本章的剩余部分将详细描述整个威胁建模过程，具体如下:
·威胁建模过程
·消减技能
·利用威胁模型辅助代码审核
威胁建模过程
尽管创建威胁模型过程中的所有步骤看上去相当繁琐，但其中大多数都不需要过多的 安全技能，甚至只需完全的按部就班即可。列举如下：
\1. 定义应用场景。
\2. 收集外部依赖列表。
\3. 定义安全假设。
\4. 创建外部安全备注。
\5. 绘制一个或多个待建模应用的数据流图。
\6. 确定威胁类型。
\7. 识别系统威胁。
\8. 判断风险。
\9. 规划消减措施。
利用威胁模型辅助代码评审
威胁建模过程中的交付物之一就是一个系统输入点清单。这事实上就是场景图中展示 的东西。如果你仔细看较早之前的图9 3, Pet Shop 4.0场景图；你就能看到三类系统主要输入点：匿名用户输入点、Pet Shop顾客输入点以及管理员输入点。在进行Pet Shop代码 安全bug评审时，首要的就是对远程和匿名方式可访问的所有代码进行评审。简单浏览一 下数据流图以确定相应方式下可访问的元素内容。
利用威胁模型辅助测试
我们曾提及，针对特定的威胁类型（如：假冒和篡改）应有特定的消减措施。这些措 施本身也可能遭受攻击。明确如何构造攻击或者参照本书第22章定义出的威胁树模式，并 考虑每一棵树上的每一个叶子节点进行渗透测试。这些叶子节点不仅能够给予你设计洞察 能力，也能给予你攻击洞察能力。请参照第22章获得更多信息。
关键成功因子和指标
什么才能缔造一个好的威胁模型？长久以来在微软，我们为此问题争论很久，因为确 定一个好的威胁模型总是过于主观。这个谜团有点像大法官Potter Stewart关于色情定义的 著名评论（Stewart 1964）： “当我看到它我就知道它是什么”。最终，在Windows Vista开发 过程中，我们有很多用于评估的威胁模型，而且我们使用指标将好的威胁模型与不太好的 区分开来。我们最后采用了表9 12所示版本的度量指标。
最低限度，威胁模型也应被评为“OK”，而且用于渗透测试的部分至少也应为“好" 或者以上。
第5阶段：创建安全文档、 工具以及客户最佳实践
能确保客户处于受控状态之中的唯一方式就是为他们提供可操作的安全指南以及工具。
为什么需要文档和工具？
应用SDL时，你将花费时间以缔造更为安全的设计、生成安全bug更少的更为安全的 代码，并且创建用于帮助确认软件产品更安全的工具。在你完成所有的这些任务之后，你 就可以将软件交付给客户并帮助他们执行这些任务。客户大都以自有的方式使用产品，而 且并不是所有的客户都会以默认安全配置方式使用产品。因此为客户提供更为详尽的安全 信息很重要，以使其一方面能够做出明智之举——如何安全地部署产品，另一方面使其能 够切实理解所做出的安全配置决策的真实含义。因为安全与可用性之间存在由来已久的矛 盾，所以更重要的是教导客户无论是在现有威胁，还是处于风险的交易过程、产品功用等方面都做出如何操作和部署产品的正确决策。
创建指导性安全最佳实践文档
首先，需要指出的是本章并不是一个如何撰写提供给客户的文档的教程。相反，本章指出了你应当添加到文档中的安全最佳实践信息。
第一步首先是对现有文档进行梳理。在这一过程中，你可以进一步明确哪些安全信息 应当被纳入进来。以下将讨论各种不同形式的文档，并给出一些你应当增加的内容建议。
安装文档
安装文档之所以非常关键是因为其描述了在安装应用时所应遵循的最佳实践。
主线产品使用文档
这部分最关键的工作就是你应当让安全专员对用户手册这一文档的草稿进行审阅，并对可能含有不安全操作的部分进行评论。
帮助文档
帮助文档与一般文档相比，更倾向于面向多个任务对象；一个用户按下快捷键F1后， 就可以开启帮助并弹出具有任务敏感性的帮助。正因为帮助本身是具有任务敏感性的，你 应当为每一个任务都进行合适的裁减以囊括相关安全最佳实践。这将使你所给出的建议更 具有针对性。
开发人员文档
如果你提供了使开发人员能够利用一个API或者一套类、对象在平台上进一步开发应 用，那么你就应当在每个可应用的函数以及方法调用中说明安全信息以及最佳实践。
创建工具
SCW****：
禁用不需要的服务。
阻止无用端口。
允许对已开放端口进行安全限制或约束。
如果必要，禁止不需要的US Web扩展。
减少针对服务器消息块(Server message block, SMB)、LanMan以及LDAP (Lightweight Directory Access Protocol)等协议的暴露程度。
定义相应的审计策略。
第6阶段：安全编码策略
使用最新版本编译器与支持工具
究其根本，一个开发人员所写的代码势必要被编译成机器可以执行的某种格式，并产 生包括编译器防御特性在内的代码。我们在下一部分将对这一过程进行剖析。你也应当首先定义使用的编译器与工具标记。这些包括优化标记、联编器选项等在内。
使用编译器内置防御特性
新版本的微软编译器为已编译代码增加防御特性。这些保护性的代码是由编译器自动 添加，无需开发人员进行干预。主要的防护选项如下：
•缓冲区安全检査：/GS
•安全异常处理：/SAFESEH
•数据执行防护兼容性：/NXCOMPAT
缓冲区安全检查：/GS
是防御性代码的最著名的一个例子，由编译器在应用中插入代码，帮助检查 运行时某些种类的缓冲区溢出。微软最先在Visual Studio.NET 2002上采用该机制，并在 Visual Studio 2005中改进发布最新实现。
安全异常处理：/SAFESEH
联编选项在可执行镜像中仅加入安全的异常。其通过增加额外的经操作系 统运行验证过的异常处理信息，确保代码在调用一个有效的异常处理而不是一个被劫持（重 写过）的异常处理。
数据执行防护兼容性：/NXCOMPAT
联编选项意味着可执行文件经测试与微软Windows中的数据执行保护 (Data Execution Protection, DEP)特性完全兼容(Microsoft 2005)。
使用源代码分析工具
源代码分析工具陷阱
两个陷阱
· 第一个陷阱：根本没有用于安全代码的“银弹”之说；你不得不做很多事情使代码变得更 为安全，而工具仅仅是其中的一个组成部分。想当然地认为你可以通过运行工具而发现所 有某特定类型的bug,是一个错误的而且是危险的开始。
· 第二个陷阱：在寻找实际bug时不免导入歧途(也称干扰)。
源代码分析工具的益处
两点好处：
第一， 有助于将代码审核过程规模化
第二， 有助 于执行安全编码策略
切勿使用违禁函数
存在大量的函数，甚至是20年前，不足以应对今日的威胁。你可以通过使用头文件、代码扫描工具或者更新后的编译器等发现违禁函数。
减少潜在可被利用的编码结构或设计
一些常用的编码结构或者设计并不安全。例如，在Windows中，创建一个具有空DACL 的对象是可行的，也就是说一个具有空访问控制列表的对象，毫无保护。
使用安全编码检查清单
创建一个用于描述在生成软件产品时的任何代码最小需求的安全编程检查清单。拥有 一个可遵循的检查清单对于确保代码满足最小安全要求是十分有用的。尽管检査清单是相 当有用的，你也不能简单地按照检查清单去撰写安全的代码。
第7阶段：安全测试策略
模糊测试
三种主要 的解析器：
•文件格式解析器例如：包括操作图片文件（JPEG、BMP、WMF、TIFF）的代码或 者文档以及可执行文件（DOC、PDF、ELF> PE、SWF）。
•网络协议解析器例如：SMB、TCP/IP、NFS、SSL/TLS. RPC 以及 AppleTalk。你 可以通过在请求之前即发出响应等的方式来打乱网络操作顺序。
• API和其他零散解析器例如：包括浏览器 可嵌入协议处理器（诸如callto:） 让我们对每种解析器类型逐一详解。
模糊操作文件格式
•识别应用所支持的所有文件格式。
•收集一个应用所支持的有效文件库。
•对文件进行畸形化操作。
•让应用读取该文件，并观察应用
网络协议模糊操作
三种对网络流量进行模糊操作的有效方式：
•创建伪造数据包
•记录 模糊 回放(Record fuzz replay)数据包
•仅在数据包被置入网络前或刚被网络读取之后进行畸形化。
零散模糊测试
任何使用、操作或分析来自于未经信任的数据结构的代码都必须被解析。好的例子如 用于ActiveX控件或者任何诸如Java、Macromedia Flash的移动代码，或者可以在浏览器中 执行的.NET代码，识别出这些代码的所有方式和属性并系统性地对其进行模糊测试操作， 最简单的处理方法就是编写一个可示范移动代码的HTML页面，并使用JavaScript对所有 移动代码所有的方式和属性进行模糊测试操作。对于位于移动控制设备上的URL也要进行 模糊测试操作。例如，构造使得URL很长(长于1000个字符),并观察移动代码是否能 够处理该URL,并检査从哪里装载哪个URLo
通过模糊测试修复发现的bug
如何理解每一次崩溃或意外错误究竟代表着一个什么样的具体问题，这一点非常重要, 因此你应当经常对此类反常现象进行调查。在你确切理解问题之后，才能给出安全相关的 结论。如果你没有测试代码，那么肯定会有其他人替你做这件事，并造成更严重的后果。
如果你通过模糊测试发现了代码中的大量bug,那么停下正在做的事情，并开始更深 入的代码审核。代码审核和模糊测试二者密切相关。
最后，切勿忽视用于模糊测试的一小部分计算机所起到的价值。循环处理100000个或 更多文件可能是非常耗时的一项活动，因此专门分配一小部分机器用于模糊过程是相当有 用的。
渗透测试
渗透测试（pentesting）是一个用于在信息系统中发现脆弱性的测试过程。你应当在产 品开发的测试阶段就开始计划渗透工作。
运行时验证
最后一种测试方式就是运行时验证测试，其利用诸如AppVerif之类的工具检测代码执 行时的某些特定类型bugo AppVerif在之前的模糊测试过程部分的章节中已经讨论过了。 然而，其用处不仅仅局限于模糊测试；也可被用于在常规测试或者分析中来发现严重的安 全缺陷。因而，你应当定期的使用AppVerif运行应用程序，并审核日志文件以确保没有待 修复的问题
必要时审核并更新威胁模型
威胁模型是安全测试中用到的一些价值难以估量的文档。有时候，在项目的设计阶段 之后，功能和具体实现会发生变化。威胁模型就应当被重新审核，以保证仍能够精确并且 完整地覆盖软件所提供的所有功能。威胁模型可被用于推动和提醒安全测试计划的执行。 一个应用的最具有风险的部分通常情况下就是那些具有最广泛受攻击面的部分，而且威胁本身就是需要进行彻底测试的最高级别风险。
重估软件的受攻击面
在SDL测试阶段应对产品的受攻击面重新进行评估。度量受攻击面有助于团队更好地理解 究竟哪些功能组件直接面临攻击威胁，哪些会在存在漏洞时具有最高损失风险。评估受攻 击面的大小可以使团队将测试以及代码评审等工作集中于高风险区域，并采取相应纠正措 施。此类纠正措施可能包含只在漏洞修复后才发布相应功能组件的决定，默认禁用一个功 能组件，或者修改开发实践以降低漏洞在后期修改或重新开发时再次被引入的概率。在受 攻击面被重新评估之后，该受攻击面应当被归档以反映其基本情况。
第8阶段：安全推进活动
安全推进活动过程：
培训
代码评审
威胁模型更新
安全测试
文档
准备安全推进活动
一次成功的推进活动需要周密的计划以及从一开始就被列入日程计划中的时间投入。承担产品安全职责的人员应当推动该安全活动， 包括组建推进领导团队。该团队还应囊括小部分人员，其可以代表所 有产品设计、开发阶段，诸如开发、测试、文档、设计以及项目管理，同样还应包括团队 中的一个或多个与日程表中活动密切相关的，最终将软件交付给客户的相关人员。
安全推进活动并非随着时间意义上的最后终止而完成，只有当必需的任务都完成后才 标志着该推进活动顺利完成。常见的退出标准如下：
・所有人员都接受过最新的安全培训。
・所有高优先级（Pril）的源代码都被评审过且已经签字通过。
・所有高优先级的可执行代码都应由测试人员签字方可通过。
•所有威胁模型都已经被重新评估且更新（至少，所创建的威胁模型应针对所有功能 组件，而并不是仅针对那些非常老的功能组件或者产品）。
・受攻击面也被重新分析，而且默认受攻击面的适用性也应被确认。
・所有文档都应被审核过以纠正安全指南。
培训
软件开发团队最低程度也需要接受专门的培训，以使其对安全推进活动的期望值以及 推进流程等有所了解。部分雇员可能需要参加与安全相关的技术类培训，举办这些技术培 训是值得的。一旦参与该年度培训的团队成员比例越高，此类技术课程就越显得有用。
代码评审
第一步就是对每一个源代码文件的所有者分配权限、相关所有文件等 建立一个数据库。
文件名：文件名称，包括存储目录。
文件属主：文件属主姓名。
优先级：评审代码的优先级。等级范围从1到3, 1为最高优先级。
评审者：评审该代码的人员名称。如果多人评审，就要单独列一个表以存储所有评审 人员名称。
评审结果：该域仅包含三个可能值：是、否、部分。
评论：评审者评审代码过程中关于该文件的所有可能有价值的评论。
第二步明确评审优先级
默认运行、在互联网上侦听或者连接至互联网的代码优先级为1。
存在为数众多且优先待解决的漏洞的代码优先级为1。
以高特权（例如，SYSTEM、administrator, root等）方式执行的代码优先级为1。
安全相关类代码（例如，认证、授权、加密以及防火墙代码等）优先级为1 =
对于.NET代码来说，未经验证的代码优先级为1=你可以使用PEVerify工具 （Microsoft 2006）判断微软的中间语言代码是否经过验证。
对潜在不可信来源的数据结果进行解析的此类代码优先级为1。
以用户权限运行的可选安装代码，或者默认安装但并未达到任何优先级为1的标准 的代码优先级为2。
安装类代码一般优先级为3,但一些对访问控制权限、密钥或密码进行设置的代 码不在此范围之内。因为数据的敏感性、默认权限设置错误的可能性或者安装时 在不适当的位置留下安装密码之类等错误，建议考虑将后者优先级设置为lo （我们很惊讶地发现类似事件在过去屡有发生［Secunia 2004］。）
Q/A或者测试主管，非开发团队，必须对此优先级清单确认通过。
最后建立一个囊括产品中所有可执行文件清单，并在此基础之上为每一个组件分配一个测试属主。
可执行文件属主
测试属主：负责测试该组件的测试或Q/A人员姓名。
优先级：评审代码的优先级。等级范围从1到3, 1为最高优先级。
验证：是或否。
评论任何与该组件或验证过程有关的评论
威胁模型更新
架构师和程序经理们需要对威胁模型进行不止一次的评审。我们都知道，威胁模型中 有大量的集中问题需要关注，而且确实非常重要。
在安全推进活动中对于威胁模型进行评审的一些要点：
・判断数据流图数据流图自上次评审之后是否需要变更。在设计阶段与验证阶段所发 生的软件设计变更应当被反映在数据流图中，而且应作为一个整体来对待。
・确保所有数据流图元素都已映射到相应的STRIDE威胁类别中。
・检查系统中的所有输入点。确保该清单是完整的，且自上次评审之后没有发生变更。
・检查所有针对系统的匿名网络级接口访问。是否具备认证机制，限制在本地子网或 可信IP地址范围之内？
・确保所有存储的敏感数据都被正确无误地保护。通常情况下此类保护机制应包括对 访问控制列表的评审。
・确保所有承载安全敏感数据的数据流都被保护。此类保护机制应防止泄露（加密） 以及恶意篡改检测（消息认证码或者数字签名）。
安全测试
安全推进测试确实具备明显不同的关注点。你仍然可以使用之前章节所讨论到的测试技巧，但推进活动中的测试关注的仅仅是那些最高风险的功能组件。最后做一次验证以确保 你拥有一份可被代码解析的文件格式清单，并对其进行恰当的模糊测试无疑是好的。
受攻击面Scrub
以下简单的清单将有助于你推动受攻击面Scrub：
· 统计所有开放的端口、socket、SOAP接口、远程过程调用（RPC）端点以及管道。 以上是否默认都需要？
· 验证所有未经认证的网络输入点是十分必要的。以上默认是否都经过验证？
· 验证所有网络接入点是否限制在正确的子网或可信源地址集合中。
· 验证运行的每一进程是否利用了合适的权限来完成指定任务。你是否能够清除一些 保护客户的权限？
· 验证创建的每一个对象的访问控制列表是否正确无误。如果你继承了 Windows中的 操作系统访问控制列表，你的代码可能是正确的，因为操作系统的访问控制列表可 能是正确的。
· 如果你使用数据报协议，你的代码是否默认侦听数据报协议？你是否默认采用流协 议，是否允许用户选择仅在必要时使用数据报支持并理解相应风险？
第9阶段：最终安全评审
产品团队协调
这一部分并非纯技术性的活动，而是一个纯粹的过程活动，该过程的执行好坏将直接 影响到最终安全评审是否能够顺利进行。首先，该团队必须填写一个调査问卷。以下问题 的很多答案事实上在最终安全评审进行之前就应已经获得：
・该产品是独立运行或者是一个服务/管理/特性/附加包？
・产品是否与网络有任何关联部分？
・安全推进活动什么时候进行，持续多久？
・受攻击面分析文档放在哪里？
•威胁模型又存放在何处？
•源代码存放在哪里？
• bug bar记录存在哪里？
・对未修复安全bug进行数据库查询的清单存储在哪里？
・安全团队上次是否对威胁模型进行过评审？如果是，谁评审的，评审了什么以及为 什么评审？
-是否有任何你所了解到的SDL需求与软件本身不兼容？如果是，是哪些以及为什么？
•你是否运行过所有分析工具，上一次运行这些工具是在什么时候？
.这一清单并不详尽，但正如你看到的那样，目的就是为了帮助评审人员开展后续的最 终安全评审活动。
威胁模型评审
“第4阶段：风险分析”中详细讲述的威胁模型是构建安全系统的基础，而理 论模型反映实际状况这一点是不可避免的。在最终安全评审期间，威胁模型被再次评审以 验证其是否准确，是否处于最新状态并是否采取了相应的消减措施。
未修复的安全bug评审
如果开发人员在编写代码的时候出错，文档作者在撰写文档时出错，测试人员也在测 试软件时出错，是否意味着人们在向bug追踪数据库中录入bug信息时也会出现错误？最 终安全评审的这一部分旨在验证那些标记为"暂不修复”的安全bug是否可真正对其不予 理睬。所有超过产品既定水平的安全bug在发布前都必须得以修复，因此bug的严重性或 关键程度是准确的就至关重要。我们已经发现人们总会时不时地误将缺陷的严重性归咎于 简单的人为错误。
工具有效性验证
对于最终安全评审团队来说，验证软件开发期间所使用到的所有相关工具是相当重要 的。所需工具以及版本清单在第21章，“SDL必备工具以及编译器选项”。相应的安全测 试工具，例如文件和网络模糊测试器等，都必须被评审且通过验证以确保都能正常运行。
当然，有很多种验证的方式：第一就是査看生成文件(makefiles)以及编定脚本(build scripts),并且验证是否已经在其中设置了相应的标记。例如，在微软Visual C++工具中， 我们可通过编译命令行有无/GS参数确保这一点。我们也可以检查MIDL编译器是否使用 了诸如/ROBUST之类的参数。
在最终安全评审完成之后
在你决定是否容忍某一异常时，决策过程中由初级管理人员直接决策这一现象很少见。 当然，任何事情都有正反两面，高层管理人员的介入也会各有利弊。但无论如何，你都有 必要收集所有相应的背景信息以辅助管理者做出正确的决策，包括：
•该问题应该如何解决？
・该问题为什么现在会被发现？ 一旦该问题曾经被修复过，是否此时就无法发现呢？
・可能的解决方法是什么，如果有，为什么不加以修复？
・你该对客户如何解释这一问题？不要单纯依赖于客户能够阅读安全指南文档。
・如果就此问题已经开过会议但仍没有解决该问题，甚至变得比预料中更糟糕，一旦 攻击发生时处理计划是什么？
・如果当前产品版本中没有解决该问题，那么修复该问题的计划是什么？
・客户能够在什么时间获得一个已解决该问题的更新版本？
・有无其他使该问题影响重要性降低的处理措施呢？
