前回は piyokango さんによる「変化」のお話しでしたが、今回は「脆弱性への対応をどのように行なっていくか」トリアージや対処をテーマに根岸さんから課題の提案がありました。CVSS の基本値を基準とした対応を続けていて果たして良いのか、もう少し広く視る必要があるのではないか、CVSS に代わる管理手法や評価指標を紹介いただき、組織がどのように取り組んだら良いか議論されました。
脆弱性への対応
根岸さん：piyokango さんの脅威のお話に呼応する形で、今度は脆弱性の側から見た現在の課題について紹介したいと思います。
脆弱性の対応と言っても、いろんなフェーズがあります。脆弱性の対象を把握するところから、脆弱性の有無をいかにタイムリーにキャッチアップするか、見つけた脆弱性が自分達に影響を及ぼすのか（対応の有無・緊急性など）の分析及び評価、そして最終的には修正（場合によってはインシデントの対応）を行います。その中で、主に3番目「脆弱性の分析・評価」と、4番目「脆弱性の修正」について議論をしたいと思います。
脆弱性対策、脆弱性管理
少し話が逸れますが、ちょうど今週（10/4）、米 CISA が法的に拘束力のある指令 Binding Operational Directive（BOD）を出しました。この1番目「脆弱性の対象の把握」と、2番目「脆弱性の確認」をやるように政府機関向けに求めるもので、詳しくは、あとで BOD 23-01 を参照いただきたいと思いますが、自分達が管理するネットワーク上の資産の可視化を7日ごとに開始、脆弱性の検出を14日ごとに開始、無理な場合の条件も付いていますが、基本的には毎週と隔週実施について命令が出ています。
これは、かなり踏み込んだなと。CISA は脆弱性の対応を連邦機関向けにやっていますが、そもそも前段の把握する部分というのは抜けていた感じがあるのでここで出してきたなと、まさにそこが大事というのを海の向こうでもやっているんですよね。これはアメリカだけの話ではなく、我々民間も官公庁もこれからしっかり脆弱性の対応をやっていかないと対策できないという事を、ちょうど良いタイミングで出ていたので、キーワードだけご紹介します。
「脆弱性の分析、評価」と「脆弱性の修正」ですが、脆弱性もライフサイクルと言われるものがあります。脆弱性を意図的に作ることはないと思いますが、①バグを作ってしまい、②内部のレビューや外部からの指摘で発見、③報告ないしは報告なく勝手に公開され、④それに対してベンダーがパッチを出す、⑤そうすると必然的にそれを攻撃するコードが出る場合があって、⑥コードが出たら実際に攻撃が来る、普通ならこういう順序ですが、稀にパッチが出る前に攻撃コードが出ることや、実際に攻撃がくるゼロデイという場合もあります。実際のところ、どんなフェーズ、タイムスパンでやってくるのかあまり知られてないと思いますが、これを調査した事例をご紹介します。
脆弱性のライフサイクルと攻撃活動
アメリカのセキュリティ企業 Kenna Security 社が出しているレポート「Prioritization to Prediction Volume 6」ですが、2019年の CVE 1.8万件以上のうち、実際に攻撃が観測された脆弱性は473件で、実際には数パーセントなんですよね。そこから更に473件を分析すると、「パッチ公開前に1/3の脆弱性は攻撃コードが公開されている」、「パッチ公開から2日以内に5%、1ヶ月以内に45%の脆弱性で攻撃が観測されている」、「攻撃コード公開前から攻撃が観測される脆弱性は30%、公開後1ヶ月以内に56%の脆弱性で攻撃が観測されている」このようなデータが出ています。
何が言いたいのかと言うと、パッチが出て、攻撃コードが出て、攻撃が来る、この通りに行けば良いですが、そうはならないケースが結構あります。実は、パッチが公開されるタイミング、更にそれよりも攻撃コードが出るタイミングがキーになっていて、これらのタイミングを抑えられるかどうかで、その後の攻撃に対応できるかの命運が分かれるんですよね。
でも、脆弱性って年間に2万件から3万件あるわけですよ。やってられないじゃないですか。ただ、実際に攻撃が来るのは数百件とかごく一部なんですよね。これらをどのように見つけ、優先順位高く対応を進められるか、というのがキーワードで、これが多くの企業の課題なんじゃないかと思っています。
CISA が発表した「2021年に米国で最も悪用された脆弱性」
今年、CISA が「2021 Top Routinely Exploited Vulnerabilities」を発表しました。これは主にアメリカ国内の話で、2021年の１年間に最も攻撃が観測された脆弱性についてまとめたレポートです。ポイントとしては、2021年に観測された脆弱性ではあるものの、2020年や2019年など少し前の脆弱性もトップ15に多く含まれていて、相変わらず狙われているんですよね。これは、絶対見逃してはいけないポイントだと思っています。最新のものだけが常に攻撃されるわけではなくて、実は2,3年くらい前の古いものも有効だから攻撃されているわけですよ。そこを忘れてはいけない。ということは、放置されている脆弱性がたくさんあるということですよね。もしかしたら把握していなくて、さっきの把握するフェーズが抜けていて、自分達は使っていないと思っているけど、実は攻撃されているケースもある。これも頭に入れておいてほしいです。
対策の優先順位
アメリカのセキュリティ企業 Flashpoint 社が今年出したレポートで、2022年上半期に収集した脆弱性11,860件のうち、27.3%は CVE/NVD に未報告または詳細データ無しでした。実際には CVE が付いていないものが多くあります。ざっくり言うと、ここ2､3年は年間2万件くらいCVEが出ていますが、実際はもっと多くて把握できていないものが結構あるので3万件以上はあるんですよ。
Flashpoint 社が収集した脆弱性11,860件のうち、(1)リモートから攻撃可能、(2)攻撃コードが公開されている、(3)有効な対策がある、の3条件を満たすものは、2,081件 (17.5 %)でした。リモートから攻撃可能で攻撃コードも出ている、でも攻撃に対する有効な対策があるというのがポイントで、対策のないものにいくら対応しようと思っても難しいですが、まずは対策があるところに注力しよう、ということです。
脆弱性の対応について最近の傾向と課題
根岸さん：脆弱性対応についての最近の傾向・課題ですが、特にパッチが出てから攻撃が来るまでのスピード感は、今は1日足らずで観測されています。以前は１週間以内にパッチをあてればいいと思っていたのが、スピード感が変わってきているという報告が散見されます。
その他、提供側が脆弱性と認めず仕様として扱われているものや、設定の不備ですね。具体的な事例として、今年国内のクラウドベンダーで負荷分散の装置を攻撃された事例があって、最近も取り上げられていましたが、パッチが出てから適用されるまで１週間くらい時差があり、なぜこんなに遅いのかと批判されていたんですが、僕は、論点はそこではないと思っていて。あれは、本来外からアクセスされるべきでない管理ポートが、設定不備で開いていたため、それを突かれてしまったもの。設定に不備があった点が実はキーポイントで、脆弱性の対応プロセスとしてリモートから攻撃されないならすぐにパッチを当てなくても良いという判断は、正しかったかもしれないんですよ。１週間という尺度だったら問題ない気がします。
辻さん：優先度高いものからですよね。
根岸さん：そうなんですよ。だとすると、そこを変えることが問題ではなく、自分達の環境把握に問題があったんじゃないの？という話にもつながるので、こういう CVE がつかないとか、脆弱性とは思われない問題というのも、実はちゃんとトリアージしないといけなかったりすることを、ひょっとして皆さん漏れていませんか？「脆弱性って、CVE がついてパッチが出るものだけ対応すれば良いんでしょ？」って思っていると、いやいや違いますよ、というね。もう一度改めて、ここで皆さんにも考えてほしいです。
トリアージの課題
根岸さん：トリアージにも課題があります。皆さんに解決策を提示するつもりはなくて、こういう課題があるという事を知って欲しいというお話しになります。よく使われる「CVSS（共通脆弱性評価システム）」ですが、スコアリングとしては良いですが、スコアの出し方にさまざまな批判があります。問題は、基本値のみの運用で数字だけが一人歩きしてしまっていて、本来は実際に今攻撃が起きているか、今すぐ対応すべきかどうか、という判断をしなければならないのですが（基本値の後に本当はやるフェーズがあってそこがキモなはずですが）、現状は、ほぼ基本値のみで運用されているのが実態なのではないかと思います。その CVSS に代わる管理手法や評価指標がいろいろ出てきているのでご紹介します。
KEV（Know Exploited Vulnerabilities Catalog）→悪用が確認されている脆弱性のカタログ、CVE がアサインされていないと登録されない、登録される基準がやや不透明
KEV は、CISA が出している今実際に悪用が確認されている脆弱性カタログで、BOD 22-01 という指令と結びついていて、ここに載ったらいついつまでに対処しなさい、という連邦政府機関向けの法的な拘束力があるものです。世界中で使われているものも多数含まれるので、こういうものを参考にするという考えはあるんですが、さっき言った課題があって、CVE が無いとここには入らないんですよね。piyokango さんが言っていましたが、アメリカのカタログなので日本固有の問題は一切入りません。日本でよく使われているソフトウェアの脆弱性は絶対に入ってこない。とはいえ、一つの指標としてここに出るものは攻撃が観測されて1,2日程度の割と早いタイミングで入っているので、最近だと、Microsoft Exchange Server のゼロデイの脆弱性も出ていました。ここに出ていたら、攻撃がきていてやばいぞと分かる一つの指標にはなります。ただ、これだけで十分とは言えないところはあります。
SSVC（Stakeholder-Specific Vulnerability Categorization）→決定木を用いた脆弱性管理手法、Exploitation の有無が判断の重要な指標 (Active / PoC / None)
最近注目されている脆弱性の管理手法で、SSVC というものを聞いたことありますか。これもアメリカ政府などで採用されており、カーネギーメロン大学が2,3年前に提唱したもので「CVSS」に対する批判ですよね。ちょっと露骨ですが、「CVSS」をひっくり返して「SSVC」という名前になっています。数年前から CVSS に対する批判があって、これに代わるものが必要だよね、ということで出てきたものになります。
いわゆるディシジョンツリー（決定木分析）を使っていて、こういう場合に当てはまりますかという設問に「はい」・「いいえ」で従っていくと「このパッチはすぐに対応しなさい」、「この脆弱性はすぐにパッチを当てなさい」など、アクションにつながる決定木を用いた判断ができるような仕組みになっています。すごく良いんですけど、盲点というかみんな忘れているものがあって、判断が分かれる決定木の一番初めの大事なポイントに何が書いてあるかというと、Exploitation という指標があって、1)この脆弱性は攻撃が観測されている状況か、2)攻撃コード PoC が出ている状態か、3)それらが全く無い状態か、この三択で分かれています。結局、その脆弱性が今悪用されているかが分からないと何の判断もできません。それに対する答えは、SSVC は出してくれない。フレームワークとしては優れていますが、結局攻撃が観測されているのか、攻撃コードが出ているのかどうかを知らないと何も使えないので、そこは忘れてはいけないです。フレームワークがあると、なんとなくできそうと思ってしまいがちですが、必ずしもそうでは無いと僕は思っています。
EPSS（Exploit Prediction Scoring System）→機械学習を用いた悪用可能性のスコアリング手法、計算手法や入力データの妥当性に難あり
FIRST という団体が出している EPSS は、ずばり CVSS そのものを置き換えようというものになります。この先1ヶ月以内に、この脆弱性が攻撃される可能性があるかないか、というのを確率で出そうという意欲的な試みです。これが思っているようにできれば、すごく良い取り組みですが、現状だとちょっと問題があるというか、あまり精度がよくないんですよね。一応、機械学習を用いて予測の精度を上げようとしていますが、それが本当に妥当なのかどうかがよく分からない。決定木が良いのは説明可能な事です。SSVC が何で良いのかというと、“こういう理由で判断した”というのが厳密に説明できるからです。ところが、EPSS はなぜこの脆弱性の確率が高いのか全く説明できない。なので、これは普及が難しいかもしれないですね。ただ、FIRST は力を入れていますので、興味がある方は FIRST の EPSS のウェブサイトを見ていただければ、今どの脆弱性のスコアが高いか全て見られます。
どれもこれも完全に今の問題を解決するというよりは、単純に問題を置き換えている感じですね。よく脆弱性の英語の文章を見ていると、“This vulnerability has been actively exploited in the wild“ということが書いてあって、これがキーワードになるんですが、「今実際にこの脆弱性が本当に悪用されているかどうか」をどう把握するか、という問題を結局解決していないですよね。そこが課題かなと思っていて、ここは僕も模索しているところで、具体的な解決策は提示できないのですが、皆さんがもし意識していないのであれば意識した方が良いと思うし、意識している方がいらっしゃったら是非やり方を共有してほしいです。手っ取り早く、外部の専門ベンダーのサービスを買うという手段もありますが、丸投げしてしまうと自分たちの状況がどうか判断する力を養うことができなくなってしまうので、あまりお勧めしません。あるいは、コミュニティや早期警戒情報などの情報を収集したり、専門家の発信情報をキャッチしたり、Twitter でも脆弱性の関連する Tweet を収集したサイトもありますよね。
辻さん：僕は「CVE STALKER」というサイトを見ていますね。
根岸さん：一つの指標として、それらで騒がれていたら「これは気を付けないといけない」というのは、ある程度相関がありそうなんですよね。ただ、みんなが騒いでいるからと言っても事実かどうかの検証は必要です。
辻さん：併せて、自分に関係があるかも検証が必要ですよね。
根岸さん：自分たちにとってどうか、という視点は結局自分たちにしか分からない部分ですよね。さっき外部のサービスを買う話をしましたが、今どんな攻撃が来ているか分かっても、それが自分たちにどれくらい影響を及ぼすものか前提が把握できていないと、「うちは関係ない」で済ませてしまったら、もう全く意味がないですよね。これは特効薬的なもので簡単に解決できる問題ではないと思っています。
piyokango さん：これはノウハウが強く活きるところかなと感じていて、まさに"exploited in the wild" って書いてあれば分かりやすくていいですが、そんなのばかりではないじゃないですか。日本の組織が出している情報でも「この脆弱性が悪用されています」って書いてある組織どれくらいありますか、っていうくらい結構皆無に近い状態ですよね。とはいえ、このタイミングでこの組織が情報を出したら、「もしかしたらもう悪用されている可能性があるよね」とか、まだちょっと経験頼りになっていますよね。
根岸さん：piyokango さんのように長年見ていたら、「何となくこれ危ないんじゃないか」とか、「表立って情報は出ていないけど攻撃コードが出回っているんじゃないか」とか、不穏な動きは感じますよね。さっきの予報の話じゃないですが、対象は脅威と脆弱性で違うけど、やろうとしていることや取り組みたい課題は似ている気がしていて、これだけやっておけば良いというのがあまり思いつかないですよね。
辻さん：対策の現場において、「これだけやっておけば良い」という考えはだいたい失敗しますよね。トリアージは自分達が対策をしていく上で大事なものではあるんですけど、考え方のひとつとして、自分達はこれをちゃんと対応することによって、結果、作業量や負担を減らすことにつながるというのが考えられる。
それの第一歩としては、これは僕の意見でしかないんですけど、まず CVSS の基本値だけに反応するのを辞めた方が良いと思っていて。それだけを頼りにすると、攻撃があるものと無いもので、あるものの方が優先度は高いんですけど、無いものの方が基本値が高かったら、そっちから対策する基準を作っている組織って結構あるんですよ。
そうすると、言い方ちょっと極端ですけど、今すぐ当てなくても良いパッチを当てる作業をしないといけなくなくなってしまう。結局、全部当てられる体力のある組織であれば良いんですけど、なかなかそんなの無理ですし時間も限られているので。ここをしっかりしておけば、自分達が本当に今やらなきゃいけないことがわかる、イコール作業量を減らすことができて、現場の疲弊も防ぐことにつながるんじゃないかと思うので、CVSS に振り回されることからまず離れるのが良いんじゃないかと思います。
根岸さん：さっき紹介したいくつかの調査レポートでも同じことを言っていて、CVSS ベースで対応しようと思ったらものすごい負担になるんですよね。それを減らす・楽をするための方法でもあるんです。自分が本当にやらなければならないことを絞り込むのをどうするか、そこにもうちょっと注力した方が実際には楽になるんだけど、とりあえず使える指標がないとどうにもできないから、CVSS が高いものは直ぐにどうにかしようという基準をつくりがちでそこに判断を依存しがち。一旦、それをやめて絞り込むことや課題で挙げたものについて漏れているものがあれば地道に取り組む方が、結果的に自分達が楽できるし、効果的な対策になるんじゃないかという課題認識があって、皆さんに考えるきっかけにしてほしいと思っています。
辻さん：バサっといきなり変えるのは無理だと思うんですけど、今まで対応してきたものは優先度高くやってきたけど、本当に攻撃コードあったっけ？という事を調べるところからやってみるのも良いかもしれないですよね。
根岸さん：振り返りってあんまりやらないですもんね。実はこれ必要なかったかもはないかもしれないけど、究極的には全てのパッチをあてられるのが理想だからね。意外と、振り返っての検証というのは見過ごしがちだもんね。組織の中で経験だよりになってしまうという話になるとすると、外部頼りではなくて地道にやっていかないとダメなのかなと。
辻さん：外部は優秀だったとしても、自分達の組織に一番詳しいのは自分達なんでね。
関連ページ
出張版「セキュリティのアレ」〜情報セキュリティワークショップin越後湯沢2022 ナイトセッション参加レポート part.1〜
|
