IoTセキュリティ検証は、一体どこまでやればよいのか？ ７つのポイントで解説！
近年、IoT機器を含むデジタル機器のサイバー攻撃に対するリスクが非常に高まっていることはご存じのとおりだろう。サポート切れの機器や脆弱性のある機器が放置されていると、それらの機器がマルウェアに感染し、踏み台にされてDDos攻撃に加害者になってしまうこともありえる。そこで重要になってくるのが、IoT機器の十分なセキュリティ検証である。だが実際に「IoTセキュリティ検証を、どこまでやればよいのか？」といった現場の声も聞かれる。この点について、ユビキタスAIコーポレーション SPQA事業部 松本 希氏が解説した。
IoTのセキュリティリスクと、ライフサイクルにおける検証で考慮すべき点とは？
いまやIoT機器であっても、十分なセキュリティ対策を施していかねばならないことは常識になってきた。エッジ側のIoT機器というと、ネットワーク・インターフェイス（I/F）が攻撃の侵入経路と考えがちだが、実は通常利用のI/F、メンテナンス用のI/F、非公開のI/Fなどからもハッキングされる恐れがある。そういった背景もあり、事前のファジングテストやぺネストレーションテストの必要性が高まっているのだ。
IoT機器にセキュティ対策を施す際は、企画から販売・サービスまでのライフサイクルに合わせていく必要がある。たとえば設計段階ではセキュリティレベルに応じたハードウェアの選定をしたり、実装段階ではセキュアコーディングによって穴のないプログララムを作り、検証段階では脆弱性診断やセキュリティ検証を実施しておくことが重要だ。
ユビキタスAIコポレーションでは、こういったライフサイクルに合わせて、以下のような施策を用意している。たとえばセキュアコーディングでは静的解析ツール「CodeSonar」、セキュリティ検証や運用・保守ではIoTセキュリティ検証フレームワーク「beSTORM X」や、脆弱性診断サービス、セキュリティ定期検診サービスなどを提供しているそうだ。
ちなみに同社のbeSTORM Xは、TCP/IPやWi-Fiなど200種類以上のプロトコルをサポートし、実際に攻撃データをIoT機器に流して様子を見ることが可能だ。経産省の「セキュリティ検証の手引き」でも、脆弱性を検証する代表的なツールとして紹介されている。またツールを自社で導入するだけでなく、専門知識を持ったエキスパートエンジニアが一括で対応してくれるサービスも提供中だ。
IoT機器のセキュリティ検証で知っておきたいポイント（技術面）
さて、ここからは表題のテーマである「セキュリティ検証に関する7つのポイント」についてお伝えしよう。ここでは技術面と運用面に分けて考えてみる。まず技術面から5つのポイントについて説明する。
【技術面からの5つのポイント】
- 製品の攻撃経路になりうるI/Fの洗い出しから始める
IoT機器ごとに多様なI/Fを搭載しているため、どこから攻撃されそうなのか、そのリスクを検討する。攻撃はネットワーク以外のI/F（USB、Bluetoothなど）にも存在するので注意。 - 攻撃者視点でのアプローチで考える
攻撃者側は、開発者や製造者が意図していない想定外のパケットを送ったり、プロトコルの穴を意識した攻撃を仕掛けてくる。セキュリティ検証の際は、エンジニアの専門スキルもポイントの1つになるだろう。
3.IoT機器の特性に応じたテスト環境を構築
テスト時に困るのは、製品ごとに異常時の振る舞いが異なることだろう。一体何を基準としてエラーと判断すればよいか分からないこともある。エラーもサービスが停止するなど、振る舞いによって分かることもあるが、内部メモリーの変化などは見た目では分からない。そのため事前に判断材料を見える化しておき、確認できる状態にしておくことが大切だ。
4.組込み機器の視点での解析
機器の中には、サードパーティ製のプロトコルスタックを利用しているケースもあり、OSやミドルウェアに脆弱性を発見しても、その原因の切り分けが難しいこともある。外部委託のソースコードを完全に把握できない場合は、問題切り分けのための解析情報を相手に渡せるようにしておきたい。IoT機器の検証では組込みとセキュリティの知見が必要だ。
5.ツールを利用したテストの自動化
そもそも人手でテストケースやパターンを作成するには時間・コスト的に限界があるだろう。たとえばファジングテストで4byteのパケットを流すにしても、8bit×4＝32bit＝2の32乗となり、42億個の組み合わせで総当たりしなければならない。そうなると自動化はもちろん、あらかじめ過去の脆弱性や攻撃者の視点でシナリオを持ったツールを活用して、効果的なテストを行うことが肝要となる。
IoT機器のセキュリティ検証で知っておきたいポイント
次に、運用面からのポイントを2つ紹介する。
【運用面からの2つのポイント】
6．セキュリティパートナーによる検証
ユーザーからセキュリティ要件を受けて製造メーカーが対応する場合は、なかなか迅速に検証できないことも多い。そこでセキュリティパートナーに検証業務を委託すれば、多くの恩恵を受けられるだろう。人材や体制構築を持つパートナーによって、リードタイムの短縮や、第三者視点での客観的なエビデンスの提示などが受けられる。
7．問題可視化からの取り組みが大切
運用面においては、現行モデルの問題点の可視化が大切だ。本来、上流工程の設計段階からセキュリティを考慮できれば理想的だが、開発期間もコストも膨大なものになってしまう。そこで現行モデルから入り、フィードバックできるような問題点をみつけて、次世代のモデルに反映していくことが現実解となるだろう。
ここまでの技術面と運用面の7つのポイントを踏まえ、「どこまでセキュリティ検証を行えばよいのか」というテーマについての答えを考えてみると、そこには絶対的な正解はなく、「まず始めてみることが重要」ということになるだろう。セキュリティ対策は「進化し続けなければならないもの」であり、機器の特性にあった最適解を考える必要があるからだ。 機能・サービス・I/F単位でセキュリティの課題が発生するため、「本当に求められる機能を絞り込み、不要な機能を搭載しないこと」が安全性を高める1つの答えにもなる。また自社での解決だけでは限界があるため、検証ツールの導入やパートナーとの連携、他社の事例なども参考にして、セキュリティ検証のカバレッジを考えるとよいだろう。
セキュリティ検証におけるユビキタスAIコーポレーションの取り組み
以上のポイントを踏まえたうえで、これまでユビキタスAIコーポレーションが実施してきた具体的な検証事例についても紹介したい。
【事例1】HTTPサーバー搭載のIoT機器（サービス）
HTTPサーバー／HTTPSクライアントのセキュリティ検証のために、IoT機器のシリアルI/Fから吐き出されるログを監視する独自モニター（beSTORMモニター）を構築した。その結果、HTTPサーバーのコネクションのリソース枯渇によってサービスが停止。またHTTPSクライアントへファズデータ（想定外のデータ）を送ると機器がハングアップした。ソフトウェアでの検証は済んでいたが、検証ツールを利用すると、こういった新たな脆弱性が炙り出されることがある。
【事例2】無線LANアクセスポイントその1（サービス） 無線LANのAP（アクセスポイント）に、beSTORMからファズデータを送信。その結果、IPヘッダのオプション領域の異常値が起因する障害によって、イーサーネットレベルで通信ができなくなった。この問題を解決するために、ユビキタスAIコポレーションは、メーカーに追加試験と試験スクリプトを提供し、セキュリティの向上に貢献した。
【事例3】無線LANアクセスポイントその2（サービス）
無線LANのAPに対して、beSTORMから複数のファジング試験を同時に行い、超高負荷な環境でセキュリティを検証した。メモリの空き状況をログ出力から監視していたところ、メモリが枯渇して機器がリセットされてしまう現象をとらえた。メーカー側で不備を改修して、安全な安全な製品を世に無事に届けられた。
【事例4】医療用デバイス（ツール）
この事例は、秘匿性の高い医療用デバイスだったので、ユビキタスAIコーポレーションの検証サービスは利用せず、試験環境を提供して顧客自身の手でセキュリティ検証を実施した。beSTORMをベースとした試験環境とロギングシステムにより、USBホスト／ペリフェラルへのファジング試験を実施。ネットワーク以外のセキュリティ試験となった好例だろう。
【事例5】産学連携CAN-FD対応
最後の事例は、名古屋大学との産学連携による事例だ。同大とユビキタスAIコーポレーションは、beSTORMのカスタマイズ機能を使って、当時まだ検証不可能だった「CAN-FD」（CAN with Flexible Data Rate)のプロトコルに対応したファイジング環境を構築。beSTORMは、世の中に出回っておらず、将来的に発展しそうなプロトコルに対しても、ユーザー側でカスタマイズすることで、先取りした試験環境を作り出せる。 このほかにもbeSTORMによって、さまざまなセキュリティに関するクリティカルな問題を検出している。事前に問題を検証することで、より安全・安心な製品をつくれるため、今後もファイジング試験やぺネストレーションテストなどの必要性が高まっていくだろう。
★セキュアなIoTサービスを実現するソリューション「Edge Trust」の詳細、資料の請求はこちらよりも確認ください。
★ソフトウェアセキュリティ検証ツールの詳細、資料の請求はこちらよりも確認ください。
