IoTセキュリティ

分野・産業別のIoTデバイス数及び成長率予測の通り（下記図３）、IoTデバイスの単純なデバイス数は大幅に増加し、クリティカルな分野への応用は急速に広がりを見せている。

総務省の試算によると2020年には530億個のIoTデバイスが活用され、その多くがホームネットワーク、コネクティッドカー等の消費者向けサービスに向けて普及していくことが見込まれている。工場、店舗といった業務利用の範疇での限られた利用から一般消費者向けに広がっていく中で、セキュリティの確保は急務とされており、2016年には 経済産業省及び総務省のワーキンググループから「IoTセキュリティガイドライン ver1.0」(※1) が策定されるなど、国を挙げての関心が高まっている。また、国立研究開発法人情報通信研究機構（NICTER）の発表によると、2017年に観測された年間のサイバー攻撃パケット数は1500億にも上る（下記図４）。同レポートでは、この半数近くがウェブカメラやモバイルルータなどのIoT機器に関連した攻撃であると報じている。

図４でも強調されている通り、1つのIPアドレス当りの攻撃パケット数はおよそ56万パケットにも及ぶ。IPパケットのサイズは伝送経路によって可変であるが、モバイル通信において一般的な1パケット＝128バイトとしたとき、56万パケットは71メガバイトにも及ぶ。このデータ量にはヘッダ部が含まれていたり、同一の攻撃があったりするため、すべてが有効な攻撃ではないが、経年による母数の増加も考慮し、年間71メガバイト相当の攻撃は “なされるもの” として対策を講じるべきであろう。このような背景を受けて、政府及び各団体（国内ではIPAなど）はIoTシステムに対するセキュリティ、セーフティ、リスクマネジメントに対する資料を数多く公開している。

「つながる世界のセーフティ＆セキュリティ設計入門」 [IPA, 2015] では、守るべき対象からセキュリティとセーフティを分類している。概念上重複する部分はあるが、主として人の命、身体、心、モノとしてのシステム/機械、金銭等を保護する対象とするものをセーフティ、主としてデータ、ソフトウェア、品質等を保護する対象とするものがセキュリティと定義されている。このとき、セキュリティの不備によって引き起こされたハザードが引き金（要因）となり、セーフティを侵す事故につながることに特に注意すべきである。1つのデバイスの脆弱性がM2M（デバイス同士の通信）や、エッジデバイスを侵食する危険性をもつIoTシステムにおいては、まさにセキュリティは最大限の関心を払うべき品質の属性と言える。
ウェブをはじめとするソフトウェアセキュリティに関する啓蒙を目的とし世界中にチャプター（支部）を持つNPO団体OWASP（オープンソースコミュニティ）では、「Internet of Things Top Ten」として、IoTシステムに想定される10の脆弱性につながる要素を発表している。

図5. において、いくつかの要素は一般のクラウドサービスにも当てはまる (4 Lack of Transport Encryption等) が、特にIoTデバイスにおいては、7, 8, 9 ,10 に注目したい。想定される脆弱性としては、モバイルインターフェースによる伝送経路が安全でない状態での認証情報の送信、デバイス層におけるパスワードの使いまわし、検証無しのファームウェアアップデート、フラッシュメモリ等、情報を保持しうるデバイスへの容易な物理アクセスなど、が挙げられる。また、このような脆弱性に対して開発者は具体的にどのような対策を採ればよいのか？という問いに対し、アンサードキュメントが「OWASP Top 10 Proactive Controls」として毎年発表されている。2018年度のTop 10を見てみよう（図６）。

各種モバイル、ウェブ開発のSDK/フレームワークにおけるセキュアコーディングガイドラインにも通じるものがあるが、それを前提として、挙げられている要素に特別目新しいものは無いように見える。得てして規模が大きくなりやすいIoTシステム開発において、これらのガイドラインがどれぐらい “本当に” 守られているかを計測し、期待値との乖離をコントロールしていくことも、IoTシステムの品質保証において求められていくだろう。

OWASP IoT Projectではさらに、ドラフトではあるが、製造業者、開発者、消費者それぞれに向けたIoTセキュリティの チェックポイントである「IoT Security Guidance」 や、トップ10 それぞれの脆弱性に向けてどんなセキュリティテストを実施すべきかを示す「IoT Testing Guides」 を掲示している。こちらも併せて参照されたい。

セキュアIoTシステム開発プロセスにおけるテストエンジニアの役割

ここからは、実際のIoTシステムの開発プロセスにおいて、テストエンジニアが具体的にどのような役割において、どのような技術を発揮していくべきかを考えてみる。ここではCSA（Cloud Security Alliance）ジャパンの翻訳・公開による「『つながる世界』を破綻させないためのセキュアなIoT製品開発 13のステップ」 (※2) に記載の「セキュアなIoT開発のためのガイダンス」（下記図７）をベースに、施策を適用し易い、いくつかのステップに対して、満たすべき要件をさまざまな開発成果物が充足しているかを「レビューする」、動作する成果物が要件定義、設計段階で想定した通りに実際にふるまうかを「テストする」の２つの観点を取り上げてみたい。なお、後者は単なるテストケースの実行ではなく、テスト要求分析やテスト設計などテストに関するすべてのアクティビティを包含する。

【セキュアな開発手法】

企画されたIoTシステムの開発に着手するにあたり、開発チームは、まずセキュアな開発方法論の構築に取り組む。この策定段階からテストエンジニアには重要な役割がある。特に、掲げられたセキュリティ要件に対し、テストの専門家による技術面、コスト面などからみたテスタビリティが担保されないのであれば、それは確実に絵に描いた餅となる。

• レビューする
  • セキュリティ要件に対し、テスタビリティの観点からレビューする。
  • 想定される物理的な配置、運用に対しシステム保全性の観点からレビューする。
• テストする
  • 脅威モデリングに参加する。
  • 脅威モデリングの一環として、Attack Surfaceそれぞれに対するテストを設計する。

【セキュアな開発環境及びインテグレーション環境】

組み込み、車載などの業界ではソフトウェアを安全に実装するためのコーディングガイドライン、推奨されるツールチェイン等が既に存在する。開発エンジニアがこれらに払う努力を継続的かつ正当に評価するためにも、CIシステムへの静的解析、コーディングスタイルチェッカーなどの組み込みを実現したい。

• レビューする
  • 言語ごとに複数存在するセキュリティガイダンスから最適なものを選ぶ。あるいは選ばれているかをレビューする。
• テストする
  • コーディング規約、選択されたセキュリティガイダンスへの準拠度合いの評価をCIシステムに静的解析の一環として実装する。
  • OSS製品に存在する脆弱性を検出できる機構を構築する。

【プライバシー保護の確立】

プライバシーは、セキュリティが確立した上に構築されるデータの“運用”に関する機能性である。健康、行動、財産等に関する個人データは、特にセンシティブであり、これが製品上でどのように取り扱われるか？を独立性の度合いはあれ、実際に作る人ではない立場からレビューすることが重要になる。また、EUによるGDPR（一般データ保護規則）の施行による大手クラウドベンダーの混乱は記憶に新しい。テストエンジニアは地域ごとの法令、ガイドラインを強く参照しつつも「一人目のユーザ」としての感覚を失わないよう、バランスよくデータの運用を評価する必要がある。

• レビューする
  • GDPR（EU）、HIPAA（米国/ヘルスケア）、OECDプライバシーガイドライン（経済協力開発機構）等、システムの仕様/性能が仕向け先のガイドラインに沿っているかをレビューする。
  • 多くのガイドラインに共通する「必要最小限のデータ送信」が設計時点でどれぐらい遵守されているかをレビューする。⇒最小限の感覚が実装に寄っていないか？
• テストする
  • ユーザのデータが運用上どのように扱われるか。それに不安を覚えないかを、多様なペルソナを想定しながら検証する。

【ハードウェアセキュリティのエンジニアリング】

デバイス層において、ハードウェアの制約から逃れることは難しい。どれだけ厳密にソフトウェアを開発したとしても、ハードウェアが持ち去られ、エッジコンピューティングに送られる前にデータを盗み出されたら（さらにそのデータの暗号化がずさんだったりしたら）目も当てられない。IoTデバイスが、どこでどのように運用されるのかをレビュー/テストすることは、勝手口に鍵をかけるのと同じぐらい重要である。

• レビューする
  • デバイス内部のメモリ/ストレージはどのように保護されるのかをレビューする。
  • デバイスはどのように保守・メンテナンスされるのかをレビューする。
• テストする
  • デバイスへの物理的なアクセスによってデータが取得できるかを検証する。

【データ保護】

ソフトウェアのみで構成されたシステムからみて、前述の物理デバイスと、伝送経路は考慮から漏れやすい。また、「セキュアなIoT開発のためのガイダンス」にも記載のある通り、IoTと今日のインターネットとの決定的な違いは、人間対サービスではなく、マシン対マシン（M2M）通信であることにある。M2Mにおけるデータ通信は、１）特定周期で大量の通信（上り）が発生する、２）データパケット自体は簡素である、３）実際の分析はエッジコンピューティング層以上で行う、といった性質を持つ。特に一定周期での大量の通信に対しては、可用性保持の観点から負荷テストを計画しておく必要があるだろう。

• レビューする
  • IoTデバイス間、IoTアーキテクチャ層同士を繋ぐプロトコルの暗号スペックは何で、なぜそれが選ばれているかをレビューする。
• テストする
  • 特にB2Cシステムにおけるデバイスとシステムの間のペアリングの仕様が、どのようなデバイスでも受け付けてしまわないかを検証する。
  • デバイスからのバースト的なデータ流量に対する負荷テストを設計する。

【セキュアな更新機能の提供】

昨今のサービス志向の流れを受け、IoTシステムにおいても、リリース時点でサービスが完成していることは稀である。そのため、システムは断続的にアップデートされていく。クラウドコンピューティング層、エッジコンピューティング層のアップデートは、ほぼクラウドサービスのように（例えばBlue-Green Deployment）考えられるかも知れないが、デバイスはそうはいかない。ファームウェアを安全に更新できる必要がある。

• レビューする
  • ファームウェアはエンドツーエンドで保護されているか？　開発、提供、廃棄のライフサイクル全般にわたって脅威の入り込む余地が無いか？をレビューする。
• テストする
  • ファームウェア更新の権限を検証する。
  • トランザクション、割り込みに着目しながら、アップデートテストを設計する。

【セキュリティレビューの実施】

前述の通り、サービス化したIoTシステムはその事業が継続する限り永続的にアップデートされていく。
また、既存の枠組みにおける新たな脅威、枠組み自体を超える新たな脅威など、驚異の側も進化していく。
よって、IoTシステム開発におけるセキュア開発プロセスそれ自体も、継続的なフィードバックと改善を繰り返す機構を備えていなければならない。

• レビューする
  • セキュリティ要件自体のアップデートサイクル、方式をレビューする。
  • 構築されたセキュア開発プロセス自体を第三者機関にアセスメントしてもらう。
• テストする
  • ―

本節では、冒頭で参照した「セキュアなIoT開発のためのガイダンス」から特に主立ってテストエンジニアが貢献すべきアクションを抽出した。開発プロセスのほとんどのステップにわたり、テストエンジニアに期待される役割が存在する点があることに着目されたい。

IoTとデータ品質

ソフトウェアの品質特性モデルとして著名な ISO/IEC 9126 が、2013年にISO/IEC ISO/IEC 25000 SQuaREシリーズとしてアップデートされた際、「製品品質」、「利用時の品質」に加えて、「データ品質」が定義された（下記図８）。

仮に伝送経路/集積/集計機構としてのIoTシステムに不備がなかったとしても、そのシステムの中を流れるデータ品質に問題があれば、サービス総体としては目的を達成できないことになる。IoTの検証としては、システムに加えて実際にそこを流れるデータ品質特性にも着目していく必要があるだろう。

データ品質の詳細な解説は別記事に譲るとして、ここではデータ品質モデルに挙げられている品質特性の簡単な解説にとどめる。また、IPAは「つながる世界のソフトウェア品質ガイド」(※3) として、データ品質特性を含めて SQuaREシリーズ の品質特性を解説しているので、そちらも参照されたい。

固有のデータ品質特性：

システムが介在しなくても存在、評価できるデータが本来持つ品質特性。紙の書類の回覧でも同様の品質が求められる。例えば、役所に提出する用紙では、年号の正確性、完全性、一貫性などが、アルファベットの頭文字大文字を1つ選択させる、などの制約により保証されている。IoTシステムにおいては、データのバリデーション、データ送出時におけるフォーマッティングなど、仕様のレビュー観点として活用できるだろう。

システム依存のデータ品質特性：

データをシステム上で運用する段になって初めて問われる特性。 これらの特性はシステムの品質特性と深く関連する。可用性、移植性については、システムの品質特性に同名の特性があり、それを保証するアプローチは多くの部分が重複する。唯一回復性についてはシステムの運用時に検討されることが多い内容であるため、注意が必要である。

固有及びシステム依存のデータ品質特性：

前述の二つの側面を併せ持つ特性。例えば「日付データ」などは、年号/日付 の 記述方式といったデータの在り方の側面と、システムで扱われるフォーマットと いう側面の二つの性質を併せ持つ。

「システム依存のデータ品質特性」においては、IoTが本質的にシステムオブシステムズであることから、データが複数のシステムをわたって処理されることが前提となる。固有、システム依存のいずれの性質を持つものであっても、データの生成、加工、蓄積のそれぞれの過程で、データに対する品質指標を定め、それを継続的に計測するような仕組みが必要になるだろう。

終わりに

現在、IoTという用語は、単なるシステムアーキテクチャを超えて、新たな国策、社会システムを考える上での一つのひな型として機能しつつある。無数のハードウェアがソフトウェアを通じてお互いに協調しつつ、社会に対して出力を行うという仕組みに対して、一般的にテストエンジニアだけでなく、ソフトウェアに関わるエンジニアは本能的な恐怖を感じているのではないだろうか。それは未知の出力先に対するものであったり、社会とシステムで累乗される複雑さであったり、未だ見ぬ技術的脅威に対する恐怖である。しかし、テストエンジニアにはもとよりリスクを適切に体系化し、現実的なコストで施策を打ち出し、施策の結果を検証するスキルが備わっている。

社会はさまざまな価値観に基づいて、より良く、より効率的な社会へ、トランジションを果たそうとしている。社会とソフトウェアシステムが歩み寄っていくことは、業務としては恐怖である反面、多くのエンジニアがいつか夢見た未来でもあることだろう。テストエンジニアが主体的に品質技術を発揮していくために、本記事が足がかりの一つになれば幸いである。

• ※1IoTセキュリティガイドライン（METI/経済産業省）
  http://www.meti.go.jp/press/2016/07/20160705002/20160705002.html
• ※2CSA ジャパン プレスリリース
  https://www.cloudsecurityalliance.jp/newsite/?p=2872
• ※3つながる世界のソフトウェア品質ガイド ～あたらしい価値提供のための品質モデル活用のすすめ～
  IPA 独立行政法人 情報処理推進機構： https://www.ipa.go.jp/sec/publish/20150529.html

テストエンジニアから見た構造物としての「IoT」とそのテストにおけるアプローチの考察【前編】

この記事をシェアする