您好,欢迎访问三七文档
当前位置:首页 > 行业资料 > 国内外标准规范 > CISP2018-软件安全开发-V4.1
软件安全开发版本:4.1讲师姓名机构名称课程内容2软件安全开发知识域知识子域软件安全开发生命周期软件安全实现软件安全测试软件安全需求及设计软件安全交付知识子域:软件安全开发生命周期软件生命周期模型了解软件生命周期的概念及瀑布模型、迭代模型、增量模型、快速原型模型、螺旋模型、净室模型等典型软件开发生命周期模型。软件危机与安全问题了解三次软件危机产生的原因、特点和解决方案;了解软件安全和软件安全保障的基本概念。软件安全生命周期模型了解SDL、CLASP、CMMI、SAMM、BSIMM等典型的软件安全开发生命周期模型。3软件生命周期模型软件的定义软件是与计算机系统操作有关的计算机程序、规程、规则,以及可能有的文件、文档及数据软件生命周期模型瀑布模型迭代模型增量模型快速原型模型螺旋模型净室模型4软件生命周期模型-瀑布模型最早出现的软件开发模型核心思想按工序将问题简化将功能的实现与设计分开不足没有对开发周期后期发现错误做出相应的规定5软件生命周期模型-迭代模型瀑布模型的小型化应用完整的工作流程降低风险增量开支的风险产品无法按期进入市场的风险加快开发进度任务清晰需求更容易随需而变6软件生命周期模型-增量模型融合了瀑布模型和迭代模型的特征本质上是迭代,每个增量发布一个可操作产品7软件生命周期模型-螺旋模型兼顾快速原型的迭代的特征以及瀑布模型的系统化与严格监控引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失构建原型是螺旋模型用以减小风险的途径8其他软件开发方法快速原型模型快速原型模型又称原型模型,它是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。净室模型净室是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术。力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。9软件安全重要性–软件危机第一次“软件危机”-20世纪60年代根源:日益庞大和复杂的程序对开发管理的要求越来越高解决:软件工程第二次“软件危机”-20世纪80年代根源:软件规模继续扩大,程序数百万行,数百人同时开发,可维护性难解决:面向对象语言-C++/java/c#第三次“软件危机”-21世纪头十年根源:软件安全解决:软件安全开发生命周期管理10软件缺陷普遍存在千行代码缺陷数量普通软件公司:4~40高管理软件公司:2~4美国NASA软件:0.1漏洞数量国家漏洞库统计数据,最近5年最高一年入库漏洞7000+国家漏洞库漏洞数量统计11软件安全问题产生-内因软件规模增大,功能越来越多,越来越复杂软件模块复用,导致安全漏洞延续软件扩展模块带来的安全问题Windows操作系统不同版本源代码数量12软件安全问题产生-外因互联网发展对软件安全的挑战开发环境和开发人员对软件安全的挑战开发者缺乏安全开发的动机•市场和业务要求将交付期和软件功能做主要因素•用户方没有提供安全方面的压力开发者缺乏相关知识•软件复杂性加大,开发者需要学习更多东西•传统软件开发不进行安全教育缺乏安全开发工具•缺乏安全开发配套管理、测试等工具13软件安全保障贯彻风险管理的思想安全不必是完美无缺的,但风险必须是可管理的树立对软件安全控制的信心,该信心是通过保障活动来获取的通过在软件开发生命周期各阶段采取必要的、相适应的安全措施来避免绝大多数的安全漏洞采取措施只能有效减少,但并不能完全杜绝所有的安全漏洞!14软件安全开发生命周期软件安全开发覆盖软件整个生命周期需求分析阶段考虑软件的安全需求在设计阶段设计符合安全准则的功能编码阶段保证开发的代码符合安全编码规范安全测试和运行维护确保安全需求、安全设计、安全编码各个环节得以正确有效的实施在软件的各个阶段引入安全措施!15软件安全问题越早解决成本越低在软件开发生命周期中,后面的阶段改正错误开销比前面的阶段要高出数倍NIST:在软件发布以后进行修复的代价是在软件设计和编码阶段即进行修复所花代价的30倍16相关模型和研究安全软件开发生命周期安全设计原则安全开发方法最佳实践安全专家经验多种模型被提出和研究可信计算安全开发生命周期(微软)CLASP(OWASP)综合的轻量应用安全过程BSI系列模型(GaryMcGraw等)SAMM(OWASP)软件保证成熟度模型17SDL什么是SDL安全开发生命周期(SecurityDevelopmentLifecycle,SDL)SDL发展18SDL的阶段和安全活动七个阶段十七项必需的安全活动19弃用不安全的函数模糊测试分析攻击面创建质量门/Bug栏核心安全培训最终安全评析执行事件响应计划培训验证实施要求发布设计响应确定安全要求确定设计要求动态分析事件响应计划使用批准的工具安全和隐私风险评估威胁建模静态分析攻击面评析发布存档正式发布软件后12个月内的漏洞对比IE:漏洞总数下降35%,高危漏洞数下降63%操作系统:漏洞总数降低45%SDL实施效果181483InternetExplorer6InternetExplorer7MediumHigh20CLASP21什么是CLSAP综合的轻量应用安全过程(Comprehensive,LightweightApplicationSecurityProcess,CLASP)用于构建安全软件的轻量级过程,由30个特定的活动(activities)和辅助资源构成的集合针对这些活动给出了相应的指南、导则和检查列表特点基于角色的安排CMMI什么是CMMI软件能力成熟度集成模型(CapabilityMaturityModelIntegration)五级过程区域22SAMM什么是SAMM软件保证成熟度模型(SoftwareAssuranceMaturityMode,SAMM)提供了一个开放的框架,用以帮助软件公司制定并实施所面临来自软件安全的特定风险的策略,23BSI系列模型BSI(BuildingSecurityIN)使安全成为软件开发必须的部分强调应该使用工程化的方法来保证软件安全软件安全的三根支柱风险管理:策略性方法接触点:一套轻量级最优工程化方法,攻击与防御综合考虑安全知识:强调对安全经验和专业技术进行收集汇总,对软件开发人员进行培训,并通过安全接触点实际运用24BSIMMBSI成熟度模型对真实的软件安全项目所开展的活动进行量化构建和不断发展软件安全行动的指南25各模型比较SDL文档丰富,维护更新及时较多工具支持适合大型企业BSI接触点强调开发安全重点注重实用方法上手容易BSIMM最佳实践参考他山之玉不强制实践CLASP轻量级过程;以角色及其职责为核心适合小型企业SAMM开放框架安全知识要求较低和BSIMM的安全活动能对应CMMI自动的、可扩展的框架集成化框架,消除了各个模型的不一致性持续改进,就可克服软件开发中困难26知识子域:软件安全需求及设计威胁建模理解威胁建模的作用及每个阶段的工作内容;掌握STRIDE模型用于进行威胁建模实践。软件安全需求分析理解软件安全需求在软件安全开发过程中的重要性;理解安全需求分析的方法和过程。软件安全设计理解软件安全设计的重要性及内容和主要活动;理解最小特权、权限分离等安全设计的重要原则;理解攻击面的概念并掌握降低攻击面的方式。27威胁建模什么是威胁建模威胁建模是了解系统面临的安全威胁,确定威胁风险并通过适当的缓解措施以降低风险,提高系统安全性的过程。为什么要威胁建模帮助在设计阶段充分了解各种安全威胁,并指导选择适当的应对措施对可能的风险进行管理可以重新验证其架构和设计有助于软件的受攻击面降低28威胁建模流程确定对象识别威胁评估威胁消减威胁威胁降低威胁漏洞攻击者29威胁建模-确定对象确定要保护和评估的目标(资产)在使用实例和应用场景中分析明确应用或系统的关键威胁场景•部署方式、配置信息、用户使用方式等典型场景•移动或小型设备物理失窃场景•Web应用匿名用户场景30威胁建模-识别威胁识别每一个可能面临的威胁理解软件可能面临的威胁是安全开发的前提威胁不等于漏洞威胁永远存在SSpoolfingIdentity假冒身份/欺骗标识TTamperingwithdata篡改数据RRepudiation抵赖IInformationDisclosure信息泄漏DDenialofService拒绝服务EElevationofPrivilege权限提升31理解STRIDE六类威胁32威胁安全属性定义举例Spoofing(哄骗)可鉴别性模仿其他人或实体伪装成microsoft.com或ntdll.dll。Tampering(篡改)完整性修改数据或代码修改硬盘、DVD或网络数据包中的DLLRepudiation(抵赖)不可抵赖性声称没有执行某个动作“我没有发送过那封电子邮件”,“我没有修改过那个文件”,“亲爱的,我确实没有访问过那个网站!”InformationDisclosure(信息泄露)机密性把信息披露给那些无权知道的人允许某人阅读Windows源代码;公布某个Web网站的用户清单。DenialofService(拒绝服务)可用性拒绝为用户提供服务使得Windows或Web网站崩溃,发送数据包并耗尽CPU时间,将数据包路由到某黑洞中。ElevationofPrivilege(权限提升)授权获得非授权访问权允许远程因特网用户执行命令,让受限用户获得管理员权限。威胁建模-评估威胁评估威胁风险值评估被利用和攻击发生的概率评估攻击后资产的受损后果,并计算风险参考风险管理、安全工程中相关内容!33威胁建模-消减威胁重新设计并排除这个威胁使用标准的威胁消减技术发明新的消减方法根据安全Bug标准来确定是否可接受风险把威胁作为漏洞记录下来,以后再想办法消减要想办法消减每个威胁!34软件安全需求及安全设计的重要性软件安全需求和设计是开发安全软件的基础软件安全需求分析以风险管理为基础,建立“威胁”分析计划建立软件安全需求定义,确保软件安全需求定义正确安全需求应文档化软件安全设计软件系统的每一项需求,都应该在软件安全设计阶段认真考虑35安全需求分析安全需求分类安全功能需求安全保障需求需求分析的要点安全需求进行有效定义不仅考虑系统功能,还要考虑系统不应该做什么功能需求、安全需求、安全目标要达到平衡36需求工程师不要仅仅从用户的角度出发考虑系统的功能,还应从攻击者的角度出发考虑系统的漏洞。需求分析过程系统调查定性分析系统的脆弱点和可能遭受的安全威胁脆弱点和安全威胁的定量分析需求的确定37建立在风险分析的基础上!安全设计的重要性安全编码?安全测试?传统方法:软件发布后测试、等待修复BugGaryMcGraw:50%的安全问题由设计瑕疵引起安全提前介入,效益高,成本低38设计缺陷——举例MicrosoftBob明文存储口令,甚至将口令拿到客户端对比验证软件安全设计安全概要设计阶段包括但不限于:安全体系结构设计、各功能块间的处理流程、与其他功能的关系、安全协议设计、安全接口设计等。安全详细设计阶段详细设计阶段作为安全功能的程序设计阶段,应当直接指导安全功能的编码工作。包括但不限于:模块设计、内部处理流程、数据结构、输入/输出项、算法、逻辑流程图等39根据安全需求方案确定的安全目标,对初步风险评估确定的控制措施的具体技术实现而进行安全设计安全设计的主要活动40详细风险评估控制措施选择安全技术实现安全设计评审安全设计原则41最小特权原则权限分离原则最少共享机制原则完全中立原则心理可接受度原则默认故障处理保护原则经济机制原则不信任原则纵深防御原则保护最薄弱环节原则公开设计原则隐私保护原则攻击面最小化原则降低攻击面作用攻击面越小,安全
本文标题:CISP2018-软件安全开发-V4.1
链接地址:https://www.777doc.com/doc-1502012 .html