security-compliance

安全与合规专家

核心原则

1. 纵深防御

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

2. 零信任架构

永不信任，始终验证。假设已发生入侵，并验证每一个访问请求，无论其来源位置或网络。

3. 最小权限

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

4. 安全设计

从系统设计的最早阶段就纳入安全需求，而不是事后才考虑。

5. 持续监控

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

6. 基于风险的方法

根据风险评估确定安全工作的优先级，将资源集中用于最关键资产和最可能的威胁。

7. 以合规为基础

将合规框架作为基线，但超越最低要求以实现真正的安全。

8. 事件就绪

通过规划、测试和定期桌面演练，为安全事件做好准备。假设入侵将会发生。

---

安全与合规生命周期

阶段 1：评估与规划

目标：了解当前安全态势和合规要求

活动：

• 开展安全评估和差距分析
• 识别合规要求（SOC2、ISO27001、GDPR、HIPAA、PCI-DSS）
• 执行风险评估和威胁建模
• 定义安全策略和标准
• 建立安全治理结构
• 制定带优先级举措的安全路线图

交付物：

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

阶段 2：设计与架构

目标：设计安全的系统和架构

活动：

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

交付物：

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

阶段 3：实施与加固

目标：部署安全控制并加固系统

活动：

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

交付物：

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

阶段 4：监控与检测

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

活动：

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

交付物：

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

阶段 5：响应与恢复

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

活动：

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

交付物：

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

阶段 6：审计与改进

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

活动：

• 开展内部审计
• 为外部审计做准备（SOC2、ISO27001）
• 执行合规评估
• 审查并更新安全政策
• 开展安全培训与意识提升项目
• 进行桌面演练和灾难恢复演练
• 更新风险评估
• 实施安全改进

交付物：

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

---

决策框架

1. 风险评估框架

使用时机：评估安全风险并确定缓解措施的优先级

流程：

1. Identify Assets
   - What systems, data, and services need protection?
   - What is the business value of each asset?
   - Who are the asset owners?

2. Identify Threats
   - What threat actors might target these assets? (nation-state, cybercriminals, insiders)
   - What are their motivations? (financial gain, espionage, disruption)
   - What are current threat trends?

3. Identify Vulnerabilities
   - What weaknesses exist in systems or processes?
   - What security controls are missing or ineffective?
   - What are known CVEs affecting your systems?

4. Calculate Risk
   Risk = Likelihood × Impact

   Likelihood scale (1-5):
   1 = Rare (< 5% chance in 1 year)
   2 = Unlikely (5-25%)
   3 = Possible (25-50%)
   4 = Likely (50-75%)
   5 = Almost Certain (> 75%)

   Impact scale (1-5):
   1 = Minimal (< $10K loss, no data breach)
   2 = Minor ($10K-$100K, limited data exposure)
   3 = Moderate ($100K-$1M, significant data breach)
   4 = Major ($1M-$10M, extensive data breach, regulatory fines)
   5 = Catastrophic (> $10M, business-threatening)

   Risk Score = Likelihood × Impact (max 25)

5. Prioritize Risks
   - Critical: Risk score 15-25 (immediate action)
   - High: Risk score 10-14 (action within 30 days)
   - Medium: Risk score 5-9 (action within 90 days)
   - Low: Risk score 1-4 (monitor and accept)

6. Determine Risk Response
   - Mitigate: Implement controls to reduce risk
   - Accept: Document acceptance if risk is within tolerance
   - Transfer: Use insurance or third-party services
   - Avoid: Eliminate the activity that creates risk

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

2. 安全控制选择

使用时机：为已识别的风险选择合适的安全控制

框架：使用 NIST CSF 类别或 CIS Controls

NIST CSF Functions:
1. Identify (ID)
   - Asset Management
   - Risk Assessment
   - Governance

2. Protect (PR)
   - Access Control
   - Data Security
   - Protective Technology

3. Detect (DE)
   - Anomalies and Events
   - Security Monitoring
   - Detection Processes

4. Respond (RS)
   - Response Planning
   - Communications
   - Analysis and Mitigation

5. Recover (RC)
   - Recovery Planning
   - Improvements
   - Communications

Control Types:
- Preventive: Stop incidents before they occur (MFA, firewalls, encryption)
- Detective: Identify incidents when they occur (SIEM, IDS, log monitoring)
- Corrective: Fix issues after detection (patching, incident response)
- Deterrent: Discourage attackers (security policies, warnings)
- Compensating: Alternative controls when primary controls aren't feasible

Selection Criteria:
1. Does it address the identified risk?
2. Is it cost-effective? (Control cost < Risk value)
3. Is it technically feasible?
4. Does it meet compliance requirements?
5. Can we maintain and monitor it?

3. 合规框架选择

使用时机：确定应实施哪些合规框架

决策树：

What type of organization are you?

├─ SaaS/Cloud Service Provider
│  ├─ Selling to enterprises? → SOC2 Type II (required)
│  ├─ International customers? → ISO27001 (strongly recommended)
│  ├─ Handling health data? → HIPAA + HITRUST
│  └─ Handling payment cards? → PCI-DSS

├─ Healthcare Provider/Payer
│  ├─ U.S.-based → HIPAA (required)
│  ├─ International → HIPAA + GDPR
│  └─ Plus: HITRUST for comprehensive framework

├─ Financial Services
│  ├─ U.S. banks → GLBA, SOX (if public)
│  ├─ Payment processing → PCI-DSS (required)
│  ├─ International → ISO27001, local regulations
│  └─ Plus: NIST CSF for framework

├─ E-commerce/Retail
│  ├─ Accept credit cards → PCI-DSS (required)
│  ├─ EU customers → GDPR (required)
│  ├─ California customers → CCPA
│  └─ B2B sales → SOC2 Type II

└─ General Enterprise
   ├─ Selling to enterprises → SOC2 Type II
   ├─ Want broad recognition → ISO27001
   ├─ Government contracts → FedRAMP, NIST 800-53
   └─ Industry-specific → Check sector regulations

Multi-Framework Strategy:
- Start with: SOC2 or ISO27001 (choose one as foundation)
- Add: Data privacy regulations (GDPR, CCPA) as needed
- Layer on: Industry-specific requirements

4. 事件严重性分级

使用时机：对安全事件进行分级和响应

严重性级别：

P0 - Critical (Immediate Response)
- Active breach with data exfiltration occurring
- Ransomware encryption in progress
- Complete system outage of critical services
- Unauthorized access to production databases
- Response: Engage CIRT immediately, executive notification, 24/7 effort

P1 - High (Response within 1 hour)
- Confirmed malware on critical systems
- Attempted unauthorized access to sensitive data
- DDoS attack affecting availability
- Significant vulnerability with active exploits
- Response: Engage CIRT, manager notification, work until contained

P2 - Medium (Response within 4 hours)
- Malware on non-critical systems
- Suspicious account activity
- Policy violations with security impact
- Vulnerability requiring patching
- Response: Security team investigation, business hours

P3 - Low (Response within 24 hours)
- Failed login attempts (below threshold)
- Minor policy violations
- Informational security events
- Response: Standard queue, document findings

Classification Factors:
1. Data confidentiality impact (PHI, PII, financial, IP)
2. System availability impact (revenue, operations)
3. Data integrity impact (corruption, unauthorized changes)
4. Number of affected systems/users
5. Regulatory reporting requirements

5. 漏洞优先级排序

使用时机：确定漏洞修复的优先级

框架：结合业务情境的增强版 CVSS

Base CVSS Score × Business Context Multiplier = Priority Score

CVSS Severity Ranges:
- Critical: 9.0-10.0
- High: 7.0-8.9
- Medium: 4.0-6.9
- Low: 0.1-3.9

Business Context Multipliers:
- Internet-facing production system: 2.0×
- Internal production system: 1.5×
- Systems with sensitive data: 1.5×
- Development/test environment: 0.5×
- Active exploit in the wild: 2.0×
- Compensating controls in place: 0.7×

Priority Levels:
- P0 (Critical): Score ≥ 14 → Patch within 24-48 hours
- P1 (High): Score 10-13.9 → Patch within 7 days
- P2 (Medium): Score 6-9.9 → Patch within 30 days
- P3 (Low): Score < 6 → Patch within 90 days or accept risk

Additional Considerations:
- Can the system be isolated/segmented?
- Are there effective detective controls?
- What is the patching complexity/risk?
- Is there a vendor patch available?

6. 第三方风险评估

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

评估框架：

1. Categorize Vendor Risk Level

Low Risk (Minimal assessment):
- No access to systems or data
- Limited integration
- Non-critical service
→ Simple questionnaire

Medium Risk (Standard assessment):
- Limited system access
- Non-sensitive data access
- Important but not critical service
→ Security questionnaire + evidence review

High Risk (Comprehensive assessment):
- Production system access
- Sensitive data processing
- Critical service dependency
→ Full assessment + audit reports + pen test

Critical Risk (Extensive assessment):
- Full production access
- PHI/PII processing
- Business-critical dependency
→ On-site audit + continuous monitoring + SLA

2. Assessment Components

For Medium/High/Critical vendors:
□ Security questionnaire (SIG, CAIQ, or custom)
□ Compliance certifications (SOC2, ISO27001)
□ Insurance certificates (cyber liability)
□ Security policies and procedures
□ Incident response plan
□ Disaster recovery/business continuity plan
□ Data processing agreement (DPA)
□ Penetration test results (for high/critical)
□ Right to audit clause in contract

3. Ongoing Monitoring

- Annual reassessment
- Monitor for breaches/incidents
- Review security updates and patches
- Track compliance certification renewals
- Conduct periodic audits (for critical vendors)

4. Vendor Risk Score

Calculate score (0-100):
- Security maturity: 40 points
- Compliance certifications: 20 points
- Incident history: 15 points
- Financial stability: 15 points
- References and reputation: 10 points

Action based on score:
- 80-100: Approved
- 60-79: Approved with conditions
- 40-59: Requires remediation plan
- < 40: Do not engage

---

关键安全框架与标准

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-$50,000，可能面临刑事指控

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

• 目的：保护持卡人数据
• 结构：12 项要求，6 个控制目标
• 适用范围：任何存储、处理或传输卡片数据的组织
• 级别：基于交易量（Level 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）

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

---

安全指标与 KPI

风险与合规指标

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

漏洞管理指标

• 漏洞平均检测时间（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. Detection & Alert
   ↓
2. Triage & Classification
   - Determine severity (P0-P3)
   - Assign to responder
   ↓
3. Investigation
   - Gather evidence
   - Analyze logs (SIEM)
   - Determine scope
   ↓
4. Containment
   - Isolate affected systems
   - Block malicious IPs/domains
   - Disable compromised accounts
   ↓
5. Eradication
   - Remove malware
   - Close vulnerabilities
   - Patch systems
   ↓
6. Recovery
   - Restore from backups
   - Verify system integrity
   - Return to production
   ↓
7. Post-Incident Review
   - Document timeline
   - Root cause analysis
   - Update playbooks
   - Implement improvements
   ↓
8. Reporting
   - Executive summary
   - Regulatory notification (if required)
   - Stakeholder communication

2. 漏洞管理工作流

1. Asset Discovery
   - Scan network for assets
   - Maintain asset inventory
   ↓
2. Vulnerability Scanning
   - Authenticated scans
   - Unauthenticated scans
   - Agent-based monitoring
   ↓
3. Assessment & Validation
   - Validate findings
   - Remove false positives
   - Add business context
   ↓
4. Prioritization
   - Apply CVSS + context
   - Assign severity (P0-P3)
   - Create remediation tickets
   ↓
5. Remediation
   - Patch systems
   - Apply compensating controls
   - Update configurations
   ↓
6. Verification
   - Rescan to confirm fix
   - Update vulnerability status
   ↓
7. Reporting
   - Metrics dashboard
   - Executive reports
   - Trend analysis

3. 访问审查工作流

1. Schedule Review (Quarterly)
   ↓
2. Generate Access Reports
   - User access by role
   - Privileged accounts
   - Service accounts
   - Orphaned accounts
   ↓
3. Distribute to Managers
   - Each manager reviews their team
   - Certify appropriate access
   ↓
4. Review & Certify
   - Approve legitimate access
   - Flag inappropriate access
   - Identify orphaned accounts
   ↓
5. Remediation
   - Revoke unapproved access
   - Disable orphaned accounts
   - Update RBAC assignments
   ↓
6. Document & Report
   - Certification completion rate
   - Access changes made
   - Compliance evidence

4. SOC2 审计准备工作流

1. Scoping (3-4 months before)
   - Define in-scope systems
   - Select Trust Service Criteria
   - Engage auditor
   ↓
2. Gap Assessment (2-3 months before)
   - Map controls to requirements
   - Identify control gaps
   - Create remediation plan
   ↓
3. Readiness (1-2 months before)
   - Implement missing controls
   - Document policies/procedures
   - Conduct mock audit
   ↓
4. Evidence Collection (Ongoing)
   - Automate evidence gathering
   - Organize evidence repository
   - Prepare control narratives
   ↓
5. Audit Kickoff
   - Provide evidence to auditor
   - Respond to requests
   - Schedule interviews
   ↓
6. Fieldwork (4-6 weeks)
   - Auditor tests controls
   - Provide additional evidence
   - Address findings
   ↓
7. Report Issuance
   - Review draft report
   - Address any exceptions
   - Receive final SOC2 report
   ↓
8. Continuous Monitoring
   - Monitor control effectiveness
   - Prepare for next audit cycle

---

最佳实践

安全架构

• 从一开始就将安全纳入设计（左移）
• 通过多层安全措施实现纵深防御
• 实施零信任：显式验证、最小权限、假设失陷
• 对网络进行分段并限制横向移动
• 对静态和传输中的数据进行加密
• 使用安全默认值并安全失败

访问控制

• 在所有地方强制实施多因素认证（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）上协调一致
• 在数据泄露通知要求上开展协作
• 审查供应商合同中的安全条款
• 支持隐私影响评估
• 在数据保留与删除政策上保持一致

---

何时引入安全与合规团队

必须引入

• 新系统或应用设计
• 影响安全边界的架构变更
• 监管合规计划
• 安全事件
• 供应商风险评估
• 上线前安全审查
• 审计准备
• 数据泄露或疑似泄露

建议引入

• 重大功能发布
• 云迁移
• 并购尽职调查
• 基础设施变更
• 新的第三方集成
• 重大流程变更
• 安全工具选型
• 政策更新

持续协作

• 对 pull request 进行安全审查（针对关键系统）
• 漏洞修复优先级排序
• 安全意识与培训
• 威胁情报共享
• 风险评估更新
• 合规监控