自社IoT製品は安全ですか？～製造事業者が押さえるべき「脆弱性管理」の重要性～

オープンソースに 内在する脆弱性 自社IoT製品は安全ですか？ 製造事業者が押さえるべき 「脆弱性管理」の重要性 IoT機器の製造事業者を中心としてDXやオープンイノ ベーションの活動を推進していく中でOSSの使用は避 けることができません。OSSの脆弱性を悪用したサイ バー攻撃も年々増えてきており、セキュリティに知見のあ るエンジニアが不足する中、セキュリティとはそもそも何 をするべきなのか、誰が担当していくものなのか、限られ た時間のなかでプロセスを効率化する方法を考えてい きたいと思います。

01 増加するIoT機器へのサイバー攻撃 　現状として、IoT機器の基本的なセキュリティ対策がされてい 　近年のソフトウェア開発においては、 　対応策としてSBOM（Software Bill of Materials）と呼ばれ ないというケースが散見されます。IoT機器すべてに管理が行き ① 自社で独自に作ったもの るソフトウェア部品表を活用した脆弱性の管理が有効です。 届きにくいこと、またインターネットに繋がるという意識が低い ② 外部委託業者などに依頼して作ったもの 脆弱性が含まれるソフトウェアを使用していると、被害の拡大 ことからサイバー攻撃の標的となりやすい傾向があります。 ③ OSSを利用して作ったもの を助長してしまうことにも繋がる可能性があり、SBOMを活用し 実際に2020年にはサイバー攻撃の約4割がIoT機器を対象とし など自社開発以外にも、外部のソフトウェアも多く取り入れて た脆弱性管理をすることでセキュリティに関するリスクを明ら た攻撃となっており、マルウェアに感染したIoT機器が踏み台と います。ソフトウェアの構造が複雑になっている反面、脆弱性の かにすることは重要です。 なって大規模なDDoS攻撃に発展した事例など、障害に繋がる 管理が課題となっています。 ような事例も多々発生しています。 サイバー攻撃の約4割は IoT機器が標的 40% 自社開発 外部委託 OSS 開発元の異なるソフトウェアが組み合わさり 企業のソフトウェアは構造が複雑に… SBOMでソフトウェアの構成要素を可視化 出典： 総務省 令和3年版 情報通信白書, 第2部 基本データと政策動向, 第5節 サイバーセキュリティ対策の推進 脆弱性の管理が重要 セキュリティリスクを明らかに https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/html/nd255210.html

02 各国の製品セキュリティへの対策 　IoT機器へのサイバー攻撃 EUサイバーレジリエンス法 ＜概要＞ が増えている中、各国でも製 　EUサイバーレジリエンス法では、デバイスやネットワークに直接的/間接的に接続さ 品セキュリティに対する対策 　世界的なサイバー攻撃の増加により、対策費用は年間で5.5兆ユーロと れるすべての製品が対象となっており、SBOM作成や更新プログラム提供等セキュリティ を打ち出しています。ここでは も推定されており、対策のために主要課題への対応が急務とされています。 要件への適合が求められています。 主要なものとして、EUサイ ①低レベルのサイバーセキュリティや脆弱性の蔓延に対処するための 　適合性評価では製品ごとにクラス分けがされており、それぞれで自己適合宣言または 　セキュリティアップデートが不十分。 第三者認証が求められています。適合性評価の証明書として、CEマークやEUCC証明書 バーレジリエンス法と米国大 ②ユーザが適切にセキュリティ対策を備えた製品を選択できていない。 が用いられます。脆弱性の悪用やインシデントを発見した場合には、24時間以内に 統領令をご紹介します。 ③サイバーインシデントが組織全体・サプライチェーン全体に短時間で ENISAへの報告が義務化されており、必須要件、適合性評価、製造者の報告義務に違 　それぞれの規制に共通す 　多大な影響を与えており、デジタル製品がEU市場全体で使用される 反した場合には最高1,500万ユーロまたは当該企業の全世界売上高の2.5％以内のど る点は、ソフトウェアの脆弱 　ため、国境を越えた対策が必須。 ちらか高い方という罰金が科されることもあります。 性管理に関するセキュリティ 対策の記載がされているとい うことです。 米国大統領令 ＜概要＞ 　米国大統領令では、「ソフトウェアサプライチェーンのセキュリティ強化」として、NISTを通じて政府が調 ①官民での脅威情報の共有や、ソフトウェアサプライ 達するソフトウェアの開発に関するセキュリティ基準としてSBOMの開示などが求められています。 　チェーンのセキュリティ対策の強化に向けた対策 　ソフトウェアサプライチェーンの確保に向けてはNISTなどを中心として、ガイドラインの策定も指示されて ②NISTなどを中心として、ガイドラインやガイダンスの おり、整備が進んでいます。さらに、権限昇格機能やネットワークへのアクセス権限をもつものに関しては、 　整備を行っている 重要なソフトウェアとして位置づけられ、すべてのソフトウェアを特定して管理することも求められています。 　こういった世界の動向もあり、日本企業においてもグローバルな市場で競争力 セキュリティセンター（NISC）から出された、サイバーセキュリティ2022でもOSSの を維持していくためにはソフトウェアの脆弱性管理に関わるSBOMの管理および コミュニティの活性化や、SBOM整理を実施すること、ツール整備を行うことに関し 提供へ対応していくことが必要となります。 て記載があり、SBOMの普及に向けたモデル構築が検討されています。医療機器 　日本国内でも、ソフトウェアの脆弱性管理に向けた動きがあり、内閣サイバー 分野においても国内でSBOM提供を義務化する動きがあります。

03 押さえるべき脆弱性管理のポイント（1） 各企業が対応していくべき事項 　開発プロセスは大きく分けて、製品開発段階とリリース後の運用段階 　またファームウェアの更新方法に関しても色 と々制限があり、遠隔更新 の二段階に分けられます。近年の動向から、IoT機器に対する攻撃が非常 機能が搭載されていない既存商品、もしくは、機器自体のスペック制限で 　DXやオープンイノベーションを進めて に増えています。Webアプリケーション、携帯アプリケーションであれば、 更新機能が搭載できないケースや、エンドユーザの都合でファームウェア いく中で、OSSの使用は避けられないと 脆弱性問題が発生した場合、すぐに修正パッチをリリースし、アップデー 更新自体ができないケースなど多々あります。これらを考慮すると、製品リ いう現状もあり、各企業が対応していか トすることで問題を解決できます。しかし、Webサービスと違いIoT機器の リース後の継続対応も開発プロセスの一環として認識すべきだと考えて なければならないこととして、ソフトウェア ライフサイクルは5年もしくは10年と非常に長いスパンです。 います。 の脆弱性管理は重要性を増しています。 　OSS利用に関する課題として、 セキュアな開発プロセス 1. 利用するOSSに脆弱性が内在している 可能性がある 製品開発段階 運用段階 2. ソフトウェアベンダーから受領した モノの把握が必要 3. リリース後の継続した脆弱性管理の 計画・設計 実装 ビルド テスト リリース 配置 運用 体制が整えられていない 脅威分析 セキュア実装 静的解析 動的解析 コードサイニング 初期設定 脆弱性診断 ということが挙げられます。 セキュリティ セキュア設定 ソフトウェア ペンテスト セキュアな配布 導入ガイダンス 脆弱性検証&対応 　では次に、IoT機器における脆弱性管 要件の検討 資産把握 パッチ対応 理のポイントを見ていきましょう。 OSS利用検討 脆弱性報告 製品開発工程 製品市場利用

04 押さえるべき脆弱性管理のポイント（2） 　近年、製品開発工程においてシフトレフ 　製品の開発段階では、様々な開発工程にセキュリティが絡んでいます。 　そして、製品リリース後も、定期的に脆弱性診断を実施したり、発見さ トという概念があり、脆弱性問題は早い段 例えば、設計段階の脅威分析、セキュリティ要件検討、open sourceの利 れた脆弱性の検証と対応が必要です。自社製品の脆弱性に対応するた 階で解決した方がコストが抑えられること 用検討、実装段階では、セキュアな実装・設定、ビルド段階の静的解析、 めに、パッチをリリースしたり、脆弱性報告を実施する必要もあるのです。 から、より早い段階でセキュリティを考慮 ソフトウェア資産の把握等、テスト段階では動的解析、ペンテスト等の開 　自社のIoT製品の出荷前にこれらの開発工程を検討しましたか？ した仕様の検討やテストを実施する動き 発工程があります。 　また出荷後、脆弱性情報の収集は実施していますか？ があります。 　製品がリリースされた後も、運用段階に セキュアな開発プロセス 入ったところで製品の脆弱性問題が発見 されるケースが多々あるからです。このこと 製品開発段階 運用段階 から、自社製品の脆弱性情報の継続監視 が必要だと考えています。 計画・設計 実装 ビルド テスト リリース 配置 運用 製品開発工程 製品市場利用 シフトレフト 早い段階から脆弱性に対処 脆弱性の 継続監視

05 押さえるべき脆弱性管理のポイント（3） 　では次に、国内外のセキュリティ動向を踏まえて近年世界中で重要視されいる、製品開発段階の 　現在のIoT機器開発では、ソフトウェアを1社で作り上げるのはほぼ不可能でどこかに外部の ソフトウェア資産の把握と製品リリース後の脆弱性情報収集について説明します。みなさんはソフト ソースコードを取り入れる必要があります。自社で書いたコードはもちろん、外部のソースコードを ウェア資産の分類について考えたことがありますか？ 利用する以上、セキュリティの観点で安全性を確認しなければなりません。 　ファームウェアは「誰がコードを書いたのか」という観点で分類をすると、以下の3種類になります。 　そこで、近年問題視されているのがオープンソースです。開発工数を節約できるという利点から、 オープンソースの利用は非常に有効だと考えます。世界中の優秀なエンジニアが無償で高品質な ソースコードを提供しているので、最近では9割以上のソフトウェアにオープンソースが使用されて います。しかしその反面、オープンソースに対する研究や、攻撃が急増しているのも事実です。 　自社IoT機器を開発する際に、セキュリティの視点で外部のソースコードに対しても確認を行う ことができていますか？ 　安全にオープンソースを利用するには、計画・設計段階で、オープンソースの利用検討を実施す べきだと考えています。製品開発段階において、もし利用予定のオープンソースがあれば、早い段 階でオープンソースの情報を把握することを強くおすすめします。 1st party code 3rd party code Open source 自社開発のソースコード。 外部購入したソフトウェア、 インターネットから自由に ライブラリ等、またはソフト 入手可能なソースコード。 ウェアベンダーに開発を依 頼したモノ。

06 OSSの選定ポイント 利用するOSSのバージョンを 　オープンソースを利用する場合、これら3つの懸念点に注意 ソフトウェア資産を把握することが出来れば… Q1 確認しましたか？ してください。左記のポイントに注意すれば、万が一脆弱性が 攻撃者が作成したバージョンの 発見されても、素早く修正パッチがリリースされ、問題を最小限 OSSの脆弱性が公開された場合、自社製品へ 可能性はないですか？ に抑えることができます。IoT機器のメンテナンスには様々な物 の影響度合いがすぐに確認できる ▲ OSSの名前と公開websiteの確認 理的課題があること、オープンソース起因の脆弱性はできるだ ▲ Github/GitLab上のfork情報の確認 け減らしておくことが重要です。 外部から受領したソフトウェア・ファームウェア ▲ OSS projectがfundation、もしくは、 の安全性が確認できる 大手企業と提携しているか？ 　計画・設計段階で選定したオープンソースの情報は、実装・ ビルド段階のソフトウェア資産把握に非常に有効です。利用す ソフトウェア部品表の提供に関する規制が厳し Q2 OSSのメンテナンスは十分ですか？ るオープンソースパッケージに脆弱性が含まれていた場合、自 くなり、今後顧客から情報提供の依頼が増え、 ▲ OSSコミュニティにおいて1年以内で 社開発チームとソフトウェアベンダーが影響を受ける可能性が その対応が必要 重要な活動があるか？ あることからも資産の把握は必要であるといえるでしょう。 ▲ OSSの最新版が1年以内のモノか？ ▲ バージョン情報に不安定性を示す文字列、 alpha beta等の文字が含まれていないか？ Q3 コミュニティへ脆弱性を報告する 窓口は公開されていますか？ ▲ 脆弱性報告用の窓口があるか？

07 自社製品の脆弱性情報の収集方法 　自社製品がリリースされた後、製品自体の脆弱性が発見されたり、利用するOSSの脆弱性が公開されたりと 　一般的には、日本メーカーの製品に脆弱性が発見された場合はJPCERTより通知が受け 継続的な情報収集が求められます。 られます。もし世の中のソフトウェアコンポーネントに既知の脆弱性が発見された場合は、自 　ここで、自社製品脆弱性情報の収集方法について、整理しています。 分達でその脆弱性情報を収集し、自社のソフトウェア資産表と照らし合わせて影響がある 一般的には、品質管理部もしくはPSIRT（Product Security Incident Response Team）組織が自社製品の脆 かどうかを判断する必要があります。この場合、自社ソフトウェアの資産情報が整理されてい 弱性情報を収集します。エンドユーザからの不具合情報、民間の研究ラボからの脆弱性指摘が出てきた場合は ないと、エンドユーザからの問い合わせに対し回答できない恐れがあります。 下記の２点に注意することが必要です。 自社製品の脆弱性情報の収集において ポイント1 ポイント2 自社製品に対して、脆弱性情報を収集する 定期的に脆弱性データベースの最新情報 ための対応窓口の設置が必要 を確認し、自社製品への影響を確認 脆弱性情報とスムーズに照合するために SBOMをまとめておく必要がある

08 IoT機器製造事業者が直面する課題と対策方法 01 02 03 オープンソースに ソフトウェアベンダーから 製品リリース後、 脆弱性が内在する可能性 受領したモノの把握 継続的な脆弱性の管理 　この課題は主に、開発チームの課題となります。具体的 　これは主に自社開発チーム及び外注先の課題となります。現 　これは主に品質管理部もしくはPSIRT組織の課題となりま には、オープンソースパッケージがさらに別のオープン 在ほとんどの場合、ソフトウェアベンダーから受領したソフトウェ す。一部開発チームにも関わりがあります。前提として、IoT製 ソースパッケージを参照する場合、これらの脆弱性混入 ア、ライブラリ、コンポーネント等のソフトウェア部品表情報が付 品をリリースした後に脆弱性がみつかることを想定しておく必 の状況を特定するまで時間がかかるという問題です。 随されていません。もしソフトウェアベンダーがオープンソース 要があります。品質管理部、もしくはPSRIT組織で明確な脆弱 　今後世界規模で大きな脆弱性が発見された場合、自 パッケージを使用していた場合、外部から調達したソフトウェ 性情報の受付窓口を開設・運営していますか？　または定期 身が利用する機器に影響があるかどうかを知るために、 ア、ライブラリ、コンポーネントの管理は全くできていない状態で 的にJPCERTもしくはNVDデータベースにアクセスして、自社製 エンドユーザから問い合わせが来るかもしれません。この す。外部から購入したソフトウェアも、外注先に開発を依頼して 品関連の脆弱性情報を収集していますか？　人による脆弱性 問い合わせに対応するためには、ソフトウェア部品表が 受領した成果物もすべては最終的に自社のIoT機器として出荷 情報の収集には限界があります。抜け漏れがないとも言い切 ないと一から調査しなければならず、工数を非常に消耗 されるため、“機器の品質担保にセキュリティの担保も含まれて れません。社内の脆弱性管理体制について、関わる各組織の してしまいます。エンジニアの工数で調べるのが難しい場 いること”を改めて認識しなければなりません。オープンソースの 役割分担をしっかり決めておかないと、IoT機器の脆弱性管理 合はツールの利用が一つの解決策だと考えます。 利用状況も合わせて、現在自社開発チームは「どこまで把握で はうまく回せません。 きている」のかを一度確認してみてください。 対策方法 　この２点を実現するために、人の手で実施する作業を減らし、プロセスの効率化 1. 開発段階でセキュリティ工数を確保し、ソフトウェア資産の把握を実施しましょう。 及び自動化をすることをおすすめします。当然、皆さんの組織体制によって、脆弱性 管理のやり方は一概には言えません。様々な課題を踏まえて、ソフトウェア資産の 2. 製品リリース後も継続的かつ効率的な脆弱性監視体制を整えましょう。 把握及び継続的なIoT機器脆弱性管理機能を持つソリューションをご紹介します。

09 Finite State社のファームウェア診断サービス 　今回紹介するのは、IoT機器に特化した脆弱性管理 　また、IoT機器に特化したソリューションのため、IoT まとめ ソリューションであるFinite State社のファームウェア 機器向けの診断項目が準備されています。多数のCPU 　世界各国ではEUサイバーレジリエンスや米国大統領令など、ソ 診断サービスです。 アーキテクチャ/OS種類にも対応しています。30万点以 フトウェアの脆弱性管理のためにOSSを含めたSBOMの管理や提 　このソリューションの特長として、SaaS型のサービス 上のファームウェア診断実績もあり、信頼できる診断 供に関して規制を行う動きが出てきています。 で導入コストが抑えられ、ファームウェアをアップロード プラットフォームです。 するだけで様々な診断が実施可能となり、ソースコード 　グローバル事業を展開していく中で競争力の確保や、日本国内 の提供が不要なことが挙げられます。 IoTに特化した での今後の規制に向けた動きに対応するためにもソフトウェアの 脆弱性管理ソリューション 脆弱性管理としてSBOMの管理は重要な課題となっています。 　主な機能として、ソフトウェア資産を把握するための SBOMリストの生成ができます。主流なSBOMフォー 　IoT機器メーカーにおいても、限られた工数や時間の中でOSSに マットであるSPDX、CycloneDXの両方に対応していま ・SBOMリストを生成 ・既知の脆弱性CVEを提供 内在する脆弱性の把握、外注しているソフトウェアベンダーのOSS す。自社で開発したファームウェアはもちろん、外部か ・継続的に脆弱性情報を監視 使用状況の把握、リリースした後の脆弱性管理の体制構築が必要 ら受領したソフトウェアコンポーネントも診断可能で となります。課題解決にむけて、プロセスの効率化および、自動化に す。また、検出したソフトウェアコンポーネントに紐づけ 向けた対応は重要性が高くなっています。これらに有効なFinite る既知の脆弱性情報であるCVE情報を提供できます。 ファームウェアを State社のファームウェア診断サービスを活用することは重要なポ 毎日新しいCVE情報が公開されていますが、関連する アップロードするだけ イントとなるでしょう。マクニカでは、適切なセキュリティ商材の選定 ソフトウェアコンポーネントが診断済みのファームウェ 30万点以上の はもちろん、IoT機器の開発プロセスに関する課題や悩みに対して アに存在する場合は自動的に診断結果に追加されま 診断実績 お応えします。もし、この診断ソリューションに興味があり、自社IoT す。ファームウェアの再診断は不要なため、継続的な脆 機器のファームウェアを試してみたい方はマクニカまでお問い合わ 弱性情報の監視が実現できます。 せください。

・本資料に記載されている会社名、商品、サービス名等は各社の登録商標または商標です。なお、本資料中では、「™」、「®」は明記しておりません。 ・本資料は、出典元が記載されている資料、画像等を除き、弊社が著作権を有しています。 ・著作権法上認められた「私的利用のための複製」や「引用」などの場合を除き、本資料の全部または一部について、無断で複製・転用等することを禁じます。 ・本資料は作成日現在における情報を元に作成されておりますが、その正確性、完全性を保証するものではありません。 お問い合わせ 045-476-2010 mac-cic@macnica.co.jp https://www.macnica.co.jp/business/iot_security/manufacturers/finitestate/ 株式会社マクニカ　ネットワークス カンパニー 〒222-8563 横浜市港北区新横浜1-5-5 西日本オフィス 〒530-0005 大阪市北区中之島2-3-33 大阪三井物産ビル14階 TEL. 045-476-2010 ｜ FAX. 045-476-2060 TEL. 06-6227-6916 ｜ FAX. 06-6227-6917 @Macnica, Inc.