今回のとことんDevOps勉強会では「システムの脆弱性、把握してますか? 〜 これからはじめる脆弱性管理」ということで、システムに存在するセキュリティ的な脅威となるバグや設定不備の総称である脆弱性に対してどのように対策を取っていくのかをお話しさせていただきました。今回は弊社もパートナーとして取り扱っている脆弱性管理ツールのyamoryを題材に実際の画面を交えながら、脆弱性の管理と対策について紹介させていただきました。Q&Aコーナーでは発表者の水野に加え、yamoryの藤田様にもご参加いただき、様々なご質問にお答えさせていただきました。
振り返りも兼ねて当日の配信の様子をYoutubeでアーカイブしています。当日参加できなかった方も、これを機会にとことんDevOps勉強会に興味を持っていただければと思います。
セミナー動画 - YouTube Live アーカイブ
発表資料 - Speaker Deck
参考リンク
本日、題材とさせていただいたyamoryのWebサイトはこちらになります。
Q&Aまとめ
今回は発表者の水野に加えて、yamoryの藤田様にも回答いただきました。(以下、敬称略)
モデレーター
新村(日本仮想化技術)
回答者
水野(発表者・日本仮想化技術)
宮原(日本仮想化技術)
藤田(yamory)
Q: バックポートの対応は、それぞれのディストリビューションの運営が行っているんですか？主要ディストリビューションで使われているバージョンだとソフト提供側（Opensslとか）が準備したりすることもあるんですか？
A:
(水野)基本的にはディストリビューション側で行っています。
(新村)藤田さんに質問ですが、yamoryとしてはディストリビューションごとの対応策の提示はどのように行っているのでしょうか？
(藤田)yamoryでは各ベンダーからの情報を提示しているので、各ディストリビューションごとの個別の情報を出すようになっています。
Q: ディストリビューションが違うと同じソフトの同じバージョンいてれるつもりでも、セキュリティパッチ当たってたりなかったりで中身は違う可能性があるんですねー・・・
A:
(水野)ディストリビューションの固有パッチも結構あります。セキュリティだけではなく、機能面でもあるディストリビューションだとデフォルトで有効になってる機能が、他のディストリビューションでは無効になっているということもあります。そのため、できればアップストリームのドキュメントだけではなく、ディストリビューション固有のドキュメントなんかも読んでみると良いと思います。
Q: yamoryで脆弱性の確認をするのはどれぐらいの時間がかかるのですか？システム的な負荷とか、サーバーの数が多いときにかかる時間が気になります
A:
(藤田)yamoryはUbuntuでいえばaptといったようなパッケージ一覧をyamoryに送付し、yamory側で脆弱性データベースと突合して、その結果を表示するようになっています。そのため、システム的負荷はほとんどありません。確認する時間に関しても、初回に関してもパッケージ一覧を登録してから10分から20分程度で脆弱性の情報を確認いただけます。その後は、毎日最新の脆弱性情報をアップデートしたものとパッケージ一覧を突合していきます。
また、最初にパッケージ一覧の取得に関してもよほど大量なパッケージを使用していない限り数秒で終わるレベルになっています。
Q: CVEなどの脆弱性の影響があるとして、なかなか単純なバージョンアップも認めて貰えないような場合、どのように説明したらいいものでしょうか
A:
(宮原)これは本当に難しい課題ですね。バージョンアップが行われることを前提として、あらかじめルールやポリシーを決めておいたり、リグレッションテストの効率的なやり方を考えておく必要があると思います。
(新村)こちらの内容、脆弱性管理ツールのベンダーの立場から藤田さんのご意見を伺わせていただけますでしょうか？
(藤田)yamoryを導入していただいている企業様ですとそういうシチュエーションにはなりにくいのかと思いますが、導入しているのであればImmidiateのものは対応しましょうといったルールが必要かと思います。最近ではアメリカ政府からKEV(known exploited vulnerabilities)といった既に悪用が確認された脆弱性のリストがあり、yamoryではそれを表示する機能があるので、それを元に放置しないように説明する方法があると思います。
Q: Ubuntu の脆弱性 で ステータスが Ignored になっているものは脆弱性としては影響するが修正されずに無視されているという理解で合っていますでしょうか？
A:
(水野)はい、その認識であっています。例えば、とあるパッケージの脆弱性が見つかって影響があることが確認されていても、そのディストリビューションでサポート対象外となっているような場合には、ステータスがIgnoredとされ修正パッケージは提供されません。ほとんど全てのケースで、バージョンが古くてサポートが切れているというのがIgnoredに設定される理由です。CVEの詳細にはなぜIgnoredに設定されるかの理由が記載されているので確認すると良いでしょう。
Q: ecrのイメージスキャン(inspector)やsecurity hubだけだとなにか問題ありますか
A:
(藤田)小規模なところであれば、それでも十分だと思います。ECRに置くイメージが増えてきた場合や、AWS以外と組み合わせてマルチクラウドで情報が散逸してしまっているような場合では、yamoryが役立つと思います。他にも脆弱性のステータス管理や高度なトリアージ機能を使いたい場合などはyamoryを使っていただくと良いと思います。
(新村)ユーザーの立場から水野さんのご意見はどうでしょうか？
(水野)一元管理ができるというのが便利だと思います。AWS以外にもGitHubなどいろんなコンポーネントが脆弱性診断の対象となるので、それをyamoryのダッシュボードで一元管理できるのは管理コスト的に非常に良い点だと思います。
Q: 以前問題になった、Log4jのようなもの（ソフト本体ではなくライブラリやAPI）でも、脆弱性管理ツールは検出できるんでしょうか？
A:
(藤田)yamoryではコンポーネントの依存関係を解決してから一覧を取得してyamoryに登録するという仕組みになっているので、依存の末端部分にLog4jのようなコンポーネントが存在していても、yamoryで検知することができます。Log4jの脆弱性が話題になった時も、半日もかからず対象のユーザーには通知を行うことができていました。
ただし、IT資産管理としてIT機器のファームウェアの中でLog4jが使われているといったようなケースでは検知するのが難しいという点はご了承いただきたいと思います。
Q: 問題が起きた時に役職者が全ての責任を負う、というのを明示的に記述して壁に貼っとくとかするしか＞単純なバージョンアップも認めてもらえない
A:
(水野)アプリへの影響を気にするというのもわかりますが、リグレッションテストができないのであれば、プロジェクトのあり方から考え直した方が良いと思います。ただ、あまりOSのセキュリティアップデートでアプリの動作に影響するという話はあまり聞かないですね。
(宮原)ケースとしてはセキュリティアップデートの影響でデフォルトの設定が反転してしまって、突然起動しなくなった経験はあります。塩漬けにしちゃってるような大規模な複雑なシステムは後から対応できなくなるケースはあり得ると思います。そこをそのままにするのではなく、根本からどうやってセキュリティアップデートを適用できるようになるかを議論していかなければいけないと思っています。
(勉強会終了後に追加された質問です。終了後に回答をいただきました。)
Q: ネットワークカメラなど組込Linuxで脆弱性が見つかった場合、ファームウェアが提供されない限り手詰まりになるのでしょうか？
A:
(藤田)ファームウェアが提供されない限りは対応できません。脆弱性情報自体がベンダーから提供されない場合もあるので、その場合はyamoryとしても脆弱性を報告することができません。
