27 安全工程¶
说明
本文档由 AI 生成
这一章(Chapter 27: Security Engineering)非常关键,尤其是在当今数字化时代,安全不再是附加功能,而是系统生存的基础。这份PPT从宏观角度阐述了如何将安全“设计”进系统,而不是事后补救。
这一章的逻辑非常严密:首先定义了安全工程的核心概念(资产、威胁、漏洞);接着分析了不同领域的在线安全威胁(社交媒体、移动、云、IoT);然后深入讲解了安全工程分析的具体步骤(需求获取、建模、度量);最后通过安全保证(Security Assurance)和风险分析(Risk Analysis)来构建系统的可信度(Trustworthiness)。
以下是为你整理的详细笔记(Markdown格式),专有名词后均已附上英文对照,非常适合用来复习备考。
🛡️ 软件工程 Chapter 27: 安全工程 (Security Engineering)¶
1. 为什么要进行安全工程?(Why Security Engineering?)¶
- 安全的定义 (Definition): 安全是系统完整性 (Integrity)、可用性 (Availability)、可靠性 (Reliability) 和安全性的前提。
- 资产 (Assets): 系统资源(信息、文件、程序、存储、处理器容量),对利益相关者具有价值。
- 攻击 (Attacks): 利用漏洞 (Vulnerabilities),允许未经授权的系统访问。
- 核心原则 (Core Principle): 仅仅通过响应错误报告很难让系统变得更安全。安全必须从一开始就设计进去 (Security must be designed in from the beginning)。
2. 安全需求分析 (Analyzing Security Requirements)¶
- 暴露 (Exposure): 重新创建丢失的系统资产所需的时间或成本价值。
- 威胁分析 (Threat analysis): 确定可能损坏系统资源或使其无法被未授权访问的条件或威胁的进程。
- 控制措施 (Controls): 创建控制措施以避免攻击并减轻其损害。
3. 在线安全威胁 (Online Security Threats)¶
- 社交媒体 (Social Media): 网络通常允许用户开发可访问其个人详细信息的应用程序。
- 移动应用 (Mobile Applications): 运行在移动设备上的原生应用可能拥有与设备所有者相同的资源访问权限。
- 云计算 (Cloud Computing): 带来了额外的保密性和信任问题,因为它模糊了“受信任内部 (trusted inside)”和“不受信任外部 (untrusted outside)”之间的界限。
- 物联网 (Internet of Things, IoT): 普通物体能够通信并报告有关其用户及其环境的情境信息。
4. 安全工程分析 (Security Engineering Analysis)¶
- 安全需求获取 (Security requirements elicitation):
- 确定用户如何与系统资源交互。
- 创建描述系统威胁的**用户故事 (User stories)**(注:原文如此,通常为 abuse stories/misuse cases)。
- 进行用户威胁建模和风险分析,确定作为非功能性需求一部分的系统安全策略。
- 定位**攻击模式 (Attack patterns)** 以识别系统安全缺陷的解决方案。
- 安全建模 (Security modeling):
- 捕获策略目标、外部接口需求、软件安全需求、操作规则、安全架构描述。
- 在设计、编码和审查期间提供指导。
- 状态模型 (State models): 帮助确保系统允许的状态转换序列从安全状态开始并在安全状态结束。 idot; 形式化模型 (Formal security models): 可能提高系统的可信度,因为可以使用正确性证明 (Correctness proofs) 作为系统安全案例的一部分。
- 度量设计 (Measures design):
- 安全度量应关注系统可靠性 (Dependability)、可信度 (Trustworthiness) 和生存能力 (Survivability)。
- 衡量资产价值、威胁可能性。
- 正确性检查 (Correctness checks):
- 软件验证活动和安全测试用例必须可追溯到系统安全案例 (Security cases)。
- 在审计、检查和测试用例中收集的数据被分析并总结为安全案例。
5. 安全保证与风险分析 (Security Assurance & Risk Analysis)¶
- 安全保证 (Security Assurance): 用于表明你创建了一个让最终用户和利益相关者有信心的安全产品。
- 安全声明 (Security claims)
- 论证 (Arguments): 将声明相互关联。
- 证据 (Evidence): 支持论证的审查、证明等。
- 安全风险分析 (Security Risk Analysis): 微软创建威胁模型的步骤:
- 识别资产 (Identify assets)
- 创建架构概述 (Create architecture overview)
- 应用分解 (Application decomposition)
- 识别威胁 (Identify threats)
- 文档化威胁 (Document threats)
- 评级威胁 (Rate threats)
6. 系统可信度 (System Trustworthiness)¶
- 信任 (Trust): 软件组件和利益相关者之间相互依赖的置信水平。
- 验证 (Verification): 确保使用可追溯到安全案例的客观和可量化技术来评估安全需求。
- 证据 (Evidence): 用于证明安全案例的证据必须对所有系统利益相关者来说都是可接受和有说服力的。
- 信任度量 (Trust metrics): 大多基于源自涉及信任情况下的过去行为的历史数据。
💡 复习重点总结 (Key Takeaways for Exam)¶
- 核心概念辨析 (Core Concepts): 必须清晰区分 Asset (资产)(我们要保护的东西)、Vulnerability (漏洞)(系统弱点)、Threat (威胁)(潜在的损害来源)和 Attack (攻击)(利用漏洞的具体行为)。
- 安全设计原则 (Design Principle): 重点记住“安全必须从一开始就设计进去 (Designed in from the beginning)”,而不是通过补丁 (Patching) 来实现。
- 特定领域威胁 (Domain-specific Threats): 考试可能会考案例分析,需要记住不同领域的特定风险:
- Cloud (云): 模糊了内外网边界 (Blurs the line)。 idot; Mobile (移动): 应用权限过高 (Same access as owner)。
- IoT (物联网): 泄露环境和用户情境信息 (Contextual information)。
- 安全建模 (Security Modeling): 理解 State Models (状态模型) 的作用——确保系统始终处于安全状态(Secure State)。
- 威胁建模步骤 (Threat Modeling Steps): 微软提出的流程是一个很好的答题框架:识别资产 -> 架构概述 -> 分解应用 -> 识别威胁 -> 文档化 -> 评级。
- 安全案例 (Security Case): 这是一个重要的论证过程,由 Claims (声明)、Arguments (论证) 和 Evidence (证据) 组成,用于向利益相关者证明系统的安全性。
评论区
欢迎在评论区指出文档错误,为文档提供宝贵意见,或写下你的疑问