CLOSE

トリと振り返るサイバーインシデント2024(全1記事)

2024.11.27

Brand Topics

PR

セキュリティ対策における「自社」の範囲はどこまでか? 業務委託先からの情報流出リスクへの備え

提供:株式会社網屋

サイバーセキュリティの専門家が一堂に会する、株式会社網屋の「Security BLAZE 2024」。現代の企業運営には、ランサムウェアに代表されるサイバー攻撃や内部不正など、さまざまなセキュリティリスクが伴います。本セッションでは、セキュリティインコことpiyokango(ぴよかんご)氏が、2024年上半期に公表された、国内のセキュリティに関するインシデント(事件・事故)を振り返りながら、攻撃者の手口や事前の備えについて解説しました。

2024年1月から9月までのインシデントは440事例

piyokango氏:それでは「トリと振り返るサイバーインシデント2024」としまして、お話をさせていただきます。

まず簡単に自己紹介をさせていただきます。ふだんからインシデントや脆弱性などのセキュリティ事象をまとめております。Xやブログ、あるいは最近ですとポッドキャストで、「#セキュリティのアレ」という名前で配信などもしておりますので、よろしければ見ていただけると大変ありがたいです。

今日お話ししたい内容は、大きくこの1番と2番になります。タイトルにあるとおり、2024年の国内インシデントの上半期の概況ということで説明させていただいていたかと思いますけど、(範囲を広げて)今回は1月から9月の分までをあらためて取りまとめました。せっかくですので、そちらのお話をみなさまと共有をさせていただきたいなと。

加えて今日は、そのまとめた結果を受けて私の中で気になったインシデントも併せてご紹介させていただければと思います。

さっそくですけれども、国内インシデントの概況です。私が確認した2024年の1月から9月までに公表されたインシデントの事例は440例でした。

(当事者が)公表された事例ですので、報道で取り上げられただけのものは、この440例の中には含めていませんし、あるいは2023年に発生したのを受けて2024年の1月とかに公表されたものは含めていなくてですね。

実際どれぐらいのプレスリリースの数があったかというと、続報なども含めると、650例とかに近い数字になってくるかなというものです。月別で見ていきますと、おおよそ30件から50件ぐらいになっております。この後、具体的にこの440例の中身を見ていきたいんですが。

「このインシデントからどういった影響があったかな?」ということについて、事例の数をそれぞれ検証してみました。見ていただくとわかるとおり、足しても440例にはならなくてですね。

1つの事案で影響が複数のシーンに及ぶことがありまして、ランサムウェアの事案を見てもデータが暗号化されてしまう、あるいはそれでシステム障害が起きてしまう。

最近ですと、さらに多重脅迫ということで、情報を盗み出して公開すると脅しをかけるものもありますので、本当に情報流出、システム障害、データの暗号化というものに全部かかってくるところもあります。

それぞれに1例ずつ計上されているところもあり、単純にこの数を足しても440例にならないというものです。

多岐にわたる情報流出や不正アクセス

やはり情報流出が突出して多いところは、当事者となる組織以外に影響が及ぶということを側面として踏まえれば、これぐらいの偏りが出るのは、ごくごく自然かなとは思います。

見方を変えれば、もしかするとシステム障害だけとかデータが改ざんされただけというものについては、(影響が当事者にとどまるため)公表されていないものもまだまだ多くあるのかなと思うところではあります。

踏み台に関しては、実際にデータが流出するといったものだけでなく、被害に遭ったところが踏み台にされて、詐欺メールをばら撒く。そういうものについては踏み台ということで計上させていただいていると。

さらに、今ご紹介した440例の事例において、どういった対象が不正アクセスが行われていたかというのも数えてみたんですけども、やはり社内のシステムや資産が一番多いですね。

吹き出しで書かせていただいているとおり、サーバーやネットワークというかたちでざっくり書かれているものもあれば、細かくデータベースや業務PC何台、検証やテスト環境ですと書かれているものもありました。さまざまではあるんですけども、そういったものを全部一まとめにして122例です。

それ以外は、「これも社内のシステムだよ」という見方もあるんですけども、ECサイトが被害に遭ってクレジットカード情報が不正利用されるという事例もございました。

そちらについては別出しでWebサイトが被害に遭ったということで52例。これはクレジットカードの流出事案以外に、単純にWebサイトが改ざんされたといったものも含めています。

あとはクラウドサービスということで、組織が利用しているさまざまなクラウドがあるかとは思うのですが、不正ログインされて情報が漏れてしまった可能性がある。そういうかたちで公表しておられるものも48例ございました。

最も多い手口は認証認可の情報の不正利用

さらに、こういった不正アクセスがどういった手口で行われているかも数えてみました。まず「調査中」というのを見ていただくとわかるとおり、非常に多くてですね。調査中、あるいはそもそも記載されていないものが半分近くを占める状況ではあります。

手口についても、概要レベルでは書いていただいているところがございまして。やはり一番多いのが、認証認可の情報が不正利用されてしまったというもの。84例ということで、IDやパスワードが盗まれてしまったり、発行していたアクセスキーが悪用されてしまうといったものなどがここに含まれていると。

ほか、数は少ないんですけども、脆弱性の悪用であったり、ソーシャルエンジニアリングと書いているのは、フィッシングのケースなども含めて15例。

ただ、先ほど申し上げた認証認可の情報は、フィッシングを通じて盗まれたものが結果的に悪用されてしまったものもあるように思います。

また、DDoS攻撃も13例ということで少ない状況ではあるんですけども。一方でシステム障害というかたちで公表しておられるところは本当に多いんですね。ただ、そのシステム障害からさらに一歩踏み込んで、それが攻撃であったか自社に起因するもの(自損事故)であったかを書いているところは、多くはありません。

システム障害ということでのみ公表しておられるところは、今回の440例の中には含めていないんですけども、もしかすると、その中にはDDoS起因のものも含まれているかもしれないなと。さまざまなDDoS攻撃のトレンドレポートを見ていると、公表していないケースがいっぱいあるなとは思いますので、そういったところはこのへんのギャップから感じるところではあります。

認証認可が不正利用される場合の3つの手口

認証認可は非常に不正利用が多いね、というお話をさせていただいたのですが、ここを少しクローズアップして、どういった手口があるかを説明させていただきます。

大まかにはこの3つかなというところです。脆弱性の悪用についてはもう本当にわかりやすく、システムやネットワークに存在する脆弱性が狙われるもの。その脆弱性を悪用して、アカウント情報、ID、パスワードであったり、あるいはセッション情報といったものを盗んで不正ログインに使う。

自分自身を管理者、あるいはシステム上で何でもできる特権という権限に昇格させるなんていうことも、脆弱性を使って行われる手口の一例ではございます。

やはりこの脆弱性の悪用で悩ましいところは、修正だけでは対応が十分ではない場合です。例えば今申し上げた、情報が盗まれてしまったというケースにおいては、その後修正をしても、盗まれた情報はそのまま有効となっている場合もあります。そこをしっかりケアしていないと、(脆弱性を)修正したにもかかわらず不正ログインされてしまったりしますので注意が必要かなと。

2つ目はマルウェアの感染ということで、昨今やはりインフォスティーラー、その名前の通り情報を盗み出すというマルウェアに注意したいなというところではございまして。認証情報が保存された端末に感染して、これ(認証情報)を外に送るというものです。

ただ、インフォスティーラー自身は端末中で何か目立った激しい派手な動きはしません。それこそウイルス対策ソフトなどが検知しない限りは、感染事実に気づきにくいのが正直なところだとは思います。

中には情報を送って、それで成功とみなして自分自身を消してしまうものもあったりします。

昨今ですと私有PCで感染してしまって、実はそれを業務利用していたので、結果的に業務の認証情報が漏れてしまったと見られる事例もあります。なかなかこのインフォスティーラーの対応は難しいというか、注意が必要な脅威かなと。

最後はフィッシング詐欺。これはみなさまもすでにご存じだとは思うんですけども、IDやパスワードを盗むだけではなくて、最近ですと二段階認証に対応した、AiTMと呼ばれる中間者攻撃の一種もあります。

そういった手口なども登場しておりますので、2段階認証を入れているから絶対安全というわけではないことにも注意をしたいなというものです。

サイバー攻撃者の分業体制

このような手口も当然あるのですが、認証認可の不正利用が多い状況については、この2点も関係があるかなと思います。

1つ目はやはりブローカーが存在すると。認証認可の情報を売買する人物がすでに複数いるという状況ですね。当然ながら必要とする人は、その認証認可を取引している人から買いますので、届きやすい状況にもなっているのが怖いところだなと。

さらに、そのブローカーの存在が関係しているところではありますが、侵入経路を確保する役と、実際にランサムウェアといったサイバー攻撃を直接行う役が一致しないケースもあります。

侵入経路を確保する役は、それこそ経路の確認さえ終わってしまえば侵入はストップして、情報を盗んだりはしません。組織側からすると、あからさまな不審な挙動やシステム障害が起こらないので、気づくことが難しい実情があったりですね。

やはりこの間、(攻撃者間の)取引が挟まりますので、盗まれた時から実際に攻撃が起こるまでの期間が空くことによって、根本原因を確認(できなかったり)、ログが残らなかったり、3ヶ月か半年経ってしまってから攻撃されたりしてしまうと、そういう状況になりかねませんので。

そうなると根本原因への対処が遅れてしまう、あるいはそもそも対処ができていないということになってしまいます。もしかすると、せっかく対応した後に、また同じような攻撃を受けることも起きかねません。やはりブローカーと分業制に伴う時間差(での攻撃)が起きているところについては、注意して対応、対策を練っていく必要があるかなというところです。

業務委託先を発端としたインシデント件数の公表が増加

2024年の状況をまとめさせていただいたんですけども、次に“トリ”わけ気になるインシデントを挙げさせていただければと思います。

先ほど冒頭で、月別の(インシデントの)件数を掲載させていただいたんですが、7月、9月が突出しているんですね。「これ、なんでかな?」というのはやはり気になるところかなとは思うんですけども。

この中身を見ていきますと、業務委託先を発端としたインシデント公表事例が非常に多いことがわかりました。

7月、9月は59件、57件と非常に多いんですけども、ほかの月もほぼ毎月何かしら業務委託先を発端として影響を受けたと公表しておられるところがありました。そう見ると、業務委託先を発端としたインシデントがけっこう多い状況でございました。

どれぐらいが業務委託先に起因したインシデントだったのかということで、最近のトレンドかわからないんですけども、公表された資料上に、実際に委託先の社名や組織名が書いてあります。

2023年にもあったんですけれども、やはり2024年も本当に多く見るなというものでした。委託先からさらに再委託されているケースも含めて、だいたい20社でした。


とりわけ数が多いのと、関連する公表事例が多かったのは、1月、6月、7月、9月の4つの事例です。業種はさまざまですけれども、(その業務委託先が)影響しているということで公表された数は、やはり20例とか40例とか非常に多い状況ではあります。

その分野、その業界では、やはり依頼先として本当にすぐ名前が挙がるような有名な企業かなと思うのですけども、ランサムウェアの被害に遭われたところは4つ中3つの事例がありました。

やはりランサムウェアは、最近ですと情報流出の可能性が非常に懸念されるので、公表に至るというケースが非常に増えてきているのかなと思います。

業務委託元と委託先の間にある、さまざまな懸念点

こういった業務委託先を発端としたインシデントが増えている状況は、深刻になってきていると思うのですが、いろいろ考えていくと、問題もあるなというところです。委託元と委託先、あるいは事前の備え、実際に発生してしまった時、それぞれで懸念される問題の例を挙げさせていただいたんですけども。

委託元からすれば、委託先が業務状況を十分に問題なく行えているかを、逐次把握するのはなかなか難しいところかなと(思います)。だからこそ、業務委託というかたちで行っているのだとは思うのですけども。

「もともとの取り決めに従って情報の管理をしっかりやって業務に当たられているか」というところの把握に漏れが出ると、実は杜撰な管理だったということで、インシデントが起きた時には大きな問題になったりしますので、なかなか難しいところかなと。

一方で、何でもかんでも「やれ、やれ」といった強い要求を出してしまうと、費用に跳ね返ってきてしまう懸念もあります。ここはどこまで出すべきかというところで悩んでおられるところも多いのではないでしょうか。

訓練しようにも、「訓練に参加してください」と言うと、当然訓練参加費用も必要になりますので、果たしてその費用を委託元側がどこまで見ていけるのかというところは問題だったり。

委託先に関しても、こういったかたちで業務委託先を発端としたインシデントが多々発生する状況においては、下手すれば個別の要求も出てくる可能性が考えられます。やはりそういった個別要求にどこまで対応していくかも悩ましいところです。

お金だけ積まれても、人がすぐ手当てできるかはわかりませんので、そこについては、単純に費用だけで解決できるところでもないのかなと思います。

問題が起きた時の対応や対処は後手に回りがち

一方で、委託先が増えていけばいくほど、影響が波及する範囲も拡大していくのは懸念されるところではあります。どこまでを前提にするかというのはあるんですけども、体制をどこまで考えていくかも問題になってきます。

また、実際に問題が起きた時も、委託元からすれば、自社自身は発生の主体ではないので、どうしても対応や対処が後手に回ってしまうことがあるのかなと。

やはり委託先が調査をするのが主ではありますので、「提供された情報が漏れていません」と最新の報告を受けた後に、「実は漏れていました」ということで、その後の調査結果がひっくり返るなんていうことも、2024年に実際ありました。後手に回るという実情があることは踏まえておくべき点ではあります。

また、業務委託先についても、このように関係先やステークホルダーが多く介在するところで、どうやって全体をコントロールしていくか。調整コストも含めて、負荷が非常に高いという懸念が出てきますし、広報については多くの関係者がいるというところもあります。

(関係者が多いことから)なんでもかんでも言うのはなかなか難しいところだとは思うんですけども、当事者側からすれば委託元からは「しっかり情報を出せ」と言われますので、この板挟みは非常に難しいところかなと。

時には(情報を)提供した委託元から、委託先である自社では開示していない詳細な情報が出てしまうこともあったりします。このへんの制限や統制も難しいところがあります。

これら懸念される問題は、先ほどのスライドで紹介した4つの事例のどれにも当てはまるのかなと思うんですが。

それこそ委託元1社の特定の事業に対して、委託先が何十社と存在するケースは、この問題が深刻になる可能性がありますので、委託元も委託先も注意していく必要があるかなと。

事前に「サイバー攻撃を受けた場合のリスク評価」をしておく

一方で、じゃあ、どうしたらいいのかというと、182例の事例を見ていくと、しっかり対応できていると見えるところと、まだちょっと対応が後手に回っていると思われる事例が見受けられるというのも正直なところです。

委託元からすると、クリティカルな業務がどういったところを委託しているのか、どういった情報を提供しているのかというところも含めて、リスクの評価をやられたほうがよいなと思います。

多くのところでやっているとは思うんですけども、サイバー攻撃であるという前提に立った上でのリスク評価をやっていただいて、その後に実際に攻撃が起きた時の対処計画とか。

本当にもうどうしようもない時は、委託先を切り替えるという判断にもつながるとは思うんですけども。委託先に渡していた情報を受け取らないと、そもそも切り替えができないような状況でサイバー攻撃を受けていると、そういった情報が暗号化されていてまったく手がつけられないことが普通に起こりえますので。

そういったことを踏まえて、「サイバー攻撃を前提にした切り替えって、そもそも実現できるの?」というところは考えておいたほうがよいのかなと。

委託先に関しては、本当にもう日頃からのセキュリティ対策をしっかりやっていただくのは、当たり前のところではあるんですが。特に委託元が政府や重要インフラなど、どういった委託を受けているかというところは(全社として)しっかり把握しておくほうがよいのかなと思います。

あるいは、先ほど申し上げた情報交換も、透明性というところを踏まえた観点での公開・共有は実施したほうが疑心暗鬼にならないかなと思います。このへんは特に事前にどこまでやるべきかは考えておいたほうがよいのだろうなというところです。

身近なランサムウェアの脅威にどう対応していくか

ちょっと駆け足だったんですけども、「おわりに」というところで、今日はさまざまなところでランサムウェアというキーワードをお話しさせていただきました。被害に遭われたところは口を揃えて「自分自身がなんで被害に遭ったの?」と言うぐらいに、もう本当に、いつなんどきこういった脅威にさらされるかわからない状況です。

実際に警察庁などが公表している資料でも、ランサムウェアの暗号化の被害によって、バックアップが使えなくなったということで取りまとめられている数字がかなり多くを占めているという現状があります。

一方でランサムウェアの脅威は、昨今ではバックアップを真っ先に狙われるのが当たり前です。そのギャップを自分ごととして捉えられているかというところにかかるかなと思いますので、あらためて身近な脅威として捉えて対応いただきたいなというところ。

2点目としては、認証認可の情報ですね。1番目にお話させていただいたんですけども、ここの管理が杜撰ですと、そこから組織へ侵入されて具体的にクリティカルなシステムに影響が及ぶようなことも起こりかねません。ですので、認証認可の情報をしっかり管理をしていただく。

あるいは、発行した情報が適切にフォローがされているかどうか。発行済みのままになっていないかというところなども含めて、見直しを徹底していただきたいというところですね。

「自社」をどこまでの範囲とするかの見極めの重要性

最後にかっこ書きで「自社」とさせていただいているんですけども。この「自社」は、自分たちの組織で扱っているシステム、情報資産だけを指す世界だけでいいのか。あるいは、業務委託先を踏まえたかたちで見ていかなければいけないのか。その見極めというところがより重要になってきていると思います。

何でもかんでも範囲を広げてみればいいというものでもなくて、広げれば広げるほど当然コストも必要な体制も十分なケア、対応が必要になってきます。

何でもかんでもやれというわけにもいきませんので、どこまでやるべきかというところは、リスクの分析、評価が必要だというお話はしたんですけども。そこも踏まえた上でどこまでやるべきか。「自社」はどこかというところは、経営層も含めてしっかり意識合わせをしていただいたほうがよいのではと。

2024年の事例からも、対応が遅いところと早いところは、けっこうはっきり見ていてわかるのが正直なところです。業務委託先が被害に遭われてすぐ公表をされて対応に当たられているところもあれば、1ヶ月ぐらい経ってからやっと公表されているところもあったりと、本当にさまざまなんですよね。

その差が出るところを、事前の備えということでご紹介しましたが、「自社」が指す範囲の見極めが重要になってまいりますので、そこはしっかりやっていただいたほうがよろしいんではないかなと思います。

以上、「トリと振り返るサイバーインシデント2024」、最近の事情をまとめさせていただいた上で、気になる事情も含めてお話をさせていただきました。ご清聴どうもありがとうございました。

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

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

無料会員登録

会員の方はこちら

株式会社網屋

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

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

人気の記事

新着イベント

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

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

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