IoTペネトレーションテストの十大問題（企画編）
サイバーセキュリティは、技術を売るよりも、どうやって使うかを企画する方が面白い。
When
①TOE完成度問題
「ペネトレーションテストは完成度の高い部品でやるべきである」という理想と「出荷後や出荷直前に脆弱性が見つかっても簡単には直せない」という現実。このふたつのギャップに由来する、本質的な解決は不可能な問題。市場に出荷する1年前に、発見した脆弱性を修正をすることのできる最期の試作品がつくられることもあるが、その後で不慮の事態によって変更が生じることは避けられない。代替策として、初回起動時に強制アップデートをするという例があるが、これができる製品は限定される。
補題：修正の困難性
Webサービスの脆弱性であれば、データセンターにあるサーバのプログラムを直して対応完了にできるだろう。それでも困難な問題といえるであろうが、台数の多いIoT製品のプログラムを直すのはそれとは簡単さが全く異なる。出荷後の修正が必要な場合はリコールに発展し、その費用は莫大である。リコールをせずに修正すると、当局からリコール隠しと指摘される恐れがある。
関連する問題：開発は計画的に
特にマルチメディアの部品は開発日程が延期されがち。テスト時期に機能が未実装のことがある。
関連する問題：テストは計画的に
最期の試作品がリリースされてから、発見した脆弱性を修正することができるデッドラインまでの時間は、せいぜい1〜2ヶ月しかない。このため、ずいぶん前から計画的に実施する必要がある。黎明期においては急遽実施が決まることも多く、関係者から叱られやすい。
How
②十分性問題
「どれだけのテストケースをやれば十分と言ってよいか？」という、ペネトレーションテストにおける究極の問題である。そもそもペネトレーションテストにおいては、テストケースの網羅性を保証するのは困難であるが、一方で不十分なテストも許されることではない。これはIoTに限った話ではないが、IoTのサイバーセキュリティテストはWebの世界に比べて未成熟であるため、十分性を説明する手段が確立されておらず、より重大な問題と言える。
Why
④必要性問題
主に費用に関わる背景から、ペネトレーションテストの必要性を問われる頻度は高い。やったほうが良いのは議論の余地がないが、その分の費用は最終的にお客様が負担することになる。法律で必須となっているわけではないので、実施するための確固とした理由がない。一方で、必須にされてもそれはそれで困る。
What
⑤どれ問題
複数のシステムを組み合わせた製品では、製品全体をテストするのが難しい場合がある。その場合に、全体のうちのどのシステムをテストすべきか、システム単位だけで全体はやらなくてよいのか、といった決めねばならぬ問題が生じる。
関連する問題：リバエン禁止条項
構成部品の納入元とリバースエンジニアリングを禁止する契約をしている場合、テストができない。
⑥バリエーション問題
通称、バリ問題。関連する一連の製品群において、複数のバリエーションがあるときに「最初に開発される製品が最も豊かな機能を有しているとは限らない」という事実に由来する問題。最初に最も豊かな機能の製品でテストできれば、以後に再テストの必要性はないが、往々にそうではないため、その度に再実施の検討が必要になる。そして、それは悩ましい。
⑦TOE破壊問題
評価者は、評価対象の製品をおもちゃと同じと思っているかのようだ。少なくとも製品への愛情は有していないし、値段や価値はわかっていない。このため評価対象を貸す前に、破壊の可否を強く意識づけるべきである。評価対象に対して不可逆なテストをする前には、発注者に必ず確認をさせる。
How much
⑧費用妥当性問題
コンペティタが少なく、且つどの企業も確固たる見積の根拠を有していないため、費用が営業担当者のひと声によって決まりやすい。見える化も難しい。
Who
⑨評価者選定問題
評価者のスキルを定量化するための指標がない。経済産業省が基準を公開しているが、IoT向けのものはない。海外において評価会社の一覧を公開しているものはあるが、日本にはない。「有名なところにやってもらったほうがいいんじゃないか」という有声を重視する風潮。あまり厳しい要求をすると、受注できる人がまったくいなくなるか、そこまでいかなくとも選択肢がなくなってしまう。よく言ってナレッジベース、悪く言って好き勝手にテストすることしかしない。ロジカルシンキングができない。読むひとのことを考えずに報告書を書く。途中で評価者が退職する。などの一連の問題の総称。
関連する問題：エコシステム未成熟問題
ペネトレーションテストに代表されるテストや評価は、新興サイバーセキュリティ企業にとってとっかかりにしやすいサービスである。さらに、サイバーセキュリティの専門家を名乗る者が、コメントとして「ペネトレーションテストが必要」と言いやすいがため、業界のガイドラインに書かれやすい。一方で、新興企業のサービス提供レベルは一般に低い。品質にかかる企業内ルールがない。また第三者であるがゆえに、各製品の開発者においては常識や共通認識とされる知識を有さない。これにより、ガイドラインでは必要と謳われるのにも関わらず、実際にはサービス提供側の体制が整っていない状態が生じる。
第三者開示
発注者が報告書を第三者へ開示するのに、事前に承諾を求められることがある。競合他社への開示や、「○○社に評価してもらっています」と公表されるのを躊躇することまでは同意できる。一方で、そうでもないのに開示されて困るようなテストをしてはならない。
再テスト時の評価者
初回のテストで脆弱性が発見された場合に、修正後の再実施において同じ評価者がテストする必要かあるかという疑問が生じる。答えは、テストの位置づけによって決まる。通常は、初回のテストの際に、再現性手順を評価者が示していれば、開発者にも再実施できるので、同じ評価者による再実施は必要ない。ただし、監査の位置づけでテストする場合に限っては、再実施も開発者以外の評価者が実施するべきである。またこの場合は、評価者が誰なのかを社外に公告できることが条件である。
関連する問題：対策要否の判断が悩ましい
評価者からの指摘において、業界相場に比べて過剰な対策を推奨していたり、攻撃者による悪用が困難であったり、果ては事実と異なる推測で書かれていたりすることがある。そんな指摘であっても、発注者は報告書を読み込んで対策要否を考えなくてはならない。どうやら彼らには、指摘は多ければ多いほうがいいという勘違いと、0件では報告書を発行できないというプライドがあるらしい。しかもこの問題は、テストの終盤で明らかになるためタチが悪い。
