CNITSEC CISM cheat sheet

治理(Governance)决定“做什么、谁负责”，管理(Management)负责“怎么做、做到什么程度”。治理由董事会/高层负责，管理由管理层执行。

ISO/IEC 27001 要求最高管理者通过方针、角色职责、管理评审和资源保障来证实领导力与承诺(Leadership and Commitment)，治理职责不可委托给IT部门。

三道防线模型(Three Lines Model)：第一道为业务/运营管理，第二道为风险与合规等监督职能，第三道为内部审计。内部审计必须独立于第一、二道。

安全方针(Security Policy)由最高管理者批准发布，须包含目标、承诺、职责框架和持续改进要求；方针是强制性的，标准/指南(Standard/Guideline)是支持性文件。

CIA 三要素：机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)；扩展属性包括不可否认性(Non-repudiation)、可问责性(Accountability)和真实性(Authenticity)。

安全角色分离(Segregation of Duties)：开发与生产运维、审批与执行、安全审计与被审计岗位不得由同一人兼任，以降低欺诈与错误风险。

关键绩效指标(KPI)衡量过程有效性，关键风险指标(KRI)衡量风险暴露趋势；治理层通过KPI/KRI仪表板进行监督和决策。

安全战略须与业务战略对齐(Business Alignment)；安全投入的合理性以风险降低和业务价值论证，而非单纯技术先进性。

安全治理框架常用参照：ISO/IEC 27014（信息安全治理）、COBIT（IT治理）、NIST CSF（识别-保护-检测-响应-恢复）。

风险(Risk) = 威胁(Threat) × 脆弱性(Vulnerability) × 资产价值(Asset Value)；常用公式：风险 = 可能性(Likelihood) × 影响(Impact)。

风险评估流程：资产识别 → 威胁识别 → 脆弱性识别 → 现有控制评估 → 可能性与影响赋值 → 风险值计算 → 风险等级排序。

风险处置四选项：降低/缓解(Mitigate)、转移(Transfer，如保险或外包)、规避(Avoid)、接受(Accept)；残余风险(Residual Risk)必须由资产所有者或业务负责人正式接受。

风险偏好(Risk Appetite)是组织愿意承担的风险总量；风险容忍度(Risk Tolerance)是可接受的偏差范围；风险容量(Risk Capacity)是组织能承受的最大风险。

定性评估使用高/中/低等级，适合快速排序；定量评估使用ALE = SLE × ARO（年化损失期望 = 单次损失期望 × 年发生频率），适合成本效益分析。

风险登记册(Risk Register)至少记录：风险描述、资产、威胁、脆弱性、现有控制、可能性、影响、风险等级、处置措施、责任人、截止日期、残余风险。

ISO/IEC 27005 与 NIST SP 800-30 是主流风险评估方法论；风险评估须在重大变更、新系统上线及定期（如每年）重复进行。

风险处置计划需明确控制措施、成本、时间表和责任人；控制实施后应重新评估以确认残余风险在容忍度内。

威胁建模(Threat Modeling)常用 STRIDE（仿冒、篡改、否认、信息泄露、拒绝服务、权限提升）识别设计阶段风险。

ISO/IEC 27001 采用 PDCA 循环：Plan（建立ISMS与风险评估）、Do（实施控制）、Check（监视、测量、内部审核、管理评审）、Act（纠正与持续改进）。

ISMS 核心文件：适用范围(Scope)、信息安全方针、风险评估与处置方法、风险处置计划、适用性声明(SoA)、内部审核报告、管理评审记录。

适用性声明(Statement of Applicability, SoA)必须列出 ISO/IEC 27001 附录A全部控制项，说明是否适用、理由及实施状态，是审核重点。

ISO/IEC 27001 认证分两阶段审核：第一阶段审核体系文件与准备情况，第二阶段审核实施有效性；证书有效期三年，需进行监督审核（通常每年一次）。

管理评审(Management Review)由最高管理者主持，输入包括审核结果、风险状况、事件统计、法规变化；输出包括改进决定和资源需求。

内部审核(Internal Audit)须由独立于被审核活动的人员执行，审核方案应考虑过程重要性、变更和以往审核结果。

ISO/IEC 27002 是控制措施实施指南（原为行为准则），27001 是要求标准；27003 为实施指南，27004 为测量，27005 为风险管理。

不符合项(Nonconformity)分严重与一般；纠正措施(Corrective Action)须分析根本原因并验证有效性，不能只做纠正(Correction)。

ISMS 范围界定须考虑内外部问题、相关方要求、接口与依赖关系；范围变更须重新评估风险并更新SoA。

控制分类：预防性(Preventive)、检测性(Detective)、纠正性(Corrective)、威慑性(Deterrent)、补偿性(Compensating)；按性质分管理、技术、物理三类。

访问控制模型：DAC（自主，所有者授权）、MAC（强制，基于标签与许可级别）、RBAC（基于角色）、ABAC（基于属性）。最小权限与知其所需(Need-to-Know)为基本原则。

身份认证三因子：所知(密码)、所有(令牌/证书)、所是(生物特征)；多因子认证(MFA)须使用不同类别因子。

加密：对称算法 AES（128/192/256位）、非对称 RSA/ECC 用于密钥交换与签名、哈希 SHA-256/SHA-3 用于完整性；哈希不加盐易受彩虹表攻击。

PKI 信任链：根CA → 中间CA → 终端实体证书；证书吊销通过 CRL 或 OCSP；数字签名提供完整性、身份认证与不可否认性，不提供机密性。

网络边界控制：防火墙（包过滤/状态检测/应用层）、IDS（检测告警）、IPS（检测并阻断）、WAF（Web应用防护）、DMZ 隔离对外服务。

纵深防御(Defense in Depth)要求多层互补控制，避免单点失效；控制选择应基于风险评估结果，而非产品流行度。

日志与监控：集中化日志(SIEM)须保证时间同步(NTP)、日志完整性与保留期限；特权账户活动必须重点审计。

业务连续性与灾难恢复：RTO（恢复时间目标）、RPO（恢复点目标）、MTD（最大可容忍中断时间）；备份遵循 3-2-1 原则并定期演练恢复。

事件响应六阶段（NIST SP 800-61）：准备 → 检测与分析 → 遏制、根除与恢复 → 事后活动；准备阶段决定响应能力上限。

事件(Incident)与事件(Event)不同：Event 是可观察到的系统行为，Incident 是已对CIA造成或可能造成影响的事件集合。

遏制策略分短期（隔离主机、断网、封禁IP）与长期（打补丁、重建系统）；遏制前须评估证据保全需求。

证据保全(Chain of Custody)：记录谁在何时何地以何方式接触证据；取证镜像须使用写保护设备并计算哈希校验值。

事件分级依据影响范围、数据敏感度、业务中断程度和法规上报要求；分级决定上报层级与响应时限。

变更管理：所有变更须经申请、风险评估、审批、测试、实施、回滚计划与验证；紧急变更事后须补审批。

问题管理(Problem Management)关注根本原因消除，事件管理关注尽快恢复服务；二者输出应反馈至风险管理。

服务台与安全运营中心(SOC)协同：一线分诊、二线分析、三线取证/工程；升级路径(Escalation Path)须预先定义并演练。

事后复盘(Lessons Learned)须在事件关闭后短期内完成，输出改进项并纳入风险登记册与演练计划。

《中华人民共和国网络安全法》确立网络运营者安全保护义务、关键信息基础设施(CII)保护、网络实名制与事件报告要求。

《数据安全法》建立数据分类分级保护制度，重要数据出境须依法进行安全评估；《个人信息保护法》规定处理个人信息的合法性基础、告知同意与个人权利。

个人信息保护法要求：最小必要原则、单独同意（敏感个人信息）、跨境传输三条路径（安全评估、认证、标准合同），以及个人信息保护影响评估(PIA)。

《网络安全等级保护条例》(等保2.0)将系统分为五级，一级最低、五级最高；三级及以上须每年测评一次，二级建议两年一次。

《关键信息基础设施安全保护条例》要求CII运营者设立专门安全管理机构、进行年度检测评估并报告重大事件。

网络安全事件报告：运营者应在发现后立即采取补救措施，并按规定向主管部门报告；迟报、瞒报、漏报须承担法律责任。

合规框架包括 ISO/IEC 27001、ISO/IEC 27701（隐私）、等级保护、GDPR（如涉及欧盟数据主体）；合规是基线，不等于安全充分。

数据生命周期合规：收集（合法正当必要）、存储（加密与期限）、使用（权限与审计）、共享（合同与审批）、销毁（不可恢复）。

审计与证据：合规证据须可追溯、可验证、有时效；第三方服务商须通过合同明确安全责任与审计权。