統合セキュリティリスク管理（USRM）プログラム

目的

統合セキュリティリスク管理（USRM）プログラムは、効率を改善し、全体的な可視性を可能にし、セキュリティ推奨事項の採用率を向上させるために、セキュリティ観察事項、推奨事項、および発見事項の一貫した特定、文書化、優先順位付け、対処、および追跡を保証します。このプロセスは、組織全体のセキュリティリスク管理プロセスへのインプットとしても機能し、より迅速な意思決定を可能にします。

適用範囲

本プログラムは、Security 部門の推奨事項、発見事項、観察事項を支援するように設計されています。USRM プロセスへのさまざまなソースのオンボーディングは、適切な標準化とチーム間での成功した採用を確保するため、段階的なアプローチで展開されます。これらのソースは、その後個々の STORM リスクにマッピングされます。

カバレッジには特定されたソースが含まれます:

役割と責任

権限マトリクス

セキュリティ発見事項が特定された場合、優先順位に基づいて以下のマネジメントレベルに通知する必要があります。これらのマネージャーは、提案された修復アプローチに同意しない場合や、代替の対処がより適切であると判断した場合に介入する権限を持ちます。

手順

USRM のワークフローは以下の通りです:

サービスレベルコミットメント

これらのコミットメントは、プロセスの各フェーズに対する標準化されたタイミング期待値を確立します。これにより、すべてのセキュリティチーム間で一貫した応答時間が確保され、発見事項のライフサイクル中にいつアクションや応答を期待できるかについての明確な期待がビジネスステークホルダーに提供されます。

特定

Security の各チームには、独自に定義されたワークフローがあります。これらのワークフローの出力の 1 つは、アクションまたは修復を必要とする発見事項の特定です。優先順位を評価するために発見事項を正規化するため、以下のステップを完了する必要があります。

特定されると、発見事項はチームの標準フォーマットおよび Issue テンプレートに従って Issue として開かれるべきです。Finding Identifier は、関連する GitLab プロジェクトで Issue を開く責任があります。Finding Identifier は、必要なすべての情報、修復推奨事項を記入し、検証のために Remediation Manager に発見事項を提出します。Finding Coordinator は、発見事項をライフサイクル全体を通じて管理する責任があります。これには、関連するリスク Issue とのリンクを確保すること、Remediation Manager と発見事項を検証すること、すべての修復進捗を追跡すること、現在の情報とステータス更新で GitLab Issue を更新することが含まれます。各発見事項にはリスク評価が割り当てられ、これが修復の優先順位を決定します。

USRM Issue テンプレート

チームがセキュリティ発見事項を作成する際に使用できる標準化された USRM 発見事項テンプレート が利用可能です。このテンプレートにより、すべての USRM 追跡発見事項間で一貫性が確保され、適切な追跡と管理に必要なすべてのフィールドが含まれます。

主要なガイドライン:

• 既存の Issue テンプレートを持つチームは、必要なすべての USRM フィールドとラベルが含まれている場合は、そのまま使用を続けることができます
• 既存のテンプレートがないソースには USRM テンプレートを使用すべきです
• 使用されるテンプレートにかかわらず、すべての発見事項には追跡とレポート作成のために必要な USRM ラベルが含まれている必要があります

発見事項記述のドラフト作成ガイダンス

記述には、発見事項に関する誰が、何を、いつ、どこで、なぜ、どのように、を含めるべきです。レビューステップとして、この発見事項について何も知らなかった場合、その発見事項、特定された方法、および目標への影響を理解できるでしょうか？以下の 4Cs モデルの活用を検討してください:

• Condition - 現在の状態
• Criteria - ポリシー、要件、コントロール、規制などに基づく望ましい状態
• Cause - 観察事項の根本原因
• Consequence - 目標／資産への実際または潜在的な影響

Prod Sec 部門の追加の役立つリスクドラフト作成ガイダンスは こちら で見つけることができます。

必須ラベル

優先順位付けとレポート作成、メトリクスを可能にするため、必須ラベルを適用する必要があります。これらのラベルは以下の通りです:

任意ラベル

Issue ステータスとアラートラベル

これらのラベルは、注意が必要な Issue を追跡するため、トリアージボットによって自動的に、または Finding Coordinator によって手動で適用されます:

リスク評価

多くのチーム（例: SIRT）には既存のリスク評価方法論があります。それを持たないチーム向けには、以下のセキュリティ部門の要件に適応された標準化された GitLab の 優先度 と 重要度 フレームワークを使用してください:

推奨事項

推奨事項は、発見事項にどのように対処するかを反映します。ISO 31000 では、リスクの対処に以下のアプローチの 1 つ以上を適用することを推奨しています:

• 回避 - リスクを引き起こす活動を開始または継続しないことを決定する、またはリスクの源を完全に排除する
• 緩和 - リスクの発生可能性または影響を低減するコントロールを導入する。
• 転嫁 - 契約、アウトソーシング、または保険を通じてサードパーティとリスクを共有する。
• 受容 - リスクを取るための情報に基づいた決定を下す。

推奨事項は以下を行うべきです:

• 根本原因に対処する - これができない場合、推奨事項はリスクの発生可能性または影響を低減するべきです。
• 低コンテキストである。
• 達成可能 – 利用可能なリソース、スキル、制約を考慮した現実的なもの。
• 実行可能 – 何を、誰によって、いつ行う必要があるかを明確に述べる。

Red Team の追加の役立つガイダンスは こちら で見つけることができます。

修復計画

推奨事項を使用して、適切なオーナーグループと協力して SMART 修復計画を策定します。

Business Risk と Security Risk Owner

修復計画が文書化されたら、Business Risk Owner と Security Risk Owner の両方に通知する必要があります。

Business Risk Owner:

• 発見事項によって提示されるリスクと対応の決定について全体的に説明責任を負う
• 特定された発見事項と提案された修復計画について情報提供を受ける必要がある
• 修復アプローチを承認するか、修正を要求する権限を持つ
• 修復が実行不可能または正当化されない場合、リスクを正式に受け入れることを選択できる

Security Risk Owner:

• 発見事項を特定した発信元のセキュリティチームを代表する
• 提案された修復計画がセキュリティ推奨事項に十分に対処していることを確認するためにレビューする
• 技術的検証とセキュリティ承認を提供する
• 修復アプローチが重大な残余リスクを残す場合、懸念をエスカレーションする

GitLab Issue で両方のオーナーをタグ付けすることで、適切な可視性と説明責任が確保され、リスクが適切に対処される可能性が大幅に向上します。

リスク受容

リスクを回避、緩和、または転嫁するのではなく、リスクを受け入れることを決定する場合があります。セキュリティ発見事項に対してリスク受容が望ましい場合、修復オーナーは以下を提供する必要があります:

1. リスクの説明: リスクの明確な記述
2. ビジネス上の正当性: 受容が必要な理由
3. 補完的なコントロール: エクスポージャーを低減するためにどのような緩和策が実施されているか
4. 想定期間: 受容がどれだけの期間必要か（リスク評価に基づき最大 24 ヶ月）
5. 残余リスク: 補完的なコントロール後にどのリスクが残るか

Finding Coordinator は、リスク許容度およびコンプライアンス／規制義務に基づいて受容が適切であることを検証します。承認は 権限マトリクス に従って部門のマネジメントチームから必要です。

承認されたら、risk-acceptance::active ラベルと適切なリスクレベルラベルを適用します。Issue は引き続きオープン状態のままです 追跡され定期的にレビューされる、進行中のリスク受容として。

定期レビュースケジュール

Finding Coordinator は以下の間隔で定期レビューを実施します:

各レビューについて、Finding Coordinator は以下を行います:

1. 元の条件がまだ存在するかどうかを評価する
2. 重要度が変更されたかどうかを評価する
3. 脅威の状況やビジネス環境への変更をレビューする
4. 受容の正当化が引き続き有効であることを確認する
5. 修復オプションが利用可能になったかどうかを評価する
6. 補完的なコントロールが引き続き有効であることを検証する

Security 承認

Security は以下が実施されていることを検証します:

• 対処計画またはリスク受容
• フォローアップ／修復テストの期日
• 必須ラベル
• モニタリングが実施されている
• 発見事項が関連するリスク Issue にマッピングされている

モニタリング

推奨事項の品質とエスカレーション

セキュリティチームからの発見事項が正確、最新、適切に管理されていることを保証するため、トリアージボット を活用しています。このボットは、Issue の品質、ナッジング／エスカレーション、および部門全体のセキュリティ発見事項のタイムリーな解決をサポートします。

Finding Coordinator

Finding Coordinator は、発見事項がアクティブで最新の状態を保ち、定義された修復タイムラインを持つことを保証する責任があります。これらのタスクはトリアージボットポリシーによって支援されます。彼らはまた、エスカレーションを開始し、ブロッカーがクリアされていることを保証します。Finding Coordinator の役割は、SecCompliance および SecRisk チームのメンバーによって担われます。Finding Coordinator のより詳細な責任と手順については、以下の折りたたまれたセクションをご確認ください。

必須トリアージボットポリシー

発見事項を生成するすべてのセキュリティチームは、それぞれのプロジェクトで以下の自動化ポリシーを実装する必要があります:

1. 古い Issue ナッジング

ポリシー: Issue が非アクティブのままの場合の自動ナッジング

• トリガー: 30 日間更新のない Issue
• アクション: 30 日間の非アクティブ後、stale ラベルを追加し、ステータス更新を要求するコメントを追加し、アサインされた人をタグ付けする
• 例外: ignore または blocked のラベルが付いた Issue は除外される

- name: Nudge stale issues
  conditions:
    issue_type: issue
    forbidden_labels:
      - stale
      - <blocked team label here>
    state: opened
    date:
        attribute: updated_at
        condition: older_than
        interval_type: months
        interval: 1
    actions:
        redact_confidential_resources: false
        comment: |
           {{author}} This issue has not been updated in 1 month.

            If this issue is still relevant, please provide an update and/or update the workflow status.

            The `stale` label has been applied to help track issues requiring attention.
        labels:
          - stale

1. アサイン欠落管理

ポリシー: すべての発見事項 Issue には指定されたオーナーが必要

• トリガー: 作成から 48 時間後にアサインされていない Issue
• アクション: needs-assignee ラベルを追加する
• 例外: バックログマイルストーンの Issue はアサインされていない状態のままである可能性がある

  - name: Alert when issue has no assignees
    conditions:
      issue_type: issue
      forbidden_labels:
          - Missing_Assignee
      ruby: resource[:assignees].empty?
      state: opened
    actions:
        redact_confidential_resources: false
        comment: |
          {{author}}, This issue is missing an assignee.
        labels:
          - Missing_Assignee
  - name: Remove Missing_Assignee label when there are assignees
    conditions:
      issue_type: issue
      labels:
          - Missing_Assignee
      ruby: |
          !resource[:assignees].empty?
      state: opened
      actions:
        remove_labels:
          - Missing_Assignee

1. 期日超過 Issue 追跡

ポリシー: 期日超過の Issue は即時の注意と正当化が必要

• トリガー: 期日を過ぎた Issue
• アクション: overdue ラベルを追加し、更新されたタイムラインを要求するコメントを追加する
• 例外: 承認されたタイムライン延長を持つ Issue（コメントで文書化）

  - name: Comment on past due issues
    conditions:
      state: opened
      issue_type: issue
      forbidden_labels:
          - overdue
          - bot-ignore
      ruby: |
          past_due_date?
      actions:
        redact_confidential_resources: false
        comment: |
          {{author}} This issue is past due. Please review and update the timeline or mark as completed.
        labels:
          - overdue

1. 期日強制

ポリシー: すべての発見事項 Issue には現実的なタイムラインが必要

• トリガー: 期日のない 7 日以上経過した Issue
• アクション: needs-due-date ラベルを追加し、アサインされた人にタイムラインを要求する
• 例外: リサーチまたは発見の Issue は代わりにマイルストーン日を使用する場合がある

  - name: Comment no due date issues
    conditions:
      state: opened
      issue_type: issue
      forbidden_labels:
          - missing_duedate
      ruby: resource[:due_date].nil?
    actions:
        redact_confidential_resources: false
        comment: |
          {{author}} This issue has no due date. Please review and update the timeline or mark as completed.
        labels:
          - missing_duedate

1. 必須ラベル強制

ポリシー: すべての発見事項 Issue にはメトリクスとレポート作成のための必須ラベルが必要

• トリガー: 必須ラベルが Issue から欠けている
• アクション: missing-label ラベルを追加し、アクションのためにアサインされた人をタグ付けする
• 例外: バックログの Issue は無視される

  - name: Alert when an issue is missing required labels
    conditions:
      issue_type: issue
      forbidden_labels:
          - Missing_Labels
          - bot-ignore
      ruby: |
          [" list labels"].any? { |rl| !resource[:labels].any? { |l| l.start_with?(rl) } }
      state: opened
      actions:
        redact_confidential_resources: false
        comment: |
          {{author}} this issue does not have an appropriate project work labels.

          Please label it accordingly based on the Labeling Guide). The following labels are missing:
          #{ [" list labels"].map{ |rl| "- #{ rl } #{ resource[:labels].any?{ |l| l.start_with?(rl) } ? ':white_check_mark:' : ':x:' }"}.join("\n") }

          Once you add the missing labels, please remove the `Missing_Labels` label. If you are not a member of SecCompliance, please kindly ignore this message.
        labels:
          - Missing_Labels

修復とクロージャー

Finding Identifier は、修復が完了し、発見事項を効果的に緩和することを検証する責任があります。検証されると、Issue は修復のエビデンスの適切なドキュメンテーションと共にクローズできます。

参考資料

サポートチャンネルと更新

Slack で #security_help に連絡するか、関連する Issue で finding coordinator をタグ付けしてください。USRM の更新は #security_discuss で毎週公開されます。月次の録画は、より詳細な分析と共に 公開 されます（社内のみ）。Risk Source Owner との定期的なミーティングは、傾向のレビューとフィードバックの収集のために実施されます。

内部ドキュメント

• Unified Security Risk Management Epic
• Security Risk Sources
• GitLab Issue Triage Guidelines
• StORM Program Procedures
• Observation Management Procedure
• Vulnerability Resolution SLAs
• GitLab Security Handbook

ページのソースコードを見る - ページの編集 - please contribute.