セキュリティオペレーションのオンコールガイド
セキュリティオペレーションサブ部門は、実際の、または潜在的なセキュリティインシデントの報告に対して、24時間365日体制で対応する責任を共同で負っています。
- SIRT (セキュリティインシデント対応チーム) は、一般的に疑わしい活動 (フィッシング、ハッキング、ソーシャルエンジニアリングなど) やセキュリティアラートの報告に対応します。
- Trust & Safetyチームは、一般的に暗号通貨マイニング、プラットフォームのSPAM、不正利用、いじめ、利用規約違反の報告に対応します。
セキュリティオペレーションのマネージャーはオンコールの責任を共有し、エスカレーションや緊急事態に対する適切なカバレッジを確保する必要があります。セキュリティ部門は、報告されたすべてのインシデントに合理的な時間枠で対応できるよう、オンコールエスカレーションのシリーズを維持しています。
SIRTのオンコールスケジュールは、Pager Dutyの Security Responder ポリシー内で管理されています。
オンコールセキュリティのハンドオフ
時間
標準のハンドオフ時間はスケジュール通りです。ただし、関係者全員が合意し、変更についてチームに通知される限り、チームメンバーは一時的に変更されたハンドオフスケジュールに合意する権限を有します。
SIRT (11月 - 4月)
- 23:00 から 07:00 UTC –> APAC - 8時間
- 07:00 から 15:00 UTC –> EMEA - 8時間
- 15:00 から 23:00 UTC –> AMER - 8時間
SIRT (4月 - 11月)
- 22:00 から 06:00 UTC –> APAC - 8時間
- 06:00 から 14:00 UTC –> EMEA - 8時間
- 14:00 から 22:00 UTC –> AMER - 8時間
SIRTの時間は SIRT Handoffs カレンダーに反映されています。両者が時間変更に合意する場合、変更はハンドオフの少なくとも24時間前にカレンダーに反映する必要があります。これにより、他のチームメンバーが前夜にスケジュールを十分に計画できます。会議時間の変更は通知としてカウントされます。
SIRTの書面ハンドオフ
インシデントのIssueは、あらゆるインシデントのSSoT (信頼できる唯一の情報源) です。インシデント概要には必ず重要なインシデント更新を含めてください。
SIRTは、書面引き継ぎサマリーのために自社開発のツール Handogotchi を使用しています。Handogotchiは、ハンドオフ時間の1時間前にオンコールのSIRTエンジニアにインシデントを更新し、追加情報を加えるよう促します。ハンドオフ時間の30分前には、アクティブなインシデントへのリンクを自動的に送信します。
書面ハンドオフは、各シフト終了の少なくとも30分前までに完了する必要があり、ウォームハンドオフのベースとなります。
すべてのインシデントについて、最大1時間ごとに一時停止して文書化することと、各作業ステップの後にドキュメントを最新の状態に保つことを習慣にすることを強く推奨します。
SIRTのウォームハンドオフ
SIRTは、書面ハンドオフを明確にし、複雑な状況での誤解を避けるためにウォームハンドオフを使用します。15分以内に終わるべきです。地域ごとに1人 (引き継ぎ元と引き継ぎ先) が必要です。
引き継ぎ元の地域は、上記のセクションで説明したとおりにハンドオフを準備します。引き継ぎ先の地域は、会議に参加する前に書面ハンドオフを把握しておく必要があります。チームメンバーはウォームハンドオフ会議に備えて、未解決の質問や明確化に焦点を当てた効率的な会議になるよう準備しておく必要があります。
インシデントは十分に文書化されているため、ウォームハンドオフには書面のアジェンダはありません。出てきた重要な議論ポイントはすべて、即座にインシデントのIssueに文書化し、修正する必要があります。
SIRTのオンコール
平日
平日オンコールエンジニアの責任
セキュリティオペレーションは、フォロー・ザ・サン (follow-the-sun) モデルを使用して平日のオンコールカバレッジを提供します。平日のオンコールセキュリティエンジニアは、それぞれの地域の日中の時間にオンコール責任をカバーするチームメンバーです。
- 平日のオンコールシフトは、通常、月曜日から金曜日までの1勤務週をカバーします。
- 平日のオンコールセキュリティエンジニアは、
"Triage Engineer"の役割をカバーすることが期待されており、PagerDuty経由およびさまざまなSlack・アラートチャンネル経由で提示されるアラートやインシデントの最初の対応者となるべきです。
週末
週末オンコールセキュリティの責任
SIRTは、割り当てられたシフト中にアラートとインシデントに対応するよう予定されたエンジニアによって、週末のカバレッジを維持しています。セキュリティマネージャーは、バックアップのエスカレーションパスとして24時間365日オンコールです。
SIRTの休暇のスケジューリング
インシデントが対応されないままにならないようにするため、SIRTのチームメンバーは、計画された休暇をスケジュールする前に以下のステップを完了する必要があります。
- 計画された休暇中のオンコールシフトに対して適切なカバレッジを確保する
- クローズの準備ができたインシデントをクローズする
- オープンしているインシデントを別の対応可能なチームメンバーに再割り当てする
マネージャーの責任: マネージャーは、チームメンバーの休暇前に、割り当てられたすべてのインシデントが適切に引き継がれるよう確保する責任があります。このプロセスが完了していない場合、マネージャーは未解決のインシデントに対するカバレッジを確保することになります。
SIRTのオンコールページング
オンコールのページングワークフロー
SIRTオンコールのページングワークフローは現在、以下のエスカレーションパスに従うように設計されています。
- 通知はインシデントの Slack チャンネルに送られ、日中の地域に指定されたオンコールのセキュリティエンジニアにページングされます。
- 15 分間応答がない場合、日中の地域のすべてのセキュリティエンジニアにページングされます。
- チームメンバーがページを承認しない場合、15分後にバックアップとして日中の地域のセキュリティオペレーションマネージャーにページングされます。
- SIRTのエンジニアまたはマネージャーが前のページを15分後も承認しない場合、SIRTディレクターにページングされます。
SIRTのオンコールページング業務
オンコールエンジニアの主な関心事は、入ってくるページに対して適時かつ適切な対応を提供することです。ページを受信した場合は以下を行います。
- 対応するアラートのSlackチャンネル、またはPagerDutyを通じて直接アラームを承認する。
- インシデントのGitLab Issueを確認し、そこに掲載されているチェックリストに従ってトリアージする。
アラームが承認されない場合、オンコールのセキュリティインシデントマネージャーに通知されます。
エンジニアは最初の15分以内にページを承認し、最初のページから1時間以内に潜在的なインシデントの初期トリアージを開始する必要があります。
オンコールのセキュリティマネージャー
オンコールのセキュリティエンジニアに加えて、GitLabセキュリティ部門全体のセキュリティマネージャーは、セキュリティエンジニアがセキュリティページを承認できない場合のバックアップとして機能します。SIRTがページングの試みを承認しない場合、PagerDutyは自動的にオンコールのセキュリティマネージャーをエンゲージします。
オンコールのセキュリティマネージャーの責任は以下のとおりです。
- オンコールのセキュリティエンジニアがページを承認しない場合に、オンコールシフト中に携帯電話で連絡が取れる状態にしておく。
- オンコールのセキュリティエンジニアに連絡してページを承認するよう試みる。注意: Slackが利用できない場合や代替の通信手段が必要な場合、PagerDutyにはオンコールプロセスに関与するGitLabチームメンバーの携帯電話番号があります。GitLabはバックアップ通信チャンネルとしてZoomチャンネル (#Slack Down!) も用意しています。
- オンコールのセキュリティエンジニアが応答しない場合、他のエンジニアに連絡してページを引き継いでもらうよう試みる。タイムゾーンと地域に基づいて優先順位を決定する。
- GitLabに対する高インパクトのセキュリティインシデントが発生した場合、オンコールのセキュリティマネージャーはチーム/部門間の調整を支援するためにエンゲージされます。
トリアージエンジニア
オンコールシフト中、オンコールのセキュリティエンジニアはトリアージのDRIであり、以下のコア責任を負います。
ページを承認しトリアージする；委任する
インシデントを監視しトリアージする；委任する
アラートを監視しトリアージする；自分の活動に対するアラートを委任する；結果として生じるインシデントを委任する
マネジメントによって決定されたクリティカルな割り当てを継続する
セキュリティ関連のSlackチャンネルを監視し対応する；委任する
オンコールおよびインシデント処理プロセスを改善する - Issueや必要なサポートチケットをオープンすることで、オンコール関連の問題と改善の機会を文書化する。
可能な範囲で進行中の作業を継続する
トリアージエンジニアの委任責任
委任により、チームは適切なカバレッジと応答時間を維持しながら、グローバルなチーム全体に作業負荷を分散することができます。また、1人がインシデント量の急増を処理しなければならないリスクを最小化します。
- オンコールエンジニアは、初期トリアージを実施した後、インシデントを他のエンジニアに委任する必要があります。
- 委任のガイドライン:
- S1またはS2に分類されたインシデントは、現在の日中の地域で対応可能なチームメンバーにのみ委任すべきです。
- その他のすべてのインシデントは、いずれの地域でも休暇中でないチームメンバーに割り当てることができます。
- 時々、チームメンバーは優先度の高い、時間的に重要な割り当てに取り組んでおり、一時的に委任を受けられないことがあります。これらの状況はチームに透明性をもって伝える必要があります。これらのチームメンバーが意図せずに委任されたインシデントを受け取った場合、マネージャーと協力してインシデントの再割り当ての支援を求めるべきです。
- 緊急性の高いインシデントに取り組むことができる他のチームメンバーがいない場合、オンコールエンジニアは最後の手段となります。
インシデントの所有権
初期トリアージの後にインシデントに割り当てられた人が、インシデントの解決に責任を負う人物となります。GitLabインシデントのassigneeフィールドを使用して責任者を特定してください。重大度1または重大度2のインシデントの場合、インシデントが封じ込められるまで、世界中で作業を継続する必要があります。複数の人が1つのインシデントに取り組む場合、作業はそれぞれのassigneeを持つタスクに分割されます。
インシデントの所有権を持つということは、以下に責任を負う人物であることを意味します。
- 封じ込められた、または解決された状態への継続的な進行を確保する
- 高重大度のインシデントの24時間365日の継続的なカバレッジを維持する
- 正確かつ適時なIssue追跡とステークホルダーとのコミュニケーション
- 適切な文書化とコミュニケーション
責任者であるということは、インシデントタスクを実行する唯一の人物であることを意味するわけではありません。すべての部門のチームメンバーがインシデント解決の支援のために呼び出される可能性があり、これらの依頼はタスクまたは関連Issueとして文書化されるべきです。
例外
この手順への例外は、情報セキュリティポリシー例外管理プロセス に従って追跡されます。
c955a93f)