1、目录2.1 安全需求概述2.2 安全需求分析方法2.3 安全设计概述2.4 安全设计方法2.5 威胁建模1本章学习目标1.了解安全需求的定义和标准；2.了解安全需求分析过程；3.了解软件安全设计的内容；4.了解什么是威胁建模；5.理解安全设计的分析方法；6.理解安全需求的原则；7.掌握安全设计的方法；8.掌握威胁建模的过程；2安全需求概述2.1安全需求的定义传统软件需求由功能需求、非功能需求和约束构成。安全需求的定义有三种：（1）将安全需求看作传统软件需求的非功能性需求部分，用于补充产品的功能描述，从安全方面描述产品特性。（2）将安全需求看作与业务功能需求同等重要的安全功能需求，是开发人员必须
2、实现的软件功能，对业务功能需求进行安全约束。（3）使用安全策略或质量需求来定义安全需求。安全需求的三个安全属性软件安全需求是为保障实现业务功能而对相关信息的机密性、完整性和可用性提出的要求。（1）机密性(Confidentiality)指保护敏感信息不被未授权用户访问。（2）完整性(Integrity)指保护数据不被更改或破坏。（3）可用性(Availability)指确保资源被授权用户的使用。安全需求的标准安全需求常用的标准有：安全开发标准ISO27034；信息技术软件安全保障规范GB/T30998-2014；功能安全基础标准IEC61508；信息技术安全性认证通用标准（CC标准）。CC标准
3、定义了安全功能需求和安全保障需求来规范安全需求。（1）安全功能需求是指安全系统应该提供的安全功能。开发者可参照CC标准第二部分安全功能要求中定义的安全审计、通信/不可抵赖、密码支持、用户数据保护、标识和鉴别和安全管理等确定需求。（2）安全保障需求是指安全可信度及为保障可信度而应采取的措施。开发者可参考CC标准第三部分安全保障要求定义的保护轮廓评估、安全目标评估、配置管理、交付和运行、脆弱性评估和保障维护等。安全保障级别安全保障级别（EVL）是CC标准定义的系统安全可信度评价方法。安全保障级别（EVL）通过安全系统在构造管理、生命周期支持和脆弱性评估等方面所采取的措施来确定系统的安全可信度，EV
4、L1至EAL7评估等级对开发系统的安全要求不断增加。安全风险值，系统的病毒感染率和平均失效时间MTTF都是除安全保障级别（EAL）外当前成熟流行的评价系统安全保障程度的指标。安全需求分析方法2.2安全需求分析过程安全需求分析的过程是一个不断发展的过程，安全需求的内容需要不断地进行修正以保持分析结果的有效性。软件安全需求的分析过程有以下步骤：（1）系统调查：了解系统所处的安全环境及其它安全信息，确定需要保护的资产，评价各个资产的相对价值。（2）分析系统的脆弱点和安全威胁：确定系统的脆弱点，针对每个脆弱点可能由此引发的安全威胁及其对资产可能造成损害的程度进行定性和定量分析。（3）确定需求：结合定性
5、分析和定量分析的结果，确定信息系统的安全需求，开发人员根据需求实施相应的安全措施。安全需求分析方法安全需求分析方法目前均是对传统需求分析方法的扩展，在传统需求分析过程中融入安全性考量。安全需求分析的常用方法有滥用案例、滥用框架和安全质量需求工程（SQUARE）等。滥用案例滥用案例是在传统的需求分析方法用例上的安全扩展，开发者通过将自己置于攻击者的状态，考虑当安全机制无效或被破坏时的后果，可更深入了解系统和防范恶意攻击。滥用案例的典型方法有误用用例和滥用用例：（1）误用用例方法是从功能性用例的文本描述中分析可能存在的安全漏洞并识别出对应的威胁，建立威胁用例和对应的安全需求用例。（2）滥用用例方法
6、用于捕获攻击者与系统之间的交互所产生的威胁，对攻击者的企图、攻击能力进行评估，针对识别出的威胁单独建立威胁用例，这些威胁用例与误用用例中的功能性用例并不产生交互。滥用案例的创建步骤（1）用UML 的方法描述参与者和用例。（2）引入主要的滥用者和滥用用例。（3）研究滥用用例和用例之间潜在的include关系。（4）引入新的用例来发现或阻止滥用用例。（5）形成详细的需求记录。滥用框架滥用框架是在传统的需求分析方法中问题框架上的安全扩展，开发者从攻击者的角度考虑系统面临的问题，采用已有的问题框架方法针对问题领域进行分析并获取安全需求。滥用框架通过滥用框架威胁图和安全需求描述图来描述系统面临的安全问题
7、。滥用框架定义“攻击者领城”表示攻击者；定义“受害者领域”表示系统遭受威胁的资产；引入“反需求”表示攻击者对系统的需求，先获取反需求，再制定相应的安全需求。滥用框架威胁图图中E1表示反需求在受害领域产生的安全威胁现象。E2表示机器领域和受害者领域之间的共享现象，机器领域通过E2对受害领域进行操作来完成软件系统的功能。实线的E3表示恶意攻击者对机器领域产生的攻击现象。虚线的E3表示反需求受到攻击者领域的需求引用，它和反需求一起描述了攻击者领域对机器领域的攻击效果。滥用框架威胁图滥用框架安全需求描述图图中E1表示在攻击情况下受保护领域所期望的现象。E2表示机器领域和受害者领域之间的共享现象，机器领
8、域通过E2对受害领域进行操作来完成软件系统的功能。实线的E3表示恶意攻击者对机器领域产生的攻击现象。虚线的E3表示反需求受到攻击者领域的需求引用，它和反需求一起描述了攻击者领域对机器领域的攻击效果。安全需求描述图SQUARE过程模型SQUARE过程模型在软件开发周期的早期植入安全概念，在系统实现后分析系统的安全性，并对系统将来的修改和更新起着重要作用。SQUARE过程分析安全需求应当在项目发生变化时重新应用。SQUARE模型需要项目投资者、需求工程师和安全专家的参与，过程相对复杂，适合在大型项目中运用。SQUARE模型的执行过程（1）统一定义：查阅IEEE和SWEBOK等安全相关资料进行统一定
9、义。（2）确认安全日标：在软件项目开始阶段确定安全目标，并在整个生命周期中持续关注。软件项目的不同用户有不同的安全目标。（3）开发方案：分析选择可更好地支持安全需求定义的方案。（4）进行风险评估：风险专家根据项目需求推荐特定的风险评估方法，进行风险分析并得出风险评估结果。（5）选择启发性方法：根据项目客户的不同类型选择适合的启发式方法。（6）制定安全需求：利用之前所选开发方案得出安全需求。（7）需求分类：对关键需求，目标和可能存在的构架约束进行区分。（8）需求排序：通过需求分类和成本效益分析进行需求排序。（9）需求复查：注意不完善的和需要独立于特定架构实现的需求。17安全设计概述2.3总体设计
10、阶段内容总体设计又称概要设计，此阶段对比分析多种系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构。总体设计阶段的主要任务有：（1）系统设计：划分出组成系统的物理元素。（2）结构设计：确定系统中程序的模块组成，实现软件安全性需求，确定模块相互间的关系。详细设计阶段内容系统的详细设计是在总体设计的基础上进一步细化，为每项任务选择适当的技术手段和处理方法。详细设计阶段的主要内容有：（1）确定模块采用的算法，写出模块的详细过程性描述。（2）确定模块使用的数据结构。（3）确定模块接口的细节。包括对系统外部的接口、用户界面，对系统内部模块的接口、模块输入数据、输出数据和局部数据等。（4）为每个模
11、块设计出测试用例。包括输入数据，期望输出等内容。安全设计原则（1）简单易懂原则：代码越复杂越难审查的透彻，越容易出错。（2）最小特权原则：对于请求存储资源的主体，只授予执行操作所需的最少访问权，而且应该保证对于该访问权只准许使用所需的最少时间。（3）权限分离原则：把软件划分为不同独立的模块，把权限分离成不同的权限许可和认证条件，把用户分离成不同的权限角色。（4）最少共享机制原则：避免多个主体共享同一个资源，因为敏感的信息可能通过相同的机制在这些主体之间共享导致被其他用户获取。安全设计原则（5）完全中立原则：每次主体对资源的请求，系统都应该实行认证和执行检查，特别是和安全相关的内容。（6）心理可
12、接受度原则：安全机制不应妨碍资源的可用性或使得资源难以获取，否则用户很可能会选择关闭这些安全机制或功能。（7）默认故障处理保护原则：当系统失效或产生故障时，必须是以安全的方式来处理系统信息，系统故障处理默认应该是安全的设置（8）不信任原则：开发者应假定系统环境是不安全的，对外部实体的所有输入都应进行检查。安全设计原则（9）纵深防御原则：用多重防御提高攻击者的攻击成本来管理风险。（10）保障最弱环节原则：攻击者一般从系统最薄弱的环节发起攻击，开发者应针对软件的薄弱点实施更强的安全保护措施。（11）公开设计原则：假定攻击者有能力获取系统足够的信息来发起攻击，而不是依赖于攻击者不可能知道来保护系统的
13、安全。（12）隐私保护原则：系统收集到的用户信息都应实施妥善和安全的保护。（13）攻击面最小化原则：软件的攻击面越大，其安全风险也就越大。安全设计方法2.4危险性分析危险性分析是对系统存在的危险类别、出现条件、事故后果等进行分析，判断系统潜在的危险性。危险性分析的步骤如下：（1）确定危险事件。将对危险事件有影响的单元确定为软件安全性关键单元，分析这些单元影响危险事件的方式和途径。（2）分析影响软件安全性关键单元的其他单元对安全的影响。（3）分析软件安全关键单元的详细设计是否符合安全性设计的要求。确定在测试计划、说明和规程中包含的需要的安全性要求。（4）确定在系统操作员、软件用户、系统诊断手册等
14、中包含安全性要求（5）确保编程人员了解安全关键单元，向程序员提供安全编程的建议。25基于模式的软件安全设计基于模式的软件安全设计通过组合以往的设计模式开发新的框架，实现设计过程的软件复用，提升设计质量。常见的软件安全设计模式有：（1）架构级模式：分为不信任分解、特权分离和推迟到内核。（2）设计级模式：分为安全工厂模式、安全策略工厂模式、安全构建器工厂模式、责任安全链模式、安全状态机器模式和安全访问者模式等。（3）实施级模式：分为安全日志、清除敏感信息、安全目录、路径名规范化、输入验证、资源获取初始化等模式。26安全关键单元的确定和设计安全关键单元是指其错误可能导致系统存在严重危险的软件单元。安
15、全关键单元的确定需要对确定的安全性关键部件进行细化和分解，再对产生的软件单元作进一步分析，从中确定安全性关键单元。安全性关键单元应遵循以下设计准则：（1）分离安全关键单元。保障非关键的单元故障不会影响关键单元。（2）安全关键单元至少受控于两个独立的单元。（3）安全关键单元必须具有强数据类型；（4）安全关键的计时单元必须由系统控制，不允许随意修改。27威胁建模2.5威胁建模概述威胁建模以结构化的方式识别和评估系统面临的威胁，使开发人员充分了解和管理可能的安全威胁，指导选择恰当的应对措施，降低安全防护成本，提高工程质量。威胁建模需要重复进行，因为：（1）安全人员很难一次找出所有威胁。（2）目前应用
16、程序大多为动态，威胁建模过程需要随着应用程序的发展不断重复，改善并适应变化的应用程序。威胁建模过程（1）识别资源：找出系统必须保护的有价值的资源。（2）创建总体体系结构：利用简单的图表来记录应用程序的体系结构。（3）分解应用程序：分解应用程序的体系结构。（4）识别威胁：根据应用程序的体系结构和潜在缺陷，找出可能影响应用程序的威胁。（5）记录威胁：利用通用威胁模板记录每种威胁。（6）评价威胁：对确定的威胁列表进行评价以区分优先顺序。威胁建模的输出威胁建模过程的输出是工作项目报告，内容包括应用程序体系结构安全方面的记录和评价过的威胁列表。该工作项目报告可使项目成员更加清楚地了解需要处理的威胁，以及
17、如何进行处理。（1）设计者利用项目报告来进行技术与功能方面的安全设计选择决策。（2）开发者利用项目报告来降低风险。（3）测试人员利用项目报告编写测试案例来测试应用程序是否容易受分析所找出的威胁的攻击。威胁的缓解技术威胁建模的评估结果将决定威胁是否需要被缓解，以及确定缓解所需要使用的技术措施。常用的缓解威胁的技术有：（1）对于假冒：使用认证技术解决，如Cookie认证、数字签名等技术。（2）对于篡改：使用数据完整性技术解决，如哈希函数、消息认证码等密码算法，或采用防篡改协议来传输。（3）对于信息泄漏：使用数据保护的技术解决，如对称加密、非对称加密等密码算法，或采用访问控制手段限制访问，或采用隐私保护协议保护隐私数据的存取等技术。THANKS!THANKS!让网络更安全让世界更美好w w w.q i a n x i n.c o m
个人主页
