JC-STAR ★1のセキュリティ要件について

はじめに

三菱電機 情報技術総合研究所では、IoT機器を応答機能に設置した「IoT家電ハニーポット」を運用しており、IoT家電を標的としたサイバー攻撃を観測しています（参考記事1、参考記事2）。

この記事では、IoT機器のセキュリティの1つの基準として、セキュリティ要件適合評価及びラベリング制度（JC-STAR: Labeling scheme based on Japan Cyber-Security Technical Assessment Requirements）のセキュリティ要件を確認し、よく報告されるサイバー攻撃に対するセキュリティ対策がカバーされていることを確認します。

JC-STARとは

JC-STARは、IoT製品が所定のセキュリティ水準に適合していることを確認・可視化する制度です。ルーターやネットワークカメラなど、家庭で広く使われているIoT機器も対象に含まれています。適合水準を満たす製品には、二次元バーコード付き適合ラベルが付与されるため、消費者がIoT機器を購入する際に、製品情報を確認しやすく、適切なセキュリティ対策がなされたものを選択しやすくなることが期待できます。

セキュリティ水準として、最低限の脅威に対応するための製品共通の適合基準・評価手順（★1）と、IoT製品類型ごとの特徴に応じた適合基準・評価手順（★2～★4）という4段階の要件レベルが設定されています。★3と★4は、重要インフラ等での利用を想定した機器が対象なので、一般の消費者が家庭用のIoT機器を選ぶシーンにおいては、★1（製品共通）と★2（製品類型ごと）で求められるセキュリティ要件がポイントになります。

2025年3月現在、★1の申請受付開始が2025年3月下旬に予定されており、★2以上については2026年以降の開始が計画されています。以下では、既に公開されている★1適合基準において求められるセキュリティ要件を確認します。

★1適合基準

★1には以下に示す16個の適合基準があります。
（イメージしやすいように丸めた書き方をしています。公開されている適合基準通りの文言ではありませんので、ご注意ください）

適合基準番号	セキュリティ要件の概要
S1.1-01	アクセス制御
S1.1-02	推測困難なデフォルトパスワード
S1.1-03	認証値を変更可能
S1.1-04	総当たり攻撃対策
S1.1-05	脆弱性開示ポリシーの公開
S1.1-06	ソフトウェアのアップデート機能
S1.1-07	簡単なアップデート手順
S1.1-08	ソフトウェアの完全性
S1.1-09	アップデートの適時性
S1.1-10	製品型番の確認方法
S1.1-11	セキュアな保存
S1.1-12	セキュアな通信
S1.1-13	攻撃面の最小化
S1.1-14	電源OFFに対するレジリエンス
S1.1-15	ユーザデータの消去機能
S1.1-16	製品に関する情報提供

やや馴染みが薄いと思われるものについて補足します。

S1.1-13（攻撃面の最小化）の攻撃面とは、アタックサーフェス（attack surface）とも呼ばれ、IoT機器への攻撃の口になりうるインターフェースなどを指します。それを最小化するということは、攻撃の口を減らすということです。たとえば、IoT機器でTelnetが動作していて攻撃に悪用される事例がたびたび報告されます。多くの場合、IoT機器の利用者に対してTelnet機能を提供する意図は無く、開発時に利用していたTelnetを無効化せずに出荷してしまったものと思われます。このように攻撃面になりうる不要な機能は無効化する必要があります。

S1.1-14（電源OFFに対するレジリエンス）は、IoT機器の電源がOFFになっても、再び起動した時に電源OFF前の状態に戻ることを意味します。S1.1-03やS1.1-06とも関連しており、設定した認証値やアップデートしたソフトウェアなどのセキュリティ対策が、電源OFFをしても保持されることを保証するための要件です。

S1.1-15（ユーザデータの消去機能）は、IoT製品の利用時ではなく、手放した後のリスクを想定したセキュリティ要件です。廃棄や売却、賃貸住宅からの退去などで、ユーザデータが残ったままのIoT機器が他人の手に渡ると、情報漏えいのリスクがあります。実際、IoT機器ではありませんが、中古のHDD（ハードディスクドライブ）から情報漏えいする事例はたびたび報告されています。このようなリスクを抑えるため、ユーザデータを消去する機能は不可欠です。

★1適合基準は、製品共通のセキュリティ要件であり、世の中でよく報告されるIoT機器に対するサイバー攻撃への対策となっていることが期待されます。そこで、サイバー攻撃の動向との対応関係を確認します。

サイバー攻撃の動向

公的機関や非営利団体が発行しているサイバー攻撃に関する報告書として、インターネットで観測される攻撃傾向を報告するもの（NICTによるNICTER観測レポートやJPCERT/CCによるインターネット定点観測レポート）や、インシデントの社会的な影響に注目するもの（IPAによる情報セキュリティ10大脅威やJNSAによるJNSAセキュリティ十大ニュース）があります。

ここでは、セキュリティ要件とサイバー攻撃の対応関係を確認するため、NICTER観測レポートを参照します。NICTER観測レポートで報告されている事例が、世の中のサイバー攻撃の全てではありませんが、大局的な攻撃傾向を捉えたものとしては最も信頼できるものの1つです。

2020年～2024年のNICTER観測レポートで報告されている主な分析事例と、それぞれで悪用された主な脆弱性を以下に整理します。

年号	分析事例	主な脆弱性
2020～2024	Mirai感染ホスト数の推移	Telnet、簡単なデフォルトパスワード、その他
2020	ADB1が有効な機器の感染事例	デバッグポート
2020	ブロードバンドルータ	その他
2021	ブロードバンドルータ	その他
2021	DVR	バックドア
2022	海外製DVR/NVR製品の脆弱性	バックドア
2023	LTEルータ	Web管理画面、Telnet、簡単なデフォルトパスワード、その他
2023～2024	InfectedSlursの感染活動	簡単なデフォルトパスワード
2024	IoTボット感染ホスト数の推移	Telnet、簡単なデフォルトパスワード
2024	RapperBotの観測事例	その他

MiraiはルータやネットワークカメラなどのIoT機器に感染するマルウェアで、 2016年に大流行しました。その後も、感染ホスト数は減少傾向にあるものの、未だに活動が続いています。NICTER観測レポートにおいても、継続的に感染ホスト数の推移が報告されている、影響力の大きいマルウェアです。

Miraiの感染拡大における最も重大な脆弱性は、Telnetが動作していることと、簡単なデフォルトパスワードで侵入できてしまうことだと考えられます。また、Mirai以外にも、Telnetや簡単なデフォルトパスワードが攻撃に利用される事例が多いことが分かります。

多くのIoT製品において、Telnetは製品本来の機能として求められるものではないと思います。そのような、製品の利用者にとって不要な機能が攻撃に利用されるケースは多く、上表のデバッグポートやバックドアもそれに該当します。

LTEルータの事例では、Web管理画面がインターネットからアクセスされ、攻撃に利用されています。Web管理画面そのものはLTEルータの所有者が利用するための正規の機能ですが、デフォルトでインターネット側のポートからアクセス可能とする必要性は低いと考えられます。その意味で、これも不要な機能が攻撃に利用されたケースと言えるでしょう。

上表では、Telnetなどのよくある脆弱性とは異なる、ソフトウェア個別の脆弱性を「その他」と記載しています。Telnetのような分かりやすい脆弱性以外にも、様々なソフトウェアの脆弱性がサイバー攻撃に悪用されています。ベンダーには、開発プロセスにおいて脆弱性を作り込まないための取り組みに加えて、脆弱性が発見された場合の適切な対応も求められます。

脆弱性と★1適合基準の対応

上述のサイバー攻撃で悪用されている脆弱性と、★1適合基準の対応を整理します。

脆弱性	適合基準	説明
簡単なデフォルトパスワード	S1.1-02 S1.1-03	デフォルトのパスワードは機器固有の推測困難なものとし、また、変更できるようにする。
Telnet、デバッグポート、バックドア	S1.1-13	不要な機能を無効化する。
Web管理画面	S1.1-13	デフォルトではインターネット側からアクセスできないようにする。
その他	S1.1-05～S1.1-09	脆弱性への対応体制を整えること。ソフトウェアをアップデート可能とし、脆弱性発見時は速やかにセキュリティアップデートを提供すること。

今回参照した2020年～2024年のNICTER観測レポートで報告されている主なサイバー攻撃で悪用されている脆弱性が、JC-STARの★1適合基準のセキュリティ要件によってカバーされていることが分かります。

おわりに

JC-STARは、完全・完璧なセキュリティが確保されていることを保証するものではありませんが、家庭のIoT機器においてよく報告されるサイバー攻撃への主なセキュリティ対策はカバーしていると考えられます。今後、IoT製品の購入時に、セキュリティを付加価値として捉え、安心して使える製品を選択しやすくなることが期待できます。

1. Android Debug Bridge ↩