サービス比較の記事一覧

AIで顧客対応・サポート業務を自動化したい

サービス比較の記事一覧

AIで顧客対応・サポート業務を自動化したい

不正利用・金融トラブルを未然に防ぎたい

脆弱性・セキュリティ診断サービス
の関連情報


関連サービス資料を
無料で一括ダウンロード

IoTセキュリティ評価検証ガイドラインとは?CCDSの評価・検証プロセスと試験項目・JC-STARとの関係を解説

IoTセキュリティ評価検証ガイドラインとはのサムネイル画像
脆弱性・セキュリティ診断サービス比較表(2026年版)のプレビュー

主要19サービスの料金・機能を無料で一覧比較

脆弱性・セキュリティ診断サービス比較表(2026年版)

IoT機器を開発・出荷していると、リリース前に「セキュリティはきちんと評価したのか」を社内や取引先から問われる場面が増えてきました。Webサービスと違い、ハードウェアやファームウェア、無線通信まで含むIoT製品は、どこを・どの手順で確かめればよいのかが見えにくく、拠り所になる評価の進め方を探している担当者は少なくありません。

その手がかりとして名前が挙がるのが「IoTセキュリティ評価検証ガイドライン」です。一般社団法人 重要生活機器連携セキュリティ協議会(CCDS)が2017年に公開した文書で、IoT機器のセキュリティを評価・検証するプロセスを、計画の立て方から実行・報告まで体系立てて整理しています。ただ、本体がPDFの技術文書であるため、中身に何が書かれているのか、どこから入手できるのかが掴みにくいのも事実です。

本記事では、このガイドラインの正体と入手先を結論から示したうえで、評価検証プロセスの全体像、自社製品でチェックすべき試験項目(OWASP IoT Top 10・ETSI EN 303 645・電気通信事業法の技術基準)、そしてIPAの適合性評価制度「JC-STAR」をはじめとする関連制度・規格との使い分けまでを整理します。

あわせて、自前の評価と第三者への委託をどう線引きするか、IoT機器・ハードウェアも診断できるセキュリティ診断サービスの選択肢についても解説します。

脆弱性・セキュリティ診断サービスの関連サービス資料
PR
本セクションにはプロモーションが含まれており、表示順は当社独自の基準や提携状況に基づいています。

IoTセキュリティ評価検証ガイドラインとは

IoTセキュリティ評価検証ガイドラインとは、一般社団法人 重要生活機器連携セキュリティ協議会(CCDS)が2017年に策定した、IoT機器のセキュリティ評価・検証の進め方を体系的にまとめた文書です。評価検証をどう計画し、どんな手法・ツールで、何を試験し、結果をどう記録・報告するかという一連のプロセスを示しています。

IoT セキュリティ評価検証ガイドライン Rev1.0
一般社団法人 重要生活機器連携セキュリティ協議会
2017 年 6 月 30 日

出典:IoT セキュリティ評価検証ガイドライン Rev1.0|一般社団法人 重要生活機器連携セキュリティ協議会(CCDS)

このガイドラインは、総務省の「身近なIoTプロジェクト」でスマートホーム分野の実証事業として整備されたものが前身です。当初の「スマートホーム分野セキュリティ検証ガイドライン」から現在の名称へ変更された経緯があります。実証の事例としてスマートホームを扱っていますが、文書自体は広くIoT機器全般に活用できることを念頭に作られています。

出典・参考資料(1件)

位置づけとしては、法的な強制力を持つ規制ではなく、業界団体が開発者・評価担当者向けに示す任意のガイドラインです。評価検証計画書の記載要件は、ソフトウェアテストの国際標準であるISO/IEC/IEEE 29119を参考に作られています。

読み手として想定しているのは、設計者・開発者だけでなく、評価検証を担うテストエンジニアや、予算・人員を決める意思決定者まで幅広い層です。品質保証(QA)の視点でセキュリティ評価を進めたい担当者にとって、具体的な作業に落とし込みやすい構成になっている点が特徴といえます。

公開されているのは2017年のRev1.0で、本記事執筆時点でもこの版が参照されています。IoTを取り巻く技術や脅威は変化しているため、評価検証の進め方(プロセス)の骨格はこのガイドラインで押さえるとよいでしょう。個別の試験項目は、後述するOWASP IoT Top 10やETSI EN 303 645、2025年に始まったJC-STARといった新しい基準・制度で補うのが実務的です。

現物は、CCDSの公式サイトからPDFで入手できます。本記事で解説する内容は要点の抜粋であるため、自社の評価に実際に適用する際は、下記の原典を確認してください。

出典・参考資料(1件)

評価検証プロセスの全体像

ここからは、ガイドラインが示す評価検証プロセスの骨格を、作業の流れに沿って見ていきます。ガイドラインは、場当たり的に脆弱性を探すのではなく、計画を立ててから実行し、結果を記録・報告するまでを一続きのプロセスとして定義しています。

文書の章立てに沿うと、評価検証は大きく次の流れで進みます。

IoTセキュリティ評価検証ガイドラインが示す評価検証プロセスの5段階を左から右への流れで示した図。STEP1 方針・計画策定、STEP2 評価検証設計、STEP3 評価検証実行、STEP4 報告・完了、STEP5 総括・フィードバック。
  1. 方針・計画策定:製品ライフサイクルのどこで評価検証を行うかを位置づけ、対象範囲・体制・スケジュールといった評価の方針と計画を定めます。
  2. 評価検証設計:製品開発ライフサイクルと関連するセキュリティ対策を踏まえ、静的検証手法・動的検証手法を選び、評価検証仕様書を作成してツールを選定します。あわせて手順書を整え、検証に使うデータを準備します。
  3. 評価検証実行:設計した仕様・手順に沿って評価検証を実施します。検出されたインシデント情報は、レポートフロー・記載項目・深刻度基準に沿って管理します。
  4. 報告・完了:評価検証の実施状況を報告し、どの項目をどう検証し何が見つかったかをまとめた完了報告を作成します。この記録が、評価を実施したことの証跡になります。
  5. 総括・フィードバック:プロジェクトを振り返り、次の評価検証に活かします。

この流れのうち、特に設計段階で選ぶ「静的検証手法」と「動的検証手法」の2本立てが、後述する試験項目や自前・外部委託の線引きにつながります。静的検証は、ソースコードや設計を動かさずに確認する手法、動的検証は、実際に機器を動かして確認する手法です。

出典・参考資料(1件)

評価検証で使う主なツール(静的検証・脆弱性スキャン・ペネトレーション・ファジング)

ガイドラインの付録(Appendix1)では、評価検証で使うツールを4つの区分で一覧にしています。各区分には代表的なツール名も具体的に挙げられているため、手を動かす段階で、どの種類のツールを使うのかを把握する手がかりになります。

  • 静的脆弱性検証ツール:ソースコードを動かさずに脆弱性の兆候を調べるツール(静的検証)。
  • 脆弱性スキャンツール:既知の脆弱性の有無を機械的に調べるツール。
  • ペネトレーションツール:攻撃者の視点で侵入可否を試すためのツール(動的検証)。
  • ファジングツール:想定外のデータを大量に送り込み、異常時の挙動を調べるツール(動的検証)。

検出した脆弱性のリスクを評価する手法として、付録ではCVSS v3やNIST SP 800-30などのリスク評価手法(脆弱性の深刻度を点数化する手法)も紹介されています。どのツールで何を確かめるかは、次に見る試験項目と対応づけて考えると整理しやすくなります。

出典・参考資料(1件)

自社製品で何を評価・検証するか(試験項目一覧)

ここからは、自社のIoT製品で具体的に何を評価・検証すればよいかを確認します。CCDSのガイドラインは評価の「進め方」を体系化したもので、個別にどんな項目を見るかは、ここで挙げるOWASP IoT Top 10やETSI EN 303 645、電気通信事業法の技術基準といった国際的な観点・国内の基準を当てはめて設計します。

評価の抜け漏れを防ぐため、代表的なものだけでなく全体を把握しておくことをおすすめします。

OWASP IoT Top 10(IoT機器の代表的なリスク)

OWASP IoT Top 10は、国際的なセキュリティコミュニティOWASPが公開する、IoT機器で特に注意すべき代表的なリスク10項目です。最新版は2018年版で、設計・開発時の観点として広く参照されています。項目名は原典の英語表記が正式なものであるため、英語と内容を併記します。

No.項目(OWASP原文)内容(何を確認するか)
1Weak, Guessable, or Hardcoded Passwords推測されやすい・固定の初期パスワードを使っていないか
2Insecure Network Services不要・安全でないネットワークサービスが動いていないか
3Insecure Ecosystem InterfacesWebやクラウド、モバイル連携など外部接点が安全か
4Lack of Secure Update Mechanism安全なソフトウェア更新の仕組みがあるか
5Use of Insecure or Outdated Components安全でない・古い部品やライブラリを使っていないか
6Insufficient Privacy Protectionプライバシー情報の保護が十分か
7Insecure Data Transfer and Storageデータの通信・保存が安全に行われているか
8Lack of Device Management機器の管理(監視・更新・廃棄)の仕組みがあるか
9Insecure Default Settings初期設定が安全な状態になっているか
10Lack of Physical Hardening物理的な堅牢化(分解・改ざん対策)がされているか
出典・参考資料(1件)

ETSI EN 303 645(消費者向けIoTの基本要件)

ETSI EN 303 645は、欧州電気通信標準化機構(ETSI)が2020年に発行した、消費者向けIoT機器のサイバーセキュリティ基本要件を定めた国際規格です。ネットワークに接続する消費者向けIoT機器と、その関連サービスとのやり取りについて、守るべきセキュリティとデータ保護の基本的な事項を示しています。後述するJC-STARや海外のラベリング制度でも参照される、国際的な土台となる規格です。

この規格は、第5章で次の13の要件領域を定めています(項目名は原典の英語表記)。

  • No universal default passwords(共通の初期パスワードを使わない)
  • Implement a means to manage reports of vulnerabilities(脆弱性の報告を受け付ける手段を設ける)
  • Keep software updated(ソフトウェアを更新できるようにする)
  • Securely store sensitive security parameters(重要なセキュリティパラメータを安全に保管する)
  • Communicate securely(通信を安全に行う)
  • Minimize exposed attack surfaces(攻撃対象となる面を最小化する)
  • Ensure software integrity(ソフトウェアの完全性を担保する)
  • Ensure that personal data is secure(個人データを安全に扱う)
  • Make systems resilient to outages(障害・停止への耐性を持たせる)
  • Examine system telemetry data(システムのテレメトリデータを点検する)
  • Make it easy for users to delete user data(利用者が自分のデータを簡単に削除できるようにする)
  • Make installation and maintenance of devices easy(機器の設置・保守を容易にする)
  • Validate input data(入力データを検証する)
出典・参考資料(1件)

電気通信事業法の技術基準(端末設備等規則)

国内では、インターネットに接続するIoT機器の一部が、電気通信事業法に基づく技術基準の対象になります。端末設備等規則(昭和60年郵政省令第31号)第34条の10では、インターネットプロトコルを使用する専用通信回線設備等端末が満たすべき機能として、主に次の要件を定めています。

  • アクセス制御機能(第1号):設定の変更にアクセス制御機能を備えること。
  • 初期パスワードの変更など(第2号):あらかじめ設定された識別符号の変更を促す機能を持つか、機器ごとに異なる識別符号を付すなどの措置を講じること。
  • ソフトウェアの更新(第3号):電気通信の機能に係るソフトウェアを更新できること。
  • 電源停止後の維持(第4号):電力の供給が停止した場合でも、アクセス制御の設定と更新されたソフトウェアを維持できること。

よく「アクセス制御・初期パスワード変更・ソフトウェア更新の3点」と紹介されますが、条文上は電源停止後の維持を含む構成になっている点に注意してください。自社製品が対象となる端末に該当するかは、総務省の原文で確認することをおすすめします。

出典・参考資料(1件)

これらの試験項目は、先に見た評価検証プロセスの「設計」段階で手法と対応づけます。設定不備や古い部品の確認は静的検証、通信の安全性や想定外入力への耐性はファジングやペネトレーションといった動的検証で確かめる、といった形です。

OWASP IoT Top 10などで挙がるこうした観点が、実際のIoT機器でどんな脆弱性として現れ、過去にどのような被害につながったのかは、代表的な脆弱性6タイプと実被害事例を整理した以下の記事で確認できます。どの弱点から優先して対処すべきかの考え方もまとめているため、評価項目の抜けを点検する際の参考になります。

CCDSガイドライン・JC-STAR・公的ガイド・規格の使い分け

ここまで見てきたように、IoT機器のセキュリティ評価に関わる文書・制度・規格は複数あり、「結局どれを見ればよいのか」が分かりにくくなりがちです。それぞれの発行主体・位置づけ・何に使うかを整理すると、次のようになります。

IoTセキュリティ評価に関わる文書・制度・規格の使い分けを3段で示した図。土台はCCDSのIoTセキュリティ評価検証ガイドラインで進め方を押さえる。その上にOWASP IoT Top 10・ETSI EN 303 645・電気通信事業法の技術基準を試験項目として当てはめる。最後にJC-STARのラベルや第三者評価で結果を証明する。
文書・制度・規格発行主体位置づけ主な用途
IoTセキュリティ評価検証ガイドラインCCDS(業界団体)任意のガイドライン評価・検証の進め方(計画〜実行〜報告)を体系的に押さえる
JC-STAR(セキュリティ要件適合評価及びラベリング制度)IPA(独立行政法人)任意の適合性評価・ラベリング制度製品のセキュリティ水準を★で可視化・ラベル取得する
IoT機器を開発する中小企業向け 製品セキュリティ対策ガイド経済産業省任意のガイド設計・開発段階からのセキュリティ対策の考え方を学ぶ
OWASP IoT Top 10OWASP(国際コミュニティ)任意の参照リスト代表的なリスク観点で評価項目の抜けを点検する
ETSI EN 303 645ETSI(欧州標準化機構)国際規格消費者向けIoTの基本要件に沿って評価する
電気通信事業法の技術基準(端末設備等規則)総務省法令に基づく技術基準対象端末が満たすべき機能要件を満たす

このうち、近年とくに押さえておきたいのがJC-STARです。JC-STARは、IPAが運用する「IoT製品に対するセキュリティ要件適合評価及びラベリング制度」で、2025年3月から運用が始まりました。インターネットと通信できる幅広いIoT製品を対象に、セキュリティ要件への適合を評価してラベルを付与します。

評価レベルは★1〜★4があり、★1はIoT製品共通の最低限の脅威に対応するための基準、★2〜★4は製品類型ごとの特徴に応じた基準です。評価の方式はレベルで分かれ、★1・★2はベンダーが自己評価する自己適合宣言方式、★3以上は独立した第三者評価機関の評価報告書に基づく仕組みになっています。この「自己評価か、第三者評価か」の線引きは、次に述べる自前・外部委託の判断に直結します。

出典・参考資料(1件)

各文書・制度・規格の公式入手先(リンク集)

本記事で挙げた文書・制度・規格の現物(公式ページ・PDF)へのリンクをまとめました。自社での検討や社内共有の際に、原典にあたる出発点として活用してください。

出典・参考資料(6件)
  • IoT セキュリティ評価検証ガイドライン Rev1.0(PDF)|CCDS(リンク)
  • JC-STAR(IoT製品に対するセキュリティ要件適合評価及びラベリング制度)|IPA(リンク)
  • IoT機器を開発する中小企業向け 製品セキュリティ対策ガイド(PDF)|経済産業省(リンク)
  • OWASP Internet of Things Top 10 — 2018(PDF)|OWASP(リンク)
  • ETSI EN 303 645 V2.1.1(PDF)|ETSI(リンク)
  • 端末設備等規則 第三十四条の十|e-Gov法令検索(リンク)

評価検証は自前か外部委託か(線引きと判断の観点)

評価検証の全体像と試験項目が見えてくると、次に迷うのが「どこまで自社で行い、何を外部に頼むか」です。すべてを自前で抱え込む必要はなく、工程の性質に応じて分担するのが現実的です。

目安として、設計レビューや静的検証のように、仕様や開発情報をもとに自社の知見で進めやすい工程は、内製に向いています。一方、実機を動かして行う動的検証は、専門的な環境や技術が必要になるため、外部委託が向きやすい領域です。

IoTセキュリティ評価を自前で行う工程と外部委託が向く工程の線引きを2列で示した図。社内で進めやすいのは評価方針・計画の策定、設計レビュー、ソースコードの静的検証、OWASP IoT Top 10などでの評価項目の洗い出し。外部委託が向きやすいのは実機への動的検証(ペネトレーション・ファジング)、ハードウェア・ファームウェア解析、JC-STAR★3以上で求められる第三者評価。
  • 社内で進めやすい工程:評価方針・計画の策定、設計レビュー、ソースコードを対象とした静的検証、OWASP IoT Top 10などを使った評価項目の洗い出し。
  • 外部委託が向きやすい工程:実機に対するペネトレーションテストやファジングといった動的検証、ハードウェア・ファームウェアの解析、JC-STARの★3以上で求められる第三者評価。

内製と外部委託のどちらを選ぶ場合でも、工程の切り分けだけでは判断しきれない面があります。IoT機器や医療機器のセキュリティ診断にも対応するHi AUDIT(株式会社TECHFUND)の生田氏は、社内でツールを運用する場合と監査会社に委託する場合、それぞれで確認すべき点を次のように挙げています。

株式会社TECHFUND セキュリティ監査事業部 事業責任者
生田氏
独自インタビューより

社内でツールを運用する場合、診断を実行するだけでなく、検出結果が実際に悪用可能なのかを見極め、対応の優先順位を決める専門性や工数も必要になります。また、監査会社へ個別に依頼する場合も、診断範囲に加えて、事業固有の仕組みをどこまで理解してくれるか、修正や再確認をどこまで支援してくれるかが重要です。

特に、JC-STARで★3以上のラベルを狙う場合は、制度上、独立した第三者評価機関による評価が前提になります。自社のリソースや目標とする評価レベルに応じて、内製と外部委託の配分を決めるとよいでしょう。次の章では、IoT機器・ハードウェアの評価にも対応できる外部サービスを紹介します。

IoT製品のセキュリティ評価を外部に頼むには

ここからは、IoT機器・組み込み機器・ハードウェアそのものを評価・検証の対象にできるセキュリティ診断サービスを紹介します。動的検証やハードウェア解析など、自社だけでは手の届きにくい工程を補い、JC-STARの取得支援まで対応するサービスもあります。

一口にIoT対応といっても、IoTデバイス専用の診断メニューを持つサービスもあれば、Web・アプリなど幅広い診断の一環としてハードウェアにも対応するサービスもあり、対象の具体性には差があります。自社がどこまでの評価を求めるかに合わせて、下記の比較表で各サービスの対象範囲・手法・JC-STAR対応を見比べてください。

← 横にスクロールできます →
サービス名Hi AUDIT(株式会社TECHFUND)GMOサイバーセキュリティ byイエラエ
評価・診断の対象(IoT機器・ハードウェア対応)Web・アプリ・スマートコントラクト監査が主力。IoT機器や医療機器などハードウェアにも診断対応(TECHFUND申告)「IoTデバイス ペネトレーションテスト」を独立メニュー化。Web・スマホ・クラウド・ネットワーク・NFT/ブロックチェーン・デスクトップ・AIなど幅広く対応
主な試験・診断手法ツールによる自動診断と専門家の手動診断を組み合わせたハイブリッド診断(TECHFUND申告)IoTはハードウェア解析・ソフトウェア解析(ファームウェア逆アセンブル)・動的解析を組み合わせた手動主体の診断
JC-STAR・規格への対応公式に記載なしJC-STAR取得支援サービスを提供
修正・改善まで支援●修正方法の助言から修正後の再確認まで支援(追加料金なしと説明)△報告書に対策方法を記載・報告会は任意。再診断の扱いは公式に記載なし
詳細情報公式資料を見るサービス詳細を見る

Hi AUDIT(株式会社TECHFUND)

Hi AUDITのウェブサイト

Hi AUDITは、株式会社TECHFUNDが提供するセキュリティ診断サービスです。Web3領域のスマートコントラクト監査を主力としつつ、Webサービス・アプリケーションの診断に加えて、IoT機器や医療機器といったハードウェアに対するセキュリティ診断にも対応領域を広げている点が特徴です。

同社が重視するのは、リスクを発見して終わりにしない点です。見つかった脆弱性について、どう直せばよいかの助言から、修正後の再確認までを支援する方針を掲げています。業界ごとに異なるセキュリティ要件に合わせた診断を強みとしており、ハードウェアを含む製品のリスクを洗い出し、改善まで伴走してほしい企業に向いています。

発見後の対応について、生田氏はインタビューで次のように述べています。

株式会社TECHFUND セキュリティ監査事業部 事業責任者
生田氏
独自インタビューより

見つけた脆弱性を放置せず、適切に対応していただくことが重要だと考えていますので、対応が終わるまで並走させていただくのが当社の方針です。多くの会社様から「珍しい」と言われますが、レポートを出して終わりという会社は結構多いのではないでしょうか。当社は、レポートの説明会、ご質問への回答、修正方法のご相談、「直したので見てほしい」というご依頼への対応を、追加料金なしですべて無料で行っています。

GMOサイバーセキュリティ byイエラエ

GMOサイバーセキュリティ byイエラエのウェブサイト

GMOサイバーセキュリティ byイエラエは、国内のホワイトハッカーを多数擁するサイバーセキュリティ専門企業です。手動を主体とした脆弱性診断・ペネトレーションテストを中核に据え、IoT機器向けには「IoTデバイス ペネトレーションテスト」を独立したメニューとして提供しています。

IoTデバイス ペネトレーションテストでは、ハードウェア解析・ソフトウェア解析・動的解析の3つを組み合わせます。基板のデバッグインタフェースなどを調べるハードウェア解析、ファームウェアを逆アセンブルして評価するソフトウェア解析、通信路のパケットキャプチャなどを行う動的解析です。

TLSや無線通信(Wi-Fi・Bluetooth)、セキュアブート、ファームウェアの抽出可否といった観点を評価でき、スマートロックやカメラ、車両部品などの実績が公開されています。さらに、製品セキュリティ対策としてJC-STARの取得支援サービスも用意しているため、ラベル取得まで見据えて相談したい企業にも向いています。

ここで取り上げたのはIoT機器にも対応する診断サービスですが、診断方法(手動・ツール自動・ハイブリッド)や費用相場、選び方まで含めて脆弱性診断サービス全体を比較検討したい場合は、以下の記事で主要サービスを横断的に整理しています。委託先選びの出発点としてあわせてご覧ください。

まとめ

IoTセキュリティ評価検証ガイドラインは、CCDSが2017年に公開した、IoT機器のセキュリティ評価・検証の進め方を体系化した任意のガイドラインです。評価の計画から設計、実行、報告までの流れと、静的検証・動的検証の手法、使うツールまでを押さえられます。

実際の評価では、OWASP IoT Top 10やETSI EN 303 645、電気通信事業法の技術基準といった観点で試験項目の抜けを点検し、2025年に始まったJC-STARをはじめとする制度・規格との使い分けを押さえることが大切です。

そのうえで、動的検証やハードウェア解析、第三者評価といった工程は、IoT機器・ハードウェアに対応したセキュリティ診断サービスへの委託も選択肢になります。自社の評価レベルの目標に合わせて、内製と外部委託を組み合わせていきましょう。

よくある質問(FAQ)

Q. IoTセキュリティ評価検証ガイドラインとは何ですか?

A. IoTセキュリティ評価検証ガイドラインとは、一般社団法人 重要生活機器連携セキュリティ協議会(CCDS)が2017年に策定した、IoT機器のセキュリティ評価・検証の進め方を体系的にまとめた任意のガイドラインです。評価の計画から設計、実行、報告までの一連のプロセスと、静的検証・動的検証の手法、評価検証で使うツールの一覧までを示しています。

法的な強制力を持つ規制ではなく、設計者・開発者・テストエンジニアから予算や人員を決める意思決定者までを読み手に想定した文書です。評価検証計画書の記載要件は、ソフトウェアテストの国際標準ISO/IEC/IEEE 29119を参考に作られています。

出典・参考資料(1件)

Q. IoTセキュリティ評価検証ガイドラインはどこから入手できますか?無料ですか?

A. IoTセキュリティ評価検証ガイドラインは、CCDSの公式サイトからPDFで公開されており、無料で入手できます。正式名称は「IoT セキュリティ評価検証ガイドライン Rev1.0」で、本記事執筆時点ではこのRev1.0が公開されている版です。

本記事の解説は要点の抜粋であるため、自社の評価に実際に適用する際は、下記の原典PDFにあたって確認してください。評価検証計画書や仕様書の実例、検証ツール一覧なども付録として収録されています。

出典・参考資料(1件)

Q. IoT製品のセキュリティ評価は自社で行うべきですか、第三者に委託すべきですか?

A. IoT製品のセキュリティ評価は、評価方針の策定・設計レビュー・静的検証は自社で進めやすく、実機を動かす動的検証やハードウェア解析、第三者評価は外部委託が向くというのが基本的な線引きです。すべてを自前で抱え込む必要はなく、工程の性質に応じて分担するのが現実的です。

ソースコードや設計情報をもとに自社の知見で確認できる工程は内製に向き、専門的な環境や技術が必要なペネトレーションテスト・ファジング・ファームウェア解析は外部委託が向きます。特にJC-STARで★3以上のラベルを狙う場合は、制度上、独立した第三者評価機関による評価が前提になります。

Q. IoT製品にJC-STARのラベル取得は必須ですか?★レベルはどう選べばよいですか?

A. JC-STARは、IPAが2025年3月から運用する任意の適合性評価・ラベリング制度で、取得は義務ではありません。インターネットと通信できる幅広いIoT製品を対象に、セキュリティ要件への適合を評価してラベルを付与します。

評価レベルは★1〜★4があり、★1はIoT製品共通の最低限の脅威に対応する基準、★2〜★4は製品類型ごとの特徴に応じた基準です。評価方式はレベルで分かれ、★1・★2はベンダーの自己適合宣言方式、★3以上は独立した第三者評価機関の評価報告書に基づきます。どのレベルを狙うかは、製品の性質や取引先・市場からの要請に応じて検討します。各レベルの詳細な要件や申請手順は、制度の公式情報で確認してください。

出典・参考資料(1件)

Q. 自社のIoT機器は電気通信事業法の技術基準の対象になりますか?

A. 電気通信事業法の技術基準(端末設備等規則 第34条の10)は、インターネットプロトコルを使用する専用通信回線設備等端末が対象で、該当する機器はアクセス制御や初期パスワード変更などの機能を満たす必要があります。

条文では、アクセス制御機能、あらかじめ設定された識別符号(初期パスワード)の変更を促す措置、電気通信の機能に係るソフトウェアの更新、電源停止後の設定・ソフトウェアの維持、という要件が定められています。自社製品が対象の端末に該当するかは、総務省の原文で確認することをおすすめします。

出典・参考資料(1件)

Q. OWASP IoT Top 10やETSI EN 303 645は、CCDSのガイドラインとどう使い分ければよいですか?

A. CCDSガイドラインが評価・検証の「進め方」を示すのに対し、OWASP IoT Top 10やETSI EN 303 645は「何を見るか」の試験項目・要件を示すもので、両者は補完関係にあります。CCDSガイドラインで評価のプロセスを設計し、その試験項目としてOWASP IoT Top 10やETSI EN 303 645を当てはめる、という使い方が分かりやすいです。

OWASP IoT Top 10はIoT機器で特に注意すべき代表的なリスク10項目、ETSI EN 303 645は消費者向けIoT機器のサイバーセキュリティ基本要件を定めた国際規格で、JC-STARや海外のラベリング制度でも参照されます。

出典・参考資料(2件)

Q. 出荷前に「セキュリティはきちんと評価したのか」と問われたら、何を示せばよいですか?

A. この問いには、CCDSガイドラインに沿って作成した評価検証の計画書・仕様書と、実行結果(検出されたインシデント情報とその対応)の記録を示すことで答えられます。ガイドラインは、計画・設計・実行・報告の各段階で残すべき成果物を定めているため、評価を実施したこと自体を客観的に説明する根拠になります。

さらに客観的な証明が求められる場合は、JC-STARのラベルや、第三者評価機関による評価報告書を取得しておくと、社内・取引先に対してより強い裏づけとして提示できます。

IoTセキュリティ診断サービスの料金・資料を一括チェック

MCB FinTechカタログでは、IoT機器・ハードウェアの評価にも対応する脆弱性・セキュリティ診断サービスの最新資料を無料で一括請求できます。診断対象や手法、JC-STAR対応の有無を比べて、自社に合う委託先を効率的に探せます。

MCB FinTechカタログに掲載しませんか?

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。

監修者

マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト

松嶋真倫

都市銀行にて金融実務を経験後、暗号資産関連スタートアップの創業期に参画し、市場分析・業界調査に従事。2018年にマネックスグループ入社。以降、ビットコインをはじめとするデジタルアセットからマクロ経済環境まで、金融市場を横断した調査・分析および情報発信を担う。FinTech・次世代金融領域のリサーチ統括、各種レポートや書籍の執筆、日本経済新聞など国内主要メディアへのコメント・寄稿、イベント登壇などを行う。2021年3月より現職。
記事内でご紹介している製品・サービスは監修者が選定したものではなく、編集部が独自に選定したものです。
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。

関連記事

新着記事

脆弱性・セキュリティ診断サービス
おすすめの診断サービス