「すべてのインシデントに対して同じ対応を取るべきか？」これは簡単な質問のようで、その答えには大きな意味が隠されています。

例えば、メールサービスが停止し、サービスデスクに数名のユーザーからメールが受信できないと苦情が寄せられているとします。サービス停止の原因がサーバーのアップデート後に行った構成の問題であった場合、対象となったユーザーの生産性の損失によってこのサービス停止が企業にもたらした影響は数値化できます。ところが、悪意のある行為が原因で、メールサービスの停止がさらに深刻なセキュリティ侵害の最初の予兆であった場合、このサービス停止が企業にもたらす影響は計り知れないほど大きくなる可能性があります。

サービスデスク：セキュリティインシデント発生時に最前線での対応が求められる存在

サービス部門のほとんどが、インシデントを速やかに解決し、社員やユーザーを通常通り業務にあたれる環境に戻すために取り組むことをインシデント管理だと考えています。たしかにほぼすべての種類のインシデントに対してこのアプローチは効果を発揮しますが、前述の例のようにセキュリティ関連のインシデントには深刻なリスクや影響につながる可能性があるため、個別に対応することが求められます。

セキュリティ関連のインシデントが発生した場合、セキュリティ専門の部門と連携するとしても、IT部門を代表して矢面に立ち、最前線で取り組みを行うのはサービスデスクとなります。したがって、サービスデスクは、協調された対応に欠かせない役割を担う必要があります。言うまでもありませんが、サービスチームは通常重大なインシデントが発生した場合や事態がさらに深刻化した場合、コミュニケーションや調整の中心的な役割を担います。

重大なセキュリティインシデントへの対応方法を計画する最悪のタイミングは重大なインシデント発生中です。したがって、サービス部門は、セキュリティインシデントに対応する方法を主体的に計画し、備える必要があるのです。十分に備えていないことは、あるIT部門の責任者が言うように「最終進入路で航空機を作ろうとする」ことと同じくらい無謀なことなのです。セキュリティに関連する攻撃の発生頻度が増え、その脅威が高まっていることを踏まえ、多くの企業が重大なインシデントが発生した「場合」ではなく、重大なインシデントは「いつ」発生するのかを不安視するようになっています。

セキュリティインシデント管理（SIM）計画

サービス部門が自社のセキュリティインシデント管理（SIM）計画を策定する場合、他のIT部門だけでなく、関係する可能性のある他の部門とも連携し計画を策定することが理想的であり、これはサービス部門への推奨事項のひとつとされています。

その理由は、重大なセキュリティインシデントには、すぐに発生するIT関連の問題の枠をはるかに超える影響、例えば法的責任やプライバシーのリスク、ガバナンスの問題などの影響を企業にもたらす可能性があるためです。

ただし、すべてのセキュリティインシデントにすべての社員を関わらせるべきだということではありません。考えられる幅広い影響からのリスクに対応し、リスクを軽減するために総合的な対応計画を策定するべきだということです。

様々な部門と連携してSIM計画を策定する場合は、関わる各部門の役割と責任を決めてください。セキュリティインシデントの種類と範囲に基づいて役割と責任を割り当てる際は、RACIモデル（Responsible/実行責任者、Accountable/説明責任者、Consulted/協業先、Informed/報告先）を活用することを検討してください。セキュリティ部門だけでなく、各部門の窓口を決め、合意を得てください。侵害が発生してから特定の措置の承認を行う社員を決めるのではなく、SIM計画の一環として承認者を決定してください。また、クリティカルな状況下でリクエストが「保留」のまま放置されることがないよう、対応時間と承認者の代理を務める社員も決定してください。

さらに、インシデント発生中に収集する必要のあるデータと情報についても検討してください。これは、インシデントの範囲や対応を特定する際はもちろん、すべての問題が解決したインシデント後に対応を評価し、改善する際にも役立ちます。

フライトに向け準備を行うパイロット同様、異なる種類のサービス、アプリケーション、デバイス、資産、構成アイテムを対象に、隔離、シャットダウン、復元、試験といったオペレーション上の手動でのタスク、手順、確認、通知や承認をできる限り無くすための自動化ツールを活用すれば、セキュリティ対応の最中に重大なことを「見落とす」リスクを軽減できるでしょう。

SIM計画を策定したら、対象のスタッフを指導し、定期的に計画の模擬訓練を実施してください。また、考えられるセキュリティインシデントを特定するトレーニングを実施してください。加えて、手順が徹底されていること、効果を発揮することを確認するため実際のインシデントを想定した訓練を行い、改善の余地があるエリアを特定してください。

SIMには障害復旧計画と類似点があります

SIM計画は、障害復旧（DR）計画に類似しています。どちらも策定しておくことは大切ですが、誰もが実際に使用する機会が訪れないことを願うものでもあります。もしセキュリティインシデントに直面し、SIM計画を実行に移さなければならなくなった場合には、インシデントを解決後、必ず時間をかけて対応を改善する方法を判断してください。記憶が曖昧になる前にインシデントを見直し、インシデント発生中に収集したデータと情報をまとめてください。

対応の責任を負う部門と共に見直しを行う際は、インシデントの背景を調査し、判断してください。「マスコミ」の取材のように、インシデントに関連する「人物、内容、場所、時間、方法、理由」を明らかにしてください。この情報は、訴訟手続きに必要になる可能性がある点にも留意してください。

また、対応全般についても評価してください。脅威の特定、軽減、復旧がどれほど速やかに実行されたかを分析し、評価してください。さらに備えを万全にするため、現行の防御とトレーニングの効果を正確に評価し、改善できるエリアを特定し、得た教訓を応用してください。

重大なインシデントの場合、軍隊で使用されている「事後」報告書と類似した報告書を経営陣向けに作成してください。対応の速度や効果の分析など、見直しの中で明らかになった事項を要約してください。また、考えられる金銭的影響と法的影響を忘れずに含めてください（これらの影響に関する情報は対応に関わる各部門から得ることができます）。

質問の例

見直しの中で検討すべき質問の例をいくつかご紹介します。もちろん、これよりも検討すべき質問は多くあるかと思いますが、ここでご紹介する例は、セキュリティインシデントへの対応改善に取り組むための第一歩を踏み出す上で役立てていただくことを目的としたものです。

  • インシデントの種類は？
  • インシデントは最初どのように検出されたか？
  • 初期段階で深刻度の評価が行われたか？
  • 対応計画はどの程度うまく機能したか？従わなかった手順があったか？役立った手順は？役立たなかった手順は？
  • 対応の指揮を執る社員は明確だったか？対応は効果的だったか？変更すべきことはあるか？
  • 役立つ可能性のあるデータや見解はあるか？
  • 部門内/部門間のコミュニケーションは効果的かつタイムリーだったか？うまく機能したことは何か？うまく機能しなかったことは何か？
  • 関わってもらうべきだったと思う部門はあったか？どの段階で関わってもらうべきだったか？
  • 次回インシデントが発生した場合、改善できることは何か？

備えあれば憂いなし

セキュリティ侵害とセキュリティインシデント（もしくはそれらを試みる行為）は、現存する脅威とそれを取り巻く環境を考慮すると発生して当然だと言えます。ただし、何事も備えあれば憂いなしです。サービス部門は（他のIT部門や企業と連携し）、今後起こり得るインシデントに起因するリスクに対応し、リスクを軽減する万全の態勢を整えている協調の取れたチームのために、十分に裏付けられた計画を用意することで、さらに保護を強化し、最悪の事態に備えることができます。