セキュリティ インシデントへの対応

          GitHub企業の組織またはリポジトリに影響を与えるセキュリティ インシデントに戦略的に対応します。

この記事で

この記事のガイダンスは、エンタープライズ所有者、組織の所有者、セキュリティ マネージャー、およびセキュリティ チームを対象としています。 ただし、この記事で説明するいくつかのアクションを実行するには、エンタープライズ所有者ロールが必要です。 一部の手順では、組織の所有者またはリポジトリ管理者との調整が必要になる場合があります。

Introduction

このガイドでは、セキュリティ インシデントに対応する方法について説明し、脅威の検証と調査に使用できる GitHub サーフェスと、それを含めて修復するために使用できるツールについて説明します。

重要

ここでの手順は、一般的なガイドラインです。 すべてのインシデントは一意であり、特定の状況に基づいて異なるアプローチが必要になる場合があります。

          GitHub のサポートプラットフォーム固有の質問に役立ちますが、システムとリソースに影響を与えるセキュリティ インシデントを調査して対応することをお勧めします。

[前提条件]

企業に対 して監査ログ ストリーミング と ソース IP アドレスの可視性 が既に有効になっている (セキュリティ情報およびイベント管理 (SIEM) システムにデータをストリーミングする) ことがあり、そのデータにアクセスできるのが理想的です。 「企業の監査ログのストリーミング」を参照してください。

応答全体を通して

応答を進めていく際は、次の点を確認してください。

  • 証拠の保持: 疑わしいアクティビティのスクリーンショットを撮り、ログまたはクエリ結果をエクスポートし、影響を受けたファイルまたはコードのコピーをクリーンアップ前に保存します。
  • 記録を保持する: 結果 (時間、日付、侵害のインジケーター (IoC)、影響を受けるリポジトリなど) を文書化し、実行した各決定を記録します。
  • コミュニケーション: 関連する利害関係者 (セキュリティ リードやエンジニアリング マネージャー、機密データが危険にさらされている場合は法的およびプライバシー チームなど) に通知し、最新の状態に保ちます。

手順 1: 信号を評価し、迅速に検証する

目標は、表示されている信号が実際のアクティブな脅威である可能性が高いかどうかを迅速に判断することです。

1. 識別

表示されているシグナルの性質を特定してみてください。 たとえば、シグナルは次の兆候を示します。

  • 資格情報の侵害 (漏洩したシークレットのアラート、外部サイトで見つかった資格情報のレポート)
  • 不正アクセスまたはアカウントの侵害 (疑わしいログイン、未知のコミットまたは変更のレポート)
  • データ流出 (疑わしいファイルの変更または追加、予期しないワークフローの実行、異常な API アクティビティ、不明なリポジトリの作成、または予期しないリポジトリの可視性の変更のレポート)
  • 悪意のあるコード挿入 (疑わしいコード変更のレポート、予期しないワークフローの実行、新しいファイルの追加)
  • サプライ チェーン攻撃 (疑わしいパッケージ バージョンのレポート、脆弱な依存関係に関するアラート)

組織全体または企業全体でこれらの脅威シグナルを特定する方法については、 一般的なセキュリティ インシデントの調査領域 を参照してください。

最初の目標は、脅威シグナルを検証して対応を戦略化することですので、調査の初期の段階で詳細な検査に時間を費やさないようにすることをお勧**** めします。

2. 検証

潜在的な脅威が実際の脅威であり、それが現在アクティブであるかどうかを検証する証拠を確認します。

次の GitHub ツールとサーフェスが役立ちます。

ツール/表面Purpose
セキュリティの概要とセキュリティアラート組織全体または企業全体のセキュリティ アラートを確認する
監査ログトークンの作成、アクセス許可の変更、リポジトリの可視性の変更など、調査中のシグナルに関連するイベントを検索します
アクティビティ ビュー特定のリポジトリのプッシュ、コミット、ブランチ アクティビティのタイムラインを表示する
[
          GitHub コード検索](/code-security/reference/security-incident-response/investigation-tools#github-code-search) | リポジトリ間で、特定のファイル名やコード パターンなど、侵害の既知のインジケーターを検索する |

| 依存関係グラフ | リポジトリが特定のパッケージまたはパッケージのバージョンに依存しているかどうかを確認する | | ワークフローの実行とログ | ワークフロー実行履歴を確認し、疑わしいアクティビティのログ出力を検査する |

各ツールの詳細については、 セキュリティ インシデントの調査ツール を参照してください。

検証フェーズは迅速に行うことができます。

  • 信号が 実際 の アクティブな 脅威である可能性が高いかどうかを判断するのに十分な証拠を収集することを目的とします。
  • シグナルを誤検知としてすぐに除外できない場合は、それが本物であると仮定します。
  • 詳細な調査は後で実行できます。

3. 決定する

収集された証拠に基づいて、次の 3 つを決定します。

  1.        **これは本当の脅威ですか?** シグナルを誤検知として迅速かつ自信を持って除外できない場合は、それを実際のものとして扱い、封じ込めに進んでください。

  2.        **脅威は引き続きアクティブですか?** 攻撃者が引き続きアクセス権を持っているか、アクティビティが進行中であると思われる場合は、最初に即時封じ込めアクションに優先順位を付けます。 侵害が履歴に表示される場合は、調査と修復が必要ですが、対応を計画する時間が長い場合があります。

  3.        **潜在的なスコープは何ですか?** 1 つの資格情報、リポジトリ、組織、または企業全体など、侵害がどの程度まで到達できるかを検討します。 これにより、応答を適切にスケーリングするのに役立ちます。

疑わしい場合は、脅威を実際の脅威として扱い、証拠が許すように応答をスケールバックします。

手順 2: 脅威を封じ込める

次の手順では、実際のアクティブな脅威に対処していることを前提としています。 今の目標は、これまでに知っていることを使用して 、継続的なリスクを直ちに減らすこと です。

攻撃者のアクセスと機能を制限するために実行できる包含アクションがいくつかあります。

重要

選択したアクションは、脅威の性質、潜在的な範囲、およびこの時点での証拠に基づいて行う必要があります。 すべてのインシデントに対してこれらのすべてのアクションを実行することはお勧めしません。 一部のアクションは他のアクションよりも破壊的または破壊的であるため、上記の脅威の性質の評価に基づいて、各アクションのリスクと利点を比較検討する必要があります。

侵害された資格情報を取り消す

公開された資格情報または悪用された資格情報の場合、最も迅速に実行できるアクションは、影響を受ける資格情報を取り消して、不正使用を防ぐことです。

  • API を使用して取り消す

    トークンが次のいずれかの型で、トークンのリテラル値がわかっている場合は、 REST API 経由で要求を送信することで、トークンを取り消すことができます。 「無効化」を参照してください。

    • Personal access token (classic)
    • Fine-grained personal access token
    • OAuth app アクセス トークン
    • GitHub App ユーザー アクセス トークン
    • GitHub App 更新トークン

  • 失効と封じ込めのオプション

    資格情報アクセスをブロックするための追加のオプションがあります。 資格情報の種類別の完全な一覧については、「 GitHub 資格情報の種類のリファレンス」を参照してください。

  • 緊急対応 (重大インシデント)

            GitHub Enterprise Cloudのエンタープライズ所有者は、企業全体のアクセスをロックダウンするために一括緊急アクションを実行できます。 
        Enterprise Managed Usersを使用する企業の場合、**これにはすべてのユーザー トークンとキーの削除が**含まれます。 これらは、自動化を中断する影響の大きいアクションであり、重大なインシデント用に予約する必要があります。 「[AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents)」を参照してください。

アクセスを制限する

エンタープライズ、組織、またはリポジトリへのアクセスを制限するために、いくつかの即時アクションを実行できます。

  • IP 許可リストを構成する

    不明または疑わしい IP アドレスによる組織または企業へのアクセスをブロックします。 IP 許可リストを使用して Enterprise へのネットワーク トラフィックを制限する (エンタープライズ管理者) と 組織に対する許可 IP アドレスを管理する (組織の所有者) を参照してください。

  • 侵害されたユーザーまたは疑わしいユーザーを削除する

    ユーザーを削除するか、アカウントを中断します。

            [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise) (エンタープライズ管理者) と [AUTOTITLE](/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) (組織の所有者) に関する記事を参照してください。

  • リポジトリの可視性をプライベートに変更する

    影響を受けるリポジトリの可視性をプライベートに変更し、他のユーザーがさらに変更を加える機能を制限します。 たとえば、機密性の高いコードが組織に属するパブリック リポジトリで公開された場合、または悪意のあるアクターがリポジトリの可視性設定をプライベートからパブリックに変更した場合、リポジトリの可視性を変更できます。 リポジトリの可視性を設定する (リポジトリ管理者と組織の所有者) と Organization 内でリポジトリの可視性の変更を制限する (組織の所有者) を参照してください。

  • 緊急対応 (重大インシデント)

            GitHub Enterprise Cloudのエンタープライズ所有者は、企業全体のアクセスをロックダウンするために一括緊急アクションを実行できます。 これには、 **SSO をロックダウンして** 所有者以外のすべてのアクセスをブロックしたり、 **組織全体のすべてのユーザー SSO 承認を取り消したりすることが含まれます**。 これらは、自動化を中断する影響の大きいアクションであり、重大なインシデント用に予約する必要があります。 「[AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents)」を参照してください。

悪意のある成果物とアクティビティを無効にする

  • 悪意のあるワークフローの実行を停止する

            GitHub Actionsワークフローまたはランナーがアクティブな攻撃の一部として使用されていると思われる場合は、次のアクションを実行できます。

  • Webhook を無効にする

    侵害されたリポジトリまたは組織の Webhook がライブ データ流出チャネルとして使用されていると思われる場合は、無効にすることができます。 「Webhook を無効にする」を参照してください。

  • 悪意のあるブランチを削除する

    悪意のあるコードまたはワークフローを含むブランチを特定した場合は、すぐに削除して実行を防ぎます。 「リポジトリ内でブランチを作成および削除する」を参照してください。

手順 3: 完全に調査する

すぐに封じ込めた後、目標は、インシデントの全範囲と影響を理解し、すべての IoC と永続化メカニズムを特定し、脅威を含めて完全に修復するために必要な証拠を収集することです。

重要

インシデント対応は線形プロセスではありません。 新しい IoC を検出したり、攻撃の詳細を理解したりするときに、調査、封じ込め、修復を繰り返し行う必要がある場合があります。

  1. これまでに見たシグナルとこれまでに収集した証拠に基づいて、何が起こったかについて の作業仮説 を作成し、その仮説を証明または反証するために必要な追加の証拠を決定します。

  2.        **AUTOTITLE** で説明されているさまざまな[調査領域](/code-security/reference/security-incident-response/investigation-areas)を検討して、調査の指針を示します。

    調査を 1 行の問い合わせに制限しないでください。 多くの攻撃では、悪意のあるパッケージのインストールと資格情報の悪用、ワークフロー ファイルの挿入、データ流出などの手法の組み合わせが使用されます。 潜在的なすべての攻撃ベクトルを調査していることを確認します。

  3. これまでにすべての既知の IoC を文書化し、GitHubのすべてのサーフェスにわたるトレースを検索します。

  4. 影響を受けるすべてのワークフロー、リポジトリ、および組織をインベントリして、インシデントの範囲を体系的にキャプチャします。

    • リポジトリ名、影響を受けたもの (コード、シークレット、ワークフロー)、侵害のタイムラインを含めます。
    • 影響を受けるすべてのアカウントと資格情報の一覧を作成します。 公開または誤用された可能性のあるトークン、SSH キー、またはその他の資格情報に注意してください。
  5.        **証拠** に対する作業理論を検証します。
    • 収集した証拠を確認します。 これは最初の仮説をサポートしていますか?
    • 別の説明を検討してください。 観察したアクティビティに別の原因が考えられますか?
    • 仮説が反証された場合は、証拠に基づいて新しい仮説を形成し、必要に応じて調査手順を繰り返します。

  6. 新たな IoC や即時対応が必要な進行中の活動の証拠を発見した場合は、コンテインメントに戻ってください。

何が起こっているのか、根本原因を理解している自信が高まったら、調査結果を文書化して修復に進みます。

手順 4: 修復

ここでの目標は、侵害のすべてのトレースを削除し、根本原因を修正し、システムをセキュリティで保護された状態に復元することです。 修復アクションは、直面した悪用によって異なりますが、いくつかの適切なプラクティスは次のとおりです。

トークンとシークレットをローテーションする

資格情報が侵害されたことが不明な場合でも、露出の可能性がある場合はローテーションします。

  • 取り消された、または公開された可能性のあるトークンを置き換える新しいトークンとシークレットを生成します。
  • リポジトリ、環境、および組織レベルで GitHub に格納されているシークレットをローテーションします。
  • 侵害されたトークンを使用してアクセスされた可能性がある外部システムの資格情報を更新します。
  • 今後定期的なローテーションを促進するために、トークンの有効期限ポリシーを有効にすることを検討してください。 「Enterprise 内の個人用アクセス トークンに対するポリシーの適用」を参照してください。

永続化メカニズムの監査

最初の封じ込めアクションの後でも、攻撃者がアクセスを維持するために確立した可能性のある永続化メカニズムを確認する必要があります。

これには、次のようなチェックが含まれますが、これらに限定されません。

  • 追加または変更された可能性のある疑わしいワークフロー ファイルまたは未知のワークフロー ファイル。
  • 未知のドメインを指す新しい Webhook。
  • 新しいセルフホステッド ランナー。
  • セルフホステッド ランナーへの変更。
  • GitHub Apps または OAuth app の新しくインストールされた認可。
  • リポジトリに追加された新しいデプロイ キー。
  • 新しいバイナリ ファイルまたは実行可能ファイル。

依存関係の監査と再インストール

侵害された依存関係は、攻撃ベクトルとして機能する可能性があります。 依存関係の完全な監査を行い、信頼できるソースから再インストールしてください。

  • 脆弱な依存関係のDependabotアラートを確認し、利用可能な場合は悪意のあるパッケージのDependabot malware alertsアラートも確認します。 (Dependabot malware alertsは現在、npm エコシステムで使用できます。その他のマルウェア アドバイザリを調査するには、type:malwareでGitHub Advisory Databaseを検索し、依存関係グラフの一致を監査します。
  • 依存関係を既知の適切なバージョンにピン留めするか、SHA をコミットし、パッケージ レジストリから再インストールします。

修復の確認

修復作業が成功したことを確認します。

  • code scanningアラートを確認して、コードの脆弱性が解決され、新しい脆弱性が導入されていないことを確認します。
  • secret scanningアラートを確認して、リポジトリにシークレットが公開されたままでなく、すべてのアラートが解決されたことを確認します。
  • インシデント発生後の数日と数週間後に、監査ログやその他の関連するサーフェスを引き続き確認および監視します。

手順 5 ドキュメント

残りのフェーズと将来のリファレンスには、詳細なドキュメントが不可欠です。

  • 調査中に検出されたすべての IoC を記録します。
  • タイムスタンプや各アクションを実行したユーザーなど、実行されたすべての修復手順を文書化します。
  • 影響を受けるリポジトリ、ワークフロー、およびアカウントのインベントリを維持します。
  • 行われた決定とその背後にある推論を文書化します。
  • コンプライアンス、法的、またはプライバシーへの影響に注意してください。 このインシデントが、通知を必要とするデータ侵害であるかどうかを検討します。

手順 6: 振り返りと強化

ここでの目標は、インシデントから学習し、同様のインシデントを防ぐためにセキュリティ体制を強化することです。

  1. インシデントの 概要を記述します。 これには、最初の表示から解決までのイベントのタイムライン、根本原因の分析、決定とアクション、学習した教訓が含まれている必要があります。

  2. 残りの修復タスクや、学習した教訓に基づいて実装する必要があるセキュリティの改善など、セキュリティ インシデントの 未処理のアクション 項目 を問題として追跡します。

           Copilot はこれらを作成するのに役立ちます。また、個別に作業する Copilot に適切な範囲の問題を割り当てることができます。 
       [「AUTOTITLE」を](/copilot/how-tos/use-copilot-agents/coding-agent/create-a-pr#assigning-an-issue-to-copilot)参照してください。

  3. まだお持ちでない場合は、会社またはチームに up-to-date セキュリティ インシデント対応計画があることを確認します。 これには、定義された役割と責任、エスカレーション パス、通信プロトコル、重大度分類基準、および一般的な脅威の種類に対するステップ バイ ステップの対応手順が含まれます。 Copilot は、特定のニーズとリソースに基づいてこの計画を生成および調整するのに役立ちます。 その他のガイダンスについては、「 インシデント対応とは」を参照してください。

次のステップ

  • まだ行っていない場合は、セキュリティ体制を強化して、将来のインシデントのリスクを軽減することを検討してください。 「セキュリティ上の脅威からの保護」を参照してください。