管理层职责

治理结构

报告

管理层培训义务

管理层每年至少参加一次网络安全培训，内容涵盖：

• 当前威胁态势和相关事件
• NIS2/BSIG义务和责任
• 风险管理和措施评估
• 事件响应流程和升级

基础培训（所有员工）

角色特定培训

入职培训

新员工在获得系统访问权之前：

• 信息安全政策介绍
• 基本网络卫生培训
• 确认安全策略

文档

• 出勤记录集中管理
• 培训完成是系统访问权的先决条件
• 完成率作为KPI年度评估

多因素认证

MFA要求

MFA方法（优先级排序）

MFA例外

MFA要求的例外仅在有充分理由时允许：

• 须提供书面理由
• 须ISB审批
• 须定义补偿措施
• 有时间限制并设到期提醒
• 服务账户：IP白名单 + API密钥替代MFA

密码策略

服务账户

访问控制模型

BAUER GROUP采用基于角色的访问控制模型（RBAC）：

角色模型

权限流程

授予

1. 员工或上级提交申请
2. 数据/系统负责人审批
3. IT执行
4. 在权限清单中记录

变更

1. 角色变更时：撤销旧权限，授予新权限
2. 期限：角色变更后5个工作日内
3. 上级审查旧权限

撤销（离职）

权限审计

通信渠道

电子邮件安全详解

基于DNS的认证

机密数据的邮件处理

紧急通信

备用渠道

当主要通信渠道被入侵或不可用时：

准备措施

• 关键人员的最新联系名单可离线获取（打印或存储在独立设备上）
• 预定义暗语用于电话沟通中的身份验证
• 每年对所有危机管理团队成员进行可达性演练
• 备用通信计划是危机管理文档的组成部分

3-2-1规则详解

备份类型

按数据类型的备份目标

恢复验证

监控

• 自动监控备份成功/失败状态
• 备份失败立即生成告警
• 监控存储容量和保留期限
• 每月向ISB提交备份报告

危机定义

当安全事件出现以下情况时，即构成危机：

• 威胁组织的运作能力
• 同时影响多个系统或站点
• 需要与客户、监管机构或媒体进行外部沟通
• 常规升级路径不足以应对

危机管理团队

危机流程

第一阶段：警报 (< 1小时)

• ISB通过手机通知危机管理团队（系统被入侵时不使用电子邮件）
• 初始态势：已知情况、受影响范围、直接威胁
• 危机管理团队会议（现场或通过备用渠道电话会议）

第二阶段：态势评估 (< 4小时)

• 完整的影响分析
• 决定沟通策略
• 准备BSI报告（如构成需报告的事件）
• 准备客户通知（如受影响）

第三阶段：应对处置（数天至数周）

• 按DR计划协调恢复
• 定期危机管理团队更新（至少每天一次）
• 持续与BSI沟通
• 客户沟通（状态更新）

第四阶段：恢复正常运营

• 验证所有已恢复系统
• 管理层宣布解除危机状态
• 移交至常规运营

第五阶段：总结复盘 (< 30天)

• 全面的事后分析
• BSI结案报告
• 经验教训和行动计划
• 调整DR计划、响应预案和风险分析

危机演练

恢复目标

恢复程序

场景：单系统故障

1. 确定原因（硬件、软件、配置）
2. 激活故障切换（如有）
3. 从备份恢复系统或重新部署
4. 从Git仓库应用配置
5. 重新上线前进行完整性检查
6. 加强监控24小时

场景：勒索软件

1. 立即： 将所有受影响系统从网络隔离
2. 确定加密范围
3. 验证备份完整性（确认干净备份）
4. 从经验证的备份恢复系统
5. 轮换所有凭证
6. 系统重新上线前关闭攻击向量

场景：数据中心故障

1. 启动危机管理团队
2. 切换至备用站点（如有）
3. 按服务类别优先恢复
4. 启动客户沟通
5. 确保临时运行
6. 主站点可用后进行完整恢复

故障切换系统

DR测试

详细要求映射

§30第2项 -- 事件管理 <-> CRA Art. 14

§30第4项 -- 供应链 <-> CRA Annex I第II部分第1项

§30第5项 -- 漏洞管理 <-> CRA Art. 10/11

AI法案协同效应

总体架构

NIS2（组织与运营）
  ├── 风险管理 ←──── AI法案（AI风险管理，Art. 9）
  ├── 事件管理 ←──── CRA（产品事件，Art. 14）
  ├── 供应链 ←──── CRA（软件SBOM，Annex I）
  ├── 漏洞管理 ←──── CRA（产品CVE，Art. 10/11）
  ├── 培训 ←──── AI法案（AI素养，Art. 4）
  └── 密码学 ←──── AI法案（网络安全，Art. 15）
                ←──── CRA（产品加密，Annex I）

协议要求

TLS (Transport Layer Security)

SSH

电子邮件 (SMTP)

数据库加密

备份加密

密钥生命周期

轮换间隔

证书管理

清单

所有证书集中登记：

监控

吊销流程

证书被泄露时：

1. 立即向CA申请吊销
2. 颁发新证书并部署
3. 检查被泄露的密钥是否在其他地方使用
4. 记录事件并纳入风险分析

审计类型

审计范围

内部ISMS审计

渗透测试范围

审计文档

每次审计须记录：

• 审计范围和时间段
• 审查方法
• 发现及严重程度（关键 / 高 / 中 / 低 / 信息性）
• 建议措施
• 负责人和修复期限
• 跟踪日期

发现管理

安全KPI

漏洞管理

事件管理

访问控制

业务连续性

培训

报告

法定义务

§38第1款 -- 批准与监督

管理层承担个人义务：

§38第2款 -- 个人责任

• 管理层对因违反第1款义务所造成的损害承担个人责任
• 免责协议无效
• 关于赔偿请求的和解无效
• 机构对管理层的损害赔偿请求不得被排除

§38第3款 -- 培训义务

• 管理层必须定期参加培训
• 目的：获得足够的知识以识别和评估风险
• 内容：风险管理实践及其对机构服务的影响

BAUER GROUP的实施

批准流程

监督机制

培训证明

责任风险最小化

为最小化管理层个人责任风险，建议采取以下措施：

组织结构

管理层
  ├── 信息安全官 (ISB)
  │     ├── 风险分析与ISMS
  │     ├── 事件管理与BSI联络
  │     ├── 审计与合规
  │     └── 培训与安全意识
  ├── IT主管
  │     ├── IT运维（服务器、网络、云）
  │     ├── 软件开发
  │     └── 服务台/支持
  └── 数据保护官 (DSB)
        └── DSGVO合规

ISB -- 角色与权限

报告结构

定期报告

事件驱动报告

文档义务

以下文件须持续维护并随时可查：

升级矩阵

沟通计划

内部沟通

外部沟通

事件中的客户通知

当安全事件影响客户数据或服务时，通知包括：

• 事件类型和范围
• 受影响的数据或服务
• 已采取的应对措施
• 对客户的建议措施
• 查询联系人
• 预计限制持续时间

紧急联系人

以下联系人随时可达（包括工作时间以外）：

三级报告模型

第一级：预警（24小时）

第二级：更新（72小时）

第三级：结案报告（1个月）

重大安全事件标准

事件满足以下至少一项标准即为重大事件：

内部报告流程

发现事件
  → 通知ISB (< 1小时)
    → 初步评估：是否为重大事件？(< 4小时)
      → 如是：准备BSI预警 (< 24小时)
        → 通知管理层
          → 审查DSGVO报告义务 (Art. 33: 72小时内向监管机构报告)
            → 审查CRA报告义务 (Art. 14: 24小时内向ENISA报告)

并行报告义务

文档记录

每个需报告的事件均须完整记录：

• 带时间戳的事件时间线
• 所有决策及其依据
• 与BSI的沟通（报告ID、往来信函）
• 已采取措施及其效果
• 经验教训和后续措施

保存期限：事件结案后至少3年。

五阶段模型

BAUER GROUP的事件响应流程遵循成熟的NIST SP 800-61框架，并根据§30第2款第2项BSIG的要求进行了调整。

第一阶段：准备

第二阶段：检测与分析

分析步骤：

1. 初始评估：事件是否真实？（分诊）
2. 按严重程度分级（关键 / 高 / 中 / 低）
3. 影响分析：哪些系统、数据、客户受到影响？
4. 报告义务审查：是否构成§32 BSIG规定的重大事件？
5. 初步取证评估：攻击向量、时间范围、威胁指标（IoC）

第三阶段：遏制

第四阶段：根除与恢复

第五阶段：总结复盘

预案手册

针对常见场景，已预定义响应预案：

基本原则

BAUER GROUP受三项互补的欧盟网络安全法规约束。为避免重复工作并最大限度减少内部合规负担，需系统性地利用协同效应：CRA和AI法案合规中的现有流程将被NIS2引用而非复制。

协同效应概览

详细协同效应

漏洞管理 (第5项)

报告义务 (第2项 / §32)

供应链 (第4项)

工作量优化

通过系统性利用CRA基础工作，NIS2特有的额外工作量可降低至：

目的

资产清单记录BAUER GROUP所有信息技术系统、组件和流程。它是风险分析的基础，使保护措施能够与具体资产相对应。

资产类别

服务器系统

网络组件

• 防火墙及规则集版本和最近审查日期
• 交换机和路由器及固件版本
• VPN网关和接入点
• DNS服务器和负载均衡器

应用程序

云服务

• 供应商及其位置和法律管辖区
• 合同期限和SLA
• 存储数据的分级
• 退出策略和数据可移植性

数据资产

维护

目的

信息安全政策为BAUER GROUP所有信息技术系统、组件和流程的保护定义了框架。它是ISMS的最高指导方针，须经管理层批准发布。

保护目标

适用范围

信息安全政策适用于：

• 所有员工、管理层以及具有系统访问权限的外部服务提供商
• 所有自行运营和第三方托管的信息技术系统
• 所有办公地点和远程工作场所
• 信息生命周期的所有阶段（创建、处理、存储、删除）

职责

审查周期

分级方案

方法论

风险分析遵循结构化流程，参照ISO 27005和BSI IT基础保护标准：

确定背景 → 识别风险 → 分析风险 → 评估风险 → 处置风险

威胁目录

风险评估矩阵

根据发生概率和影响程度评估风险：

风险处置计划

对于每个已识别的风险进行记录：

流程集成

必备条款

与具有BAUER GROUP系统或数据访问权限的服务提供商签订的合同须包含以下最低要求：

信息安全

事件管理

检查与审计权

数据处理

退出策略

合同管理

评估流程

初始评估（委托前）

评估标准（评分）

最低分数： 标准供应商12/18分，关键供应商15/18分。

复评

分类

安全意识计划

持续措施

钓鱼模拟

网络卫生规则

工作场所

密码与认证

通信

文档记录

必修培训

基础培训 -- 全体员工

总时长： 每年约2小时

管理层培训（§38第3款BSIG）

时长： 每年2-3小时，由ISB或外部讲师进行

角色专项培训

培训方法

补丁期限

补丁流程

标准流程（中/低）

1. 通过扫描或CVE监控识别漏洞
2. 评估和优先级排序
3. 在预发布环境中测试补丁
4. 在期限内部署到生产环境
5. 验证：扫描确认已修复

紧急流程（关键/高）

1. IT运维 + ISB立即评估
2. 如补丁暂时不可用，实施临时方案（如WAF规则、网络隔离）
3. 测试补丁（缩短测试阶段，必要时并行进行）
4. 紧急部署（允许在常规维护窗口外进行）
5. 验证和记录

例外处理

当补丁无法在期限内完成时：

补丁跟踪

扫描计划

基础设施扫描

应用程序扫描

CVE监控

信息源

评估流程

CVE发布
  → 相关性审查：受影响产品是否在我们的环境中使用？
    → 是：CVSS评估 + 上下文评估
      → 关键/高：立即升级至IT运维
      → 中：纳入补丁周期
      → 低：下一个发布周期
    → 否：归档

漏洞跟踪

每个已识别的漏洞均须记录：

SDLC中的安全

CI/CD安全流水线

每次提交自动经过以下步骤：

依赖管理

Secrets管理

访问控制原则

多因素认证（MFA）

MFA强制要求用于：

• 所有外部访问（VPN、Web门户）
• 管理系统访问
• 云服务和SaaS应用
• 电子邮件访问

首选MFA方法：硬件令牌（FIDO2/WebAuthn）、认证器应用（TOTP）。不允许基于短信的MFA。

密码管理

入职/离职

安全通信

应急通信

• 预定义的备用通信渠道（电话、替代即时通讯）
• 关键人员的最新联系列表可离线获取
• 定期验证可达性

备份策略

BAUER GROUP采用3-2-1规则：

恢复目标

灾难恢复

• 定期恢复测试 – 每季度验证可恢复性
• 每个系统的文档化恢复程序
• 关键业务服务的故障转移系统
• 明确责任和沟通渠道的升级计划

危机管理

发生危机时（如勒索软件、全面中断）：

1. 激活危机团队（ISO、管理层、IT负责人）
2. 建立态势感知并记录
3. 激活沟通计划（内部、客户、当局）
4. 按文档化的DR计划恢复
5. 事后审查，总结经验教训并调整计划

所有NIS2要求到文档、实施和协同效应的完整映射。

§30 BSIG – 风险管理措施

其他BSIG义务

CRA协同效应

AI法案协同效应

标准

静态数据加密

• 所有服务器系统的全盘加密
• 敏感数据的数据库加密
• 备份加密（AES-256）

传输数据加密

• 所有外部连接使用TLS 1.2+，优先TLS 1.3
• 服务器管理使用SSH（Ed25519密钥）
• 远程访问内部系统使用VPN

密钥管理

证书管理

• Let's Encrypt用于公共TLS证书（自动续期）
• 证书到期监控
• 文档化的证书续期和撤销流程

年度安全审查

KPI

渗透测试

• 外部测试 – 由独立提供商每年进行
• 内部测试 – 重大变更时事件驱动
• 范围 – 基础设施、Web应用、内部系统
• 结果利用 – 发现结果纳入风险分析和行动计划

PDCA循环

分级

事件响应流程

1. 检测与报告

• 监控系统、日志分析和人工检测
• 每位员工有义务立即报告可疑事件
• 集中向信息安全官（ISO）报告

2. 分析与评估

• 按严重程度分级
• 确定受影响的系统、数据和客户
• 评估：是否为§32 BSIG下的可报告事件？

3. 遏制

• 立即隔离受损系统
• 封锁受影响的凭证
• 服务中断时激活故障转移系统
• 修复前保全证据

4. 消除与恢复

• 消除攻击原因（恶意软件、被入侵账户）
• 数据丢失时从备份恢复
• 重新投入使用前验证系统完整性
• 轮换所有可能被入侵的凭证

5. 事后审查

• 根因分析的事后总结
• 记录并制定改进措施
• 必要时更新风险分析

§32 BSIG报告义务

本文档描述了BAUER GROUP对NIS 2指令 (EU) 2022/2555及德国NIS2实施法 (NIS2UmsuCG) 要求的实施情况。涵盖BSIG §30(2)规定的所有十项风险管理措施，以及§32（报告义务）、§33（注册）和§38（管理层职责）的相关义务。

范围

互补文档

文档结构

法律来源

适用性

NIS2指令区分两类实体：

§30 BSIG – 十项风险管理措施

其他义务

信息安全政策

BAUER GROUP运营信息安全管理体系（ISMS），涵盖机密性、完整性、可用性和真实性的保护目标。信息安全政策由管理层每年审查和批准。

系统化风险分析

风险处理选项

资产清单

所有IT系统、组件和流程均记录在中央清单中：

• 服务器系统 – 物理和虚拟服务器，含位置、用途和责任人
• 网络组件 – 防火墙、交换机、路由器，含固件版本
• 应用程序 – 自研和第三方软件，含许可证和支持状态
• 数据资产 – 按保护需求分类（普通、高、极高）
• 云服务 – 外部服务，含提供商、位置和合同状态

标准导向

• ISO/IEC 27001:2022 – 信息安全管理体系
• BSI IT-Grundschutz – 风险分析方法框架
• 实施条例 (EU) 2024/2690 – NIS2详细技术要求

供应商概览

评估标准

审查周期

漏洞检测

补丁管理

安全开发

• 安全设计 – 从设计阶段起纳入安全要求
• 代码审查 – 安全相关更改的四眼原则
• 自动化测试 – CI/CD管道中的Lint、构建、安全扫描
• 依赖锁定 – 版本化和验证的依赖