BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 攻撃側と防御側の相違

攻撃側と防御側の相違

原文(投稿日:2021/02/04)へのリンク

Kenna SecurityとCyentia Researchは、ソフトウェアの悪用と修正/パッチサイクルを比較する分析をリリースした。この分析では、15か月の間に、攻撃者が9つで優位に立ったことが示されている。この優位は、脆弱性の約4分の1から来るものであり、脆弱性が公開される前に悪用されていた。そして、パッチが利用可能になってから防御側がパッチを適用するのに約1か月以上かかっている。

調査レポートでは、2019年に開示された約18,000のCVE(Common Vulnerabilities and Exposures)が比較されたが、脆弱性と悪用の間に事実として認められる共通のパスは見つからなかった。脆弱性の最初の出現は、CVEとパッチの間でほぼ等しく(それぞれ40%)変動していた。他は、悪意のあるペイロードが最初に発見されていた(約20%)。攻撃者は、既知の脆弱性が含まれている場合、ソフトウェアを悪用する方がはるかに簡単である。カスタム攻撃を作成せずに、悪用するためのペイロードを利用できるためである。一般的な逆シリアル化攻撃ペイロードを生成するサンプルツールの1つは、Javaおよび.NET用のysoserialである。しかし、他への悪用が見つかっており、Struts2のCVE-2020-17530などの脆弱性を突かれている。

エクスプロイトメトリックは、パッチを作成する開発チームと、ソフトウェアが悪用される前にアップデートをデプロイする必要がある運用チームの両方にとって重要な要素である。DevOpsチームは多くの場合、ソフトウェア構成分析に重点を置いている。これは、開発チームがデプロイされ、実行されているさまざまなコードに影響を与える新しいライブラリを理解する助けとなる。

アプリケーションのライブラリと環境にあるCVEはリスクを表すが、アプリケーションセキュリティに対して信頼できる唯一の指標ではない。

CVEは、ライブラリと主要なソフトウェアコンポーネントに最も一般的にリスト化されている。開発チームのカスタムコードにはギャップがある。

Kennaの分析によると、エクスプロイトコードはCVEの前に公開されることが多いことを明らかにした。CVEは存在しないがエクスプロイトは存在するため、アプリケーションは脆弱なままになる。

2019年、パブリックDocker OpenJDKイメージは「mystery meat JDK」を提供してきた。これはバージョン番号を利用したものであったが、適合するセキュリティパッチが含まれていなかった。これは、脆弱性チェッカーが、実際に存在してもCVEを報告しないことを意味する。

もう1つの問題は、脆弱なコードがロードされたかどうかを把握せずに、存在するCVEに対して、使用することとと、誤ってレポートすることにある。これは一般的に古いJavaインストールで発生し、CVEアナライザはバックエンドシステムでアプレット関連の脆弱性を報告していた。そのバックエンドシステムは、アプレットを使用したことがない、あるいはアプレットをまったく含まないJavaバージョンを使用していたものである。これはリスク管理者の公案を表している。脆弱なソフトウェアが見られても使用されていない場合、それはリスクか。

ソフトウェアのリスクは、パッチがリリースされてから実際にパッチが適用されるまで続く。運用面では、Kennaのレポートによると、ターゲットオーディエンスの約80%に到達するには、防御側に約5か月のパッチ適用、攻撃側に約6か月のハッキングが必要となる。

開発チームにとって重要なポイントは、定期的にパッチを適用して、ライブラリを更新する必要があることである。GitHub Dependabotなどのツールを使用してこれを自動化すると、Equifaxのようにアプリケーションが危険にさらされるのを防ぐことができる。しかし、いずれの場合も、パッチを適用する必要があり、適用できる状態になっているだけでは不十分である。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT