イベント後の考察：S4 ICS検知チャレンジ
ICS（産業制御システム）の脅威検知ソリューションや資産インベントリ管理ソリューションを提供する企業は20社以上あり、各社それぞれ、自社の製品が業界最高性能を誇ると謳っている。その中からどれか1社を選ぶとしたら、どうしたら良いだろうか。ICS検知チャレンジを始めたのは、何らかのソリューションを導入予定の資産保有者や顧客に、公平な視点で製品を比較した技術的指標を提供したかったからだ。
S4x19 ICS検知チャレンジの当初計画
S4x19はマイアミのサウスビーチで2019年1月に開催されたが、主催者側ではそこで最高のICS検知チャレンジを実施するべく準備を進めてきた。ある採掘会社から400GB分のICSデータの提供を受けた。このICSデータには、 Rockwell/Allen Bradley、iFix、Modicon、OsiSoft PIなどの製品群、リモートアクセス、分散制御システム(DCS)、各種車両(パワーショベル、ダンプカー、掘削機)、スロープ維持管理システムからの通信など、莫大な量のデータが含まれていた。ある資産保有者がボランティアでデータを提供してくれ、非常に協力的だった。彼はまた詳細なインベントリも提供してくれた。そこには製品の型番、ソフトウェアやファームウェアのバージョンまでもが記載されていた。自分でもパケットキャプチャ(pcap)を収集してみたが、今回のコンテストの資産インベントリ部門を見る限り、全てがうまくいくだろうという確信を得た。
DeloitteのRon Brashが、pcapを匿名化するとともに、サイバー攻撃発生の痕跡をpcapに混入させるという根気のいる仕事を引き受けてくれた。Ronはこの作業に400時間以上を費やした。攻撃のあるものは単発事象として、またあるものはさらに大規模なサイバー攻撃に関連していたり、その一部だったりするように作られていた。関連事象の場合は、チャレンジ参加企業の側で、自社の製品がその大規模なサイバー攻撃をいかにして特定し、眼前の事象と関連付け、解析を行ったかを審査員に示さなければならない。DeloitteのMarc-Etienne Bergeron 、Gravwell のCorey Thuen 、そしてSchneider Electric 、Rockwell Automation 、FireEye の数名が個人としてRonの作業を支援した。
S4x18チャレンジで多くの教訓を得ていたので、今回はスコアその他の問題となった部分を改善した。8時間という短時間で、アナリストの影響を最小限に留めた、素晴らしいコンテストとなるはずだった。
S4x19 ICS検知チャレンジの実際
詳細は「参加者の不足」セクションで説明するが、蓋を開けてみると、参加希望者はDragos、Kasperskyの両社と、あるオープンソースの資産保有者チームのみだった。この数ではコンテストが成立しない。そこで私たちは方針を転換し、互いに関連するサイバー攻撃事象を含んだ130GB分のpcapデータを参加者に配布した。参加者はこれを金曜日の遅くに受け取り、翌週の水曜日を期限に、自社の製品と手法をもって解析する。そしてその結果に基づき、採点表を埋め動画を作って提出するよう参加者に求めた。当日のメインステージでは、模擬サイバー攻撃に関するこれらの動画と情報を公開した。その様子は以下で視聴できる。
資産インベントリ部門のコンテストは実施しなかった。参加者が出した結論に対する審査も行わなかった。しかし今回のチャレンジについて考えたことがいくつかあるので、それを記してみたい。
(リアルタイムに収集して処理するには)ビッグデータが本当にビッグ過ぎた
ひとつ思い当たったのは、多くのソリューションでは、今回のICSデータを捌くには処理能力が不足してしまうということだ。分かっていてしかるべきだったが、計画の段階では気付けなかった。しかもその前段階として、解析エンジンのある場所まで全てのデータを送る必要がある。この400GBというデータはある大きな鉱山で収集したものだ。その鉱山で発生する典型的なICSトラフィックの一部を切り出したもので、スイッチを使って約2時間収集したデータとなっている。コンテスト参加者がデータの大部分を「ノイズ」と呼ぶのを何回か耳にしたが、実際は非常に饒舌なICS通信データだ。
当初の計画では、参加者に400GBのデータを8時間に渡って配信するつもりだった。これはアナリストが結果に関与できる余地を狭める目的だった。このスケジュールならば、アナリストがデータを解析できる時間的余裕があまりない。アナリストではなくシステムが自動的にデータを処理して攻撃を特定した成果が、最終結果に反映されるはずだった。 Dragosは、この転送率でデータを取り込んで保存するために、専用のハードウェアを購入した。
データを130GBに切り詰め、締め切りを1日延ばして4日後にしたのだが、攻撃を部分的であれ検知し、それを報告するための動画を作成するには複数のアナリストが力を合わせて作業する必要があった。この130GBのデータは、ある鉱山で発生するICSトラフィックの一部、約45分ぶんを切り出したものだ。こうしたデータストリームが10か所、20か所、あるいは100か所のサイトから定常的に流れてくるとしたらどうなるか、想像してみてほしい。
資産保有者はこの容量問題を重く捉えるべきだ。試用期間や試験導入期間ではこうした問題が浮上してこない場合が多い。また、メーカーがそのソリューションで分散処理にどのように取り組んでいるか、よく見極める必要がある。「ノイズ」の排除をできる限り早期に、データの収集場所にできる限り近い地点で行うことは、どのような場合でも極めて重要になる。警報と、実際のデータの限られた部分のみを転送するようにするのだ。これに関連して、これら膨大なデータが生み出す警報や事象全てに、アナリストが介在しなければならないという問題も無視できない。
資産保有者に私からアドバイスしたいのは、ここで述べた理由や、これから触れるさまざまな理由により、導入にあたっては慎重に物事を進めるべきだということだ。試験導入を行い、最初の採用候補を選定したら、少数のサイトで運用してみて、データ通信量やアラート数にうまく対処できているかどうかを確認する。そして経営サイドに、この最初の導入で選んだ製品が最終的に採用される保証はないことを確認しておかなければならない。政治的な理由で実用性に欠けるソリューションを採用してしまうことのないよう、注意するべきだ。
攻撃の検知と解析
私たちが特に調べたかったのは、コンテスト参加者が複数の事象の関連性を探り当て、ICSに対する攻撃経路を突き止め、その攻撃目的と、システムにどのような影響を与えるかを評価できるかという点だった。製品にはこれを自動的に行える機能が備わっていることが望ましい。採点表には攻撃事象を先行事象や後続事象と関連付けるための欄が用意されており、審査で重視される項目となるはずだった。
Kasperskyチームは事象間の関連性に触れなかった。同チームは攻撃事象がICS内のさまざまな領域で発生するのを検知できたが、事象の関連性については示せなかった。これらの事象は5つの単発事象として報告された。Dragosチームは模擬攻撃者の痕跡を追跡し、攻撃経路を抽出して見せた。時間的余裕があったため、これがアナリストが仕事をした結果なのか、Dragos製品が仕事をした結果なのか、どちらの寄与が大きいのか不明瞭な部分が残る。動画では、Dragos GUIでしっかりと経路が突き止められているのが見てとれる。
今回の結果より、このカテゴリーの製品に関して2通りのアプローチが存在することが明らかとなった。第1のアプローチは、ICS上で発生した攻撃や他のサイバー関連事象を個別に検知し、セキュリティオペレーションセンター(SOC)にあるセキュリティ情報イベント管理(SIEM)に転送してそこで解析を行う。これはKasperskyと同様の手法だ。第2のアプローチは、実際に攻撃を製品上で解析する。こちらのアプローチを採る場合は、製品が他のソースからセキュリティー事象関連のデータを集めることがほぼ不可欠となる。例えば、エンドポイントプロテクションやファイアウォールのログ、Active Directoryといったソースを活用する必要がある。Dragosは、オペレーショナルテクノロジー(OT)用のSOC(OT SOC)が必要だと主張しているが、このアプローチはそうした主張と軌を一にするものだ。個人的には、多くの資産保有者にとってOT SOCが正しい選択なのかどうか、そもそも実現可能なのかどうかについて、肯定的な判断が下せないでいる。
検知テストの難しさ
現在、多くの資産保有者がソリューションを試験導入しており、その数は増加傾向にある。市場規模、そして登場間もない技術であることを勘案すると、この傾向は特筆に値する。静的ソリューションの場合は、こうした製品のひとつをICSに接続し、資産インベントリにおいてどのように機能するかを確認するのはさほど困難ではないし、危険でもない。エンジニアリングワークステーションや管理アプリケーションで診断クエリを実行すれば、さらに多くのデータが得られる。(注意：ここでの考察は、資産インベントリ・管理ソリューションと検知ソリューションとがそれぞれ別個に存在し、互いに通信しながら機能するという視点に立っている。今日一般的な統合的ソリューションとは異なる。)
問題は、検知をどのようにテストするかということだ。単発事象をいくつか発生させ、シグネチャーによりそれを検知できるか確認することはできる。ネットワークに新しいコンピューターを接続したり新しいトラフィックパターンを作り出したりして、アノーマリ検知で捉えられるかを見ることもできる。こうした基本的テストではコンテスト参加者の間に差が生まれないし、それなりのスキルを持った攻撃者がICSに侵入した場合、これとは全く異なるレベルの事象が引き起こされることになる（だからこそこのカテゴリーの製品が必要となるのだ）。
自社専用のRon Brashたちを雇い、2人月以上をかけて綿密なテスト計画を組み上げることは理論上可能である。しかし実際にはそれはできないし、試験運用期間や初期デプロイメント段階において、各種のソリューションが本格的な敵対行為や攻撃の対象となることは、率直に言ってほとんどない。今のところ、この業界で勝利するために必要なのは、優れたマーケティングと営業努力、売り込むためのストーリー、そしてGUIだ。GUIは極めて重要で、サイバー攻撃の種類によっては、pcapに当たることなしに部分的にでも解析を行うことができる。今回のチャレンジ用に準備したpcapを使い多くのソリューションをテストする機会は、残念ながら失われてしまった。潜在的な顧客に対して、普通では得がたい、役に立つ情報を提供できるかと期待したのだが、叶わなかった。
参加者の不足
動きが速く競争も激しいこの業界でスタートアップ企業としてやっていくことは、容易ではないしストレスも多い。そうした状況を私も認識しているということを、まずは明らかにしておきたい。差し出がましく言うべきことでもないが、スタートアップ各社にはそれぞれの利益に最も適う行動を取る権利があるし、実際そうするだろうことを私は理解している。そして、今回のチャレンジになぜ参加しない決定を下したのか、各社にはその理由をはっきりと明かす義務もない。
S4x18やS4x19 ICS検知チャレンジに参加することは、勇気を必要とする行動だった。自社製品に対する自信がなければ下せない決断だった。あるメーカーの製品の成績が振るわなければ、チャレンジチームが発表する審査結果や講評や報道資料を目にした顧客があれこれ聞いてくることに対して、説明する作業に追われる。それどころか、「勝者」が実際の結果が示す以上のストーリーを組み立てて攻勢に出てくることが考えられるので、それにも対処しなければならない(S4x18で勝利したClarotyのことだ)。
S4x19 チャレンジではそうした事態が起きないように、資産インベントリと検知の両部門において、参加者の評価を階層(トップ、ミドル、ロー)に振り分ける形にした。これにより、非常に似通った成績であるのにわずかな差異を針小棒大に喧伝する企業が現れないようにするつもりだった。しかしこの対処法をもってしても、メーカーはコンテストに参加してこなかった。また、人脈を駆使し、この市場に参入しているあらゆるメーカーに参加を呼びかけても無駄だった。メールの長いやり取りや数多くの電話会議も効き目がなかった。
ICS検知ソリューション市場の圧倒的なトップ4のうち、ClarotyとDragosの2社が10月に S4x19 ICS検知チャレンジへの参加を申し込んできた。Kasperskyについては、こちらの参加要請が遅れたこともあるが、ビザ取得の懸念が解消した途端すぐに参加を表明してきた。トップ4の残りの2社、NozomiとForeScout(SecurityMatters)も、S4x18チャレンジに参加し好成績を収めていたことから、今回も参加してくれるものと期待していた。それどころか、実のところ、コンテスト参加者の数を制限しなければならないのではないかと危惧していた。というのは、自社がトップクラスの技術・製品を保有していることを証明するために、他にも多くの企業が集まってくると考えていたからだ。しかし事態はその方向には進まなかった。さらに、年末になり、Clarotyも参加を取りやめた。仮にどこかの面で性能に不備が見つかった場合、チャレンジに参加していない同業他社が、それを攻撃材料に使ってくるリスクがあると判断したからだ。
25社にも達するメーカーがなぜ参加しなかったのか、読者もそれぞれに思うところがあるだろうが、私自身の考察・分析は次の通りだ。
- 業界大手の残りの2社、NozomiとForeScoutは、自分たちは既に業界の主導的立場にあるので参加しても旨みが少ないと判断した。(Dragosのアナリスト陣を恐れた可能性もある。Dragosの製品は、私の個人的意見では、S4x18チャレンジの時点ではまだ実力不足だったが、チャレンジの審査対象領域を中心に製品を改良し、経験を積んだアナリストを大量に採用して今年に臨んできた。)
- Indegyは動的サイバーセキュリティー装置に的を絞って開発を行っている。同社製品の、チャレンジの審査対象となるような静的検知性能は、競争力に欠ける可能性がある。
- 業界トップ4の下に来るCyberXとその他の数社は、他社に勝てないことを危惧していた。その一方で、試験導入や販売の面では実績が上がっているのだ。コンテストに参加することはリスクが大きすぎると判断した。
- 残りの全社—検知市場では約20社が出遅れた位置にいるが、なぜコンテストに参加しないのか私としては理解に苦しむ。そうした企業にとっては、トップ企業と同列に名前が呼ばれることすら価値があると思うのだが。チャレンジに参加すること自体、知名度を上げるのに役立つだろう。彼らにとってリスクがあるとしたら、やはり市場での差は製品の差なのだと納得されてしまうような成績しか残せなかった場合のみだ。しかし20社の中には、市場で成功するためのマーケティング、営業力、資金、インフラストラクチャーに欠けてはいるものの、技術的には優秀である企業が存在していてもおかしくはなかった。しかし今回の機会を無駄にする選択をしたということは、自分たちが競争力に欠けることをほとんどの企業が知っていたのだと、私としては結論づけざるを得ない。
ICS検知チャレンジの未来
チャレンジ課題を作成するために必要となる多大なボランティア作業、そしてメーカーの側では参加に乗り気でないという現状に照らし合わせて、S4x20 で検知チャレンジが開催される可能性は低い。そうした状況を変える唯一の方法は、チャレンジが開催されたら必ず参加すると、十分な数のメーカーが積極的に支持を表明してくれることだ。多くのメーカーが集まらないならば、残念ながら検知チャレンジに未来はない。
S4x20のハッカーコンテスト(CTF)に検知チャレンジの要素を組み込めないかと、いろいろ検討を重ねているところではある。S4で何か新しいことを試してみるために、絶えずアイデアを練っている状態だ。
元記事:
Dale PetersonはDigital BondのCEOで、S4カンファレンスの創始者である。S4カンファレンスは世界最大かつ最も進んだICSセキュリティカンファレンスで、マイアミサウスビーチで毎年1月に開催される。Daleの英語の記事は dale-peterson.com で読むことができる。
