ソフトウェアデリバリーをSOCとSIRTに結び付ける
完了セキュリティ監視、インシデントの引き継ぎ、証拠保全、復旧の責任を定義します。セキュリティ対応をソフトウェアライフサイクルにつなげます。
理解度を確認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)この選択を解除すると、このブラウザーに保存した進捗がすべて削除されます。
進捗はこのブラウザー内に保存されます。アカウントも追跡もありません。
出典と参考資料
- NIST: Incident Response Recommendations, SP 800-61 Rev. 3 ↗
- FIRST: CSIRT Services Framework ↗
- Taiga: Shared responsibility ↗
- Taiga docs: Audit log ↗