1. 数据分级与分类
1.1. 分级和分类的目的是为了对不同分级或分类的数据采用不同的防护措施，分级和分类越多，管理成本就越高
1.2. 数据分级通常是按照数据的价值、敏感程度、泄露之后的影响等因素进行分级
1.2.1. 通常分级一旦设定，基本不再变化
1.2.2. 每一个数据分级可对应多个数据分类
1.3. 数据分类通常是按照数据的用途、内容、业务领域等因素进行分类
- 1.3.1. 数据分类可随着业务变化而动态变化
2. 风险评估与定级指南
2.1. 弱点（漏洞等）等级越高，发生风险的概率越高，从而风险越高
2.2. 威胁（黑客、内部人员等）等级越高，发生风险的概率越高，风险越高
2.3. 防护措施（安全加固、防御措施等）越弱，发生风险的概率越高，风险越高
2.4. 前面三个都跟风险发生的概率（可能性，简记为P，即Probability）有关
2.5. 资产价值越高，发生风险后造成的影响越大，从而风险越高
- 2.5.1. 第四个为风险发生后的影响（简记为I，即Impact）
2.6. 业务重要性，决定了风险发生后对企业的影响程度
2.7. 漏洞类型，决定了漏洞被利用的概率，以及被利用后进一步影响其他业务的概率
3. 风险管理要求
3.1. 风险Owner
3.1.1. 风险所有者
3.1.2. 这一角色的确定，对风险管理非常重要，因为*无人认领的风险就意味着风险可能会持续存在
3.1.3. 风险Owner是有责任、有义务管理业务安全风险的业务管理者
3.1.4. 由管理者担任，由上级委派给下级解决，也符合安全工作自上而下推动的原则
3.2. 风险指标
3.2.1. 各种风险等级、各种风险类型的风险数量
3.2.2. 风险收敛的比例和速度
3.3. 风险处置与闭环
3.3.1. 如果发现风险未能得到及时处理，则风险可能酿成安全事件
3.3.2. 遇到风险无法通过管理或技术手段降低的时候，也可以考虑*风险转嫁措施
3.3.3. 风险转嫁，并不是指嫁祸于人，而是业界已经广泛使用的风险规避措施
3.3.4. 购买保险就是最常见的风险转嫁措施
3.3.5. 供应商的失误，给自己所在企业的业务带来的风险，可以通过合同严格区分责任界面，虽然是转嫁给供应商，但供应商为自己的失误买单也是非常合理的
3.3.6. 接受风险的决策，也需要形成文字记录，留存备案
3.4. 事件管理要求
3.4.1. 在处置安全事件时，一个基本的原则是“以快速恢复业务，降低影响为主要目的”，而不是立即找到事件发生的根本原因
3.4.2. 应急响应
3.4.2.1. 应急团队
3.4.2.1.1. 统筹协调，联系业务，事件定级并视严重程度及时同步到相关人员
- 3.4.2.2. 入侵检测与防御团队
3.4.2.2.1. 提取关键日志，定位受损业务，实施拦截策略
- 3.4.2.3. 业务团队
3.4.2.3.1. 采取应急措施，中断入侵行为
3.4.3. 事件定级可决定该事件应该上升到哪一层级，确定卷入的人员、团队范围，以决定是否采取更多的措施
3.4.3.1. 当数据泄露开始在社交媒体传播造成影响时，可及时在官方社交网络账号上同步处置情况，安抚用户，有效防止谣言的产生
3.4.4. 在事件得到控制，风险解除之后，需要开始对事件进行复盘，按时间顺序还原入侵事件的详细入侵路径、所利用的漏洞类型、攻击方法，对其进行研究并找出风险点，给出防御措施，包括业务自身的改进、安全防御系统的策略覆盖或防御规则的升级
3.5. 人员管理要求
3.5.1. 人员包括员工、访客、合作伙伴等，需要遵循、配合相应的安全管理政策、流程
3.5.2. 身份认证
3.5.2.1. 是对访问者身份的确认，是授权、访问控制、审计等其他一切安全机制所赖以信任的基础
3.5.2.2. 身份错了，则后面的一切控制机制就失灵了，因此安全上不能容忍冒用账号的行为
3.5.2.3. 借用他人账号：自己没有权限或权限不够，借用有权限操作的相关人员的账号
3.5.2.4. 出借自己的账号给他人（含代为输入口令）：他人没有权限或权限不够，将自己的账号口令告知他人（或代为输入）
3.5.2.5. 正确的做法是，如果确属业务需要，员工访问业务系统不具有相应权限或权限不足时，应该通过正规的渠道，申请相应的权限
3.5.3. 授权
3.5.3.1. 对敏感业务的授权，在满足最小化授权的基础上，还需要体现出SOD、授权与行权分离的原则，不要授予同一个员工多个彼此协作的权限
3.5.3.2. SOD是指权限分离（Separation of Duty）
3.5.3.2.1. 在一人承担多个重要角色时，往往可能导致授权漏洞的发生
3.5.3.3. 授权与行权分离是指负责审批权限的人不能执行，即不能审批自己提交的权限或业务单据审核
3.5.4. 访问控制
3.5.4.1. 需要防止员工从事恶意行为
3.5.4.2. 后门程序是可绕过正常的身份认证、授权、访问控制、审计机制，执行高权限操作的相关程序
3.5.4.2.1. 私建的后台管理入口
3.5.4.2.2. 私建的任意操作系统命令执行入口或任意SQL指令入口
3.5.4.2.3. 其他特权指令
3.5.5. 可审计
3.5.5.1. 内部的一些安全机制，通常也会占用一部分系统资源
3.5.5.2. 有的业务团队为了降低这部分资源消耗，可能会破坏、干扰、屏蔽各种安全监控系统或安全工具的运作
3.5.5.2.1. 屏蔽企业内部的扫描器
3.5.5.2.2. 停止HIDS入侵检测服务
3.5.6. 资产保护
3.5.6.1. 经审核私自对外开源
3.5.6.1.1. 损害了公司的知识产权
3.5.6.1.2. 配置文件中敏感数据泄露
3.5.6.2. 主动泄露内部信息到外部
3.5.6.3. 安装高危软件
3.5.6.4. 随意处置或丢弃敏感文档等
3.5.6.5. 个人持有生产环境的敏感数据副本
3.5.6.5.1. 生产环境的敏感数据，除了正常的业务使用之外，不应该直接以数据源本身存在的原始形式流出生产环境
3.5.6.6. 未经授权使用其他业务敏感数据
3.5.6.7. 拒绝打补丁或修复漏洞
3.5.6.7.1. 打补丁及修复漏洞，对于防止安全事件的发生非常重要，需要明确谁对此事负责，及时打上补丁或修复漏洞
3.6. 配置和运维管理
3.6.1. 配置管理
3.6.1.1. 不是指该如何设定业务系统的各种配置文件或加固措施，而是在CMDB（配置管理数据库）中登记与维护更新，维护CMDB的及时性和准确性，并将CMDB作为安全监测的数据源
3.6.1.2. 在小型企业，配置管理可能并不是刚需
3.6.1.2.1. 对于大中型企业来说，CMDB就必不可少
3.6.1.3. 不仅记录了企业有多少设备
3.6.1.4. 还记录了我们开展安全工作所必需的数据
3.6.1.4.1. IP地址，可以作为主机层安全扫描的数据源输入，可以作为该地址是否存在敏感数据的标记
3.6.1.4.2. 使用的域名，可以在发生安全事件后第一时间根据域名找到相应的业务团队
3.6.1.4.3. 操作系统、容器类型及版本，可以在第一时间基于威胁情报，统计出哪些设备需要紧急打上系统安全补丁，防止漏洞被外部利用
3.6.1.4.4. 服务端口，没有登记的端口将被视为可疑的行为（可能来自黑客、木马等）
3.6.1.5. CMDB记录的数据不完整或不及时更新，也将在很大程度上影响企业的安全防御能力
3.6.1.6. CMDB记录的数据粒度越细，则维护CMDB的成本越高
3.6.1.7. 一些公司CMDB只登记最基本的信息，其他安全工作所需要的信息几乎全部采用安全组件自动采集的方式来完成
3.6.1.8. 具体记录哪些信息，需要根据管理和业务的需要进行权衡
3.6.2. 运维管理
3.6.2.1. 即规范运维操作，如使用自动化运维管理平台或跳板机、只从内部源部署开源组件、执行安全加固等
3.6.2.2. 将自动化运维能力的提升作为改进的方向
3.6.2.2.1. 建立自动化运维的基础设施，让日常的例行运维操作都通过自动化运维平台来实现，如批量脚本发布、文件发布、内容发布等
3.6.2.2.2. 建立通用的服务基础设施，如统一接入、数据服务，让业务不再单独部署自己的Web服务器或数据库服务器等通用服务
3.6.2.2.3. 引导业务尽可能地将日常操作纳入自动化运维平台
3.6.2.3. 只有在自动化运维能力覆盖不到的场景下，才使用第二选择：通过跳板机进行运维，以及执行运维审计
3.6.2.4. 运维人员资质要求，如仅限正式员工运维
3.6.2.5. 流程上的要求，如经过安全扫描或代码审计，无高危漏洞才能发布
3.6.2.6. 域名管理与登记，特别是企业存在多个顶级域名的情况下，需要对域名用途进行限定
3.6.2.7. 部署区域要求，企业一般存在多个网络安全域，该如何部署（如是否强制要求通过HTTPS网关统一接入），应有规范约定
3.6.2.8. 对使用开源组件的要求
3.6.2.9. 按照已发布的安全配置规范进行加固，包括补丁以及病毒防护要求
3.6.2.10. 是否启用WAF、HIDS等安全防御设施
3.7. 业务连续性管理
3.7.1. BCM, Business Continuity Management
3.7.2. 是为了应对各种天灾人祸等异常情况而采取的预防性管理与技术措施
3.7.3. 自然灾害：地震、台风、海啸、洪水、火灾等
3.7.4. 人为灾害：黑客入侵、网络DDoS攻击、内部破坏或泄露数据等
3.7.5. 其他如供电中断、硬件故障、软件故障等导致的服务中止
3.7.6. 异地热备高可用方案
3.7.6.1. 在面临天灾如地震、海啸等情况下，可能会出现整个机房不可用的情况，这时就需要为重要的业务建立异地灾备机制
3.7.6.2. 安全防御基础设施、安全组件与支持系统（SSO、权限管理等）为大量业务所共同依赖，因此也需要提前建立异地容灾机制
3.7.7. 应急预案
3.7.7.1. 在出现漏洞报告、黑客入侵、DDoS攻击、数据泄露事件后，需要启用应急响应，以尽快恢复业务为首要目标，再来总结分析背后的原因
3.7.7.2. 卷入相关业务团队，共同应对
3.7.7.3. 止损：能止损的场景立即止损，如切断入侵路径、封禁相关IP、通知用户修改口令、回滚恶意的操作或交易等
3.7.7.4. 溯源与风险评估：包括漏洞利用或入侵的全过程（时间点和操作），评估受影响的范围
3.7.7.5. 事件总结与改进优化：改进业务缺陷、优化安全防御策略等
3.7.8. 数据备份与恢复演练
3.7.8.1. 没有备份
3.7.8.2. 备份不完整，无法使用备份的数据恢复业务
3.7.8.3. 备份未经恢复测试验证，不确定能否基于该备份恢复业务
