脆弱性が発見されたらいつ直す？　セキュリティエンジニアが教える修正パッチの管理方法

パッチ管理とは何だ？

佐分基泰 氏（以下、佐分）：では、さっそく始めたいと思います。佐分基泰と申します。もともとは開発をやっていまして、そのあとインハウスのセキュリティとして診断とかパッチ管理とかをやっていました。現在はyamoryで「DevSecOpsをやるぜ！」ということで、がんばっています。

さっそく本題に移りますが、こんな話をちょっと聞いたことがないですか？　開発者でもいいですし、社内のどこかの人が「この脆弱性がすごい話題らしいぞ」と。「非常に危ないらしいぞ」と。「今すぐ直そう！」と。ただ、この話をされるとき多くの場合、影響範囲とか、あとは何日以内に直す？　そもそもその攻撃というのは世間一般で発生しているのか、みたいな話は特別されずに脆弱性を直そうということが発生します。

まさしく今回の話の主題がこれになります。それを直すために発生するのがパッチというものだと思うんですけど、これを管理するというのでけっこういろいろな問題があります。そもそもパッチ管理とは何だ？　ということですが、簡単に言うと脆弱なモジュールに修正パッチを当てる作業です。問題が発生した場合は何の問題が発生するの？　ということなんですけど、1つ目はだいたい工数的な問題ですね。

どのサーバとかどのサービスにパッチを適用するのかという部分で問題が発生する。非常に多くの脆弱性が発生すると思いますので、工数も限られていて結局どれからやろうかという話になるのかなと。2つ目がそもそもの影響の調査ですね。どのサーバに脆弱性があって、または全社内のサービスにおいてどのサービスが影響を受けるのかという影響調査。ここも工数とかに影響すると思うんですが、影響調査もなかなか難しい。

そして最後がデグレですね。安易にパッチを適用するとサービスが落ちるということもあるので、やっぱりビジネス継続的な話でもそうですし、時間が掛かったりもします。実はまだまだ問題があったりします。

パッチマネジメントは実際やってみると地獄

パッチマネジメントは実際やってみると地獄です。1つ目の問題が、資産台帳を作成する際に非常に時間が掛かる。まず自分のサーバで使われている構成というものを一覧化しなければいけませんよね。例えばTomcat、MySQL、Ubuntuとかのそういった情報と、それらのバージョンというものの一覧を作らなければいけない。そしてこれらはサーバごとに違う可能性があるので、やっぱり非常に煩雑な管理になってしまいますよね。

次にそれらの情報を持ったあとに脆弱性をリストアップしなければいけません。つまりCVEの番号とかCVE情報とかを読んでいって脆弱性をリストアップする作業が必要になってくる。いざ修正を行うとなった場合アップデートを行うと思うんですが、アップデートをしたあとに資産台帳、いわゆる先ほど言ったOSSの一覧ですね。OSSのバージョン一覧とかを更新するという作業が発生します。

そうしないとAのサーバとBのサーバで古いほうは脆弱なサーバになってしまっているということが起こりかねません。このパッチと資産台帳の更新という部分が実はDevOps、アジャイルとかスクラムというものと非常に相性が悪いです。

相性が悪い理由の1つとして、アジャイルやスクラムみたいなイテレイティブな開発において、こちらの開発のリリースサイクルと合わなくなってくる要素に、非常にリリースのサイクルが早いという点があります。1週間2週間でもいいですし、1日N回のリリースが発生した際にそれらの資産台帳を更新するという必要がやっぱり出てきます。

脆弱性の評価は難しいのでルールが重要

CVEが毎日100件ぐらい出るというところでやっぱり厳しい。その上、資産台帳がありません。つまり自分がどのOSSを使っていてどのバージョンであるかという状態がないということですね。そうするとそもそもリストアップで1ヶ月程度掛かってしまう。そもそも脆弱性のどれが危険なんだ？　と。脆弱性を見つけた場合にそれらを評価していくと思うんですけど、どれが危険かわからないとなるとやっぱり評価が難しいです。

その上、さらに開発者間で議論になったりする話だと思うんですけど、これって本当に攻撃されるのかどうかという評価をしてくれと言われることがあります。無理な話なんですけど、そういった話をたまに聞きます。そうなった場合、よくある現場の対応の1つとして、けっこうつらいんですけどCVSSが10点以上は即時対応みたいな。CVEの点数ですね。リスク評価としてリスクが10点以上は今すぐ直しましょうという話になるということです。

でもDevOpsをやっている会社さんでこれをやると「そもそも新規開発に時間が割けないぞ？」という話になったりするのかなと思います。僕らがDevOpsをやっている理由としてビジネスを加速させる話とかがあると思うんですけど、それがセキュリティによってブロッカーとして動いてしまって開発がストップしてしまうみたいなことが起こりかねません。

そもそものメリットであった市場投入までの時間短縮というところがセキュリティのブロックによってなかなかうまく回らないぞということがありえる。だからこそ限られた工数、または攻撃までの時間を考慮した上で適切なルールを作っていくことが重要になります。

運用可能なレベルでルールを作る

そのルールがない場合のお話を1つしていこうかなと。このルールがないとよくある話として、上層部との折衝というのが発生します。よくある話としてサービスを落とすという判断だったときに「これめっちゃ売り上げが落ちるじゃん」みたいな話だったり、あとは「それってどのくらい攻撃されるの？」みたいなことを証明してくれと。先ほどあった話ですね。それを依頼されるケースがあるのかなと思います。

穴が1つでもあればアウトだろという話もそうなんですけど、でも上との折衝では結局悪魔の証明をさせられるみたいなことが起こり得ます。だからこそ先にルールを握っておく。このルールはその上層部もそうですし、チーム内でもそうですし、「このルールでやろう」と言ってネゴシエーション取れましたよねということであれば、みんな「そうだよね」となります。今すぐ直そうねという判断に持っていけるかなと。

そしてその際に重要なのが運用可能なレベルでルールを作るということになります。運用可能なルールを作るために必要な要素は何でしょう。そもそもパッチのルールの要素というのはだいたいこの2つしかないのかなと思います。1つが何を危険とするかという基準、もう1つがいつまでに直すかという期限です。この2つの要素というのは実はめちゃくちゃ難しくて、1つ目の基準というのを深掘りしていくといろいろな要素があります。

例えば内部犯行はどうするの？　どの脆弱性を危険とするのか、内部ネットワークの脆弱性はどのぐらいのリスクとして評価するのか、他にもいろいろとあると思います。期限も難しくて、こちらは決めの問題ではあると思うんですけど、どのくらいの期間で直そうかという話をちゃんと話して内部で決めておかなければいけません。結局めちゃくちゃ難しい。

DoSって危険だと思いますか？

さらに難しい話をもう1個深堀って例としてお話します。

みなさん、DoSって危険だと思いますか？　たぶんこれはいろいろな事業に関わっている人かどうか、開発者のスタンスというので大きく評価が変わってくるのかなと思います。DoSは何せ攻撃者のメリットがすごい少ないです。SQLインジェクションであったりRemote Code Executionというものは内部の、例えばクレジットカード情報、他にはパスワードみたいなデータを盗むことができます。

これらは非常に換金率が高いので攻撃者へのメリットとしては優位だよねという話になるんですけど、DoSの場合だと攻撃者の直接的な換金とかお金をもらうというところにあんまりつながりません。となるとやっぱりSQLインジェクションとかに比べてリスクというのは1段下がります。

また、運用でカバーできるケースもあります。落とされたらrebootしろ、それでも攻撃されたらIPブロックしろ。それでもまだ攻撃してくるならパッチを適用しろみたいな。これはあくまでも最悪なケースであると思うんですけど、他のものに比べるとリスクを1段下げられるというような考え方をする人もいるでしょう。

一方で、ここまでリスクを低減するような話になっていたんですけど、今度は逆で医療とか金融といったサービスに関わる人からすれば、「人の命に関わるぞ」と。「DoSはめちゃくちゃ危険だぞ」ということをおっしゃると思います。結局のところ、脆弱性を評価するというのは非常に難しいということがわかるかなと思います。

ルール作りはまずはライトに始めてみる

そこら辺をしっかりと加味した上でルール作りをしようとなると、けっこう挫折するかもしれません。初めからしっかりやるとここら辺は非常に難しくて挫折すると思います。まず材料がないと判断できないですし、自分たちがどのレベルで運用できるのかというのを把握するためにも、まずはライトに始めてみるのが良いのかなと思います。

ライトに始めるための指標を1つ用意しました。これは危険度がたぶんどの人もおおよそ同じで「これは危険だね」と判断できる要素になります。1つ目がデータ漏洩につながる脆弱性、例えばRemote Code Execution、SQLインジェクション、パストラバーサルみたいなものですね。これらはデータ漏洩につながるから危険です。ここは異論ないと思います。

次は攻撃コードが存在するかどうか。攻撃コードが存在するということはスクリプトキディみたいな脆弱性の内容や攻撃コードを詳しく知らずとも攻撃ができるということになるので非常に危険です。そして最後が外部からアクセスできる領域にその脆弱性があるかです。つまり公開サーバとかにその脆弱性があるかというところで評価をします。

ここら辺の3つの事項をベースラインとして考えていくと、けっこう現実的に一番危険なもの、またはそれ以外のものという判断とかができるかと思います。ただ、この3つの要素は、たぶんみなさんもそういったリスク評価のフレームワークとかないのかと思うので、1つ例を取って見てみましょう。

リスク評価のフレームワーク

リスク評価のフレームワークとしてけっこう有名なものだとDREADというものであったりPASTAというものがあります。それらのリスク評価の要素として脅威モデリングというものとかがあったりします。お時間もございませんので、今回はDREADだけをピックアップしていきます。

DREADなんですが、5つの要素で構成されています。1つ目がどのくらいのダメージを負うのか。次が再現の可能性、簡単にその脆弱性が再現できるかですね。次が攻撃利用可能性。次が影響範囲、ユーザみたいな部分ですね。最後が発見可能性、脆弱性が発見できるかどうかという部分になります。Microsoftは一時期このDREADというモデルを使っていたんですけど、今は使っておりません。

この要素というのは先ほど言った危険度の共通認識というものとおおよそ同じです。データ漏洩につながる脆弱性というのは潜在的な損害、ダメージの大きさと影響ユーザ数というところにおおよそつながってきます。攻撃コードが存在するかどうかというのは再現可能性、発見可能性というものにつながります。最後の公開サービスかどうかというところは攻撃利用可能性という部分につながってくるのかなと。

要素としては網羅とはいかないですが持っているだろうと思うので、ここら辺をベースにルールを作ってみるといいのではないかと思います。逆にこれ以上やろうとするとけっこう厳しくて、例えばリスク評価が難しくなる要素を以下に2つ用意しているんですけど、この2つを入れるとけっこう難しくなったりします。

1つ目が各資産の重要度、例えばAのサーバで個人情報を扱っている、Bのサーバだと個人情報じゃないデータを扱っているとか。そこをさらに難しくしていくと、個人情報の中で機微な情報をAは持っているけどBは持っていない。その場合にそれらの資産を含めた上でこっちのほうから早急にパッチを当てようという話になると、けっこう厳しくなってきます。

もう1つが厳密に攻撃される可能性。つまりThreat Modelingみたいな話ですね。内部犯行もあり得るよねというところまで適切に評価をしてハンドリングするとなると、どうしてもリスク評価をするためだけにけっこうな工数や時間が掛かります。

もちろんここら辺もしっかりとやることでより適切なパッチマネジメントができるものの、今回最初にお話ししたDevOpsでビジネスを止めないためにも必要なリソースがあまり割けないぞというところであれば、こういったリスク評価が難しくなる要素というのはあまり入れずに、カジュアルに始めるほうがいいだろうと思っております。

なので、先ほど言った危険度の共通認識という部分とかをベースにルールを作ってみるのはいかがかと思います。「リスク評価のやり方はなんとなくわかったよ」では次は「結局パッチ対応はどうするんだ？」ということになります。

カジュアルに始めるのであれば簡単にある程度の情報は収集

パッチ対応も実はいろいろなレベルがあります。1つ目がみなさんよくある話だと思うんですけど雰囲気のパッチ対応。脆弱性が出て「今すぐ直そうぜ」という感じですね。もう1つが今回お話した内容、危険度とかそういったものを優先度付けして「これは危険だから今すぐ直そうぜ」「これはルール上何週間か遅らせてもいいレベルだから置いとこうね」とか。

もう1つがそこからさらに上ですね。攻撃コードの調査、及びそれが実際に刺さるかまで試してみるという点になります。ここからさらにやるのであれば厳密なリスクアセスメント。内部犯行で、内部の人間はどれくらい危険なのか。どういったロールが危険でどういったロールは危険じゃないかみたいな話とか、そういったところまでやっていくのかどうか。

今回ここにレベルを4つ紹介したんですけど、そもそも攻撃コードってどうやって調べるんだ？　そもそもどうやって収集するんだ？　という話があります。カジュアルに始めるのであれば実はけっこう簡単にある程度の情報は収集できます。簡単にやるのであればTwitterとかGoogleとかExploitDBと呼ばれるサービスとかでCVE番号とかで調べて見ていただけるといいかなと。

Twitterの場合だとCVE番号＋PoC、Proof of Concept、その脆弱性を実証するためのコードですね。この2つの単語で検索していただけると、その脆弱性を実証するためのPoCを呟いている人がけっこういたりします。これが呟かれているということは、それだけ話題がある脆弱性だよねという判断にもできるので実際に脆弱性を評価する際はそこら辺をやってみるといいと思います。

実際にPoCを見つけてこれを試そうというレベルまでいったのであれば、例えばDockerを使って脆弱な環境を用意していただければいいのかなと。用意をしたらPoCコードが実際にマルウェアでないことを確認した上で脆弱なサーバに刺さるかをテストしていただければいいと思います。

PoCの中にはやっぱりマルウェアというのもあったりするので、内部のコードが怪しいぞとなったらむやみやたらに使わないほうがいいですし、それでもやっぱりちゃんとリスク評価をしたいということであればマルウェア解析の環境とかを調べていただいてそこら辺を参考にしつつやっていただければいいのかなと思います。

まだ何もやっていないようであれば、まずは実際に始めてみる

ちょっと最後がドタバタしてしまいましたが、まとめに入りたいと思います。

パッチ管理の最初の一歩として、まずはルールの仮組みとかをしてみていただければいいのかなと。中にはSIRTとか、そういったセキュリティのチームが存在する場合もあると思いますし、そういった会社さんとかですとここの話は既にやっているということをおっしゃるとは思うんですが、まだやられていないようであればパッチ適用のルールを作ってみるのもいいのではないかと思います。

そして作ったら、次はサーバのライブラリとかを少なくとも軽く一覧化してみればいいかなと。バージョンまで厳密に管理するのはきついというのであれば、一旦はライブラリ一覧でもいいのでそれを実施していただければいいでしょう。そうするとCVE情報とかを雑にフィルターできたりするので、そこら辺をフィルターしてより簡単に始めてみていただけるのかなと思います。

そして最後はルールによって評価をして、これは今すぐにやらなくてもいいよねという判断がある程度できて1つ上のステップに進めるのかなと思います。

ちょっと蛇足ですがDevSecOpsというのはやっぱりDevOpsの延長線上にあるのかなと思います。ビジネスを止めてもいけないですし、何よりエンジニアの1つの要素としてセキュリティがあります。だからこそそれらを天秤にかけてどちらを重要視するということではなく、うまくバランスをとって現実的なレベルでセキュリティを強化していくというのが非常に重要だと思っております。

まだ何もやっていないようであれば、まずは実際に始めてみてはいかがでしょうか。まだ始めていないのであれば何をやってもプラスになります。そして最後は自分のアプリは自分で守っていければいいと思うので、みなさんでよりセキュアな世界を築いていけるようにがんばっていければいいなと思います。

本当にドタバタとしてしまいましたが、以上で発表を終わりたいと思います。ありがとうございました。