《软件安全开发》读后笔记 第3章 软件安全设计

非常平淡

软件设计是从软件需求到软件实现必不可少的活动，它把各种软件需求转换为可以直接实现的软件结构。
软件安全设计方法是一套在软件生产过程中关注软件安全性的卓有成效的开发步骤和流程。
3.1 软件设计与安全设计

3.1.1 软件设计的主要工作

       软件设计过程考虑的主要内容包括架构设计、接口设计、构件设计和部署设计。     
       从工程管理的角度，软件设计可以分为概要设计和详细设计。概要设计是根据需求确定软件和数据的总体框架，详细设计是将其进一步精化成软件的算法表示和数据结构。
       从生命周期的角度，软件设计可以看作是从软件需求规格说明书出发，根据需求分析阶段确定的功能，设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法等内容，形成软件的具体设计方案，即从整体到局部，从概要设计到详细设计的过程。
       在设计活动完成后，应该形成设计规格说明。然后，对设计过程和设计规格说明进行评审。
3.1.2 软件安全设计原则

1．最小特权原则
     最小特权原则是指应限定系统或网络中每个主体所必须拥有的最小特权，确保系统故障、错误、网络部件篡改等原因造成的损失最小。
     仅将所需权限的最小集授权给需要访问资源的主体，并且该权限的持续时间也应该尽可能短。
2．职责分离原则
     职责分离原则是指分配不同的任务给不同职位的人，或者在多个人之间对某个特定的安全操作过程分配相关的特权。
3．默认安全原则
     默认安全是指需要为系统的安全措施提供默认的配置，包括默认账号、默认权限、默认策略。默认安全原则也是保持系统简单化的重要方式。
4．心理可接受原则
  心理接受能力被定义为：对资源的访问不应该因为安全机制的出现而变得更加困难。
5．隐私保护原则
隐私和安全是构建可信应用的两个关键因素。隐私，即用户能控制个人信息的使用、收集和发布；安全是采用保护措施，防止恶意行为或影响，保护个人信息的保密性、完整性和可用性。
       隐私保护需要告诉用户所收集的个人数据将如何使用，确保用户数据安全存储，并且只按照声明的用途使用。当数据将用于声明外的其他用途时，告知用户，并让用户选择，确保用户数据的使用符合相关法律的要求。（Tips：《数据安全法》、《个人信息保护法》）
6．保护最薄弱环节原则
    安全是一个链条，其安全性由最弱的环节决定，软件安全由最弱的组件决定，攻击者常常试图攻击系统中看起来最薄弱的部分。
7．故障保护原则
       任何复杂系统都难免出现各类故障，可以设法避免由故障带来的安全问题。当系统出现各种形式的故障时，基本上都是由不安全行为造成的。
8．纵深防御原则
       纵深防御原则不仅依靠安全机制和安全服务的组合，而且还建立协议层次、信息流向等纵向结构层次的多种有效防御措施，防范各类攻击。它的基本思想是：使用多重防御策略来抵御风险，当一层防御不够时，另一层防御将会阻止进一步的破坏。
3.1.3 减少软件受攻击面

       软件受攻击面指的是用户以及潜在的攻击者都能够访问到的所有功能和代码的总和，它是一个混合体，不仅包括代码、接口、服务，也包括对所有用户提供服务的协议，尤其是那些未被验证的或远程用户都可以访问到的协议。
      减少攻击面（Reduce Your Attack Surface）就是去除、禁止一切不需要使用的模块、协议和服务，其目的是减少攻击可以利用的漏洞，一般可以采取以下步骤。首先，分析产品功能的重要性，即某些模块、协议等是否有必要保留；其次，分析从哪里可以访问这些功能，从而了解到需要对什么进行控制；最后，采取合理措施来降低受攻击面。
       设计时一般采取以下策略：重要等级为低的功能攻击面大，取消该功能；重要等级为中的功能攻击面大，设置为非默认开启，需要用户配置后才予以开启；重要等级为高的功能攻击面大，关闭或限制一些接口方式，增加一些安全的保证措施或技术。
3.2 软件安全设计方法

3.2.1 基于模式的软件安全设计

1．软件设计模式
   设计模式是对软件设计中普遍存在、反复出现的各种问题，根据多次处理的经验，提出的一套能够快速、准确响应此类问题的解决方案。设计模式描述在各种不同情况下，应如何解决共性问题。
根据要解决的问题，设计模式可以分为创建型模式、结构型模式和行为型模式。
      创建型模式解决在不指定对象具体类型的情况下创建对象的问题，可以分为抽象工厂模式、工厂方法模式、生成器模式、单例模式、多例模式等；
      结构型模式是按照事物的结构特点进行设计，可以分为适配器模式、桥接模式、外观模式等；
行为型模式是按照人们的行为进行设计，可以分为命令模式、策略模式、模板方法模式、访问者模式等。
2．安全设计模式
      在《使用模式的安全工程》（《Security Engineering with Patterns》）一文中将软件安全模式定义为：描述一个在特定环境中重复出现的特定安全问题，并为之提供一个良好的通用解决方案。
      在《确保应用程序安全性的架构模式》一文中，提出单一访问点、检查点、角色、会议、错误全览及限制视野等安全模式。
（1）单一访问点模式。用于阻止外部实体直接与系统组件交互，所有外部访问都需要通过可被监控的统一通道。
（2）检查点模式。指定一个专门组件检查与软件内组件的交互活动。
（3）会议模式。许多软件的全局信息需要在不同地方使用，特别是在分布式、多用户或多线程环境下，软件中安全相关代码需要当前用户的信息。
      企业级安全和风险管理模式表述了企业级安全问题。该模式的实施步骤是：首先，需要对企业资产进行识别，评估资产价值，分析可能面临的威胁及企业系统可能存在的漏洞；然后，确定企业面临的风险；最后，制定出企业需要的安全保护措施与安全服务。
       按照《安全设计模式》中总结的安全模式，从软件开发的角度，现在常用的安全模式可以分为架构级模式、设计级模式和实施级模式。
（1）架构级模式
该模式可以分为不信任分解、特权分离和推迟到内核（Defer to Kernel）三种类型。
（2）设计级模式
设计级模式可以分为安全工厂模式（Secure Factory）、安全策略工厂模式（Secure Strategy Factory）、安全构建器工厂模式（Secure Builder Factory）、责任安全链模式（Secure Chain of Responsibility）、安全状态机器模式（Secure State Machine）和安全访问者模式（Secure Visitor）等。
（3）实施级模式
实施级模式主要有安全日志（Secure Logger）、清除敏感信息（Clear Sensitive Information）、安全目录（Secure Directory）、路径名规范化（Pathname Canonicalization）、输入验证（Input Validation）、资源获取初始化（Resource Acquisition Is Initialization, RAII）等模式。
3.2.2 安全设计方法实践

SDL的安全设计方法、七个接触点中的安全设计方法、IBM的安全设计方法。详细内容参见第一章内容
3.3 软件架构安全性设计

       软件架构可以分为三类：逻辑架构、物理架构和系统架构。其中，逻辑架构描述软件系统中元件之间的关系，比如用户界面、数据库、外部系统接口等等；物理架构描述软件部件在硬件上的部署方式；系统架构说明系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等等。
3.3.1 软件架构的安全性

       目前，软件架构设计的安全性主要考虑安全威胁、安全机制、安全设计、访问控制和安全通道等方面。
安全威胁主要包括机密性威胁、可用性威胁、完整性威胁和真实性威胁。其中，机密性威胁指的是未经授权的用户获得了对一项服务或数据的访问权；可用性威胁是指可能导致服务或者数据难以获得、不能使用；完整性威胁是指在未经授权的情况下纂改数据和服务；真实性威胁是指通过伪造等方法，产生不存在的数据和服务。
安全机制是指在软件设计中确保安全的机制和方法，包括加密、身份验证、授权和审计。其中，加密是指将数据转换成攻击者不能理解的形式；身份验证用于验证客户、用户、服务器等所申明的身份；授权是给予访问资源所需的适当（最小）权限；审计指的是追踪访问内容和形式。
安全设计需要考虑以下三个问题：控制焦点、安全机制分层和简洁性。控制焦点关注对应用程序相关数据的保护，访问特定数据或资源时，通过指定可以调用的操作以及操作由谁完成来实施保护措施，限定特定用户或角色访问该应用程序。安全机制分层解决安全机制应该在哪一层实现的问题。简洁性强调设计的实现必须简洁明了。
3.3.2 软件架构安全分析方法

       软件架构安全性分析需要先进行架构建模，描述软件的安全需求或安全机制，检查架构模型是否满足安全需求，如果不满足，需要修改设计架构，如此反复，直至满足所有安全需求。
       目前，国内外关于软件架构安全性分析的理论和应用研究还处于探索阶段。软件架构安全性分析可以分为形式化和工程化两类分析方法。前者使用形式化方法描述软件架构和安全需求，最终的分析结果精确、可量化，且自动化程度高，但实用性较差；后者从攻击者的角度考虑软件面临的安全问题，实用性强，自动化程度较低。
1．形式化分析技术
形式化分析主要包括UMLsec建模描述分析法、软件架构模型法（Software Architectural Model, SAM）、离散时间马尔科夫链（Discrete Time Markov Chain, DTMC）安全可靠性模型方法和卡耐基梅隆大学提出的ACME组件系统架构描述法等。
2．工程化分析技术
     软件架构的工程化分析主要包括场景分析法、错误用例分析法和威胁建模。
（1）场景分析法
       场景分析法使用场景描述与软件架构静态结构和动态行为相关的安全属性，从用户角度建立相应的场景库和评价指标树，并采用评审会议方式分析架构安全性，是一种轻量级的分析方法。
（2）错误用例分析法
       错误用例是指用户在与软件交互过程中，对其他用户、软件本身及其他利益相关者造成损失的一系列行为。错误用例分析法通过检查软件架构对每个错误用例如何反应，来判断架构是否满足安全需求。
（3）STRIDE威胁建模法（广泛使用）
STRIDE威胁建模是由微软公司提出可用于架构设计安全性分析的方法。通过建立威胁模型分析欺骗/假冒（Spoofing）、篡改（Tampering）、否认（Repudiation）、信息泄露（Information Disclosure）、拒绝服务（Denial of Service）和特权提升（Elevation of Privilege）六类威胁（STRIDE）的风险等级。



3种工程化方法对比

欺骗/假冒（Spoofing）：假冒是指攻击者冒充一个用户，或者恶意服务器冒充合法服务器。
数据篡改：是指在未授权的情况下，永久地修改数据。
否认/抵赖：是指用户拒绝承认从事过的某项活动，并且无法证明他是在抵赖。
信息泄露：是指信息被暴露给不允许对它访问的人。
拒绝服务攻击：是指拒绝为合法用户提供请求的服务。
权限提升：是指没有权限的用户获得访问特权，可以对系统实施破坏性操作。
3.4 威胁建模

       威胁是潜在的会出现不利结果的事件，如信息泄露或拒绝服务等。威胁建模是了解系统面临的安全威胁，确定威胁的风险等级，并通过适当的缓解措施来提高系统安全性的过程。
在威胁建模过程中起主导作用的是软件设计者、开发人员和测试人员。
威胁建模的过程如下图所示，分为建模、威胁识别、威胁缓解和验证四个步骤。每个步骤都有多种实现方法，可以根据需求选择使用合适的方法。



威胁建模的过程

3.4.1 建模

       建模是对软件进行抽象，数据流图、统一UML图表、泳道图和状态图等都可用于软件建模。
       数据流图建模过程的主要步骤包括定义应用场景、收集外部依赖、定义安全假设、创建外部安全备注和绘制数据流图。定义应用场景是为了明确应用或系统的关键威胁场景，包括部署方式、配置信息、用户使用方式。收集外部依赖是收集应用或系统所依赖的外部产品、功能或服务信息。安全假设即采用来自其他功能组件所提供的安全服务假设，定义安全假设是为了对应用所依赖的系统环境做出准确的安全假设。创建安全备注是为了让与产品相关的用户或其他应用的设计者都可以利用外部安全备注，辅助理解应用的安全边界，以及在使用应用时应如何保障安全不受侵害。威胁建模时，一般为每个场景创建一个数据流图，当产品功能发生变化时，要及时更新数据流图。



数据流图的元素及其含义

3.4.2 威胁识别

1．威胁发现
STRIDE威胁识别是一种基于目标的方法，在这里考虑的是攻击者的目标。STRIDE是Spoofing（假冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）和Elevation of Privilege（权限提升）的首字母缩略词，把威胁分为上述6类，帮助建模者发现威胁。
2．建立威胁树
使用STRIDE对威胁分类后，可以使用威胁树分析程序中的威胁和漏洞。
威胁树起源于故障树，采用树形结构描述系统面临的威胁。用根节点表示系统所面临威胁的抽象描述，逐层细化威胁的细节信息，直到用叶节点表示具体攻击方式。威胁树描述了攻击者破坏各组件所经历的决策过程。
3．威胁评估
对威胁进行量化评估，评定其严重程度。可以使用DREAD方法来完成。
DREAD是Damage potential（潜在破坏性）、Reproducibility（再现性）、Exploitability（可利用性）、Affected users（受影响用户）和Discoverability（可发现性）的首字母缩写，分别从五个方面描述威胁的危害程度，每个方面危害程度的评分范围是1～10,10表示威胁造成的危害程度最大。
依据公式“风险=受攻击概率*危害程度”，可以计算出五个风险值，然后对五个风险值求平均数，平均数越大，则威胁对系统造成的风险就越大
3.4.3 缓解威胁

1．确立缓解顺序
威胁的缓解顺序在整体设计上要有条理性和层次性。
2．常用缓解方法



针对STRIDE威胁的缓解方案

3.4.4 验证

       验证是为了确保威胁模型准确反映应用程序的潜在安全问题，验证的内容包括威胁模型、列举的威胁、缓解措施和假设等。
       验证威胁是说明列举出的威胁如何进行攻击，攻击的内容及影响。如果验证威胁出现问题，说明威胁没有被正确识别，可能需要重新建模。此外，还要分析威胁列举是否全面，如与可信边界接触的元素都可能被污染，这些元素都应该考虑STRIDE威胁。
      验证缓解措施是指检验缓解措施能否有效降低威胁影响，是否正确实施，每个威胁是否都有相应缓解措施。
      验证假设是为了判断假设是否正确，只有假设合理，才能保证在假设条件下进行的操作是合理的。

唐大帅

鄙视楼下的顶帖没我快，哈哈

立聪堂助听器宿迁店

垃圾内容，路过为证。