組込み製品開発担当者へ向けた 失敗しないペネトレーションテスト実施のいろは

3行でわかる！本記事のサマリ

はじめに

これまで多くの企業の製品向けペネトレーションテストをアレンジしてきた経験から、テスト実証を成功に導くためのポイントを解説します。

組み込み製品開発者を取り巻くセキュリティ動向

組み込み製品を取り巻く昨今の状況について見てみると、多くの機器メーカーは業界標準や顧客の個別要求の対応に向けて、プロセス改善や機能強化などを進めています。そんな顧客からの要求のなかには、セキュリティテストの実施要件が具体的に出てきており、ペネトレーションテストも含まれることが一般的となっています。具体的には、産業用オートメーションや制御機器、開発プロセスを対象とした規格であるIEC62443-4-1においては、Security Verification and validation testing(SVV)の項目内に、"SVV-4 Penetration testing"が明記されていたり、、ISO21434や医療系各国規制・ガイダンスにも記載されていたりします。そこで、機器メーカーはペネトレーションテストの実施していくことになりますが、詳しい実施方法までは記載されていません。そのためセキュリティ対策やテストに取り組んでこなかった企業では、まずは実施をすることを目標にテストベンダーに依頼することが現実となっています。

マクニカでの過去のペネトレーションテスト失敗事例

実際にマクニカへテスト実施を依頼いただく企業も少なくありませんが、うまく実施できなかった事例も現実に存在しています。ここでは失敗事例をサンプルに、テスト前の準備、テスト実行中、そして質疑応答のQ＆Aの3段階に分けてポイントを見ていきます。

準備段階においては、網羅的に脆弱性を発見する活動となるペネトレーションテストのインプットを最初に説明。提案書内の攻撃を実際に実施することを伝えることで、顧客側にて社内稟議を通し、最終的にテスト実施の承認がおりました。承認が下りた段階で、テストを実施した結果、複数の脆弱性が発見され、レポートを作成し報告する流れとなりました。

レポート提出後の質疑応答の段階で、具体的なテスト内容や発見された脆弱性に関する質問に対して回答し、顧客担当者は社内への結果報告を行ったのです。

そこで担当者から報告を受けた責任者は、いくつか脆弱性があることは分かったものの、このテストだけで十分なのかが判断できないとのことで、担当者に再度質問が寄せられることになりました。その結果、追加のQ＆Aを受け付けることになったわけです。

この事例での問題点は大きく2つあります。1つが、Q＆Aの期間が延びてしまい、検収期間が延びてしまったこと。そしてもう1つが、本来欲しかったペネトレーションテストの結果が、責任者が望んでいたものと差が生じてしまったことです。

この事例を通じて重要な論点となってくる、顧客のテストに対する期待値とどこでギャップが生じてしまうのかという点について考えていきます。

なぜペネトレーションテストで失敗してしまうのか？

なぜ、期待値とアウトプットの差が生じてしまったのでしょうか。当初テスト実施者から依頼担当者へペネトレーションテストの説明を行いますが、テスト依頼のタイミングで「既知の脆弱性を可能な限り把握したい」「公開されていない未知の脆弱性を知りたい」といった期待値をもって、テストが依頼されたと考えられます。

テスト実行フェーズでは、テスト実行後にレポートを依頼者が受け取ると、ここでも「テスト中に実施した内容を知りたい」「テストの十分性を知りたい」「実施した内容ごとの評価を知りたい」といった期待値が、テストレポートを見た後の事後的に生まれることがあります。特に、テスト依頼者が責任者など第三者に対する説明責任がある場合、テストの十分性や実施内容に対する期待値が非常に高くなるケースが多くあるのです。

このように期待値が満たされない理由には、大きく2つの観点が考えられます。1つ目の準備段階での期待値については、正しいセキュリティテスト選択ができていないことが原因です。つまり、セキュリティテストへの理解が不十分であることが課題となってきます。そしてテスト実行後の期待値については、テスト前の準備が十分できていないことが原因で、テスト実施者と依頼者間での必要情報がやり取りされてないことが課題だと考えられます。

期待値のギャップを解消するためのアプローチとは

では、これらの課題を解決するためには、どのようなアプローチが必要なのでしょうか。大きくは「実施するテストの選定」「テストの計画」「テスト実行」という各フェーズでのアプローチが必要です。このなかで、実施するテストの設定フェーズにて、セキュリティテストの理解を深め、目的に応じたテストを決定していくことで、セキュリティテストへの理解が不十分であることの課題が解消できます。また、テストの計画フェーズにおいて、情報提供・分析および評価観点案の策定を依頼者と一緒に行っていくことで、実施者・依頼者間での必要情報がやり取りされてないことの課題が解消できるのです。

「実施するテストの選定」でのアプローチ

実施するテスト選定を正しく行うためには、どのようなテストが、どのような開発フローのなかで行われるのかといった基本を理解することが大切です。一例を挙げると、IoT機器のような製品の開発フローは、製品企画から設計・製造（実装）、評価、運用・保守、そして廃棄の流れが一般的です。このフェーズごとに、それぞれどんなテストが実施されるのかを内容含めて理解してもらえるようにしっかりと説明していくことが必要です。

開発フローごとにさまざまなテストが実施されますが、評価フェーズのなかで行うネットワークスキャンやWebアプリスキャンと呼ばれるものが脆弱性診断にあたります。評価や運用・保守フェーズにおいては、目的に応じてペネトレーションテストや脆弱性診断をそれぞれ選択しながら行ってきます。どの段階でどんなテストを行うのかを正しく理解することが、正しいテスト選択につながっていくわけです。

ペネトレーションテストと脆弱性診断の違い

ここで、ペネトレーションテストと脆弱性診断の違いについて理解しておきましょう。テストの目的は、どちらも脆弱性を発見するという似通ったものであるため混同しがちですが、その方法は大きく異なります。ペネトレーションテストは決められた方法がなく、ホワイトハッカーが手動で攻撃の実施を行い、その過程で脆弱性を見つけだすというもの。一方で脆弱性診断は、既知の検出パターンが決められており、それに沿ってツールやマニュアルによって実施するテストで、可能な限り多くの既知の脆弱性を発見することがその目的となります。

手法が固定化されていないペネトレーションテストでは、手動のために専門性が求められますが、決まった手法で既知の脆弱性を見つけていく脆弱性診断は、一部マニュアルの場合は専門船が求められるものの、基本的にはツールを使ってテストを実施するためにペネトレーションテストに比べて専門性は求められません。

テスト網羅性についても大きな違いが出てきます。ペネトレーションテストは、実現可能な脅威があるかという観点でテストを実施するため、そもそも網羅性を求めるテストではありません。一方で脆弱性診断は、事前に定められたスト項目を漏れなく実施するため、網羅性が求められるものです。

アウトプットについても、対象製品・システムに内在する脆弱性についてレポートする脆弱性診断に対して、ペネトレーションテストは、対象製品・システムに内在する脆弱性とともに、その脆弱性が攻撃につながった場合の結果がレポートされます。

似通った2つのテストであっても、目的や方法、網羅性など違いがあることを正しく理解することで、期待値でのギャップを生まない最適なセキュリティテストが選択できるのです。

「テストの計画」でのアプローチ

テストの計画フェーズでは、実施者・依頼者間での必要情報がやり取りされてないことの課題を解消していく動きが求められます。

ペネトレーションテストの進め方は、「テストの準備」「テストの実施」「結果」という3つのステップが一般的で、なかにはテスト実施者へ最低限の情報のみを与えて環境だけ用意するブラックボックステストと呼ばれるアプローチも存在しています。ただし、実施者・依頼者間で必要情報のやり取り不足が招いた課題解消につなげていくためには、テストの準備段階で、テスト実施者と依頼者が一緒になってテスト評価観点を詰めていくなど十分な活動を行っていくことが必要です。

特に重要になってくるのは、テストの準備段階において、テスト環境の提供だけでなく、必要情報提供・整理や情報の分析、テスト評価観点の策定といったステップを追加していくこと。この活動は、テスト実施者と依頼者が一緒になって行っていくなかで合意形成していくことが非常に重要です。

具体的には、テスト依頼者がIF一覧や機能一覧など情報提供を行い、実施者が機能を理解してアタックサーフェースとなり得る個所を特定、そしてテスト評価観点を作成したうえで、依頼者と合意するというステップを踏みます。この一連の活動を行うことで、ペネトレーションテスト実施前に、テスト評価観点を依頼者と実施者との間で合意を取り、それに則ってテストを行っていくことで、レポート後の期待値が大きくかけ離れることがなくなってくることでしょう。


●評価観点の参考例
ここで、テスト実施前の評価観点の作成例を紹介します。これはIoT機器が今回のテスト対象となっており、攻撃者による直接アクセスとともに、IoT機器によるクラウド接続、スマートフォンからの直接制御という観点で考えたものです。アタックサーフェースとともに、それぞれの機能、そして評価観点という点でまとめたものとしてイメージしやすいはずです。

●ペネトレーションテストで行う攻撃例
また、ペネトレーションテストがイメージしやすいよう、実際にテストにて実施される攻撃例も2つほど紹介します。1つ目が、IoT機器としてのテスト端末に攻撃者が攻撃を仕掛け、サービス停止に追い込むことができた攻撃例、2つ目がIoT機器を物理的に分解して基板上に知るあるインターフェースであるUART IFを特定し、そこから攻撃を行った例です。ペネトレーションテストの一例として参考にしてください。

これまで見てきたとおり、満足のいくペネトレーションテスト結果を得るには事前準備が重要になってきます。そんな状況も加味したうえで、テスト実施者とともに、最適なテスト計画を作成していきましょう。マクニカではテストの建て付け段階から支援を行っています。お悩みの方はぜひご相談ください。