Trustwaveの報告書をインシデント対応の視点から読む　ほか

伊Hacking Team社からの情報漏えいで明らかになった脆弱性情報の売買の実態

　日本では6月の年金機構からの個人情報漏えい事件をきっかけに、さまざまな企業や組織で発生した（または発生していた）情報漏えいが次々と明らかになり、「ウチも漏らしちゃいました祭」の状態が続いていますが、国際的には7月上旬に明らかになったイタリアのセキュリティ企業「Hacking Team」から大量の内部資料が流出した事件が大きな騒動を巻き起こしています。

　Hacking Teamは世界各国の政府や法執行機関に対して監視ソフトウェアを販売していたことから、かねてより「国境なき記者団」から「インターネットの敵」として指摘されていた企業であり、今回流出した資料によって、国防総省やFBIなどの米国機関をはじめ、ロシアやサウジアラビア、アラブ首長国連邦、エジプト、韓国など、さまざまな国が顧客であることが明らかになったのです。また、監視ソフトウェアをターゲットのPCに「感染」させるために使用していたとされる未公開の脆弱性に関する情報も明らかになり、対象ソフトウェアのベンダーから修正プログラムが相次いで公開される一方、Flash Playerの脆弱性については日本でも実際に攻撃に悪用されていたことが確認されています。

　今回流出した内部資料には、Hacking Teamが未公開の脆弱性情報をどのような経緯で入手していたかを示す情報も含まれていました。自社製品の脆弱性情報を報告した人物に「報奨金」を支払うケースでは、その経緯や金額などが明らかにされることは珍しくありませんが、Hacking Teamのような第三者の企業が「密かに」脆弱性情報を買い取るケースについては当然ながら詳細が明らかにされることはありません。今回流出したHacking Teamの内部資料は、未公開の脆弱性情報の売買に関して公になった初めての資料と言えるでしょう。

　このような中、リバースエンジニアとして知られるVlad Tsyrklevich氏は、流出した資料をもとに、未公開の脆弱性情報の売買について、攻撃ツールの開発者や脆弱性情報のブローカーなど、Hacking Teamと取引のある個人や企業ごとにまとめた形で自身のブログで紹介しています。

　注目すべきはロシアの攻撃ツール開発者Vitaliy Toropovという人物。彼は2013年10月以降、Flash Player、Safari、Silverlightの脆弱性情報を売っており、中には無料のものもあったようですが、それぞれ3万9000ドルから4万5000ドルを受け取っていたようです。

　また、クラッキングコンテストとして有名な「Pwn2Own」での活躍で知られるセキュリティ企業VUPENも、Hacking Teamに脆弱性情報を売っていたことが明らかになっています。しかし、VUPENとHacking Teamの関係は当初から良好なものではなかったようです。

　さらに、2012年に未公開の脆弱性情報を契約している顧客にのみ有償で提供するサービスを堂々と行なっているとして物議をかもしたセキュリティ企業ReVulnとも関係があったようですが、ReVulnがサーバー側の脆弱性に主眼を置いていることからビジネスの方針が合わず、取引はなかったようです。

　Hacking Teamのやってきたことは決して褒められたものではありません。批判を受けても当然でしょう。しかし、たとえHacking Teamという会社自体がなくなったとしても、この手のビジネスがなくなることはないでしょうし、政府機関などからの需要がある以上、ビジネスとしては存続し続けて行くのでしょう。我々はこのようなビジネスが存在することも念頭に置き、その上でどのような対応をすべきかを考えなくてはなりません。それは即ち「100％完全に防ぐことができない以上、インシデントが起きることを前提にした仕組みや対応体制が重要なのである」という昔から言われている「当たり前のこと」を改めて肝に銘じる必要があるのです。

Trustwaveの報告書をインシデント対応の視点から読む

　前回の連載記事で紹介した「2015 Trustwave Global Security Report」のうち、今回は「インシデント対応」に関連するデータを紹介するとともに、一般的に注意および検討すべきポイントを解説します。

かねてよりさまざまなセキュリティ関連企業や組織などが公開したレポートにおいて、情報漏えいのインシデントは、自ら検知するよりも、外部からの通報によって気付くことが多いとの調査結果が示されています。Trustwaveによるレポートでも、自ら検知できたのは19％で、81％が外部からの通報によるものであるとの結果が掲載されていますが、その内訳をさらに詳細に調べた結果が以下の図です。

　2013年に比べて自ら検知できた割合が減っている代わりに、法執行機関からの連絡で気付くケースが増えています。また、全体から見れば少数ですが、外部の第三者機関や顧客からの通報もあります。

　このようなケースに備え、企業や組織の公式ウェブサイトにインシデントに関する通報受付窓口の情報を掲載することも検討すべきでしょう。このような窓口を用意するにあたっては、当然ながら、スパム送信先やいたずらなどに悪用されてしまう危険性があることを考慮し、窓口に寄せられる情報のすべてを受け取った上で、その中からインシデントに関する情報を安全に抽出する仕組みと体制が必要となります。また、そのような専用の窓口を用意しない場合でも、代表電話をはじめとする公開されている電話番号、FAX番号、メールアドレス（WhoisデータベースやDNSのSOAレコードなどに登録されているものなど）に届け出られる可能性も考慮し、インシデントに関する情報については速やかにCSIRT（シーサート：Computer Security Incident Response Team）などのセキュリティ担当に伝達できる連絡体制の整備と、それが機能するかを演習などを通じて定期的に確認することも必要でしょう。

　次に、侵入を許してしまってから検知や封じ込めまでの日数を調べた結果について紹介します。まず、検知までにかかる日数の平均値を過去と比較したのが以下の図です。

　平均値で見ると、2014年では約半年かかっていることが分かります。しかし、一方でTrustwaveはこのような「平均値」よりも「中央値（median）」に着目しています。その理由としては、Trustwaveが調査した案件で検知までにかかった日数は、1日のケースから1655日（約4年半）までと、あまりに範囲が広すぎるので、平均値にしてしまうと現実の「典型例」が見えなくなってしまうからとしています。事実、2014年の平均値では188日（約半年）でしたが、中央値では86日（3カ月弱）となっていて大きな開きがあります。このような考えの下、中央値で封じ込めまでの日数、検知までの日数、検知から封じ込めまでの日数をまとめたのが以下の図です。

　ここで「侵入から封じ込めまでの日数」から「侵入から検知までの日数」を引いても「検知から封じ込めまでの日数」にならないことに注意が必要です。実は、検知した時点ですでに犯行は終わっていて事実上「封じ込め」られた状態になっているケースもあるのです。このように検知の前に封じ込めが終わっている日数をマイナスで表現すると、検知から封じ込めまでにかかる日数には、－34日から174日まであり、その中央値が7日となったわけです。なお、検知の前に封じ込めが終わっているケースは全体の15％だったそうです。

　続けて、自ら検知した場合と外部からの通報で認知した場合を比較した結果を紹介します。まず、検知／認知にかかった日数の中央値を示したのが以下の図です。

　外部からの通報の場合は1日から1655日で中央値が126日、自ら検知した場合は1日から148日で中央値が10日となっています。

　検知から封じ込めまでにかかった日数の中央値を示したのが以下の図です。

　侵入から封じ込めまでにかかった日数の中央値を示したのが以下の図です。

　外部からの通報の場合は1日から1692日で中央値が154日、自ら検知した場合は1日から132日で中央値が14.5日となっています。

　外部からの通報の場合、その通報内容の真偽の確認や問題箇所の特定など、自ら検知した場合に比べて時間を要する部分があるのは仕方のないことではあります。また、そもそもインシデント対応能力が不十分なために自ら検知ができず、それゆえ、外部からの通報を受けても対応に時間がかかってしまったというケースもあるでしょう。

　それでも、外部からの通報の場合は、一般的に侵入されてからすでに長い時間が経過していると考えられることから、より速やかな対応が求められます。改めて、外部からの通報を受けた場合の体制に無駄や冗長な部分がないかどうか、再確認する必要があるでしょう。