2014年8月14日木曜日

【講演予定】ID&IT Management Conference 2014

ID&IT Management Conference 2014 で以下のようなタイトルの講演を行う予定です。


Internet of *
「IoTとビッグデータが招くアイデンティティーの多様化」


なんとなくバズワードと化しつつある「ビッグデータ」。Internet of Things (IoT) も同じ道をたどるのでしょうか。こうした「言葉」の流行の陰に、いつしかその本質が覆い隠されてしまうのはよくあること。デバイスのクラウドと言ってもいい IoT がビッグデータと結びつく時、何が起きるのか。デバイスやデータの集合がアイデンティティーを獲得する。そして、それが人間とも不可分になっていく。そんな社会について考えてみます。

大阪: 2014年9月17日(水) 9:30〜17:40(9:00〜受付開始)ANAクラウンプラザホテル大阪
東京: 2014年9月19日(金) 9:30〜17:40(9:00〜受付開始)ANAインターコンチネンタルホテル東京


ご興味があれば、是非、ご来場ください。

なにか起きてから慌てても遅いインシデント対応

先日も、通信教育会社大手の個人情報漏洩が大きな話題になりました。こうした事故が起きるたびに思うことがあります。たとえば、様々なメディアから一斉にニュースが流れ、事実と憶測がまざった情報やらコメントが巷にあふれたあと、当事者側から、あたりさわりのない、もしくは、場合によっては問題を(結果的に)過小評価したようなコメントが出される・・・。謝罪会見が行われ、そこでは「想定外」が強調され、再発防止への努力が約束される・・・・。

これまで、多くの企業がこうした事故を起こし、同じような対応をしています。しかし、事故がなくならないばかりでなく、事故後の対応も、私などから見れば、まったくといっていいほど進歩がみられません。

その原因はひとつです。企業が、こうした事故が起きるという前提に立ってものごとを考えられていないからです。

面白い話があります。ずっと以前から、専門家の間では、情報セキュリティ事故の際の対応訓練といったものの必要性が言われてきました。ある時、とある企業の情報セキュリティ責任者が、経営者にこうした訓練を提案したそうです。そのときの経営者が言ったとされる言葉が、日本企業の現状を物語っているのです。「なぜ、そんなことをしないといけないんだ。そういうことが起きないようにするために、君に給料を払っているんだぞ」・・・と。

たしかに、事故は起きてはいけないことです。そのための予防手段を考えることは重要です。しかし、そこに人がからむ以上、ミスや故意、想定不全による事故は必ずと言っていいほど発生します。予防対策がしっかりしていればいるほど、何か起きた時は重大なものになりがちです。予防対策で、些末な、もしくはある程度の事故が発生する頻度は大きく下がります。しかし、とりわけ、故意や対策が想定していなかった原因による事故が相対的に大きな比率を占めるようになるわけです。それを考えれば、どれだけしっかりした対策を考えていても、事故の可能性は捨てられません。まして、一旦発生してしまえば、ビジネスをゆるがす問題に発展しかねないわけですから、発生した場合、どうして影響を最小限に押さえ込むかが重要になってきます。

海外のセキュリティコンファレンスに行くと、必ずと言っていいほど、リスク管理のトラックに、こうしたインシデント対応を考えるセッションがあります。先日、シンガポールで開催されたRSA ASIA PACIFICコンファレンスでも、「情報漏洩事故を起こした後、いかにして信頼を回復するか」と銘打ったセッションがありました。こうしたセッションでは、共通していくつかの「原則」が語られます。

・コミュニケーションの原則

被害者がいる場合、その人たちへの連絡とケアを最優先すべきである。事態が公になる前に、被害者との間でコミュニケーションが必要な場合(そうしないと、被害者にさらなる被害や苦痛を与えるような場合などがあるので、公表タイミングは慎重に行うこと。

会社として、広報を交えたかたちで、迅速に体制を立ち上げ、正確な情報をこまめに発表すること。(最初の会見で、責任を回避するような言動や、被害を過小評価するような言動を行うと、信頼の維持が難しくなるので、事実を事実として伝え、わからないことは、はっきりそう言ったうえで、タイムリーにアップデートしていくこと)

コンプライアンス上、当局への報告などが必要な場合は、迅速に実施すること。また、捜査機関等の関与が必要な場合は、早い段階で連携を開始すること。


・延焼防止とビジネスの維持

問題がわかっている場合、ただちに問題箇所に対して応急処置を行うこと。但し、その処置によって、原因究明や証拠収集に影響が出るような操作は回避すること。

同種の問題が他で生じないかどうかを迅速に確認すること。また、そうした可能性のある部分に対して応急措置を講じること。

その上で、業務やサービスの変更、停止が必要な部分について、優先度の高い部分から対応していくこと。やむなく業務、サービスを継続せざるを得ないという経営判断はありうるが、その場合、新たな問題が生じないか厳重に監視、管理を行いつつ継続すること。



このほかにも様々な原則が語られますが、こうした原則の多くは、事前の準備がないと実行できません。シナリオに基づいて、体制や対応方法を十分検討し、関係部署や関係者に周知しておく必要があるのです。そのためには、こうした事故がありうるという前提に立つ必要があるのです。

企業の情報セキュリティ責任者の仕事は、第一義的には、こうしたインシデント発生を未然に防ぐことにあるわけですが、本当に手腕が試されるのは、こうしたインシデントが発生してしまった時です。いかに迅速に対処し、様々な被害を最小限にとどめられるかが問われます。そういう意味では、日本企業の情報セキュリティ担当者は、まだその仕事の半分しかこなせていないのかもしれません。

競争が激化するビジネスにおいて、勝ち残っていくためには、どんどん新しいことにチャレンジしていくことが必要です。たとえば、市場を広げるためには、これまで避けていた、リスクの高い取引を行う必要も生じます。このような場合、ビジネスの世界では、たとえば、貸し倒れやキャンセルなどの発生を想定しつつ、それがビジネス全体を脅かさない方策を考えます。それがビジネスを成功に導くリスクマネジメントなのです。そして、これは、情報セキュリティやITの世界でもまったく同じです。リスクを抑えながら、どのようにして新しい技術を取り込んでいくか、それがこれからのITに求められることであるならば、様々なインシデントの発生を前提とした取り組みが必須だと言えるのではないでしょうか。

【記事】セキュリティにもストラテジストが必要

エンタープライズ・ジン IT Initiatve に対談記事が掲載されました。

セキュリティにもストラテジストが必要


日本HPの藤田さんとの対談形式の記事です。クラウドのセキュリティを考える上で、とりわけ日本のクラウドユーザがかかえる課題についてお話ししました。

【記事】IoTとビッグデータの組み合わせは劇薬かもしれない

エンタープライズ・ジン IT Initiative にインタビュー記事が掲載されました。

「IoTとビッグデータの組み合わせは劇薬かもしれない」

IoT (Internet of Things)は、様々な機器をネットワーク化することにより統合管理しようという流れなのですが、実は、こうしたネットワークはビッグデータ収集のためのセンサー端末としても働きます。事業者にとっては近い将来、機器管理の効率化よりも、収集されたデータの方が大きな価値を産むという可能性が高いのです。そのような視点からIoTを見た時、単にデバイスネットワーク以上の課題が浮き上がってきます。このインタビュー記事ではそうした視点からIoTとビッグデータがもたらす、セキュリティ上の課題についてお話ししています。

【寄稿】ITLeaders続編

第7回 クラウドにおけるインシデント対応(後編)

第8回 クラウドアプリケーションのためのセキュリティアーキテクチャ確立を


が公開されました。いずれも、前回同様、CSAクラウドセキュリティガイダンスに基づく解説記事です。

2014年6月29日日曜日

【寄稿】クラウドにおけるインシデントレスポンス

CSAジャパン(一般社団法人日本クラウドセキュリティアライアンス)の有志メンバーでインプレスビジネスメディアさんの IT Leaders に連載中の記事です。CSAガイダンスをベースにして、その各ドメインでのポイントを解説しています。

今回、私はインシデントレスポンスに関する部分を担当しました。第6回と第7回の2回にわけて掲載されます。

【第6回】クラウド利用におけるセキュリティインシデント対応(前編)

読まれたご意見などいただければ幸いです。

2014年5月9日金曜日

昨今の話題まとめとか

この連休は、ちょっと長めのお休みをいただき、リフレッシュしてきました。ちょっとエネルギーをもらったので、また仕事に励もうと思っています。

ところで、このところ、様々な脆弱性問題などが発生しています。このあたりをまとめた記事をJNSA(NPO日本ネットワークセキュリティ協会)のホームページに寄稿しましたので、お読みいただければと思います。

執筆中、さらに IEゼロデイ問題やApache Strutsの問題などが騒ぎになりましたが、これらはこの記事では対応できていません。

IEゼロデイ脆弱性は、発見される前に有効な攻撃コードが流通してしまったため、米国DHS(国家安全保障省が警告を出す事態に陥りました。XPサポート切れ直後にゼロデイ脆弱性が使われることは、ある程度予想されていたため、やはり・・と行った感じです。今回、マイクロソフトがXPも含めて対応をしてくれたのは、有り難かったと思います。

この脆弱性は、use after free と呼ばれるタイプの脆弱性で、プログラム内で一時的なデータ領域を確保するためのヒープ領域の取り扱いに問題が生じたものです。この脆弱性は、使用後、解放されたヒープ領域のデータを再利用できる手段を提供します。攻撃コードでは、最初にAdobe Flash Playerのオブジェクトを実行させ、その機能を使ってヒープ領域に大きなメモリを確保した上で、攻撃に必要な情報を埋め込み、領域を解放します。その後、Java Scriptで、IEの脆弱性を悪用し、あらかじめ書き込んであった情報を使って、攻撃コードを実行させます。この方法により、マイクロソフトが組み込んでいるASLR(攻撃コードによって、既存のライブラリコードが悪用されるのを防ぐため、プロセスごとにメモリ配置をランダマイズする対策)やDEP(データ領域でのコード実行禁止)などが回避できてしまうことになり、攻撃者が悪意あるコードを実行できてしまいます。

この攻撃コードを使って攻撃を仕掛けるには、まず、利用者を不正な(もしくは改ざんされた)Webサイトに誘導してFlashオブジェクトやJava Scriptを実行させることが必要です。このことから、いわゆる水飲み場攻撃を目的として作られた攻撃コードであるとも言え、特定の企業や政府機関などが標的にされた可能性があります。これが、DHSがまっさきに警告を出した理由でしょう。

このコードでは、Flash実行を禁止することで被害は防げますが、それ以外にも悪用する方法はあると考えられるので、早めに修正プログラムを適用することが重要です。今回は幸いにもXP対応が行われましたが、今後、これが保証されるものではないので、XPについては、できうる限り早くOSを更新しておく必要があります。

Apache Struts は、Webアプリケーションを開発するためのJavaベースのオープンソースフレームワークです。TomcatなどのJavaアプリケーションサーバの上で動作し、Webアプリケーションを開発するための様々な機能を提供します。このため、多くのWebサイトでアプリケーション構築に際して利用されています。

今回の脆弱性については、当初、Strutsの現バージョンであるStruts2の脆弱性として公表され、開発元のApache Foundation によって修正パッチが配布されました。この脆弱性は、外部から不正に加工されたリクエストを送ると ClassLoaderと呼ばれるJavaランタイムの機能を掌握することができ、攻撃者が任意のJavaコードを実行できるというものです。これによって実行されるJavaコードはWebサーバ(アプリケーションサーバ)の実行権限で実行されるため、制限はありますが、サーバの構成によっては重要なデータが漏洩したり、Webが改ざんされるといった可能性があります。また、これらがシステム権限で動作していた場合(通常、これは絶対行ってはいけないこととされていますが、アプリケーションの構造を簡単にするため、安易に行われるケースが後を絶ちません)サーバ自体を乗っ取られてしまう危険もあります。

修正配布で一件落着したかに見えたのですが、後日、この修正が不十分だったことが発覚します。さらに、同様の脆弱性が既にサポート切れとなっているStruts1という古いバージョンにも存在することが確認されたため、大騒ぎとなりました。Struts2の再修正は行われましたが、Struts1についてはサポート切れから相当期間経過しているため、修正は行われません。一方、国内では、まだStruts1で動作しているWebサイトが相当数有り、これらをどうするかが大問題となっています。Java環境はそのバージョンへの依存が強いため、どうしても開発者やサイト運用者はバージョンアップを嫌う傾向にあります。しかし、一旦サポートが切れてしまうと、こうしたリスクに曝されることになりますから、早め早めで対応していくという考え方に切り替える必要があるでしょう。これは、SIerだけではなく、コストを負担するユーザ側の認識も必要です。このような対応は必要なコストとして将来的なロードマップに乗せておく必要があるのです。今回、一部のSierが独自に修正コードを提供しはじめていますが、これが出来るSIerはそれほど多くありません。オープンソースのソフトウエアを使うということは、こうしたこと(自己責任でに利用)を頭に置いておく必要があります。

とりあえず、簡単にまとめてみました。ご参考まで。