セキュリティ人材不足に待ったをかける！生成AIを活用したセキュリティ運用

はじめに

セキュリティ人材が不足している、と言われて久しいですが、あなたの企業はこの課題に対してどのように向き合っていますか？おそらく大半の企業が、「人が足りない～」と嘆いているだけのことが多いのではないでしょうか。ないものねだりをしても仕方がないので、本ブログでは人力に頼らない"生成AIを活用したセキュリティ運用"を考えます。

セキュリティ人材不足の裏付け

経済産業省が公開した「サイバーセキュリティ体制構築・人材確保の手引き」では、”「セキュリティ監視・運用」分野等を担う実務者・技術者層のセキュリティ人材の量的・質的不足が確認されています” と報告されています。また、JUAS調査におけるセキュリティ体制に関するアンケート結果（https://juas.or.jp/cms/media/2022/02/it22_2.pdf ）にも、セキュリティ人材の不足が数字として表れています。さらに、多くのユーザー企業では専任のセキュリティ担当部隊を用意しておらず（できず）、IT部門や情シス部門が兼任してセキュリティ運用を行っているのが現状です。
つまり、人手が足りていないのは決してあなたの会社だけでなく、日本全体で直面している深刻な課題なのです。パブリッククラウドにおけるセキュリティは重要度が高く、いつでも・どこからでも・誰でもアクセスができるパブリッククラウドのセキュリティをおろそかにすることは、金庫に鍵をかけずに家の外に置いているのと同義です。我々はこの課題にもっと真摯に取り組まなければなりません。

セキュリティ担当が行っている業務の一例

さて、セキュリティ人材が不足していることをわかっていただいたところで、次にセキュリティ担当者は具体的にどんな業務を行っているのかを見てみましょう。セキュリティ担当の業務を知ることで、生成AIを活用して効率化できそうなタスクを洗い出し、次のアクションにつなげます。
まず一般的なセキュリティ担当の業務フローを確認します。インシデントが起きてから対応完了までのフローとしては；

1. インシデントが発生したことを検知
2. インシデントの内容を解釈する
3. リソース担当者に連絡
4. リソース担当者が問題を修正
5. 管理者へ対応が完了したことを説明

の流れが一般的です。このうち、2. インシデントの内容を解釈する に工数が非常にかかると言われています。ここでいう解釈とは、5w1hのように、どのサーバが・どのIPから・いつ・どんな方法で・どういう攻撃をしたか、を把握することです。3番の手順でリソース担当者に連絡をして脆弱性や設定ミスをふさいでもらうことになるのですが、彼らはセキュリティについて詳しくないことが多いです。そのため、セキュリティ担当者が彼らに「どこをどういう風に直してほしいのか」を分かりやすく伝える必要があります。
しかしここで人材不足の問題です。はたして貴社の既存のセキュリティ担当者たちが、しかも兼務や未経験者が多い状況で、日々大量かつ不定期に発報されるインシデントを解釈しきれるでしょうか？毎日同じインシデントが発報されるなら簡単ですが、実際はそうではありません。常に未知の攻撃が発報されるのが現状です。それらすべてをひとつずつ対応するのには膨大な工数と知識量が求められます。インシデントの解釈はもはや人力で行えるものではないのです。

次に、実際のインシデントをキャプチャで見てみましょう。例として扱うのはAWSのマネージドサービスである”AWS GuardDuty”です。GuardDuty は以下のようなFindings（＝インシデント）を発報します。

JSONで見るとこんな感じです。（一部抜粋）

いかがでしょう。これを見てパッと解釈できる人はAWSエンジニア以外で多くはないはずです。パブリッククラウドのセキュリティサービスは確かに便利ですし、全リージョンで有効化することがベストプラクティスとされています。ですがこのレベルのインシデントが毎日大量に発報されたらどうでしょうか。セキュリティ担当者に負荷が集中し、本当に対応すべきインシデントを見失って重大な損失を負うかもしれません。3rdParty製のセキュリティ製品についても同様です。製品を導入して満足している企業が多いと聞きますが、本当に重要なのはセキュリティ担当の体制です。ここがしっかりしていないと、大量のインシデントに対処できなくなり、いわゆる「アラート疲れ」に陥る危険性があります。

生成AIで効率化できないか

ここまで述べた通り、インシデントの解釈はセキュリティ体制を整備する上でボトルネックとなる部分です。セキュリティの知見が浅い人や社内のリソースを把握しきれていない人に解釈は難しいでしょう。ですが、インシデントの解釈とは言いかえればJSONを読み解くことです。コードを読むことは人間よりもAIが圧倒的に正確でスピーディです。ここでは、上記のGuardDutyのFindingsを例に、Amazon Bedrock(*)を活用して解釈をさせるワークフローを見てみましょう。
*参照：Amazon Bedrock：AWSが用意したトレーニング済みのAIモデルを簡単に利用できるサービス（https://aws.amazon.com/jp/bedrock/）

例えば、以下のようなワークフローを構築します。AWSエンジニアでない方はふわっとした理解で大丈夫です。

GuardDuty が検知したセキュリティインシデントをEventBridgeがキャッチし、ステートマシンに送ります。ステートマシン内部では生成AIの基盤モデルであるBedrockを呼び出していて、ここでGuardDuty のインシデントを解釈させます。解釈させたメッセージはSNS経由でセキュリティ担当者のEメールアドレスに送信されます。このアーキテクチャが実現すると、インシデントが発報されるたびにワークフローが走って、リソース担当者にそのまま渡せる解釈されたメッセージを受け取ることができます。セキュリティ担当者に十分な知識がなくとも、人手が足りていなくとも、生成AIが代わりにセキュリティ運用をしてくれるのです。

以下は実際にこのアーキテクチャを構築し、受け取ったEメールの一例です。どうでしょう。対応方法や攻撃先のIPアドレスを記載してくれます。ここまできれいに解釈してくれるなら、もはや人間の力は不要です。面倒なことはAIに任せるべきです。

まとめ

セキュリティ人材の不足への対応策として、生成AIを活用したセキュリティ運用を考えました。本ブログはあくまで一例であり、これを参考に企業ごとにカスタマイズすべきです。今回は生成AIでセキュリティを解決する「光」の部分をご紹介しましたが、生成AIを使うことによって生まれる「影」も存在します。別のブログでは、生成AIを使用するときに考慮すべきリスクについて考えますので、お楽しみに！

弊社では、パブリッククラウド環境のセキュリティ対策として、純国産CNAPPの提供をしています。SOCでの運用サポートサービスも行っておりますので、詳しく知りたい方は、ぜひ資料DLよりお役立ち情報をご覧ください。