既知の脆弱性を悪用したサイバー攻撃や、そうした攻撃から生じたセキュリティインシデントの報告を目にすることが、昨今まったくめずらしくなくなってきました。「既知の脆弱性なんだから対策すればすむ話では?」と片付けたくなる気持ちも確かにわかるのですが、じつは「脆弱性対策のためにパッチを当ててください」は「言うは易く行うは難し」の典型で、現場側にそれができない相応の事情があることも少なくありません。しかも、やれデジタルトランスフォーメーションだ、デジタライゼーションだ、とソフトウェアの役割の拡大が進むばかりとくれば、それらのソフトウェアを稼働させているシステムや機器がいったいどこにどれだけあるのか、ぜんぶ社内で把握して管理するのも大変です。これらの要因があいまって、脆弱性を悪用する攻撃は今後も拡大していくことが予測されています。
実際、ソフトウェアにひそむ脆弱性は標的組織への侵入手段として繰りかえし悪用されていて、弊社が2022年に行った調査でもセキュリティインシデントのじつに31%が脆弱性の悪用から始まっていたことが判明しています。
脆弱性はプログラムの不具合や設計上のミスが原因で発生しますが、脆弱性の増加をすべて開発者の知識不足に帰することはできません。予算や納期、開発上の優先事項など、発注側・受注側のさまざまな都合も脆弱性を増やす要因になりますし、IT技術の発展が、PC、スマートフォン、ウェアラブルデバイスはいわずもがな、自動車、ATM、重要インフラ設備、医療用機器、子供用のおもちゃまで、世のありとあらゆるモノのソフトウェア利用を後押ししたことも、大きな要因になっています。脆弱性がひそみうるソフトウェアは、それこそ無数に身の回りにあふれているわけです。
当然ながら、年次で報告される脆弱性の数も右肩上がりになっています。米国NISTのNational Vulnerability Databaseによれば、2022年だけで25,000件以上の脆弱性が報告され、2023年も8月末ですでに18,000件を超える脆弱性が報告されていています。今後も、報告数が増加する見通しは変わらないでしょう。
脆弱性が発見されると「概念実証コード(Proof of Concept CodeまたはPoC Codeとも呼ばれる)」が公開されることがあります。PoCコードとは「セキュリティ機構をバイパスする」「任意のコードを実行する」「権限を昇格する」など、脆弱性がもたらす影響を確認するためのプログラムのことで、インターネットをちょっと検索すればこれが無数に見つかります。このPoCコードを利用すれば、ある脆弱性が自組織にもたらす影響を調べられるので、組織の現状把握に役立ちます。ただし、同じPoCコードは攻撃者にも利用されていて、標的組織を侵害するさい、彼らはPoCコードを使って、どんな脆弱性を悪用できそうかを調べています。
前述のとおり、たしかに不具合を修正した最新版のソフトウェアに更新すれば脆弱性に対応できますが、修正バージョンが配布されていても適切なタイミングでソフトウェアを更新できないケースは多々あります。代表的な理由は以下の3つです。
ソフトウェアが動作している機器やシステムが多すぎる、対象システムの数や種類が多すぎる、管理責任者があいまい、いつのまにか誰も使わなくなった古いソフトウェアが稼働したままになっていてその存在を誰もしらない、テストや一時目的で使ったソフトウェアをそのままにして担当者が辞めてしまった、管理者が辞めたあとの引き継ぎ手がいない…とくに大きな組織だとこうした「野良資産」の存在は珍しくありません。たとえ資産管理されているシステムであっても、その上で稼働するソフトウェアはOSからデバイスドライバ、アプリケーション、ライブラリまで相当な数にのぼるので、それらすべての種類とバージョンの組み合わせを網羅的に管理している組織はごくわずかでしょう。既知の古い脆弱性が悪用されてセキュリティインシデントにつながってしまうケースが後をたたないのは、「そもそも自社の資産の把握は簡単ではない」という理由が挙げられます。
脆弱性に対応するパッチは、PCやスマートフォンのように利用者がほんの数分で適用・再起動すればすむものばかりではありません。たとえば更新処理が外注されていて外部エンジニアによる影響の事前検証・事後検証が発生するので、更新対応の人件費がかさみすぎるケースや、工程の一部に組み込まれたシステムを脆弱性対応のために止めると製造ライン全体が連鎖的に止まってしまい、事業上の損失が大きすぎるケースなど、一部のシステムはつねに高い稼働率を要求します。そうしたシステムでは、少なからずダウンタイムが発生するソフトウェア更新はそうそう頻繁には行えませんし、重要システムにもかかわらず、セキュリティを担保するソフトウェア更新をタイムリーに行えないという矛盾が生じます。
ビジネスで利用されるカスタムアプリケーションや医療機器、製造装置は、特定バージョンのオペレーティングシステムや特定バージョンのオープンソースライブラリで稼働するように作られていることがあります。そのアプリケーションの動作を保証するため、メーカーによってOSなどのソフトウェア更新を行うことが禁止されていたり、しくみ上、更新ができないものも少なくありません。そうしたカスタムアプリケーションや機器が生命維持などの重要な役割を担っていたり、非常に高額で代替できるものがなかったりすると、やむなく長期にわたって危険なまま利用されてしまうことがあります。
以上、3つの理由から(これらだけにとどまるわけではないですが)、すべてのソフトウェアを最新版に更新できている組織の数はかなり心もとないのが現状です。とはいえ、「適用できないからそのままで」と開きなおるわけにもいきません。脆弱性を悪用した攻撃が減る兆しがない以上、できるところからリスク低減対策をやっていくしかないわけです。そこで、優先度の高いものから順に、以下の 3 つにまとめました。
セキュリティフレームワークの一種であるCISコントロールでも、ハードウェアとソフトウェア資産の把握は最優先事項として挙げられています。とくにインターネットから直接アクセスできる資産は攻撃を受けやすいので、ゲートウェイ、セキュリティアプライアンス、IoT、クラウドなどは、種類を問わず優先的に対応を進めていきましょう。このさい資産目録を手作業で管理したのでは、変更に弱く、どうしても陳腐化が避けられないので、資産の検出から脆弱性の管理まで一貫して自動化するシステムを導入し、資産管理者の負担やミスを積極的に減らすようにしましょう。
日常的に資産の可視化を行い、脆弱性の対応優先順位づけや修正適用まで自動化できれば理想的です。そこまでやるのが難しい環境であれば、少なくとも悪用が確認されている脆弱性には優先して対応しましょう。たとえば米国CISAが公開している悪用が確認されている脆弱性のリストは、この優先順位づけの参考になるでしょう。2023年9月の本稿執筆時点ではこのリストには989件の脆弱性が記載されています。
資産の可視化や脆弱性の自動管理体制がうまく回るようになったら、未知の脆弱性にも対応できるゼロトラスト環境づくりで組織を堅牢化しましょう。ゼロトラストを実現する要素には、最小権限アクセスポリシー、継続的な通信の検証、脅威に対する継続的なセキュリティ検査といった施策があります。これらの要素を実現すれば、たとえ脆弱性を悪用する攻撃が発生しても、いち早くそれを発見し、被害を最小化できる確率を高めてくれます。まだ立ち上がっていない場合は、社内にゼロトラスト環境推進プロジェクトを立ち上げてください。ベストプラクティスを学び、自社の現在の立ち位置を確認し、それを脆弱性対応に活用しましょう。
今回は既知の脆弱性を中心に取り上げ、パッチ適用の現状と各組織が抱える問題、対策の指針について論じましたが、パッチが存在しない未知の脆弱性に対する攻撃(ゼロデイ攻撃)も決してすくなくないので、次のステップとして、未知の脆弱性への対策で鍵となるゼロトラスト環境づくりの推進についても簡単にふれました。
まずは既知の脆弱性への対策をしっかり行える体制をととのえ、余裕ができたら未知の脆弱性に対応できる堅牢な環境づくりを進めてください。
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.