外注したシステムの脆弱性は誰のせい？ 連日の「深刻な脆弱性」にどう向き合い、どう対応するか？（1/4 ページ）

連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。この状況に、企業はどう向き合えばよいのだろうか？　＠ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。

[宮田健, 谷崎朋子，＠IT]

　多くの企業が安心して使っているであろうソフトウェアにも、外注したシステムにも、脆弱（ぜいじゃく）性は存在し得る。連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。「ソフトウェアに脆弱性が見つかった場合、すぐにパッチを適用すること」、これはセキュリティの“基本”だが、言うほど簡単ではないと感じている情報システム担当者の方も少なくないのではないだろうか。この状況に、企業はどう向き合えばよいのだろうか？

　このような問題意識の下、＠ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。今回から2回にわたり、多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。

レポート一覧（クリックで各セッションレポートに移動）

• “バグハンター”は何を見つけ、どう考えるに至ったか
• XSSは「ポップアップ」だけにあらず！ 「勝手にアドミン追加可能」を放置するな
• ＠ITの人気連載著者が語る、「外注したシステムの脆弱性は誰のせい？」
• 脆弱性管理、“やってるつもり”が一番危ない？――カスペルスキー
• 脆弱性診断、静的／動的の欠点を埋めるのは“AI”かもしれない――テクマトリックス
• 侵入防御と内部の感染拡大を視野に入れた包括的なソリューションが大切――ジェイズ・コミュニケーション
• 脆弱性情報を収集、チェックする継続的かつ効率的なソリューションがあれば――NTTテクノクロス
• できる範囲を明確にして内製化する――ソニーデジタルネットワークアプリケーションズ
• 次回は、GEデジタルのセキュリティ対策事例や日本を代表するセキュリティリサーチャー3人の鼎談など

“バグハンター”は何を見つけ、どう考えるに至ったか

　基調講演には、リクルートテクノロジーズ シニアセキュリティエンジニアの西村宗晃氏、そしてJPCERTコーディネーションセンターの久保正樹氏がパネルディスカッションに登場。企業を守る“レッドチーム”メンバーとして、「とあるIT資産管理ソフト」に存在した致命的な脆弱性を発見した事例を紹介した。その脆弱性は既に修正済みながら、この問題から想起できる「本当の課題」について、深く斬り込むセッションだ。

基調講演「リクルートテクノロジーズが、とあるIT資産管理ソフトウェアの脆弱性を発見し、修正されるまで」の様子

　今回きっかけとして取り上げられた「とあるIT資産管理ソフト」の脆弱性は、過去に大きな話題となったものだ。リクルート社内でも採用されており、実際にこの脆弱性を使った攻撃を受けていたという。リクルートのCSIRTチームがその攻撃を特定、調査する上で、「今後、他の製品も同様に狙われるのではないかと思った」と西村氏は振り返る。緊急性を鑑みて、IPAやサポート窓口ではなく直接JPCERTコーディネーションセンターに情報共有したことで、多くの企業に注意喚起が行えた。

　IT資産管理ソフトが狙われたことに関しては、2つの重要なポイントがある。「極めて管理者権限に近い動作ができる」こと、そして「国産ソフトが狙われた」ことだ。

リクルートテクノロジーズ ITソリューション統括部 サイバーセキュリティエンジニアリング部 クオリティマネジメントグループ 兼 インシデントレスポンスグループ シニアセキュリティエンジニア 西村宗晃氏

　西村氏は、このIT資産管理ソフトのエージェント機能に着目。さまざまな機能が実装されていることを紹介する。

　「社員がブラウザで、どのサイトを見て、どんなデータを送ったか。USBメモリを挿してどんなファイルを移動させたか。もちろん、ソフトウェアの遠隔アップデートの実行もできるし、クリップボードにコピーした情報を全てチェックすることもできる。サポートのために画面共有まで行え、極めて管理者権限に近い動作が行える。狙われているのは、その“機能”。それがサイバー攻撃に使われていた」（西村氏）

　そしてもう1つのポイントは、攻撃者が「日本のソフトウェアの脆弱性を狙い始めたのではないか」という点だ。

　「今回の事件が成功体験になったとしたら、攻撃者の考え方も変わるリスクがある。だからこそ、他の資産管理ソフトも同様の攻撃が来たときに大丈夫かを考える必要がある」（西村氏）

脆弱性情報が公開されていない＝安全、とは限らない

　自社で作った製品であれば、開発ライフサイクルにおいてセキュリティを担保するために、脆弱性を発見するための施策を作り込むことは可能だ。しかし他社製品であっても、企業がそれを利用するのであれば、セキュリティの評価をすべきなのではないだろうか。西村氏はそのように考え、PCにインストールしているソフトウェアや、利用しているASPの検査を行っているという。

　「リクルートでは昔から、サービスを使いたいという要望があれば、まずガバナンスとしてセキュリティ対応を行っているかヒアリングをしてから使っている」（西村氏）

　この背景には、自分たちが使っているソフトウェアが、前提として「安全ではない」という考え方がある。

JPCERT コーディネーションセンター 情報流通対策グループ マネージャー 兼 脆弱性解析チーム リーダー 久保正樹氏

　久保氏はJPCERTコーディネーションセンターで公開しているJVNのデータベースに触れ、日々多くのソフトウェアに何らかの脆弱性が存在し、公開されていることを挙げる。

　「JVNで公表された脆弱性は、顕在化した脆弱性をメーカーが事後対応したというリストにすぎない。バグが全くない完璧なソフトウェアが存在しないように、ソフトウェアには何かしらの脆弱性が潜在的に存在しているのではないか、と考えるのが自然。顕在化しているかいないかの違いだけだ。脆弱性がJVNに出ていないから安全な製品であるというわけではない」（久保氏）

　ただし、ここには1つのヒントも隠されている。JVNに掲載されている製品は「脆弱性を見つけたとき、直して告知する対応をしているベンダーのもの」であると考えられる。中には自社で脆弱性を発見したとき、JPCERTに連絡し「JVNに掲載し広く伝えてくれ」と言うベンダーもいる。

　「こういうベンダーは、消費者がベンダーを選ぶ意味でもきっちり評価すべきだ。そういう世界になってほしい」（久保氏）

CVSSスコアをどう受け取るか

　脆弱性を判断するための情報として、共通脆弱性評価システム「CVSS（Common Vulnerability Scoring System）」による「CVSSスコア」がある。しかし、これについて西村氏は「“うのみ”にすべきではなく、個別に判断すべきだ」と述べる。

• 関連リンク：共通脆弱性評価システムCVSS概説：IPA 独立行政法人 情報処理推進機構

　例えば、バッファオーバーフローはメモリを壊し、クラッシュを引き起こす脆弱性であるため、可用性に影響がある。ところが、メモリを壊す攻撃を工夫することで、別のプログラムにプロセスを遷移させることも可能だ。その難易度は高いが、「任意のコードを実行可能」と判断できることで、バッファオーバーフローはCVSSスコアが最大値に近い脆弱性ということになる。

　「生じる影響を自社で判断できないと、CVSSスコアをそのまま受け取らざるを得ない。エンジニアは攻撃者の視点で分析できないと、本当は影響のない脆弱性についても温度感高く対応してしまい、その結果サービスの進化を止めることになるかもしれない」（西村氏）

　リクルート社内では、CVSSスコアではなく「VulnDB」を用いて脆弱性の一次情報のある場所を特定し、実際に一次情報を解析して判断している。この情報をAPI経由で社内のSlackに流し、グループ内の開発メンバー全体に向けて情報を共有しているという。常時、100件程度の情報が毎日流れており、開発メンバーからセキュリティチームへのフィードバックも多いという。

脆弱性情報を収集することから始めよう

モデレーターを務めた＠IT編集部の高橋睦美

　会場からの質問として、「中小規模の企業では脆弱性対策として何ができるのか」という問い掛けがあった。

　「専門家とコンサル契約ができれば一番良いが、費用も高い。単なるアイデアだが、セキュリティ情報をウォッチしている人をコミュニティー内で見つけ、その人に顧問契約を結ぶことができれば効果が高いかもしれない」（西村氏）

　「JVNさえ見ていればいいですか？　とよく聞かれるが、答えは明確にNo。これはあくまで氷山の一角。まずは自社で使っている製品を把握し、脅威となり得るものは何か、それを守るにはどこを見ればいいのかを考え、脆弱性情報を収集してほしい」（久保氏）