CVE採番機関CNAの今／ウェブプライバシー保護技術の比較

CVE採番機関CNA（CVE Numbering Authority）の今

　脆弱性の識別子として国際的に使用されているCVE（Common Vulnerabilities and Exposures）番号は米国政府の支援を受けた非営利団体MITRE社が採番しています。しかし、現在はMITREだけでなく、CNA（CVE Numbering Authorities、CVE採番機関）として認定された複数の企業や団体などがCVE番号を採番できるようになっており、本稿執筆時点では世界の14の国や地域で合計80ほどのCNAが存在しています。日本では、2010年6月に国内初のCNAに認定されたJPCERT/CCを含め、3つのCNAがあります。

　そこで今回は、今年の1月1日から適用されるようになった「CVE Numbering Authorities (CNA) Rules, Version 2.0」の内容とともに、CNAの現状について簡単に紹介します。

　まず、CNAには「Primary CNA」「Root CNA」「Sub CNA」の3つのCNAが存在します。これらの関係を示したのが図1です。

図1（CNA Rules Version 2.0より抜粋）

　Primary CNAは現時点でMITRE社のみであり、Root CNAはDistributed Weakness Filing ProjectとJPCERT/CCの2つのみです。また、図1が示すようにRoot CNAの管理下に別のRoot CNAを置くこともできるようになっています。

　Root CNAを含め、CNAには、CERT/CCやICS-CERT、JPCERT/CCのような公的機関（「National and Industry CERTs」と分類）だけでなく、さまざまな企業や団体もなることができます。例えば、MicrosoftやApple、Google、Trend Micro、Symantecといった民間企業をはじめ、Debian GNU/LinuxやFreeBSDといったオープンソースのプロジェクトもすでにCNAとして認定されています。これらは「Vendors and Projects」と分類され、基本的に自組織の製品の脆弱性に対して採番を行います。CNA全体ではこの「Vendors and Projects」に分類されるCNAが圧倒的大多数を占めています。

　ほかにも「Vulnerability Researchers」と分類されるCNAも存在します。これらは主にセキュリティベンダーで、基本的に自ら発見（分析）した脆弱性に対して採番を行います。現時点では、6つの企業（Airbus、Duo Security、IOActive、Kaspersky Labs、Rapid7、Talos）と1名の個人（Larry Cashdollar氏）の計7つのCNAが認定されています。

　さらに、まだ2つだけですが、HackerOneやZero Day Initiativeといった「Bug Bounty Programs」もCNAに認定されています。

　このように、公的機関や企業だけでなく、セキュリティ研究者個人やBug Bounty ProgramsもCNAになれるようになったことでCNAの数は急激に増えています。情報処理推進機構（IPA）の活動報告レポート「脆弱性対策情報データベースJVN iPediaの登録状況［2017年第4四半期（10月～12月）］」によれば、2016年12月から2017年11月の間でCNAの数は約1.7倍に増えており、このCNAの増加が、CVE番号が振られ、脆弱性情報データベースNVDに登録されて公開される脆弱性の数が急増している理由の1つなのではないかと見られています。

　日本ではJPCERT/CCを含めてもCNAはまだ3つしかありません（米国54、中国6）。自組織の製品の脆弱性に対応している企業や団体はもちろん、脆弱性を発見しているセキュリティベンダーや研究者の皆さんも、CNAになることを一度検討してみてはいかがでしょうか？　なお、CNAとして認定される方法についてはCVEのページに「How to Become a CNA」として掲載されています。

ウェブプライバシー保護技術の比較

　ウェブブラウザーの拡張機能の中には、プライバシー保護を目的にトラッキングされないようにしてくれるものがあります。また、広告やスクリプトなどをブロックする機能も結果としてプライバシー保護の役割を果たすことがあります。これらのウェブプライバシー保護技術の「性能」を調べて比較した研究論文「A comparison of web privacy protection techniques」がフランスと日本の研究者らによって発表されました。ただし、本稿執筆時点ではレビュー前（pre-review）の論文のみが公開されている状態なので、結論を含め、内容が修正される可能性があることに気を付けなくてはなりません。

　論文では、プライバシー保護の観点で最高成績を収めたのはRequestPolicy ContinuedとNoScriptであるものの、ウェブページの表示品質が悪い（表示が崩れる）ので、プライバシー保護とのバランスを考慮するとGhosteryとuBlock Originが最も良いと結論付けています。その一方で、GhosteryとuBlock Originは手動で作られるブロックリストに基づいているため保守が面倒であるとも述べており、今後の研究は、Privacy BadgerやMyTrackingChoicesのようにブロックリストによらない方法の改善や信頼できるブロックリストの自動構築に注力すべきとしています。

　調査に使用したものは表1にまとめられています。ここで「RPC」はRequestPolicy Continuedです。また、調査にはOpenWPMとFirefox 45を使っています。

表1

　調査方法としては、Alexaが公開しているアクセス数ランキングで上位にあるサイトへのアクセス（crawling）を行ない、アクセスしたサイト間でCookieなどを通じて情報が漏れる可能性がないかを調べています（厳密にはもっとはるかに複雑な方法で精緻に調べています）。

　ウェブページの表示品質については、アクセスしたページのHTMLを解析し、プライバシー保護機能が有効な場合に失われる要素の数を調べるなどして判断しています。

　RequestPolicy ContinuedやNoScriptがプライバシー保護の観点では「最高」でも、GhosteryとuBlock Originのほうが実用的という結論は、実際にこれらを使ったことがある人にとって全く違和感のないものです。しかし、GhosteryやuBlock Originでも表示が崩れることは多々あり、「使いこなす」にはそれなりに知識が必要であることも事実。一般の方に勧めるのは少々はばかられるものがありますし、まだまだ改善の余地はあるでしょう。

　なお、研究者らはFirefox以外のブラウザーでも調査することを計画しているようです。また、近年は標準でプライバシー保護機能を有しているブラウザーも増えてきているので、そのような標準機能との性能比較など、今後の研究にも注目したいところです。