[レポート]生成 AI でセキュリティ強化！×生成 AI の脅威分析に参加しました(AWS-17) #AWSSummit

はじめに

お疲れさまです。とーちです。

現在開催中のAWS Summit 2024で行われた「生成 AI でセキュリティ強化！×生成 AI の脅威分析」のレポートをお伝えします。

セッション視聴

セッションはオンデマンドで視聴可能です。公開期限は2024年7月5日（金）までとなっておりますので、視聴される場合はお早めにアクセスしてください。

セッション概要

セッション概要 タイトル : 生成 AI でセキュリティ強化！×生成 AI の脅威分析

生成 AI を活用する上でセキュリティは欠かせません。本セッションでは、生成 AI を使ったセキュリティ強化の方法と、生成 AI を使う際の脅威分析について解説をします。生成 AI を用いたセキュリティ強化をする例として、セキュリティアシスタントとしての活用を取り上げます。そこではユーザーに対し、正確、かつ、セキュリティポリシー・社内のナレッジ等の組織の状況に即したアドバイスが求められます。それらを実現するため、一貫した情報提供を可能とする、Amazon Kendra、Amazon Security Lake、Amazon Bedrock 等を用いた実装例を紹介します。また、生成 AI を用いるには、生成 AI の進歩に伴う新たなセキュリティ脅威への理解も不可欠です。医療履歴を管理するサンプルアプリを例に、セキュリティ脅威の発見と分析の考え方をご紹介します。

スピーカー : 長谷 有沙

セッションレベル : 200

レポート内容

前半

生成AIの役割

• AWSの生成AIの定義
  • プロセスを合理化して効率を高め、組織に貴重なインサイトを提供する
• 具体例
  • 普段セキュリティの業務に携わるなかでログの解析や脅威トレンドをおいかけてると思うが、それが本来的なやりたいことかというと違うはず
  • 自社のセキュリティ対策を今後どのようにししていくかを考えることこそがやりたいことではないか？
  • 生成AIををつかうことでログの解析やレポート生成をある程度自動化できる
  • これによって本来やりたいことに時間を割けるはず
• 生成AIをセキュリティアドバイザーとして活用するDEMO
  • DEMOではある手法を使ってサンプル環境のログをインプットしている
  • DEMOではセキュリティペストプラクティスと推奨対策がなにかを質問する
  • 実際の生成AIアプリとのやり取りの内容
    • ユーザ：私達のチームはIAMのアクセス権限付与の戦略に苦労している、IAMの戦略としてどのようなものを使えばいいか？
    • 生成AIの回答：個々のユーザに権限付与をするのではなくロールやグループを使いましょう
    • ユーザ：自分たちの組織が優先すべき戦略はどんなものがあるか？
    • 生成AIの回答：優先すべき戦略は、権限が大きいIAMロールがあるが最小権限になっているかを棚卸しすべきという提案
  • 生成AIをつかうことでドキュメントを調べる時間を削減できる。生成AIの回答をもとに次のアクションを検討することができる

生成AIを用いたセキュリティの強化、利用する際の注意点

• ハルシネーションのリスク
  • 古い回答や間違ってた回答をするというリスクがある
  • 正しいが自社にはそぐわないという回答
• 生成AIにどこまで情報を入れていいかという悩み
• これらを鑑みると生成AIでは人間による確認がまだ必要といえる
• ハルシネーションを軽減しながらも生成AIを活用していくのが課題といえる

ユースケースに沿った生成AI活用方法

• 生成AIの回答精度向上にはコンテクストベースの活用が重要
• より役立つ回答を生成AIにさせるにはデータの反映度合いがポイントになる
• 生成AIにそれほど詳しくない人でも精度向上が望めるのがRAG
• RAGとは
  • RAGは事前に定めたトレーニングデータ以外の信頼できる知識ベースを参照させるもの。LLMへの質問のインプット情報として使用する
  • アプリの開発者でどの情報を参照させるか指定
  • アプリケーションの開発者にとっては参照情報の指定をするだけなので生成AIの詳細な知識はいらない
  • RAGはAWS上でも構築できる
• RAGの選択肢をAWSでは２つ用意している
  • Amazon Kendra
    • Amazon Kendraは数十種類のネイティブコネクタを備えている
  • OpenSearchService
    • OpenSearchServiceはamazon security lakeなどのログのデータを取り込むのが得意
• RAGにインプットする情報はユースケースに即したものにする
• DEMOのアーキテクチャでもRAGを使っていた。以下の情報をインプットとしていた
  • セキュリティポリシー
  • IAMドキュメント
  • アカウント内のセキュリティ状況、SecurityLakeのSecurityHUbの検出結果
• 人間が判断するときにここは見るだろうというデータを与えるのが重要
• 前半まとめ
  • 生成AIの出力は次のアクションを決めるアドバイスになる
  • 生成AI未経験でも生成AIのメリットを享受可能
  • ユースケースにそって　出力を最適化できる

後半

生成AIを保護するセキュリティ

• 対応すべきリスクの見極めが重要
• 生成AIは新しい分野なのでプロアクティブにリスク分析する必要がある
• リスクベースアプローチとベースラインアプローチがある
  • リスクベースアプローチは対象システムの実際の攻撃を想定してすすめる
  • ベースラインアプローチは業界の基準などを元に対策を決めるアプローチ
• 生成AIでは新しい分野なのでリスクベースアプローチが適している
• 脅威モデリングとは
  • 脅威を可視化してセキュリティ対策を実施していくための手法
  • アウトプットとしてはシナリオとアクションがリスト化される
  • リスト化したあとは脅威の内容同士を比較して受容度を決める
• 脅威モデリングで行うこと４つ
  • ステップ１：開発対象はどのようなものか
    • 開発対象のプロダクトの理解は開発ドキュメントをベースに開発メンバーとともに実施する
    • 例として医療履歴を質問できるアプリケーションを取り上げる
    • アーキテクチャ図を理解する、機微情報がどこにあるかなどを確認するのがポイント
    • 次はデータフロー図の分析、プロセスとデータストアを明確化することでよりどこにどのようなデータがあるかを分かりやすくしていく
  • ステップ２：落とし穴はどこか
    • プロダクトの理解をしてきたところで、脅威を考えるうえでの参考情報を確認する、反復することでどのような攻撃手順を整理する
    • STRIDE　脅威のフレームワークを使うことで網羅的な観点で脅威を洗い出せる
    • 脅威インテリジェンスの確認。OWASP TOP10 for LLM Applicationsなどをみることで典型的な脅威を理解する
    • 脅威シナリオの例：悪意あるプロンプトによる他のユーザーデータの搾取
    • 脅威シナリオを具体的に脅威構文に落とし込む
    • 脅威モデリングをするときにいくつもの脅威シナリオを考える。なるべく同じ文章を含めることで比較しやすくする
    • 例えば、
      • 「前提条件」を備えた「脅威ソース（アクター）」が「脅威のアクション」を実行しうるため、「脅威のインパクト」につながる可能性があり、「脅威を受ける資産」の「目標に」悪影響を及ぼす
      • ※「」で囲った部分を脅威シナリオごとに変えていく
    • これを繰り返すのが脅威モデリング
  • ステップ３：このシナリオが成立するかを実際に攻撃して確認する
    • DEMOでは、mysqlのカラム名を糸口に他のユーザの情報を引き出していた
    • 攻撃を可能としたステップを理解する
    • ４段階あった
      • アプリはユーザからどんなプロンプトも受け入れていた
      • プロンプトはLLMからLogicにそのまま渡されていた
      • LLMはプロンプトからSQLを生成していた
      • SQLクエリはLLMのレスポンスとして渡される
    • 攻撃の対策
      • どんなプロンプトでも受け入れるのであれば、対策としては許容可能なプロンプトのみを受け入れるようにするなど
      • 一つだけ対策するのではなく多層防御するのが大事
      • 脅威インテリジェンスもヒントになる
  • ステップ４対処は十分か？
    • 対策の評価は、２種類ある
      • 実装した緩和策の妥当性
      • 脅威モデリングプロセスの検証
• 後半のまとめ
  • 生成AIのセキュリティ対策特別なものは必要ない。脅威モデリングで対応できる
  • 参考情報として使えるのがフレームワークや脅威インテリジェンス

感想

生成AIアプリケーションであっても、従来の脅威モデリングは十分に機能することが分かりました。 直近脅威モデリングを勉強していたこともあり、実際の脅威モデリングの方法を具体的に学べたのがとても良かったです。 実際の現場で脅威モデリングをするとより理解が深まりそうだと思ったので機械があれば実施してみたいと思います！