CISP软件安全开发课件.ppt

1、软件安全开发软件安全开发课程内容课程内容2软件安全开发软件安全开发知识体知识域软件安全软件安全开发概况开发概况软件安全需求和设计软件安全需求和设计软件安全编码软件安全编码软件安全测试软件安全测试软件安全开发软件安全开发的关键工作的关键工作软件安全开发的必要性软件安全开发的必要性软件安全开发背景软件安全开发背景知识子域软件安全开发模型及研究软件安全开发模型及研究知识域：软件安全开发概况知识域：软件安全开发概况v知识子域：软件安全开发背景 了解软件的发展和产生的安全问题 了解软件安全问题产生的原因3软件安全的基本概念软件安全的基本概念v软件的定义 计算机程序、方法、规则和相关的文档资料以及在计算机

2、上运行时所需的数据（IEEE）v软件安全 采用系统化、规范化、数量化的方法来指导构建安全的软件v软件安全基本概念 使安全成为软件开发的必须部分 软件安全工程化三个支柱：风险管理、软件安全切入点、安全知识4软件安全问题广泛存在软件安全问题广泛存在v软件应用广泛 电脑游戏、火车票售票系统、多媒体教学 手机、航天飞机、人造卫星 v软件安全问题广泛存在 运行错误 售票系统反应慢、连不上、崩溃 多媒体教学系统死机 黑客盗取泄漏的银行密码 v安全问题日益增加56软件安全问题产生后果软件安全问题产生后果v软件安全问题的后果 造成产品运行不稳定，得不到正确结果甚至崩溃可靠性、可用性 被恶意攻击，导致信息泄漏/

3、数据破坏等后果保密性、完整性v一些因软件安全问题导致的严重后果 售票系统瘫痪 美国放射治疗仪超剂量辐射事件 阿丽亚纳5号火箭首发失败事件 Stuxnet病毒攻击伊朗布什尔核电站6软件产生安全问题的原因软件产生安全问题的原因v内因 软件开发安全意识淡薄 软件开发缺乏安全知识 软件趋向大型化和复杂化 软件第三方扩展增多v外因 软件使用场景更具威胁7软件越来越复杂软件越来越复杂8 eg.Windows 系列软件源代码行数系列软件源代码行数9漏洞与软件安全漏洞与软件安全v漏洞普遍存在 平均每1000行程序存在20个缺陷 (Dacey 2003) 采用严格的软件开发质量管理机制和多重测试环节，软件公司的

4、缺陷率（ 千行代码）：普通软件开发公司的缺陷密度为440个缺陷高水平的软件公司的缺陷密度为24个缺陷美国NASA的软件缺陷密度可达到0.1个缺陷v漏洞已经成为危害软件安全的主要因素 危及用户对软件的信任、业务运营，还会危及一系列关键基础设施和应用9传统的软件开发局限性传统的软件开发局限性传统软件开发教育的局限性传统开发人员能力的局限性传统软件生命周期的局限性 软件教育包括软件工程、数据结构、编译原理、系统结构、程序语言等 缺乏安全开发教育 对安全问题没有的足够理解 不了解安全设计的基本原理 不知道安全漏洞的常见类型 不知道如何设计针对安全的测试数据 软件生命周期包括需求分析、架构设计、代码编写

5、、测试和运行维护五个阶段 缺乏安全介入的阶段10 需要安全的软件开发！需要安全的软件开发！需要安全的软件需要安全的软件v理想的安全软件 不存在安全漏洞 能抵御各种攻击威胁 按照预期的方式执行：do what is intendeddo what is intendedv软件安全保障的思路 通过在软件开发生命周期各阶段采取必要的、相适应的安全措施来避免绝大多数的安全漏洞。 采取措施只能有效减少，但并不能完全杜绝所有的安全漏洞。1112软件安全保障软件安全保障v软件可以规避安全漏洞而按照预期的方式执行其功能v目标：在软件开发生命周期中提升软件的安全性 可信赖性：无论是恶意而为还是无意疏忽，软件都没

6、有可利用的漏洞存在 可预见性：对软件执行时其功能符合开发者的意图的信心。 遵循性：将（软件开发）跨学科的活动计划并系统化，以确保软件过程和软件产品满足需求、遵循相关标准。12软件安全保障与风险管理软件安全保障与风险管理v在软件安全保障中，需要贯彻风险管理的思想 “安全就是风险管理”v软件安全是以风险管理为基础 安全不必是完美无缺的，但风险必须是能够管理的v最适宜的软件安全策略就是最优的风险管理对策 这是一个在有限资源前提下的最优选择问题 防范不足会造成直接的损失；防范过多又会造成间接的损失1314软件安全开发生命周期软件安全开发生命周期v软件安全开发 采取措施防止由于设计、开发、提交、升级或维

7、护中的缺陷而导致的系统脆弱性 20世纪末/21世纪初开始展开研究v 安全软件开发生命周期 思想：安全软件开发涵盖了软件开发整个生命周期 通过软件开发的各个步骤来确保软件的安全性，其目标是确保安全的软件得以成功15安全软件开发生命周期安全软件开发生命周期v思想：将安全融入 在设计/开发/测试等过程中融入安全 在传统的过程中增加安全过程v思想：安全提前介入 NIST：在软件发布以后进行修复的代价是在软件设计和编码阶段即进行修复所花代价的30倍 软件系统发布以后才进行漏洞修复代价是最高的，且常常伴随着软件系统使用者的极大损失v思想：软件安全开发标准化和规范化 规范指南 最佳实践1516降低解决软件安

8、全问题的代价降低解决软件安全问题的代价v早期发现并改正错误有以下优点 在软件开发生命周期中，后面的阶段改正错误开销比前面的阶段要高出数倍 早期发现并改正错误可以减少时间和开销16知识域：软件安全开发概况知识域：软件安全开发概况v知识子域：软件安全开发模型及研究 了解安全开发生命周期（SDL）的发展历程，理解SDL的主要内容 了解使安全成为软件开发必须的部分（BSI）系列模型 了解综合的轻量级应用安全过程（CLASP）的主要内容 了解软件保障成熟度模型（SAMM）的框架 了解各个模型的特点及适用性17可信计算安全开发生命周期可信计算安全开发生命周期v微软，2002.1，盖茨v 安全开发生命周期S

9、DL（The Trustworthy Computing Security Development Lifecycle） 自 2004 起，SDL 作为全公司的计划和强制政策，在将安全和隐私植入软件和企业文化方面发挥了重要作用。 通过将整体和实践方法相结合，SDL 致力于减少软件中漏洞的数量和严重性。SDL 在开发过程的所有阶段中均引入了安全和隐私。18SDLSDL发展历史发展历史v2002.1今 20 世纪 90 年代中期到后期 (Melissa) 和 21 世纪初期（Code Red、Nimda、UPnP 等）出现了一系列影响重大的恶意软件事件，促使微软重新考虑开发人员安全过程和策略192

10、0SDLSDL的阶段和安全活动的阶段和安全活动v软件安全开发生命阶段 5+2=7个阶段 16项必需的安全活动20SDL每个阶段用到的工具每个阶段用到的工具2122IE采用采用SDL后的效果后的效果22Source: Browser Vulnerability Analysis, Microsoft Security Blog 27-NOV-2007采用采用SDL之前之前采用采用SDL之后之后漏洞总数降低了35%高危漏洞数降低了63%正式发布后12个月内修复的漏洞总数BSIBSI系列模型系列模型vBSI使安全成为软件开发必须的部分 Building Security IN，BSI Gray Mc

11、Graw，Cigital公司v在整个软件开发生命周期中要确保将安全作为软件的一个有机组成部分。 无须改变你的软件开发方法 适用各种软件开发生命周期v合作 NIST 美国国土安全部 大学（加州大学戴维斯分校、普林斯顿、莱斯）2324软件安全的三根支柱软件安全的三根支柱v三根支柱 应用风险管理（战略） 软件安全接触点（战术） 知识2425接触点模型接触点模型v接触点，即在软件开发生命周期中保障软件安全 一套最优方法、一种战术性方法 在每一个开发阶段上尽可能地避免和消除漏洞 “黑帽子”和“白帽子”2526BSIMMBSIMMvBSI成熟度模型 Building Security In Maturit

12、y Mode Gary McGraw、Brian Chess和Sammy Migues 使用SSF对所有项目进行描述 了解别人的安全项目过程，指导自己的安全项目v目标 是对真实的软件安全项目所开展的活动进行量化 构建和不断发展软件安全行动的指南vBSIMM 3.0 2011年 42个公司（Microsoft、Intel、Google、)2627BSIMMBSIMM结果图结果图2728SSFSSFvSSF（Software Security Framework） 软件安全框架28SAMMSAMMvOWASP SAMM Software Assurance Maturity Mode 软件保证成熟

13、度模型 OWASP（开放Web应用安全项目）v一个开放的框架，用以帮助制定并实施针对软件安全特定风险的策略 评估一个组织已有的软件安全实践； 建立一个迭代的权衡的软件安全保证计划； 证明安全保证计划带来的实质性改善； 定义并衡量组织中与安全相关的措施。 2930SAMMSAMMv规定了四个软件开发过程中的核心业务功能 治理：组织管理其软件开发的过程和活动 构造：组织在开发项目中确定目标并开发软件的过程与活动 验证：组织测试和验证软件的过程与活动 部署：组织软件发布的相关管理过程与活动v4个成熟度级别 0-3级3031OWASP SAMMOWASP SAMM3132CLASPCLASPv综合的轻

14、量应用安全过程综合的轻量应用安全过程（Comprehensive, Lightweight Application Security Process (CLASP) ）v选取了30个特定的基于角色的活动(activities)，用于提升整个开发团队的安全意识，并针对这些活动给出了相应的指南、导则和检查列表3233CLASPCLASP介绍介绍v 基于角色 项目经理 、需求分析师 、软件架构师 、设计者 、实施人员 、集成和编译人员 、测试者和测试分析师 、安全审计员v对于每个活动，CLASP描述了以下内容 安全活动应该在什么时间、应该如何实施 如果不进行这项安全活动，将会带来的多大的风险 如果实

15、施这项安全活动，估计需要多少成本3334各模型比较各模型比较34SDL文档丰富，维文档丰富，维护更新及时护更新及时较多工具支持较多工具支持适合大型企业适合大型企业BSI接触点强调开发安全强调开发安全重点重点注重实用方法注重实用方法上手容易上手容易BSIMM最佳实践参考最佳实践参考他山之玉他山之玉不强制实践不强制实践CLASP 轻量级过程；轻量级过程；以角色及其职以角色及其职责为核心责为核心适合小型企业适合小型企业SAMM开放框架开放框架安全知识要求安全知识要求较低较低和和BSIMMBSIMM的安全的安全活动能对应活动能对应35知识域：软件安全开发关键工作知识域：软件安全开发关键工作v知识子域：

16、软件安全需求和设计 了解软件安全需求分析和安全设计的重要性 理解软件安全设计基本原则 理解影响系统安全性的6类威胁，以及威胁建模过程35软件安全需求及安全设计的重要性软件安全需求及安全设计的重要性v安全编码？安全测试？ 传统方法：软件发布后测试、等待修复Bug Gary McGraw ：50%的安全问题由设计瑕疵引起 安全提前介入，效益高，成本低36v设计缺陷举例 Microsoft Bob 明文存储口令，甚至将口令拿到客户端对比验证37软件安全需求及安全设计的重要性软件安全需求及安全设计的重要性v软件安全需求和设计是开发安全软件的基础v软件安全需求分析 以风险管理为基础，建立“威胁”分析计划

17、 建立软件安全需求定义，确保软件安全需求定义正确 安全需求应文档化v软件安全设计 软件系统的每一项需求，都应该在软件安全设计阶段认真考虑37安全设计原则安全设计原则v最小特权v权限分离v最小共享v完全中立v心理可接受v默认故障处理v经济机制v不信任v纵深防御v保护最薄弱的环节v公开设计v隐私保护v攻击面最小化39受攻击面概念受攻击面概念v 什么是受攻击面 对一个软件系统可以采取的攻击方法集合，软件的功能、API、接口、资源、数据存储等都是受攻击面v 为什么要降低受攻击面 一个软件的攻击面越大安全风险就越大3940降低受攻击面的方法降低受攻击面的方法v第一步：分析产品功能v第二步：分析访问功能v

18、第三步：采取合理措施降低特权40受攻击面增加远程访问受限访问本地访问仅管理员访问用户访问匿名访问41降低软件受攻击面策略降低软件受攻击面策略v重要等级为低的功能：攻击面大，取消该功能v重要等级为中的功能：攻击面大，设置为非默认开启，需要用户配置后才予以开启v重要等级为高的功能：攻击面大，关闭或限制一些接口方式，增加一些安全的保证措施或技术41降低受攻击面对于提高软件源代码安全性至关重要！减少软件受攻击面减少软件受攻击面42威胁建模威胁建模v什么是威胁建模 威胁建模是了解系统面临的安全威胁，确定威胁风险并通过适当的缓解措施以降低风险，提高系统安全性的过程。v为什么要威胁建模 帮助在设计阶段充分了

19、解各种安全威胁，并指导选择适当的应对措施 对可能的风险进行管理 可以重新验证其架构和设计 有助于软件的受攻击面降低43威胁建模流程威胁建模流程v确定对象v识别威胁v评估威胁v消减威胁44威胁降低威胁漏洞攻击者威胁建模流程威胁建模流程确定对象确定对象 应用的可信任边界之内的所有功能组件 边界之外的应用最实际部分识别威胁识别威胁 发现组件或进程存在的威胁 威胁不等于漏洞评估威胁评估威胁 判断攻击发生概率 攻击后果 计算风险消减威胁消减威胁 重新设计并排除这个威胁 使用标准的威胁消减技术 发明新的消减方法 根据安全Bug标准来确定是否可接受风险 把威胁作为漏洞记录下来，以后再想办法消减4546STR

20、IDE建模方法建模方法vSTRIDE建模 微软SDL中提出 发现或纠正设计级（design-level)的安全问题46理解理解STRIDE威胁威胁4747消减威胁举例消减威胁举例48v消减威胁知识域：软件安全开发关键工作知识域：软件安全开发关键工作v知识子域：软件安全编码 理解通用安全编码准则：验证输入、避免缓冲区溢出、程序内部安全、安全调用组件、禁止使用不安全函数等 理解使用安全编译技术对提高编码安全水平的作用，了解常用安全编译技术 理解源代码审核的目的及方式，了解常见源代码静态审核工具49通用安全编码准则通用安全编码准则v验证输入v避免缓冲区溢出v程序内部安全v安全调用组件v禁止使用不安全

21、函数50验证输入验证输入v安全程序第一道防线是检查每一个不可信的输入 DirectXMIDI 库，难以检查所有的输入，可能导致IE被恶意利用v检查、验证或者过滤输入 不让恶意数据进入程序后续处理 类似网络中部署防火墙v何处检查 最初接收数据时 （第一次）使用数据时5152验证输入验证输入常见输入源常见输入源v命令行 参数数量、数据格式、内容v环境变量 环境变量可能超出期望 有的环境变量存储格式存在危险v文件 不信任可以被不可信用户控制的文件内容 不信任临时文件v网络 来自网络的数据是“高度不可信的”v其他来源5253验证输入验证输入常见数据类型常见数据类型v字符串 确定合法范围，拒绝非法字符（

22、串） 0（NIL） 行结束编码0 x0a（unix）0 x0d 0 x0a (dos, windows)0 x0d (APPLE MacOS)0 x85 (IBM OS/390) 特定字符系统字符分割字符53验证输入验证输入常见数据类型常见数据类型v数字 数字检查（正则表达式/ASCII值） 负数检查（大数溢出为负数）Sendamil 攻击 合法范围检查v文件名 最好不让用户设置文件名 避免特殊字符. / - -rf ./ com154验证输入验证输入常见数据类型常见数据类型v电子邮件地址 限制合法的电子邮件地址vUTF-8 变长编码vURI/URL 非法地址 在合法地址后面增加恶意内容55避

23、免缓冲区溢出避免缓冲区溢出v缓冲区溢出 缓冲区：包含相同数据类型的实例的一个连续计算机内存块 溢出：数据被添加到分配给该缓冲区的内存块之外v外部数据比目标空间大v是一个非常普遍而且严重的问题56避免缓冲区溢出避免缓冲区溢出v溢出后果 攻击者可以使远程服务程序或者本地程序崩溃 攻击者可以设计溢出后执行的代码vC/C+语言 语言特性决定 大量的库函数存在溢出strcpy、strcat、gets等v其他语言 调用C语言库 C#允许设置“不安全”例程57避免缓冲区溢出避免缓冲区溢出解决办法解决办法v解决办法 编码避免缓冲区溢出填充数据时计算边界、动态分配内存、控制输入 使用替代的安全函数或函数库使用没

24、有缓冲区溢出问题的函数：strncpy、strncat、C+中std:string使用替代库：Libmib、libsafe 使用更新更安全的编译环境，打开具有安全防御机制的安全编译选项StackGuard、ProPolice、/GS 非执行的堆栈防御不可在堆栈上执行代码5859程序内部安全程序内部安全v程序内部接口安全程序内部接口数据的检查assertv异常安全处理检测异常，安全处理各种可能运行路径检测到某些错误行为/数据，必须以合适的方式处理，保证程序运行安全必要时立即拒绝服务，甚至不回送详细的错误代码59程序内部安全程序内部安全v最小化反馈 避免给予不可靠用户过多的信息成功或失败作为跟踪检

25、查的日志可以记录较为详细的信息 认证程序在认证前尽量少给信息（版本） 如果程序接受了密码，不要返回它v避免拒绝服务攻击 输入错误尽快返回 设置超时 延时服务60程序内部安全程序内部安全v避免竞争条件 访问共享资源时（文件/变量）没有被适当地控制 使用原子操作 使用锁操作避免死锁v安全使用临时文件 很多安全漏洞发生在访问已知文件名或可猜测的临时文件时6162安全调用其他组件安全调用其他组件v应用程序实际上几乎都不会是自包含的，它们通常都会调用其他组件 底层的操作系统 数据库 可重用的库 网络服务（WEB、DNS）62安全调用其他组件安全调用其他组件v组件安全 检查组件文档，搜索相关说明gets随

26、机数 使用经过认可的组件 尽可能不调用外部命令，如果不得已要调用，必须严格检查参数system、open、exec、63安全调用其他组件安全调用其他组件v返回值安全 一定要检查返回值，调用是否成功 成功时检查返回值，是否按照期望值处理数据中可能含有 NUL 字符、无效字符或其他可能产生问题的东西 错误时检查错误码v传递数据安全 视安全需求和安全环境考虑传输加密，包括密码算法和安全协议6465禁止使用不安全函数禁止使用不安全函数v编码中禁止使用的危险函数举例6566安全编译安全编译v使用最新版本编译器与支持工具v使用编译器内置防御特性 gcc -Wall -Wpointer-arith -Wst

27、rict-prototypes -O2 6667源代码审核源代码审核v源代码审核就是检查源代码，检测并报告源代码中的可能导致安全弱点的薄弱之处。v人工审核 费时费力 容易遗漏v工具审核 速度快，自动 可升级知识库67 源代码审核源代码审核关注编码中的实现缺陷，通常通关注编码中的实现缺陷，通常通过静态分析工具进行，它们扫描源代码，能够过静态分析工具进行，它们扫描源代码，能够发现大约发现大约50%50%的安全问题的安全问题。68代码审核工具代码审核工具v商业工具 Coverity Fortify Ounce Labs SecureSoftwarev免费/开源工具 BOON Cqual Xg+ Fi

28、ndBugs68“好好”的源代码分析工具的源代码分析工具v安全性 安全审核，不要以功能为主v多层性 软件的多层架构、多层平台、多种语言v可扩展性 扩展规则、扩展技术v知识性 主用于分析，开发者也能“学到” 安全编程知识v集成性 支持与IDE集成，支持make、ant等工具69为什么要软件安全测试？为什么要软件安全测试？v软件测试 按照特定规程，发现软件错误的过程。 检查软件是否满足规定的要求，或是清楚地了解预期结果与实际结果之间的差异 其目的在于发现软件中的错误v软件安全测试 有关验证软件安全等级和识别潜在安全缺陷的过程 查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力

29、 传统测试仅考虑软件出错时的处理，没有考虑对软件的故意攻击7071安全测试安全测试v在应用投产前，应由独立的安全团队对应用的安全性进行综合评估 功能性安全测试 对抗性安全测试v传统测试方法 白盒测试 黑盒测试 灰盒测试v特定的安全测试手段 模糊测试 渗透测试7172模糊测试模糊测试v模糊测试（Fuzz测试） Baron Miller、Lars Fredriksen、Bryan So首次提出 是一种通过提供非预期的输入并监视异常结果来发现软件故障的方法v模糊测试可以基于黑盒、灰盒、白盒而实现。 不关心被测试目标的内部实现 设计输入，检测结果，发现安全漏洞v微软SDL包含了Fuzz测试72 非常有

30、效的漏洞挖掘技术，已知漏洞大部分都是通过这种技术发现的。 FuzzFuzz测试测试v强制软件程序使用恶意/破坏性的数据并进行观察结果的一种测试方法 不够强壮的程序会崩溃 编码良好的程序正常运行v特性 方法学 基于应用场景涉及的随机值 大量测试用例 查找漏洞或可靠性错误73FuzzFuzz测试步骤测试步骤 生成大量的畸形数据作为测试用例 将这些测试用例作为输入应用于被测对象 监测和记录由输入导致的任何崩溃或异常现象 查看测试日志，深入分析产生崩溃或异常的原因74影响模糊测试效果的关键因素影响模糊测试效果的关键因素v测试点 数据通道入口、可信边界点v样本选择 选择覆盖面广、便于测试的多个样本v数据

31、关联性 智能模糊测试v自动化框架v异常监控与异常恢复v分析评估75渗透测试渗透测试v渗透测试 通过模拟恶意黑客的攻击方法，来评估系统安全的一种评估方法 从攻击的角度测试软件系统是否安全 使用自动化工具或者人工的方法模拟黑客的输入，找出运行时刻目标系统所存在的安全漏洞v优点 找出来的问题都是真实的，也是较为严重的v缺点 只能到达有限的测试点，覆盖率较低76渗透测试流程渗透测试流程77渗透测试要点渗透测试要点v测试目的 是进行安全性的评估，不是摧毁或破坏v测试人员 技术、知识和经验很重要 像“坏人”一样思考问题v安全问题 系统备份和恢复措施 测试风险控制7879灵活安排自己的灵活安排自己的“组合组合”v代码审核 + 体系结构风险评估v基于风险的安全测试 + 渗透测试v安全需求分析 + 滥用案例开发v代码审核 + 渗透测试v体系结构风险分析 + 基于风险的测试v79 必须完整的遵循“安全开发”过程吗？ 谢谢，请提问题！谢谢，请提问题！