NECセキュリティ技術センターの郡です。NECは2021年3月30日、CVE(Common Vulnerabilities and Exposures)採番機関であるCNA(CVE Numbering Authority)となりました[1]。これにより、NECは内部や外部から報告された自社製品の脆弱性に対して独自にCVEを付与することが可能となりました。今回はCNAの制度やその周辺の活動を簡単に紹介します。
CVE (Common Vulnerabilities and Exposures)付与とその需要拡大
CVEは脆弱性に対して付与される一意の識別番号です[2]。MITRE社によって採番が行われており、「CVE-2021-○○○○」といった形式で、付与された年と連番の数字によって構成されています。2021年4月時点で15万以上の番号が脆弱性に対して付与されており、毎年数千、ここ数年は1万以上ものCVEが新規に登録されています。
CVEは一意に識別されるため、異なるプラットフォーム間でも情報を共有できるというメリットが存在しており、脆弱性識別方法のスタンダードとなっています。このためCVE番号の付与は非常に需要の高い作業なのですが、前述したとおりその対象範囲は急速に拡大しているという課題が存在しました。そこで迅速にCVEを付与する仕組みを維持するため、分散したCVE採番の仕組みが採用されました。この仕組みがCNA (CVE Numbering Authority)です。
CNA (CVE Numbering Authority)
CNAは、事前に合意した範囲の製品に影響を与える脆弱性に対して、独自の判断でCVEを付与することをMITRE社によって許可された組織のことです。NECはNECグループの製品であればこの判断を行うことが可能となります。
CNAは以下の図のような階層構造になっています[3]。(一部省略)
最終的な仲裁者であるTop-Level Root CNAを頂点として、その下にRoot CNAとSub-CNAが存在しています。Root CNAはCVEプログラムの管理部門で、新しいCNAを募集、トレーニングを提供、Sub-CNAの管理等の活動を行う機関です。日本ではJPCERT/CCがRoot CNAとして2018年に認定されており、さらにその下に日本のCNA組織が存在しています。NECはSub-CNAに該当し、現在日本ではNEC含め三社がJPCERT/CCをRootとするCNAとして活動しています[4]。なお、Root CNAやSub-CNAと言った呼び方はCVEプログラム内でも議論があり、Root CNAをRoot、Sub-CNAをCNAと呼んでいる場合もあります。
補足ですがCNAの登録地域は本社機能の位置で決定されるため、海外での取引がメインでも日本に本社が存在すれば、登録地域は日本となります。
CVEの取得は通常CNA組織に依頼をするしかないため、脆弱性ハンドリングに関わる組織や人間の数が増えてしまいスケジュールの合意などが難しくなる場合があります。自組織で採番可能な場合このような調整を一本化出来るため、脆弱性ハンドリングをスマート化できると考えています。
Sub-CNAの役割とルール
Sub-CNAは実際にCVE番号を割り当て、CVEのコンテンツを作成する組織として活動します。
Sub-CNAのルールはMITRE社によるCVE Numbering Authority (CNA) Rulesによって定められています。CNA以外にも影響のあるルールを以下にいくつか抜粋して掲載します。[5](日本語訳は筆者による)
- CVE付与のルールに従うこと
CVEの付与は漠然と行われているわけではなく、定義されたルールに従って実施されています。このルールはCVEプログラムによって制定されたルールですので、一般的に呼称される脆弱性の考え方とは一致しない場合も存在しています。
例えば「別の脆弱性に依存する脆弱性に対してCVEを付与してはならない」といったものが存在しています。これは、ある製品に脆弱性Aと脆弱性Bが見つかったとして、脆弱性Bは脆弱性Aの修正によって影響がなくなるような場合を指します。ある脆弱性を起点に複数の脆弱性が見つかることは珍しくありませんが、この起点に依存する脆弱性にはCVEを付与しない決まりとなっています。
この他にも、「公開するつもりのない脆弱性にはCVEを割り当ててはならない」、「利用者のアクションが必要ない場合にはCVEを割り当ててはならい」といったルールも存在しています。前者はCVEの存在理由が脆弱性の一意識別とその共有にあることを考えれば理解していただきやすいと思われます。後者は利用者によるアップデート処理等が必要か、そうでないかを意識したルールです。例えばSNSで提供されているサービスで問題があり、利用者のプロフィールなどが意図せず公開される脆弱性が見つかったとします。一般的には脆弱性として認識される問題ですが、サービス提供側の修正のみで問題が解決する場合、CVE番号は付与しないといった処理が行われます。
このようにCVEの付与は一般的な脆弱性の考え方と異なる部分がいくつかあります。JVNに情報を掲載しているベンダの方や、脆弱性研究を行っている方は一度このルールを確認しておくと、CVE番号の取得の際に混乱が生じないかもしれません。
- 誰でも閲覧可能かつ、スコープ範囲内の脆弱性公開ポイントを持つこと
脆弱性公開アドバイザリのページを想像していただくのがよいと思われます。誰でも閲覧可能であることが条件のため、有料サポート限定サイトなどは該当しません。アドバイザリは広く一般に公開されていることが脆弱性ハンドリングの基本と言えます。
- 開示ポリシーの公開
連絡方法や受け取った脆弱性情報をどう取り扱うのか、期待するやり取りなどを記載したポリシーページを用意する必要があります。
複数製品を製造している企業でポリシーページを用意していない場合、国内からの報告であればIPAが受付けてJPCERT/CCが仲介してくれますが、海外からの報告の場合はこのようにはいきません。発見者が窓口を見つけられなかった場合、脆弱性を一方的に公開してしまう可能性が存在しています。
上記アドバイザリページやポリシーページはCNA一覧サイトにリンクがあるため、今後同様のページの作成を考えられている方は参考になると思います[4]。
これらのルールはCNAに参加しない場合も、脆弱性ハンドリングを行う中で参考になる考え方と思われます。興味があれば他のルールもご参照ください。
おわりに
CVEプログラムにはいくつかのWGが存在しており、上記のルールも含めた話し合いが行われています[6]。脆弱性の考え方や定義はクラウドコンピューティングの時代になったことで大きく変化しており、初期設定などこれまでは仕様で片付けられてきた問題がその範疇に収まらなくなっていくことで、CVEのあり方も変化していくだろうと考えています。
既にCVEが脆弱性識別のスタンダードとなっている以上、CVEの考え方が脆弱性の考え方に影響を与える立場になっています。脆弱性研究やハンドリングに関わる方は、是非CVEプログラムの状況を追跡いただければと思います。
参考文献
[1] https://cve.mitre.org/news/archives/2021/news.html#March302021_NEC_Added_as_CVE_Numbering_Authority_CNA
[2] https://cve.mitre.org/about/faqs.html#pc_cve_records
[3] https://cve.mitre.org/cve/cna/rules.html#section_1-2_cna_program_structure
[4] https://cve.mitre.org/cve/request_id.html
[5] https://cve.mitre.org/cve/cna/rules.html#section_2_sub_cnas
[6] https://cve.mitre.org/working_groups.html
執筆者プロフィール
郡 義弘（こおり よしひろ）
セキュリティ技術センター インテリジェンスチーム
脅威情報の収集や展開、活用法の検討とともに、PSIRTとして脆弱性ハンドリングに従事。CISSP Associate、情報処理安全確保支援士(RISS)、GIAC(GCTI)を保持。 山の上からセキュリティを見守りたい。