サイト内の現在位置

SCAPの要素第一回～製品の識別と脆弱性情報管理の難しさ～

NECセキュリティブログ

2020年4月10日

製品の脆弱性情報管理を担当しています、岩下です。
わたしが担当するブログでは数回に渡り、情報システム等のセキュリティ対策自動化、負担削減や標準化を目指してNIST(アメリカ標準技術研究所)が策定した仕様群SCAP(Security Content Automation Protocol)の要素について紹介していきたいと思います。
その中で、今回は製品情報の一意な識別子であるCPE(Common Platform Enumeration)について紹介します。

CPEが必要な理由

脆弱性を管理するためにはまず、数多く配信される脆弱性情報から対象のシステムに関連する脆弱性情報のみを抽出する必要があります。
関連する脆弱性情報を抽出するためには、その製品情報(その脆弱性が影響を与える製品と該当するバージョン情報)が必要となる為、常日頃からシステムで使用している製品情報を管理しておかなければなりません。そのため、SCAPでも製品を一意に識別するためにCPEを定義しています。

CPE名の書式

CPEは以下のフォーマットで記載されます。

cpe:/{種別}:{ベンダ名}:{製品名}:{バージョン}:{アップデート}:{エディション}:{言語}

フィールド	説明
種別	製品種別(ハードウェア(=h)、OS(=o)、アプリケーション(=a)を識別します。
ベンダ名	製品を提供するベンダのドメイン名を利用して作成されます。NECなら“nec.co.jp"から“nec"となります。買収や移譲等により提供ベンダが変わっても既存製品のCPEのベンダ名は変更されません。
製品名	製品名を記述します。スペースが含まれる場合はアンダースコア(“_")で置き換えます。ベンダが正式採用している略称を採用する場合もあります。(例: “Java Runtime Environment" → “jre")
バージョン	製品のバージョンを記述します。
アップデート	製品のアップデートやサービスパック情報を記述します。
エディション	提供方法などのエディション(例:プロフェッショナル版、無償版)を記述します。
言語	製品で使用している言語を特定したい場合に使用します。IETF4646のタグを利用し、日本語の場合は“ja"となります。

情報参照元:IPA 共通プラットフォーム一覧CPE概説
new window https://www.ipa.go.jp/security/vuln/CPE.html

NECが登録しているCPE例)
h:nec:aterm_wf1200c:-:*:*:*:*:*:*:*
o:nec:aterm_wf1200c_firmware:1.2.1:*:*:*:*:*:*:*
a:nec:universal_raid_utility:2.5:rev_2244:*:*:*:*:*:*

尚、CPEはNISTのNVD(National Vulnerability Database:NISTが運営する脆弱性データベース)で管理されており、公式CPE辞書は以下のサイトで参照可能です。
new window https://nvd.nist.gov/products/cpe

製品情報管理の難しさ

昨今、セキュリティへの認知が広まったことや資産管理の観点から、各組織でも製品情報管理を積極的に行っている(または検討している)という話を聞きます。
ただ一方で、「独自書式で製品情報を管理している」「独自書式での管理の為に脆弱性情報管理が難しくなっている」という話もよく聞きます。

それら組織ではなぜCPEによる製品情報管理をしないのでしょうか?
それには以下のような理由が考えられます。

人間の管理には向かない命名規則
CPEは機械が自動処理することを想定した書式のため、人間が管理することには向いていません。
脆弱性が未公表の製品のためCPEが無い
CPEは脆弱性情報が検知された製品情報しか登録されません。その為、CPEが定義されていない製品が世の中には多くあります。
また、新しく販売された製品も脆弱性が検知されるまではCPEが登録されず、その為に「CPEが無い」期間が発生することになります。
同一製品でも複数のCPEが登録される場合がある
買収や譲渡等による提供ベンダの変更、製品名(製品体系)の多様化、略語製品名での登録や誤登録・・・といった理由により同一製品が複数のCPEで登録される場合があります。例えばSUSE Linuxを抽出した結果は以下のようになります。

登録製品の粒度が一定ではない
登録されている製品によってはそのCPEの中に複数の製品が含まれることもあります。例えばRed Hat Enterprise Linux Serverには複数のパッケージがインストールされますが、CPE上では“Red Hat Enterprise Linux Server"という単位で登録されており、個々のパッケージのCPE名は管理されていないこともあります。
またCPEの製品バージョン粒度がベンダの公開単位となっている製品もあり、各組織の管理単位と異なるといった問題もあります。例えば、“Red Hat Enterprise Linux Server"ではCPEの単位がメジャーバージョン(例:“7")で登録されていますが、製品情報管理を行う上ではより細かい粒度での管理が求められる為、マイナーバージョン単位(例:“7.7")で定義されることが望ましくあります。また登録の粒度が製品により一定化していないことにより全体の管理が困難となる問題もあります。

“名寄せ"の必要性

CPE自体は便利ですが、上記のような難点があり、そのままでは製品情報管理やCPEを用いた脆弱性情報管理に使うのは難しそうです。CPEの運用が強化され、製品名の変遷等の対応もケアされ、最新製品のラインナップも早急に対応され、誤登録が早急に是正される・・・ようになるのを待つのには時間がかかりすぎます。
また上記より、各組織で独自の製品情報管理をしている背景には、製品名の変遷や最新製品のラインナップへの追随などが非常に難しく、製品名を選択するためのリストを更新しつづけることができないというものがあり、結局登録するユーザ毎に自由記述となる(そして脆弱性情報管理が困難になる)ケースが多いものと思われます。

ではどのようにすれば現実的にCPEを用いた製品情報管理ができるでしょうか。
解決案の一つとして、ここでは“名寄せ"という処理を挙げます。

“名寄せ"とは様々なCPE情報から製品名を管理体系ごとにマッピング(グループ化)する処理です。
極端な例ですが、先ほどのSUSE Linuxでは以下の様になります。

“名寄せ"では

ベンダサイトの製品体系
過去の製品名変遷
発生している脆弱性情報に関連付けられているCPE名

を十分に調査し、マッピングする製品名を決めます。
この時、マッピングの粒度を「製品の総称にするのか(“SUSE Linux")」「メジャーバージョンにするのか(“SUSE Linux 15")「エディション毎にするのか(“OpenSUSE"、“SUSE Linux Enterprise Server")」等々も脆弱性情報の提供形態や頻度なども考慮して決定しなければなりません。

また、脆弱性未発生の製品に関しても、ベンダサイトの製品体系や過去の同ベンダのCPE名の粒度を加味してユーザ向け製品名を決定する必要があります。それら製品についてはそれ以降も調査を行い、脆弱性情報が発生しCPE名が決定した際にはマッピング済みのCPE名を更新していく・・・といった継続的な作業が必要になります。

上記の様に、管理体系や将来を見据えての製品名の粒度決定は難しく、ある程度の経験やスキルのあるエンジニアが地道に堅実にやっていく必要がある、という状況になっています。
CPEはセキュリティ対策の負担削減のために製品管理のため識別子に着目したことは非常によいと感じていますが、実運用上では、各々で“名寄せ"が必要になるなど負荷削減しきれていない部分もあり、実に惜しいと考えています。