名称: 安全合规描述: 指导安全专业人士实施深度防御安全架构，实现行业框架合规（SOC2、ISO27001、GDPR、HIPAA），进行威胁建模和风险评估，管理安全运维和事件响应，并将安全嵌入整个SDLC。

安全与合规专家

核心原则

1. 深度防御

应用多层安全控制，以便当一层失效时，其他层提供保护。绝不依赖单一安全机制。

2. 零信任架构

永不信任，始终验证。假设存在漏洞，无论位置或网络如何，验证每个访问请求。

3. 最小权限

授予用户和系统执行其功能所需的最小访问权限。定期审查和撤销未使用的权限。

4. 安全设计

从系统设计的最早阶段集成安全要求，而不是事后添加。

5. 持续监控

实施持续监控和警报，实时检测异常和安全事件。

6. 基于风险的方法

基于风险评估优先处理安全工作，将资源集中在最关键资产和最可能威胁上。

7. 合规作为基础

使用合规框架作为基线，但超越最低要求以实现实际安全。

8. 事件准备

通过规划、测试和定期桌面演练准备安全事件。假设会发生妥协。

安全与合规生命周期

阶段1：评估与计划

目标: 了解当前安全状况和合规要求

活动:

进行安全评估和差距分析
识别合规要求（SOC2、ISO27001、GDPR、HIPAA、PCI-DSS）
执行风险评估和威胁建模
定义安全政策和标准
建立安全治理结构
创建安全路线图，优先处理举措

交付物:

风险登记册，包含优先风险
合规差距分析报告
安全架构文档
安全政策和程序
安全路线图和预算

阶段2：设计与架构

目标: 设计安全系统和架构

活动:

设计深度防御架构
实施零信任网络架构
设计身份和访问管理（IAM）系统
架构数据保护和加密解决方案
设计安全CI/CD流水线
为应用和系统创建威胁模型
定义安全控制和补偿控制

交付物:

安全架构图
威胁模型（STRIDE、PASTA或攻击树）
带安全边界的数据流程图
加密和密钥管理设计
IAM设计，含RBAC/ABAC模型
安全控制矩阵

阶段3：实施与加固

目标: 部署安全控制和加固系统

活动:

实施安全控制（预防性、检测性、纠正性）
配置安全工具（SIEM、EDR、CASB、WAF、IDS/IPS）
加固操作系统和应用程序
实施静态和传输中加密
部署多因素认证（MFA）
配置日志和监控
实施数据丢失防护（DLP）
建立漏洞管理程序

交付物:

加固基线和配置标准
部署的安全工具和控制
加密实施
MFA部署
安全监控仪表板
漏洞管理程序

阶段4：监控与检测

目标: 持续监控威胁和异常

活动:

监控安全日志和事件（SIEM）
分析安全警报和异常
进行威胁狩猎
执行漏洞扫描和渗透测试
监控合规控制
跟踪安全指标和KPIs
审查访问日志和特权账户活动
分析威胁情报源

交付物:

安全运营中心（SOC）运行手册
警报分诊和升级程序
威胁狩猎剧本
漏洞扫描报告
渗透测试报告
安全指标仪表板
合规监控报告

阶段5：响应与恢复

目标: 响应安全事件并恢复运营

活动:

执行事件响应计划
遏制和根除威胁
执行取证分析
恢复受影响系统
进行事件后审查
根据经验教训更新安全控制
向利益相关者和监管机构报告事件
改进检测规则和响应程序

交付物:

事件响应报告
取证分析结果
根本原因分析
修复计划
更新的事件响应剧本
监管违规通知（如需要）
事件后审查和建议

阶段6：审计与改进

目标: 验证合规并持续改进安全

活动:

进行内部审计
准备外部审计（SOC2、ISO27001）
执行合规评估
审查和更新安全政策
进行安全培训和意识计划
进行桌面演练和灾难恢复演练
更新风险评估
实施安全改进

交付物:

审计报告（内部和外部）
SOC2 Type II报告
ISO27001认证
合规证明
更新的政策和程序
培训完成指标
桌面演练结果
持续改进计划

决策框架

1. 风险评估框架

何时使用: 评估安全风险并优先处理缓解工作

流程:

1. 识别资产
   - 需要保护什么系统、数据和服务？
   - 每个资产的业务价值是什么？
   - 谁是资产所有者？

2. 识别威胁
   - 哪些威胁行为者可能针对这些资产？（国家行为体、网络犯罪分子、内部人员）
   - 他们的动机是什么？（财务收益、间谍活动、破坏）
   - 当前威胁趋势是什么？

3. 识别漏洞
   - 系统或流程中存在什么弱点？
   - 哪些安全控制缺失或无效？
   - 哪些已知CVE影响您的系统？

4. 计算风险
   风险 = 可能性 × 影响

   可能性等级（1-5）：
   1 = 罕见（一年内机会<5%）
   2 = 不太可能（5-25%）
   3 = 可能（25-50%）
   4 = 很可能（50-75%）
   5 = 几乎确定（>75%）

   影响等级（1-5）：
   1 = 最小（损失<1万美元，无数据泄露）
   2 = 较小（1万-10万美元，有限数据暴露）
   3 = 中等（10万-100万美元，显著数据泄露）
   4 = 主要（100万-1000万美元，广泛数据泄露，监管罚款）
   5 = 灾难性（>1000万美元，威胁业务）

   风险评分 = 可能性 × 影响（最高25）

5. 优先处理风险
   - 关键：风险评分15-25（立即行动）
   - 高：风险评分10-14（30天内行动）
   - 中：风险评分5-9（90天内行动）
   - 低：风险评分1-4（监控并接受）

6. 确定风险响应
   - 缓解：实施控制以减少风险
   - 接受：记录接受，如果风险在容忍范围内
   - 转移：使用保险或第三方服务
   - 避免：消除产生风险的活动

输出: 风险登记册，包含优先风险和缓解计划

2. 安全控制选择

何时使用: 为识别风险选择适当安全控制

框架: 使用NIST CSF类别或CIS控制

NIST CSF功能：
1. 识别（ID）
   - 资产管理
   - 风险评估
   - 治理

2. 保护（PR）
   - 访问控制
   - 数据安全
   - 防护技术

3. 检测（DE）
   - 异常和事件
   - 安全监控
   - 检测过程

4. 响应（RS）
   - 响应规划
   - 沟通
   - 分析和缓解

5. 恢复（RC）
   - 恢复规划
   - 改进
   - 沟通

控制类型：
- 预防性：在事件发生前阻止（MFA、防火墙、加密）
- 检测性：在事件发生时识别（SIEM、IDS、日志监控）
- 纠正性：在检测后修复问题（修补、事件响应）
- 威慑性：劝阻攻击者（安全政策、警告）
- 补偿性：当主要控制不可行时的替代控制

选择标准：
1. 它是否解决识别风险？
2. 是否成本效益高？（控制成本<风险价值）
3. 是否技术可行？
4. 是否满足合规要求？
5. 我们能否维护和监控它？

3. 合规框架选择

何时使用: 确定实施哪些合规框架

决策树:

您是什么类型的组织？

├─ SaaS/云服务提供商
│  ├─ 向企业销售？ → SOC2 Type II（必需）
│  ├─ 国际客户？ → ISO27001（强烈推荐）
│  ├─ 处理健康数据？ → HIPAA + HITRUST
│  └─ 处理支付卡？ → PCI-DSS

├─ 医疗保健提供者/支付者
│  ├─ 基于美国 → HIPAA（必需）
│  ├─ 国际 → HIPAA + GDPR
│  └─ 加上：HITRUST用于综合框架

├─ 金融服务
│  ├─ 美国银行 → GLBA、SOX（如公开）
│  ├─ 支付处理 → PCI-DSS（必需）
│  ├─ 国际 → ISO27001、本地法规
│  └─ 加上：NIST CSF作为框架

├─ 电子商务/零售
│  ├─ 接受信用卡 → PCI-DSS（必需）
│  ├─ 欧盟客户 → GDPR（必需）
│  ├─ 加州客户 → CCPA
│  └─ B2B销售 → SOC2 Type II

└─ 一般企业
   ├─ 向企业销售 → SOC2 Type II
   ├─ 希望广泛认可 → ISO27001
   ├─ 政府合同 → FedRAMP、NIST 800-53
   └─ 行业特定 → 检查部门法规

多框架策略：
- 开始：SOC2或ISO27001（选择一个作为基础）
- 添加：数据隐私法规（GDPR、CCPA），根据需要
- 层叠：行业特定要求

4. 事件严重性分类

何时使用: 分诊和响应安全事件

严重性级别:

P0 - 关键（立即响应）
- 活跃违规，数据外泄发生
- 勒索软件加密进行中
- 关键服务完全中断
- 未经授权访问生产数据库
- 响应：立即参与CIRT，执行层通知，24/7努力

P1 - 高（1小时内响应）
- 关键系统上确认恶意软件
- 尝试未经授权访问敏感数据
- DDoS攻击影响可用性
- 具有活跃利用的显著漏洞
- 响应：参与CIRT，经理通知，工作至遏制

P2 - 中（4小时内响应）
- 非关键系统上恶意软件
- 可疑账户活动
- 具有安全影响的政策违规
- 需要修补的漏洞
- 响应：安全团队调查，工作时间

P3 - 低（24小时内响应）
- 登录尝试失败（低于阈值）
- 轻微政策违规
- 信息性安全事件
- 响应：标准队列，记录发现

分类因素：
1. 数据机密性影响（PHI、PII、财务、IP）
2. 系统可用性影响（收入、运营）
3. 数据完整性影响（损坏、未经授权更改）
4. 受影响系统/用户数量
5. 监管报告要求

5. 漏洞优先处理

何时使用: 优先处理漏洞修复

框架: 增强CVSS，带业务上下文

基础CVSS评分 × 业务上下文乘数 = 优先级评分

CVSS严重性范围：
- 关键：9.0-10.0
- 高：7.0-8.9
- 中：4.0-6.9
- 低：0.1-3.9

业务上下文乘数：
- 面向互联网的生产系统：2.0×
- 内部生产系统：1.5×
- 带敏感数据的系统：1.5×
- 开发/测试环境：0.5×
- 野外活跃利用：2.0×
- 已部署补偿控制：0.7×

优先级级别：
- P0（关键）：评分≥14 → 24-48小时内修补
- P1（高）：评分10-13.9 → 7天内修补
- P2（中）：评分6-9.9 → 30天内修补
- P3（低）：评分<6 → 90天内修补或接受风险

额外考虑：
- 系统能否隔离/分段？
- 是否有有效检测控制？
- 修补复杂性/风险是什么？
- 是否有供应商补丁可用？

6. 第三方风险评估

何时使用: 评估供应商和合作伙伴的安全风险

评估框架:

1. 分类供应商风险级别

低风险（最小评估）：
- 无系统或数据访问
- 有限集成
- 非关键服务
→ 简单问卷

中风险（标准评估）：
- 有限系统访问
- 非敏感数据访问
- 重要但不关键服务
→ 安全问卷 + 证据审查

高风险（全面评估）：
- 生产系统访问
- 敏感数据处理
- 关键服务依赖
→ 全面评估 + 审计报告 + 渗透测试

关键风险（广泛评估）：
- 完全生产访问
- PHI/PII处理
- 业务关键依赖
→ 现场审计 + 持续监控 + SLA

2. 评估组件

中/高/关键供应商：
□ 安全问卷（SIG、CAIQ或自定义）
□ 合规认证（SOC2、ISO27001）
□ 保险证书（网络责任）
□ 安全政策和程序
□ 事件响应计划
□ 灾难恢复/业务连续性计划
□ 数据处理协议（DPA）
□ 渗透测试结果（高/关键）
□ 合同中的审计权条款

3. 持续监控

- 年度重新评估
- 监控违规/事件
- 审查安全更新和补丁
- 跟踪合规认证续订
- 进行定期审计（关键供应商）

4. 供应商风险评分

计算评分（0-100）：
- 安全成熟度：40点
- 合规认证：20点
- 事件历史：15点
- 财务稳定性：15点
- 参考和声誉：10点

基于评分的行动：
- 80-100：批准
- 60-79：批准，带条件
- 40-59：需要修复计划
- <40：不参与

关键安全框架与标准

NIST网络安全框架（CSF）

目的: 基于风险的框架，改善网络安全
结构: 5功能、23类别、108子类别
最适合: 一般组织、政府承包商
成熟度模型: 第1级（部分）到第4级（自适应）

CIS关键安全控制

目的: 优先操作集，用于网络防御
结构: 18控制，带实施组（IG1、IG2、IG3）
最适合: 实际实施指导
重点: 防御常见攻击模式

ISO/IEC 27001

目的: 国际标准，信息安全管理
结构: 14领域、114控制（附录A）
最适合: 国际认可、正式认证
要求: ISMS（信息安全管理体系）

SOC 2 Type II

目的: 服务组织控制，安全和可用性
结构: 信任服务标准（安全、可用性、机密性、处理完整性、隐私）
最适合: SaaS公司、云服务提供商
审计: 3-12个月观察期

NIST 800-53

目的: 联邦系统安全控制
结构: 20家族、1000+控制
最适合: 政府承包商、FedRAMP
基线: 低、中、高影响系统

GDPR（通用数据保护条例）

目的: 欧盟数据隐私法规
范围: 任何处理欧盟居民数据的组织
要求: 法律依据、同意、数据主体权利、违规通知
处罚: 最高全球收入的4%或2000万欧元

HIPAA（健康保险可移植性和责任法案）

目的: 保护健康信息（PHI）
范围: 医疗保健提供者、支付者、业务伙伴
要求: 行政、物理、技术保障
处罚: 每违规100-50000美元，可能刑事指控

PCI-DSS（支付卡行业数据安全标准）

目的: 保护持卡人数据
结构: 12要求、6控制目标
范围: 任何存储、处理或传输卡数据的组织
级别: 基于交易量（级别1-4）

核心安全域

1. 身份与访问管理（IAM）

认证机制（MFA、SSO、无密码）
授权模型（RBAC、ABAC、ReBAC）
特权访问管理（PAM）
身份治理和管理（IGA）
目录服务（Active Directory、LDAP、Okta、Auth0）

2. 网络安全

网络分段和微分段
防火墙（下一代、WAF、应用层）
入侵检测/预防（IDS/IPS）
VPN和安全远程访问
零信任网络架构（ZTNA）
DDoS防护

3. 数据安全

静态和传输中加密（AES-256、TLS 1.3）
密钥管理（KMS、HSM）
数据分类和标记
数据丢失防护（DLP）
数据库安全（加密、掩码、令牌化）
秘密管理（Vault、AWS Secrets Manager）

4. 应用安全

安全SDLC和DevSecOps
SAST（静态应用安全测试）
DAST（动态应用安全测试）
SCA（软件组合分析）
安全代码审查
OWASP Top 10缓解

5. 云安全

云安全态势管理（CSPM）
云访问安全代理（CASB）
容器安全（镜像扫描、运行时防护）
无服务器安全
基础设施即代码（IaC）安全扫描
多云安全架构

6. 终端安全

终端检测和响应（EDR）
反病毒和反恶意软件
主机防火墙
设备加密（BitLocker、FileVault）
移动设备管理（MDM）
补丁管理

7. 安全运维

安全信息和事件管理（SIEM）
安全编排、自动化和响应（SOAR）
威胁情报平台（TIP）
威胁狩猎
漏洞管理
渗透测试和红队演练

8. 事件响应

事件响应计划和剧本
计算机取证和调查
恶意软件分析
威胁遏制和根除
事件后审查和经验教训
监管违规通知

9. 治理、风险与合规（GRC）

安全政策和程序
风险评估和管理
合规管理和审计
安全意识培训
供应商风险管理
业务连续性和灾难恢复

安全指标与KPIs

风险与合规指标

开放关键/高风险数量
风险修复时间（平均修复时间）
合规审计发现（开放/关闭）
合规控制有效率
政策确认完成率
培训完成率

漏洞管理指标

平均检测时间（MTTD）漏洞
平均补丁时间（MTTP）
漏洞积压（总开放、按严重性）
补丁合规率（SLA内修补系统百分比）
漏洞复发率

事件响应指标

平均检测时间（MTTD）事件
平均响应时间（MTTR）
平均遏制时间（MTTC）
平均恢复时间（MTTR）
按严重性事件数量
事件复发率
误报率

安全运维指标

SIEM警报量（总、按严重性）
警报分诊时间
警报误报率
安全工具覆盖率（监控资产百分比）
威胁狩猎覆盖率（审查环境百分比）
渗透测试发现

访问管理指标

MFA采用率
特权账户审查完成率
访问认证完成率
孤儿账户数量
密码政策合规率
登录尝试失败率

意识与文化指标

网络钓鱼模拟点击率
安全培训完成率
安全意识测验分数
安全政策违规
安全相关帮助台票据

安全工具生态系统

SIEM（安全信息与事件管理）

Splunk Enterprise Security
IBM QRadar
Microsoft Sentinel
Elastic Security
Sumo Logic

EDR/XDR（终端/扩展检测与响应）

CrowdStrike Falcon
SentinelOne
Microsoft Defender for Endpoint
Palo Alto Cortex XDR
Carbon Black

漏洞管理

Tenable Nessus/Tenable.io
Qualys VMDR
Rapid7 InsightVM
Greenbone OpenVAS（开源）

云安全

Wiz
Prisma Cloud（Palo Alto）
Lacework
Orca Security
AWS Security Hub / Azure Security Center / GCP Security Command Center

SAST/DAST

Snyk
Veracode
Checkmarx
SonarQube
OWASP ZAP（开源）

容器安全

Aqua Security
Sysdig Secure
Prisma Cloud Compute
Trivy（开源）

秘密管理

HashiCorp Vault
AWS Secrets Manager
Azure Key Vault
CyberArk

身份与访问

Okta
Auth0
Azure AD / Entra ID
Ping Identity
CyberArk（PAM）

常见安全工作流

1. 安全事件响应工作流

1. 检测与警报
   ↓
2. 分诊与分类
   - 确定严重性（P0-P3）
   - 分配给响应者
   ↓
3. 调查
   - 收集证据
   - 分析日志（SIEM）
   - 确定范围
   ↓
4. 遏制
   - 隔离受影响系统
   - 阻止恶意IP/域名
   - 禁用被入侵账户
   ↓
5. 根除
   - 移除恶意软件
   - 关闭漏洞
   - 修补系统
   ↓
6. 恢复
   - 从备份恢复
   - 验证系统完整性
   - 返回生产
   ↓
7. 事件后审查
   - 记录时间线
   - 根本原因分析
   - 更新剧本
   - 实施改进
   ↓
8. 报告
   - 执行摘要
   - 监管通知（如需要）
   - 利益相关者沟通

2. 漏洞管理工作流

1. 资产发现
   - 扫描网络资产
   - 维护资产清单
   ↓
2. 漏洞扫描
   - 认证扫描
   - 非认证扫描
   - 代理监控
   ↓
3. 评估与验证
   - 验证发现
   - 移除误报
   - 添加业务上下文
   ↓
4. 优先处理
   - 应用CVSS + 上下文
   - 分配严重性（P0-P3）
   - 创建修复票据
   ↓
5. 修复
   - 修补系统
   - 应用补偿控制
   - 更新配置
   ↓
6. 验证
   - 重新扫描确认修复
   - 更新漏洞状态
   ↓
7. 报告
   - 指标仪表板
   - 执行报告
   - 趋势分析

3. 访问审查工作流

1. 安排审查（季度）
   ↓
2. 生成访问报告
   - 用户按角色访问
   - 特权账户
   - 服务账户
   - 孤儿账户
   ↓
3. 分发给经理
   - 每位经理审查其团队
   - 认证适当访问
   ↓
4. 审查与认证
   - 批准合法访问
   - 标记不当访问
   - 识别孤儿账户
   ↓
5. 修复
   - 撤销未批准访问
   - 禁用孤儿账户
   - 更新RBAC分配
   ↓
6. 记录与报告
   - 认证完成率
   - 访问更改
   - 合规证据

4. SOC2审计准备工作流

1. 范围界定（前3-4个月）
   - 定义范围内系统
   - 选择信任服务标准
   - 参与审计师
   ↓
2. 差距评估（前2-3个月）
   - 映射控制到要求
   - 识别控制差距
   - 创建修复计划
   ↓
3. 准备（前1-2个月）
   - 实施缺失控制
   - 记录政策/程序
   - 进行模拟审计
   ↓
4. 证据收集（持续）
   - 自动化证据收集
   - 组织证据库
   - 准备控制叙述
   ↓
5. 审计启动
   - 提供证据给审计师
   - 响应请求
   - 安排访谈
   ↓
6. 实地工作（4-6周）
   - 审计师测试控制
   - 提供额外证据
   - 处理发现
   ↓
7. 报告发布
   - 审查草案报告
   - 处理任何例外
   - 接收最终SOC2报告
   ↓
8. 持续监控
   - 监控控制有效性
   - 准备下一审计周期

最佳实践

安全架构

从开始就以安全设计（左移）
应用深度防御，多层安全
实施零信任：显式验证、使用最小权限、假设漏洞
分段网络并限制横向移动
加密静态和传输中数据
使用安全默认值并安全失败

访问控制

强制执行多因素认证（MFA）处处
实施最小权限访问
使用即时（JIT）特权访问
定期审查和认证访问
终止时及时禁用账户
避免共享账户和服务账户滥用

安全运维

用SIEM集中日志
尽可能自动化检测和响应
维护事件响应计划并测试
进行定期威胁狩猎演练
保持漏洞修复SLA积极
通过桌面演练实践事件响应

应用安全

将安全集成到CI/CD（DevSecOps）
扫描代码漏洞（SAST、DAST、SCA）
遵循OWASP Top 10指南
为关键更改进行安全代码审查
实施安全API设计（认证、速率限制、输入验证）
使用安全头（CSP、HSTS、X-Frame-Options）

云安全

使用基础设施即代码（IaC）带安全扫描
启用云原生安全服务（GuardDuty、Security Hub）
实施CSPM监控配置错误
使用云原生加密和密钥管理
应用最小权限IAM政策
监控影子IT和未经授权资源

合规

将合规视为持续过程，非一次性
映射控制到多框架以效率
尽可能自动化证据收集
维护合规日历以截止日期
记录一切（如未记录，则不存在）
外部审计前进行内部审计

安全文化

使安全成为每个人责任
进行定期安全意识培训
运行网络钓鱼模拟以测试意识
奖励安全意识行为
创建清晰、可访问安全政策
培养鼓励报告安全问题的文化

与其他学科集成

与DevOps/平台工程

将安全扫描集成到CI/CD流水线
自动化安全测试和合规检查
实施基础设施即代码（IaC）安全
使用容器扫描和运行时防护
协调生产问题事件响应

与企业架构

对齐安全架构与企业架构
参与架构审查委员会
确保架构标准中安全要求
设计安全集成模式
定义安全参考架构

与IT运维

协调补丁管理和变更控制
协作监控和警报
联合安全与操作事件响应
对齐备份和灾难恢复程序
协调访问管理和特权访问

与产品管理

为新功能提供安全要求
参与新产品威胁建模
平衡安全与用户体验
建议隐私和合规影响
支持安全作为产品差异化因素

与法律/隐私

协调数据隐私法规（GDPR、CCPA）
协作违规通知要求
审查供应商合同安全条款
支持隐私影响评估
对齐数据保留和删除政策

何时参与安全与合规

必需参与

新系统或应用设计
影响安全边界的架构更改
监管合规举措
安全事件
供应商风险评估
生产前安全审查
审计准备
数据违规或疑似违规

持续协作

安全审查拉取请求（关键系统）
漏洞修复优先处理
安全意识和培训
威胁情报共享
风险评估更新
合规监控

名称: 安全合规 描述: 指导安全专业人士实施深度防御安全架构，实现行业框架合规（SOC2、ISO27001、GDPR、HIPAA），进行威胁建模和风险评估，管理安全运维和事件响应，并将安全嵌入整个SDLC。

安全与合规专家

核心原则

1. 深度防御

2. 零信任架构

3. 最小权限

4. 安全设计

5. 持续监控

6. 基于风险的方法

7. 合规作为基础

8. 事件准备

安全与合规生命周期

阶段1：评估与计划

阶段2：设计与架构

阶段3：实施与加固

阶段4：监控与检测

阶段5：响应与恢复

阶段6：审计与改进

决策框架

1. 风险评估框架

2. 安全控制选择

3. 合规框架选择

4. 事件严重性分类

5. 漏洞优先处理

6. 第三方风险评估

关键安全框架与标准

NIST网络安全框架（CSF）

CIS关键安全控制

ISO/IEC 27001

SOC 2 Type II

NIST 800-53

GDPR（通用数据保护条例）

HIPAA（健康保险可移植性和责任法案）

PCI-DSS（支付卡行业数据安全标准）

核心安全域

1. 身份与访问管理（IAM）

2. 网络安全

3. 数据安全

4. 应用安全

5. 云安全

6. 终端安全

7. 安全运维

8. 事件响应

9. 治理、风险与合规（GRC）

安全指标与KPIs

风险与合规指标

漏洞管理指标

事件响应指标

安全运维指标

访问管理指标

意识与文化指标

安全工具生态系统

SIEM（安全信息与事件管理）

EDR/XDR（终端/扩展检测与响应）

漏洞管理

云安全

SAST/DAST

容器安全

秘密管理

身份与访问

常见安全工作流

1. 安全事件响应工作流

2. 漏洞管理工作流

3. 访问审查工作流

4. SOC2审计准备工作流

最佳实践

安全架构

访问控制

安全运维

应用安全

云安全

合规

安全文化

与其他学科集成

与DevOps/平台工程

与企业架构

与IT运维

与产品管理

与法律/隐私

何时参与安全与合规

名称: 安全合规描述: 指导安全专业人士实施深度防御安全架构，实现行业框架合规（SOC2、ISO27001、GDPR、HIPAA），进行威胁建模和风险评估，管理安全运维和事件响应，并将安全嵌入整个SDLC。