誰もが信頼している製品･サービスに潜む脆弱性

脆弱性がまったくない製品やサービスは存在しない

――利用しているソフトウェア製品やサービスそのものに潜んでいるサイバーリスクには、どのようなものがあるのでしょうか。

佐々木：まずはソフトウェア自体、あるいは製品のアップデートなどを配布する経路が汚染されるケースがあります。例えば、ソフトウェアにバックドア（システム内部に不正侵入するための入り口）や侵入につながる脆弱性が含まれたまま配布されるのです。これには悪意のある攻撃者が意図的に組み込むものと、メーカー側の何らかの不備で脆弱性が含まれ悪用されるものがあります。

もう1つは、ベンダーによる遠隔からの保守などが狙われるケースです。このようなサービス提供者をマネージドサービスプロバイダー（MSP）と呼びますが、このMSPが攻撃されて利用する端末が汚染され、これを足がかりにユーザー環境に侵入されます。

一般的に「サービスプロバイダーのアクセスは安全だ」という認識があるので、とくに対策がされていないことも多く、簡単に侵入されてしまうのです。製品アップデートの流通経路やMSPのアクセスのように、もともと信頼しているものが利用されると、対策は難しいものがあります。

――製品に含まれる脆弱性とはどのようなものですか。

福本：ソフトウェアの欠陥や不具合である「バグ」の中で、セキュリティに関係するものを「脆弱性」といいます。バグは製品をリリースする前に潰すのですが、どうしても何かしらが残ってしまいます。つまりバグが起きない製品がないように、脆弱性のない製品も存在しないのです。現状のソフトウェアは部品を組み合わせて作るので、いずれかの部品に脆弱性が含まれているケースもあれば、設計やコーディングの不備から生まれる脆弱性もあります。

以前から脆弱性を生まないための脅威分析やセキュアコーディング技法などはありますが、それでも防ぎきれず、多くの場合は製品提供後に脆弱性が見つかって慌てて対処する形になります。

そのため今は、「脆弱性が見つかった後の対処が大事」と言われます。見つかった後で脆弱性をどのように修正しユーザーに届けるのか計画を立てておく必要があり、その計画を実行できる体制を内部に作ることが極めて重要です。

守るべきものにどのようなリスクがあるか確認しておく

――アジャイル開発やDevOpsなどの新しい開発、運用では、「シフトレフト」でセキュリティ対策をすべきとの話もありますが。

福本：開発プロセスの早い段階からセキュリティ対策をする「シフトレフト」が注目されていますが、開発の世界ではかなり前から言われていたことです。開発リソースが十分にない場合、とりあえず製品を作って公開し、脆弱性が見つかってから対処するケースも多いでしょう。

しかし、設計段階であれば容易に対応できたものでも、後から対応すると手間もコストも大きくかかってしまいます。さまざまな研究でも、後から対処するほうがコストは増えるとの結果があります。JPCERTで開発企業などにセキュア開発を紹介する際も、シフトレフトの考え方を普及させようとしているところです。

――開発の現場では日々どのようなことを意識すればよいのでしょうか。

佐々木：発見される脆弱性のすべてが、ゼロデイ攻撃のようにすぐに悪用されるわけではありません。多くは情報公表後に速やかに対処すれば、大きな事故は防げます。そのためには、修正プログラムの適用、問題発生時のセキュリティ専門機関やセキュリティ企業との連携など、対処の手順を想定しておく必要があります。

福本：素早く対処するためにも、製品やサービスの中で守らなければいけないものが何かは明確にしておきたいです。例えば顧客の個人情報のように、絶対に守らなければならないものにどのようなリスクがあるかをあらかじめ把握しておくのです。

ユーザー企業だけでなく、専門組織も標的になる

――製品ベンダーや開発側、さらにセキュリティ専門組織などが攻撃された事例はありますか。

佐々木：有名なものに、2020年に発生したアメリカのSolarWinds社の事件があります。同社の製品アップデートサーバーが侵害され、Orionというソフトウェアのアップデートファイルを通じ、世界中の組織にバックドア（システム内部に不正侵入するための入り口）がインストールされました。

また国内では、富士通が運営するプロジェクト情報共有ツール「ProjectWEB」の情報漏洩の事例があります。富士通はセキュリティに特化した専門企業という枠ではないですが、SI企業として大規模なITシステムの開発などを請け負い、セキュリティ対策や監視サービス、SOC（Security Operation Center）サービスなども提供しています。そんな企業のサービスが侵害され、顧客の情報が漏洩しました。

――オープンソースソフトウェアなどに悪意のある脆弱性が組み込まれた事例はありますか。

福本：直近では2024年3月末に発覚した、圧縮ツールのXZ Utilsの例があります。このメンテナーとして2年ほど前にコミュニティに参加していたメンバーが、故意にバックドアを仕込んだのです。

このケースは、信頼を得ていた正規のメンテナーによるソーシャルエンジニアリング的な手法だったので、かなり注目を集めました。これを受け、オープンソースソフトウェアのセキュリティ強化を目的としたグローバルコミュニティのOpenSSFは、ソーシャルエンジニアリングによるプロジェクト乗っ取りに関する注意喚起を出しました。

佐々木：背景には、オープンソースプロジェクトの人手不足もあるでしょう。外部からの侵入には技術的な対策を打てますが、コミュニティに悪意のある人が紛れ込むことへの対応はかなり難しいです。

――さまざまなリスクが懸念される中、開発者は何を気にかけておけばよいでしょうか。

佐々木：まずは開発しているものについて、どのような部品が入っているかを把握するのがベースラインです。そのために「SBOM（Software Bill of Materials）」（ソフトウェア部品表のデータ）などを使うのもよいでしょう。そのうえで、悪意あるものが紛れ込んでいるかを判別し、迅速に対処するのが次のステップです。

福本：SBOMの考え方は提唱され始めたばかりで、しっかり実装されている状況にはまだありません。SBOMを流通させて有効活用するにはさまざまな問題があり、SBOMを入れれば万事解決ということは決してないのです。

また契約によっては、どの部品を使っているかを明らかにできないケースもあり、すべての部品情報をSBOMに取り込むのは現実的ではないでしょう。不完全なSBOMが流通すれば、本質的なものが隠れる可能性があることも憶えておかなくてはなりません。

たとえ侵入されても被害が拡大しない準備も必要に

――実際に自社の製品やサービスに脆弱性があるかをどう管理すればよいでしょうか。

福本：脆弱性があるかどうかのモニタリングを手助けするツールやサービスがあります。有償のものからオープンソースのものまであり、利用している企業も少なくありません。また、国内で脆弱性情報を公開するデータベースとしてIPAが運用するJVN iPediaなどがあり、海外にも無料で使える同様のデータベースがあるので、そういったものを活用するのもよいでしょう。

ほかにも、外部の人に脆弱性を発見・報告してもらい報酬を支払う「バグバウンティ」があります。脆弱性を見つけるのに役立ちますが、一方で指摘された際にきちんと対処できる社内体制がなければ有効に機能しません。

――改めて製品やサービスを提供する側が、今後考慮すべきことはどのようなものでしょうか。

佐々木：以前は脆弱性情報が出て急いでパッチを当てれば間に合いましたが、最近はそれが崩れつつあります。未公開の脆弱性情報は、それを知る1つのグループだけが悪用すると思われてきましたが、現在では複数グループで脆弱性情報を共有するケースが確認されています。

これまではセキュリティ専門組織などから注意喚起が出て、1週間以内にパッチを当てれば防げると思われてきました。しかし今は早ければ当日に攻撃がきて、翌日には別グループからも攻撃されます。侵入対策を諦めるわけではありませんが、インターネットにつながるシステムなどは侵入を前提に準備しておくべきでしょう。二要素認証の追加や、侵入されても奥まで入れないようにするなどの対策が必要です。

以上のようにユーザー側は厳しい状況にいますので、製品・サービス提供側はこれまで以上に脆弱性情報や、当該脆弱性が悪用されているかどうかという情報について速やかにユーザーに提供しなければなりません。

福本：開発者側で意識すべきは、メンテナンスがすでに止まってしまっているモジュールは使わないようにするということです。よく使われていても、もう何年もメンテナンスがされていないものもあります。開発者が撤退してしまったものや、すでに亡くなってしまっているものなどは、万が一脆弱性が見つかっても誰も直せないという事態に陥りかねません。開発の際に使うライブラリやモジュールが、将来にわたり安心して使えるかどうかは確認すべきでしょう。

（谷川 耕一 ： ライター）