　連載1回目では欧州でWi-Fi、Bluetoothをはじめとした、無線を利用するIoT（モノのインターネット）機器販売に必要な認証制度「Radio Equipment Directive（RED）」の改正を取り上げた。そして、その整合規格がまだ確定したものではないことも解説した。連載2回目では、REDの整合規格がまだ決まっていない中、設計開発チームは“ごく基本的なサイバーセキュリティ要求事項”である「ETSI EN 303 645」に対応しておくことが重要だと解説した。

　連載3回目の本稿では、開発しているIoT機器をどのようにETSI EN 303 645規格に適合させるべきかを解説する。機器の開発には大きく分けて2つのケースがあると思われる。まっさらな新機種を開発する場合と、既存機種を改良する場合である。両者間においてセキュアな製品開発に求められるアプローチは大きく異なるため、それぞれのケースを解説する。

セキュリティの定義が曖昧なまま進む開発

　まずは完全な新機種を開発する場合である。このようなケースの場合は、まずETSI 303 645で要求されている機能を熟知して、それらを漏れなく実装するというアプローチをとるのが最善といえる。製造業の開発現場では当たり前のことだと思われるが、新しい製品を開発するに当たっては、機器に求められる機能やスペックをある程度文書化するだろう。

　例えばテレビであれば画面のサイズ、受信できる放送の種類（地デジ、CS、BS、4Kなど）、HDMI端子の数、サポートするVOD（ビデオ・オン・デマンド）の種類などは、当然開発が本格化する前にはある程度検討が終わり、スペックが確定しているはずだ。一方でMFP（マルチファンクションプリンタ）の場合であれば1秒間の印刷枚数、インクカートリッジの容量、動作電圧、動作温度／湿度、サポートするOSの種類などをある程度確定させてから開発が始まる。

開発コンセプトの中に「サイバーセキュリティ」を考慮することが大切出所：テュフラインランドジャパン

　しかしながら、サイバーセキュリティについては「すべきこと」と「してはいけないこと」がきちんと定義されないまま、開発が進んでいるケースがほとんどではないだろうか。サイバーセキュリティスペックを明確にしないまま、開発が始まってしまうので、当然ながら脅威に対して脆弱（ぜいじゃく）な機器が出来上がってしまうのである。まずは製品開発の指針となる「セキュア開発ガイドライン」を作成したうえで、本格的な開発に取り組むことが大切になる。このガイドラインは、機器開発の一部、もしくは全部を委託する際にも重要な役割を果たす。

　だが、スマートフォンのアプリやクラウドとの接続などに関わる部分はパートナー企業に外注しているケースも多いだろう。そのような場合に、サイバーセキュリティ上の要求事項が提示されていないと、脆弱性を抱えたソフトウェアが納品される可能性が高くなるし、納品後にETSI 303 645への対応を要求した場合、追加料金が要求されることも考えられる。

　何よりも脆弱性の修正に余計な時間がかかってしまうことで、新製品の発売が遅れてしまうリスクもある。セキュア開発ガイドラインを制定していれば、RFP（提案依頼書）の要求事項の一部として活用することも可能になる。このため、サプライチェーン全体で機器のサイバーセキュリティを担保することができるようになる。

「健康診断」でセキュリティの問題をチェック

　　　　　　 1|2 次のページへ