ページの本文へ

Hitachi

日立ソリューションズ ソフトウェア部品管理ソリューション

OSS管理ブログ

セキュリティ事例で考えるSBOMの重要性

セキュリティ事例で考えるSBOMの重要性

これまでの私たちのブログの記事を通じて、「SBOMとは何か」については詳しくご理解いただけたと思います。であれば、実際に会社の中でSBOMを管理する仕組みを作ろうと、既に動き出されているかもしれませんね。

上司にSBOM対応の必要性を訴えても理解してもらえず予算がつかない、取引先の担当者に対して情報共有を依頼してもきちんと対応してもらえない・・・このような「上司(取引先)がわかってくれない問題」は、SBOMの管理を始めようとしている組織に非常によくあるお悩みです。

SBOMの重要性や必要性を訴えてもわかってもらえないのなら、「それを怠るとどうなるか」=「ホラーストーリー」を示してみてはいかがでしょうか。過去に実際に発生した事例を交えて説明し、その影響の大きさや深刻さを自分ごととして理解していただければ、きっと周囲の協力を得ることができるでしょう。今回は、米国でここ数年の間に発生したSBOM関連のセキュリティ事件や事例を紹介します。

①Hikvision 製ネットワークカメラの脆弱性(CVE-2017-7921)

2017年に発見されたこの脆弱性は、認証の不備により、悪意のある第三者によって管理者権限で任意の操作がおこなわれる可能性があるというもので、CVSS v3でスコア10.0の深刻な脆弱性として報告されています。

実は、このネットワークカメラは、OEM製品として別のブランドでも多数販売されているのですが、National Vulnerability Database(NVD)で脆弱性情報の影響を受ける製品として報告されたのはHikvision製品のみでした。このため、80社以上の同社のOEMパートナーから販売されている少なくとも25万台以上のデバイス(IPVMによる試算より)が、「脆弱性がある」ことが明示されないままとなってしまいました。

本脆弱性についての詳細はJVNDB-2017-003961をご覧ください。

この事例は、特にOEMビジネスモデルにおいて脆弱性についての情報が正しく提供されない可能性があることが明らかになり、ユーザーが「自分が使用しているこの製品は、本当に大丈夫なのか?」という不安を抱えるきっかけになりました。

②Ripple20(CVE-2020-11896、CVE-2020-11897ほか)

Treck社が開発したTCP/IPライブラリで見つかった19個の脆弱性のことをまとめて、「Ripple20」と言います(合計19個なのにどうして「20」・・・?)。2020年6月、JSOF社により発見されたこの脆弱性は、19個中の4個がCVSS v3でスコア9.0以上であり、悪意のある攻撃者によってリモートコードの実行ができてしまうなど、深刻なものが含まれています。このTCP/IPライブラリは昔からさまざまなところで使用されており、全世界の医療、運輸、エネルギー、通信などありとあらゆる業界の数億台のデバイスがこの脆弱性の影響をうけると言われています。

本脆弱性についての詳細はJSOF社のレポートをご覧ください。

Ripple20の事例は、業界を問わず普及しているライブラリの脆弱性であることがポイントで、「プリンターからデータが盗まれる」「輸血ポンプの挙動が変更される」「産業用の制御装置が誤動作する」など多種多様な顕在化の可能性が指摘されています。ひとつの小さなコンポーネントの脆弱性が広範囲に波及し、さまざまな業界、アプリケーション、企業、および人々に影響を与える可能性が改めて認識されるきっかけとなった事例と言えるでしょう。

③Amnesia:33(CVE-2020-13984、CVE-2020-13985ほか)

4つのTCP/IPスタックのOSSライブラリ(uIP、FNET、picoTCP、Nut/Net)で見つかった合計33個の脆弱性のことを、「Amnesia:33」と呼びます(33個だから)。2020年12月にForescout社により発見されたこの脆弱性は、全世界150社の100万台以上のデバイスが影響をうけると言われており、CVSS v3でスコア9.8のもの(CVE-2020-24336)を含む、深刻な脆弱性です。遠隔の悪意のある第三者によってサービス運用妨害(DoS)や任意のコードの実行がおこなわれたり、機微な情報が漏洩したりする可能性があるとして、広く対応が呼びかけられています。

本脆弱性についての詳細はForescout社のサイトをご覧ください。

Amnesia:33の存在するTCP/IPスタックが、幅広い業種向けのIoT、OT、ITデバイスに広く分散していることから、完全な影響評価は難しく、根絶することも非常に困難であると言われています。また、脆弱性が発見されたOSSライブラリの中には既にEnd of Lifeになっており、セキュリティパッチが提供されないものもありました。OSSを使用するうえではこのような事態に備えて、自分でコードを調査して脆弱性に対応できる技術力も必要だと言えるでしょう。

まとめ

以上の3つのSBOMセキュリティ事例からは、近年の複雑なサプライチェーンにおけるセキュリティ対応の難しさがよくわかります。NVDなどで脆弱性の情報を定期的に収集していたとしても、自分が使用している製品の中身が正確に把握できていなければ意味がありません。Bean to Barのチョコレートのように、原材料調達から加工、製品販売まで一貫して自社でおこなうということができればそれも良いのかもしれませんが、近年のソフトウェアの複雑化や高機能化、市場投入の早期化などを考えると現実的ではありません。ということで、サプライチェーンのトレーサビリティの確保が重要になり、この手段としてSBOMが重要であるということが言えるわけです。

ところで、上記のJSOF社のサイトでは、当該脆弱性を利用したエクスプロイトの実演ビデオを観ることができます。これ自体は、コマンドを実行すると電源が落ちて機器がピーピー鳴るという、一見、平和なビデオなのですが、「これが医療機器だったら」、「これが車や電車だったら」という考えが頭をよぎった途端、ぞーっとしました。Software Component Transparencyがいきなり身近に感じられた瞬間でした。

米国では、SBOMの実証実験(PoC)が、自動車業界、エネルギー業界、医療業界で既に始まっています。このように、人命に関わる業界においてSBOMへの関心が高いということは、とてもありがたいと思っています。

オープンソース管理ソリューション
タグ一覧
新着記事