LLMはSOCを大幅に強化できますが、適切に制限しなければ、攻撃者がスケールを拡大する一方で、まったく新しい攻撃面を開くことになります。
大規模言語モデル（LLM）はセキュリティの分野に3つの異なる形式で同時に登場しました。アナリストの傍らに配置される生産性ツール、製品とワークフローに組み込まれたコンポーネント、そして攻撃者がプローブ、操作、盗難の対象にできるターゲットとして存在しています。
この融合により、会話は複雑になっています。数秒でインシデントを要約できるのと同じ機能は、一見もっともらしいスピアフィッシングの前置きも生成できます。検知ロジックをドラフトできるアシスタントと同じものが、ガードレールなしで内部ナレッジベースに接続されている場合、機密コンテキストをリークするように誘導される可能性もあります。
私はLLMを別の高い影響力を持つシステムとして扱っています。つまり、結果を定義し、脅威をモデル化し、モデルが誤ったり操作される可能性を前提としたコントロールを構築するのです。
LLMがセキュリティチームの作業をどのように変えているか
「SOC内のLLM」について語るとき、多くの人はチャットインターフェースを想像します。より重要な変化はアーキテクチャレベルです。LLMは非構造化されたセキュリティデータを構造化された仮説、ナラティブ、次のステップに変換することを低コストで実現できます。これが重要なのは、セキュリティ業務の大部分が技術的に難しいものではなく、コンテキストの結合だからです。
セキュリティプログラム内にLLM機能を展開する場合、出力がアドバイザリで検証しやすい狭い一連のワークフローから始めます。その後、チームが品質を測定し、失敗モードを管理できるようになった後に初めて拡張します。
早期導入に適した高価値のユースケースを以下に示します。
- 生テレメトリを「何が起こったのか、なぜそれが重要なのか、次に何をチェックすべきか」というナラティブに変換するアラートトリアージサマリー
- ログ、チケット、チャットトランスクリプトからタイムラインを生成し、ギャップと推奨される枢軸を強調するインベスティゲーションコパイロット
- エンジニアが確認とテストを行うためのSigma、YARA、またはクエリ言語スニペットのドラフトを作成するための検知エンジニアリング支援
- 同様の結果をクラスター化し、悪用可能性をビジネス用語で説明し、パッチウィンドウを提案する脆弱性管理コパイロット
- アシスタントが依拠した正確な内部統制言語を引用して質問に答えるポリシーおよび標準Q&A
これらの安全なシナリオでも、私が使用する運用ルールはシンプルです。LLMの出力を信頼されていないものとして扱うことです。モデルがコードを書く、遵守アクションを推奨する、または内部データを参照することが許可されている場合は、それが幻覚を見たり、社会的にエンジニアリングされたり、不安全な動作に促すされたりする可能性があると想定する必要があります。
OWASPコミュニティはLLM対応アプリケーションの一般的な失敗モードをカタログ化しており、プロンプトインジェクション、不安全な出力処理、機密情報の漏洩、過度なエージェンシー、過度な依存などが含まれます。これらは学術的な概念ではありません。セキュリティワークフローでのLLMの失敗方法に直接マップされます。OWASP Top 10 for LLM applicationsを参照してください。
実際には、セキュリティにおけるLLM展開を3つのレイヤーと考えます。モデル、それが見ることができるデータ、そしてそれが取ることができるアクションです。最初のレイヤーを広げることで（たとえば、より良いモデルやプロンプトを使用することで）、他の2つのレイヤーを制限されたままにして、かなりの価値を得ることができます。
3つの設計選択により、価値を損なうことなく一貫してリスクが低減されます。
- ソースを明示的にする。検索拡張生成を使用して、アシスタントがキュレートされたドキュメント、チケット、またはプレイブックから回答し、引用されたスニペットをアナリストに表示します。
- モデルをブラスト半径から除外する。モデルはシークレットを保持してはいけません。短命のクレデンシャル、スコープされたトークン、ツールへのブローカー付きアクセスを使用します。
- アクションをゲートする。システムの状態を変更するもの（ブロック、検疫、削除、メール送信）は、人間の承認または別のポリシーエンジンを必要とします。
リーダーシップはそれでも測定について明確な視点を持つ必要があります。アシスタントが応答時間を短縮するか信号品質を向上させるかを定量化できない場合、不確実な利得のために新しいクラスの運用リスクを負っています。
攻撃者が同じ機能を使用してスケールとパーソナライゼーションを行う方法
ディフェンダーだけがコンテキスト結合を自動化しているわけではありません。攻撃者はLLMを使用して偵察を行い、言語を作成し、迅速に反復することができます。結果は新しい攻撃ではなく、むしろ攻撃者の経済学の変化です。より安いパーソナライゼーション、より高速な反復、および言語の障壁の低下です。
最も直接的な影響はソーシャルエンジニアリングにあります。良いフィッシングメールは単なる正しい文法ではありません。それは状況的な関連性です。正しいトーン、正しい内部用語、ビジネスプロセスの正しい瞬間です。LLMはそのような調整をスケールで簡単にします。
Heiding、Lermen、Kao、Schneier、Vishwanathによる2024年の研究は、人間の被験者で検証された完全に自動化されたスピアフィッシングキャンペーンを評価しました。彼らの実験では、AI生成のメールは人間の専門家と同等のパフォーマンスを示し、一般的なフィッシング制御グループより大幅に優れていました。この論文は完全に読む価値があります。なぜなら、それは問題を定量化し、攻撃者の経済を具体的にするからです。
同時に、組織はLLMを内部ナレッジベース、チケッティングシステム、ワークフローツールに接続することにより、新しい一連のソフトターゲットを作成しています。攻撃者がユーザー制御入力、共有リポジトリ内のドキュメント、またはアシスタントが読むことが許可されているセキュリティ侵害されたWebページを通じてプロンプトインジェクションを誘導できる場合、モデルはデータ漏洩または不安全なアクション用のコンジットになる可能性があります。
これが、LLMセキュリティを攻撃的および防御的なディシプリンの両方として扱う理由です。LLM対応の脅威から組織を防御しており、独自のLLM対応システムを防御して、それらが自分に対して使用されないようにしています。英国科学技術革新省は、デザイン全体のメンテナンスからAIライフサイクル全体の脆弱性をマップしています。これはセキュリティチームにとって有用なメンタルモデルです。
これを実行可能に保つため、攻撃者の機会を3つのバケットに分類しています。
- 説得エンジンとしてのLLM。より良い前置き、より優れた多言語詐欺、より良い偽装、およびより良い詐欺スクリプト
- 生産性エンジンとしてのLLM。コモディティマルウェア、スクリプト、偵察レポート、エクスプロイト適応の高速反復
- ターゲットおよびピボットとしてのLLM。プロンプトの盗難、システム指示の抽出、データソースの中毒、またはツール使用エージェントの操作
防御的な含意は不快です。特に検証、本人確認、プロセスの強化など、既存のコントロールのいくつかがこれまで以上に重要になります。幹部承認ワークフローが説得力のあるメッセージでバイパスできる場合、LLMは攻撃者がその弱点をより速く見つけて悪用するのを支援します。
LLMはコンテンツベースの検出も複雑にします。攻撃者がクリーンな言語を生成できる場合、トーンやグラマーの手がかりよりも技術的および行動的シグナル（送信者認証、異常なログイン、異常な支払いリクエストパターン）に重みを置きます。
LLMを使用しながらプロットを失わないコントロールスタック
組織はLLM用に真新しいガバナンス体制が必要だと思いません。彼らは既存のガバナンス筋肉を新しい失敗モードに適用する必要があります。最も近い適合はモデルの崇拝ではなくリスク管理です。
有用なアンカーはNIST人工知能リスク管理フレームワークで、これはアクティビティをガバン、マップ、測定、管理に組織します。価値はラベルにはなく、ディシプリンにあります。責任を定義し、コンテキストと影響を理解し、リスクを測定し、軽減策を運用化します。
LLMプログラムについてセキュリティおよびリスク委員会にアドバイスしている場合、次のコントロールスタックを提案します。意図的に実用的で、サードパーティモデル、内部データ、ツール統合の混合環境を想定しています。
- ガバン。モデルが何をすることが許可されているか、誰がそれを所有しているか、あなたのコンテキストで安全でないことが何かを定義します（データクラス、規制対象ワークフロー、重大な決定）。
- マップ。プロンプト、データソース、検索パイプライン、プラグイン、ダウンストリームアクションを含む、モデルエンドポイントだけでなく、エンドツーエンドのシステムを文書化します。
- データを保護する。トレーニング、ファインチューニング、検索コーパスをインベントリ化し、アクセス制御を実施し、中毒、漏洩、不正な再利用を監視します。
- AI固有の技術でスレッドモデルを作成する。MITRE ATLASを使用して、可能性の高い攻撃者の動作をマップし、シナリオにプロンプトインジェクションとツール悪用を含めます。
- 境界にガードレールを構築する。入力検証、コンテンツフィルタリング、出力制約、および自動化に供給する出力のためのスキーマベースの解析。
- 高影響力アクションをゲートする。エージェントが本番環境でステータスを変更する前に、明示的な承認、ステップアップ認証、またはポリシーエンジンのチェックが必要です。
- 本気でテストする。アシスタントをレッドチーム化し、ジェイルブレークとプロンプトインジェクションスイートを実行し、現実的な負荷の下でエラー率を測定します。
- 計測、監視、対応する。プロンプト、ツール呼び出し、出力をログに記録し、異常な使用パターンを検出し、安全でない自動化用のキルスイッチを維持します。
さらなるステップ
2つの公開ガイダンスは、安全なAIを運用ステップに変換するため、読む価値があります。第1に、「安全なAIシステム開発のガイドライン」—英国国立サイバーセキュリティセンター（NCSC）および米国サイバーセキュリティおよびインフラストラクチャセキュリティ庁（CISA）が発行したドキュメント—は、安全な設計から安全な運用と保守までのライフサイクルガイダンスを提供しています。第2に、「AIシステムを安全に展開する」—米国国家安全保障局の人工知能セキュリティセンター（AISC）およびサイバーセキュリティおよびインフラストラクチャセキュリティ庁（CISA）、ならびに他の国および国際機関によって共同発行—は、外部開発されたAIシステムの展開と運用のためのベストプラクティスに焦点を当てています。
最後に、過度なエージェンシーを意図的に交差させるラインとして扱います。LLMベースのエージェントに与える自律性が多いほど、新しいクラスの特権ソフトウェアを構築しています。ジュニアスクリプトに制限されたAPIアクセスを与えない場合は、確率モデルに与えてはいけません。
LLMとサイバーセキュリティの融合はオプションではありません。攻撃者はこれらのツールを使用し、従業員はすでに使用しています。利点は生産性の向上をキャプチャしながら、データ、アイデンティティ、変更管理の制御を保つことから来ます。
この記事はFoundry Expert Contributor Networkの一部として発行されています。
参加したい場合は？
