サイバーインシデントの最新動向と 各組織に期待される取り組みトピックス・イベントレポート
一般社団法人 JPCERTコーディネーションセンター
理事、最高技術責任者
真鍋 敬士 氏
-
※
所属・役職は2018年12月現在のものです。
世界では、日々さまざまなインシデントが発生しています。日本におけるインシデント情報をとりまとめる窓口がJPCERT／CCです。本セミナーでは、JPCERT／CCから最新のサイバーインシデント動向を紹介するとともに、万が一インシデントが発生した場合に、組織としてどのような対応が求められるのかを解説しています。
JPCERT／CCとは
真鍋氏が理事を務めるJPCERT／CC（JPCERTコーディネーションセンター：Japan Computer Emergency Response Team Coordination Center）は、セキュリティ対策における日本の窓口となるCSIRT（窓口CSIRT）であり、経済産業省からの委託事業として運営されており、基本的にほぼ無償でサービスを提供しています。おもな活動内容は、大きく分けて、「脆弱性情報ハンドリング」「情報収集・分析・発信」「インシデントハンドリング」です。
2000年前後に発生するサイバーセキュリティに関連する問題は、ほぼすべてが脆弱性に起因していたことから、経済産業省が脆弱性を適切にハンドリングするためのルールを定めました。同センターは、そのルールに則って活動する組織として、IPA（情報処理推進機構）と共同で脆弱性情報を受け付け、それをベンダーへ提供して対策への取り組みを促す、という活動を行っています。
近年のインシデント傾向
2018年4月～9月の期間にJPCERT／CCへ報告されたインシデントのうち、もっとも多かったのは「フィッシングサイト」（35.9％）で、システムの弱点を探す「スキャン」（34.5％）、「Webサイト改ざん」（7.8％）、「マルウェアサイト」（2.7％）がそれに続く、という結果でした。これまでは、「スキャン」が報告のほぼ半数を占めており、この半年間における「フィッシングサイト」の増加傾向は明らかです。
流出した情報がさらなる攻撃に利用されている？
真鍋氏は、近年発生したインシデントの例として、流出した認証情報データ（ID、パスワード）がダークウェブ（注1）で取引されていた事例を紹介しました。報道などでも取り上げられましたが、2017年12月には約14億件、2018年2月には約2億件のデータがダークウェブで取引されていたことが発覚しています。それらのデータの中には、日本に関連するものも含まれていました。
実は、こういった流出したデータが取引されるという事例は、近年に始まったことではありません。かなり以前より、こういった取引は行われています。
認証情報を含む、個人情報の流出はそれ自体も大きな問題ですが、それ以上に「どこから流出したか」が問題です。また、流出した情報が他の攻撃に利用されている、という問題もあります。真鍋氏によれば、近年行われている攻撃に用いられている認証情報は、2013年前後に流出したものです。なお、流出した認証情報は、リスト寄せやログイン試行によって、サイバー犯罪者にとって商品価値の高い（精度の高い）リストになっています。
情報流出のルートとしては、ECサイトなどへの侵入、マルウェア感染、フィッシング詐欺が主流です。そして、流出した情報が取引され、さらなる攻撃（サイトに侵入するためのリスト型攻撃、フィッシングメールの送付、カード情報の悪用など）に利用される……というサイクルができあがっていると考えられます。
かつてフィッシングといえば、金融機関の口座の情報を狙ったものが一般的でした。しかし、近年はECサイトやメッセージングサービスの認証情報の窃取を狙ったものも増えています。
こういった、そのままでは（サイバー犯罪者が）利益を得にくい認証情報が狙われるようになった理由も、先に述べたダークウェブでの取引によって認証情報を現金化できることや、認証情報を他の攻撃に流用可能だからでしょう。
つまり、フィッシングはそれ自体を目的に行われるだけでなく、認証情報を得るための攻撃の土台として行われる場合もあると考えられます。
（脚注1）
ダークウェブ：インターネットには接続されているものの、アクセスするために特定のツールや認証などが必要な、オーバーレイネットワークに存在しているWebサイト群。
その他のインシデント例
インシデント例として続いて紹介されたのが、マルウェア感染です。2015年10月頃から、マルウェアが添付された日本語のメールが大量にばらまかれました。こういったメールは、2018年8月にいったん止まったものの、10月以降に再開しています。
ほかにも、攻撃されなかったらビットコインを送れ、と要求する脅迫型DDoSや、「Mirai（ミライ）」に代表されるIoTデバイスを利用したDDoS攻撃、設定ミスによるデータベースのダンプファイルの流出、DNSゾーン転送の設定不備に起因する情報流出の危険性などが紹介されました。
もしインシデントが発生してしまったら
自身の組織がサイバー攻撃を受けたとしても、直ちに気づくかといえば、必ずしもそうとは言えません。もちろん、DDoSやWebサイトの改ざんといった、明らかな攻撃ならすぐに気づくでしょう。しかし、情報流出やマルウェアの通信先に利用されているといった被害の多くは、外部からの連絡によって発覚するケースも少なくありません。
また、自組織の名前が攻撃キャンペーンに関するレポートに記載されていた場合や、他の組織が攻撃キャンペーンによる被害を受けたことを発表した際に、実は自組織も同じ攻撃キャンペーンによる被害を受けていたことが発覚する、など調査や取材によって意図せず明らかになってしまう可能性もあります。
ある調査によれば、インシデント発生からそれが発見されるまで、多くの場合3か月近くかかっているそうです。
もし、インシデントが発生してしまった場合、原因究明や復旧など技術的な調査ももちろん必要ですが、それ以上に所管官庁などへの報告、株主や顧客への報告、場合によっては謝罪会見の実施など、外部への対応が求められます。つまり、インシデント対応は、おもに組織外部とのやりとりになる、ということです。
インシデント発生に備えて組織に求められる対応
DDoS攻撃、ランサムウェア、Webサービスからの情報窃取といったサイバー攻撃による被害は、結局のところ事業継続への障害や情報漏えいといった企業が従来から取り組んでいる課題に集約されます。一方で、サイバー攻撃では犯人の特定が非常に難しいこともあって、システム構成や運用に要因を求めがちです。
しかし、システム構成や運用の仕方など、目の前の状況だけにこだわっていては、インシデント対応は進みません。NIST（National Institute of Standards and Technology：米国国立標準技術研究所）が「コンピュータセキュリティインシデント対応ガイド」にて提唱している、準備→検知・分析→封じ込め・根絶・復旧→教訓というプロセスに沿った対応が求められます。
組織におけるインシデント対応を行うために、真鍋氏が訴えたのが「組織内CSIRT」の構築です。組織内CSIRTの果たすべき役割としては、組織内における情報の集約・ハンドリングおよび（必要に応じた）経営上の問題への昇華、インシデント発生時の外部組織との対応窓口などが挙げられます。また、日本シーサート協議会（NCA）など、CSIRTコミュニティへの参加も役立つでしょう。
インシデント対応時の情報の取り扱い
真鍋氏は、インシデント対応時の情報の取り扱いにおいてもっとも重要なこととして「情報をどう出し入れするか」を挙げるとともに、それを実現する手段の1つとして、外部からの情報を受け取る窓口を一本化することを求めました。
また、インシデントが通報された際の対応として、通報された事業部（部署）内だけで対応を行わず、経営課題として情報共有すること、適切なタイミングで情報を公開していくこと、過熱する報道などに翻弄されないことの重要性を指摘しています。
ほかにも、前述したNCAやISAC（Information Sharing and Analysis Center）といった情報共有のための枠組みの活用や、膨大なサイバー攻撃に関する情報を管理するための機械化や自動化も検討してほしいと訴え、セミナーを締めくくりました。