2022年9月2日

今年度から私は新しい仕事の取り組みとして、弊社のお客様先で発生したセキュリティインシデントの対応業務を担当しています。今回のブログでは私がインシデント対応業務を行う中で気を付けていること・ポイントだと思うことについてご紹介したいと思います。あくまで私個人が気を付けていることを記載したため、”このやり方が正しい”ということではありません。インシデント対応でこのような考え方もある、という参考にしてもらえればと思います。また、ここでは細かい技術的な話は取り扱いません。あくまでインシデント対応の各段階においてどのような考え方で取り組んでいるかということを紹介していきます。
前提として、私はインシデントが発生したお客様のシステム担当者から相談を受けて支援するという形で対応にあたっています。例えば以下の図1のようなイメージで、インシデント対応チームとして業務にあたっています。

以降では下記のインシデント対応の流れに沿って説明します。

1．最初の一歩

ここでは私たちにインシデント対応の相談が来た時にまずどのようなことに気を付けているかを説明します。

本当にインシデントなのか確認する

インシデントの相談が来た際、素早い対応が求められるということもあり、どのような原因でインシデントが発生したかという前提で話を進めてしまうことがあります。しかし、そもそもインシデントが本当に発生したのかというところについて疑う必要があると思います。例えば、お客様のシステムでアンチウイルスソフトがアラートを出したため感染したと思い、NECに連絡が来た事例がありました。そこで状況をうかがって話を整理したところ、アンチウイルスソフトの誤検知の可能性が考えられました。そのため、まずはアンチウイルスソフトの誤検知ではないかどうかを確認から始めることを提案しました。インシデントが発生したということで話を進めていくと人的コストが発生しますし、本格的に調査が開始すれば金銭的コストが発生します。お客様にとってもコストがかかることは可能な限り避けたいはずですので、まずは本当にインシデントが発生したかを確認します。

インシデント対応完了に向けたゴールと道筋を設定し、関係者間で合意する

インシデント対応に入る際に私がまず考えることは、どうすればこのインシデントの対応が完了したと言えるかのゴールを設定することです。インシデントが発生すると、素早い対応が求められるためついつい場当たり的な対応をしてしまうことがあります。そうすると、「この作業は何のためにやっているのか」というのが曖昧になってしまい、回り道をしてしまうことがあります。そうならないためにも、最初にインシデント対応が完了するまでの具体的な道筋を明らかにしてそれを提案し、関係者間で合意するのが良いと考えています。

また、このとき、基本的にはお客様の要望に従います。例えば、「復旧を最優先にしたいので調査は最低限にしてほしい」や、「復旧に時間がかかってもよいので、調査で原因究明と被害をしっかり明らかにしてほしい」などが考えられます。ただし、お客様としてはインシデントにどう対応すればよいかわからないというケースがほとんどだと思います。そのため、まず提案する側としてはお客様に対応状況・方針を報告し、合意に至るためにはどうしたらいいかという観点で検討し、提案する。そして、提案の中でお客様から方針の違いや追加の期待などがあればそれもインシデント対応完了までのタスクに組み込むというのがゴール設定の流れだと考えています。

責任の所在を明らかにする

日本ではお客様のシステム開発・運用・保守に複数のベンダーが関わっている場合があります。その際、誰がどの範囲について責任があり、対応する必要があるのかを明確にするのが良いと考えています。例えば、システム開発と運用保守でベンダーが異なる場合、システム開発上での脆弱性や設定ミスの責任はシステム開発したベンダーにあります。運用・保守でのパッチ未適用や設定ミスについては、ベンダーがお客様からパッチ適用や設定変更について契約を結んでいるか確認します。これは、この後の段階で各関係者がオーナーシップをもって作業にあたるために必要なことだと思います。

2．一時的な封じ込め・復旧

マルウェア感染が疑われる場合、一時的な封じ込めが必要になります。一時的な封じ込めではマルウェアによるインシデントの影響を最小限にするための措置を講じます。具体的には、インシデントが起きたサーバやPCをネットワークから遮断してオフラインにしたり、設定を変更して問題がある機能を停止したりします。封じ込め措置についてはインシデント発生が確認されてすぐにお客様側で対応されている場合もありますが、封じ込めが適切に行われているかどうかは確認するようにしています。

このような封じ込め措置によってお客様のビジネスが継続できない場合があります。例えば、組織のネットワークを完全に外部から遮断した場合、外部とのメール連絡ができない、ECサイト等が停止するといったことがあります。インシデント対応のためにビジネスが継続できない状態が続き、組織が致命的な損害を被ることは避ける必要があります。そのため、お客様の希望に応じて部分的にビジネスを再開・継続させるために、完全に侵害されていない環境を別途用意するなどの一時的な復旧措置を提案することもあります。

3．調査

調査は復旧に向けた重要な段階だと考えています。復旧にどれくらいの時間やお金がかかるかはここでの調査結果次第になります。お客様としては予算調達などの調整の都合もあるため、この段階は早々に完了することが求められると考えています。

ここで、インシデント対応のための調査には侵入経路の特定と影響範囲の特定、被害の特定の3つの目的があると考えています。

侵入経路の特定

侵入経路の特定では、どこからシステムに侵入されたのかを特定します。これができていないと、脆弱性を解消できず再度同じ方法で侵入されてしまう可能性があるため、必須の調査だと考えています。

侵入経路の特定方法としては、例えば被害のあったシステム（ネットワーク）とインターネットなどの外部との接点を洗い出し、各接点について可能性を検討していきます。

影響範囲の特定

影響範囲の特定では、インシデントの範囲を特定します。これができていないと、システムの復旧の対象範囲が決まらないため、これも必須の調査だと考えています。

ここで、範囲には2つの観点があると考えています。

1つ目は時間的な意味での範囲です。具体的には、いつから侵入されていたかということです。それによって、例えばどこまでの時点まで戻してデータを復旧させればよいのかなど、復旧の段階に関わってきます。

2つ目は空間的な意味での範囲です。いわゆるネットワーク構成図上でどこからどこまでに侵害の可能性があったのかということです。これによって、例えば、どのシステムを新たに置き換えるかなど、復旧の段階に関わってきます。

被害の特定

被害の特定では、CIA（Confidentiality, Integrity, and Availability）の観点で侵害があるかどうかを特定します。例えば、重要な情報の漏えいや改ざんがないかなどを調査します。これも、侵害があったものについての対応を検討するという意味で復旧に関わってきます。

4．復旧

復旧では調査の段階で明らかになった情報をもとに、システムを正常に戻します。例えば、侵入経路の起点になった脆弱性への対策や、異常なデータを正常に戻したり、侵害の可能性のある部分のシステムを新規に置き換えるなどの対応が挙げられます。

お客様に復旧方法について提案する際は、単に今回問題があったところについてのみ対策するということではなく、継続的なセキュリティ対策についても提案するのが良いと考えています。例えば、暫定的な対策として侵入の契機となった脆弱性のパッチをあてるということだけでなく、恒久的な対策としてパッチ適用の運用体制を整えるといったことが考えられます。

まとめ

お客様にセキュリティ対策について提案する際は、第一にセキュリティの観点での理想論に沿った内容を説明することだと考えています。しかし、セキュリティの理想論を現場に適用するというのは実際には難しいことであり、お客様にそのまま受け入れられることもあまり無いと思います。

それでもあえて理想論に沿った内容を提案するのは、セキュリティの対策に抜け漏れが無いようするためです。最初からお客様の事情に沿ったセキュリティ対策から検討に入ってしまうと、対策に抜け漏れが発生してしまうことが懸念されます。また、お客様システムの担当者の方で先回りしてセキュリティ対策を提案したつもりが、お客様との間で認識に齟齬が発生する懸念もあります。

最初に理想論に沿った抜け漏れのないセキュリティ対策を提案した後で、お客様側の事情に沿ったセキュリティ対策の調整を進めて合意していきます。そうすることで、お客様とセキュリティ対策の内容について認識の齟齬無く、そして対策の漏れなく復旧を進めていけると考えています。

一般的に、日本ではシステムの調達や開発は自社ではなく他社のベンダーに任せているところが多いです。そのためか、インシデントが発生するとお客様としてはどうしたらいいかわからないということが多いのではないかと思います。そういった場合に、お客様のビジネスが最小限の被害・コストで適切に再開・継続できるよう、お客様の事情に合わせた最適な提案・対応ができるようにしたいと思っています。

本ブログが少しでもみなさんの役に立ち、安心・安全な社会に少しでも寄与することを願っています。

執筆者の他の記事を読む