2019年1月10日木曜日

CES2019 その1

長い間、ブログの更新をサボってしまいましたが、今回はラスベガスで開催されている全米最大のエレクトロニクスショー、CESからのレポートです。

【ラスベガス風景】
昨日からラスベガス入りして、今日からショーを見て回ります。今日は、頭の中にインデックスを作るために、ひととおり駆け足で見て回ることにしました。まずは、メイン会場から少し離れた、IoT関連の展示会場へ向かいます。
スマートホーム系のIoTでは、次第に形が定まってきている印象を受けます。機器の制御や通信については、ZWAVEやZigbee3.0といった標準に乗るメーカーがほとんどで、デバイスの選択肢も2年前に比べるとかなり増えた印象を受けます。

【ZWAVEアライアンスのブース】

【つながる機器群】
こうしたデバイスレイヤーの標準の上に、ユーザーインターフェイスとしてのAI,たとえばGoogle Assistant や Amazon Alexaなどを使用して全体をたばねるといった形が定着しつつあります。
一方、家電メーカー系はというと、ちょっと混迷しているかもしれません。冷蔵庫や電子レンジといったものにAIを積んでネットにつなぐ・・・といった流れは2年前のCESでも見られていたのですが、そこから大きく進んだ感じでもなく、また、スマートホームとしての(住居インフラとなるIoT環境との)統一感もいまひとつ見られません。大手家電メーカーは、どうしても囲い込み戦略になりがちなので、そういう意味での停滞感があるのかもしれません。本格的なスマートホームを実現するためには、もっとオープンなインターフェイスが必要になりそうです。

さて、CESのもうひとつの目玉が自動車関連です。こちらは、自動運転が次第に実用化段階に入りつつあり、各社とも力が入っています。AI搭載の自動運転車のプロトタイプやコンセプトモデル展示の一方で、各社ともに、近未来の公共交通システム的なコンセプトでの展示も増えています。これは、自動運転化後に起きるであろう、自動車所有意欲の低下を意識したもののようにも思えます。所有から利用への変化はこの世界でもいずれ起きるのかもしれません。

【ベンツのコンセプトカー】

【乗り合いの自動運転車】

【乗車体験コーナー】
また、AIは自動運転だけでなく、ドライバーや利用者のエクスペリエンス向上のためにも応用されます。利用者の顔などから感情や感覚を読み取り、適切なアシストをしたり、車内の環境をそれにあわせて制御するといった応用は各社とも力を入れているようです。

さて、IoT、家電、車、ヘルスケアなど、いずれの世界でも、AI搭載は普通に行われるようになってきたわけですが、私のようなセキュリティ屋の性分としては、どうしても「大丈夫か?」と思いながら見てしまいます。

気になるのは、AIにかかわらず、現在流行となっている技術の開発において、どこまでセキュリティが意識されているのか、という点です。たしかに、安全という面では、自動車やヘルスケアの分野、電気製品などについては一定の基準があるはずなのですが、それらが「悪意」を前提としたものかと言えば、必ずしもそうではありません。

たとえば、AIにおいては、近年、画像認識を混乱させるような攻撃が話題になっています。昨年11月にブリュッセルで開催されたESCAR EUROPEという自動車関連のセキュリティコンファレンスでは、道路標識を誤認させるような攻撃手法が紹介されていました。しかし、こうした問題への対応は簡単ではありません。現在、AIと呼ばれているものの多くが、人間や動物の五感についての神経系の動きを模倣する「深層学習」という手法を利用しています。これは、知能というより、神経系の学習能力を模したものです。ただ、これは神経系を電子的に再現するのではなく、その動きを数値的にシミュレーションしているため、統計解析などを応用した高度な数学的演算が必要になります。NVIDIAのようなAI用チップメーカーが提供しているのは、ニューラルネットワークを直接実現するチップではなく、こうした数値演算を高速化するための並列処理コンピュータなのです。

【NVIDIAの車載用コンピュータ】
また、こうした演算のプログラミングには様々な統計解析手法や数学的手法に関する知識が必要となります。最近では、GAFAなどを含め、こうした深層学習のプログラミングを簡素化するためのツールキットを無償で提供する動きがあり、それほど高度な知識がなくても深層学習を応用したシステムを作ることができるようになっていますが、そのレベルでは、先に述べたような攻撃に対する対策は困難です。どうしても、深層学習の原理に詳しい専門技術者や研究者に悪意を前提として対応を考えてもらわざるをえません。

IoTなど、ハードウエアに近い分野に関しても似たような状況が存在します。こちらも近年、脆弱性の問題がクローズアップされていますが、結局のところ、開発者が「悪意」を意識できるかどうか、という点に問題は帰結します。

いずれも、我々、いわゆる「セキュリティ専門家」にとってはハードルが高い分野です。こうした分野に個別に足を踏み入れるのもひとつの方法かもしれませんが、おそらくそれならば、セキュリティを離れて、その分野の専門家に転身してしまったほうが早そうです。一方、こうした最新技術のプラットホームとなるコンピュータシステムは、いまだに従来型のものです。AIといえども例外ではなく、こうした部分については、これまでのベストプラクティスが応用できます。つまり、従来型のセキュリティで基盤は守ることができるわけで、専門知識が必要となるのは、その上のアプリケーション部分だけなのです。ついでに言えば、AIで防ぎきれない問題については、従来型の枠組みの中に安全弁を入れる方法もあるでしょう。

逆に、先端技術の技術者や研究者に基盤のセキュリティまで考えてもらうのは荷が重いので、従来型のセキュリティ専門家は依然として必要とされます。問題は、この両者がうまくコラボレーションできるかどうかです。基盤とアプリケーションは相互に密接に関連しますから、全体をひとつのシステムとして考えられないと困ります。こうしたシステム設計の段階で、どうセキュリティを組み込んでいくのか、またアプリケーション開発者に対して、悪意を前提とした課題をきちんと提起していけるかどうかは、むしろ、我々、従来からセキュリティ畑で働く人間の仕事なのかもしれません。

深層学習への攻撃では、そのためにAIを使う手法なども明らかになっています。こうした「敵対的」AIは、対AIだけでなく、今後セキュリティ全般に対する大きな脅威となることは間違いありません。今後、我々セキュリティ専門家が、様々な分野の専門家とうまくコラボレーションしていけるかどうかが、生き残りの鍵といっても過言ではないような気がするのです。

少し脱線気味になってしまいましたが、いつものセキュリティ関連のコンファレンスやショーではなく、こうした最先端技術を見て回ることで、セキュリティ屋としての自分を、その井戸の中から追い出すことは重要だろうと思います。

明日以降、もう少し深く、見て回ろうと思っていますので、また気づいたことなどを書こうと思っています。

2018年5月9日水曜日

Spectre-NG?

Spectreに類似のCPU脆弱性が8個ほど発見されたと報じられています。マイクロコードの修正とOSなどのソフトウエア修正の両方が必要なため、詳細の開示はこれらの準備が整うまで延期されるようですが、リモートコード実行可能な脆弱性が含まれるというのが気になりますね。

https://www.heise.de/ct/artikel/Exclusive-Spectre-NG-Multiple-new-Intel-CPU-flaws-revealed-several-serious-4040648.html

https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/spectre-next-generation-new-intel-cpu-vulnerabilities-found

2018年1月19日金曜日

MeltdownとSpectre

そういえば、いまさらですが、MeltdownとSpectreの話。個人的に調べてFacebookなどに書いていた内容を、ここにも書いておきます。まずは、Meltdownの話。


最近のCPUは、命令の実行を高速化するために、複数の命令を並列実行する機能を持っている。たとえば、ある命令がメモリからのデータ読み込みを必要とするため、待ち時間が生じるような場合、次の命令が前の命令の結果に依存しなければ、それを待ち時間の間に実行するというような処理である。これをアウトオブオーダー実行(順序によらない実行)と言う。最近のプロセッサ命令は、実行過程でよりプリミティブなマイクロコードに分解されるため、こうした前処理は常に先行して行われ、依存関係に直接関わる実行ステージのみが未実行の状態で引き続く命令が待機することになる。これにより、命令列の中の複数の命令が並行して実行されながら、結果を保留した状態で待機していて、先行する命令の完了と同時に結果が反映される。また、こうした命令列の中に分岐(条件分岐)命令が存在した場合は、過去の分岐状況に基づいて予測された分岐結果に基づいて、次にどの命令を先行するか決定して実行する。予測が外れた場合、並行して実行された結果は捨てられ、正しいパスで再度実行される(かえって効率が低下する)ため、こうした方式は投機的実行と呼ばれている。
今回、問題になったのは、並行して実行される命令にOSカーネルのみがアクセス可能なメモリ領域にアクセスするような命令が含まれていた場合、たとえ、プロセス自体に権限がなくても(ユーザプロセスであっても)それが実行されてしまうという点。もちろん、その実行結果が確定された段階では、メモリアクセス例外が発生して処理が中断されるため、直接プログラム側からその値を確認することはできないのだが、実際は、この実行によって、アクセスしたメモリのページがキャッシュに読み込まれるといった副作用が生じる。また、例外発生までに一定のタイムラグが生じるため、先行する命令の結果を受けた後続命令もある程度実行されてしまうため、こうした副作用を、読み込んだデータに依存する形で発生させることができる。この問題は、ソフトウエアへの依存性はなく、こうしたプロセッサのアーキテクチャに存在するため、様々なOSプラットフォームや同種のアーキテクチャを持つCPUで発生する。

あるページがキャッシュされているかどうかは、そのページに対するアクセス速度を調べることで判定ができるが、これを使用してサイドチャネルを作る手法は既にいくつか既知になっている。(たとえば、Flush + Reloadなど)キャッシュを削除しておいて、他のプロセスがどのページを再度キャッシュしたかを調べることができれば、これを悪用してプロセス間でデータ受け渡しが可能になる。(もちろん、そう単純ではないが・・・)
たとえば、先に実行される命令が、カーネルページのアドレスにアクセスして1バイトのデータを取得した後、その値×ページサイズをインデックスにして、後続の命令が実際に実メモリがマッピングされている仮想アドレスにアクセスしたとする。当然、カーネルページへのアクセスでは例外が発生することになるが、この例外発生の前に、カーネルページへのアクセスによるデータが確定して、準備が整ってそれを待っていた後続の命令が実行されてしまう。つまり、ある先頭アドレス+読み出したデータ×ページサイズの位置のページがキャッシュされることになる。もちろん、そのプロセス自身は例外によって読み出したデータを知ることができないが、他のプロセスから、どのページが新たにキャッシュされたかを知ることができれば、読み出したデータの値がわかる。これが、Meltdown攻撃の基本的な原理。サイドチャネル攻撃との組み合わせで効率が悪いように思えるが、それでも平均して500KB/s程度のデータ読み出しが低いエラーレートで可能とのことである。
CPUアーキテクチャの問題であるため、この攻撃を原理的に防ぐ方法は、ハードウエアの改修以外にない。
一方、Linux等のOSでは、ユーザプロセスの仮想メモリ空間に、すべてのカーネルメモリと実メモリがマッピングされている。このことによって、上の攻撃で、最悪の場合、全実メモリの情報やカーネルメモリ内の情報を読み出すことができる。もちろん、それを悪用するためにはカーネルメモリの構造や他のアプリケーションのメモリ構造を知っている必要がある。また、カーネルにおいても、最近ではASLR(KASLR)つまり、アドレス配置のランダム化が行われており、攻撃の難易度は高くなっているが、これも実際のマッピングを推測する手法はいくつか存在する。
Windowsにおいては、Linuxのように全実メモリをプロセス仮想空間にマップするようなことは行っていないが、依然として重要な情報を持つカーネルページがマップされているため、Meltdown攻撃が機能する可能性が高い。
Linuxにおいては、最新の改修で KAISER(KPTI)と呼ばれるパッチが導入された。これにより、当面、全実空間やカーネルページの大部分にアクセスできなくなるが、依然として一部のカーネルページにはアクセス可能である。ただ、KASLRを介してマッピングがランダム化されていることもあって、攻撃難度はかなり上がることになる。当面は、これ(KAISER)が最良の対策となる。ただ、こうしたページに含まれるカーネル空間のポインター値からKASLRのマッピングを推測できる可能性はあり、最終的にはこうしたポインターのすべてをユーザ側からアクセスできなくする必要があるとのこと。
WindowsやMacOS X, iOSにおいても同様のパッチが既に提供されている。思うに、この攻撃自体の難易度は高いものの、影響範囲が様々なOSプラットフォームやハードウエアを越えて非常に広いことから、有効な攻撃コードが出回る可能性も否定できない。仮想環境やコンテナ環境などにおいても、隔離環境からホストOSや他のインスタンスの情報にアクセスできるなど広く影響を与えることから、とりわけクラウドサービス環境における対応は急務と言えるだろう。

次に、Spectreの話。

Spectre攻撃は、Meltdown同様にキャッシュへの副作用を利用してサイドチャネルから情報を得る方法だが、カーネルメモリや仮想空間にマップされた実メモリページではなく、特定のプロセスの仮想空間内のデータを狙う手法である。従って、Meltdown対策としてのKAISERは有効ではない。攻撃対象となるのは、CPUが持っている分岐予測実行(投機的実行)機能。

分岐予測と分岐先予測

Meltdownの時に書いたように、最近のCPUは、ある命令の待ち時間の間に後続命令の実行準備や先行命令に依存しない命令を実行して結果を保留する、アウトオブオーダー実行の機能を持っているが、これを含めて命令コードを先読みするパイプライン機能は分岐命令によって乱されるため、分岐の多い処理ではパフォーマンスが低下する。これをカバーするために付加されたのが分岐予測の技術である。最近のCPUでは、よく使用される条件分岐命令の仮想アドレスと、その最近の分岐の履歴をテーブルとして保持していて、この情報に基づいて次に先読みすべきコードを決定している。また、間接ジャンプやリターン命令といったダイナミックに飛び先が変わる命令については、よく使用される分岐先アドレスを保持していて、これを用いて分岐先を予測し先読みを行う。分岐予測の結果を高速に利用するため、各命令の仮想アドレスは下位30ビット程度をハッシュテーブル化して保持され(BTB:Branch Target Bufferと呼ばれる)、実行時は分岐命令がデコードされているかどうかにかかわらず、先読みのために使用される。このアドレスは仮想アドレスであるため、たとえば、異なるプロセスであっても、同じ場所に分岐命令があれば(ASLRなどのため、共有ライブラリであってもこの可能性は極めて低いが)同一のものとして扱われる。

分岐予測については、外部からその分岐をコントロールできれば、あらかじめ分岐有無を学習させることが可能である。また、分岐先予測については、対象となる命令の仮想アドレス下位30ビットが等しくなる位置に同じ命令がある攻撃用プロセスを準備できれば、他のプロセスから分岐先予測を攪乱することも可能である。(論文では20ビット程度でもよかったと書かれている)

基本的な攻撃の原理

分岐を伴うコードで、予測結果によって先読みされる部分に、外部から与えたデータで任意の仮想アドレスを参照するような命令を持つ部分を探し、この分岐命令についてそのコードを先読み実行するように学習させた上で、参照したいメモリアドレスを与えて、予測を失敗させる。これにより、もし参照したメモリブロックがキャッシュされていなければキャッシュ要求が発生し、キャッシュされる。あらかじめキャッシュを削除してからサイドチャネルでキャッシュされた場所を調べる手法は、Meltdownと同様。

分岐先予測を使った攻撃ではもう少し自由度が上がる。メモリ参照を行うコードは分岐命令とは全く違う場所にあってもよい。この場合は、攻撃プロセスを使って、分岐先予測を攪乱し、メモリ参照を行うコードのアドレスをBTBに押し込んでしまえばいい。これは、バッファオーバフロー攻撃時のROP(Return Oriented Programing)と類似の手法である。もちろん、実行結果は最終的に破棄されることになるが、キャッシュは残る。

以下、具体的な攻撃コンセプトの例。

A) 条件分岐を攻撃する方法(分岐予測への攻撃)例

1) 標的とするプロセスのプログラム内で、外部から与えられる値によって分岐条件が変わり、投機的実行によって、その値に依存する位置のメモリブロックをキャッシュする副作用を発生するようなコードを見つける・・たとえば、指標値による二重のテーブルルックアップ

if (x < size_a1)
  y = a2[a1[x] * 256];

のようなコード。これは機械命令に落ちる際に if 条件を満たさなければ分岐するようなコードになるが、この分岐予測が「分岐しない」となる場合は、xによってa1 + xのメモリにある値が参照され、それに対して256(キャッシュブロックのサイズの倍数の値)を掛けた値だけa2に加えた位置へのアクセス要求が発生し、そのブロックがキャッシュされる。

2) この分岐に対して、いくつか正常な(size_a1より小さな)値を与えて学習させた後に、xに不正な(size_a1より大きな)値を与えると、分岐予測によって、不正なxを用いた計算が先行して(投機的に)行われる。たとえば、事前にキャッシュをあふれさせたりフラッシュしてしまうことで、条件評価の際にsize_a1をメモリから取得しなければいけないなどの時間がかかるようにしておく必要がある。これにより、a2 + (a1 + x) * 256 の位置のブロックがキャッシュされる。

3) サイドチャネルを使って、新たにキャッシュされたブロックのアドレスを調べると、a1 + xにある値が推定できるので、この作業をxを変えながら行うことで、標的プロセスの仮想メモリ空間内にある値を読み出すことが可能になる。

B) 間接分岐やリターン命令を攻撃する方法(分岐先予測への攻撃)例

1) 標的プロセス内で、2つのレジスタ(R1, R2)に外部から操作可能な値を持った状態で実行される間接分岐(メモリ間接のジャンプ)命令やリターン命令などを見つける。

2) 同じく標的プロセスのコードや使われている共有ライブラリ(DLL, SOなど)内で、まず、R1をオフセットとしてメモリをDWORD参照し、その値をR2に加える(32bit演算)ようなコードと、その次にR2を使ってメモリを間接参照するなんらかの命令を持つ部分を見つける。たとえば、以下のような例(実際のWindowsのコードの一部)が書かれている。ここで、EDIとEBXが外部から制御可能。edxの値は既知である前提。

adc edi,dword ptr [ebx+edx+13BE13BDh]
adc dl,byte ptr [edi]

3) 1)の間接分岐もしくはリターン命令について分岐先予測ロジックを攻撃し、2) のコードを分岐先と予測するように学習させる。

4) R1を参照したいアドレス(CPUによってバイトオーダーを考える必要あり)にし、R2をメモリ参照によってアクセスされるアドレスの先頭に設定するような値を標的プロセスに外部から与えて 1)のコードを実行させる。これにより、間接分岐やリターン命令がメモリアクセスを待っている間に分岐先予測によって2)が投機的に実行され R2 + [R1]<<24 + [R1+1]<<16 + [R1+2] << 8 + [R1+3} の位置のメモリ(バイトオーダーに注意)がキャッシュされる。

5) サイドチャネルを使用して新たにキャッシュされたブロックのアドレスを調べることで、4)のアドレスがわかる。A)ほど単純ではないが、こうした手法をR1の値を変えながら繰り返せば(メモリアクセスバウンダリーの問題は考慮が必要だが)標的プロセスの任意のメモリの値を取得する事は原理的には可能である。

C) JavaScriptを使用したブラウザ攻撃の可能性

JavaScript実装の多くが、JIT(実行時コンパイル)を行っているため、分岐命令やそれに伴った予測実行コードを意図的に生成することができると考えられる。サイドチャネルを作るためのキャッシュの破棄やキャッシュされたかどうかの判断は、巨大な配列を使用することで間接的に可能になる可能性がある。これによって、ブラウザに実装されているサンドボックス機能等のプロテクションが回避される可能性がある。

とりあえず、参考までに・・・・

活動サマリーなど

皆様、あけましておめでとうございます。

長い間、ブログの更新をサボってしまったので、その間あったトピックスをいくつか紹介しておきます。

7月 Interpol World コンファレンス(シンガポール)参加
   CSAジャパン(日本クラウドセキュリティアライアンス)IoTセキュリティセミナ
   DEFCON 23 (ラスベガス)参加
9月 (ISC)2 World Congress (オースティン)参加
   JAPAN IDENTITY & CLOUD SUMMITにて講演

CSAジャパン IoT WGでは、8月にIoTへのサイバー攻撃仮想ストーリー集(第一版)を発行しましたが、この編集にもリーダーとして係わっています。終盤は、個別の業務多忙のため、あまり公的な活動に参加できていませんが、今年はまた積極的に参加していきたいと考えています。

2017年5月29日月曜日

「つながる世界」を破綻させないためのセキュアなIoT製品開発 13のステップ 公開(CSAジャパン)

一般社団法人日本クラウドセキュリティアライアンス(CSAジャパン)から、CSA IoT ワーキンググループの "Future-proofing The Connected World: 13 Steps to Develop Secure IoT Products" の日本語翻訳版が公開されました。

「つながる世界」を破綻させないためのセキュアなIoT製品開発 13のステップ

この翻訳版は、私も参加している CSAジャパン  IoT WG のメンバー中心に半年以上をかけて翻訳・レビューしたものです。

IoT関連記事を寄稿しました

株式会社イプロス様のサイト Tech Note にIoTセキュリティの基礎知識を連載開始しました。

https://www.ipros.jp/technote/basic-iot-security1/

8回にわたって、IoT製品・サービス提供時に留意が必要な事項などを解説する予定です。

2017年3月1日水曜日

明るい未来か混沌か・・・

しばらくブログもサボってしまいました。ホームページに至っては、1年放置という状況。とりあえず、本業が忙しかった・・・・ということにしておいてください。

今年参加した二つの大きなイベントで、なんとなく対照的な未来像を見ました。ひとつは1月に毎年ラスベガスで行われる世界最大規模の家電ショーであるCES、もう一つは2月にサンフランシスコで開かれた、これも毎年恒例のRSAコンファレンスです。


前者は、コンシューマ向けの電子製品や最新テクノロジーが満載、自動運転車からテレビ、スマート家電、3Dプリンター、そしてゲーム機まで、様々な製品やコンセプト展示が、ところ狭しと並びます。
2年前にも一度行ったのですが、そのときは、ほとんどがコンセプト展示だった自動運転車は、既に各社とも、実際に走る実験車を展示しており、コンセプトカーの多くは、さらにAI搭載と、明らかに大きく進んでいます。
家電系は、大画面の有機EL(LED)4K/8Kスマートテレビを筆頭に、いわゆる「繋がる家電」が目白押し。3Dプリンターはさらに高機能化と低価格化し、様々な素材を使って造形ができるようになっています。ゲーム機はVR(仮想現実)ゲームが主流。体験コーナーでは、VR+体感型の絶叫系ゲームに長蛇の列ができるなど、こちらも人気を集めたいました。
VR、AR(拡張現実)は様々な用途で実用化されつつあります。特に、ARは、日常の仕事や生活のアシストに不可欠のものになっていくと思われ、透過型グラスのディスプレイ、自動車用のHUD(ヘッドアップディスプレイ)などが、多く展示されていました。

ロボットは、こちらも進化していて、クラウドのAIと連携した様々な接客や介護、見守り用のロボットが展示されていました。
ちょっと気になることといえば、自動車以外の分野で日本企業の存在感が希薄に感じられたことです。各社とも、そこそこの規模で展示はしているものの、内容はかなり絞り込んだ印象を受けました。一方で、存在感を年々増しているのが韓国や中国の企業です。大手企業のブースは総合的な展示で、かつての日本メーカーを彷彿とさせます。まさに、Before/Afterな感じです。また、各国とも、国が支援した形で、自国の企業を集めた展示コーナーを作っていて、様々な新興企業が展示をしていました。日本からはJETROが、同じようなブースを構えていましたが、ちょっと存在感に欠ける印象でした。
さておき、CESでは、未来はこんなに素晴らしい・・・といった印象が大きく、かつて少年時代に夢見た未来像がどんどん実際のものになっていくという「わくわく感」があります。それが、CESを見に行きたいという最も大きな理由なのです。もちろん、こうした技術の爆発的進歩や拡大に対して危惧がないわけではありませんが、それらをどうにか解決して「手に入れたい未来」がそこにあるのです。

◇

 一方、今回参加した(この原稿はサンフランシスコで書いているのですが)RSAコンファレンスは、冒頭から「混沌」に包まれていました。
初日に行われた、一連のキーノートで受けた印象は、まさに「混沌」です。端的にまとめれば、「技術の爆発的な進化が混沌を生み、様々な想定外を含むセキュリティ問題が発生するだろう」という予言です。
そして、一連のキーノートから得た「結論」は、「これから来る困難な時代に、我々は協力して臨まなければならない」というものでした。つまり、「何が起きるか予想もできないから、とにかくみんなでかんばろう」という、ちょっと精神論めいたイメージです。
そこまで暗いイメージを作り上げるのは、やりすぎだろう・・・と感じたのですが、FUDじゃないか、という前に、我々の業界の現状をもう一度考えてみる必要があるのかもしれません。実際、CESで見た技術の爆発は非常に印象的です。各分野の技術を引っ張っているのは、いずれも世界トップレベルの研究者や技術者です。さらに、これからAIがそうした進歩を後押しする時代になれば、進歩はさらに加速するでしょう。いわゆる「シンギュラリティー」(技術的特異点)は、2045年よりも、ずっと早く訪れるかもしれません。そんな技術の進歩の最先端に対し、セキュリティの「専門家」は何ができるのでしょうか。
自ら手を下すにはハイレベル過ぎる領域です。基本は述べられても、実際の実装や現場での対応は多くの「セキュリティ専門家」には非常に困難な仕事になるでしょう。まして、我々が相手にするのは、そうした最先端技術を「使う」側の人たちです。我々同様、彼らもそうした技術の中身や本質を理解することは困難です。そういう意味では、「セキュリティ屋」さんたちが暗くなってしまうのは当然なのかもしれません。一方、攻撃者は、少数精鋭で、その分野を極めてくるはずです。そうなれば、核ミサイルを木の盾で防ごうとするようなもので、まったくもって歯が立たないでしょう。もちろん、迎撃ミサイルを作ることは可能です。しかし、そのためには、攻撃側と同じレベルの(狭い分野での)高度な技術知識が必要です。しかし、人材の面から言えば、そうした「専門家」の大量育成は不可能です。(CTFなどで育成できるレベルの人材ではありません)一方で、守るべき前線は広大で、どれだけ人がいても足りません。つまり、こうした非対称性の拡大が、これから起きようとしている(と彼らが言っている)「混沌」の本質なのかもしれません。つまり、今回のRSAコンファレンスで感じた「混沌」は、すなわち「セキュリティ業界」の行き詰まり感なのだろうと思うのです。

◇

さて、こうした両極端を目にしたわけですが、どちらが・・・という議論は、おそらく不毛でしょう。なぜならば、どちらも現実だからです。そして、我々が欲しいのは「明るい未来」です。ならば、どうすれば「混沌」を解消して、明るい未来を手に入れられるのでしょうか。少なくとも我々は、「不都合な現実」をたくさん知っています。でも、いまやそれらの多くは我々には(少なくとも技術的には)どうしようもありません。そろそろ、我々は「セキュリティ業界」という枠を崩して、ITという大海原に散らばっていく必要があるのかもしれません。そうして、様々な分野の技術者や専門家と協力して、それぞれの分野におけるセキュリティの底上げを「内部から」していく必要があるのだろうと思うのです。今回、RSAコンファレンスに参加して、こうした思いを強くした次第です。