NIST
NIST
NIST SP 800-53 Rev.5 – The Controls
1. AC — Access Control（访问控制）
AC-1 Policy and Procedures：制定访问控制策略和流程。
例：每年更新访问控制政策并发布。AC-2 Account Management：用户账户生命周期管理。
例：定期审核所有用户账户并禁用离职账户。AC-3 Access Enforcement：执行访问控制策略。
例：通过 RBAC 限制不同岗位对系统资源的访问。AC-4 Information Flow Enforcement：信息流控制。
例：部署网络分段策略隔离敏感数据流。AC-5 Separation of Duties：职责分离。
例：审批与批准操作分别由不同角色执行。AC-6 Least Privilege：最小权限。
例：普通员工按最小权限访问业务系统。AC-7 Unsuccessful Login Attempts：失败登录处理。
例：5 次错误登录后锁定用户账户。AC-8 System Use Notification：登录提示通知。
例：登录前显示合法使用声明提醒。AC-9 Previous Logon (Access) Notification：上次登录提示。
例：登录时显示上次登录的时间与 IP。AC-10 Concurrent Session Control：并发会话控制。
例：每个账号最多允许 1 个并发会话。AC-11 Session Lock：会话锁定机制。
例：10 分钟无操作就自动锁屏。AC-12 Session Termination：会话自动终止。
例：超过最大空闲时间后自动登出。AC-13 Supervision and Review—Access Control：访问审核与监督。
例：每季度审查访问日志和例外情况。AC-14 Permitted Actions without Identification or Authentication：未认证允许操作。
例：访客网络仅限访问互联网资源。AC-15 Automated Marking：自动标记信息。
例：敏感文件自动添加分类标签。AC-16 Security Attributes：安全属性处理。
例：根据数据分类动态调整访问权限。AC-17 Remote Access：远程访问管理。
例：远程访问必须通过 VPN 并启 MFA。AC-18 Wireless Access：无线接入控制。
例：内部 Wi‑Fi 仅支持企业认证 WPA3。AC-19 Access Control for Mobile Devices：移动设备控制。
例：启用 MDM 并限制存储本地敏感数据。AC-20 Use of External Information Systems：外部系统访问限制。
例：禁止使用个人设备访问内部系统。AC-21 User-Based Collaboration and Information Sharing：用户级信息共享。
例：根据业务需求授予文件共享权限并审计。AC-22 Publicly Accessible Content：公开内容发布控制。
例：发布到网站内容需安全团队审核。AC-23 Data Mining Protection：数据挖掘防护。
例：限制批量导出敏感数据行为。AC-24 Access Control Decisions：访问控制决策逻辑。
例：基于策略引擎统一评估访问请求决策。AC-25 Reference Monitor：访问监控机制。
例：使用内核级参考监控完整性检查访问控制实施。
2. AT — Awareness and Training（意识与培训）
AT-1 Policy and Procedures：制定安全意识和培训策略与流程。
例：每年制定并更新员工安全与隐私意识培训策略，并发布执行说明。AT-2 Literacy Training and Awareness：为所有用户（包括管理层和承包商）提供安全及隐私基础培训和意识课程。
例：新员工入职安全培训包括基本网络安全、社工防范与数据使用准则。AT-3 Role-Based Training：针对不同角色提供安全与隐私职责相关的培训。
例：开发团队接受安全编码规范、OWASP Top 10 相关风险培训。AT-4 Training Records：维护和存储安全与隐私培训记录。
例：HR 或 LMS 系统记录每位员工完成培训日期、内容与成绩。AT-5 Contacts with Security Groups and Associations：与安全组织及行业协会保持联系以提升意识。
例：安全团队定期参与 ISACA、OWASP 会议并分享最新威胁情报。AT-6 Training Feedback：收集培训反馈以改进内容与效果。
例：每次安全培训结束后发放问卷收集改进建议。
3. AU — Audit and Accountability（审计与可追责）
AU-1 Policy and Procedures：制定审计与可追责策略和流程。
例：制定企业审计策略并设定审计周期与责任。AU-2 Audit Events (Event Logging)：定义和记录需要审计的事件。
例：记录管理员登录、权限变更和敏感数据访问事件。AU-3 Content of Audit Records：规定审计日志应包含的信息内容。
例：每条日志记录包括用户、时间、操作和来源。AU-4 Audit Log Storage Capacity：管理审计日志存储容量。
例：设置日志服务器存储、轮换和容量告警。AU-5 Response to Audit Logging Process Failures：处理审计记录失败。
例：日志写入失败时触发告警并保存本地备份。AU-6 Audit Record Review, Analysis, and Reporting：审计日志审查、分析与报告。
例：每周分析异常登录与权限提升行为。AU-7 Audit Record Reduction and Report Generation：生成审计报告与数据摘要。
例：自动生成月度审计摘要供管理层审阅。AU-8 Time Stamps：确保审计记录时间戳准确和统一。
例：所有服务器通过 NTP 同步时间戳。AU-9 Protection of Audit Information：保护审计信息的完整性和机密性。
例：对审计日志加密并限制访问权限。AU-10 Non-repudiation：提供操作不可否认性机制。
例：使用数字签名防止关键操作日志被篡改。AU-11 Audit Record Retention：审计记录保留策略与期限。
例：关键系统日志保留 1 年以上。AU-12 Audit Record Generation：自动生成审计日志。
例：系统自动记录所有失败登录尝试。AU-13 Monitoring for Information Disclosure：监控信息泄露审计事件。
例：审计未授权数据访问或传输事件。AU-14 Session Audit：会话级审计控制。
例：记录用户会话建立和结束事件。AU-15 Alternate Audit Logging Capability：备用审计日志功能。
例：主日志服务故障时备份日志服务继续记录。AU-16 Cross‑Organizational Audit Logging：跨组织审计日志协同。
例：合作机构间共享审计信息并保留来源身份。
3.4 CA — Assessment, Authorization, and Monitoring（评估、授权与监控）
CA-1 Policy and Procedures：制定评估、授权和监控策略与流程。
例：发布年度安全评估政策，并分配责任人。CA-3 Information Exchange：管理系统间信息交换的安全。
例：审批部门间数据共享，确保加密和访问控制。CA-4 Security Certification：对系统进行安全认证。
例：新系统上线前完成安全认证，确保符合标准。CA-5 Plan of Action and Milestones (POA&M)：制定整改计划。
例：发现安全缺陷后记录整改措施和时间表。CA-6 Authorization：系统授权与审批管理。
例：系统上线前安全授权审批并记录批准流程。CA-8 Penetration Testing：定期进行渗透测试。
例：每年对关键系统执行红队测试，发现潜在风险。CA-9 Internal System Connections：监控内部系统互联安全。
例：审查内部 API、服务访问权限及日志记录。
3.5 CM — Configuration Management（配置管理）
CM-1 Policy and Procedures：制定配置管理策略与流程。
例：发布年度配置管理政策，并指定负责人。CM-2 Baseline Configuration：建立系统基线配置。
例：记录所有服务器的标准操作系统和应用配置。CM-3 Configuration Change Control：管理配置变更流程。
例：所有系统更新需提交变更请求审批。CM-4 Impact Analyses：分析配置变更的安全影响。
例：更新数据库前评估安全和业务影响。CM-5 Access Restrictions for Change：限制变更操作权限。
例：仅授权管理员才能修改生产系统配置。CM-6 Configuration Settings：管理系统配置设置。
例：禁用不必要的端口和服务。CM-7 Least Functionality：最小功能原则。
例：仅启用系统所需功能模块。CM-8 System Component Inventory：维护系统组件清单。
例：记录硬件、软件及固件版本信息。CM-9 Configuration Management Plan：制定配置管理计划。
例：详细描述如何管理、监控和维护系统配置。CM-10 Software Usage Restrictions：限制软件使用。
例：禁止在生产环境安装未经授权软件。CM-11 User-Installed Software：控制用户自行安装软件。
例：用户安装软件需经过审批。CM-12 Information Location：管理信息存储和位置。
例：敏感数据仅存储在受控服务器。CM-13 Data Action Mapping：记录数据操作映射。
例：记录数据库表与访问操作对应关系。CM-14 Signed Components：验证组件签名和完整性。
例：系统更新包必须包含官方数字签名。
3.6 CP — Contingency Planning（应急规划）
CP-1 Policy and Procedures：制定应急规划政策和流程，明确目的、范围、职责与合规要求。
例：发布组织级应急响应政策，协调跨部门协作，每年更新并同步至相关人员。CP-2 Contingency Plan：制定系统应急计划，涵盖核心业务功能、恢复目标、角色职责与系统恢复流程。
例：编制业务连续性计划与灾难恢复计划，明确关键系统恢复优先级，分发至应急响应团队。CP-3 Contingency Training：为相关人员提供应急职责培训，确保掌握应急流程与操作。
例：新员工入职后开展应急流程培训，每季度组织应急响应团队进行桌面推演。CP-4 Contingency Plan Testing：定期测试应急计划有效性，识别不足并整改。
例：每年执行一次全流程灾难恢复演练，每半年开展一次关键功能恢复测试。CP-5 Contingency Plan Update：根据测试结果、系统变更或实际应急事件，更新应急计划。
例：演练结束后 30 日内修订计划漏洞，系统重大升级后同步更新应急流程。CP-6 Alternate Storage Site：建立备用存储站点，确保备份信息的存储与检索，控制等效于主站点。
例：核心数据实时同步至异地备用存储，签订存储服务协议保障访问权限。CP-7 Alternate Processing Site：建立备用处理站点，确保主站点不可用时快速恢复核心业务运行。
例：租用同城灾备机房，配置与主站点一致的硬件资源，签订优先级服务协议。CP-8 Telecommunications Services：建立备用通信服务，保障主通信链路中断时的业务连续性。
例：部署双运营商专线，配置 VPN 备用链路，确保应急状态下通信不中断。CP-9 System Backup：定期备份用户级、系统级信息及相关文档，保护备份信息的机密性、完整性和可用性。
例：核心系统每日执行全量备份+增量备份，备份数据加密存储，保留周期符合业务要求。CP-10 System Recovery and Reconstitution：在规定时间内将系统恢复并重构至已知安全状态。
例：明确系统恢复时间目标（RTO），采用快照回滚、数据恢复等方式快速恢复系统。CP-11 Alternate Communications Protocols：提供备用通信协议，保障应急状态下的通信连续性。
例：配置备用网络通信协议，在主协议故障时自动切换，不影响核心业务数据传输。CP-12 Safe Mode：系统检测到特定异常条件时，进入预设的安全运行模式。
例：系统遭遇恶意攻击或硬件故障时，自动进入仅保留核心功能的安全模式，限制非必要操作。CP-13 Alternative Security Mechanisms：部署备用或补充安全机制，确保主安全机制不可用时的基本防护。
例：主防火墙故障时，自动启用备用访问控制机制，限制外部非授权访问。
3.7 IA — Identification and Authentication（标识与认证）
IA-1 Policy and Procedures：制定标识与认证政策和流程，明确目的、范围、角色职责与合规要求。
例：发布组织统一的身份认证管理政策，涵盖内外部用户认证标准，每年 review 并更新。IA-2 Identification and Authentication (Organizational Users)：对组织内部用户进行唯一标识与认证，关联用户身份与系统进程。
例：为每位员工分配唯一工号作为系统登录标识，采用“密码+硬件令牌”多因素认证访问核心系统。IA-3 Device Identification and Authentication：对组织定义的设备/设备类型进行唯一标识与认证，再建立本地、远程或网络连接。
例：服务器、网络设备采用数字证书认证，禁止使用默认密码，物联网设备通过设备唯一序列号+加密密钥进行身份验证。IA-4 Identifier Management：管理系统标识，包括授权分配、标识符选择、防止重复使用等。
例：新员工入职需经部门主管授权方可分配系统标识符，员工离职后标识符保留 90 天后方可重新分配。IA-5 Authenticator Management：管理系统认证凭证，包括初始分发、内容保护、定期更换、丢失处理等。
例：密码需满足至少 12 位长度（含大小写、数字、特殊字符），每 90 天强制更换，丢失的硬件令牌需 24 小时内注销并补发。IA-6 Authentication Feedback：在认证过程中隐藏认证信息反馈，防止未授权人员利用。
例：登录失败时仅提示“账号或密码错误”，不明确指出具体错误项，密码输入时以星号（*）隐藏显示。IA-7 Cryptographic Module Authentication：实现符合适用法规标准的加密模块认证机制。
例：使用符合 FIPS 140-3 标准的加密模块，对管理员访问加密设备进行身份认证。IA-8 Identification and Authentication (Non-Organizational Users)：对非组织用户或其代理进程进行唯一标识与认证。
例：合作伙伴用户采用“一次性验证码+手机号验证”双因素认证，访客用户仅分配临时标识，限制访问范围。IA-9 Service Identification and Authentication：对组织定义的系统服务和应用进行唯一标识与认证，再与设备、用户或其他服务建立通信。
例：微服务间通过 API 密钥+数字签名进行身份认证，第三方服务接入需通过 OAuth 2.0 协议完成认证授权。IA-10 Adaptive Authentication：要求用户在特定情况下采用补充认证技术或机制。
例：用户在非常用设备、异地登录时，自动触发人脸识别补充认证；访问敏感数据时需额外输入动态口令。IA-11 Re-Authentication：在组织定义的场景或情况下，要求用户重新认证。
例：用户会话空闲超过 30 分钟后访问敏感功能需重新登录，执行权限变更、数据导出等操作前强制二次认证。IA-12 Identity Proofing：基于适用标准和指南的身份保障级别要求，对需要逻辑访问系统的用户进行身份核验。
例：新员工入职时需提交身份证、工牌等材料进行线下身份核验，远程入职用户通过视频认证+官方证件核验完成身份 proofing。3.8 IR — Incident Response（事件响应）
IR-1 Policy and Procedures：建立事件响应的政策与流程框架，明确管理规则、角色及职责边界。
例：发布组织级事件响应政策文档，界定安全团队、业务部门的响应职责，每年评审更新。IR-2 Incident Response Training：为相关人员提供事件响应技能培训，确保掌握识别、处置事件的能力。
例：每季度组织响应团队开展实操培训，新员工入职纳入事件识别与上报流程培训。IR-3 Incident Response Testing：定期测试事件响应能力，验证计划有效性并优化不足。
例：每年开展全流程模拟演练，每半年针对单一场景进行桌面推演。IR-4 Incident Handling：执行事件全流程处置，覆盖检测、遏制、根除、恢复等环节。
例：部署 SIEM 系统监测异常，发现攻击后立即隔离受影响资产，清除威胁后恢复服务。IR-6 Incident Reporting：建立事件上报机制，确保事件信息及时传递至对应责任方。
例：普通事件 1 小时内上报安全团队，重大事件 30 分钟内同步至管理层与监管机构。IR-7 Incident Response Assistance：协调内外部资源，为事件处置提供技术、流程等支持。
例：与安全厂商签订应急协作协议，事件发生时联合开展威胁溯源与处置。IR-8 Incident Response Plan：制定正式事件响应计划，明确处置流程、资源需求与恢复策略。
例：编制分场景响应子计划，明确不同级别事件的启动条件与 RTO/RPO 目标。IR-9 Information Spillage Response：针对敏感信息泄露制定专项响应流程，降低信息扩散风险。
例：建立敏感数据泄露应急方案，包含数据溯源、扩散阻断、受影响范围评估等步骤。3.9 MA — Maintenance（维护）
MA-1 Policy and Procedures：建立系统维护的政策与流程，明确维护活动的管理规则、职责与合规要求。
例：发布维护管理政策，界定运维团队、安全团队在维护活动中的审批与执行权限，每年更新。MA-2 Controlled Maintenance：对系统维护活动进行管控，包括维护前审批、过程监控与维护后验证。
例：生产系统的维护操作需提交变更申请，经安全团队审核后执行，维护后验证系统运行状态。MA-3 Maintenance Tools：管理维护工具的使用，确保工具的安全性、合规性，避免引入风险。
例：维护工具需经过安全检测后入库管理，仅授权运维人员可申请使用，禁止使用未认证的第三方工具。MA-4 Nonlocal Maintenance：管控远程维护活动，包括身份认证、通信加密与操作审计。
例：远程维护必须通过 VPN+多因素认证接入，操作过程全程日志记录，维护结束后关闭远程权限。MA-5 Maintenance Personnel：对维护人员进行管理，包括资质审核、权限控制与操作培训。
例：维护人员需通过安全资质认证方可上岗，按最小权限原则分配维护操作权限，定期开展安全培训。MA-6 Timely Maintenance：及时执行系统维护活动（如补丁更新、故障修复），降低安全与业务风险。
例：高危漏洞补丁在发布后 72 小时内完成部署，普通故障修复在 24 小时内响应处理。MA-7 Field Maintenance：管控现场维护活动，包括人员身份核验、操作监督与数据保护。
例：第三方人员现场维护时，需由内部人员全程陪同，禁止携带存储设备，维护后清除操作痕迹。
3.10 MP — Media Protection（介质保护）
MP-1 Policy and Procedures：建立介质管理的政策与流程，明确介质全生命周期的管控要求。
例：发布介质保护政策，覆盖介质的采购、使用、存储、运输、销毁等环节，明确各环节责任部门。MP-2 Media Access：管控介质的访问权限，仅授权人员可接触、使用敏感介质。
例：存储核心数据的介质需存放在加密柜中，访问需双人授权，记录介质的取用与归还信息。MP-3 Media Marking：对介质进行标识，明确介质的分类、敏感级别与管理要求。
例：敏感介质表面标注“机密”“内部使用”等标识，电子介质中嵌入分类标签元数据。MP-4 Media Storage：安全存储介质，根据介质敏感级别采取对应的物理与逻辑防护措施。
例：机密级介质存放在防火、防水的物理保险柜中，电子介质存储时启用加密与访问控制。MP-5 Media Transport：安全运输介质，防止运输过程中介质丢失、泄露或损坏。
例：跨区域运输敏感介质需使用加密包装，由专人押运，运输全程记录轨迹与交接信息。MP-6 Media Sanitization：对废弃或不再使用的介质进行安全清除，确保介质中的信息无法被恢复。
例：电子介质采用符合 NIST 标准的消磁、加密擦除方式处理，纸质介质进行粉碎或焚烧销毁。MP-7 Media Use：规范介质的使用行为，避免介质被滥用或用于未授权场景。
例：禁止在非受控设备上使用敏感介质，禁止将介质内容复制到个人设备，使用后及时归还存储。MP-8 Media Downgrading：对介质进行降级处理，确保降级后介质的敏感级别与内容匹配。
例：介质内容从“机密”降级为“内部”时，需经安全团队审核，清除介质中超出降级后级别的信息。
3.11 PE — Physical and Environmental Protection（物理与环境防护）
PE-1 Policy and Procedures：建立物理与环境防护的政策和流程，明确防护范围、职责与合规要求。
例：发布数据中心物理安全管理政策，覆盖门禁、监控、消防等环节，每年评审更新。PE-2 Physical Access Authorizations：对物理区域的访问进行授权管理，明确不同区域的访问权限。
例：数据中心核心机房仅授权运维主管访问，办公区按部门分配门禁权限，定期清理失效授权。PE-3 Physical Access Control：通过物理措施（如门禁、锁具）控制对敏感区域的访问。
例：数据中心入口部署生物识别门禁，机房通道设置双重门禁，非授权人员无法单独进入。PE-4 Access Control for Transmission：管控物理传输通道的访问，防止未授权接入或篡改。
例：通信线缆布放在加密管道中，传输机房设置单独门禁，禁止无关人员接触传输设备。PE-5 Access Control for Output Devices：管控物理输出设备（如打印机、复印机）的访问与使用。
例：敏感文档打印机仅授权指定人员使用，输出文件需凭取件码领取，设备启用审计日志。PE-6 Monitoring Physical Access：对物理区域的访问进行监控记录，及时发现异常行为。
例：数据中心部署无死角监控摄像头，监控录像保存 90 天以上，异常门禁刷卡触发实时告警。PE-7 Visitor Control：管控访客的物理访问，包括身份核验、陪同管理与权限限制。
例：访客需经内部人员邀约，核验身份后发放临时门禁卡，全程由邀约人陪同，禁止进入敏感区域。PE-8 Visitor Access Records：记录访客的访问信息，包括访问时间、区域与陪同人员。
例：访客登记系统记录姓名、单位、访问事由等信息，访问结束后回收临时门禁卡并归档记录。PE-9 Power Equipment and Cabling：保护电力设备与线缆的安全，确保供电稳定与物理防护。
例：供电设备部署在独立机房，线缆采用防火、防篡改材质，定期检测电力系统运行状态。PE-10 Emergency Shutoff：设置紧急断电装置，在突发情况下快速切断电源以降低风险。
例：数据中心机房配备紧急断电按钮，仅授权安全人员操作，触发后同步告警至监控中心。PE-11 Emergency Power：配置应急供电系统，保障关键设备在断电后的持续运行。
例：数据中心部署 UPS 不间断电源，支持核心设备运行 4 小时以上，同时配备备用发电机。PE-12 Emergency Lighting：设置应急照明系统，确保紧急情况下人员安全疏散与操作。
例：机房、疏散通道安装应急照明灯，断电后自动启动，照明时长不低于 90 分钟。PE-13 Fire Protection：部署消防防护系统，预防火灾并在火情发生时及时处置。
例：数据中心配备气体灭火系统，安装烟雾报警器，定期开展消防演练与设备检测。PE-14 Environmental Controls：管控物理环境参数（如温湿度、防尘），保障设备稳定运行。
例：机房部署精密空调，温湿度控制在 22±2℃、40%-60%区间，定期清洁防尘设施。PE-15 Water Damage Protection：采取措施防止水浸损坏设备，包括防水设施与监测告警。
例：机房部署漏水检测传感器，空调管道采用防水包裹，机房选址避开低洼易淹区域。PE-16 Delivery and Removal：管控物资的配送与清运，防止未授权物品进入或敏感物品带出。
例：数据中心物资配送需提前报备，清运物品需经安检，禁止携带存储设备等敏感物品出机房。PE-17 Alternate Work Site：设置备用工作场所，保障业务在主场地不可用时的连续性。
例：在异地设置备用办公区，配备基础 IT 设备与网络，主场地故障时可快速切换办公。PE-18 Location of System Components：合理规划系统组件的物理位置，降低环境与物理风险。
例：核心服务器部署在机房内层区域，远离门窗与水源，网络设备集中部署在机柜并做好固定。PE-19 Information Leakage：采取物理措施防止信息泄露，如声音、电磁信号等。
例：涉密会议室部署信号屏蔽设备，敏感区域采用隔音材料，防止谈话内容或电磁信号外泄。PE-20 Asset Monitoring and Tracking：对物理资产进行监控与追踪，防止资产丢失或被盗。
例：服务器、网络设备粘贴唯一标识标签，定期开展资产盘点，异常移动触发告警。PE-21 Electromagnetic Pulse Protection：采取措施防护电磁脉冲对设备的影响。
例：关键设备配备电磁屏蔽罩，机房部署电磁干扰检测设备，避免设备受电磁脉冲损坏。PE-22 Component Marking：对物理组件进行标识，明确资产信息、敏感级别与管理要求。
例：服务器标签标注资产编号、所属系统、责任人，涉密设备额外标注保密级别。PE-23 Facility Location：选择安全的场所位置，降低外部环境带来的物理风险。
例：数据中心选址避开地震带、洪涝区，远离易燃易爆场所，周边配备安防设施。
3.12 PL — Planning（规划）
PL-1 Policy and Procedures：建立安全与隐私规划的政策和流程，明确规划的框架、职责与管理要求。
例：发布组织级安全规划管理政策，规范安全计划的编制、评审、更新流程，每年同步业务战略调整。PL-2 System Security and Privacy Plans：编制系统安全与隐私计划，明确系统的安全目标、控制措施与责任分工。
例：新业务系统上线前，编制涵盖访问控制、数据加密、审计等措施的安全与隐私计划，经安全团队审核后实施。PL-3 System Security Plan Update：定期更新系统安全计划，适配系统变更、威胁变化或合规要求。
例：系统功能升级后 30 日内，同步更新安全计划中的控制措施；每年基于风险评估结果修订计划内容。PL-4 Rules of Behavior：制定系统用户的行为规范，明确合法使用、安全责任与违规后果。
例：发布员工系统使用行为准则，禁止泄露账号密码、违规访问数据等行为，违规者将按制度追责。PL-5 Privacy Impact Assessment：开展隐私影响评估，识别系统对个人信息的处理风险并制定防护措施。
例：在收集用户个人信息的系统上线前，评估数据收集、存储、使用环节的隐私风险，明确加密、最小化收集等防护手段。PL-6 Security-Related Activity Planning：规划安全相关活动（如风险评估、培训），确保资源与进度匹配。
例：制定年度安全活动计划，明确每季度开展一次风险评估、每月组织一次安全培训，提前配置资源与时间。PL-7 Concept of Operations：明确系统的运行概念，描述系统的功能、用户场景与安全边界。
例：编制系统运行概念文档，说明系统的业务用途、用户角色、数据流转路径，为安全控制设计提供依据。PL-8 Security and Privacy Architectures：设计系统的安全与隐私架构，确保安全控制融入系统设计。
例：在系统架构设计阶段，明确网络分段、身份认证、数据脱敏等安全架构组件，由架构师与安全专家联合评审。PL-9 Central Management：建立集中化的安全管理机制，统一管控安全策略、控制措施与资源。
例：部署集中式安全管理平台，统一配置防火墙规则、账号权限，集中监控各系统的安全状态。PL-10 Baseline Selection：选择符合系统风险等级的安全控制基线，作为安全防护的基础要求。
例：根据系统处理数据的敏感级别，选择 NIST SP 800-53B 中的对应基线，确定基础安全控制措施。PL-11 Baseline Tailoring：根据系统实际需求裁剪安全控制基线，确保控制措施的适用性与有效性。
例：对低风险的内部办公系统，裁剪基线中部分高等级控制措施（如多因素认证），保留核心访问控制要求。
3.13 PM — Program Management（项目管理）
PM-1 Information Security Program Plan：制定信息安全项目计划，明确项目的目标、范围、资源与进度。
例：编制年度信息安全项目计划，涵盖安全工具部署、漏洞整改等任务，明确各任务的负责人与时间节点。PM-2 Information Security Program Leadership Role：明确信息安全项目的领导职责，确保项目的资源协调与决策落地。
例：指定高管担任信息安全项目负责人，统筹跨部门资源，审批项目重大决策，推动安全目标达成。PM-3 Information Security and Privacy Resources：配置信息安全与隐私相关的资源（人员、资金、工具），保障项目实施。
例：年度预算中预留安全工具采购、人员培训等资金，配备专职安全团队，采购 SIEM、漏洞扫描等工具。PM-4 Plan of Action and Milestones Process：建立整改计划与里程碑管理流程，跟踪安全缺陷的修复进度。
例：对风险评估发现的漏洞，制定整改计划并明确里程碑节点，每周跟踪修复进度，逾期任务升级督办。PM-5 System Inventory：维护系统资产清单，记录系统的基本信息、责任部门与安全状态。
例：建立集中式系统资产清单，包含系统名称、部署位置、责任人等信息，每季度更新清单并同步安全评估结果。PM-6 Measures of Performance：定义安全项目的绩效指标，评估项目的实施效果。
例：设定“漏洞修复及时率”“安全培训完成率”等绩效指标，每月统计指标达成情况，优化项目执行。PM-7 Enterprise Architecture：构建企业级架构，确保安全控制与业务架构的融合。
例：在企业架构设计中融入安全组件，明确各业务系统的安全接口与数据流转规则，由架构团队与安全团队联合评审。PM-8 Critical Infrastructure Plan：制定关键基础设施的安全保障计划，确保核心业务的连续性。
例：针对核心业务系统（如支付系统），制定包含冗余部署、灾备切换的安全保障计划，定期开展演练验证。PM-9 Risk Management Strategy：制定风险管理策略，明确风险的识别、评估、处置流程与准则。
例：发布组织级风险管理策略，规定风险评估的频率、方法，明确高风险需立即处置、中风险限期整改的准则。PM-10 Authorization Process：建立系统授权流程，确保系统在满足安全要求后投入使用。
例：新系统上线前需通过安全评估、漏洞扫描等检查，经安全团队授权后，方可正式投入生产环境。PM-11 Mission and Business Process Definition：明确组织的使命与业务流程，为安全项目提供业务导向。
例：梳理核心业务流程（如客户订单处理），识别流程中的安全风险点，针对性设计安全控制措施。PM-12 Insider Threat Program：建立内部威胁防控项目，识别并处置内部人员的安全风险。
例：部署用户行为分析工具，监控异常数据访问、权限滥用等行为，制定内部威胁处置流程，定期开展内部风险培训。PM-13 Security and Privacy Workforce：建设安全与隐私专业团队，提升团队的技能与资质。
例：招聘具备 CISSP、CIPP 等资质的专业人员，定期组织安全培训与认证考试，提升团队的技术与管理能力。PM-14 Testing, Training, and Monitoring：规划安全测试、培训与监控活动，持续提升安全能力。
例：每季度开展渗透测试，每月组织安全培训，实时监控系统安全状态，形成“测试-培训-监控”的闭环机制。PM-15 Security and Privacy Groups and Associations：与外部安全组织、协会合作，获取行业最佳实践与威胁情报。
例：加入行业安全联盟，定期参与安全研讨会，共享威胁情报，借鉴其他组织的安全管理经验。PM-16 Threat Awareness Program：建立威胁感知项目，提升组织对安全威胁的识别与响应能力。
例：每周发布威胁情报简报，每月开展威胁场景演练，提升员工对钓鱼邮件、勒索病毒等威胁的识别能力。PM-17 Protecting Controlled Unclassified Information on External Systems：制定外部系统中受控非涉密信息的保护措施。
例：在第三方云平台存储受控信息时，要求平台提供加密存储、访问审计等功能，签订保密协议明确责任。PM-18 Privacy Program Plan：制定隐私项目计划，明确隐私保护的目标、措施与进度。
例：编制年度隐私项目计划，涵盖隐私影响评估、数据脱敏工具部署等任务，明确各任务的实施周期。PM-19 Privacy Program Leadership Role：明确隐私项目的领导职责，推动隐私保护措施的落地。
例：指定隐私专员担任项目负责人，统筹隐私保护资源，审批隐私相关决策，确保合规要求的满足。PM-20 Dissemination of Privacy Program Information：向相关人员传递隐私项目信息，提升隐私保护意识。
例：定期向员工发布隐私政策更新、合规要求等信息，在新员工入职培训中加入隐私保护内容。PM-21 Accounting of Disclosures：记录个人信息的披露情况，确保披露行为的合规性与可追溯性。
例：建立个人信息披露台账，记录披露的信息内容、接收方、目的等，披露前需经隐私专员审核。PM-22 Personally Identifiable Information Quality Management：管理个人身份信息的质量，确保信息的准确性与完整性。
例：建立个人信息校验机制，定期清理冗余、错误信息，明确信息的更新流程，保障数据质量。PM-23 Data Governance Body：建立数据治理机构，统筹数据安全与隐私的管理决策。
例：成立由业务、IT、安全部门组成的数据治理委员会，审批数据分类、共享规则等重大决策。PM-24 Data Integrity Board：建立数据完整性管理机构，保障数据的准确性与未被篡改。
例：成立数据完整性委员会，制定数据校验、备份等规则，定期审计数据完整性状态，处置数据篡改风险。PM-26 Complaint Management：建立投诉管理流程，处理隐私与安全相关的投诉并跟踪整改。
例：设立安全与隐私投诉渠道，接收用户投诉后 3 个工作日内响应，15 个工作日内完成调查与整改。PM-27 Privacy Reporting：定期报告隐私保护的实施情况，向管理层与相关方同步进展。
例：每季度向管理层提交隐私报告，包含隐私风险处置、合规要求满足情况等内容，年度发布公开隐私报告。PM-28 Risk Framing：开展风险框架设计，明确组织的风险偏好与安全目标。
例：结合业务战略，确定组织的风险偏好（如低容忍财务数据泄露风险），以此指导安全控制的设计。PM-29 Risk Management Program Leadership Roles：明确风险管理项目的领导职责，推动风险管控措施的落地。
例：指定风险经理担任项目负责人，统筹风险评估资源，审批风险处置决策，确保风险在可控范围内。PM-30 Supply Chain Risk Management Strategy：制定供应链风险管理策略，识别并处置供应链中的安全风险。
例：发布供应链风险管理策略，要求供应商提供安全评估报告，定期审计供应商的安全控制措施。PM-32 Purposing：明确数据的使用目的，确保数据的收集与使用符合合规要求。
例：在收集用户数据时，明确数据的使用目的（如提供服务、优化体验），禁止超出目的范围使用数据。
3.14 PS — Personnel Security（人员安全）
PS-1 Policy and Procedures：建立人员安全的政策与流程，明确人员安全管理的范围、职责与合规要求。
例：发布人员安全管理政策，规范员工入职、在职、离职全周期的安全管控流程，每年评审更新。PS-2 Position Risk Designation：对岗位进行风险定级，根据岗位涉密程度匹配安全管控措施。
例：将接触核心数据的岗位定为“高风险”，需额外开展背景调查；普通办公岗位定为“低风险”，执行基础安全管控。PS-3 Personnel Screening：对人员进行背景筛查，验证身份、资质与信用状况，降低内部风险。
例：新员工入职前开展身份核验、工作经历核查，高风险岗位额外进行背景调查与信用记录查询。PS-4 Personnel Termination：规范员工离职流程，回收权限、资产并清除敏感信息访问权限。
例：员工离职当日，回收门禁卡、办公设备，禁用系统账号；离职后 7 日内，删除其邮箱、共享文档等权限。PS-5 Personnel Transfer：管理员工岗位调动流程，同步调整权限与安全培训内容。
例：员工岗位调动后，立即调整其系统访问权限至新岗位所需范围，组织新岗位对应的安全职责培训。PS-6 Access Agreements：与人员签订访问协议，明确敏感信息访问的责任与保密义务。
例：高风险岗位员工入职时，签订《敏感信息访问保密协议》，明确违规访问的追责条款。PS-7 External Personnel Security：管控外部人员（如承包商、访客）的安全，明确其访问权限与责任。
例：承包商需签订《外部人员安全协议》，仅分配其工作所需的最小权限，工作期间由内部人员全程陪同。PS-8 Personnel Sanctions：建立人员违规行为的处罚机制，对违反安全规定的人员进行追责。
例：对违规泄露敏感信息的员工，按制度给予警告、降职等处分；情节严重的移交相关部门处理。PS-9 Position Descriptions：明确岗位的安全职责，将安全要求融入岗位描述。
例：在岗位描述中明确“定期参加安全培训”“遵守信息保密规定”等安全职责，作为员工绩效考核依据。
3.15 PT — Personally Identifiable Information Processing and Transparency（个人身份信息处理与透明度）
PT-1 Policy and Procedures：建立个人身份信息（PII）处理的政策与流程，明确 PII 管理的合规要求。
例：发布 PII 处理管理政策，规范 PII 的收集、存储、使用、销毁流程，符合《个人信息保护法》等法规要求。PT-2 Authority to Process Personally Identifiable Information：明确 PII 处理的授权机制，确保处理行为的合法性。
例：PII 的收集、使用需经隐私专员授权，超出授权范围的处理行为需重新审批。PT-3 Personally Identifiable Information Processing Purposes：明确 PII 的处理目的，禁止超出目的范围使用 PII。
例：收集用户手机号的目的为“发送服务通知”，禁止将手机号用于营销推广等未明确的用途。PT-4 Consent：获取用户对 PII 处理的同意，明确同意的范围与可撤销性。
例：在用户注册时，明确告知 PII 的处理目的，由用户主动勾选“同意”后方可收集；用户可随时撤销同意。PT-5 Privacy Notice：向用户提供隐私通知，明确 PII 的处理规则与用户权利。
例：在产品界面显著位置展示《隐私政策》，说明 PII 的收集类型、使用方式、用户的查询/删除权利。PT-6 System of Records Notice：发布记录系统通知，明确 PII 记录系统的管理规则与访问方式。
例：对存储用户 PII 的系统，发布《记录系统通知》，说明系统的用途、PII 类型及用户访问自身信息的方式。PT-7 Specific Categories of Personally Identifiable Information：明确特殊类型 PII 的额外保护措施，如生物识别信息。
例：对用户人脸、指纹等生物识别信息，采用加密存储，仅用于身份认证，禁止用于其他用途。PT-8 Computer Matching Requirements：规范 PII 的计算机匹配流程，确保匹配行为的合规性与安全性。
例：PII 的计算机匹配（如用户信息比对）需经隐私专员审批，匹配过程全程审计，匹配结果仅用于合法业务场景。
3.16 RA — Risk Assessment（风险评估）
RA-1 Policy and Procedures：建立风险评估的政策与流程，明确风险评估的方法、频率与职责。
例：发布风险评估管理政策，规定每年开展一次全组织风险评估，每季度对核心系统开展专项风险评估。RA-2 Security Categorization：对系统进行安全定级，根据系统处理数据的敏感程度确定保护级别。
例：按数据敏感程度将系统分为“核心”“重要”“一般”三级，核心系统需执行最高等级的安全控制措施。RA-3 Risk Assessment：开展风险评估，识别系统的安全风险，评估风险的影响与发生概率。
例：采用“资产-威胁-脆弱性”方法开展风险评估，识别系统的漏洞、威胁，评估风险的影响范围与发生可能性。RA-4 Risk Assessment Update：定期更新风险评估结果，适配系统变更、威胁变化等情况。
例：系统功能升级后 30 日内，重新开展风险评估；每年基于新威胁情报，更新风险评估报告。RA-5 Vulnerability Monitoring and Scanning：持续监控与扫描系统漏洞，及时发现安全脆弱性。
例：每周对核心系统开展漏洞扫描，实时监控漏洞库更新，高危漏洞在发现后 72 小时内启动整改。RA-6 Technical Surveillance Countermeasures Survey：开展技术监控对抗调查，识别并处置未经授权的技术监控设备。
例：每季度对敏感区域（如涉密会议室）开展技术监控设备排查，发现未经授权的摄像头、窃听器等设备立即处置。RA-7 Risk Response：制定风险响应措施，根据风险等级采取规避、转移、降低、接受等策略。
例：对高风险漏洞采取“降低”策略（立即修复）；对低风险漏洞采取“接受”策略（持续监控）。RA-8 Privacy Impact Assessments：开展隐私影响评估，识别 PII 处理过程中的隐私风险并制定防护措施。
例：在新系统上线前，评估 PII 收集、使用环节的隐私风险，制定数据加密、最小化收集等防护措施。RA-9 Criticality Analysis：开展系统重要性分析，明确核心系统的优先级与保护策略。
例：通过业务影响分析，确定核心业务系统的重要性等级，核心系统需配置冗余、灾备等额外保护措施。RA-10 Threat Hunting：开展威胁狩猎，主动识别系统中的潜在威胁与攻击行为。
例：安全团队每月开展威胁狩猎，分析系统日志、流量数据，识别隐蔽的攻击行为并提前处置。
3.17 SA — System and Services Acquisition（系统与服务采购）
SA-1 Policy and Procedures：建立系统与服务采购的安全政策与流程，明确采购全周期的安全管控要求。
例：发布采购安全管理政策，规范供应商选型、合同签订、验收等环节的安全审核流程，每年更新以适配合规要求。SA-2 Allocation of Resources：为系统与服务采购分配安全相关资源（人员、资金），保障采购过程的安全评估。
例：采购预算中预留安全评估费用，配备专职安全人员参与采购的安全审核，确保采购对象符合安全标准。SA-3 System Development Life Cycle：将安全控制融入系统开发生命周期（SDLC），从设计阶段落实安全要求。
例：在 SDLC 的需求、设计、开发、测试阶段均加入安全评审环节，确保每个阶段的安全控制落地。SA-4 Acquisition Process：规范采购流程，将安全要求纳入采购文档、供应商评估与合同条款。
例：在采购需求中明确系统需满足的安全标准（如等保 2.0），将安全条款写入采购合同，要求供应商提供安全承诺。SA-5 System Documentation：要求供应商提供系统安全相关文档，确保系统的可维护性与安全性。
例：采购系统时，要求供应商提供安全架构设计、操作手册、漏洞修复指南等文档，作为验收的必要条件。SA-6 Software Usage Restrictions：限制软件的使用范围，仅授权使用符合安全要求的软件。
例：禁止使用未经安全检测的开源软件，采购商业软件时需验证其安全合规性，建立授权软件清单。SA-7 User-Installed Software：管控用户自行安装的软件，防止未授权软件引入安全风险。
例：通过终端管理工具禁止用户自行安装软件，特殊需求需提交审批，经安全检测后由管理员部署。SA-8 Security and Privacy Engineering Principles：要求系统开发遵循安全与隐私工程原则，从设计层面降低风险。
例：要求供应商遵循“最小权限”“默认安全”等工程原则，系统设计需包含数据加密、访问控制等安全组件。SA-9 External System Services：管控外部系统服务（如云服务）的采购，评估其安全与隐私能力。
例：采购云服务前，评估服务商的安全合规资质（如等保备案），签订服务级别协议（SLA）明确安全责任。SA-10 Developer Configuration Management：要求开发者实施配置管理，确保系统配置的一致性与安全性。
例：要求供应商采用版本控制工具管理代码与配置，配置变更需经过审批，确保生产环境配置的安全合规。SA-11 Developer Testing and Evaluation：要求开发者开展安全测试与评估，验证系统的安全能力。
例：要求供应商在系统交付前完成渗透测试、漏洞扫描，提供测试报告，安全问题修复后方可验收。SA-12 Supply Chain Protection：实施供应链保护措施，识别并处置供应链中的安全风险。
例：对核心系统的硬件供应商，开展供应链风险评估，要求其提供组件溯源证明，防止恶意组件植入。SA-13 Trustworthiness：评估系统的可信性，确保系统组件的完整性与可靠性。
例：要求供应商提供系统组件的可信认证（如代码签名），验证组件未被篡改，确保系统运行的可信性。SA-14 Criticality Analysis：开展采购系统的重要性分析，明确核心系统的额外保护要求。
例：对支撑核心业务的采购系统，开展重要性分析，要求其具备冗余部署、灾备切换等额外安全能力。SA-15 Development Process, Standards, and Tools：要求开发者遵循安全开发流程、标准与工具，提升开发安全水平。
例：要求供应商采用安全开发生命周期（SDL）流程，使用静态代码扫描工具，遵循 OWASP 安全编码标准。SA-16 Developer-Provided Training：要求供应商提供系统安全使用培训，确保用户掌握安全操作技能。
例：系统交付后，要求供应商提供管理员安全操作培训，内容包括权限管理、应急处置等，确保系统安全运维。SA-17 Developer Security and Privacy Architecture and Design：要求供应商提供安全与隐私架构设计文档，验证其合理性。
例：要求供应商提交系统安全与隐私架构设计文档，由安全团队评审，确保架构包含数据脱敏、访问审计等组件。SA-18 Tamper Resistance and Detection：要求系统具备防篡改与篡改检测能力，防止恶意篡改系统组件。
例：要求核心系统的硬件具备物理防篡改设计，软件部署完整性校验机制，篡改行为触发实时告警。SA-19 Component Authenticity：验证系统组件的真实性，确保组件来源合法、未被篡改。
例：采购硬件组件时，验证供应商提供的组件认证文件，通过哈希校验等方式验证软件组件的完整性。SA-20 Customized Development of Critical Components：管控核心组件的定制开发，确保开发过程的安全可控。
例：对核心系统的定制组件，要求开发过程全程审计，代码需经过安全评审，交付前完成漏洞扫描。SA-21 Developer Screening：对参与开发的人员进行背景筛查，降低内部风险。
例：要求供应商对参与核心系统开发的人员开展背景调查，确保人员无安全不良记录。SA-22 Unsupported System Components：管控未受支持的系统组件，及时替换或采取补偿措施。
例：采购系统时，要求避免使用已停止维护的组件；若存在此类组件，要求供应商提供安全补偿方案。SA-23 Specialization：根据系统的特殊需求，实施定制化的安全控制措施。
例：对涉及医疗数据的采购系统，实施符合《医疗保障数据安全管理办法》的定制化安全控制，如数据脱敏、访问审计。
3.18 SC — System and Communications Protection（系统与通信保护）
SC-1 Policy and Procedures：建立系统与通信保护的政策与流程，明确全周期的安全管控要求。
例：发布系统与通信安全管理政策，规范网络架构、加密传输等环节的管控流程，每年适配新威胁更新。SC-2 Separation of System and User Functionality：分离系统功能与用户功能，避免用户操作影响系统安全。
例：将系统管理员功能与普通用户功能逻辑隔离，普通用户无法访问系统配置、日志等核心功能。SC-3 Security Function Isolation：隔离安全功能组件，确保单一组件故障不影响整体安全能力。
例：将防火墙、入侵检测等安全组件独立部署，各组件的运行环境物理/逻辑隔离，避免组件间风险传导。SC-4 Information in Shared System Resources：保护共享系统资源中的信息，防止未授权访问或泄露。
例：在共享服务器中，为不同用户/业务的文件配置独立权限，敏感文件加密存储，避免共享资源内信息泄露。SC-5 Denial-of-Service Protection：实施拒绝服务（DoS）防护措施，保障系统的可用性。
例：部署抗 DDoS 设备，设置流量阈值告警，对异常流量进行清洗，确保核心业务系统不因流量攻击中断。SC-6 Resource Availability：保障系统资源的可用性，通过冗余、监控等措施避免资源耗尽。
例：核心服务器采用集群部署，配置资源监控告警，当 CPU、内存使用率超过阈值时自动扩容或触发预警。SC-7 Boundary Protection：保护系统边界安全，控制外部与内部网络的访问。
例：在网络边界部署下一代防火墙，配置访问控制策略，仅允许授权的 IP、端口通信，阻断恶意流量。SC-8 Transmission Confidentiality and Integrity：保障传输过程中信息的机密性与完整性。
例：业务数据传输采用 TLS 1.3 加密协议，通过数字签名验证传输数据的完整性，防止传输过程被窃听或篡改。SC-9 Transmission Confidentiality：单独强化传输信息的机密性，针对高敏感数据实施额外加密。
例：核心业务数据（如用户支付信息）传输时，在 TLS 加密基础上增加端到端加密，双重保障数据机密性。SC-10 Network Disconnect：具备网络断开能力，在紧急情况下切断系统与网络的连接。
例：核心系统部署物理/逻辑断开开关，当检测到大规模攻击时，可一键切断外部网络连接，防止威胁扩散。SC-11 Trusted Path：建立可信通信路径，确保用户与系统间的通信未被篡改或监听。
例：管理员登录核心系统时，启用专用可信通道（如硬件加密终端），通道内的操作全程加密且不可篡改。SC-12 Cryptographic Key Establishment and Management：建立加密密钥的生成、分发、存储、销毁全生命周期管理机制。
例：采用硬件安全模块（HSM）生成与存储密钥，密钥分发通过加密通道，密钥定期轮换并安全销毁过期密钥。SC-13 Cryptographic Protection：采用密码技术保护信息的机密性、完整性与可用性。
例：敏感数据存储时采用 AES-256 加密，身份认证采用 RSA 非对称加密，确保信息在全生命周期的密码防护。SC-14 Public Access Protections：强化公开访问服务的安全防护，防止未授权访问或攻击。
例：对外网站部署 Web 应用防火墙（WAF），过滤 SQL 注入、XSS 等攻击，公开接口增加频率限制与身份校验。SC-15 Collaborative Computing Devices and Applications：保护协同计算设备与应用的安全，防止信息泄露。
例：企业协作工具（如 OA、即时通讯）启用数据脱敏功能，禁止敏感信息在协同应用中明文传输，操作行为全程审计。SC-16 Transmission of Security and Privacy Attributes：安全传输安全与隐私属性信息，确保属性的真实性。
例：用户身份属性（如权限等级）传输时，附加数字签名，接收方验证签名后再执行权限判定，防止属性被篡改。SC-17 Public Key Infrastructure Certificates：管理公钥基础设施（PKI）证书，确保证书的合法性与有效性。
例：建立企业 PKI 系统，定期检查证书有效期，及时吊销过期/泄露证书，仅信任合法 CA 签发的证书。SC-18 Mobile Code：管控移动代码（如 App 插件、脚本）的安全，防止恶意代码执行。
例：企业 App 禁止加载未签名的移动代码，移动代码上线前需经过安全检测，运行时限制代码的权限范围。SC-19 Voice over Internet Protocol：保护 VoIP 通信的安全，防止通话内容被窃听或篡改。
例：企业 VoIP 系统采用加密传输协议，通话内容全程加密，身份认证采用数字证书，防止非法接入通话。SC-20 Secure Name/Address Resolution Service (Authoritative Source)：保障权威域名/地址解析服务的安全。
例：企业权威 DNS 服务器部署访问控制策略，仅允许授权设备查询，启用 DNSSEC 验证解析记录的完整性。SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver)：保障递归/缓存域名解析服务的安全。
例：企业递归 DNS 服务器启用缓存污染防护，限制递归查询范围，定期清理恶意缓存记录，防止解析结果被篡改。SC-22 Architecture and Provisioning for Name/Address Resolution Service：优化域名解析服务的架构与配置，提升安全性。
例：采用多区域 DNS 服务器部署架构，配置冗余解析节点，解析服务的配置遵循最小权限原则，减少攻击面。SC-23 Session Authenticity：验证会话的真实性，防止会话劫持或伪造。
例：系统会话采用随机生成的强令牌，会话令牌定期轮换，用户登录时验证设备指纹，防止非法会话复用。SC-24 Fail in Known State：确保系统故障时处于已知安全状态，避免故障导致安全漏洞暴露。
例：核心系统配置故障安全策略，当系统崩溃时自动回滚至最近的安全配置状态，关闭所有非必要服务。SC-25 Thin Nodes：强化瘦节点（如终端设备）的安全，减少本地存储与计算风险。
例：企业办公终端采用瘦客户端模式，所有数据存储在云端，终端仅执行基础操作，降低本地数据泄露风险。SC-26 Decoys：部署诱饵系统（如蜜罐），诱捕攻击者并收集威胁情报。
例：在网络边界部署高交互蜜罐，模拟核心业务系统，当攻击者接入时记录其攻击行为，用于威胁分析与防御优化。SC-27 Platform-Independent Applications：保障跨平台应用的安全，确保不同平台下的安全控制一致性。
例：企业跨平台 App 采用统一的安全开发框架，在 Windows、iOS 等平台下均启用数据加密、权限控制等一致的安全措施。SC-28 Protection of Information at Rest：保护静态存储信息的安全，防止存储介质中的信息泄露。
例：服务器硬盘采用全磁盘加密（FDE），数据库敏感字段采用字段级加密，备份数据加密后存储在专用介质中。SC-29 Heterogeneity：采用异构架构，降低单一架构漏洞导致的大规模风险。
例：核心业务系统采用“Windows+Linux”异构服务器部署，网络设备混合使用不同厂商产品，减少通用漏洞的影响范围。SC-30 Concealment and Misdirection：采用隐蔽与误导措施，降低系统被攻击的概率。
例：核心系统隐藏真实版本信息，对外展示虚假的系统标识；关键服务端口采用非默认端口，混淆攻击者的目标识别。SC-31 Covert Channel Analysis：分析隐蔽通道，识别并阻断非法信息传输通道。
例：定期对系统开展隐蔽通道分析，识别进程间、网络间的非法数据传输通道，通过配置优化阻断此类通道。SC-32 System Partitioning：对系统进行分区隔离，限制风险在单一分区内扩散。
例：将企业网络分为办公区、业务区、核心区，分区间通过防火墙隔离，核心区仅允许业务区的授权流量访问。SC-33 Transmission Preparation Integrity：保障传输前数据准备过程的完整性，防止数据在发送前被篡改。
例：数据传输前通过哈希算法生成完整性校验值，发送方与接收方分别校验，确保数据在准备阶段未被篡改。SC-34 Non-Modifiable Executable Programs：防止可执行程序被篡改，保障程序运行的完整性。
例：核心系统的可执行程序采用数字签名，系统启动时验证程序签名，若签名不匹配则禁止程序运行。SC-35 External Malicious Code Identification：识别外部恶意代码，防止恶意代码进入系统。
例：部署邮件网关、终端杀毒软件，实时检测外部传入的恶意代码（如病毒、木马），发现后立即隔离清除。SC-36 Distributed Processing and Storage：保障分布式处理与存储的安全，确保分布式环境下的控制一致性。
例：分布式数据库启用分布式加密与权限控制，每个节点的操作均需经过身份认证，节点间通信采用加密协议。SC-37 Out-of-Band Channels：建立带外通信通道，用于紧急情况下的安全管理。
例：核心系统部署带外管理通道（如独立网络、硬件控制台），当主网络被攻击中断时，通过带外通道进行系统运维。SC-38 Operations Security：强化操作安全，防止操作过程中的信息泄露或错误。
例：系统操作采用双人复核机制，敏感操作（如数据删除）需经两人授权；操作过程全程记录，定期审计操作日志。SC-39 Process Isolation：隔离系统进程，防止进程间的非法访问或风险传导。
例：核心系统采用容器化部署，每个业务进程运行在独立容器中，容器间配置网络隔离，防止进程间的恶意访问。SC-40 Wireless Link Protection：保护无线链路的安全，防止无线通信被窃听或篡改。
例：企业无线网络采用 WPA3 加密协议，启用 802.1X 身份认证，定期更换无线密钥，禁止开放无线接入。SC-41 Port and I/O Device Access：管控端口与 I/O 设备的访问，防止未授权设备接入。
例：通过终端管理工具禁用非必要的 USB 端口，服务器仅开放业务所需的网络端口，接入新设备需经过安全审批。SC-42 Sensor Capability and Data：保护传感器能力与数据的安全，防止传感器数据被篡改或泄露。
例：物联网传感器采用加密传输协议，传感器数据存储前进行完整性校验，未授权设备无法修改传感器配置。SC-43 Usage Restrictions：限制系统资源的使用范围，防止资源被滥用。
例：企业办公终端限制安装娱乐软件，服务器限制非业务进程运行，通过资源监控工具告警异常资源占用。SC-44 Detonation Chambers：部署引爆室（如沙箱），安全检测可疑文件或代码。
例：邮件网关将可疑附件投递至沙箱中运行，检测其是否包含恶意行为，确认安全后再交付给用户。SC-45 System Time Synchronization：同步系统时间，确保日志、认证等功能的时间一致性。
例：所有系统设备通过 NTP 服务器同步时间，时间误差控制在 1 秒内，确保日志审计、会话管理的时间准确性。SC-46 Cross Domain Policy Enforcement：实施跨域策略强制，确保不同安全域间的访问符合政策要求。
例：建立跨域访问控制策略，低安全域访问高安全域需经过双重身份认证，跨域传输的数据需经过脱敏处理。SC-47 Alternate Communications Paths：配置备用通信路径，保障通信中断时的业务连续性。
例：核心业务系统部署主备双链路通信，当主链路故障时自动切换至备用链路，切换过程不影响业务运行。SC-48 Sensor Relocation：具备传感器重定位能力，适应安全需求的变化。
例：物联网传感器支持远程重定位配置，当安全风险区域变化时，可调整传感器的监控范围与数据传输策略。SC-49 Hardware-Enforced Separation and Policy Enforcement：通过硬件实现隔离与策略强制，提升安全控制的可靠性。
例：采用硬件隔离卡将终端分为办公与涉密两个环境，硬件级强制隔离两个环境的资源，防止信息交叉泄露。SC-50 Software-Enforced Separation and Policy Enforcement：通过软件实现隔离与策略强制，适配动态的安全需求。
例：采用虚拟化软件划分不同的安全虚拟机，通过软件策略限制虚拟机间的资源访问，动态调整隔离规则。SC-51 Hardware-Based Protection：采用硬件级安全保护措施，提升系统的底层安全性。
例：核心服务器采用具备可信平台模块（TPM）的硬件，通过 TPM 实现启动完整性验证、密钥安全存储等底层安全功能。
3.19 SI — System and Information Integrity（系统与信息完整性）
SI-1 Policy and Procedures：建立系统与信息完整性的政策与流程，明确完整性管控的范围、职责与要求。
例：发布系统与信息完整性管理政策，规范漏洞修复、恶意代码防护等环节的流程，每年结合威胁态势更新。SI-2 Flaw Remediation：及时修复系统与软件漏洞，降低漏洞被利用的风险。
例：建立漏洞管理流程，高危漏洞在发布后 72 小时内启动修复，中低危漏洞 15 日内完成整改，修复后验证效果。SI-3 Malicious Code Protection：实施恶意代码防护措施，防止恶意代码入侵与传播。
例：终端部署杀毒软件、服务器配置恶意代码检测工具，实时监控恶意程序，发现后自动隔离并清除。SI-4 System Monitoring：持续监控系统状态，及时发现完整性异常（如文件篡改、进程异常）。
例：部署主机入侵检测系统（HIDS），监控系统文件哈希值、进程行为，异常变更触发实时告警。SI-5 Security Alerts, Advisories, and Directives：及时获取并响应安全告警、公告与指令，同步落实防护措施。
例：订阅安全厂商的威胁情报，收到高危漏洞公告后 2 小时内评估影响，12 小时内制定修复计划。SI-6 Security and Privacy Function Verification：验证安全与隐私功能的有效性，确保功能按设计运行。
例：每季度对访问控制、数据加密等安全功能进行验证测试，确认功能未被篡改、能有效防护风险。SI-7 Software, Firmware, and Information Integrity：保障软件、固件与信息的完整性，防止未授权篡改。
例：软件、固件部署前验证数字签名，信息存储时生成完整性校验值，定期比对校验值确认未被篡改。SI-8 Spam Protection：实施垃圾邮件防护措施，防止垃圾邮件携带恶意代码或欺诈信息。
例：部署邮件过滤系统，基于关键词、发件人信誉等规则拦截垃圾邮件，可疑邮件投递至隔离箱待审核。SI-9 Information Input Restrictions：限制信息输入的格式与内容，防止恶意输入破坏系统完整性。
例：业务系统的输入框设置格式校验（如手机号、邮箱格式），禁止特殊字符输入，防范 SQL 注入等攻击。SI-10 Information Input Validation：验证输入信息的合法性，防止恶意输入导致系统故障或数据篡改。
例：后端系统对所有用户输入进行合法性验证，过滤恶意脚本、非法字符，确保输入信息符合业务规则。SI-11 Error Handling：规范错误处理机制，避免错误信息泄露或被利用攻击系统。
例：系统错误时返回通用提示（如“操作失败，请重试”），不暴露具体代码、路径等敏感信息，错误日志仅内部可见。SI-12 Information Management and Retention：规范信息的管理与留存，确保信息在生命周期内的完整性。
例：建立信息分类留存制度，敏感信息加密存储并定期校验完整性，超期信息按流程安全销毁。SI-13 Predictable Failure Prevention：预防可预测的故障，避免故障导致系统完整性受损。
例：定期对硬件、软件进行健康检查，提前替换老化设备，修复潜在故障点，降低系统异常崩溃风险。SI-14 Non-Persistence：采用非持久化部署方式，降低恶意代码驻留或信息篡改的影响。
例：临时测试环境采用非持久化容器，每次使用后重置至初始状态，防止恶意代码长期驻留。SI-15 Information Output Filtering：过滤输出信息，防止敏感信息泄露或输出内容破坏接收方系统。
例：业务系统输出数据时，过滤敏感字段（如身份证号脱敏），验证输出格式，避免输出恶意内容。SI-16 Memory Protection：保护系统内存的完整性，防止内存数据被篡改或泄露。
例：启用系统内存保护机制（如地址空间布局随机化 ASLR），限制进程对其他进程内存的访问权限。SI-17 Fail-Safe Procedures：制定故障安全流程，系统故障时保障信息完整性与系统可控。
例：核心系统故障时自动触发故障安全模式，暂停业务操作、备份当前数据，防止故障扩大导致数据损坏。SI-18 Personally Identifiable Information Quality Operations：保障个人身份信息（PII）的质量，确保 PII 准确、完整。
例：建立 PII 质量校验机制，定期清理重复、错误数据，更新 PII 时验证来源合法性，保障数据质量。SI-19 De-identification：对 PII 进行去标识化处理，降低信息泄露的隐私风险。
例：非业务必需场景下，对用户姓名、手机号等 PII 进行脱敏（如“张*”“138****1234”），仅保留必要信息。SI-20 Tainting：对敏感信息进行标记（污点标记），跟踪信息流转路径，防止未授权扩散。
例：核心业务数据标记为“敏感”，系统跟踪其流转过程，非授权用户访问时触发告警，记录访问轨迹。SI-21 Information Refresh：定期更新信息，确保信息的时效性与完整性。
例：用户权限信息、系统配置信息每月刷新一次，同步最新状态，防止过期信息导致的权限异常或配置错误。SI-22 Information Diversity：采用信息多样性措施，降低单一信息格式或存储方式的风险。
例：核心数据同时以结构化（数据库）与非结构化（加密文件）方式存储，避免单一存储介质故障导致数据丢失。SI-23 Information Fragmentation：将敏感信息分片存储，降低信息完整泄露的风险。
例：用户核心数据分为多个片段，存储在不同服务器中，仅授权系统可聚合片段，单个片段泄露不导致信息完整泄露。
3.20 SR — Supply Chain Risk Management（供应链风险管理）
SR-1 Policy and Procedures：建立供应链风险管理的政策与流程，明确供应链风险的管控范围与职责。
例：发布供应链风险管理政策，规范供应商评估、采购审核等环节的流程，每年结合供应链威胁更新。SR-2 Supply Chain Risk Management Plan：制定供应链风险管理计划，明确风险识别、评估与处置的措施。
例：编制年度供应链风险计划，涵盖供应商风险评估、组件溯源等任务，明确各环节的时间节点与责任人。SR-3 Supply Chain Controls and Processes：实施供应链管控措施与流程，降低供应链各环节的风险。
例：在采购、生产、交付等供应链环节设置安全审核点，核心组件采购前验证供应商的安全资质。SR-4 Provenance：追溯供应链组件的来源，确保组件的合法性与未被篡改。
例：要求硬件供应商提供组件的溯源文档，记录原材料、生产流程等信息，验证组件来源合法、未被恶意篡改。SR-5 Acquisition Strategies, Tools, and Methods：采用安全的采购策略、工具与方法，降低采购过程的风险。
例：核心系统采购采用“多方供应商比价+安全资质优先”策略，使用加密工具传输采购敏感信息。SR-6 Supplier Assessments and Reviews：对供应商进行安全评估与定期审核，验证其安全能力。
例：每年对核心供应商开展安全评估，审核其安全政策、漏洞管理流程，评估结果作为续合作的依据。SR-7 Supply Chain Operations Security：强化供应链运营环节的安全，防止运营过程中的风险引入。
例：供应商生产核心组件时，安排内部人员驻场监督，验证生产环境的安全防护措施，防止恶意组件植入。SR-8 Notification Agreements：与供应商签订通知协议，要求供应商及时通报供应链安全事件。
例：在采购合同中明确，供应商发现组件安全漏洞或供应链事件时，需 24 小时内通知采购方，同步处置措施。SR-9 Tamper Resistance and Detection：要求供应链组件具备防篡改与篡改检测能力，防止组件被恶意修改。
例：核心硬件组件采用防篡改封装，内置篡改检测传感器，组件被篡改时触发告警并记录异常。SR-10 Inspection of Systems or Components：对采购的系统或组件进行安全检测，验证其安全性。
例：新采购的系统或组件交付后，开展渗透测试、漏洞扫描等安全检测，检测通过后方可投入使用。SR-11 Component Authenticity：验证供应链组件的真实性，确保组件为合法原厂产品。
例：采购硬件组件时，验证产品序列号、防伪标识，通过厂商官方渠道核实组件的合法性，防止假冒产品。SR-12 Component Disposal：规范供应链组件的处置流程，防止处置过程中的信息泄露或组件滥用。
例：废弃的供应链组件（如旧服务器）需经过消磁、粉碎等安全处置，处置过程全程记录，防止组件被二次利用。
思 维 教程：