CVE を解決の優先度 1 にすべき理由
アプリケーション セキュリティがスタックである理由については、以前に説明しました。 これをもう一度言うのは、現代のアプリケーションは決して単独では展開されないということを時々思い出す必要があるからです。 そうじゃないよ。
現代のアプリケーションはすべて、何らかのプラットフォーム上に展開されます。 それは Apache または IIS である可能性があります。 Oracle または IBM アプリケーション サーバーである可能性があります。 Express を使用した node.js または必要なすべてのライブラリを備えた Python が考えられます。 私たちがネットワークを提供するためにオペレーティング システムと仮想化/コンテナーに依存しているのと同様に、アプリケーションは TCP や HTTP などの処理のためにプラットフォームとライブラリに依存しています。
さらに、開発者は機能のためにライブラリを使用します。 車輪の再発明は時間の無駄なので、開発者は JSON パーサー、ファイル管理、認証と承認、データベース サポートのためにオープン ソースやその他の手段に頼ります。 UIレイアウトと管理も同様です。 今日、ほとんどの開発者は、これらの機能を提供するためにライブラリを利用しており、ビジネス ロジックとサービスという付加価値に集中することができます。
Contrast Labs による 2017 年のアプリケーション検査では、「サードパーティのソフトウェア ライブラリがアプリケーション コードの 79% を占めている」ことが判明しました。 Java の場合、平均は 107 個の異なるライブラリでした。 .NET 用ですか? 19. 逸話的に言えば、私は node.js で少なくとも 5 つの異なるライブラリを使用しています。
しかし、この分裂に関する安全保障の状況について彼らが発見した事実は、驚くべきものだ。
アプリの 79% はライブラリで構成されていますが、既知の脆弱性 (CVE) はわずか 2% にすぎません。 残りのほとんどを占めるのはカスタム コードで、脆弱性の 97.3% を占めています。
ライブラリと脆弱性の間のこの不均衡な調達セキュリティリスクは、 SANS の調査で「回答者の 23% がサードパーティのソフトウェア製品とサービス (COTS、クラウドベースのサービス、オープンソース ソフトウェア) に大きく依存しているにもかかわらず、サードパーティ ソリューションのセキュリティを確保する責任を十分に果たしていない」という結果が出た理由を説明できるかもしれません。 COTS を含むセキュリティ プログラムはわずか 23% です。」
ふん。 そうなると、Kenna Security が報告した脆弱性解決への応答率が低い理由が説明できるかもしれません。 2015 年に Kenna Security は、2 億 5,000 万の脆弱性と 10 億件を超える侵害イベントを抱える 50,000 の組織を対象に実施した調査について報告し、脆弱性の修復に関して非常に興味深い点が 2 つあることを発見しました。
- 平均して、企業が脆弱性を修正するには 100 ～ 120 日かかります。
- 40 ～ 60 日で、CVE が悪用される確率は 90 パーセントを超えます。
- 脆弱性が悪用される可能性が高まってから脆弱性が解消されるまでの期間は約 60 日です。
言い換えれば、ほとんどの組織は、2% の脆弱性に十分な速さで対処しておらず、脆弱性による侵害を回避できていないのです。 おそらく、組織のセキュリティ プログラムに含まれていないライブラリに配置されているためです。
それがなぜなのかに関係なく、それは最優先事項である必要があります。 その理由を説明させてください。
昔、攻撃者は次のことを行う必要がありました。
- 脆弱性について知る
- 被害者のサイトを探す
- エクスプロイトの実行を試みる
これは手作業で時間がかかりました。 あなたが知名度の高いターゲットでない限り、誰もあなたのために時間を無駄にするつもりはない。
今日では、脆弱性はインターネットの速度（ご存知かもしれませんが、光の速度です）で共有されています。 ご存知のとおり、光バックボーンとターゲット検出は自動化されています。 スクリプトとボットは、人間よりもはるかに速く（そして安価に）侵害の可能性があるサイトを探し出してマークすることができます。 これは、セキュリティ保護されていない IoT デバイスからデス・スター規模のボットネットが構築されるのと同じ方法です。 自動化は善良な人々の生産性を向上させるだけではありません。
これらは非標的型攻撃です。 いわば、計画されていない機会攻撃です。 価値のあるデータや興味深いデータは持っていないかもしれませんが、リソースは持っています。 そして、そのリソースは他の被害者を見つけたり、他の攻撃を遂行したりするために使われる可能性があり、そして、これがどのように終わるかはご存じのとおりです。
CVE の公開後は、非標的型攻撃が特に多く発生します。 これは、カスタム コードが固有のものであるためです。カスタム コードには多くの脆弱性がありますが、それを見つけるには時間と労力がかかります。 一般的に使用されているライブラリやプラットフォームに存在する CVE を悪用するのは簡単です。 投資収益率が非常に高いため、この機会を逃すわけにはいきません。 2015 年の Verizon DBIR では、 「攻撃の 70% は、パッチが利用可能な既知の脆弱性を悪用した」と指摘されています。
そのため、アプリケーションを構成する 79% のライブラリのいずれかで新しい CVE が公開された場合は、実際のソフトウェア更新を通じて、または仮想的にWeb アプリケーション ファイアウォールを使用して、パッチを適用することが最優先事項になります。 その CVE がプラットフォームに関連している場合(Apache Killer など)は、優先度を「すべて削除」にする必要があります。Web サーバーとアプリケーション サーバーのフィンガープリントを作成する方が、ライブラリの脆弱性をスキャンするよりも簡単だからです。
実際のところ、標的になるほど有名でなくても、危険にさらされる可能性はあります。 おそらく、著名な組織と同じスタックを使用しているため、非標的型攻撃の標的になる可能性が高いです。 そうではないと思われる場合は、CVE データベースにアクセスして、 node.js に関連する公開済みのすべての CVEを検索できることを考慮してください。 次に、 builtwith.comにアクセスし、Node.js フレームワークである Express で構築された Web サイトを検索します。 このサイトでは、「Express を使用しているライブ Web サイトが 230,116 件、過去に Express を使用していたサイトがさらに 263,872 件」あることがわかっているだけでなく、ダウンロードするための便利なリンクも提供されています。
これは Web アプリの shodan.io とはまったく異なりますが、2 つの要素を組み合わせて成功するエクスプロイトを考案するのはそれほど難しくありません。
したがって、自分は「規模が十分ではない」からライブラリや Web プラットフォームの CVE を無視できるなどと誤解しないでください。
そうやって人々は Twitter でトレンドになるのです。 そしてそれは良い意味ではありません。
安全に過ごしてください。 アプリスタック全体に影響する CVE への対応を優先します。 上から下へ。