学習パス 05レッスン 6 / 8

ソフトウェアデリバリーをSOCとSIRTに結び付ける

セキュリティ監視、インシデントの引き継ぎ、証拠保全、復旧の責任を定義します。セキュリティ対応をソフトウェアライフサイクルにつなげます。

応用12 分レビュー日

発行元 執筆方針

理解度を確認SOCがビルド用IDの通常とは異なる利用を検出しました。しかし、データへのアクセスはまだ証明できません。どの引き継ぎが最も役立ちますか?演習に取り組む
SOCがビルド用IDの通常とは異なる利用を検出しました。しかし、データへのアクセスはまだ証明できません。どの引き継ぎが最も役立ちますか?

学べること

  • SOCの監視とSIRTのインシデント対応調整を区別する。
  • セキュリティインシデントの対応に役立つ引き継ぎを準備する。
  • 封じ込め、復旧、エンジニアリングによる是正を結び付ける。

名称の背後にある機能を定義する

Security operations center、つまりSOCは、一般にセキュリティ上のシグナルを監視し、アラートを調査し、インシデントの疑いをエスカレーションします。Security incident response team、つまりSIRTは、セキュリティインシデントへの対応を調整します。CSIRTも、この対応機能によく使われる名称です。

これらの機能の分担は、組織によって異なります。同じ人が両方を担うこともあります。外部の事業者が、サービスの一部を提供する場合もあります。略称だけから、対応範囲や権限を推測しないでください。監視時間、エスカレーションの経路、意思決定の権限、対応に関する約束を記録します。

FIRSTのCSIRTフレームワークは、対応チームが提供できるサービスを説明しています。NISTは、インシデント対応を、より広いサイバーセキュリティのリスク管理に結び付けています。これらの資料を使って、責任と連携方法を定義してください。FIRSTフレームワーク、NISTのインシデント対応。

AI開発を検出対象に含める

ソフトウェアデリバリーシステムには、ID、リポジトリ、runner、レジストリ、連携機能、デプロイ用の認証情報があります。エージェントを使うと、ツール呼び出しとモデル提供者へのデータフローも加わります。これらの境界を、セキュリティ設計に含めます。

定義した検出に役立つイベントを選びます。想定外のリポジトリアクセス、権限の変更、通常とは異なる成果物の公開、未承認のIDによるデプロイなどが例です。タイムスタンプ、実行者のID、リソース識別子、利用できる場合は不変の成果物digestを使って、記録を結び付けます。

これらの記録を保護します。監査記録へのアクセス、保持期間、時計の精度、収集の失敗は、調査に影響します。開発の実行ログとクラウドの監査ログは、それぞれ異なる問いに答えます。どちらも、それだけで完全なインシデント記録になるわけではありません。

インシデントの前に引き継ぎを準備する

引き継ぎの項目必要な情報
観測内容何が、いつ、どのシステムで起きたか
確実性検証済みの事実、調査中の仮説、未解決の問いのどれか
範囲ID、リポジトリ、環境、影響を受けた可能性があるデータ
証拠保護された保存場所と収集の詳細。シークレットは露出させない
操作何を変更したか、誰が承認したか、どのような結果を観測したか
判断指名された対応責任者、次の操作、次の報告時刻

トークンの失効、runnerの隔離、デプロイの一時停止、サービスの復旧を誰が実行できるかを定義します。サービス責任者は、運用への影響を説明します。セキュリティ対応者は、調査と封じ込めを調整します。関連するプライバシー、法務、事業の責任者は、実際の状況に応じて通知義務を評価します。

通知の要件は、インシデントと適用される義務によって異なります。適切な意思決定者を早期に関与させてください。AIの要約にその判断を任せたり、既定のエスカレーションを遅らせたりしないでください。

架空のトークンに関するインシデントをたどる

14:05 UTCに、SOCはビルド用IDが想定外のリポジトリを読み取っていることを検出します。14:08に、リポジトリ責任者は、その活動に該当する承認済みのジョブがないことを確認します。ソースコードが環境の外に出たかどうかは、まだ分かりません。

対応チームは、監査記録と関連するrunnerの証拠を保全します。権限を持つ責任者が、影響を受けた認証情報を失効させ、疑わしい実行経路を停止します。これらの操作は、組織の対応手順に従い、サービスへの影響を考慮して行います。

漏えいしたトークンをファイルから削除するだけでは不十分です。その認証情報は、別の場所で引き続き有効な場合があります。IDが侵害されたままなら、runnerを再構築するだけでも不十分です。妥当と考えられる影響範囲で、生成された成果物、下流へのアクセス、その他の認証情報を調査します。

デリバリーを再開する前に、ID、runner、成果物の来歴、必要なアクセス境界を検証します。まだ不明な点を記録します。ビルドの成功だけでは、デリバリー環境が信頼できることを証明できません。

調査結果をエンジニアリングに戻す

確認された原因を、担当者が明確な作業に変えます。認証情報の有効期間の短縮、アクセス範囲の縮小、runnerの隔離、検出の変更、回帰テストなどが考えられます。是正を検証し、引き継ぎを再び訓練します。

Taigaの監査記録とデリバリー記録は、文書に示された範囲で証拠になります。組織の対応プロセスに組み込んでください。Taigaを有効にすればSOCやSIRTの責任まで移ると考えずに、責任共有の境界を確認します。Audit log、責任共有。

演習に取り組む

このレッスンの架空のトークンに関するインシデントを使ってください。事実、不確実な点、影響を受けたID、保全した証拠、封じ込めの選択肢、意思決定者を含む引き継ぎを書いてください。トークンの値は含めないでください。

ワークシートをダウンロード(Markdown)
理解度を確認 ↑

学習を続ける

出典と参考資料

Taigaの関連資料

← 前のレッスン: 検出から復旧までインシデントに対応する