• 概述
  • 信息系统安全威胁
    • 物理安全：系统所用设备
    • 通信链路：传输线路上安装窃听装置或对通信链路进行干扰
    • 网络安全：窃取互联网信息
    • 操作系统：软件或硬件芯片植入威胁
    • 应用系统：网络服务或用户业务系统安全的威胁
    • 管理系统：人员管理上的疏忽
  • 安全架构
    • 架构面向安全性方向上的一种细分
      • 产品安全架构：产品安全质量属性的重要组成部分以及它们之间的关系
      • 安全技术体系架构：安全技术体系的主要组成部分以及它们之间的关系
      • 审计架构：独立的审计部门或其所能提供的风险发现能力
• 安全模型
  • 安全目标：控制和管理主体对客体的访问
  • 安全模型是准确地描述安全的重要方面及其对系统行为的关系，安全策略是从安全角度为系统整体和构成它的组件提出基本的目标
  • 状态机模型描述了一种无论处于何种状态都是安全的系统，用状态语言将安全系统描述成抽象的状态机，用状态变量表述系统的状态，用转换规则描述变量变化
    • 一个状态是系统处在特定时刻的一个快照，若满足安全策略的要求，则称此状态是安全的
  • Bell-LaPudula（BLP 模型）
    • 保证机密性
    • 主体、客体、访问操作、安全级别
    • 安全规则
      • 只能向下读，只能读安全级别低的客体
      • 只能向上写，只能写安全级别高的客体
  • Biba 模型
    • 保证完整性
    • 防止数据从低完整性级别流向高完整性级别
      • 只能下写，只能写完整性低级别的客体
      • 只能上读，只能读完整性高级别的客体
  • Clark-Wilson 模型 CWM
    • 完整性模型
    • 提出了职责隔离目标
    • 提出了应用相关的完整性验证进程
    • 定义了对于变换过程的应用相关验证
  • Chinese Wall 模型
    • 多边安全系统中的安全模型
    • 防止各部门之间出现有损客户利益的利益冲突事件
    • 客户访问的信息不会与当前他们可支配的信息产生冲突
    • 规则
      • 墙内信息可以访问
      • 完全不同的利益冲突组的可以访问
      • 主体未对任何属于其他公司数据集进行访问时才可以写
    • 定理
      • 主体只能访问位于同一公司数据集的客体或在不同利益组的客体
      • 在一个利益冲突组中，一个主体最多只能访问一个公司数据集
• 安全体系架构规划框架
  • 组织机构信息技术系统的安全体系结构的整体描述
  • 目标：建立可持续改进的安全技术体系架构的能力
  • 5 个层次的实体对象：应用、存储、主机、网络和物理
  • 三部分构成
    • 技术体系：全面提供信息系统安全保护的技术保障系统
    • 组织机构体系：组织保障系统
    • 管理体系：法律管理、制度管理和培训管理
  • 依托企业信息化战略规划
    • 目标应与企业信息化目标一致，目标更具体明确，更贴近安全
  • 围绕技术安全管理安全组织安全考虑
  • 以信息系统与信息资源的安全保护为核心
    • 围绕信息系统与信息资源的开发、利用和保护工作进行
    • 从信息化建设的蓝图入手，制定出信息系统安全的发展目标
    • 整体的、综合、全面的分析
    • 提出未来几年的需求
    • 在实施工作阶段的具体措施与方法，提高规划工作的执行力度
• 信息安全整体架构设计
  • WPDRRC 模型
    • 6 个环节：预警、保护、检测、响应、恢复、反击
      • 预警：检查系统存在的薄弱环境，分解网络的风险变化趋势和严重风险点
      • 保护：成熟的信息安全技术及方法来实现网络与信息的安全
      • 检测：发现新的威胁和弱点
      • 响应：检测到安全漏洞和安全事件后必须及时做出正确的响应
      • 恢复：尽可能短的时间内使系统恢复正常
      • 反击：形成强有力的取证能力和依法打击手段
    • 3 大要素：人员、策略和技术。人员是核心、策略是桥梁、技术是保证
  • 考虑两个方面
    • 系统安全保障
      • 安全服务、协议层次和系统单元
      • 主要考虑
        • 安全区域策略的确定
        • 统一配置和管理防病毒系统
        • 网络安全管理
    • 信息安全体系
      • 物理安全
      • 系统安全
      • 网络安全
      • 应用安全
      • 安全管理
• 网络安全体系架构设计
  • OSI
    • 除去第 5 层会话层外每一层都能提供安全服务
    • 最适合配置的有物理层、网络层、运输层和应用层
    • 5 类安全服务包括鉴别、访问控制、数据机密性、数据完整性、抗抵赖性
    • 定义分层多点安全技术体系架构
      • 多点技术防御：多点攻击一个目标
      • 分层技术防御：对手和目标间使用多个防御机制
      • 支撑性基础设施
    • 鉴别：防止其他实体占用和独立操作被鉴别实体的身份。两种关系背景：实体由申请者来代表；实体为验证者提供数据项来源
    • 访问控制
      • 决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权的访问
      • 访问控制信息 ACI 用于访问控制目的的任何信息，包括上下文信息
      • 访问控制判决信息 ADI 是在做出一个特定的访问控制判决时可供 ADF 使用的部分/全部 ACI
      • 访问控制判决 ADF 通过对访问请求、ADI 以及该访问请求的上下文使用访问控制策略而做出访问控制判决
      • 访问控制实施 AEF 确保只有对目标允许的访问才由发起者执行
    • 机密性
      • 依赖所驻留和传输的媒体
      • 存储中使用隐藏数据语义或数据分片保证
      • 传输中使用禁止访问机制、通过隐藏数据语义的机制或通过分散数据的机制保证
    • 完整性
      • 组织对于媒体访问的机制
      • 用以探测对数据或数据项序列的非授权修改
    • 抗抵赖
      • 证据生成、验证和记录，以及在解决纠纷时随机进行的证据恢复和再次验证
• 数据库系统的安全设计
  • 完整性
    • 数据的正确性和相容性
    • 通过 DBMS 或应用程序实现
    • 把握以下规则
      • 确定其实现的系统层次方式
      • 实体完整性约束、引用完整性约束
      • 慎用目前主流 DBMS 都支持的触发器功能
      • 需求分析阶段就必须制定完整性约束的命名规范
      • 根据业务规则对数据库完整性进行细致的测试
      • 专职的数据库设计小组
      • 采用合适的 CASE 工具降低数据库设计各阶段工作量
    • 作用
      • 防止合法用户使用数据库时添加不合语义的数据
      • 基于 DBMS 的完整性控制机制实现业务规则，易于定义
      • 兼顾完整性和系统的效能
      • 有助于尽早发现应用软件的错误
    • 需求分析阶段就确定
• 系统架构的脆弱性分析
  • 分析信息系统中产生脆弱性根源
  • 漏洞来源：软件设计的瑕疵、软件实现的弱点、软件本身的瑕疵、系统和网络的错误配置
  • 脆弱性特点
    • 隐藏的弱点，本身不会引起危害
    • 自觉或不自觉引入的逻辑错误
    • 系统环境的差异可能会导致
    • 得到修补或纠正可能会引起新的脆弱性
  • 生命周期
    • 引入阶段
    • 产生破坏效果阶段
    • 修补阶段
  • 分析从三个方面考虑
    • 软件故障现象
    • 软件开发
    • 软件使用
  • 分析对象分为：脆弱性数据和软件系统。软件本身考虑软件结构和实现技术
  • 典型软件架构的脆弱性分析
    • 分层架构：层间脆弱性、层间通信的脆弱性
    • C/S 架构：客户端软件、网络开放性、网络协议
    • B/S 架构：HTTP 协议
    • 事件驱动：组件、组件间交换数据、组件间逻辑关系、容易死循环、高并发、固定流程
    • MVC 架构：复杂性、视图与控制器紧密连接、视图对模型数据的低效率访问
    • 微内核架构：难以进行良好的整体优化、进程间通信开销大、通信损失率高
    • 微服务架构：分布式系统的复杂、服务间通信、服务管理复杂