サイバー スナップショット レポート
サイバー スナップショット レポート
Google Cloud Security
目次
この「防御側のメリット - サイバー・スナップショット レポート」では、サイバーセキュリティ防御の分野で新たに注目されている重要なトピックについて、実用的な知見をご紹介します。これらの知見は、サイバー攻撃への対応と分析を行う Mandiant が最前線で直接観察した結果と実体験から得られたものです。
昨年の生成 AI（人工知能）の躍進により、多目的の大規模言語モデル（LLM）も大衆の注目を集めるようになりました。現在各組織は、LLM の機能を活用して、カスタマー サービス、業務最適化、コンテンツ作成、全体的な生産性の向上を実現すべく競い合っています。
一方、LLM などの AI 対応アプリケーションの急速な成長に伴い、関連する脆弱性のリスクが高まっています。残念ながら、市場での先駆けを目指すあまり、セキュリティが後回しにされることがよくあります。
しかし、あらゆる新しいアプリケーションと同様に、アプリケーション周りのセキュリティ対策を評価することがベスト プラクティスとなります。従来のアプリケーション評価手法と類似している点もありますが、AI 対応アプリケーションには、設計、構築、評価の全体を通して考慮するべき微妙な違いも存在します。
LLM の魅力
LLM は、広範なデータセットでトレーニングされた大規模なニューラル ネットワークです。LLM は、トレーニングに使用されたデータセットの種類に応じて、テキスト生成、翻訳、要約、一般的な質問応答など、さまざまなタスクを実行するようにカスタマイズできます。
ほとんどの組織は、ウェブベースの形式で LLM をデプロイしています。そのため、顧客やユーザーは、使い慣れた形式（ウェブ アプリケーション経由）で LLM と対話でき、デベロッパーは、公開されたウェブ アプリケーション プログラマブル インターフェース（API）を使用して、明確に定義された方法で LLM を活用できます。
LLM は、汎用的な言語生成を日常的に実行し、ユーザー自身と、ユーザーからのカスタマイズされたクエリを「理解」する能力を模倣します。そのため、ウェブベースの LLM は、チャットボット、検索エンジン、バーチャル アシスタントなど、ユーザー エクスペリエンスの向上という目的に非常に適したものとなります。
LLM の特性
ウェブベースの汎用 LLM が理想的なものになるかどうかは、次の 4 つの特性によって決まります。
1 つ目はプロンプトです。アプリケーションのフロントエンドを介してエンドユーザーから与えられるクエリのことです。プロンプトを使用して、ユーザーと LLM の対話のコンテキストを設定し、会話の性質を導くことができます。プロンプトが具体的であるほど、LLM はデータセットを適切に活用してユーザーの質問に答えることができます。
2 つ目は公開 API です。LLM は、エンド アプリケーションで使用できるように、API インターフェースを意図的に公開します。これらの API により、従来のウェブ アプリケーションで LLM の機能を活用できるようになります。
3 つ目はデータです。データは、ユーザーのプロンプトに回答するために必要な情報をモデルに供給します。データの品質は重要です。LLM は、データの量と具体性に応じてユーザーのクエリを適切に処理し、ユーザーにとって有益かつ正確な回答を生成できるようになるためです。
4 つ目はトレーニング セットです。これは、モデルを最終的な目的に適合させるために、モデルの最初のトレーニングに使用されたデータのことです。これもやはり品質が重要になります。
LLM の脆弱性トップ 10
ウェブ アプリケーションが進化し、普及が進むにつれて、残念ながら、ウェブ アプリケーションに関連する脆弱性の数と種類も増えています。Open Web Application Security Project（OWASP）は、公表されているウェブ アプリケーションの脆弱性の数と種類をまとめ、数年ごとに最も一般的な脆弱性のトップ 10 ランキングを発表しています。
同様に、LLM 固有のアプリケーションについても、OWASP のトップ 10 リストが新たに作成されています。
LLM01: プロンプト インジェクション | LLM06: 機密情報の開示 |
LLM02: 安全でない出力処理 | LLM07: 安全でないプラグイン設計 |
LLM03: トレーニング データのポイズニング | LLM08: 過剰なエージェンシー |
LLM04: モデルのサービス拒否攻撃 | LLM09: 過度な依存 |
LLM05: サプライ チェーンの脆弱性 | LLM10: モデルの盗難 |
経験豊富なアプリケーション セキュリティ担当者であれば、よくご存知の脆弱性ばかりだと思います。安全でない出力処理、モデルのサービス拒否攻撃、サプライ チェーンの脆弱性、機密情報の漏洩、安全でないプラグイン設計、モデルの盗難は、LLM に限ったものではありません。これらは、一般的なウェブベースのアプリケーションやシステムにデプロイするアーキテクチャに起因する弱点です。このアーキテクチャのポジティブな点は、この 20 年の間に定義された現在のアプリケーション手法の多くが依然として適用可能であり、それらの手法の基本原則が今もなお指針となっていることです。
まとめ
ウェブベースの LLM は、ユーザーが従来のシステムと対話する方法に革命をもたらしました。明確に定義され構造化されたクエリはもはや不要であり、会話形式のより自然な方法でアプリケーションやシステムと対話できるようになりました。そして現在、人間の好奇心と創作力の進化とともに、このテクノロジーの利用方法は広がり続けています。
ウェブベースの LLM アプリケーションは、従来のウェブ アプリケーションとほぼ同じ方法で評価できます。長年にわたるアプリケーション セキュリティ テストや、脆弱性テストにより、出力のエンコード、認証と認可、データ保護、API セキュリティなどの制御は十分に定義されています。
今後は、セキュリティの専門家は、確率的テスト戦略を組み込むように、アプリケーションのセキュリティの評価手法を進化させる必要があります。確率的テストを組み込むことで、プロンプト インジェクション、過剰なエージェンシー、過度の依存に対するウェブベースの LLM アプリケーションの評価と保護が向上し、復元力のある最新のセキュリティ アプローチを維持できるようになります。
レガシーから最先端へ: SIEM 移行ガイド
2024 年の現在も、セキュリティ情報およびイベント管理（SIEM）システムは、ほとんどのセキュリティ オペレーション センター（SOC）の基幹システムであり続けています。SIEM は常に、組織全体からセキュリティ データを収集して分析し、脅威を検出、調査し、対応するために使用されてきました。しかし、15 年以上前に構築された SIEM と現在の SIEM は、実はほとんど別のものです。最新の SIEM には、クラウドネイティブ アーキテクチャに加え、ユーザーとエンティティの行動分析（UEBA）、セキュリティ オーケストレーション、自動化、対応（SOAR）、攻撃対象領域管理、AI（人工知能）などの機能が組み込まれています。
従来の SIEM の多くは、動作が遅く、操作が面倒で、不便なものです。従来型のアーキテクチャが原因で、大量のログソースを取り込むためにスケーリングできないことが多く、最新の脅威や機能に対応できないものもあります。そのため、組織の特定の要件に対応する柔軟性に欠けることがあり、また、ほとんどの組織にとって現実のものとなっているマルチクラウド戦略にも適さない可能性があります。そして従来の SIEM では、AI などの最新の技術開発を活かすことが難しい場合があります。
SIEM 移行の始まり
最近、SIEM の分野では、軽視できない構造的変化が起きています。このような変化により、従来の SIEM プラットフォームから最新のプラットフォームへの移行が加速し、多くの組織が、移行するかどうかではなく、いつ移行するかという判断を迫られることになります。
過去 1 年間の SIEM 市場の主な動き:
2023 年 9 月:
- Cisco が Splunk 買収の意向を発表
2024 年 5 月:
- Crowdstrike が新しい SIEM サービスを導入
- Exabeam と LogRhythm が合併の意向を発表
- IBM が QRadar クラウド事業を Palo Alto Networks に売却し、QRadar オンプレミス版の顧客向けの新開発を中止
Google Cloud Security のエキスパートは、数十年にわたり数百件もの SIEM 移行に立ち会い、助言を提供してきました。このような経験から、Google には、あらゆる規模の組織が適用できるベスト プラクティスに関する知見があります。それを基に、2024 年における SIEM の移行の要点を確認してみましょう。
新しい SIEM の選択
新しい SIEM ソリューションを評価するときは、まず自分自身とセキュリティ チームに次の質問を行います。これにより、各 SIEM オプションの長所と短所が明確になり、それが組織のニーズを満たすかどうかを判断できます。
1. クラウドネイティブな SIEM
その SIEM は、世界規模のインフラストラクチャを卸価格で提供できる主要なクラウド サービス プロバイダ（CSP）によるものですか？
経験上、自社所有ではないクラウドで事業を行う SIEM プロバイダは、そのようなモデルに付きものの「マージンの積み重ね」を克服することが困難であることがわかっています。クラウドネイティブな SIEM のデプロイモデルでは、新たな脅威に応じて SIEM のスケールアップとスケールダウンが可能なほか、組織のクラウド ワークロードの動的な性質の管理も可能です。クラウドネイティブな SIEM は、クラウド サービスから低レイテンシでデータを取り込めるうえに、クラウドでよく見られる攻撃を検出できる検出コンテンツが用意されているため、クラウド ワークロードのセキュリティ確保の面でも有利です。
2. SIEM とインテリジェンス
その SIEM ベンダーは、組織に特有の新たな脅威の検出をすぐに行えるように、最先端の脅威インテリジェンスを継続的に入手していますか？
脅威インテリジェンスは、組織がセキュリティ インシデントの検出、優先順位付け、調査、対応を効果的に行うために不可欠です。特に最先端の脅威インテリジェンスは、最新の脅威や脆弱性に関するリアルタイムの情報を提供するため、非常に価値があります。
セキュリティ関連企業はリアルタイムの脅威の検出機能と対応機能を向上させるために、脅威インテリジェンスと関連データフィードをセキュリティ運用のワークフローやツールにシームレスに統合することを模索しています。
3. SIEM とキュレートされたコンテンツ
その SIEM ソリューションは、サポート対象のパーサーや検出ルール、対応アクションについて、ライブラリを豊富に用意していますか？
一部の SIEM ベンダーは、一般的なデータフィード用のパーサーの作成を、ほぼユーザー コミュニティと技術提携パートナーだけに頼っています。活発なユーザー コミュニティは不可欠ですが、解析や検出ルールのコンテンツのような基本的な機能の提供をユーザー コミュニティに頼りすぎるのは問題です。一般的なデータソース用のパーサーの作成、メンテナンス、サポートは、SIEM ベンダーが直接行うべきです。検出ルールの内容を検討するときも同じアプローチを採用します。コミュニティのルールは不可欠ですが、核となる検出については、定期的にテスト、サポート、改善が行われる堅牢なライブラリを作成し維持することをベンダーに求めるべきです。
4. SIEM と AI
その SIEM には AI が組み込まれていますか？今後もイノベーションを継続する体制が整っていますか？
SIEM における AI の役割は、どのベンダーもまだ完全には理解しておらず、ましてや実装には至っていません。しかし最先端の SIEM にはすでに、実際の AI 駆動型の機能が搭載されています。たとえば、検索やルールを表すための自然言語処理、ケースの自動要約、推奨される対応アクションなどの機能が挙げられます。ほとんどのお客様や業界の観測筋は、脅威の検出や敵対者の予測分析などの機能を、AI 駆動型の SIEM 機能における究極の目標として捉えています。現在のところ、そうした機能を確実に提供できる SIEM はありません。2024 年に新しい SIEM を選択する場合は、そうした変革的な機能が有意義な進歩を遂げられるように、必要なリソースをベンダーが投資しているかどうかを考慮してください。
まとめ
進化する脅威に対応するためには、従来の SIEM から最新のソリューションへの移行がどうしても必要になります。移行は困難な課題に思えるかもしれませんが、綿密に計画して実施することで、組織の脅威の検出、調査、対応能力、全体的なセキュリティ ポスチャーを大幅に向上させることができます。
SIEM の移行に関する詳細なガイドについては、「SIEM を移行する優れた方法: レガシー システムから脱却するためのガイド」の全文をご覧ください。
Google の最新のクラウドネイティブ SecOps プラットフォームについて詳しく知りたい方は、Google のウェブページをご覧ください。
デジタル ネイティブ攻撃の増加
従来のオンプレミスのデプロイ環境からクラウド コンピューティングに移行するケースは増え続けています。Mandiant では最近、クラウドへのシステム移行が増加しているのと並行して、新たなデジタル ネイティブ組織の立ち上げも同様に増加していることを確認しています。
デジタル ネイティブとは、企業が使用する中核的な技術機能またはインフラストラクチャを指します。Mandiant では、デジタル ネイティブ組織の定義を、1 つ以上のクラウド プラットフォーム上に構築され、ほぼ完全にその中で運営されている組織としています。こうした企業は通常、小規模なデジタル フットプリントからスタートし、ビジネスニーズの拡大に伴い、他のクラウドや Software-as-a-Service（SaaS）のサービスを採用して拡大していきます。
デジタル ネイティブ組織の従業員は、通常、企業が選択したシングル サインオン（SSO）プロバイダ（Okta、OneLogin、M365、JumpCloud など）にログインしてから、業務を遂行するために必要なアプリケーションやクラウド サービスを利用します。通常、従業員がフォールバックできる専用の VPN や ID 管理プラットフォーム（Active Directory）はありません。
デジタル ネイティブとクラウド コンピューティングという新しい技術インフラストラクチャへの移行が進んでいるにもかかわらず、Mandiant のインシデント対応担当者は、これらの独特な環境においても攻撃者の活動が減少しているという事実は確認していません。これは、企業がサイバー防御体制に適応する前に、攻撃者の方が戦術・技術・手順（TTP）を適応させていることを示唆している可能性があります。デジタル ネイティブの将来的な脅威に備えるには、まずデフォルトで保護されているという思い込みを打破する必要があります。
デジタル ネイティブのセキュリティの課題
デジタル ネイティブ環境の増加により、セキュリティ チーム、特にレッドチームとブルーチームが、こうした新しいエコシステムに関連するセキュリティ上の課題を理解する必要があることが明確になっています。こうした課題は、従来のオンプレミスのデプロイとは異なる固有の課題であるからです。こうした固有の課題とは何か、また、サイバーセキュリティの専門家がこうした課題に対処するにはどのようなスキルが必要なのか、という疑問が生じます。
攻撃者と防御者が、ドメイン コントローラや証明書サービスなどの少数の主要なインフラ資産を保護するために熾烈な競争を繰り広げることはなくなりました。ただしその代わりに、組織におけるあらゆるクラウド リソース、SSO アプリケーション、データ接続が同等の脅威にさらされるようになっています。API、IAM、Kubernetes、Docker、サーバーレス関数、マイクロサービス、クラウド データベース、ストレージ、ネットワーキング、CI/CD パイプライン、その他のゲートウェイなど、各種テクノロジーを利用したデジタル ネイティブ アーキテクチャでは、それぞれのテクノロジーが攻撃者の侵入ポイントとなる可能性があります。サードパーティの SaaS アプリケーションが侵害された場合に、攻撃者が組織のクラウド環境に無制限にアクセスできる可能性があることは、徹底したセキュリティ テストを行わないとわかりません。成熟したデジタル ネイティブ環境では、相互接続のレベルが高く、サードパーティ アプリケーションと組織の「最重要資産」の境界が曖昧になっています。
デジタル ネイティブ環境のセキュリティ チームに特有のもう一つの課題は、攻撃の実行に使用されるプロトコルです。デジタル ネイティブ環境は、主に従業員のウェブブラウザからアクセスできるように設計されたアプリケーションとサービスで構成されているため、多くの攻撃はレイヤ 7 で発生します。レイヤ 7 では、HTTP などの一般的なエンドユーザー プロトコルによって組織のリソースの操作が行われます。そのため、セキュリティの専門家は、専用のコマンドライン ユーティリティではなく、主にウェブブラウザを使用して、環境内のユーザーの役を演じ、アプリケーションやサービスを操作する必要があります。この制約により、新しいデジタル ネイティブ環境の内部の状況を把握するために必要な手作業が大幅に増加します。
また、この制約の副産物として、従来のエンドポイント検出対応（EDR）ソリューションは効果がはるかに低くなります。正当なユーザーと悪意のあるユーザーが同じ方法で環境と対話しているため、防御者が本当の脅威と無害なユーザー リクエストを区別するために行う手動確認の量が大幅に増加します。この観点から見ると、デジタル ネイティブ環境の保護は、SSO とクラウド プラットフォームの信頼関係で結び付けられた一連の個々のウェブ アプリケーションの保護に似てきています。
また、必要なアプリケーションやサービスは企業ごとに異なるので、ある企業環境について得られた情報が、別の企業環境の理解に役立つことはほとんどありません。このような標準化の欠如により、セキュリティの専門家に求められる創造力のレベルが増大しています。
最前線のケーススタディ
Mandiant は、最前線で確認されているデジタル ネイティブ攻撃者の傾向を、レッドチームの活動で使用する手法に反映させています。その一つとして、大規模なデジタル ネイティブ組織を標的とし、その組織で最重要資産と見なされている内部の管理用ウェブ アプリケーションへのアクセスを試みるという、Mandiant とお客様が共同で設定した目標に取り組む活動が挙げられます。
偵察
このアプリケーションは最重要資産であり、最近サードパーティによるコード監査を受けています。認証には有名な SSO プロバイダを使用していました。Mandiant のレッドチームは、このアプリケーション自体が一般的なウェブ攻撃に対して脆弱である可能性は低いと判断し、同じ環境内の他の SSO アプリケーション（最重要資産のアプリケーションに接続できるもの）のテストに優先的に取り組みました。そのようなアプリケーションとして、アクセス リクエスト管理プラットフォーム、Kubernetes マネージャー、API 開発ツールなどが挙げられます。Mandiant はこれらの接続を厳密に文書化し、それぞれの接続で利用可能なアクセスレベルの評価を開始しました。
権限昇格
評価を進める中で、Mandiant は、社内の自動化ツールを開発するために使用されている SaaS 開発アプリケーションに対する管理者権限が、権限昇格ベクトルによって取得できることを発見しました。この活動の開始時には、この SaaS 開発アプリケーションは「低リスク」に分類されていました。これは、アプリケーション内のユーザーが、SSO プロバイダを介して割り当てられるロールと権限に制限されていたためです。当初、このアプリケーションの管理者が環境内の他の SSO アプリケーションに対するアクセス権や権限を追加で取得できる可能性があることは、指摘されていませんでした。
Mandiant は、この SaaS 開発アプリケーションの管理者権限を使用することで、多数の従業員がアプリケーションで認証を受け、内部のツールを少なくとも 1 つ毎時間実行していることを発見しました。そのため、レッドチームによる活動の方向性を転換し、そのような具体的なユーザー ワークフローについて理解してそれを悪用し、環境内の他の特権リソースへのアクセスを獲得できる可能性があるかどうかを調べることに重点を移しました。
ラテラル ムーブメント
この管理者の視点から SaaS 開発アプリケーションをさらに偵察したところ、最重要資産のアプリケーションにユーザーを接続するために使用されている設定の編集権限が Mandiant にあることがわかりました。Mandiant はその権限を使用して、各ユーザーの SSO 認証フローの最後に、Mandiant の制御下にあるサーバーに平文の SSO トークンを送信する追加のリクエストを挿入しました。この新しい構成を保存することで、Mandiant のレッドチームは、最重要資産のアプリケーションの正当なユーザーから認証リクエストを受け取りました。これらのリクエストに含まれている認証情報を利用すれば、Mandiant はリクエスト元ユーザーになりすますことができます。このインジェクションを一晩実行した結果、レッドチームは、より高い権限を持つ管理ユーザーの SSO トークンを取得し、最終的には最重要資産のアプリケーションに侵入できました。
まとめ
デジタル ネイティブな組織と、そのような組織が存在するクラウドベースの環境は、常に変化しています。かつてないほど速いペースで新しいテクノロジーが開発されて実装され、そして廃止されていくのです。こうした組織に対して確実に言えることは、新しい環境に慣れるまでサイバー犯罪者は決して待ってはくれないということです。そのため、厳重なサイバー防御を実現するには、サイバー防御の継続的な調整、レッドチームの継続的な活動、クラウド セキュリティの高度な専門知識など、プロアクティブなセキュリティ対策が不可欠です。
