「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点：セキュリティ・アディッショナルタイム（16）（2/2 ページ）

[高橋睦美，＠IT]

バグハンターが得た、報奨金以外のメリットとは

リクルートテクノロジーズのサイバーセキュリティエンジニアリング部 シニアセキュリティエンジニア、西村宗晃氏

　次に、リクルートテクノロジーズのサイバーセキュリティエンジニアリング部 シニアセキュリティエンジニア、西村宗晃氏が「脆弱性発見者の目から見た、脆弱性対応の最前線」と題するプレゼンテーションを行った。同氏はリクルートグループのセキュリティ業務を行う傍ら、プライベートではバグハンターとしても活動し、FirefoxやChromeなどWebブラウザの脆弱性を多数発見している。

　そんな同氏がバグハンターの道に踏み出したきっかけは、セキュリティキャンプの講師に選ばれ、自分の能力を示す手段が欲しいと思ったことだった。「脆弱性報奨金制度ならば、報奨金の額が、実力を可視化する1つのものさしになると思った」（西村氏）。ただ最初に脆弱性を見つけるまでは苦労し、7カ月間にわたって奮闘した末に発見したという。

　実際にバグハンティングに取り組んでみて得られたメリットは金銭だけではない。「確かに報奨金ももらえるが、何よりセキュリティエンジニアとしての基礎力が付いたことが大きい。難解なコードを読み解いたり、『この先、問題はないだろう』という先入観にとらわれず、コードを検証する力が身に付いた」と西村氏は言う。「今も、技術力の維持、向上と、瞬発力を保つために取り組んでいる。ローン返済も理由の1つだが（笑）」（同氏）。

　1000万円近くの報奨金を稼いできた同氏が脆弱性を見つけるために実践していることは2つある。1つは「既知の脆弱性に学ぶこと」。過去の脆弱性を調べ、攻撃コードを作って検証してみると、過去の脆弱性が形を変えて出てくることがままあるという。Webブラウザは頻繁にアップデートされるが、新たに加わったコミッターが古い脆弱性を再び作り込んでしまったり、リファクタリングの際にリグレッションが起こることもたまにあるそうだ。

　もう1つは「仕様に学ぶこと」。「IETFやW3Cが出している標準仕様やRFCを読み比べていくと、仕様の間で漏れが見えてくることがある。仕様書の『Security Considerations』やリスク分析の結果を見るだけでも知見が得られる」（西村氏）。これをベンダー側から裏返してみると「何か脆弱性が見つかったら水平展開して、（コードの中の類似の問題を）全部見つけ切ることが大事だと思う」と同氏は指摘する。

　また、見つけた脆弱性を通知した後のベンダーの対応についてはどうだろうか。「脆弱性への温度感は、ベンダーによって全然違う」と西村氏。同じような脆弱性を報告しても、1年ほど放置され、忘れたころに連絡が来るようなベンダーもあれば、素早くレスポンスがあり、コードも速やかに修正されるベンダーもあるそうだ。

　「中でも、Firefoxを開発しているMozillaのチームとは気持ちよくやりとりできる。なぜかというと、脆弱性への対応状況の透明性が非常に高いから。脆弱性を報告すると、Bugzillaに関係者のみ公開の状態で情報が登録され、誰がアサインされ、いつ直すかがリアルタイムにトラッキングできる。既に同じ脆弱性を指摘済みの場合はリジェクトされるが、その際もBugzillaのチケットという根拠が示される」（西村氏）。修正の早さも相まって、バグハンターから見て非常に好感度が高いそうだ。

　「Mozillaはセキュリティを高めることにプライドを持っているし、そのためにセキュリティ担当者には、緊急リリースを行う権限が与えられているようだ」（西村氏）

　さまざまなベンダーや調整機関に届け出を行ってきた同氏が思うのは、「きちんと脆弱性について理解している人を張り付け、対応できる体制を整えてほしい。そして、対応状況を共有できる体制を整えてほしい」ということだ。「届け出を行ってから全く連絡がないと、脆弱性が悪用されないかとハラハラしながら待つしかない。ぜひ発見者と定期的なコミュニケーションを取ってほしい」（西村氏）。過去には、連絡があまりに遅いことに業を煮やした発見者が脆弱性情報を公開してしまったこともあったが、これではユーザーもベンダーも発見者も、誰も幸せにならない。

　西村氏は本業では、リクルートグループのセキュリティ運用に携わっている。といっても脆弱性情報の受付窓口ではなく、公表された脆弱性情報を分析し、対応する立場で、サービスのセキュリティ強化を支援している。

　「脆弱性情報提供サービスも使っていたが、タイムラグと情報の網羅性に課題を感じていた。加えて、CVSSだけでは、自社の環境における深刻度評価と一致しないこともある。このため、自分たちで脆弱性情報収集と深刻度評価を行っている」（西村氏）。

　具体的には、RSSやTwitterを活用して一次情報収集を行うと同時に、JPCERT/CCの早期警戒パートナーシップに加わり、公表前の脆弱性情報も入手しているという。また深刻度評価は自社環境に基づいて行い、可能な限り修正パッチの内容も確認して対応方針を決めているそうだ。「修正パッチのソースコードを確認すれば、攻撃コードがすぐに出てきそうかどうかが分かる。MetasploitのGitHubのpullコードもチェックしている」（西村氏）。こうした工夫と努力によって、CVSSの数値だけを見て慌てることなく、緊急対応を実施する、しないの判断を下しているという。

　バグハンターと会社員の二足のわらじは大変そうだが、西村氏は「脆弱性を見つける個人の活動と、セキュリティ品質を高めるという会社の仕事が相互にリンクできている。このシナジーを通じて今後もセキュリティ向上に寄与したい」と述べた。

修正適用作業を少しでも楽に、滅びの呪文じゃない支援ツール「Vuls」

フューチャーアーキテクト テクノロジーイノベーショングループ シニアスペシャリスト 神戸康多氏

　最後のセッションでは、フューチャーアーキテクトのテクノロジーイノベーショングループ シニアスペシャリスト、神戸康多氏が、システム運用の現場で脆弱性対応を支援するオープンソースのスキャンツール「Vuls」を紹介した。

　脆弱性情報は年々増加の一途をたどっており、2016年には1万件を超えるCVEが登録された。神戸氏は「IPSやIDSでは防げない脆弱性も存在する。根本的な対策はアップデートだが、その作業は手動によるものが主流だ。しかし、年に出てくる数千件もの脆弱性情報を収集し、影響範囲を確認し、テストを行った後にアップデートを実行するのはかなり大変な作業だ。それも、漏れなく行う必要がある」と述べる。

　神戸氏自身、システム運用管理業務の中で多数のサーバの脆弱性管理に携わることになり、あまりの作業負荷に「怒り」すら覚えたこともあったそうだ。「Linuxと一口に言っても、ディストリビューションもアプリケーションもコンパイラもバラバラな環境で脆弱性に対応するのは本当に大変だった」と同氏は振り返る。

　それをバネに開発したのが、LinuxやFreeBSDを対象に、脆弱性情報の収集と影響範囲の確認を自動的に行ってくれるVulsだ。Vulsは、複数の脆弱性情報データベースから情報を収集し、突合した上で、どのサーバにどの脆弱性が影響するかを知らせてくれる。オンプレミスだけでなくクラウド環境もサポートしている他、RedmineやSlackといったツールとの連携機能も備えていることも特徴だ。

　「『脆弱性に速やかに対処すること』と言葉で言うのは簡単だが、実作業の負担に悩む管理者は多い」（神戸氏）。Vulsは、公開後1週間でGitHub Trendingで4位に入るほど注目を集めたという。セッション参加者の中には実際にVulsを活用しているユーザーもおり、「これがあるとやっぱり楽です」とコメントしていた。