CVEの解決を最優先すべき理由

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

以前にも、なぜアプリケーションセキュリティがスタックであるのかを詳しく説明しました。ここで改めて述べるのは、最新のアプリケーションが単独でデプロイされることは決してないという事実を、ときには思い出す必要があるためです。実際、単独でデプロイされることはありません。

現代のアプリケーションは、いずれも何らかのプラットフォーム上にデプロイされます。ApacheやIIS、OracleやIBMのアプリケーションサーバー、Expressを使用したnode.js、必要なライブラリを備えたPythonなどがその例です。ネットワーク機能をオペレーティングシステムや仮想化環境／コンテナに依存しているのと同様に、アプリケーションはTCPやHTTPなどを処理するためにプラットフォームやライブラリを利用します。

さらに、開発者は機能を実装するためにライブラリを利用します。既存の機能を一から作り直すのは時間の無駄であるため、JSONパーサー、ファイル管理、認証と認可、データベース対応、さらにはUIのレイアウトと管理に、オープンソースなどを活用しています。現在、ほとんどの開発者はこうした機能をライブラリに任せることで、価値を生み出すビジネスロジックとサービスに注力しています。

2017年にContrast Labsが実施したアプリケーション調査では、「アプリケーションのコードの79%をサードパーティ製ソフトウェアライブラリが占めている」ことが明らかになりました。Javaでは、使用されているライブラリは平均107種類でした。.NETでは19種類です。ちなみに、私自身はnode.jsで少なくとも5種類のライブラリを使用しています。

しかし、注目すべきなのは、この内訳に関して明らかになったセキュリティの実態です。

アプリの79%はライブラリで構成されていますが、既知の脆弱性（CVE）に占める割合はわずか2%です。残りのほぼすべてに相当する97.3%は、カスタムコードの脆弱性です。

ライブラリと脆弱性の間に見られる、調達元に起因するセキュリティリスクの不均衡は、SANSの調査で次の結果が示された理由の1つかもしれません。「回答者の23%は、サードパーティ製のソフトウェア製品やサービス（COTS、クラウドベースのサービス、オープンソースソフトウェア）に大きく依存しているにもかかわらず、サードパーティソリューションのセキュリティ確保に対して十分な責任を負っていません。COTSを対象に含めているセキュリティプログラムは、わずか23%です。」

なるほど。そうであれば、それがKenna Securityの報告にある、脆弱性解消への対応率の低さを説明できるかもしれません。さかのぼること2015年、Kenna Securityは調査結果を報告しました。この調査は、2億5,000万件の脆弱性と10億件を超える（実に10億件を超える）侵害イベントを抱える50,000の組織を対象に実施され、脆弱性の修復に関して非常に興味深い2つの点が明らかになりました。

• 企業が脆弱性を修正するまでには、平均で100～120日かかります。
• 40～60日で、CVEが悪用される確率は90%を超えます。
• 悪用される可能性が高まってから脆弱性が解消されるまでには、約60日間の隔たりがあります。

つまり、ほとんどの組織では、その2%の脆弱性への対処が十分に迅速ではなく、いずれかの脆弱性を悪用される事態を回避できていません。これは、組織のセキュリティプログラムの対象外となっているライブラリに脆弱性が存在するためかもしれません。

その理由が何であれ、最優先で対処する必要があります。その理由をご説明します。

かつて、攻撃者は次のことを行う必要がありました。

1. 脆弱性について調べる
2. 被害対象となるサイトを探す
3. エクスプロイトの実行を試みる

これは手作業で時間がかかるものでした。注目度の高い標的でない限り、攻撃者がわざわざ時間を費やすことはありませんでした。

現在では、脆弱性に関する情報はインターネットの速度で共有され（ちなみに、光ファイバーのバックボーンなので、文字どおり光速です）、標的の発見も自動化されています。スクリプトやボットは、人間よりもはるかに速く（しかも低コストで）、侵害対象となるサイトを探し出して目印を付けることができます。これは、セキュリティ対策が不十分なIoTデバイスからデス・スター級のボットネットが構築されるのと同じ仕組みです。自動化によって生産性が向上しているのは、善良な側だけではありません。

これらは無差別攻撃です。いわば、計画性のない便乗型の攻撃です。価値のあるデータや興味を引くデータがなくても、リソースはあります。そのリソースが、別の被害者を探し出し、さらなる攻撃を実行するために悪用される可能性があります。そして、その先に何が起こるかはお分かりでしょう。

非標的型攻撃は、CVEの公開後に特に多く発生します。カスタムコードは固有のものであり、多くの脆弱性が存在していても、その発見には時間と労力がかかるためです。一方、広く利用されているライブラリやプラットフォームに存在するCVEの悪用は、いとも簡単です。投資対効果が非常に高いため、攻撃者にとって見逃せない機会となります。 2015年版Verizon DBIR では、「攻撃の70%が、パッチが提供されている既知の脆弱性を悪用していた」と報告されています。

そのため、実際のソフトウェアアップデート、またはWebアプリケーションファイアウォールを使用した仮想パッチのいずれかによるパッチ適用は、アプリケーションを構成するライブラリの79%のいずれかで新たなCVEが公開された時点で、最優先事項とすべきです。そのCVEがプラットフォーム（Apache Killerなど）に関連する場合は、「すべてを中断して対応する」ほどの最優先事項とすべきです。Webサーバーやアプリケーションサーバーのフィンガープリンティングは、ライブラリの脆弱性をスキャンするよりもさらに容易だからです。

実際のところ、標的にされるほど知名度が高くなくても、リスクはあります。著名な組織と同じスタックを使用している可能性が高いため、標的を特定しない攻撃に見つかるおそれがあります。そうは思わないなら、CVEデータベースで公開されているnode.js関連のすべてのCVEを検索できることを考えてみてください。次に、builtwith.comでnode.jsフレームワークのExpressを使用して構築されたWebサイトを検索します。すると、このサイトでは、Expressを使用している「稼働中のWebサイト230,116件」と「過去にExpressを使用していたさらに263,872件のサイト」を把握しているだけでなく、それらをダウンロードするためのリンクまで用意されていることがわかります。

Webアプリ版のshodan.ioとまではいきませんが、情報を組み合わせて悪用を成功させるのは、それほど難しいことではありません。

「十分に大きな組織ではない」からといって、ライブラリやWebプラットフォームのCVEを無視してよいと考えるのは誤りです。

そうしてTwitterで話題になってしまうのです。しかも、悪い意味で。

安全を確保するため、アプリケーション全体のスタックに影響するCVEへの対応を優先してください。上位レイヤーから下位レイヤーまで、すべてが対象です。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事