在线图片,重点见png。
1、安全运营主题相关
运行安全
- 在集中式和分布式环境中处理信息资产的保护和控制,
- 运行安全是其他服务的一个品质,并且它本身就是一组服务
安全运行
- 保持安全服务高效可靠的运行所要求的日常事务
Topics 主题
- 调查
- 调查类型
- 记录和监控
- 供应资源
- 基础安全操作概念
- 资源保护技术
- 事件响应
- 补丁和漏洞管理
- 变更管理流程
- 预防措施
- 恢复策略
- 业务连续性规划与实施
- 物理安全
- 人员安全
- 灾难恢复流程
- 灾难恢复计划
Objectives 目标
2、安全运营的基本概念
运营安全的四个关键主题
- 维护运营弹性
- 保护有价值的资产
- 控制系统账号
- 有效管理安全服务
运营人员的要求
- prudent man负责、谨慎、明智和有能力的人
- 适度谨慎 due care
- 采取了合理的防范保护措施
- 适度勤勉 due deligence
- 在日常管理中尽到责任
控制特权账号
- 对帐号的数量和类型进行严格控制
- 小心监控系统的帐号管理权限
- 如区分服务帐号 和执行脚本的账户
- IAM 身份和访问管理
- 用户配置开通
- 知所必需和最小特权(互为补充)
- need to know知所必需
- 要求用户或进程没有不必要的访问特权来执行工作、任务和功能
- 限制用户和进程只访问必要的资源和工具来完成指定任务
- 限制可访问的资源,用户可以执行的操作
- Least privilege最小特权
- 基于工作或业务需要被授予最小知悉范围和访问权限
- 运营安全是关键,常用于军队
使用组和角色管理账号
- 不同类型的帐号
- 特权帐号
- Root or内置管理员帐号
- 用于管理设备和系统全能默认账号 – 安全控制 – 更名尽可能的严格
– 默认密码要修改
– Logs记录个人使用 root账号的行为
– 使用root帐号远程登录时
– 会话应执行强加密和监控
– 使用多因子的身份验证方法- 服务帐号
- 由系统服务和核心应用所使用的特权访问
- 密码复杂并经常更换
- 有一个策略来回收和关闭已遭泄露帐号
- 管理员帐号
- 这些账号被分配给需要系统特权访问来执行维护任务的指定个人
- 这些账号应与用户的普通账号分开
- 账号密码应安全可靠的分发给个人
- 管理员应书面承认接收账号并遵守组织规则
- 账号不再使用应立即去除
- 所有的活动应该被审计
- 部署额外的日志系统
- 多因素认证
- 超级用户
- 这些账号权限由于工作所需授予超过普通用户权限但是不需要管理员权限的
- 超级用户可以在自己的桌面上安装软件
- 应书面承认接收账号并遵守组织规则,如签署安全协议书
- 普通或受限用户账号
- 职责分离 (会导致合谋)
- 定义:将一个关键任务分成不同的部分,每个部分由不同的人来执行
- 共谋:进行欺诈需要多人共谋
- 目的: 制约,减少故意破坏的几率 补充,减少无意的疏漏和错误的几率
- 分离角色的原因
- 不同安全相关任务所需技能不同
- 将管理员任务分成多个角色以赋予不同的信任级别
- 防止安全相关功能委托一个角色或人员
- 系统管理员
- 最小特权
- 根据需要确定必要访问和应用
- 监控
- 行为被日志审计并发送到一个 单独的审计系统中
- 职责分离
- 管理员如果没有勾结他人就没能力参与恶意活动 ,将一个关键任务分解成多个不同的部分,每个部分由不同的人执行
- 背景调查
- 工作轮换 (检测性手段,预防性/威慑)
- 有不止一个人能够完成该职位的工作,可发现欺诈舞弊
- 安全管理员
- 作用:定义系统安全设置并协同管理员进行相关配置,提供一种权利制衡,为系统管理员提供审计和审查活动
- 主要职责
- 账号管理
- 敏感标签的分配
- 系统安全设置
- 审计数据的评审
- 帮助/服务台人员
- 提供一线支持
- 在需要时重置用户密码
- 进行监控和背景调查
- 操作员
- 工作职责
- 进行主机的日常操作,确保预定的工作有效进行和解决可能出现的问题
- 权限说明
- 操作员具有很高的权限,但低于系统管理员,这些权限可以规避系统的安全策略,应监控这些特权使用并进行日志审计
- 安全控制
- 最小特权
- 监控
- 操作员的行动被记录并发送至不受操作员控制的一个独立系统中
- 职责分离
- 管理员如果没有勾结他人就没能力参与恶意活动A
- 背景调查
- 普通用户
- 需要访问信息技术资源
- 监控特权
- 许可、适用性和背景调查
- 以下情况不应被授予访问权限(如,基于IDS 和防火墙日志,应立即阻断某个IP的访问,但没有;调整时钟或删除日志等)
- 近期严重缺乏相关的判断力
- 有关角色的行为出现重复的高风险模式
- 角色的表现与非法活动有关.
- Account Validation帐户验证
- Job rotations岗位轮换
- 双人操作
- 现场相互监督
- 双人核验
- 双重控制
- 通过知识分割实现
- 强制休假 (检测性控制手段)
- 又突然性,可以检测欺诈舞弊的手段
信息生命周期管理(OSG的第五章)
- 信息生命周期包括产生、分类、存储、使用、归档、销毁或清除
- 信息使用者:
- 确定信息对组织使命的影响
- 理解信息的替代价值(如果它可以被取代).
- 确定组织内外部所需要信息以及在什么环境下发布信息
- 知道信息不准时或不再需要时应该被销毁
- 信息的分类和属性
- 分级关注访问
- 分类关注影响
- 可使基线标准化
- 保留计划
- 降低存储成本
- 只保存相关的信息,可加快搜索和索引
- 诉讼保留和电子披露是不太可能会遇到错误,预决策或协商信息
(SLAs)服务水平协议
- SLA是什么?
- SLA是一个描述客户从供应商获得服务水平的简单文档,展示服务测量指标、补救或如果达不到协议要求所遭受的惩罚
- 如果由于客户的原因导致SLA达不到,则不应该受罚
- SLA外部
- IT承诺给业务部门或外部客户
- OLA内部
- IT内部
- UC支持合同
- 和供应商签订
- 为什么需要?
- 确保双方理解要求
- 确保协议没有被有意或无意的曲解
- 谁提供SLAs
- 不同的级别不同的价格
- 协商的起点
- 关键部分
- 服务部分
- 提供具体服务
- 服务可用性状态
- 服务标准(时间窗)
- 升级程序
- 各方职责
- 费用/服务权衡
- 管理部分
- 测量标准和方法定义\报告流程\内容和频率\争议解决过程
- SLA保持更新
- 供应商能力和服务需求变化
- 何时评审SLA
- 客户业务已经发生改变
- 技术环境已经发生变化
- 供工作负载发生改变
- 测量指标、测量工具以及流程的改进
3、配置管理
配置管理的目的
- 建立和维护产品、系统和项目整个生命周期的完整性
软件配置管理包括
- 识别软件产品的配置项
- 控制配置项及其变更
- 记录和报告配置项的状态和变更活动
配置管理
- 配置管理涉及在组件层面变更的评价、调整、同意或不同意、以及实施并用于软件系统的重建和维护
- 管理组件从最初的概念到设计、实施、测试、基线、构建、发布和维护
- 使得必然发生的变更可控
- 策略和标准定义组件集处于配置管理的支配下 组件是如何命名的 组建是如何输入和离开控制集的 处于CM下的组件是如何被允许变更的 CM下的不同版本的组建是如何可用的 在什么情况彼此每个都能使用 CM工具是如何启动和加强配置管理的
软件工程研究所(SEI)的
配置管理能力实践
- 识别将要置于配置管理下的配置项、组件及其相关工作产品
- 建立和维持配置管理和变更管理系统来控制工作产品
- 建立和发布内部使用基线以及交付给客户的基线
- 追踪配置项变更请求
- 控制配置项内容变更
- 建立和维持描述配置项的记录
- 执行配置审计来维持配置项的完整性
配置管理用于不同类型的资产管理
- 物理资产
- 服务器、笔记本、平板电脑、智能手机
- 虚拟资产
- 软件定义网络SDN、虚拟存储区域网络VSAN、虚拟机VM、虚拟桌面VDI
- 云资产
- 服务、组织、存储网络、租户
- 应用程序
- 私有云工作负载、Web服务、软件及服务saas
- 软件库和硬件库的安全作用
- 安全专家能迅速找到和减少与硬件类型和版本相关的漏洞
- 知道网络中硬件类型和位置能降低识别受影响设备的工作量
- 可以经扫描发现网络中未经授权的设备
4、变更管理
目的
- 保证变更不会导致意外中断
变更流程
- 1、请求变更
- 2、审核变更
- 3、批准/拒绝变更
- 4、测试变更
- 5、安排并实施变更
- 6、记录变更
紧急变更
- 得到手头授权
- 该有的测试和回退计划都要有
- 事后再补记录和补正式的授权
- ECAB 紧急变更顾问委员会
5、补丁管理和漏洞管理
补丁管理
- 目的
- 建立持续配置环境保护操作系统和应用的已知漏洞
- 很多时候厂商升级版本时不给出升级的原因和理由
- 补丁管理考虑的风险因素
- 书否通过管理层审批
- 是否遵从配置管理的策略
- 是否考虑宽带的利用率
- 是否考虑服务可用性
- 补丁管理最佳实践
- 集中补丁管理
- 集中管理补丁分类
- 基于代理
- 无代理
- 被动方式
- 虚拟化技术使你更容易建立补丁测试环境
- 一些控制措施如IDS\防火墙等,可以预留测试补丁的时间
- 补丁管理步骤
- 安全专家需要判断是否是漏洞
- 是否需要升级补丁:基于风险策略或补丁的重要程度
- 管理层和系统属主来确定是否更新补丁,是否会影响到业务
- 更新补丁已经被测试以及残余风险被解决
- 安排更新
- 部署前通知用户
- 在夜间或周末更新
- 部属前备份服务器
- 更新完成后需要在生产环境中验证,可能会产生一些不可见问题
- 部署完成后确保所有适当的机器都被更新
- 记录所有变更
- 安全和补丁信息管理
- 关键部分
- 补丁管理是要知道关于安全问题和补丁发布两者的信息
- 知道与他们环境有关的安全问题和软件更新
- 建议专人和团队负责提醒管理员和用户的安全问题或应用的更新
- 补丁优先级和作业安排
- 1、补丁生命周期(patch cycle) 指导补丁的正常应用和系统的更新,在周期中时间或事件驱动,并帮助应用的标准补丁的发布和更新
- 2、作业计划处理关键安全和功能补丁和更新;优先级和调度依赖于厂商报告的关监督以及系统的关键和系统的暴漏度
- 补丁测试
- 补丁测试的广度和深度
- 系统的关键度
- 处理的数据
- 环境的复杂度
- 可用性需求
- 可用资源
- 补丁测试流程开始于软件更新的获取和在生产部署后连续通过可接受性测试
- 补丁获取时需要进行验证
- 来源(soucre)校验
- 完整性(integrity)校验
- 数字签名
- 校验和
- 补丁校验完成后进行测试
- 测试环境尽可能的接近生产环境
- 可以用生产系统的子系统作为测试环境
- 补丁变更管理
- 变更对补丁管理的每一步都非常重要
- 修补应用程序应包含应急和回退计划
- 在变更管理方案中包含风险降低策略
- 变更管理方案中包含监控和可接受计划
- 证明补丁成功具体里程碑和可接受标准
- 允许关闭变更系统中更新
- 补丁安装和部署
- 补丁管理的部署阶段必须具有良好经验的管理员和工程师
- 安装和部署意味着生产系统的补丁和更新会真实实施
- 影响补丁部署的技术因素是工具的选择
- 工具选择
- 购买
- 自建
- 工具类型
- agent-based
- agentless systems,
- 部署安全补丁
- 及时完成
- 可控和可预期
- 补丁审计和评估
- 常规审计和评估能衡量补丁管理成功和程度
- 两个问题
- 对于任何已知漏洞或Bug什么系统需要修补?
- 系统是否更新真实的补丁?
- 关键成功因素
- 资产和主机管理
- 管理工具
- 管理工具
- 系统发现和审计作为审计和评估流程的部分
- 一致性和复合型
- 补丁管理方案中的审计和评估元素能帮助识别系统不符合组织指南或其他减少不符合的工作
- 系统声称工具和指南在安装时确保符合补丁要求主要执行手段
- 补丁管理技术非常重要,但仅靠技术不行 补丁管理方案是团队技术提供基于协作解决组织独特要求的方针和运维的解决方案
漏洞管理系统
- 脆弱性扫描
- 帮助组织知道其所有部分
- 漏洞类型
- 系统缺陷
- 配置错误
- 策略错误
- 基于主机的扫描
- 应用安全扫描
- 数据库安全扫描
- 发现配置错误
6、事件和调查
事件
- 事件管理
- 包含人、技术和流程,指导所有与事件有关的活动并指导安全人员到一个预定义和预授权路径的解决方案。
- 描述在事件中所包含的各方的角色和职责中所采取的活动。
- 管理安全技术
- 安全运营关注确保技术能够有效运行,并持续监控其有效性
- 边界控制
- 可信和不可信环境之间的划分
- 单个系统,在核心功能和终端用户流程
- 安全测量指标和报告
- 安全服务必须有能力提供测试部署在企业中安全控制的有效性
- 安全技术
- ID/IPS
- 检测或阻断攻击,以及提供趋势分析
- 防火墙
- 通过IP地址追踪攻击源和其他方式
- 安全邮件服务
- 发现或阻断大量的恶意软件或垃圾邮件
- 报告
- 报告是成功安全运行的基础
- 报告的预期受众
- 技术报告趋向于为技术专家或直接服务交付的经理设计
- 管理报告
- 提供多系统的综述以及报告所覆盖的每个服务的关键指标
- 高管仪表板
- 为高管提供当前状态的综述
- 以图表等高度可视的形式展现
- 事件检测
- 入侵检测预防与系统
- 功能
- 用来识别和应对实时或近实时的可疑安全相关事件
- 架构类型
- 基于网络流量分析
- 基于单个系统的审计日志和流程
- 部署方式
- IDS-旁路部署/带外或者并线部署
- IPS-在线或串联部署
- IDS/IPS技术类型
- 模式匹配(或签名分析)
- 基于异常协议的入侵检测系统
- 基于统计异常的入侵检测系统
- 存在问题
- 误报和漏报
- 防恶意软件系统
- 功能
- 部署在单个主机和系统上
- 主要安全要求
- 需要不断持续更新升级,通过监控来确保防病毒系统始终存活和有效
- 部署介质和邮件附件自动扫描策略;扫描应给定期安排和实施
- (SEIM)安全信息事件管理系统
- 系统日志的缺点是只能提供单个系统的视角,不能提供相关事件的涉及多个系统
- 提供一个公共平台,用于日志收集、整理、实时分析
- 提供使用来自多信息源并关于历史事件的报告
- 日志管理系统是类似的结合SEIM解决方案,提供实时分析
- 维护严格的日志存储和归档纪律
- 当今的报告工具可以将安全事件信息转换为有用的业务智能
- 响应
- 遏制策略
- (举例:从网络中切断病毒源、控制受感染的主机)
- 以合法行为来保存法庭证据
- 提供受影响的组件,保持服务的可用性
- 替代受影响组件,避免可能造成的潜在损害
- 需要时间来实施有效的遏制策略
- 需要资源来遏制受影响的组件
- 注意事项
- 延迟遏制策略导致更深的影响
- 起始事件以及相关信息应尽可能多的被记录
- 最好的办法是使用蜜罐系统和有经验的工程师
- 响应团队应关注获得受攻击系统和内存RAM和硬盘的取证影像并确定如何减少弱点
- 同样存在法律后果的是组织知道攻击系统正在被用于攻击的其他系统
- 报告
- 媒体或组织的外部事务组需要参与吗?
- 组织的法律团队需要参与评审吗?
- 该事件在什么时间点应该上升到一线管理人,并通知中层管理人。
- 高层管理人?董事?股东的董事会?
- 保护事件信息的保密性要求是什么?
- 用于报告的方法是什么?如果电子邮件系统被攻击,那么如何启动报告和通知程序?手机、固化,应急联系人?
- 恢复
- 恢复计算机映像到无损失
- 恢复的第一步是根除,根除是消除威胁的过程
- 将系统恢复或修复到一个已知的良好状态。
- 如果最后已知的映像或状态包含有实际造成事件的原因, 那么恢复变得非常复杂,这种情况下,新得映像应该生成, 并在应用移入生产环境前测试.
- 修复和审查(经验教训)
- 事件响应最重要的是总结经验教训
- (RCA)根本原因分析
- 评审系统日志、策略和程序、安全文档以及捕获可用的网络流量并首先拼凑成能够导致事故的时间伤史l
- 根源分析被管理层评审,决定是否采纳和执行
- 问题管理
- 管理不良事件,限制一个事件的影响。
- 跟踪该事件回到事件根源和解决的根本问题,关于解决缺陷,使得该事件可能成功或更成功。
- 需要更长的时间,在操作环境中发生的事件的长期过程,可能需要特定的条件,这个条件可能不会常常发生
- 安全审计和评审-缓解前兆
- 安全审计
- 由独立第三方实施,确定是控制所需要的程度
- 内部评审
- 由不负责该系统管理的组织成员来实施
- 外部审计
- 基于组织安全需求由外部实体来评价系统,提供系统的独立评审
- 安全评审
- 由系统维护或安全人员实施,来发现系统的漏洞,渗透测试属于安全评审
- 安全审计和评审的输出应列为将要有组织解决的项目和问题
- (RCA)根本原因分析
调查
- 相关定义
- 数字调查
- 大多数组织传统上缺乏的一个领域是适当的证据处理和管理。
- 计算机取证、数字取证和网络取证到电子数据发现、网络取证和取证计算。
- 基于有方法的、可验证的和可审计的程序和协议
- (DFRWS)数字证据科学工作组
- 为促进和加强发现犯罪事件的重建或者帮助预判非授权活动会终端计划运行,使用科学导向和证实的方法提取来自数据源的数字证据进行保护、收集、验证、识别、分析、解释、记录和展示。
- 取证指南
- 识别证据
- 正确识别犯罪场景、证据和潜在的证据容器;
- 搜集或获取证据
- 秉承刑事罪证查验原则以及确保场景的污染和破坏保持最小,使用可靠和可重复的收集技术来展示证据或证据拷贝的精确性和完整性
- 检查或分析证据
- 使用可靠的科学方法来确定证据的特征,进行个别证据对比以及事件重构
- 展示证据
- 解释来自于基于事实的发现的检查和分析的输出以及以一种适合特定观众的格式进行阐述
- 犯罪场景
- 形式原则
- 1、确定现场
- 2、保护环境
- 3、确定证据和证据的潜在来源
- 4、收集证据
- 5、降低污染度
- 环境
- 物理环境
- 处理相对简单
- 虚拟场景
- 很难确定证据真正的位置或获取证据
- 动态证据
- 数据存在于动态的运行环境中,保护虚拟场景非常困难
- 动机 ,机会,和手段 MOM
- 动机
- 谁,为什么
- 机会
- 何时,何地
- 手段
- 罪犯需要获得成功的能力
- 计算机犯罪行为
- 惯用手法MO
- 罪犯使用不同的操作手法进行犯罪,这可以用于帮助标识各类犯罪
- 罗卡交换定律
- 认定罪犯在带走一些东西的时候会遗留下一些东西
- 国际计算机证据组织 IOCE/Group of 8(G8)国际原则
- 当处理数字证据是,必须应用所有通用取证和程序原则.
- 抓取证据的行为不能改变证据.
- 当人员有必要访问原始数字证据时,这个人需要以此为目的进行培训.
- 所有与数字证据的扣押、访问、存储或传输有关的活动必须被完全记录、保留并在评审检查时可用.
- 当数字证据在某人身上时某人必须为所有关于数字证据的活动负责.
- 任何负责抓取、访问、存储和传输数字证据的机构对符合这些原则负责。
- 事件处理的策略、角色和职责
- 策略必须清晰、简明、并对事件响应/处理团队授权来处理任意和所有的事件
- 配备人员并经过良好培训的事件响应团队
- 虚拟团队
- 专职团队
- 混合模式团队
- 外包资源
- 响应团队的核心领域
- 法律部门(内外部的法律顾问都可以)、人力资源、通信、高管、物理/企业安全、内部审计、IS安全以及IT部门等,也包括先关业务部门、系统管理员和任何能够辅助进行事件的调查和恢复的人员
- 团队建立好需要进行培训并保持最新的培训,需要耗费极大的资源
- 小心处理公共消息披露,公关事宜
- 事件响应
- 事件响应或事件处理已经成为组织安全部门的主要职责
- 事件响应通用框架
- 建立事件响应能力
- 事件处理和响应
- 恢复和回馈
- 事件期望的结果
- 降低事件的影响
- 识别根本的原因
- 尽可能短时间的重新建立或运行
- 预防事件的再次发生
- 事件处理和响应
- 事件定义
- 事件是一个可被观察、验证和记录在案的消极事情
- 事故定义
- 事故是给公司及其安全状况造成负面影响的一系列事件
- 事故响应
- 些事情给公司造成影响并引发了安全违规,诸如此类应对问题成为事故响应或事故处理
- 处置步骤流程
- 诊断
- 包含事件的检测、识别和通知等子阶段;
- 根据事件潜在风险级别进行归类,这受到事件类型、来源(内部事件还是外部事件)、增长速度、错误抑制能力的影响;
- 处理假阳性事件( false-positive )/误报时最耗时间的;
- 如果是真实事件,则需要进行分类(基于组织的需求)和分级(确定潜在风险的等级或事件的关键度)
- 调查
- 直接处理事件的分析、解释、反应和恢复;
- 调查涉及对相关数据的适当收集,收集的数据将在分析和随后的阶段中使用;
- 管理层必须确定执法部门是否参与调查,是否为起诉而收集证据,或者是否只修补漏洞;
- 遏制
- 遏制事件,降低事件的影响
- 遏制措施应当基于攻击的类别、受事故影响的资产以及这些资产的关键程度;
- 适当的遏制措施为事故响应团队争取了对事件根本原因进行正确调查和判定的时间;
- 必须维持适当的记录以及证据潜在来源的处理;
- 必须维持适当的记录以及证据潜在来源的处理;
- 分析和追踪
- 在分析阶段收集更多的数据(日志、视频、系统活动等),从而试图了解事件发生的根本原因,并确定事件的源头是内部还是外部,以及入侵者如何渗透的;
- 安全专家需要结合正式的培训以及真实经验来作出适当的解释,往往没有足够的时间;
- 追踪往往与分析和检查并行,而且需要剔除错误线索或故意的欺骗的源;
- 另外比较重要的是一旦根源被识别以及追踪到真正的源头时需要做什么。
- 恢复
- 目的是使得业务得以恢复和运行、让受影响的系统恢复生产,并与其他活动一致;
- 进行必要的修复工作,以确保此类事件不会再次发生;
- 修复工作包括:阻止敏感端口、禁用易受攻击的服务或功能、打补丁等。
- 报告和记录最重要也最容易忽视的阶段就是汇报和反馈阶段; 组织往往能在事件中学习甚多,并从错误走向成功; 汇报需要所有的团队成员,包含受事件影响的各个团队的代表; 测量指标可以决定预算配置、人员需求、基线、展示审慎和合理性; 难点在于产生对组织有意义的统计分析和指标。
- 证据收集和处理
- 证据保管链
- 其所指的是证据介质从最初的采集、标识,到运输、使用、中间的保管及最后的存放和归档,都要有明确记录(Document)、职责归属(Accountability),以确保原本的证据介质完全没有任何机会被污染(Contaminate)和篡改(Tamper);
- 在整个证据的生命周期过程中,都是关于证据的处理的who, what, when, where, and how;
- 确保证据的真实性和完整性( authenticity and integrity),借助Hash(SHA-256)和数字签名;
- 访谈
- 调查过程中最为微妙的部分,就是证人和嫌疑人的访谈;
- 访谈前必须要审视策略、通知管理层以及联系公司法律顾问;
- 访谈过程不要单独一人,如果可能,录下整个访谈过程作为佐证;
- 理解取证程序
- 可被法庭接受的证据
- 证据标准
- 展现真实 – 准确具体 – 完整的 – 令人信服的 – 可以受理 – 数字证据是动态易变的,所以关注收集的时间
- 证据分析方式
- 介质分析:从信息介质中恢复信息或证据;
- 网络分析:从使用的网络日志和网络活动中分析和检查作为潜在的证据;
- 软件分析:分析和检查程序代码(包括源代码、编译代码和机器码)、利用解码和逆向工程技术、包括作者鉴定和内容分析等;
- 硬件/嵌入式设备分析:应包含移动设备的分析;
- 取证原则
- 调查的任何行动不得改变存储介质或数字装置中的数据;
- 访问数据的人员必须有资格这么做并有能力解释他们的行为
- 适用于第三方审计并应用于流程的审计痕迹或其他记录应被生成和保护,并精确的记录每个调查步骤
- 负责调查的人必须完全对确保以上提到的层序负责并遵守政府法律
- 关于人员抓取数据的行为不得改变证据
- 当有必要人员访问原始证据时,这个必须具有法律资格
- 与数字证据的抓取、访问、存储或传输有关的行为必须小心的记录、保存并可用于审计
- 当数字证据为某人持有时,这个人必须为证据所采取的行动完全负责
- 调查类型需求
- 计算机犯罪就是计算机促进和协助的非法行为,不管计算机是犯罪目标、犯罪工具还是与犯罪有关的证据存储。
- 计算机犯罪的第一响应人在搜索和抓取计算机设备时必须小心
- 犯罪调查三要素信息累积:是调查的基本要素 工具:工具在调查财务相关犯罪时涉及计算机系统主要围绕追踪和分析确定在正常模式下的差异或违规的日志和记录; 访谈:为调查者提供间接工具,如深入动机和可能所使用的技术,尤其是攻击者是内部人员时;
- 持续和出口监控
- 出口监测
- 出口过滤机制是监控的实践以及潜在限制从网络的一边到另一边的信息流;
- 从私有网络到互联网的信息流应被监控和控制;
- 应严格的控制、监视和审计网络流量;
- 使用物理和逻辑访问控制机制影响和管理网络流量和带宽;
- 每当新应用需要外部网络访问可能需要策略的变更和行政管理机制;
- 边界装置检查离开内网的数据包并验证所有出站数据包源IP地址属于分配的内部地址块,防止内网收到IP地址的Spoofing(欺骗)攻击;
- 安全架构师和专家承受监控方案方面的职责
- 设计的持续监控系统符合机构需求;
- 实施持续监控系统并保护机构关键设施;
几种计算机犯罪
- salami攻击
- 供给者实施几个小型的犯罪,希望他们结合起来的较大犯罪不会引起人们的注意
- 数据欺骗
- 对现有数据的更改
- 密码嗅探
- 捕捉计算机之间发送的密码
- IP欺骗
- 攻击者不想让其他人知道自己的真实地址,从而改变数据包IP地址,使其指向另一个地址。
- 垃圾搜索
- 翻看其他人的垃圾箱,以寻找丢弃的文件、信息和其他可用来对该人或公司不利的珍贵物品。
- 搭线窃听
- 一种被动攻击,用于窃听通信的工具可以是无线电话扫描器、无线电接收器、麦克风接收器、录音器、网络嗅探器等。
- 域名抢注
- 是指有人怀着用一个类似域名损害公司或者进行敲诈勒索的目标,购买了一个域名。
7、安全防护措施
资源保护
- 保护企业有价值的资产而不是全部资产
- 有形和无形资产
- 有形资产是物理的并属于传统资产范畴
- 无形资产不是物理的不属于知识产权范畴
- 设施防护
- 设施需要适当的系统和控制来维持它的运营环境
- 硬件
- 硬件需要适当的物理安全措施来维护所需要的机密性、完整性和可用性
- 操作员终端和工作中应限制访问
- 应限制设施的访问
- 应保护移动资产
- 打印设施应位于授权用户附件
- 网络装置属于核心资产应需要保护
- 介质管理
- 类型
- 软件介质
- 磁介质、光介质和固体;磁介质包括软盘,彩带和硬件驱动器
- 固态介质
- 闪盘、存储卡
- 硬拷贝
- 纸张、微缩胶片
- 介质保护
- 介质包含敏感或机密信息应该加密
- 数据应通过加密来降低泄露
- 移动介质
- 问题
- 组织不知道信息何时离开
- 组织不知道信息是否被泄露
- 用户一般不会报告违规.
- 解决建议
- 组织实施DLP
- 监控和限制USB或其他端口;监控DVD、蓝光或其他可写介质
- 安全移动介质管理方案
- 强制加密使用强认证
- 监控和记录传输到介质的信息
- 库存保管能力
- 远程擦除能力
- 定位地理位置的能力
- 归档和离线存储
- 备份和归档水两种不同类型的信息存储方法
- 备份
- 基于常规基础并在灾难发生时用于恢复信息或者系统 – 包含用户日常处理的信息
- 归档
- 信息由于历史目的,且没有持续使用,应保存并从系统中移除
- 从备份中恢复时
- 应有良好定义和记录的程序确保恢复按照正常指令执行
- 所有的备份和归档介质都应定期测试
- 云存储和虚拟存储
- 云存储
- 定义
- 电子数据存储在逻辑池中,可通过共存的计算服务、Web服务API或者利用API的利用
- 云存储服务
- 定义
- 有许多分布资源组成但始终作为一个、通过数据的冗余和分布实现高容错、通过版本副本的建立来实现高耐用
- 虚拟存储
- 通过软、硬件技术,集成转化为一个逻辑上的虚拟的存储单元
- 虚拟存储类型
- 数据块存储
- 文件虚拟化
- 虚拟存储类型
- 基于主机的
- 基于存储设备的
- 基于网络的
- 硬拷贝记录
- 记录和信息管理程序 (RIM)
- 确保信息在组织遭遇灾难时可用
- 保护硬拷贝记录
- 风险
- 纸质记录的丢失或损毁可能由于火灾、谁在、飓风和龙卷风、爆炸、烟、霉菌和微生物
- 建立保护硬拷贝的策略:
- 存在在安全、干净以及环境稳定的容器中
- 制作备份拷贝并将备份拷贝存储在外部具有标准湿度的安全区域
- 制作微缩胶卷拷贝并将拷贝文档扫描成PDF文件或其他格式
- 处置和重用
- 应小心清除残留数据
- 简单删除或格式化不能真正删除信息,只是删除信息的提示
- 软件清除工具
- 使用随机或预定的模式覆写磁介质的每一个部分
- 缺点
- 一次性覆写易被恢复,对于敏感信息应多次覆写
- 易被实验室工具恢复
- 剩磁
- 衡量介质中残存的磁场,以某种方式擦除信息剩余部分的物理表现
- 不安全
- 消磁
- 使用电磁场消除磁性
- 就是降低介质上的磁场到零.
- 比较安全的处理方法
- 物理销毁
- 粉碎、燃烧、研磨是常见的方法
- 最安全,但要注意颗粒度
攻击性防御措施
- 保护措施通用流程
- 识别和评估风险
- 选择恰当的控制措施
- 正确的使用控制措施
- 配置管理
- 评估操作
- 非授权泄密
- 非授权信息泄密的泄露被认为是威胁
- 恶意软件的恶意活动以及恶意用户都会导致重要信息的丢失
- 腐化和不恰当的修改
- 入侵检测系统
- 基于网络入侵检测系统(NIDS)
- 被动架构,部署一个网络分流器,连接到一个Hub上或交换机镜像NIDS端口
- 处理的流量相当于或远大于该设备所有端口联合的流量负载
- 不能监控加密数据,需要关注用户培训和隐私的问题
- 基于主机入侵检测系统 (HIDS)
- 实时监控主机审计日志,部署每个关键主机上
- 对主机操作系统侵害性很大
- 干扰正常系统处理,过度耗费CPU和内存
- 基于应用IDS
- 监控具体应用恶意行为的IDS
- IDS按照防护原理
- 基于特征IDS
- 特征匹配,类似于防病毒软件
- 基于签名的IDS
- 特征必须持续更新
- 只有先前确定的攻击签名被检测,不能发现新的攻击
- 分类:特征匹配、状态匹配
- 基于异常IDS (也叫基于行为或启发式)
- 能检测新的攻击
- 缺点:可能错误得检测出系统中的一个瞬间异常造成的非攻击事件
- 能检测新的攻击
- 分类
- 统计异常
- 协议异常
- 流量异常
- 基于规则IDS
- 在专家系统中使用基于规则的程序IF/THEN
- 允许人工智能
- 规则越复杂,对软硬件性能要求越高
- 不能检测新的攻击
- 入侵响应
- 如果IDS检测到入侵
- 限制或阻止系统流量
- 同时也与其他设备集成进行响应
- 比如将规则注入到路由器、VPN网关、Vlan交换设备等
- 早期版本的IDS与防火墙集成,指导防火墙对可以流量实施拟定规则
- 在启动规则的过程中可能会影响正常业务
- 误报率要严格控制
- 告警和警报
- IDS基本组件
- 传感器
- DLP 数据防泄漏
- 定义
- 瞄准防止企业敏感信息泄露的一套技术
- 三个关键目标
- 将存储在整个企业的敏感信息进行定位和编程目录;
- 将存储在整个企业的敏感信息进行定位和编程目录;
- 对整个企业敏感信息的移动进行监控和控制;
- 对终端用户系统敏感信息的移动进行监控和控制;
- 组织敏感信息的分类、存储位置和传输路径
- 组织常没有认识到他们处理的信息的类型和位置,购买DLP方案时首先要了解敏感数据类型和系统间以及系统到用户的数据流;
- 分类可以包括属性,如隐私数据、财务数据和知识产权等;
- 一旦对数据进行适当的识别和分类,更深的分析流程来帮助进行主要数据和关键数据路径的定位;
- 需要关注企业数据的生命周期,理解数据的处理、维护、存储和处置等能揭示更深的数据存储和传输路径;
- 部署DLP的优点
- 保护关键业务数据和知识产权
- 加强合规
- 降低数据泄露风险
- 加强培训和意识
- 改进业务流程
- 优化磁盘空间和网络带宽
- 检测流氓/恶意软件
- 静态数据
- 寻找并识别具体文件类型,识别和记录信息存储的位置;
- 找到后,DLP打开并识别文件的内容;
- DLP使用爬虫系统
- 动态数据
- 解决方案
- 1、被动的监测网络流量;
- 2、识别捕获的正确数据流量;
- 3、组装所收集的数据;
- 4、在数据流中进行文件重建;
- 5、执行静态数据同样的分析并确认文件内容任何部分是收到其规则限制的。
- 为监测企业网络数据移动,DLP方案使用特别的网络设备或内置技术有选择的捕获和分析网络流量;
- 深度文件检测DPI技术,作为DLP的核心能力,DPI能够越过基本的包头信息阅读数据包载荷内容
- DPI技术允许DLP检测传输中的数据并确定内容、来源和目的地;
- DLP有能力应对加密的数据(如具有加密秘钥),或者再检测前进行解密并在检测完成后继续加密;
- 使用中的数据(端点agent)
- 监控终端用户在他们的工作站上所采取数据移动行为
- 使用Agent完成任务
- DLP的通用功能
- 策略建立和管理
- 集成目录服务
- 工作流管理
- 备份和恢复
- 报告
- 邮件防护——白名单、黑名单和灰名单
- 白名单
- 一列被列为“好的”发送者的邮件地址或IP地址等
- 黑名单
- 一列“坏”的发送者
- 灰名单
- 我不知道你是谁,在我接受之前让你的邮件跳过额外的步骤
- 灰名单会告诉邮件发送服务器快速的重新发送新的邮件
- DAST-动态应用安全测试
- 用于检测应用在运行状态中安全漏洞的状态,多数暴露的HTTP和HTML的问题,多基于WEB漏洞,有些为非Web协议和数据畸形
- 动态应用安全测试是一项第三方服务,具有爬虫能力来测试RIA,HTML5,具有爬虫能力并测试使用其他Web协议接口的应用
- 蜜罐系统和蜜网
- 作为诱饵服务器收集攻击者或入侵者进行系统的相关信息
- IDS的变体
- 更聚焦于信息的收集和欺骗
- 沙盒
- 软件虚拟化技术
- 让程序和进程在隔离的环境中运行
- 限制访问系统其他文件和系统,沙盒里发生的只在沙盒里发生
- 一项取代传统基于签名防病毒,可能检测到0day漏洞和隐藏的攻击
- 恶意软件会使用各种技术规避检测
- Hooks技术
- 为检测恶意软件引入的技术
- 直接插入到程序中得到函数或库调用的通知(call back)
- 这种技术需要更改程序代码
- 为恶意软件所感知
- 打断动态代码的生成
- 主要问题
- 在调用时沙盒不能看到恶意软件所执行的任何指令
- 反恶意软件
- (AMTSO防恶意软件测试标准组织
- 提供恶意软件测试和相关产品讨论的论坛
- 发布恶意软件测试的客观标准和最佳实践
- 促进与恶意软件测试问题有关的教育和意识
- 提供工具和资源致力于标准化测试和方法
- 需要保持规则的实时更新
8、灾难恢复管理
概念
- 连续性计划-CP
- 业务连续性计划-BCP
- 灾难恢复-DR
- 灾难恢复计划-DRP
灾难恢复-DR
- 包含域
- 响应、人员、通信、评估、恢复和培训
- 制定恢复策略站点生存 自助服务 内部安排 互惠协定/互助协定 专用备用站点 在家上班 外部供应商 没有布置的
- 恢复策略的选择必须符合组织需求
- 成本效益分析 (CBA)
- 建立策略的初始费用
- 维护恢复策略解决方案的持续费用
- 方案定期测试的费用
- 通信相关的费用
- 恢复时间目标 (RTO)\最大容忍宕机时间 (MTD) \ 恢复点目标 (RPO)
- 实施备份存储策略
- 全备份
- 差异备份
- 增量备份
- 恢复站点策略
- 双数据中心
- 使用该战略使得应用不能接受宕机影响组织
- 优势: 停机时间少(分钟及秒级)、与与维护、无需恢复
- 缺点: 费用更高、需要冗余硬件、网络和人员、受限于距离
- 热站点
- 内部热站
- 准备具有运行应用程序所需的所有的技术和设备的待机站点
- 运行非时间敏感的服务,例如开发或测试环境
- 外部热站点
- 设施已经就位,但是环境需要重建
- 这些服务于服务提供商协定
- 优点: 允许测试恢复策略、高可用性、站点可在数小时内恢复
- 缺点: 内部热站比外部热站更贵、外部热站存在软硬件兼容问题
- 温站
- 部分配置有一些设备但不是真实的计算机的租赁设施
- 天 级别的恢复
- 冷站
- 冷站就是一个壳或空数据中心,且地板上没有任何技术设施
- 优点: 低成本、用于较长的恢复
- 缺点: 不能及时恢复、没有前期完全的测试工作
- 周 级恢复
- 移动站点
- 是内部配置适当电信装备和IT设备的可移动拖车或标准的集装箱, 可以被机动拖放和安置在所需的备用场所,提供关键的应用服务,如电话交换功能等。
- 优点: 高机动性以及相对容易运输、模块化方法构建数据中心、构建时不需要室内设备
- 缺点: 冷站能力必须在指定位置建立、容器的密度和设计使得升级和定制化受到极大得挑战、维持在灾难时的航运合同或或移动设备非常昂贵
- 多处理数据中心
- 如果组织的设施覆盖全国或全世界可以使用此解决方案
- 具有足够的带宽和延迟
- 可以认为组织内部的“互惠协议”
- 处理协议
- 互惠协议
- 组织间用来分享宕机风险
- 在灾难发生时,每个组织承诺承担彼此的数据和处理任务
- 问题
- 组织承诺为他人保留空余处理能力或在其他组织宕机时降低处理能力
- 首先需要组织能够遵守这些协议
- 在行业内或竞争对手间很难找到合适的合作伙伴
- 外包
- 符合企业的成本效益需求
- 承担未知能力以及能够符合要求的风险
- SAL协议能表明在一段时间内提供服务,但不能真正保障在灾难时提供保障
- 优点
- 按需服务
- 所有要求和执行责任都在第三方
- 较少的成本
- 提供更广的地域选择
- 缺点
- 更多主动测试和评估来确认能力保持情况
- 协议争论使得厂家不能执行
- 如果部署私有系统将锁定厂商
- 如果频繁发生中断可能能力构建的费用更多
- 系统韧度和容错要求
- 可信路径和故障安全机制
- 可信路径
- 为特权用户功能提供可信接口
- 提供确保使用该路径的通信不会被拦截或破坏的方法
- 故障保障
- 发生故障时自动开启(如电源中断)
- 关注生命或系统安全
- 故障财物安全
- 发生故障时自动锁闭(如电源中断)
- 关注故障后以可控的方式阻止访问,当系统处于不一致状态时
- 冗余和容错
- 驱动器和数据存储
- SAN和NAS
- SAN存储区域网络
- 在专用网络中包含专用数据模块级的存储 – 具有许多存储设备:磁带库、光盘、磁盘阵列等 – 适用ISCSI协议使得存储展现给操作系统本地磁盘一样 – 大量磁盘适用专用控制器或IP网络来连接各种系统
- NAS网络附加存储
- 使用文件级存储来代替数据块级
- 设计用简单存储和服务文件
- FTP servers
- 共享文件服务器
- 网络驱动器
- NAS同样可以为跨网络的多系统提供存储服务
- RAID 廉价冗余磁盘阵列
- RAID 0(条带化)
- 不具冗余或奇偶校验
- 一块出现故障,整个无法使用,只用于提高性能
- RAID 1(镜像)
- 数据一次性写入两个驱动器,坏了一块还可以用,50利用率
- 冗余
- RAID 2(汉明码奇偶校验)
- 数据按位条带化到所有驱动器上,如今的生产环境已经不再使用
- RAID 3(字节级奇偶校验)
- 数据条带化到所有数据上,奇偶校验数据保存在一个驱动器上,如一个发生故障,则可以从奇偶校验驱动器重建数据
- RAID 4(分组奇偶校验)
- 除了以分组而非字节奇偶校验之外,其他方面与3相同
- RAID 5(间插奇偶校验)
- 数据写入所有的驱动器的磁盘扇区单元,奇偶校验也写入所有驱动器,以确保没有单点失败
- RAID 6(第二奇偶校验数据)
- 与级别5类似,增加了容错功能,他是写入所有驱动器的第二组奇偶校验数据
- RAID 10(条带化和镜像)
- 数据同时在几个驱动器上建立镜像和条带,能够支持多个驱动器故障
- 冗余独立磁带阵列 (RAIT)
- 数据库追踪
- 用于数据库管理系统在多点的记录更新
- 用于远程的完整数据库拷贝
- 分级存储管理HSM
- 提供持续在线备份能力
- 备份和恢复系统
- 备份数据包括关键系统文件和用户数据
- 备份窗口
- 足够大
- 全备
- 不足够大
- 差备或增量备份
- 备份涉及生产系统拷贝数据到远程介质中
- 如将高密度磁带传输或存储到不同的地方
- 至少三个备份磁带
- 原站点
- 恢复单个故障系统
- 近站点
- 主站点遭受了普遍故障,且磁带已损坏
- 远程站点
- 异地站点
- 离主站点的有段距离的安全位置
- 电子传送
- 通过网络备份数据
- 实现镜像
- 主系统的变更实时传送到库服务器中
- 将变更后的文件定期传送到远程站点
- 存储库服务器
- 配置成类似于存储设备
- 与实时更新相反,文件的变更使用增量和差异备份方式传递到存储库
- 日志或交易记录
- 数据库管理系统使用的技术提供交易的冗余
- 人员编制弹性
- 避免关键人员的单点失败
- 足够的人员配备水平
- 适当的培训和教育
- 轮岗培训
灾难恢复流程
- 计划文档化
- 文档应存储在所有的恢复设施里
- 每次测试恢复计划,根据需要进行更新
- 每次测试恢复计划,根据需要进行更新
- 响应
- 事件发生后通报给集中通信团队
- 帮助服务台
- 技术操作中心
- 物理安全人员
- 制定响应计划
- 建立紧急联系名单
- 评估团队,首先通知-确认事件是否需要升级
- 首个升级团队包括:事件所有者、事件响应者以及任何确定破坏类型发生的时间
- 建立通信渠道,建立内外部的可替代通信渠道
- 不要忘记一些服务的不可用,如快递或水电服务
- 高管应急管理团队
- 由组织中的高级管理人员组成
- 不需要做作为初始响应的部分
- 为组织和业务的恢复负有全责
- 事件发生后位于指令中心
- 不需要管理日常运维
- 高管需要响应和协助需要他们指导的问题的解决
- 关注战略响应
- 应急管理团队
- 直接向指令中心汇报
- 具有监控灾难恢复团队,制定恢复和复原流程的职责
- 向高管汇报事件状态
- 制定支持恢复的决策
- 职责
- 对损害进行初步评估。
- 将当前状态、对组织的影响和行动计划通知高级管理层
- 必要时宣布这是灾难
- 在紧急情况下启动计划
- 组织和控制指挥中心,作为恢复工作的中心控制点
- 组织并为恢复工作提供行政支持
- 管理和指导问题管理职能
- 灾难恢复团队
- 检索异地记载和异地存储的恢复信息
- 向异地站点报告
- 按优先级顺序执行恢复过程
- 按需向指挥中心沟通恢复情况
- 识别问题,并报告给管理团队以获取解决方案
- 建立恢复团队支持7*24小时全天候的班次
- 建立关键业务用户和人员联络
- 修复更换设备和必要的软件来恢复正常运营
- 指令中心
- 在紧急状况中用于通信和决策的中心
- 在灾难中,用于响应灾难配备应急响应文档以及其他所需资源
- 也包含处理财物问题的程序
- 初始响应计划
- 组织具有多个位置,则需要为每个业务站点准备一个计划
- 站点中有哪些关键业务或技术
- 为其准备恰当的恢复策略
- 谁是决策者
- 如果不能回到建筑物内,人们应该去哪
- 宣告灾难发生的流程
- 备份站点的位置
- 到达备份站点的差旅方式
- 备份站点的工位分配
- 备份站点附近的酒店\交通服务和后勤服务
- 人事
- 很多计划的问题就是人力资源问题
- 灾难能够极大的影响到人员
- 灾难中组织在响应自己的需求外还需要关注相应团队家庭的艰难状况
- 支持团队成员的水平将由灾难本身的性质明确界定
- 将行政支持作为恢复团队的一部分
- 他们做别人没有时间做的事情 – 接听电话,根 据要求发送通信以与恢复人员沟通, 为恢复人员安排行程, 在恢复地点订购食物, 保存状态会议记录,制作拷贝,安排快递服务,跟踪员工的位置,以及类似的行政和人事相关职能
- 沟通
- 通知员工
- 在紧急状况中由责任管理团队直接联系应急联系名单中的成员 描述组织如何联系剩余成员 建立应急信息线,让员工了解发生的灾难信息,放在员工的工牌后面
- 利益相关者员工及其家属 承包商和商业伙伴 设施和现场经理 人事经理(HR、IT 等) 高级管理人员; 董事会 机构投资者和股东 保险代表 供应商和分销商 顾客 政府监管者和政治家 竞争对手 工会 社区 行业维权组织 互联网用户或博主 媒体代表
- 如何去说
- 在灾难恢复过程中,每个员工应向客户或厂商说的状况是一致的
- 企业应向所有利益相关者提供恢复状态的最新信息是诚实和精准的
- 安全专家需要建立问题报告和管理流程
- 评估
- 在事件中,需要确定事件的影响
- 非事故:损害有效
- 事故:启动应急流程,向管理层汇报
- 严重事故:需要向管理层向高级管理层汇报
- 恢复
- 计划中最后一部分是关于主环境复原以及迁移到正常运行
- 组织的其他部分关注与备用站点组织的复原
- 部分关注恢复到主设施生产环境所需要做的事情
- 复原主站点前需要联系法律部门和保险公司,在采取行动前拍照
- 迁移计划必须记录如何迁移的流程以及操作的细节
- 提供培训
- 不管计划多好如果没人知道就不起作用
- 领导团队:指导危机管理,在灾难恢复中不是执行恢复而是领导组织回归正常
- 技术团队:指导执行恢复的程序、以及他们要去的后勤设备
- 雇员:撤离计划、将一部分BCP计划放到新人培训中
- 演练、评估和维护计划
- DR测试策略
- 业务线和支持职能部门展示业务连续性性测试目标获得的期望,符合BIA和风险评估
- 完成测试的深度和广度的描述
- 员工、技术和设施的范畴
- 内外依存度测试期望
- 评价在开发测试策略中臆测的合理性
- 测试策略包含测试目标和范围
- BCP每年至少测试一次,当重大变更发生时需要进行测试
- 测试目标刚开始可以简单逐渐增加复杂度、参与级别、职能以及物理位置
- 测试不要危及正常业务运行
- 测试展示在模拟危机下各种管理和响应能力,逐渐增加更多的资源和参与者
- 揭示不恰当之处以便修正测试程序
- 考虑偏离测试脚本插入意外事件,比如关键个人或服务的损失
- 包括足量所有类型交易确保恢复设施适当的能力和功能
- 测试策略包含测试计划
- 基于预定的测试范围和目标
- 包含测试计划评审程序
- 包含各种测试场景和方法的开发
- 测试计划
- 主测试计划应包括所有的测试目标
- 测试目标和方法的具体描述
- 所有测试参加者包括支持人员的角色
- 测试参与者的委派
- 测试决策制定者和后续计划
- 测试位置
- 测试升级条件和测试联系信息
- 业务线和支持职能部门展示业务连续性性测试目标获得的期望,符合BIA和风险评估
灾测试计划评审
- 测试战略
- 基于预定的测试范围和目标
- BIA,验证RTO和RPO
- 包含测试计划评审程序
- 包含各种测试场景和方法的开发
- 测试策略
- 由高层制定
- 角色职责,频率、范围和报告结果
- 业务恢复和灾难恢复练习
- 业务恢复
- 关注测试业务线的运行
- 灾难恢复
- 关注技术部分连续性的测试
- 检查清单评审
- BCP拷贝分发给每个关键业务部门的经理
- 请求他们评审适合他们部门的计划部分
- 桌面演练/结构化演练测试 (会议室内可完成,成本低)
- 作为计划初始测试的工具,但不是最好的测试方法
- 目标
- 确保来自所有领域的关键人员熟悉BCP
- 确保计划反应组织从灾难恢复过来的能力
- 特点
- 在 BCP 流程中发挥关键作用的业务部门管理代表和员工的出席情况;
- 讨论 BCP 定义的每个人的责任;
- 个人和团队培训,其中包括 BCP 中概述的逐步程序的演练; 和澄清和突出关键计划元素,以及测试期间发现的问题。
- 排演演练/模拟演练 负责实施 BCP 程序的所有操作和支持人员出席; ■ 特定功能响应能力的实践和验证; ■ 注重知识和技能的展示,以及团队互动和决策能力; ■ 角色扮演在替代地点/设施进行模拟响应,以在非威胁性环境中执行关键步骤、识别困难并解决问题; ■ 动员全部或部分危机管理/响应团队进行适当的协调,而不执行实际的恢复处理; ■ 不同程度的实际通知和资源调动,以加强计划的内容和逻辑。
- 比桌面演练包含的内容更多
- 参加者选择具体的事件场景应用在BCP中
- 功能性测试/并行测试
- 包含真实人员移动到别的站点力图按照BCP规定建立通信和实施真实的恢复流程
- 主要是确定如果人员应用BCP规定中的程序, 关键系统是否能够在备用处理站点恢复DRP
- 特点■ BCP 的全面测试,涉及所有员工; ■ 演示几个小组的应急管理能力,实践一系列互动功能,如指挥、控制、评估、操作和计划; ■ 测试医疗反应和警告程序; ■ 使用实际通信能力对备用位置或设施的实际或模拟响应; ■ 在不同地点调动人员和资源,包括员工测试疏散路线和人员问责程序的疏散演习; ■ 不同程度的实际通知和资源调动,而不是模拟,其中执行并行处理并将交易与生产结果进行比较。
- 完全中断/全面测试 (风险最高)
- 最复杂的测试,尽可能模拟真实的场景,不能影响业务
- 更新和维护计划
- 任何团队都有义务参与变更控制流程
- 计划文档和所有相关程序每三个月检查一次
- 程序的正式审计每年至少一次
- 计划必须控制版本
- 连续性计划方案是正在进行的流程
- 所有定义的任务都要与时俱进与现有环境保持一致
- 必须要有年度要求
- (EMO) 应急管理组织团队的职责 ■ 应对事件和紧急情况 ■ 确定即将发生或实际发生的紧急情况的程度 ■ 建立并保持与高级管理层的沟通 ■ 与员工和客户沟通 ■ 管理媒体通信、安全、系统、设施 ■ 协调和整合业务连续性计划人员
- 正式的管理层响应流程
- 现场覆盖、支持和专业知识
- (EOC)组织紧急行动中心
- 提供位置,不管EMO是否启动提供必要的资源管理组织的恢复
- 组织应急计划小组的职责■ 为所有组织单位制定战略方向和计划,以确保 BC 和有效的应急管理。 ■ 当组织的性质需要时,跨组织单位整合应急计划流程。 ■ 为高级应急经理提供咨询服务和指导。 ■ 协调和整合应急响应组织与组织单位的激活。 ■ 提供定期管理报告和状态。 ■ 确保执行管理层遵守应急计划计划。 ■ 确保所有关键组织功能和要求的识别和维护。 ■ 采购和管理用于支持恢复公司运营(无论是技术还是组织)的备用站点。 ■ 制定、实施和维护政策和指导方针,供所有组织单位遵循。 ■ 为所有应急计划组织制定和维护测试和维护计划。 ■ 为经批准的应急计划工具提供培训、维护和支持。
- 业务连续性计划职责■ 为其职能领域提供主要联系人,以在组织中断期间处理协调响应。 ■ 作为其职责范围内的应急计划工作的资源。 ■ 确保所有应急计划和响应团队的任命、培训和备份。 ■ 协助设计和维护备用站点。 ■ 保持所有应急计划文件的通用性,包括图 7.8 中列出的所有可交付成果。 ■ 项目要求
9、物理及其他安全体系
物理安全-见安全工程
人身安全
- Privacy 隐私
- Travel 出行
- Duress 胁迫
- 胁迫也属于社会工程学攻击
- 安全意识培训中可包含此话题
ISC2道德规范
- 保护社会、公共利益与基础措施,赢得必要的公众信心与信任
- 行事端正、诚实、公众、负责、守法
- 勤奋尽责、专业胜任
- 推动行业发展、维护职业声誉