IoT時代の製品ライフサイクルに欠かせない、脆弱性管理と運用のポイントを徹底解説！【JapanSecuritySummit 2023 日立ソリューションズセッションレポート】

ここ数年にわたり、ランサムウェアの被害が急増している。2022年の被害は前年比57.5％も増加し、この2年間で約5倍に急伸中である。被害にあった企業の半数が復旧するまでに1週間以上かかり、その費用も1000万円を下らない。約8割の企業ではデータのバックアップを取っているが、それでも復旧できた企業は多くなく、ほとんど対策が意味をなしていない。ハッカーがバックアックデータまで暗号化したり、破壊したりすることが多いからである。このような被害を防ぐための「真のセキュリティ対策」とはどのようなものなのか、株式会社日立ソリューションズ セキュリティマーケティング推進部 Security CoEの扇 健一氏が解説した。

年々増加するサイバー攻撃、シャドーIoTとシャドークラウドのリスクが顕在化

IoTデバイスへのサイバー攻撃は年々増加しています。NICT（情報通信研究機構）のNICTERによる調査では、IPアドレス当たりの年間総パケット数が増え、IoT機器に使われるTelnetの23番ポートを狙った攻撃が11％から23％へ倍増しています（2022年度調べ）。IoTデバイスには、産業機器、輸送機器、自動車、倉庫、医療機器など、さまざまな分野で使われ、利便性の向上や安全性を高めるなど、生産性を向上するDXの一翼を担っています。

その一方で、IoTやクラウドの利用拡大により、DXの進展は新たな課題も生んでいます。たとえば「情シスがシステムを把握しきれない」「セキュリティの設定や対策状況が見えづらい」といったことで、未管理のシャドーIoTやクラウドがインターネットにつながることで、脆弱性を顕在化させ、サイバー攻撃を受けやすくなり、想定外の被害をもたらします。 OSSの脆弱性も大きな話題になりました。2021年末には、Javaのログ出力ライブラリのLog4jで脆弱性が発見され、世界中で大騒ぎになりました。サプライチェーン上流にあるLog4jは、該当するソフトウェアのみならず、サプライチェーン下流にある外部公開サービスにも利用されており、なかなか発見しづらいこともあります。

脆弱性管理の取り扱いをどうする？　いまSBOMが求められている背景

製品の脆弱性の取り扱いは、事前に把握した脆弱性情報をどう扱うかという「脆弱性ハンドリング」と、外部から指摘されたインシデントをどう扱うかという「インシデントハンドリング」に分類されます。

前者の脆弱性ハンドリングのフローで調査依頼を出す場合は、どんな依頼を誰に出し、依頼を受けた側は何をするか、誰に回答してもらい、誰が対策会議に出席するのかといったことを決めておきます。また製品セキュリティの問題を記録するときは、問題発生時の帳票を定義し、脆弱性情報の概要や原因・対策方法、情報発信が必要かどうかも整理しておきます。

次に、後者のインシデントハンドリングでは、インシデント発生時の対応方針、組織間の役割や連携体制、コミュニケーション窓口と方法、誰が対策会議に出席するのかどうかを決めておきます。またインシデントの記録しておきます。ここで発生日時・箇所、発生事象、影響範囲、優先順位を決めるトリアージと、事象分析、影響度の判断記録、情報発信の有無などを整理しておきます。 このように脆弱性情報とインシデントのハンドリングでは、前出のような多くの情報を整理しておく必要があります。そのためには、原因元となったソフトウェアの提供者やバージョン、依存関係などの情報も求められます。これがソフトウェア部品表のSBOM（Software Bill of Materials）が必要になる大きな背景になります。

SBOMに対する日本、米国、EUの活発な動きと、その対応要件とは？

最近は、世界各国でSBOMに対する動きがあります。日本では今年7月に経済産業省から「ソフトウェア管理に向けたSBOMの導入に関する手引Ver1.0」が策定しされました。

この手引では、「脆弱性管理」「ライセンス管理」「開発生産性向上」の3つの側面でSBOMのメリットが記載されています。たとえば脆弱性管理では、SBOMの情報を突合して脆弱性を検出することで、脆弱性の残存リスクを低減できます。また専用SBOMツールを利用することで、リアルタイムで新しい脆弱性を検出して初動期間を短縮し、脆弱性管理の自動化により手動よりも管理コストを抑えられます。

一方、世界の動きとして、米国ではコロニアルパイプラインの事件を受けて、大統領令が2021年5月に発令され、国家安全保障の観点からサプライチェーン全体でセキュリティを確保する必要があることが示されました。そのなかで各製品のSBOMを購入者に直接、またはWebサイトで公開すること、さらに60日以内に商務長官がNITA（国家電気通信情報局）の管理者と連携して、SBOMの最小限の要素（サプライヤー名、コンポーネント名とバージョン、その他の一意の識別子、依存関係、SBOM作成者、タイムスタンプ）を公表することが記載されています。 さらに大変なのはEUの動きです。サイバーレジリエンス法では明確にSBOMが記載されています。脆弱性分析を容易に実施するために、製造業者が機械判読が可能な形式のSBOMを作成するなど、デジタル要素を含む製品コンポーネントを特定して文書化しなければなりません。SBOMによってソフトウェア製造者、購入者、運用者にサプライチェーンの理解を高め、新たに出現する脆弱性やリスクを追跡するのに役立てる方針です。メーカーもサードパーティの脆弱なコンポーネントの有無を確認できるようになります。

これが直近に発行され、インターネットに接続される製品類が対象になります。もし本法案が発効された場合は、1年後から対応が求められます。そして製造業者は24時間以内に前出のNITAに脆弱性情報や緩和措置、インシデントを認識した場合の報告義務が課せられます。さらに2年後にはSBOMの作成を含む、製品に対するサイバーセキュリティの必要要件対応が必要になります。そのため、いまから早急にSBOMの準備をしないと間に合わないでしょう。

SBOMを用いた脆弱性管理の4つのステップアプローチとポイント

脆弱性管理というと、一般的なソフトウェア開発のV字モデルの「コーディング生成」から「運用保守」までのプロセスに関係します。製品リリースで終わりではなく、セキュリティ対策をしっかりサポートし、脆弱性対策を継続していく必要があります。

具体的には「構成管理」「情報取集」「判断」「対応」まで4つのステップがあります。

まず構成管理ではSBOMを作成し、各プロジェクトのSBOMを統合し、承認を受けて管理します。ここではハードウェアの一覧であるHBOMの整理も必要です。というのもソフトウェアとの依存関係があるからです。特にOSSは脆弱性が頻繁に発生するため、情報の管理をしっかりしないと、運用時の脆弱性管理が難しくなるので注意しましょう。脆弱性関連情報を収集し、検索してSBOMでヒットすれば一次判定が可能です。

構成管理を実施するうえでのポイントは以下の通りです。脆弱性について、部品提供者は著作権や機密保持の関係でソースコードをサプライチェーン下流側のベンダーに提供できないこともあります。そこで、提供を受けたバイナリコード（実行プログラム）からSBOMを生成する技術を活用しましょう。またソフトウェア環境を考慮しないと、本来は該当しない脆弱性まで拾う可能性があります。そこで前出のようにハードウェアや設定情報も抽出・管理しておく必要があります。 次に、脆弱性情報が公開されているNISTのNVDのような検索サイトで情報をしっかりと収集し、SBOMと突合して脆弱性がないかどうかを調べます。製品出荷後も継続的に監視します。脆弱性情報の見方としては、脆弱性に一意に付けられる「CVS」や、脆弱性の重要度を評価する「CVSS」があります。このスコアを見て緊急性の高いものから対処します。影響度の判断例を以下に示します。

たとえば、NVDで公開されたApache Tomcatの脆弱性ですが、Current Descriptionを見ると①のスコア判定でハイスコアになっているため、緊急性が高い脆弱性になります。②では、どんなバージョンが対象になり、③で設定条件なども示されます。ここでSBOMを使って、バージョンや条件に該当するものかを確認します。もし何か脆弱性の問題があれば影響範囲を判定し、プライオリティを付けて対策する必要があります。この優先度付けが人手と時間がかかります。

そして最後に情報を発信して、同時に脆弱性対策のプログラムも公開します。ここで重要な点は、どこまで対応できたかという記録の管理になります。また組込み製品は台数も多く、パッチを当てるのは大変で、ファームウェア全体を更新する必要もあります。できるだけ修正版を提供しなくて済むように、SBOMを管理しながら該当しないという正確な判断ができるようにすることが肝要です。

製品に脆弱性が発見されたら、すぐに対応できる体制を整備しておく

実際のところ、製品やサービスのサプライチェーンは上流から下流まで、非常に多くの部品やソフトウェアから成り立っており、SBOM情報を入手して管理することは大変です。

そこで最近では、SBOMの構成管理から情報収取、判断、対応までの一連の流れをワンストップで支援するプラットフォームがあります。こういうものを活用すると分析にも、サプライチェーンの管理にも役立ちます。たとえば、どこのサプライヤーに課題が多いかといったことも可視化されます。

そして、もし出荷製品に脆弱性が見つかった場合には、多くの関連機関との連携が求められます。自社では、誰がどう対処し、製品をどのように更新していくか？　といった対応が求められます。こういった有事に備えてPSIRT（Product Security Incident Response Team）のような組織を作り、日ごろから訓練もしておくと良いでしょう。

最後に当社では、製品セキュリティに関する多くのソリューションを提供しています。PSIRTの構築・コンサルからガイドライン策定の支援、モノづくりに必要なセキュリティ設計、脆弱性管理に求められるSBOMやプラットフォームなどを用意していますので、是非ご活用ください。