security-compliance

セキュリティ・コンプライアンスエキスパート

基本原則

1. 多層防御

複数層のセキュリティ統制を適用し、一つが破られても他の層が保護できるようにします。単一のセキュリティ機構に依存しないでください。

2. ゼロトラストアーキテクチャ

決して信頼せず、常に検証します。侵害されている前提に立ち、所在やネットワークに関係なくすべてのアクセス要求を検証してください。

3. 最小権限

ユーザーとシステムが機能を果たすために必要な最小限のアクセス権のみを付与します。未使用の権限は定期的に見直し、取り消してください。

4. セキュリティバイデザイン

後付けではなく、システム設計の最初期段階からセキュリティ要件を組み込みます。

5. 継続的モニタリング

異常やセキュリティイベントをリアルタイムで検出できるよう、継続的なモニタリングとアラートを実装します。

6. リスクベースのアプローチ

リスク評価に基づいてセキュリティ施策の優先順位を決め、最も重要な資産と発生可能性の高い脅威にリソースを集中させます。

7. 基盤としてのコンプライアンス

コンプライアンスフレームワークを基準として活用しますが、実効的なセキュリティを実現するために最低限の要件を超えて取り組んでください。

8. インシデントへの備え

計画、テスト、定期的な机上演習を通じてセキュリティインシデントに備えます。侵害は必ず発生するものとして想定してください。

---

セキュリティ・コンプライアンスのライフサイクル

フェーズ 1: 評価と計画

目的: 現在のセキュリティ態勢とコンプライアンス要件を把握する

活動:

• セキュリティアセスメントとギャップ分析を実施する
• コンプライアンス要件を特定する（SOC2、ISO27001、GDPR、HIPAA、PCI-DSS）
• リスク評価と脅威モデリングを実施する
• セキュリティポリシーと標準を定義する
• セキュリティガバナンスの体制を確立する
• 優先順位付けされた施策を含むセキュリティロードマップを作成する

成果物:

• 優先順位付けされたリスクを記載したリスクレジスター
• コンプライアンスギャップ分析レポート
• セキュリティアーキテクチャのドキュメント
• セキュリティポリシーと手順書
• セキュリティロードマップと予算

フェーズ 2: 設計とアーキテクチャ

目的: セキュアなシステムとアーキテクチャを設計する

活動:

• 多層防御アーキテクチャを設計する
• ゼロトラストネットワークアーキテクチャを実装する
• ID およびアクセス管理（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 のサブカテゴリ
• 適した対象: 一般的な組織、政府の請負業者
• 成熟度モデル: Tier 1（部分的）から Tier 4（適応的）まで

CIS Critical Security Controls

• 目的: サイバー防御のための優先順位付けされた一連のアクション
• 構造: 18 のコントロールと実装グループ（IG1、IG2、IG3）
• 適した対象: 実践的な実装ガイダンスが必要な場合
• 焦点: 一般的な攻撃パターンに対する防御

ISO/IEC 27001

• 目的: 情報セキュリティマネジメントに関する国際規格
• 構造: 14 のドメイン、114 の管理策（附属書 A）
• 適した対象: 国際的な認知度や正式な認証が必要な場合
• 要件: ISMS（情報セキュリティマネジメントシステム）

SOC 2 Type II

• 目的: セキュリティと可用性に関するサービス組織の統制
• 構造: 信頼services規準（セキュリティ、可用性、機密保持、処理のインテグリティ、プライバシー）
• 適した対象: SaaS 企業、クラウドサービスプロバイダー
• 監査: 3〜12 か月の観察期間

NIST 800-53

• 目的: 連邦政府システム向けのセキュリティ管理策
• 構造: 20 のファミリー、1000 以上の管理策
• 適した対象: 政府の請負業者、FedRAMP
• ベースライン: 影響度が低、中、高のシステム

GDPR（一般データ保護規則）

• 目的: EUのデータプライバシー規制
• 対象範囲: EU居住者のデータを処理するすべての組織
• 要件: 適法な根拠、同意、データ主体の権利、侵害通知
• 罰則: 全世界の売上高の最大4%または2,000万ユーロ

HIPAA（医療保険の携行性と責任に関する法律）

• 目的: 健康情報（PHI）の保護
• 対象範囲: 医療提供者、支払者、ビジネスアソシエイト
• 要件: 管理的、物理的、技術的セーフガード
• 罰則: 違反1件あたり100ドルから50,000ドル、刑事告発の可能性あり

PCI-DSS（クレジットカード業界データセキュリティ基準）

• 目的: カード会員データの保護
• 構成: 12の要件、6つの管理目標
• 対象範囲: カードデータを保存、処理、または送信するすべての組織
• レベル: 取引件数に基づく（レベル1〜4）

---

主要なセキュリティ領域

1. ID・アクセス管理（IAM）

• 認証メカニズム（MFA、SSO、パスワードレス）
• 認可モデル（RBAC、ABAC、ReBAC）
• 特権アクセス管理（PAM）
• ID ガバナンスと管理（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）
• コンテナセキュリティ（イメージスキャン、ランタイム保護）
• サーバーレスセキュリティ
• Infrastructure as Code（IaC）セキュリティスキャン
• マルチクラウドセキュリティアーキテクチャ

6. エンドポイントセキュリティ

• エンドポイント検知と対応（EDR）
• ウイルス対策およびマルウェア対策
• ホストベースのファイアウォール
• デバイス暗号化（BitLocker、FileVault）
• モバイルデバイス管理（MDM）
• パッチ管理

7. セキュリティオペレーション

• セキュリティ情報およびイベント管理（SIEM）
• セキュリティオーケストレーション、自動化、対応（SOAR）
• 脅威インテリジェンスプラットフォーム（TIP）
• 脅威ハンティング
• 脆弱性管理
• ペネトレーションテストとレッドチーミング

8. インシデント対応

• インシデント対応計画とプレイブック
• コンピューターフォレンジックと調査
• マルウェア分析
• 脅威の封じ込めと根絶
• インシデント後のレビューと教訓
• 規制当局への侵害通知

9. ガバナンス、リスク、コンプライアンス（GRC）

• セキュリティポリシーと手順
• リスクアセスメントと管理
• コンプライアンス管理と監査
• セキュリティ意識向上トレーニング
• ベンダーリスク管理
• 事業継続と災害復旧

---

セキュリティ指標とKPI

リスクとコンプライアンスの指標

• 未対応の重大/高リスクの件数
• リスク是正までの時間（平均修復時間）
• コンプライアンス監査の指摘事項（未対応/対応済み）
• コンプライアンス統制の有効性率
• ポリシー確認の完了率
• トレーニング修了率

脆弱性管理の指標

• 脆弱性の平均検知時間（MTTD）
• 平均パッチ適用時間（MTTP）
• 脆弱性バックログ（未対応の総数、重大度別）
• パッチ適用率（SLA内にパッチ適用されたシステムの割合）
• 脆弱性の再発率

インシデント対応の指標

• インシデントの平均検知時間（MTTD）
• 平均対応時間（MTTR）
• 平均封じ込め時間（MTTC）
• 平均復旧時間（MTTR）
• 重大度別のインシデント件数
• インシデントの再発率
• 誤検知率

セキュリティ運用メトリクス

• SIEM アラート件数（合計、重大度別）
• アラートのトリアージ時間
• アラートの誤検知率
• セキュリティツールのカバレッジ（監視対象資産の割合）
• 脅威ハンティングのカバレッジ（レビュー済み環境の割合）
• ペネトレーションテストの検出事項

アクセス管理メトリクス

• MFA 導入率
• 特権アカウントのレビュー完了率
• アクセス認定の完了率
• 孤立アカウント数
• パスワードポリシー準拠率
• ログイン失敗試行率

意識・文化メトリクス

• フィッシングシミュレーションのクリック率
• セキュリティトレーニングの完了率
• セキュリティ意識向上クイズのスコア
• セキュリティポリシー違反
• セキュリティ関連のヘルプデスクチケット

---

セキュリティツールのエコシステム

SIEM（Security Information & Event Management）

• Splunk Enterprise Security
• IBM QRadar
• Microsoft Sentinel
• Elastic Security
• Sumo Logic

EDR/XDR（Endpoint/Extended Detection & Response）

• 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

ID・アクセス管理

• 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）

クラウドセキュリティ

• セキュリティスキャンを伴う Infrastructure as Code（IaC）を使用する
• クラウドネイティブのセキュリティサービスを有効にする（GuardDuty、Security Hub）
• 設定ミスを監視するために CSPM を実装する
• クラウドネイティブの暗号化と鍵管理を使用する
• IAM ポリシーに最小権限を適用する
• シャドー IT や未承認のリソースを監視する

コンプライアンス

• コンプライアンスは一度きりではなく、継続的なプロセスとして扱う
• 効率化のため、コントロールを複数のフレームワークに対応付ける
• 可能な限り証跡の収集を自動化する
• 締め切りを管理するためのコンプライアンスカレンダーを維持する
• すべてを文書化する（文書化されていなければ、存在しないのと同じである）
• 外部監査の前に内部監査を実施する

セキュリティ文化

• セキュリティをすべての人の責任にする
• 定期的にセキュリティ意識向上トレーニングを実施する
• フィッシングシミュレーションを実施して意識を検証する
• セキュリティを意識した行動を評価する
• 明確で分かりやすいセキュリティポリシーを作成する
• セキュリティ上の懸念を報告することが奨励される文化を育てる

---

他の分野との連携

DevOps/プラットフォームエンジニアリングとの連携

• セキュリティスキャンをCI/CDパイプラインに統合する
• セキュリティテストとコンプライアンスチェックを自動化する
• Infrastructure as Code (IaC) のセキュリティを実装する
• コンテナスキャンとランタイム保護を利用する
• 本番環境の問題に関するインシデント対応で連携する

エンタープライズアーキテクチャとの連携

• セキュリティアーキテクチャをエンタープライズアーキテクチャに整合させる
• アーキテクチャレビューボードに参加する
• アーキテクチャ標準にセキュリティ要件が含まれるようにする
• 安全な統合パターンを設計する
• セキュリティのリファレンスアーキテクチャを定義する

ITオペレーションとの連携

• パッチ管理と変更管理で連携する
• 監視とアラートの運用で協力する
• セキュリティおよび運用上のインシデントに対して共同でインシデント対応を行う
• バックアップとディザスタリカバリの手順を整合させる
• アクセス管理と特権アクセスを調整する

プロダクトマネジメントとの連携

• 新機能に対するセキュリティ要件を提供する
• 新製品の脅威モデリングに参加する
• セキュリティとユーザーエクスペリエンスのバランスを取る
• プライバシーとコンプライアンスへの影響について助言する
• セキュリティをプロダクトの差別化要因としてサポートする

法務/プライバシーとの連携

• データプライバシー規制 (GDPR、CCPA) について連携する
• 情報漏えい通知の要件について協力する
• ベンダー契約のセキュリティ条項をレビューする
• プライバシー影響評価を支援する
• データの保持と削除に関するポリシーを整合させる

---

セキュリティ & コンプライアンスへの関与が必要な場面

必須の関与

• 新しいシステムまたはアプリケーションの設計
• セキュリティ境界に影響するアーキテクチャの変更
• 規制コンプライアンスの取り組み
• セキュリティインシデント
• ベンダーリスク評価
• 本番環境導入前のセキュリティレビュー
• 監査の準備
• データ漏えいまたは漏えいの疑いがある場合

推奨される関与

• 大規模な機能リリース
• クラウド移行
• M&Aのデューデリジェンス
• インフラストラクチャの変更
• 新しいサードパーティ製インテグレーション
• 大規模なプロセス変更
• セキュリティツールの選定
• ポリシーの更新

継続的な連携

• セキュリティレビュー（プルリクエスト、重要システムの場合）
• 脆弱性の修正の優先順位付け
• セキュリティ意識向上とトレーニング
• 脅威インテリジェンスの共有
• リスク評価の更新
• コンプライアンスの監視