CLOSE

これからの対応の話をしよう ランサムがありあまる 2024(全2記事)

2024.11.28

Brand Topics

PR

"危険度"だけで判断してはいけない KEVを活用した脆弱性対応の新常識

提供:株式会社網屋

株式会社網屋主催のイベント「Security BLAZE 2024」において、SBテクノロジー株式会社のプリンシパルセキュリティリサーチャーである辻伸弘氏が、セキュリティ対策の具体的な方法について解説しました。Attack Surface Management(ASM)という攻撃対象領域の継続的な管理手法と、脆弱性対応における新しい優先順位の考え方を中心にKEV(Known Exploited Vulnerabilities)を活用した現実的な対策方法を提示しながら、「完璧でなくても諦めない」という姿勢の重要性を説明しました。

悪用されやすい設定ミスの事例

辻伸弘氏:ここから守っていく話に入ろうかなと思っているんですが。まず唐突ですが、事例を2つ用意してきたので、その2つを見ていただきたいなと思います。

まず1つめ。これけっこう最近ですよね。2024年7月10日、税理士法人高野総合会計事務所が、インターネットに外接している通信機器の更新を行った時にミスが発生していて、おそらく開けてはいけない口が開いてしまったのか、あるいはアクセス制御が緩くなったのかはわかりませんが、本来インターネットに露見するべきではない何かが見えてしまって、そこから入られたと。最終的にはランサムウェアに感染した、ということがありました。

注目していただきたいのは赤字になっているところで、5月26日に設定変更を行って、ミスが発生しています。要は、口が開いた。その後アラートが上がったのが事象の1番頭に書いてある赤字、6月4日。5月26日から6月4日はおよそ10日間ぐらいなんですね。これぐらいのスピード感で入られてしまう現状があります。



2つめ。これはCisco IOS XEという、2023年に出た脆弱性なんですけれども。この脆弱性がどうかということをみなさんに知っていただきたいわけではなくて、この脆弱性を悪用するためには条件があるということなんです。

これはwebUIといういわゆる管理画面、管理アクセスと言われるようなものがインターネットに露見している場合は、インターネットから攻撃を受ける。設定画面は基本的に開けっ放しにする必要はありません。インターネットで誰かに設定いじってもらうことなんてほぼないと思いますので、そういったものは閉じておくべき。もしくは内側からしかアクセスできないようにしておくべきなんです。

「そんなのあるの?」って思われる方もいるかもしれませんが、けっこうあります。

この脆弱性が発表された当時、このShodanというサイトで見たんですけれども、世界中で11万件以上が開いていました。日本国内においては1,473件、およそ1,500件ぐらい開いていました。

これ、自分たちが外に向けて何を開けているのかを把握していない組織がまあまあいると僕は考えています。

「こう設定している」と自信を持って言えるかもしれませんが、インターネットから見たらどうですかと言われると「いや、それいつ確認したかなぁ」と思う方も多いんじゃないかなと思います。

こういった先ほどの例の設定変更によって起きたミスの隙を埋めるとか、自分たちがインターネットから見た時、言い換えれば攻撃者から見た時にどのような状態になっているのかを知るためには、こうしたものがあるといいんじゃないかと僕は思っています。

攻撃対象領域の継続的な管理「ASM」

Attack Surface Management(ASM)ですね。これは攻撃対象領域管理とよくわからない日本語で説明されることもあるんですが、最近よく言われますよね。これをどうやっていこうかなと考える方もいるかと思うんですが、そんなに深くビビる必要もないかなと僕は思っています。

まったく新しいものではなく、基本的には今までやるべきであると言われてたことを組み合わせてしっかりしましょうっていうものにやっと名前がついたと理解していただければいいかなと思います。

じゃあどうやっていくのかということなんですけれども。やり方、回し方で参考になるなと思ったのは、アメリカのCISAが出している「BOD 23-01」と「BOD 23-02」。

このBODというのは、アメリカが政府機関に対して強制力を持って行えと言える指令のことを指すので、アメリカから見て、アメリカの政府に向けて出しているものです。こちらが参考になるかなと思って持ってきました。

ただ英語で書いてあるので、こういう時はどうすればいいのかというと、やっぱり3行にまとめるのが一番いいかなと思いまして、まとめてみました。

上2つが「23-01」、下が「23-02」で言及されている内容になります。7日間ごとに自分たちが使っているネットワーク通信ができるような機器、サーバー、クライアント、ネットワーク機器、いろいろあるかと思うんですが。

そういったものをスキャンして、7日間ごとにどんなものがあるのかの可視化を行いましょう。守るためには何があるのかを知らないと守れないので、そのファーストステップとして7日間ごとに資産の可視化を行うということです。

それに加えて、見つかったものに対しては14日ごとに存在する脆弱性を検出する。

リモートだけではなくてローカルの脆弱性もあるのかといったところを調べて対処を行うサイクルを回しましょうと言っています。

3つめ、管理インターフェイスへのアクセス制御。これは先ほどCiscoの例で挙げましたけれども、必要のない口、特にインターネットに向けてそういったものを公開するなと言っています。

この3つをクリアすればおおよそAttack Surface Managementと言えるのではと僕は考えてます。



資産の可視化とあったんですけども、だいたいこれをザクッと1枚にまとめたスライドがこちらになります。

決して脆弱性診断とは違いますよってことです。ショットでやるのではなく、ずっとグルグル回し続けるというプロセスだったりサイクルだったりのようなものが、Attack Surface Management。

把握する対象はIT資産。それに対するアクセス制御。本当にそれを開ける必要があるんですか。認証は、認証の強度はどのレベルですか。そういったものをきちんと把握して、必要あれば対処する。

それに関する脆弱性はどんなものがありますか。どういった影響がありますか。それをどの順番で優先順位を考えて対処をしていきますか。こういったものをぐるぐる回していくのがAttack Surface Managementと言われているものです。

これは診断とノットイコールになっているんですが、経路という意味では似ているのかなと思います。これをインターネットからすればいいのかと言われると、決してそうではないです。もちろんインターネットからを最も優先順位を上げる必要はあるかとは思うんですが、経路もさまざまあります。


ASMの3つの経路「外部・内部・閉域網」

ASMのパターンということで、こちらからちょっと簡単に経路を説明していこうと思います。まず図の説明ですね。真ん中の赤いものがそのASM、スキャンを行ったり脆弱性をチェックするコンピューターだと思ってください。緑色がみなさんが使っているDMZ、業務ネットワークと言われるいわゆるオンプレの環境です。

右上がクラウドサービス、使っていない会社もいるかもしれませんがAWSとかGoogleとかいろいろ。MSもありますね、Azureとか。そういったクラウドサービスが右上の水色のものになります。

グレーになっているのが支社やサプライヤーなので、なんとか支店とか、アメリカ支社とかがある会社もあると思うんですけども、そういったものとか。

あとは監視をしてもらっているとかですね。MSSとかの業務上何かしらのつながりがあって、ネットワークを開放している相手と思っていただければけっこうです。そこは基本的には専用線とかVPNとかでつながってるかと思うんですけど、それの概略図がこちらになります。



経路は3つあるんですけれども、1つめは外部。これをインターネットから見ましょうってことなんですが、今この赤いコンピューターから矢印が出た範囲ですね。ファイアウォールだったり、その内側にいるDMZの公開サーバー。あとはクラウドサービスですね。余計な情報を公開していないかというクラウドの話がよく出てきますけれども、そういったものもチェックしましょうと。

あとは業務ネットワークは直接つながることはほぼないと思うんですが、この昨今VPNもかなり多いかと思うので、このVPNの入り口がまずくないかをインターネット上からチェックする、といったものが外部の経路になります。



次が内部ですね。ファイアウォールとかVPN機器に守られていないような状態の時にってことですが、中に入られてしまったらということ想定して、この中からネットワーク制御を受けない状況で本当にパッチが当たっているのか、変なサービスが動いていないのかをそれぞれDMZと業務ネットワーク内で調べることが内部のAttack Surface Managementです。



次に閉域網ですね。これは支店やサプライヤーのところにあたるんですけども、ここが侵害を受ける、いわゆるサプライチェーン攻撃というものがあります。MSPですね。そういった監視を行ってくれている組織をターゲットにして、その顧客を攻撃しようとする攻撃がけっこうあったりします。

この支店やサプライヤーが被害を受けた時に、この専用の線がVPNのケースもあるかと思うんですが、専用に用意されているこの経路を使って入られたらどうなるか。これ、けっこう弱いとこ多いんじゃないかなと思うんですよね。全部通信を許可してしまっているとか。

こちらも本当に最小限になっているのか、業務上必要なのか。弱いもんだったら強いものに変えられないのか。そういったことをつまびらかにするための経路のひとつが「閉域網」になります。


ASM実践の基本ポイント4つ

今お話ししたことを簡単にまとめると、本当は3行にしたかったんですが、4行になってしまいました。

把握する対象はIT資産、アクセス制御と脆弱性。把握する経路は、先ほど今言ったばっかりですが、外部、内部、閉域網。順番としてはこの順番が優先順位が高いのかな。内部と閉域網がもしかしたらちょっと入れ替わる可能性もあるかもしれませんが、このへんは気にしてることによるかなと思います。

こういったものの変化を常時把握します。昨日なかったものが今日はあるとかですね。先ほどの事例のように、設定変更を誤ってしまったことを見つけることができないということを防ぐために、常時把握して評価して対処するのがこのASMになります。

最後は4つめとして、なんとしてでも言いたかったのでこれをつけました。ポートスキャンから始めようということで。こういうことを導入しようとかコンサルをしてもらうと、まあまあお金かかると思うんですね。

なので自分たちのできる範囲を増やすという意味でも、あとすぐできるというふうな意味でも、ポートスキャンから始めるということです。自分たちでインターネット越しに自分たちの組織に対してポートスキャンを行ったらどれぐらいの口が開いているのか。それが自分たちが把握しているものなのかどうなのかを照らし合わせるためにやってみてほしいなと思います。

最近、よく侵入前提という言葉が当たり前のように言われますけれども、簡単に諦めてほしくないんですよね。「入り口が空いてしまっている」「ケアレスミスで入られてしまいました」、そういったものが事例を見ているとまだまだけっこうあります。

なので侵入前提を考えるのはもちろん大事です。風邪を引いた時にどうしようか、薬を買っておこうか、かかりつけの病院はどこにしようかとかですね。そういったことを考えるのはメチャクチャ大事だと思います。

でもそもそも手洗いうがいして風邪を引かないようにするのが当たり前のことだなと思います。風邪を引く前提で生活をするんではなくて、まだまだ防げる余地があるんじゃないかということを考え直していただければなと思います。


脆弱性対応における優先順位の考え方

と言ったんですが、舌の根も乾かぬうちにそれでもやられてしまう可能性があると。脆弱性を突かれてしまったらなかなか対応ができないので、この脆弱性の対応の話をしたいなと思っています。

これ、自分で調べてみたら、僕は同じことを2016年ぐらいからずっと言い続けてるみたいなんですけれども、やっとちょっとずつ受け入れられるようになってきたのかなと思ったので、この脆弱性対応について僕の考えている話をみなさんに聞いていただきたいなと思います。

そもそも脆弱性って1年にどれぐらい出るかっていうと、もう数万件出るわけなんですよね。2023年でも3万件もCVE番号が発行されていました。

もちろん、その脆弱性とCVE全部が関係しているわけじゃないですが、自分たちの使っている製品に存在している、もしくは最近明らかになった脆弱性すべてに対して即可及的速やかに対処しないといけないんでしょうか。

いけないんでしょうか、と聞いてるってことは、しなくていいと僕は思ってるってことなんですよね。

メディアのニュースを見ているとどうしても出てくるんですが、危険度というものに振り回されすぎなんじゃないかなとずっと僕は思い続けていますし、それを言い続けてきました。

危険度というのは、ニュースのタイトルにも出るような「○○○○の脆弱性危険度最大の10!」みたいなやつがあるかと思います。それって本当に一番すぐに対処しないといけないんでしょうかね。僕はそうは思っていません。

少しみなさんにも頭の体操をしていただきたいなと思うんですが。仮にこういったCVEの2024のAからFまでの6つの脆弱性があったとします。どんな脆弱性でもいいです。みなさんに関係のある脆弱性だと思ってください。

その危険度と言われる「CVSSの基本値」というものがありますが、それぞれ対応するAだったら9.8、Bだったら10.0というものだと思ってください。

この状態を知ったみなさんは、どういう優先度をつけてパッチを当てる対処をしていこうと考えるでしょうか。



僕がセキュリティ診断で報告会をした時に、この危険度を伝えたらだいたいのお客さまの反応はこんな感じです。

「赤いものは2週間ないしは、いや1週間以内に対処する。システムを止めてでも。Dは8.7なので、そうだなぁ、1ヶ月以内かな」ぐらいの感じの反応するお客さまが多かったです。ほとんどそうでした。

みなさんはどうですか? だいたいこんな感じになっちゃうのかなっていう気もしなくもないです。



「いや、もうそんなん関係なく全部やります!」っていう方はいるかもしれませんが、ここは今優先順位の話をしてるので、おそらくこんな感じなんじゃないかなと思います。

はてなのところ見ていただきたいんですが、ここの値がこうだったらどうですか? 悪用する手法があるかないか。もしくは悪用が確認されているか。どっかでその脆弱性を使った攻撃が行われているかどうかのあり・なしを追加したらどうですか? これでも本当に赤からやります?

僕はそれはまずいんじゃないかなと思っているんですよね。僕はこの悪用の手法の有無もしくは悪用の確認をこの軸に入れた場合は、この赤・黄は消えて、この赤で囲ったところ、要は「あり」になっているところから優先順位を持って対処をするんじゃないかなと思います。



これは2つ理由があって、今すぐやらないといけないわけではないものにリソースをかけて、リソースを浪費してしまうということを避けるのが1点です。もう1点はこっちのほうが大事で、危険度が低いにも関わらず悪用の手法があって悪用されているものを、先ほどのような優先順位の付け方では見過ごしてしまってやられてしまうケースが生まれてしまうということなんですね。

なので僕は、攻撃が成功した時のインパクト、要は殴られた時の痛さではなくて、それが本当に殴られるようなものなのか。悪用可能かどうかが最大の重要な優先順位を決める要素なんじゃないかなと考えています。

「でもその悪用されているかどうかが、あなたは専門家だからわかるんでしょうけれども、私たちは知るすべがありません」っていうお客さまもけっこう多かったです。僕が2016年にこの話をした時も、同じような反応をたくさんもらいました。

でも時代は変わって、情報がたくさん手に入るようになりました。これは先ほどのBODでも紹介しましたが、アメリカのCISAが出しているKnown Exploited Vulnerabilities Catalogで、悪用が確認されている脆弱性のカタログが公開されています。

これはアメリカの政府機関向けのものですが、アメリカの政府機関はここに掲載された脆弱性に関しては基本的に2週間以内に修正することを強制されています。

もちろん僕たちは政府機関ではないので2週間以内にやる必要はないですが、早ければ早いほうがいいです。そういったもののリストが出ています。



アメリカ政府がいろいろなベンダーと協調をしたり、自分たちのところに来た攻撃、観測できた攻撃を上げてリストに掲載しているので、ここに載っている情報はすべて対処するようなやり方も1ついいんじゃないかなと。踏み台にすることができるんじゃないかなと思います。逆にここに載っているものが対処できてなかったら、やばいってことなんですよね。

ただこれも注意が必要です。アメリカがアメリカ政府に言っていることなので、日本でしか使われてないアプリケーションとか、アジア圏でよく使われてるような会計ソフトとかは、ここには掲載されてきません。

それは自分たちで情報を収集する必要がもちろんあるんですが、Windowsとかみんなが使ってるようなものはここに掲載されるので、かなりのボリュームでこれを使って埋めることができるんじゃないかなとは考えています。

CVEとKEVの比較

そのKnown Exploited Vulnerability Catalog、KEVと略しますが、そのKEVも、CVEとこの脆弱性の採番と同じぐらいたくさん出てたら、「いや、それはそれで大変やねん」って思うかと思います。

CVEの発行を2013年から2024年の夏、KEVの件数をこれが発行され始めた2021年11月3日から夏の頭ぐらいまで出してみました。これをグラフにしました。

両方見比べてください。似たような感じなんですけども、数字のオーダーがぜんぜん違いますよね。これを分母をCVEとして分子のKEVを割る(KEVのCVE年別掲載数/CVE年別採番件数)と、どの年においても1パーセントを超えません。

その1パーセントの中をまず対処するということで、100パーセントそれで全部の攻撃が防げるわけではないんですが、今よりもより良くなると僕は確信をしています。

1パーセント未満と言っても、その1パーセント未満の中にみなさんが使っているアプリケーション、もしくはお客さまが使っているアプリケーション、あとOS。そういったものに絞り込んでいくとかなり数が絞られていくんじゃないかなと考えます。

相当数字のオーダーが違うので、コストもしくは手間、そうしたものが現実的なものになってきてるんじゃないかなと思います。



これで少しでもがんばってみようかな、できそうかなと思っていただければ、僕は今日話した意味があるんじゃないかなと思います。

セキュリティ対策の現実解

どんなセキュリティの事象でもですね。大事なのは、今どうなっているのかを知ることです。2016年に言っても相手にされなかったことが、今は聞いてもらえるようになりました。それと一緒です。

現状を知って、現実解を選択する。100パーセントにするのは無理でも今よりもより良くするというものが僕はセキュリティなんじゃないかなと考えています。

これを100パーセントにできればいいんですが、そんなことできないことは僕もわかってます。人・物・金は有限ですから、自分たちができる「ここまではできた」と言えるようなセキュリティ対策をみなさんに心がけていただきたいと思います。

まとめるとこの一言に尽きるんですよね。完璧は無理かもしんないですけども諦めずに完璧ではなく、それでも自分たちは最善を尽くしたと言えるような対策。簡単に諦めて侵入前提でやるのではなくて、まだまだ自分たちができることはあったんじゃないか。

侵入されたら実被害が起きなくても、かなり調べるのに時間がかかります。やっぱり手洗い・うがいにあたるようなものをもう一度見直して、この言葉を頭の片隅のどっかに置きながら「なんかあいつがこんなこと言ってたな」とか「こんなことを言ってる人いましたよ」とみなさんが伝えていただければ、すごくうれしいなと思います。

この言葉をひっさげて、どこかでみなさんとお会いしてお話しすることがあればうれしいなと思っています。僕からは以上です。ご清聴ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

人気の記事

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!