Vulsを使った脆弱性チェック運用【セキュリティ対策】

2017-11-29Vuls, セキュリティ

この記事は最終更新日から1年以上が経過しています。

Vulsを使った脆弱性チェック運用を考えてみる

数回に分けて、Vulsを使った脆弱性チェック運用に関して投稿したいと思います。
今回はなんでVulsを使う事になったか、という初めのお話。

Vulsについては、ネット上に何ぞや？といった情報が多くあるので、割愛します。
とりあえずここを見ておけば間違いない。

Vuls GitHub

何故脆弱性チェックをやるのか？

レコチョクもオンプレミス環境でサーバ等運用を行っていた際は、ホストやOS、一部ミドルウェアまでの管理を一つの部隊が一元管理をしていました。
併せてそのホストに対するアクセス許可なども集中管理していました。

ということは、

どのサービスでどんなOSやミドルウェアを使っていて
どのようなアカウントを利用し、アクセス許可設定を行っているのか

という事が、全てとは言わないもののほぼ把握出来る運用になっていました。

ところがAWS移行に合わせて、レコチョクシステム群の運用管理思想を変更(DevOps)し、各ホストの管理の多くが分散される事となりました。

もちろん悪い事では無いのですが、

システム群でどのようなパッケージやソフトウェアを使っているのか、全体を俯瞰する仕組みが無い

状態になってきたのは、このAWS移行が境であると言えます。

その中でもガイドライン等を設け、ある程度標準化される仕組みは出来ていますが、各OSのパッケージ利用状況、パッチ適用状況など、各ホストの脆弱性状態把握 という点は、各担当に任せるといったあやふやなままになってしまいました。

脆弱性チェックをするにあたって

管理しているホストの脆弱性を把握して終わり、だったら全く意味が無いのは誰しも分かっている事です。
何らかの脆弱性を認識したら、パッチをあてたり、構成を変更できないか考えてみたり色々すると思います。

問題は、

管理しているホストに脆弱性があるかどうかをチェックすること自体が面倒 (というかどうチェックすれば良いのかよくわからない)
把握した脆弱性がどれくらいのインパクトがあるか分からない (CVE？JVN？内容が難しい)
管理しているホストが多くて、状況がよく分からない (どこまでチェックしてどこまで対応してるのか…)

という所になるのではないかと思います。

という事は、

自動でチェックしてくれる
結果が見やすい
リスクの大きさがハッキリしている

という点がクリアできる仕組みを導入しよう、というシンプルな考え方にたどり着きます。

併せて、やはりシステム全体のセキュリティ品質の維持という観点から、バラバラに結果を考察するのではなく、
全体を俯瞰、判断軸を統一した方がシステム群としてのセキュリティホール発生リスクを減らせられるのではないかと考え、

全体の結果が俯瞰してみる事が出来る

というのも、一つの要件として組み込みました。

何故 Vuls を選択したのか

レコチョクはAWSにかなり親和性が高い様に環境が構築されています。
そうすると、まず候補に挙がるのは、
Amazon Inspector
です。(機能の詳細は参照してください)

機能比較をするとそこまで大きな差は無いですが、以下観点から今回はVulsを選択しました。

Inspectorはエージェント型である
　既存各ホストにエージェントを追加した場合、そのエージェント起因でパフォーマンス劣化などが発生する事が怖い
Inspectorでは各アカウント内で結果が完結してしまう
　マネジメントコンソール等で各アカウント内の結果は見えるものの、「全体を横断して見たい」となると、APIを駆使して作りこみが必要で、導入と運用工数が増える

この2点が大きい懸念事項となり、Vulsにしようと判断しました。

もちろん、Trend Micro社の Deep Security の様に、多くのベンダーが同様(+α)の製品を出していますが、
個人的にはAmazon Inspectorはコスト的にも機能的にも、今のレコチョク環境には合っていると思っています。
※Deep Securityはじめ、ベンダーの製品がダメとは言ってません、あくまで「今のレコチョク」に合うかどうかの話です

現時点での状況を考えると、Vulsが一番マッチしていた。という事です。
今後の運用や改善検討で他のツールに変更する事は排除していません。
※Vulsを導入する事 が目的では無いので (ここ大事)

つづく。