Asana による Asana の使い方: セキュリティインシデント対応

この記事は英語でもお読みいただけます。

一般的に、セキュリティインシデント対応は、テキストによるチャットやビデオ通話、共同作業用文書などを用いて行われます。Asana のセキュリティチームはどうかと言うと、当然のように、インシデント対応を含むほぼすべてに Asana を使用しています。当社は、この作業の最初から最後までをグローバルチームと共に管理、追跡するためのセキュリティインシデント対応テンプレート* を作成しました。この記事では、コラボレーションを高め、一層効果的なインシデント対応を実現する当社のテンプレートのポイントを 6 つご紹介します。

1. 誰が何をいつまでに行うかを把握する

セキュリティインシデントの対応に関わったことのある人の多くは、特定のタスクや、インシデント全体の状況がわからなかったり、何から始めればいいのかわからないという経験をしたことがあるでしょう。Asana は、そういった状況はあってはならないと考えました。

当社では、プロジェクトの一番上の部分に Roles (役割) と呼ばれるセクションを設けることにより、インシデント対応における役割を明確にするプロジェクトテンプレートをセットアップしています。このセクションでは、インシデント対応プロセスにおいて、誰がどのような役割を担うのかを明確にします。特定の作業の担当者や法務部門または通信部門といった他の部門からの参加メンバーを知りたい場合は、プロジェクト内のこのセクションを見れば確認できます。これは、メンバーがローテーションを組み、長期に渡って対応するようなインシデントでも効果を発揮します。

メモ: この記事に使用されているすべてのプロジェクト画像は例であり、当社のセキュリティチームが実際に使用しているプロジェクトやタスクの画像ではありません。

こうした役割は、Asana タスクではあるものの、ここでは参考用のタスクとして使用しており、インシデントへの対応が完全に終了するまでは完了にしません。Asana では、よくこのような形でタスクを使って担当業務を文書化しています。

また、必要なアクションは、Emergency Mitigations (緊急緩和措置) セクションで追跡し、そこに担当者と期日も記載します。そうして、対処済みのアクションと未対処のアクションを明確にしています。インシデント対応チームのメンバーなら、誰でも緩和措置を提案できます。複雑なインシデントの場合は、オートメーションを使い、新しく提案された緩和措置をインシデント対応コーディネーターに割り当て、承認を求めることもよくあります。

2. 作業の邪魔をせずに質問をする

チームが速やかに緩和措置を講じようとしている場面で関係者に質問を投げかけると、メンバーたちがフラストレーションを感じる大きな原因となります。そうした質問は、仕事の邪魔のように感じられることもありますが、実は大事な質問であることも珍しくありません。

そうした作業の中断を減らすために、プロジェクトテンプレートには、調査用の Q&A セクションを設けており、インシデント対応コーディネーターから関係者、チームメンバーを含む、すべてのメンバーがそのセクションに質問をタスクとして追加できるようにしています。質問は、私たちが適時に回答できるようになっており、場合によっては、質問に他の質問や修復作業との依存関係を持たせることもあります。そうすることで、その質問の回答ステップやいつ回答されるのかを明確にしています。

3. 承認を追跡する

インシデント対応では、主要な機能を無効にしたり、影響を受けた顧客に通知をしたり、多額のお金を費やしたりと、難しい決定を余儀なくされる場合もあれば、送信するメッセージの内容が正しいことを確認するだけでよい場合もあります。

そうした決定は、Asana の承認タスクを使って追跡しています。メッセージや決定の内容を示す親タスクと、その承認を得るためのサブタスクを作成するのが一般的です。承認タスクの承認、差し戻し、却下は、主な意思決定者が行います。

承認リクエストが却下された、または差し戻された場合は、提案内容を再度確認し、状況に合わせて調整します。

4. 明確なステータス更新

重大なインシデントの場合は、緩和措置の進捗状況を把握しておきたいと感じるメンバーがたくさんいるものです。当社では、プロジェクト内でステータス更新を使い、セキュリティインシデントの最新情報をすべての関係者に周知することにより、プロジェクト内の細かな情報を追って確認しなくてもいいようにしています。

関係者は、質問があれば、ステータス更新にコメントを投稿したり、プロジェクトの Q&A セクションで質問したりできます。

ステータス更新は、インシデントの履歴を簡単に確認できる手段にもなります。その情報は、問題の要因について考えるなぜなぜ分析で使用したり、監査目的で使用したりできます。

当社では、各自が責任感を持ってインシデントのステータス更新を定期的に投稿しており、投稿に関して一貫性を持たせるために、社内で KR (成果指標) も設定しています。

5. アクションアイテムを割り当てる

インシデント対応では、フォローアップのアクションアイテムが抜けていることがよくあります。アクションアイテムへの対応が行われないと、インシデントのクローズ後は背景情報がすぐに忘れ去られてしまいます。インシデントのクローズ後は、セキュリティ体制をどのように改善するのか、記録することが重要になります。記録が行われないと、同じセキュリティインシデントが繰り返し発生するリスクを負いかねません。

重要なアクションアイテムは、マルチホーミングを使って追跡しています。マルチホーミングとは、同じタスクを複数のプロジェクトに追加できる機能です。タスクが何らかの形で編集または変更されると、その内容が自動的にそのタスクが追加されているすべてのプロジェクトに反映されます。各緩和措置アイテムは、チームのバックログに入ります。同じ緩和措置アイテムが複数のインシデントプロジェクトに存在する場合、それが即座に解決する必要のあるものだとわかります。

Long-term Mitigations (長期緩和措置) セクションに追加されるタスクは、自動的に Security Incident Action Items (セキュリティインシデントアクションアイテム) と呼ばれる別のプロジェクトにマルチホーミングされます。このバックログを定期的にモニタリングして、セキュリティインシデントの中でもインパクトの大きなアクションアイテムを優先することがベストプラクティスとされています。当社は、定期的にアクションアイテムの優先順位を設定し直し、タイムリーな対応を実現するために Asana のカスタムボットを使用しています。

6. 一度に複数のインシデント対応を実行する

当社は、すべてのセキュリティインシデントプロジェクトが保管されるプライマリセキュリティインシデントポートフォリオを使用しています。そうすることで、複数のインシデントを同時に追跡できます。プロジェクトにはカスタムフィールドを使って深刻度のラベルを付け、適切にソートすることにより、最も深刻度の高い SEV0 のインシデントに一番注意できるようにしています。

当社は、セキュリティインシデントの指標や、全体的な最新情報およびインサイトを提供するために、ポートフォリオのステータス更新を定期的に行っています。

コラボレーションの質を高めてセキュリティインシデント対応を改善する

セキュリティインシデント対応の管理に Asana を使うようになったおかげで、一元管理された空間を使うようになり、チャットやビデオ通話、コラボレーション用文書を使わなくなったため、コラボレーションが大きく改善されました。世界中のチームメイトとシームレスに連携できるため、誰が何をいつまでに行うのかを把握できるだけでなく、関係者に最新情報を周知することもできます。

いかがでしょうか？皆さまの会社では、セキュリティインシデント対応をどのようにコーディネートされていますか？

*このプロジェクトテンプレートの最初の設計は、Ryan McGeehan 氏がセキュリティ侵害対応アジェンダについて執筆したブログ記事から多くのヒントを得て行われました。Ryan さん、ありがとうございます！インシデント発生時に私たちが担う役割は、PagerDuty のインシデントコマンダーフレームワークからアイデアを得ています。