IoTペネトレーションテストの十大問題(企画編)

サイバーセキュリティは、技術を売るよりも、どうやって使うかを企画する方が面白い。

When

TOE完成度問題

ペネトレーションテストは完成度の高い部品でやるべきである」という理想と「出荷後や出荷直前に脆弱性が見つかっても簡単には直せない」という現実。このふたつのギャップに由来する、本質的な解決は不可能な問題。市場に出荷する1年前に、発見した脆弱性を修正をすることのできる最期の試作品がつくられることもあるが、その後で不慮の事態によって変更が生じることは避けられない。代替策として、初回起動時に強制アップデートをするという例があるが、これができる製品は限定される。

補題:修正の困難性

Webサービス脆弱性であれば、データセンターにあるサーバのプログラムを直して対応完了にできるだろう。それでも困難な問題といえるであろうが、台数の多いIoT製品のプログラムを直すのはそれとは簡単さが全く異なる。出荷後の修正が必要な場合はリコールに発展し、その費用は莫大である。リコールをせずに修正すると、当局からリコール隠しと指摘される恐れがある。

関連する問題:テストは計画的に

最期の試作品がリリースされてから、発見した脆弱性を修正することができるデッドラインまでの時間は、せいぜい1〜2ヶ月しかない。このため、ずいぶん前から計画的に実施する必要がある。黎明期においては急遽実施が決まることも多く、関係者から叱られやすい。

How

②十分性問題

「どれだけのテストケースをやれば十分と言ってよいか?」という、ペネトレーションテストにおける究極の問題である。そもそもペネトレーションテストにおいては、テストケースの網羅性を保証するのは困難であるが、一方で不十分なテストも許されることではない。これはIoTに限った話ではないが、IoTのサイバーセキュリティテストはWebの世界に比べて未成熟であるため、十分性を説明する手段が確立されておらず、より重大な問題と言える。

補題:報告書の充実度
  • 発見した脆弱性だけを報告書に書いて、それで満足する評価者
  • 報告書すら書かず、分かったことをチャットツールに書いてそれで仕事は終わったとする評価者
  • 再現手法を読んでもやり方がまったく分からない報告書
  • 海外の評価者は、契約終了後の瑕疵を絶対に認めない。

等の一連の問題。彼らは手を動かすのは好きだが、報告書を書くのは嫌いである。

③何色ボックス問題

計画段階のかなり早い時期で必ず問題となることのひとつ。評価者から「事前にどのような情報を頂戴できますか?」と聞かれて顕在化する。情報の量によって、テストできる内容が変わるため重要な判断ポイントであるが、例えばマイコンファームウェアは評価者に提供できないことも多い。ブラックボックスかホワイトボックスかは決め打ちするしかないのだが、その理由の根拠を上司に問われて悶絶する。

Why

④必要性問題

主に費用に関わる背景から、ペネトレーションテストの必要性を問われる頻度は高い。やったほうが良いのは議論の余地がないが、その分の費用は最終的にお客様が負担することになる。法律で必須となっているわけではないので、実施するための確固とした理由がない。一方で、必須にされてもそれはそれで困る。

What

⑤どれ問題

複数のシステムを組み合わせた製品では、製品全体をテストするのが難しい場合がある。その場合に、全体のうちのどのシステムをテストすべきか、システム単位だけで全体はやらなくてよいのか、といった決めねばならぬ問題が生じる。

関連する問題:リバエン禁止条項

構成部品の納入元とリバースエンジニアリングを禁止する契約をしている場合、テストができない。

⑥バリエーション問題

通称、バリ問題。関連する一連の製品群において、複数のバリエーションがあるときに「最初に開発される製品が最も豊かな機能を有しているとは限らない」という事実に由来する問題。最初に最も豊かな機能の製品でテストできれば、以後に再テストの必要性はないが、往々にそうではないため、その度に再実施の検討が必要になる。そして、それは悩ましい。

TOE破壊問題

評価者は、評価対象の製品をおもちゃと同じと思っているかのようだ。少なくとも製品への愛情は有していないし、値段や価値はわかっていない。このため評価対象を貸す前に、破壊の可否を強く意識づけるべきである。評価対象に対して不可逆なテストをする前には、発注者に必ず確認をさせる。

関連する問題:何個いるねん

試作品の値段は高い。それを知らない評価者は、無邪気に好きなだけ数を要求する。一方で、数が少なすぎると、もし壊れた時にテストが途中で止まるリスクがある。論理的な解として、テストの総工数をデッドラインまでの日数で割り算すれば、非破壊試験のための試作品の個数が算出できる。一方でこの計算をするには、事前に工数を精度よく見積る必要がある。

How much

⑧費用妥当性問題

コンペティタが少なく、且つどの企業も確固たる見積の根拠を有していないため、費用が営業担当者のひと声によって決まりやすい。見える化も難しい。

Who

⑨評価者選定問題

評価者のスキルを定量化するための指標がない。経済産業省が基準を公開しているが、IoT向けのものはない。海外において評価会社の一覧を公開しているものはあるが、日本にはない。「有名なところにやってもらったほうがいいんじゃないか」という有声を重視する風潮。あまり厳しい要求をすると、受注できる人がまったくいなくなるか、そこまでいかなくとも選択肢がなくなってしまう。よく言ってナレッジベース、悪く言って好き勝手にテストすることしかしない。ロジカルシンキングができない。読むひとのことを考えずに報告書を書く。途中で評価者が退職する。などの一連の問題の総称。

関連する問題:エコシステム未成熟問題

ペネトレーションテストに代表されるテストや評価は、新興サイバーセキュリティ企業にとってとっかかりにしやすいサービスである。さらに、サイバーセキュリティの専門家を名乗る者が、コメントとして「ペネトレーションテストが必要」と言いやすいがため、業界のガイドラインに書かれやすい。一方で、新興企業のサービス提供レベルは一般に低い。また第三者であるがゆえに、各製品の開発者においては常識や共通認識とされる知識を有さない。これにより、ガイドラインでは必要と謳われるのにも関わらず、実際にはサービス提供側の体制が整っていない状態が生じる。

三者開示

発注者が報告書を第三者へ開示するのに、事前に承諾を求められることがある。競合他社への開示や、「○○社に評価してもらっています」と公表されるのを躊躇することまでは同意できる。一方で、そうでもないのに開示されて困るようなテストをしてはならない。

再テスト時の評価者

初回のテストで脆弱性が発見された場合に、修正後の再実施において同じ評価者がテストする必要かあるかという疑問が生じる。答えは、テストの位置づけによって決まる。通常は、初回のテストの際に、再現性手順を評価者が示していれば、開発者にも再実施できるので、同じ評価者による再実施は必要ない。ただし、監査の位置づけでテストする場合に限っては、再実施も開発者以外の評価者が実施するべきである。またこの場合は、評価者が誰なのかを社外に公告できることが条件である。

関連する問題:対策要否の判断が悩ましい

評価者からの指摘において、業界相場に比べて過剰な対策を推奨していたり、攻撃者による悪用が困難であったり、果ては事実と異なる推測で書かれていたりすることがある。そんな指摘であっても、発注者は報告書を読み込んで対策要否を考えなくてはならない。どうやら彼らには、指摘は多ければ多いほうがいいという勘違いと、0件では報告書を発行できないというプライドがあるらしい。しかもこの問題は、テストの終盤で明らかになるためタチが悪い。

Where

⑩運搬・輸出できないorたいへん問題

大きな製品や第三者が目にすることが許されない製品は、運搬が容易ではないため、テストする場所が限られる。そして、テスト中は社員の常時立会いが必要になる。
また、海外にいる評価者のために輸出を希望されることがあるが、輸出前に該非判定書類を作成するのは面倒で且つ時間がかかる。代わりに海外から人を呼ぶのは、渡航費や宿泊費のムダである。