セキュリティインシデントコミュニケーション計画

目的

GitLab は、GitLab.com 上であるかセルフマネージドインスタンスであるかを問わず、お客様の情報のセキュリティを極めて真剣に受け止めています。GitLab の 透明性の価値 に沿って、セキュリティインシデントについて明確かつ迅速にコミュニケーションすることを信条としています。

スコープ

本コミュニケーションレスポンス計画は、セキュリティインシデントについて GitLab が社内ステークホルダーおよび社外顧客に通知し、エンゲージする際の、誰が、何を、いつ、どのようにを示します。本行動計画は、GitLab のリスクスコアリングマトリクス で概説される「高 (high)」以上の影響を持つセキュリティイベントの戦略とアプローチをカバーします。

役割と責任

手続き

インシデントとは

GitLab セキュリティチームは、GitLab セキュリティ、利用規約、その他の関連ポリシーの違反または違反の脅威を、セキュリティインシデントとして特定します。インシデントの特定方法の詳細については、GitLab セキュリティインシデントレスポンスガイド で確認できます。

💁 コーポレートインシデント対応

外部コミュニケーションのガイダンスが必要な Support または Infrastructure 管理のインシデントについては、コーポレートコミュニケーションインシデントレスポンス計画 を参照し、Slack の #external-comms 経由でそのチームにエンゲージしてください。

👷 インフラインシデント対応

Infrastructure インシデントについては、インフラインシデント管理およびコミュニケーションプロセス に従ってください。

インシデントの範囲/重大度の定義

セキュリティエンジニアオンコール は、セキュリティインシデントの範囲、重大度 、潜在的影響 を判断します。潜在的影響が判断されたら、適切な内部および外部コミュニケーション戦略の実施を開始する必要があります。

セキュリティインシデントにおける役割と責任

セキュリティチームの役割と責任

CMOC 責任の詳細

セキュリティ実務者およびインシデントレスポンスエンジニアとして、私たちのセキュリティアシュアランスおよびセキュリティオペレーションのチームとエンジニアは、初期メッセージを作成し、CMOC / コミュニケーションマネージャーオンコール の役割を担うのに最適な立場にあります。

各チームが任命する CMOC は、以下の DRI です:

• セキュリティインシデント外部レスポンス Issue テンプレート を開設し、潜在的なステークホルダーと貢献者をタグ付けする
• 初期メッセージのドラフト作成
• 様々なコンテンツの開発と展開の追跡
• 貢献、レビュー、承認のための主要ステークホルダー (サポート、セキュリティ/SIRT リーダーシップ、法務など) の特定
• 様々な関係者 (サポート、セキュリティ/SIRT リーダーシップ、法務など) からの承認のルーティングと取得
• 関連するインシデントレスポンス Slack チャンネルおよび Issue でのコミュニケーション開発の進捗について、ステークホルダーに最新情報を提供し、情報を共有する

Security External Communications 機能の責任の詳細

Security External Communications 機能 は、以下の DRI です:

• CMOC から 提供された 初期ドラフトの編集と改善
• 必要な適切なチャンネルとコミュニケーション形式に関する助言
• 外部使用準備が整っていることを確認するための、最終メッセージの承認ポイントとしての役割
• 追加のレビューおよび/またはメッセージのニーズ (公開/メディアステートメント) のために、PR とコーポレートコミュニケーションズとの連携
• PR (メディアステートメント)、コンテンツマーケティング (ブログ記事)、マーケティングオペレーションズチーム (メールレスポンス) との連携を通じてメッセージを展開する
• 認識と使用のため、Slack チャンネル (#social_media_action、#sales、#security_discuss、#customer-success) に最終コミュニケーション資料を投稿し、デベロッパーリレーションズへの認識のため @devrel をピングする
  • Support manager on call がサポートチームの認識を管理する

拡張チームの役割、責任、および連絡先

• マーケティングオペレーションズ: セキュリティインシデントで影響を受ける関係者にインシデント関連メールを送信する責任。このグループは マーケティング緊急レスポンスプロセス を確立しており、incident_communications テンプレートを使用して インシデントコミュニケーションリクエストを作成 し、割り当てられたタイムゾーンの coverage owner にタグ付けし、Slack の #mktgops チャンネルに Issue を投稿することでエンゲージされます。

  • Marketing Ops は MailGun または Marketo を通じてメールを送信できます。このグループは提供された情報に基づいて、配信に最適なプラットフォームを判断します。カスタム配信リストを作成する必要がある場合、データチームの関与が必要となる場合があります。

• サポートチーム: セキュリティエンジニアオンコールおよびコミュニケーションマネージャーオンコールから提供される背景情報と準備された応答を使用して、私たちのサポートチームはセキュリティインシデントに起因する顧客コミュニケーションをトリアージし応答します。Slack の #support_leadership 経由でオンコールマネージャーに連絡します。緊急の場合は、PagerDuty アラートをトリガーして Support Manager On-call をページング します。Slack で #support_leadership に移動し、/pd trigger と入力して Title フィールドに要約を書き、影響を受けるサービスの一覧から Support Managers を選択して、Create をクリックします。このグループがセキュリティインシデントとイベントを早期に認識できるよう、彼らは security-external-incident-or-event-response テンプレートで FYI として自動タグ付けされます。

• デベロッパーリレーションズ: ソーシャルチャンネル経由で顧客や一般大衆に応答する必要がある場合があるため、公開資料がリリースされる前にエンゲージする必要があります。彼らのインタラクションを支援するために、準備された応答や FAQ を提供する必要があります。このグループには任意の Slack チャンネルで @devrel をピングして連絡します。このグループがセキュリティインシデントとイベントを早期に認識できるよう、彼らは security-external-incident-or-event-response テンプレートで FYI として自動タグ付けされます。

• 指定承認者 (Designated Approvers): これは、セキュリティインシデント用に開発された各コミュニケーションについてレビュアーおよび承認者として行動する個人のグループです。Security、Support、Customer Success、Legal、Corporate Communications、Investor Relations の代表者が含まれます。

内部コミュニケーション

セキュリティインシデントは、高プレッシャー、高ストレスの状況になり得ます。誰もが調査、範囲、軽減等の周辺の詳細を理解しようとしています。セキュリティ、インフラストラクチャ、エンジニアリング、オペレーションチーム間のステークホルダーが情報を得てエンゲージされていることを確実にすることは、セキュリティインシデントマネージャーオンコールの主な責任の 1 つです。セキュリティインシデントマネージャーオンコール は、インシデントの技術的詳細に深入りせず、以下を含む高レベルのステータス更新を提供することに焦点を当てるべきです。

• 現在のリスク
• 影響を受けたユーザー (一部、多数、すべて?)
• 影響を受けたサービス (本番、エンタープライズアプリ、その他)
• イベントのタイムライン
• 講じられた軽減ステップ
• インシデントの現在のステータス
• 次のステップ

GitLab チームメンバーへのコミュニケーション

チームメンバーに対するサービス停止が発生するたびに、CMOC は停止と関連 Issue に関する詳細を #whats-happening-at-gitlab に投稿し、関連するチャンネルにクロスポストする必要があります。これが gitlab.com に影響する本番インシデントなのか、組織で使用されているサービスなのかを特定することが重要です。

Slack のインシデントレスポンスチャンネル

進行中で継続的なコミュニケーションが必要なインシデントの場合、セキュリティエンジニアオンコール がインシデントレスポンス Slack チャンネルを設定します。すべてのセキュリティインシデントチームメンバーと拡張 POC を招待する必要があります。

主要な内部ステークホルダーへのエンゲージ (いつ/どのように)

外部コミュニケーション

外部コミュニケーションは、セキュリティインシデントの範囲と影響が判断され次第、簡潔で明確な言葉でできるだけ早く実施する必要があります。最初の外部コミュニケーションは影響を受けた当事者向けです。例: 影響を受けた顧客とサードパーティ (JiHu を含む) 、製品、サービスのプロバイダー、またはインシデントに関連したシステムコンポーネントのサプライチェーンに関わる組織。規制当局はインシデントの範囲、規制および法的要件に基づいて連絡されます。

顧客メッセージのターンアラウンド

外部レスポンスが必要と判断された場合、SIRT チームは S1 重大度の脆弱性について、6 時間以内に最終的な顧客コミュニケーションを開発し、承認を得て、配信または公開することを目指す必要があります。

セキュリティインシデント外部コミュニケーションのプロセス

1. 外部声明を出す必要がある、または何らかの方法で顧客とコミュニケーションする必要があると判断したら、セキュリティインシデント外部レスポンス Issue テンプレートを使用して新しい Issue を開設 します。この Issue は、SIMOC/SecCMOC がコンテンツ開発、レビュー、承認を追跡するために使用します。
2. 新しいセキュリティインシデント外部レスポンス Issue は SecCMOC に割り当てる必要があります。
3. 「この Issue を開設する際に CMOC が取るアクション」セクションのすべてのアクションが完了し、初期ドラフトが揃ったら、初回レビューおよびコミュニケーション形式/チャンネルに関する相談のため Corporate Communications team を Issue に追加します (詳細は下記)。

コミュニケーションのレビュー、承認、展開プロセス

1. 様々な提案されたコミュニケーションが準備できたら、SecCMOC は関連するセキュリティインシデント外部レスポンス Issue とセキュリティインシデント Slack チャンネルに Corporate Communications team を追加し、初回レビューと編集を行います。
2. 並行して、私たちの Security External Communications チームが適切なマーケティングチーム (PR、Marketing Ops、Content チーム) にサポートをエンゲージし、並行マーケティング支援とメッセージ展開の取り組みのために関連 Issue の作成を開始します。
3. Security External Communications がレビューを完了したら、SecCMOC は以下に概説するように、コラボレーションとレビューのために 指定主要承認者 にコミュニケーションドキュメントをルーティングする必要があります。すべての承認が達成されなければならない時刻 (目標展開時刻は 6 時間で、情報収集とコミュニケーションドラフト作成のための 1〜2 時間、ブログを公開しメールを展開するための 1 時間の展開時間を含みます) を必ず明記してください。この時点で、指定主要承認者 はドキュメントをレビューし必要な編集を行うために 30 分の時間があります。レビューはこの 30 分の時間制限内に提供されるか、代理が任命される必要があります。
4. すべてのフィードバックと編集が SecCMOC によってまとめられたら、最終レビューと承認のために Slack で 指定主要承認者 をタグ付けする必要があります。このレビューと承認プロセスは 30 分以内で完了する必要があり、承認者は作業中のインシデントレスポンスコミュニケーション Google ドキュメントの一番上の 承認マトリクス で承認をマークする必要があります。
5. コミュニケーションが最終確定したら、私たちの Security External Communications が適切なマーケティングおよびコミュニケーションチームと協力して、適切な外部および内部のオーディエンスにコミュニケーションを展開します。
6. 私たちの Security External Communications は、すべての最終資料と関連する展開の詳細が関連するコミュニケーション Issue に記載されていることを確認し、Issue をクローズします。

指定主要承認者 (Designated key approvers)

私たちの目的は、GitLab ユーザーに明確で正確な情報をできるだけ早く提供することです。S1 (重大) 脆弱性の場合、承認され展開されたコミュニケーションの目標ターンアラウンド時間は 6 時間です。この加速されたレスポンスウィンドウのため、私たちのセキュリティチーム (SecCMOC または Incident Commander) は、レビューおよび承認プロセスの開始時に承認の目標カットオフ時刻 (コミュニケーションドラフト開始から 6 時間) をアナウンスし、必要な場合、4 つの必須グループ (Security、Legal、Customer Success、Investor Relations) のうち少なくとも 2 つが承認した時点で、その時に進めます。詳細は下記を参照してください。

指定バックアップ承認者 (主要レビュアーが利用できないか応答しない場合にエンゲージ)

- 「必須」承認者については、少なくとも 2 名の指定バックアップ承認者が必要です。

• Security: VP of Security Operations が利用できない場合、VP of Security の 1 人が承認できます。利用できない場合は VP of Engineering に移ります。
• Legal: Senior Director of Legal, Privacy and Product が承認できます。利用できない場合は Legal Counsel、次に CLO に移ります。
• Customer Success: VP of Customer Success が承認できます。利用できない場合、Snr Director, Customer Success Managers、次に Director of Customer Success, Public Sector に移ります。
• Support Team: Support Manager on call が承認できます。利用できない場合、Support Senior Leadership のメンバーに移り、必要に応じて Support Managers に移ります。
• Corporate Comms: Director of Corp Comms が承認できます。利用できない場合、Manager, Public Relations に移り、必要に応じて Manager, Corp Comms に移ります。
• Investor Relations: VP of Investor Relations が承認できます。利用できない場合、Chief Financial Officer、次にバックアップ承認のために VP Finance and Business Technology に移ります。

指定主要承認者 の合意済みレスポンス時間

指定主要承認者 のレスポンス時間: 30 分

私たちのクライシスコムズ会社と GitLab のコーポレートインシデントレスポンス計画に従い、各承認者は、バックアップをエンゲージする前にコミュニケーションをレビューし応答する (フィードバックや編集を提供する) ために 30 分の時間があります。承認者からのフィードバックを受領、レビュー、統合した後、承認者からの最終レビューが要求され、各承認者は承認を提供するための 30 分のレスポンス時間があります。コミュニケーションの確立された展開時刻が近づいており、特定のチームのレビューと承認が 30 分以内に達成されない場合、4 つの必須グループ (Security、Legal、Customer Success、Investor Relations) のうち少なくとも 2 つから承認を得た時点で、最終確定と展開に進みます。詳細は下記を参照してください。

指定主要承認者 への緊急連絡

• 指定主要承認者 への連絡方法の詳細については この機密 Issue を参照してください。

指定バックアップ承認者へのエンゲージ

30 分が経過しても SecCMOC が特定の 指定主要承認者 から連絡を受けていない場合、その個人のすべての 指定バックアップ承認者 をインシデント関連の Slack チャンネルおよび Issue でエンゲージするように移行します。コミュニケーションの確立された展開時刻が近づいており、特定のチームのレビューと承認が 30 分以内に達成されない場合、4 つの必須グループ (Security、Legal、Customer Success、Investor Relations) のうち少なくとも 2 つから承認を得た時点で、最終確定と展開に進みます。

コミュニケーションチャンネルと形式

インシデントまたはイベントで使用されるコミュニケーションチャンネルと形式は様々ですが、お客様へのレスポンスの必要性と透明性の価値に整合し、お客様への潜在的なリスクと露出のバランスが取れている必要があります。

よく使用されるコミュニケーションの形式とチャンネル:

• 私たちの最も一般的な顧客レスポンスの形式は、影響を受けた顧客への直接のメールコミュニケーションです。
• より深い掘り下げレスポンスが必要な場合、またはセキュリティインシデントやイベントについてより広範なカバレッジを確保するために、緊急にブログ記事が開発される場合があります。
• 検討すべき 形式とチャンネルの詳細な解説 を参照してください
• JiHu へのコミュニケーションは、JiHu Slack ワークスペース内の #security-vulnerability チャンネル経由で行われる必要があります。

役立つテンプレートとランブック

• 👉 私たちの Security external incident or event response template (これは内部テンプレートです) には、各種コミュニケーションを開始するために使用できるテンプレート (コピーを作成する) へのリンクがあります。

• 📝 セキュリティインシデントコミュニケーションランブックは こちら (内部のみ) にあります。

外部対応チームの準備と支援

念頭に置くべき重要な点は、外部にコミュニケーションを行うときは常に、顧客および/またはコミュニティに影響する問題について外部コミュニケーションを行うことを、サポート、顧客、ソーシャル、デベロッパーリレーションズチームに通知する必要がある ということです。

このため、各インシデントレスポンス (直接メール、メディアステートメント、ブログ記事等) には、以下が付随する必要があります。

• ソーシャルメディアステートメント
• サポートおよび顧客対応チーム向け FAQ

GitLab.com 上の進行中のライブインシデント

GitLab.com 上の進行中のライブサイトインシデントについては、SIMOC/CMOC が status.io 経由で https://status.gitlab.com/ と @GitLabStatus Twitter ハンドルに更新を提供します。

外部声明およびその他の公的な公式コミュニケーション

インシデントに関連する範囲、影響、リスクに応じて、私たちのコーポレートコミュニケーションズおよびマーケティングチームは、追加のアウトリーチが必要と判断する場合があります。セキュリティインシデントに関する公式声明は、GitLab の Director of Corporate Communications、VP of Corporate Marketing、CMO、または VP of Security のいずれかが行います。

その他の役立つ情報

セキュリティインシデントで使用される潜在的なチャンネル

顧客コミュニケーションを開発・レビューするための同期ミーティング

適切な場合、貢献、レビュー、承認のための主要なステークホルダーは、Zoom セッションで同期的に集まり、顧客コミュニケーション (メール、FAQ、ブログ記事等) を作成および微調整する必要があります。この場合の同期ミーティングは、Security、カスタマーサポートおよびそれ以外のステークホルダーからの主要なインプットによりコミュニケーションの開発を加速し、迅速にレビュー段階に移行することを可能にします。これらの Zoom セッションは録画され、関連するセキュリティインシデント外部レスポンス Issue にリンクされます。

例外

本手続きの例外は、情報セキュリティポリシー例外管理プロセス に従って追跡されます。

参考文献

• Security Incident Response Guide
• Security Communications Runbooks (内部)
• Incident Communications Plan
• Marketing Emergency Response process

セキュリティインシデントコミュニケーションのレビューと承認のためのサンプル Issue テンプレート (公開アクセス可能)

この サンプル Issue テンプレート は、重大なセキュリティインシデントを取り巻くコミュニケーションについてルーティング、レビュー、承認の追跡に使用できます。これはサンプルのため、組織の構造、プロセス、ニーズに合わせて調整/修正/カスタマイズする必要があります。各組織は異なり、重大なセキュリティインシデントは様々であるため、GitLab はテンプレートの使用に関する結果を保証することはできません。

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