2019年も脆弱性の全公開情報を調べるには2～3人月かかる――CVE/CWE視点で見る2018年の脆弱性のトレンド：OSS脆弱性ウォッチ（11）

連載「OSS脆弱性ウォッチ」では、さまざまなオープンソースソフトウェアの脆弱性に関する情報を取り上げ、解説する。今回は、2018年の脆弱性のトレンドを、CVE、CWEなどの視点から見てみます。

» 2019年01月17日 05時00分公開

[面和毅，OSSセキュリティ技術の会]

　「OSSセキュリティ技術の会」の面和毅です。本連載「OSS脆弱性ウォッチ」では、さまざまなオープンソースソフトウェア（OSS）の脆弱（ぜいじゃく）性に関する情報を取り上げ、解説しています。

　今回は、2018年の脆弱性のトレンドを、「CVE（Common Vulnerabilities and Exposures）」「CWE（Common Weakness Enumeration）」など、SCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）の要素となっている脆弱性情報の視点から見てみます。

2018年の脆弱性のトレンドについて

　2018年の年末にかけてセキュリティ関連企業各社から、「2018年に起きたセキュリティインシデント」をまとめる情報が出ています。さまざまな視点の情報がありますが、本稿では、あえてCVE/CWEなどの視点で見てみます。

　なおCVE/CWEに関しては、連載「OpenSCAPで脆弱性対策はどう変わる？」をご参照ください。

公開された脆弱性数の傾向（CVE数の遷移）

　さまざまな視点で見ていくために、まずはCVEに関して「Published」を起点として見てみましょう。今回の情報は、NIST（アメリカ国立標準技術研究所）のNVD（National Vulnerability Database）から取得しています。Mitre社のDWF（Distributed Weakness Filing）がCVEを発行してからNVDに登録されるまで少し時間差があるので、その点を加味した考察とします。

　図1は2016～2018年に公開されたCVEの総数です（公開された後に重複などでリジェクトされたものは除いています）。2016年から見てみると右肩上がりで大まかに推移していますが、2017年から2018年にかけては増加傾向が緩やかになっているように見えます。

図1　2016～2018年に公開されたCVE数

　ちなみに図2では年ごとの総数を見ていますが、2016年から2017年にかけては3倍程度だったものが、2017年から2018年にかけては1.1倍以下になっています。これは、脆弱性が少なくなったということよりも、各社で脆弱性をCVEとして公開する仕組みが行き渡ってきたと考えるべきでしょう。

図2

　各CVEの情報には、CPE（Common Platform Enumeration）で種類（「OS」「App」「HW」）が記載されているため、その種類ごとに2016～2018年の遷移を見てみます（図3）。

図3　2016～2018年に公開されたCVE数（CPEによる種類別）

　図3を見て面白いのは、OSやHW（ハードウェア）に関しての脆弱性は、2016年から2018年にかけての伸び率がほぼ横ばいです。これから、2016～2017年の伸び（さらに言えば、2017～2018年の若干の伸びに対しても）をリードしているのは、（MySQLやApacheなどのミドルウェアを含む）Appであることです。このことから、OSやHWを作っていたベンダーはもともとCVEの公開を行っていたため、件数の伸び率はほぼ横ばいですが、Appを作っているベンダーがより脆弱性の（さらにCVEとしての情報の）公開に積極的になってきていることがうかがえます。

　また図3を見ると、2018年7月にAppが飛び抜けて多くなっていることに気付きます。この伸びを調べてみると、2018年7月にはAdobeのアップデート、Oracleの四半期アップデート、Microsoftの月間アップデートに加えて、Ciscoのアップデート、F5 NetworksのBIG-IP関連アプリケーションのアップデートが全て重なったためのようです（図4）。

図4　2018年8月のCVE数の内訳

　また、これらの図から、2018年は月間で1500～2000件のCVEが公開されていることが分かります。「1件のCVEについて、調査に15分かかる」と（ざっくり）見積もると、毎月375～500時間＝2～3人月ぐらいかかると算定できます。このため、「公開されている脆弱性情報全てを調査するには、2～3人月ぐらいの工数は見積もる必要がある」といえます。

　2019年にも同程度の脆弱性情報が公開されると仮定すると、そのくらいの作業量が必要と予想できるので、人員の確保や、脆弱性情報通知サービスなどを検討する際の目安にするとよいでしょう。

公開された脆弱性種別の傾向（CWE数の遷移）

　次に、各脆弱性のCWE数の遷移について見ていきましょう。CWEのトップ10の遷移を2016～2018年で見てみました（図5）。

図5　CWE-IDのトップ10の遷移

CWE-79（クロスサイトスクリプティング）：2017年とほぼ同数
CWE-119（バッファーエラー）：2017年から半減
CWE-20（不適切な入力確認）：2017年の3分の2
CWE-284（不適切なアクセス制御）：2017年の3分の2
CWE-200（情報漏えい）：2017年の3分の2

　（語弊はありますが）いかにもよくある脆弱性が減っていることが分かります。これは、テストツールを用いるなどして、目立つような脆弱性を2017年にだいぶ減らしてきた成果のように見えます。

　総数を比較する他に、伸び率を見てみましょう。2016～2017年、2017～2018年での増分を取り、2018年の伸びが2017年に比べて大きいもののトップ5を見てみます（図6）。

図6　CWE-IDの伸び率が2018年で増えたものトップ5

CWE-285（不適切な認証）：増加率が6.3倍
CWE-190（整数オーバーフロー）：増加率が3.5倍
CWE-88（引数インジェクション）：増加率が2.5倍
CWE-16（環境設定）：増加率が2.3倍
CWE-184（不完全なブラックリスト）：増加率が2倍

　この中では、特にCWE-285の増加率が著しくなっています。CWE-285のOSS系での例としては、2018年8月に発生したPostgreSQLの脆弱性（CVE-2018-10925）における「INSERT特権とUPDATE特権を少なくとも1つのカラムに対して持っているユーザーが、viewとinsertクエリを使って他のカラムをupdateできる脆弱性」などが挙げられます。

　2018年は、このような脆弱性が発見、公開されることが多くなった年だといえます。

Meltdown／Spectreについて

　エンジニアから見た2018年のセキュリティは、2018年1月4日に公開された「Meltdown/Spectre」から始まった、CPU/GPUなどのハードウェア系の脆弱性が多かった印象です。では、このCPU/GPU関係の脆弱性は、どのように扱われたのでしょうか。

　Meltdownを含むSpectreの亜種は、以前の記事でも扱いましたが、図のようになっています（図7）。

図7　Spectreの亜種とCVE-ID

　これらのCWEは、CWE-200（情報漏えい）です。このCWE-200の2016～2018年の遷移は図8のように常にトップ5内にありますが、減少傾向にあります。

図8　CWE-200の遷移

　このことから、2019年にも同様の脆弱性が出る可能性は大いにあり得ます。全体としての数は（脆弱性調査の自動化や、今回のようなハードウェア由来の脆弱性情報が流通して穴がふさがれていくため）減少するのではないかと予想できます。

まとめ

　今回は、2018年の脆弱性のトレンドを、CVE/CWEなどの視点で見ていきました。この2018年の傾向がそのまま2019年に引き継がれるとは言い切れませんが、指標の一つにできるのではないかと思います。2019年にも多くの脆弱性が公開され悪用されると思いますが、筆者の方でも（OSS中心になってしまいますが）なるべく早く情報をブログで公開する予定です。

　2019年もシステムをメンテナンスする管理者、セキュリティ担当者、システムインテグレーターの方々へ、日々のご活躍をお祈りいたします。

筆者紹介

面和毅

略歴：OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログを連載中。

CISSP：#366942

近著：『Linuxセキュリティ標準教科書』（LPI-Japan）」