技業LOG
脆弱性スキャンツールVulsとは？
Vuls（VULnerability Scanner）は国産のOSS（オープンソースソフトウェア）でシステムに関係ある脆弱性を含むパッケージ一覧を自動で取得できるアプリケーションです。
Vulsの詳細やインストール手順については開発元情報（最下段にリンクあり）をご覧いただくこととして、本技術ブログでは主に弊社のVulsでの取り組みについてご紹介させていただきますが、前置きとしてまずは簡単にVulsについてご説明させていただきます。
システム構成を簡潔に図示すると下記（図１）のようになります。
初期設定を行えば、一連の動作により脆弱性ホストの検出まで自動実行出来ます。
担当者で手分けして大量のホストを調査する手間が無くなり、また、検出結果についてはWebインターフェース（VulsRepo）でグラフィカルに可視化出来ますので脆弱性を含むホストの見落とし等のミスやリスクも低減出来ます。
| 出来る（良い点） | 出来ない |
|---|---|
| パッケージの脆弱性検知 | ゼロデイの脆弱性検知 |
| 脆弱性ホストの検知 | － |
| 脆弱性パッケージの一覧化（可視化） | 自作プログラミングに含まれる脆弱性 |
| （エージェントレス、SSH接続） | 対応OSではないもの |
- ※2018年2月16日、開発者からのご指摘で記載の仕様に誤りがあったため修正いたしました。
関係者の方々にはご迷惑をお掛けしましたことお詫び申し上げます。
弊社で導入をトライしてみて
弊社の課題
ご紹介が遅れましたが、弊社はInfoSphereブランドのインターネットサービス事業（ISP）とWebARENAブランドのホスティングサービスなどのデータセンター事業を生業としております。
これらサービスを提供するため、多種多様のホスト（サーバ）が大量にあります。
もちろん、OSやパッケージがすべて統一されている訳ではありません。
ですので、重大な脆弱性情報が公表された際には
- 影響有無の確認に稼働がかかる
- 手作業のため、抽出漏れ等のリスクを抱えている
- 各チーム単位での運用となっているため、全社的にサービス（ビジネス）への影響有無の確認がリアルタイムに行えていない
等々の課題を抱えております。
Vulsとの出会いと現場の理解
"手作業なんてナンセンス！"と誰しもが感じている中、Vulsに出会い、昨年4月に設立されたNTTPC-CSIRT※メンバーが中心となり、一部サービスで試験導入を進めました。
- ※NTTPC-CSIRTとは、2016年4月に活動を開始し、NTTPCの各組織で行われているサイバーセキュリティへの取り組みを、全社に対してノウハウ共有/展開を図り、サイバーセキュリティインシデント発生の防止と発生時の適切な対応、および脅威に対し社外各社と連携し（2016年10月にNCAに加盟）全社統制を図る活動を推進している企業内CSIRTです。
試験導入とは言え、実際に導入するとなると、当たり前ではありますが現場の理解が必要になります。
昨今のサイバーセキュリティ状況、自社の課題と目指すべき姿の共有を図り、また、CSIRTでVuls構築手順書を用意するなどの導入支援を行いつつ、現場の理解を得ながら進めて参りました。
実装方法について
Vulsの実装と運用形態については様々な議論がありました。
弊社のCSIRTはバーチャルチームであり、構築運用等の実稼働の捻出が難しく、またNWのリーチャビリティの問題で一括集約型Vulsの導入は困難と判断し、最終的には下記のように各NW（サービス）にVulsを構築する方式で実装することにしました。
具体的にはVulsの構築運用は各チームに任せ、CSIRTはスキャン結果を各チームから共有してもらい、全体を俯瞰して把握出来るような形態にしました。
試験導入を行ってみて・・・
前述しました通り様々な議論、調整を経ましてVulsの試験導入が完了しました。
実際に脆弱性ホストの可視化が出来る状態になると、現場からは
- 分かりやすい！
- これは便利！
- 自チームで認識していなかったパッケージが見つかった・・・（汗）
- 結果はおおよそ想像通り（怖い）・・・
と前向きなフィードバックを得ることが出来ました。
一方で
- やっぱり構築運用が手間
特に初めて構築する場合は若干ハードルがある
CSIRT作成の構築手順書が分かりにくい（改良を重ねる） - 全社展開に当たっては共通基盤があったほうが良い
一括集約型Vulsのほうが効率的ではないか - Vulsのバージョンによってはコマンド体系が異なり、互換性が無く再インストールが手間
Vulsのアップデートが多く再インストールが必要な時がある
都度手順書のアップデートが必要
全社で統一的な運用を図るためVulsのアップデートポリシー等の策定が必要 - 実際の運用ルールはどうするの？
運用ルール、脆弱性対応基準がないと全社での適正運用は難しい
（現在、脆弱性対応基準（案）をCSIRTが中心となって策定中）
等々の課題も明らかになりました。
終わりとまとめ
Vulsがやっていることは「内包されているパッケージに脆弱性を含むものがないかを確認する」という当たり前のセキュリティ対策ですが、このローテクを自動化によりハイエンドに仕立て上げたものとなります。そのため、ゼロデイや辞書データの更新不備を除けば誤検知はほぼありません。誤検知がないセキュリティ対策ってすばらしいじゃないですか！
# 検知できても対策は簡単じゃない、なんて事もあったりはしますが。。。
# でも、脆弱性を検知できず知らないうちに攻撃されるよりはまず実情を知るべきかと。
このツールで試験することで、「入れた覚えのないパッケージも含め、思いの外脆弱性が検出された！」なんてことも弊社の試験運用で見つかっています。今運用されているサーバに脆弱性が含まれていても知らぬが仏･･･なんてことにならないように、脆弱性ホストの把握はきちんとやって行こうと思います。
また、当然のことですがセキュリティ対策には終わりがなく、色々なアプローチがあります。
セキュリティは多層防御が基本ですので、既にネットワーク診断など他の脆弱性検知システムを導入されている方でも、組み合わせでVulsを導入するとより効果が見込めます。
しかし、こちらのツール自体は現在も開発が進んでいるため現在書いているこの記事もすぐに古くなる可能性もあります。最新情報については最下段のリンクをご覧ください。
また、技術評論社から刊行されております「Software Design」誌の2017年11月号にはこちらのVulsの特集も組まれています。ご興味のある方はぜひこちらもご参照ください。
インターネットをより自由に、安全に使えるようこれからも活動を継続していきたいと思います。
- *1Vuls: VULnerability Scanner
https://vuls.io/ - *2IPA 脆弱性ガイドライン
http://www.ipa.go.jp/security/vuln/#section10