本当にそれで十分？つながる時代のセキュリティテストとは！？

つながる時代に求められる視点とは？

IoTの時代となり、様々な機器がインターネットにつながるようになっている。このような中、IoT機器のセキュリティ対策は喫緊の課題となっている。そのためセキュリティバイデザインの考えのもと、製品の企画・設計段階からセキュリティの作り込みが行われており、あわせてセキュリティ品質を確保する上で様々なテストが行われている。今回のテーマではこの「セキュリティテスト」を取り上げるが、それに纏わるよくある誤解として、次のような発言を耳にすることがある。

A氏の発言は、一見、問題ないように見えるが、基本的にはシステムの内部構造を理解した設計者視点による、主に既知の脆弱性を対象としたテストについて言及している。一方で、サイバー攻撃は日々進化しており、企業は常に新しい攻撃手段による脅威にさらされている。従って、未知の脆弱性がシステムに内在する可能性がある。このような設計者も認識していない脆弱性や問題点の有無を発見するためには、テスト実施者が実際に侵入を試みて、ピンポイントでシステムに脆弱性がないかをテストすることが有効と考えられる。その場合、実際に侵入を試みるため、攻撃者の視点が求められる。この攻撃者視点は、内部構造を把握した状態である従来の設計者視点とは全く異なる視点であるため、新たな取り組みとして検討する必要がある。

このように、日々サイバー攻撃にさらされるIoT機器の開発においては、新たに攻撃者視点を取り入れたテストを組み合わせることで、製品開発段階において未然に脆弱性を発見し対処することが重要となる。そのためにはまず、それぞれのセキュリティテストの目的を理解しておく必要がある。

セキュリティテストの目的を理解する

セキュリティテストを体系的に整理すると、図1のようにテスト実施者に提供される情報量の多い方から順にWhite Box、Gray Box、Black Boxの3つに分類ができる。White Boxでは、設計仕様書等の機密情報を基に、内部の構造を理解した上でのテストを行う。一方のBlack Boxでは、活用情報は主に公開情報となり、内部的な設計情報が無い状態での第三者的なテストとなる。Gray Boxは、それらの中間に位置し、第三者的なテストとしながらも、最低限の設計情報を提供することで、テストの効率性を高めることを可能とするものである。

図1　セキュリティテスト概要

更に、これらWhite Box、Gray Box、Black Boxの3つの分類に対して、テスト実施者に求められる設計者視点と攻撃者視点の2つの視点を関連付けることができる。

設計者視点のテストは、White Boxテストをベースとし、設計者によるセキュリティ機能テストや、ソースコードレビューをはじめ、自動化ツールを用いたファジングテストや脆弱性診断等がある。また、テスト対象によっては、より高い品質を求める場合等、設計者の先入観を排除した第三者検証が求められることもあり、その際Gray Boxテストのようにテスト実施者に提供される情報が制限される場合もある。

これらのテストでは、プログラムを実行し動的な観点でセキュリティ機能が正しく実装されていることに加え、プログラムの実行無しにウォークスルー等のレビューや、自動化ツールにより、静的な観点でソフトウェアに不具合や脆弱性が無いかについて確認する。

一方の攻撃者視点のテストは、ペネトレーションテストが該当する。ペネトレーションテストは、IT業界では広まりつつあるテストであるが、セキュリティが重要となるIoT機器にも適用する動きが高まっている。ペネトレーションテストは、基本的にBlack Boxに該当し、公開情報を基にしたテストとなる。但し、全く設計情報が無い状態では、その情報収集に膨大な時間を要し、高度化および複雑化するシステムに対してテスト範囲や深さを適切に特定できず、限られた時間で効果的なテストができない可能性がある。このような状態では、テスト委託者とテスト実施者の双方にメリットが無いため、効率性を考慮しテスト委託者が適宜情報を提供した上でのGray Boxテストとなる場合も多い。

ペネトレーションテストでは、入手した情報を基に、攻撃シナリオを作成し、実際に攻撃を仕掛けて侵入につながる脆弱性や問題点の有無を確認する。そのテスト品質を高めるには、テスト実施者の技術的なスキルに加えて、いかに攻撃者視点で考えられるかが重要になる。

ペネトレーションテストを効果的に導入するために

ペネトレーションテストでは、Black BoxあるいはGray Boxテストが前提となることから、一般に活用情報として製品内部の設計仕様等の機密情報の入手は制限される。特に活用情報が公開情報のみとなるBlack Boxの状態でテストを行うことは、製品の設計情報の入手にかかる情報収集に多大の労力を要し、人、モノ、金、時間といったリソースを浪費する恐れがある。従って、限りあるリソースをいかに有効に使うかということが、ペネトレーションテストでは特に重要な検討事項となる。

図2にペネトレーションテストフローの概要を示す。リソースの有効活用の観点においては、特にテスト実施前のプロセスが重要となる。

図2　ペネトレーションテストフローの概要

まず事前調整として、テスト委託者とテスト実施者との間で、テストの目的、体制、実施期間、対象、範囲、提供情報等の各種取り決め事項について、事前に合意する。例えば、一般に公開されている情報に加え、テスト委託者から詳細な設計情報等が提供されるのかについて確認する。また、テストの対象や環境が、テスト専用で準備される場合、その動作が実運用環境とは異なる場合がある。このような場合、事前にテスト環境と実運用環境との差分についても十分把握しておく必要がある。更に、十分なテスト期間の確保も重要な観点となる。というのは、ペネトレーションテストは、ハードウェアおよびソフトウェアが統合されたシステムがある程度完成した状態で実施されることが多いため、製品出荷までの時間的猶予が少なく、テストのための十分な時間を確保することが困難となる場合があるためである。

このように、テストに係るあらゆる前提条件や情報を事前に収集し、テスト委託者とテスト実施者間で合意しておくことが、以降のテストにおける効果的なリソース配分や、テスト品質向上に大きく寄与する。

リソースの有効活用の観点で、もう一つ重要となるのは、適切なテストの範囲と深さを定義することである。ペネトレーションテストを効果的に導入するための手法の一つとして、リスクベースアプローチがある。リスクベースアプローチでは、製品に対してリスクアセスメントを実施し、管理すべき情報資産の特定、情報資産に対するリスクの特定と分析、特定したリスクに対する評価のステップを踏む。その結果、セキュリティ侵害された場合の影響度が大きいシステム上の部品（コンポーネント）を、優先的に評価対象とするなどの優先度付けが可能となる。テストの範囲と深さはトレードオフの関係にあり、テスト対象のコンポーネント数が多ければ、1つのコンポーネントに対し実施できるテストの深度は浅くなり、逆にテスト対象のコンポーネントが少なければ、1つのコンポーネントに対し深度あるテストを行うことができる。

以上を考慮の上、リスクベースアプローチを用いたテスト対象コンポーネントの決定に加え、網羅性も踏まえた実施可能なテスト項目数（深さ）について、メリハリをつけたテスト計画を立案し、テスト委託者とテスト実施者間で合意することが重要となる。

求められるのは説明責任

ペネトレーションテストでは、攻撃者視点で実際に侵入を試みるということから、テスト実施者は、コンピュータ、プログラミング言語、ネットワーク等に関する高度な知識と解析スキルに加え、対象となるIoT機器そのものに関する知識を備えることが望ましい。社内に適切な人材がいない場合は、優秀なホワイトハッカー（善良な目的のもとに活動するハッカー）を有する専門企業等にテストを委託する場合もある。

ここで、注意しなければならないのは、ペネトレーションテストは、攻撃者視点と高い技術力の観点だけでは不十分ということである。仮に、優秀なホワイトハッカーがテストを行い、発見事項が無かったから問題ないということだけでは、対外的な説明責任を果たしにくい。何故、問題ないのかを体系的に説明できる論証が必要となる。特に、自動車や医療等の人命に影響を及ぼす領域では、機器に対して高いレベルの安全性が求められることから、全てのテスト活動を通じて、体系立てられた十分な論証が求められる。そのために、前述のリスクベースアプローチによる、テストの範囲や深さの定義、それらに基づくテスト計画に従ったテストの実施、および結果の整理といった方法論の構築が重要となる。

また、高い専門性を持つ人材に過度に依存したやり方では、人材確保の観点も含めて現場の設計開発プロセスに組み込みにくい。ペネトレーションテストを、特定の製品開発における一過性のものとして終わらせるのではなく、社内で継続的に運用し、定着させるためにも、テストの方法論を踏まえ設計開発プロセスとして整備することが重要となる。

製品特性を踏まえた実施検討を

ここまで、つながる時代のセキュリティテストには、新たに攻撃者視点も必要となることを述べてきた。とは言え、一般にIoT機器はコスト制約が厳しいため、そう簡単には新たなテストの導入は難しい場合もあるかもしれない。しかし、製品が市場で運用されている間にサイバー攻撃を受けると、その対策に係るコストは、設計開発時における対策コストと比較して、膨大なものとなると言われている。例えば、自動車のように出荷台数が多く人命に関わる機器では、製品が一旦市場に出た後に問題が発生すると、リコール等も含め、その対応に要するコストが膨大となる可能性がある。従って、製品出荷前に可能な限り脆弱性を発見すべく、ペネトレーションテストを導入することは、製品の運用まで含めると結果的にコスト低減につながるという考え方もできるのではないだろうか。

冒頭に登場した製品設計担当役員Aの発言は、設計者視点ではセキュリティ対策を十分考慮されているが、一方で製品特性を考慮した上で、よりセキュリティ品質向上のための攻撃者視点のテストに係る考慮も必要であった。具体的には、次のような発言だとよかった。

IoT機器では厳しいコスト制約の中、そこに新たにセキュリティも考慮する必要がある。従って、セキュリティテストにおいては、種々のテストを正しく理解した上で、製品特性を踏まえたコストバランスの良いテスト計画の立案が重要となる。その上で、新たな攻撃者視点のテストを積極的に取り入れることで、未知のサイバーリスクに備えるようにしたい。

【連載】勘違いセキュリティ（あなたの理解は大丈夫？）シリーズブログ記事はこちら