情報セキュリティインシデント発生のリスクと対応(2)
3 回連載の 2 回目は、情報セキュリティ インシデントが実際に発生した際に、どのように対応するべきかを考えます。
緊急事態への対処
情報セキュリティインシデント（以下、単に「インシデント」と呼びます。）への対応は、企業や組織にとっては、危機管理という側面でとらえられるケースが多いように思います。
図 1 島原まゆやまロードから雲仙普賢岳を望む
最も身近な危機管理の例は、地震の発生、台風を始めとする風水害、火山の噴火等による自然災害（以下、「自然災害等」と言います。）でしょう。
写真は、長崎県の雲仙普賢岳（右側の雪の積もった峰が「平成新山」）です。近年では 1990 年（平成 2 年）に噴火が始まり、1991 年（平成 3 年） 6月には火砕流により多数の人的被害が発生しました。それから四半世紀が立ちますが、ご覧の通り、火砕流の跡が山頂から海までくっきりと残っています。自然災害のスケールの大きさが身をもって体験できる場所です。
図 2 豪雪への備えも危機管理（秋田県乳頭温泉郷）
日本政府においては、こうした自然災害の他にも「周辺国等からの武力攻撃事態」「航空・海上・鉄道等の重大事故」「ハイジャックやテロ等の重大事件」「パンデミック（世界的な感染症）の発生」等の事態が生じた場合には、総理官邸内の危機管理センターに情報連絡室や官邸対策室等を設置し、速やかな事態の把握、被災者の救出、被害拡大の防止、事態の終結に向けた対策の協議等を行います。先日公開された映画「シン・ゴジラ」では、この事態対処（「インシデントレスポンス」とも呼びます。）の様子も描かれており、記憶に新しい方もいらっしゃるのではないでしょうか。
情報セキュリティ インシデントの初動対応
情報システムにおいて、インシデントが発生した際の初動対応の流れに関しては、基本的に事態対処と同様の考え方ができます。
すなわち、発生した後に (1)速やかな事態の把握 (2)被害拡大の防止 (3)事態の終結に向けた対策 以上の対応が必要となります。
(1) 速やかな事態の把握
「速やかな事態の把握」とは、まず、ユーザ等からシステム管理者や CSIRT（Computer Security Incident Response Team、シーサート）にインシデント発生の申告があった際に、いつ、どのような事実経過をたどったかを整理することを言います。例えば、いつ、誰が、どのマルウェアを実行したのか、あるいは Web 改ざんが発生していることにいつ、どのように気づいたのかという事実です。これらのシステム関連の事柄に留まらず、発生の事実をいつ、誰に報告したのか、どのような行動をとったのかについても記録しておくことが必要です。
これは、クロノロ（クロノロジーの略、chronology）とも呼ばれ、後に原因究明を行う際にも、非常に大切な役割を果たすので、少なくとも、拡大防止策が講じられるまでの間の時系列は記録として残しておくとよいでしょう。
また、事実経過を整理した後は、情報を現場の管理者に留めることなく関係者、特にシステムや業務に関し判断が出来る責任者に報告し、随時判断を仰ぐ必要があります。
(2) 被害拡大の防止
次に、インシデント発生により組織にどのような影響の可能性があり、業務を継続した場合にどのようなリスクが考えられるかを考慮した上で、被害拡大の防止を行う必要があります。
例えば、PC のマルウェア感染事案であれば、感染端末の特定と抜線、あるいは感染セグメントの隔離が必要とされる措置です。インシデントは情報システム上で発生する出来事ですので、基本的にはシステムやサーバをシャットダウンするか、ネットワークから隔離すればそれ以上の被害拡大を防ぐことができます。
しかし、何らかの業務継続を行う必要がある場合には、何を中断し、何を運用し続けるか、運用を続けることのリスクを考慮し、経営上・組織運営上の判断をしなくてはなりません。一般にシステム管理者や CSIRT がこれらを判断し、実行に移すことは困難ですので、その意味においても (1) における事実経過の整理は重要となってきます。
(3) 事態の終結に向けた対策
インシデントが発生した際に、初動対応のひとまずの終結の目安は、対策を施し、同様の事案が発生しないようにした上で、システムの運用を再開することです。この前提として、システム上・運用上の予防措置と共に、インシデントを一般に公表するのか否か、また対外的にどのように説明するのかという点が重要ですが、これについては次回（第 3 回）に詳しく取り上げます。
情報セキュリティインシデントの特徴と留意点
一方、インシデントは、USB メモリの紛失事案などでない限り、主にサイバー空間という目に見えない仮想空間で発生する出来事ですので、自然災害等と次の点で大きく異なる点もあるため、注意が必要です。
(1) 発生した事実に当事者が気づかないことが多い
情報システムにおいてインシデントが発生した場合に、当事者が発生に気づかないケースが多くあります。例えば標的型メール攻撃により、PC 上でマルウェアを実行してしまった場合に、実行した本人がマルウェアを実行したことに気付かないばかりか、システム管理者ですら気付かないのです。なぜこのようなことが発生するのでしょうか。
自然災害等は発生した事実を察知するのには、さほど時間はかかりません。これは、被害が発生した場合に状況の変化が発生し、人間の五感でかんたんに異常な状態であることを把握することができるためです。
例えば、地震は発生すれば揺れを感じますし、大雨により崖崩れや堤防の決壊が起きれば視覚で発生を確認することができます。こうした理由により、自然災害発生時の総理官邸や地方自治体においては、発生後わずか数分～ 1 時間程度で対応できる体制が編成されます。
これに対して、インシデント発生時には被害の発生や状況の変化をかんたんに把握できず調査が必要なため、気づいた時（あるいは、結局は自分で気づけずに外部から発生を指摘された時）には、すでに大きな被害が発生している例も少なくありません。筆者の経験では、何年間も外部から侵入した形跡があることに気づかないケースもあります。
もう一つの理由は、近年よく指摘される「サイバー攻撃の複雑化・巧妙化」によるものです。
例えば、日本人の会社勤務のサラリーマンが職場で使用している PC で「件名：医療費通知」「添付ファイル名：医療費通知のお知らせ.lzh」のメールを受信した際に、これが標的型攻撃によるメール送信と見破るのはほぼ不可能です。また、メールに添付されているマルウェアも、送信先に応じ攻撃者がカスタマイズした「新種」のものであり、旧来のパターンファイルによるウィルス対策ソフトでは検出できません。
近年は、このような状況もあり、24 時間 365 日休むことなくネットワークやデバイスの監視を行い、サイバー攻撃の検出と分析、対応策のアドバイスを行う組織「SoC」（Security Operation Center）が注目されており、組織で SoC を立ち上げたり、SoC をセキュリティ サービスとして提供している会社もあります。しかし、残念ながらこうした SoC も万能ではなく、システムまたは端末の管理者権限が奪取され、遠隔操作で「正常な」メール送受信や Web 通信により情報が外部に漏えいされた場合は「正常な」通信としてしか認知されず、検知のしようがありません。
「特定の対策のみを過信せず、サイバー攻撃を前提とした多層防御が必要」と言われるのはこのためです。
(2) 被害の全容を特定するのに時間を要したり、わからないケースが多い
通常、自然災害等の発生においては、（東日本大震災のような大規模かつ広範囲な災害の場合、被害の全容把握するのには時間を要しますが、）大抵は発生当日ないし数日中には被害の全容が明らかになります。
一方、サイバーの世界では、被害の全容を特定するのに時間を要したり、結局詳細がわからないケースも多くあります。理由としては、いくつかありますが、（ア）マルウェアが侵入してから時間が経っており、ログを短期間しか保存していないため調査が不可能な場合 （イ） 内部情報が外部に流出した形跡があるものの、その証拠を消されているため追跡できない場合 （ウ） 広範囲にマルウェア侵入しているため、デジタルフォレンジック（端末の全部調査）に多額の費用や時間がかかり、調査が現実的にできない場合 などが考えられます。
(3) 対処マニュアル化が難しい
自然災害等が発生した場合に備え、国や地方自治体、企業においては対応マニュアルや BCP（Business continuity planning、業務継続計画）をあらかじめ作成しており、さらに事前に訓練も追加で実施している組織もあります。このように「事前準備」ができるのは、自然災害等に関しては、人的被害の把握・救助を最優先に対応し、次に生活インフラの復旧につとめるなど、どのような措置が必要なのかを事前にある程度想定できるためです。
先ほど取り上げた映画「シン・ゴジラ」の中では、東京都立川市の立川広域防災基地が登場しましたが、これは、政府の BCP において、首都直下地震等の発生の際に都心部が壊滅したり、通信が途絶した場合に、緊急災害対策本部が立川広域防災基地に設置されることを想定していることを元にしたものです。
一方、情報システムの場合には、同じような事前準備が行われている例はほとんどなく、ある程度のシナリオを組んだ上で、そのシナリオに沿った訓練が一部で行われているのみです。
例えば DDoS 攻撃で、Web サイトの閲覧が困難になったケースと、マルウェア感染による情報流出したケースでは業務継続性への影響が大きく異なりますし、情報流出事案でもその流出した疑いのある情報の内容、件数によっては、「炎上」することも考えられます。その時々のタイミングで組織へのインパクトやマスコミ・世論の反響も異なり、その時々に応じた判断や対応を求められる点も、情報システムにおけるインシデントの特徴です。
| リスクの種類 | 自然災害 | 情報セキュリティインシデント |
| 発生時 | 人間の五感での検知が可能 | 被害の有無の調査が必要 |
| 発生の検知 | 容易 | 気づかないケースが多い |
| 複合的リスク被害の特定 | 容易なケースが多い | 困難なケースが多い |
| 対処のマニュアル化 | 比較的容易 | 困難 （最低限の報告手順等を決めておき、状況により判断が必要） |
| 事前の訓練 | 可能 | ある程度シナリオを決める前提で可能 |
以上のように、自然災害と情報セキュリティインシデントには共通点と相違点の双方があります。それぞれをよく理解した上で、インシデント発生時には対応する必要があります。
次回（第 3 回）は、情報セキュリティインシデント発生の際の公表の意義について考えていきます。
Tags:
