「STRIDE-AI × Human Factors」第3回
RAGチャットボットを脅威モデリングする―STRIDEの中にHuman Factorsをどう入れるか
RAGチャットボットは、生成AIの中では比較的「安全にしやすい」仕組みだと思われがちです。
社内文書を検索し、その根拠に沿って回答させる。モデルの記憶だけに頼らない。引用元も示せる。たしかに、モデル単体より管理しやすい部分はあります [1]。
でも、私はここに少し引っかかります。
参照先があることと、その参照先を信じてよいことは、同じではありません。
文書が改ざんされていたらどうでしょう。検索結果に、本来その利用者が見てはいけない情報が混ざったら。出典が表示されていても、忙しい担当者が開かなかったら。AIが自信のある文章で「規程上、問題ありません」と答えたとき、その場で立ち止まれるでしょうか。
RAGのリスクは、モデルの中だけにはありません。
文書を作る人、登録する人、権限を設定する人、回答を読む人、承認する人、そして事故のあとに調査する人。その全員を含む流れの中にあります。
今回は、具体的な社内RAGチャットボットを一つ置き、STRIDEで脅威を洗い出します。そのうえで、それぞれの脅威にHuman Factorsがどう入り、どこで人の判断が揺らぎ、逆にどこで止められるのかを見てみます。
ここで扱う「STRIDE-AI × Human Factors」は、STRIDEを生成AIシステムの五つの層へ適用する研究提案 [2]を踏まえつつ、そこへHuman Factorsを横断的に重ねる、私自身の社会技術的な見方です。既存規格の正式名称ではありません。また、本稿で使う「サイバー判断力」も標準化された尺度ではありません。実務で使えるよう、後ほど作業定義を示します。なお、STRIDE-AI論文はMicrosoftの出版物ではありません。
まず、何を守るのか
想定するのは、社員が人事、法務、情報セキュリティ、顧客対応などの社内文書を検索できるRAGチャットボットです。
利用者の質問はアプリケーションへ渡り、検索処理がベクトルデータベースや文書保管庫から関連文書を取得します。その文書と質問をモデルへ送り、生成された回答を、引用元とともに利用者へ返します。
流れを単純化すると、次のようになります。
利用者 → UI → RAGアプリケーション → 検索基盤／文書庫 → モデル → 回答 → 利用者
ただし、裏側には別の流れもあります。
文書作成者 → レビュー／承認 → 文書登録 → 分割・埋め込み → インデックス更新
守りたいものは、少なくとも五つあります。
1. 回答の根拠となる文書の真正性と完全性
2. 利用者・文書・検索結果に対するアクセス制御
3. 質問、検索結果、モデル出力、操作履歴の機密性
4. 誰が何を入力し、何が検索され、何を出力したかという追跡可能性
5. 利用者が業務判断を安全に行い、必要なら拒否・停止・回復できること
最後の一つは、従来の情報資産一覧では見落とされやすいものです。しかしAIが意思決定へ近づくほど、人が判断できる状態そのものを守る必要があります。
STRIDEを使う前に、信頼境界を引く
脅威モデルでは、どこを情報や権限が越えるのかを見ます。このRAGには、少なくとも次の信頼境界があります。
- 利用者とUIの間
- UIとRAGアプリケーションの間
- RAGアプリケーションとモデル／外部APIの間
- RAGアプリケーションと文書庫・ベクトルDBの間
- 文書を登録する人と、登録後のナレッジベースの間
- AIの提案と、人間の業務判断・実行の間
最後の境界は、技術的なAPI境界ではありません。けれど、ここを描かないとHuman Factorsは「利用者教育」という別紙に追い出されます。
私は、AIの出力が人の判断へ変換される場所も、明示的な信頼境界として扱うべきだと考えます。
サイバー判断力とは何か
この連載でいうサイバー判断力とは、単にセキュリティ用語を知っていることではありません。
不確実性と時間制約のある状況で、異常の手掛かりを捉え、その意味と影響を考え、AIの提案を疑い、保留し、拒否し、必要な相手へ上げ、行動後には止めて回復できる力です。
もう少し分けると、次の五つです。
1. 気づく―出典、権限、文体、検索範囲などの異常を認知する
2. 意味づける―それが単なる誤差か、攻撃や漏えいの兆候かを解釈する
3. 先を読む―この回答を採用・実行した場合の影響を予測する
4. 選ぶ―確認、保留、拒否、隔離、報告のどれを取るか決める
5. 回復する―誤った判断のあとでも、停止、取消し、調査、再発防止へ移れる
これは状況認識に関する「知覚・理解・将来予測」という考え方を、RAGを使うサイバー判断へ展開した作業定義です。セキュリティ専門家の判断研究でも、脅威の手掛かりを認知し、意味を理解し、先の影響を予測する過程が、対策選択に関係することが示されています [3]。
大切なのは、この力を個人の資質だけにしないことです。
出典が隠れている。確認に10分かかる。承認待ちが100件ある。異議を唱えると仕事が遅いと思われる。停止ボタンがない。その状態で「人が最終確認する」と言っても、サイバー判断力は発揮できません。
NISTのHuman-Centered Cybersecurityも、人を問題の原因として扱うのではなく、人・プロセス・技術の関係を設計し、人が情報を得た主体的なパートナーとして安全に関われることを重視しています [4]。
では、この考え方をSTRIDEへ入れてみます。
S：Spoofing――「それは誰の声なのか」
具体的な脅威
攻撃者が、信頼された人事部門の文書に似せた偽の規程を登録する。あるいは、管理者や上司になりすまして「この手順は承認済みです」という文書を置く。RAGはそれを検索し、正規文書のように回答へ取り込みます。
さらに、外部サイトや受信メールを検索対象に含める場合、悪意あるページに埋め込まれた指示がAIへ渡る可能性があります。間接プロンプトインジェクションは、モデルが処理する外部コンテンツを通じて挙動を操作する攻撃として示されています [5], [6]。
Human Factorsはどこに入るか
人は、内容だけでなく、肩書、ロゴ、文体、整った説明に信頼を置きます。AIが「人事部の規程によれば」と断定すれば、出典を開かずに権威ある回答だと受け止めるかもしれません。自然な対話や知的に見える説明が、擬人化、権威バイアス、過信を通じて監督を弱め得ることは、OWASPのHuman-Agent Trust Exploitationでも扱われています [7]。
ここでの問題は、利用者がだまされやすいことだけではありません。真正性を判断するための情報を、システムが出していないことです。
必要なサイバー判断力と設計
- 回答中の「誰が言ったか」と、文書の実際の所有者・承認者を分けて見る
- 発行者、承認状態、版、更新日、署名を回答画面から確認できる
- 未承認・外部由来・真正性未確認の文書を、正規資料と同じ見た目にしない
- 権威ある依頼ほど、別経路で本人確認できる
STRIDEだけなら「なりすましを防ぐ」で終わります。Human Factorsを入れると、「利用者は何を手掛かりに本物だと判断するのか」までが脅威モデルになります。
T：Tampering――「正しい検索が、汚染された文書を見つける」
具体的な脅威
権限を持つ利用者、侵害されたアカウント、連携システムが、ナレッジベースへ悪意ある文書を登録する。特定の質問で必ず上位に出るよう文章を調整し、検索結果を誘導する。あるいは、正規文書の一部だけを書き換え、分割後のチャンクに危険な指示を混ぜます。
ベクトル・埋め込みを使うRAGでは、データポイズニング、アクセス制御、データ漏えいなどが主要な弱点として整理されています [8]。検索が仕様どおりでも、検索対象が汚染されていれば、もっとも関連度の高い「偽情報」が返ります。
Human Factorsはどこに入るか
認知バイアスは、攻撃を受けた瞬間だけでなく、日常運用の中に入ります。
担当者が「この部署の文書なら大丈夫」と考える。自分の仮説に合う回答だけを採用する。小さな表示崩れや出典の違和感が何度も無害だったため、異常を正常として扱う。更新件数が多すぎて、レビューが形式化する。
これは、確認不足というより、人が何を見るように設計され、何を見なくなるように運用されているかの問題です。
必要なサイバー判断力と設計
- 検索結果の内容だけでなく、由来、変更履歴、登録経路を確認する
- 自分の期待に合う回答ほど、反証となる資料を探す
- 高影響文書は二者承認とし、登録者と承認者を分ける
- インデックス更新を監視し、異常時に直前の安全な版へ戻せる
- 「最近追加された文書だけで結論が変わった」ことを検知・表示する
Human Factorsは、汚染を生む条件にも、汚染に気づく力にもなります。
R：Repudiation――「人が押した」で終わらせない
具体的な脅威
問題のある回答に基づいて顧客対応やアクセス変更が行われた。しかし後から、どの質問に、どの文書断片が検索され、どのモデルと設定で、どの回答が生成されたのか再現できない。
ログには「利用者が承認した」とだけ残っています。利用者は「AIが推奨した」と言い、開発側は「最終判断は人だった」と言う。誰も虚偽を述べていないのに、意思決定の経路が消えています。
Human Factorsはどこに入るか
ここでは責任の拡散と権限の混乱が起こります。
AIが提案し、人がボタンを押し、別のシステムが実行したとき、誰が実質的に決めたのでしょうか。人が承認したという事実だけでは、その人が根拠を見たか、代替案を持っていたか、拒否できたかは分かりません。
必要なサイバー判断力と設計
- 質問、取得文書と版、アクセス判定、プロンプト、モデル、出力、承認、実行を一つの意思決定記録としてつなぐ
- 「AIが提案」「人が判断」「システムが実行」の役割を区別する
- 高影響判断では、承認理由と確認した根拠を短く残す
- 異議、保留、差戻しも正常な判断として記録し、評価する
- 事故調査で当時の画面と情報条件を再現できるようにする
Repudiationへの対策はログ保存だけではありません。誰が判断できる状態にあり、誰に拒否権があったかを残すことです。
I：Information Disclosure――「答えなくても、検索した時点で漏れる」
具体的な脅威
一般社員が「役員報酬の改定」「未発表の組織再編」などを質問する。最終回答では伏せられていても、検索段階で権限外の文書がモデルへ渡る。回答の断片、文書タイトル、引用、エラーメッセージ、会話履歴から機密の存在や内容を推測できる。
また、利用者が顧客情報や認証情報を質問欄へ貼り付け、それがログ、外部モデル、分析基盤へ送られることもあります。RAGのアクセス制御は、生成後のマスキングだけでなく、検索前・取得時点で実施する必要があります [8], [9]。
Human Factorsはどこに入るか
利用者は、チャット画面を社内の安全な相談相手のように感じることがあります。入力欄が自然で、AIが親切に問い返すほど、必要以上の情報を渡しやすくなる。便利さを優先する組織では、「この程度なら大丈夫」が積み重なります。
一方で、警告を毎回出せばよいわけでもありません。頻繁な警告は読まれなくなり、本当に危険な場面の判断力まで奪います。
必要なサイバー判断力と設計
- 入力する前に、データ分類と送信先を判断できる
- 「回答に表示されない」と「システムへ送られない」を区別する
- 利用者権限を検索時に適用し、権限外文書をモデルのコンテキストへ入れない
- 機密入力は送信前に検知し、安全な代替手段をその場で示す
- 文書タイトルや件数、類似度スコアなど、存在推測につながるメタデータも保護する
ここでは、人に注意を求めるより、機密を渡さなくても仕事を完了できる経路を用意する方が強い対策です。
D：Denial of Service――「止まる」だけでなく、「人が追いつけなくなる」
具体的な脅威
極端に長い質問、大量リクエスト、巨大文書の反復登録により、検索・推論コストや待ち時間を増大させる。さらに、攻撃者が大量の低品質文書を登録し、検索結果をノイズで埋めることも考えられます。
RAGの可用性低下は、システム停止だけではありません。応答が遅い、根拠が多すぎる、警告が大量に出る、担当者の確認キューがあふれる。すると技術システムが動いていても、人間側の処理能力が尽きます。
Human Factorsはどこに入るか
疲労、注意資源の枯渇、アラート慣れ、時間圧力です。
急いでいる人は、十分に検討せず、最初のもっともらしい答えを採用しやすくなります。RAG利用者を直接対象にした研究ではありませんが、時間、情報、認知資源が限られる状況では、人が認知的負担の小さい手掛かりへ依存し、その過程に認知バイアスが入り得ることが、緊急時の意思決定研究でも示されています [10]。AIの確認作業が過剰になれば、「人をループに入れた」ことが、かえって安全性の錯覚になります。
必要なサイバー判断力と設計
- 技術的な負荷と、人間の確認負荷を別々に監視する
- 高リスク案件を優先し、低リスク承認を自動化・統合する
- 確認者が処理できない量になったら、安全側へ縮退する
- 疲労時に重要判断を一人へ集中させない
- 障害時にも使える代替手順を用意し、実際に演習する
DoSの保護対象には、GPUやAPIだけでなく、人の注意と判断時間も含めるべきです。
E：Elevation of Privilege――「閲覧のためのAI」が実行者になる
具体的な脅威
RAGチャットボットに、メール送信、チケット更新、文書変更、アカウント操作などのツールを追加したとします。悪意ある文書に埋め込まれた指示をモデルが読み、利用者の権限で外部送信や設定変更を提案、あるいは実行する。
ただし、利用者がもともと持つ権限の範囲内でAIが危険な操作を行う場合、厳密にはすべてが権限昇格とは限りません。過剰なエージェンシー、権限悪用、confused deputyとして捉える方が適切な場合もあります。本稿では、AIが本来の閲覧用途を越えて実行能力を得る場合、または人間の権限を代理利用して実質的に権限範囲を広げる場合を、Eとして扱います。
OWASPはExcessive Agencyの対策として、機能・権限・自律性を必要最小限にし、高影響操作に人の承認を設けることを挙げています [11]。しかし、承認ボタンがあるだけでは十分ではありません。
Human Factorsはどこに入るか
AIが「処理を完了するにはアクセス許可が必要です」と自然に説明すれば、人は作業を前へ進めるために承認しやすくなります。同じ確認が続けば、承認は判断ではなく反射になります。自動化への依存は、状況認識や、異常時に手動で引き継ぐ能力を弱める可能性もあります [12], [13]。
ここで危険なのは、人がループにいないことだけではありません。人がいても、止める材料、時間、権限がないことです。
必要なサイバー判断力と設計
- AIの提案と、実際に実行される操作を分けて理解する
- 誰の資格情報で、何が、どこへ、どの範囲で行われるか確認する
- 高影響操作は、目的・対象・差分・取消し方法を見せてから承認する
- 一括承認や曖昧な「続行」を避け、操作ごとに明示的に同意させる
- 読取り専用を初期値にし、短時間・限定範囲の権限だけを付与する
- 停止、取消し、ロールバックを承認画面と同じくらい見つけやすくする
Human-in-the-loopでは足りません。必要なのは、challenge, refusal, and recovery―疑い、拒否し、回復できるループです。
一つの攻撃を、SからEまでつないでみる
実際の事故は、一つのカテゴリーだけで完結しません。
例えば、攻撃者が人事部の文書に似せたファイルを登録する（S：なりすまし）。その中に、AIへ別の指示を与える文章を混ぜる（T：改ざん）。RAGがその文書を取得し、権限外の社員情報を回答へ含める（I：情報漏えい）。AIは「人事部承認済み」と説明し、担当者は繁忙時に出典を開かず信じる。さらにチャットボットがメール送信権限を持っており、担当者が表示された確認をそのまま押す（E：権限昇格）。後から調べても、取得チャンクと承認時の画面が残っていない（R：否認）。同時に大量の偽文書が投入され、確認担当者のキューがあふれる（D：サービス拒否）。
この連鎖の中で、Human Factorsは最後に一度だけ現れるのではありません。
- 正規文書らしい見た目を信じる
- 自分の期待に合う回答を受け入れる
- 出典確認の負担が高く、検証を省く
- AI、人、管理者の責任境界が曖昧になる
- 警告と承認の多さで疲労する
- 作業を止めることが評価されない
これらが攻撃を増幅します。
一方で、真正性の違和感に気づく、別資料と照合する、承認を保留する、権限を切る、汚染された版へ戻す、早く共有する。これらもHuman Factorsです。
人は、攻撃経路でもあり、検知器でもあり、回復力でもあります。
実務で使うための脅威記述テンプレート
STRIDEとHuman Factorsを別々のチェックリストにしないために、私は一つの脅威を次の形で書くのがよいと思います。
［レイヤー／信頼境界］に［技術的条件］があるため、［脅威主体］は［STRIDE上の行為］を行い、［資産・業務］へ［影響］を与えられる。この脅威は、［認知バイアス、負荷、権限、組織条件］によって増幅される。［役割］が［必要な情報］を得て、［確認・拒否・停止・回復］できれば、連鎖を断てる。
例えば、こうです。
文書登録からベクトルDBへの信頼境界で、発行者確認と二者承認がないため、侵害された編集者アカウントは人事規程になりすました文書を登録できる。検索結果が発行者を目立たせず、利用者がAIの説明を権威あるものとして受け入れると、誤った雇用判断へ進む。利用者が文書の所有者、版、承認状態を回答画面で確認し、保留・報告できれば連鎖を断てる。
この書き方なら、技術的な弱点、人間の成功条件、被害、止める力が、一つのシナリオの中に入ります。
対策も、技術・判断・組織の三つを一緒に置く
RAGの対策は、入力フィルターだけでは足りません。
技術
- 検索前の認証・認可と文書単位のアクセス制御
- 文書の署名、来歴、版、承認状態の管理
- 外部コンテンツの分離と間接プロンプトインジェクション対策
- モデル、検索、ツールの最小権限化
- 取得文書、モデル出力、実行操作を結ぶ監査ログ
- レート制限、異常検知、安全なロールバック
人の判断を支える設計
- 引用元を開かなくても、発行者、版、日付、承認状態が分かる
- AIの確信表現ではなく、根拠の強さと不一致を見せる
- 高影響判断では反証資料や代替案も提示する
- 承認前に、対象、差分、権限、取消し方法を明示する
- 保留、拒否、報告、停止を正規の操作として用意する
組織
- 文書所有者、RAG管理者、業務判断者、事故対応者の責任を分ける
- 速さだけでなく、適切な差戻しや異常報告を評価する
- 承認件数と疲労を測り、処理能力を超えたら運用を変える
- AIなしで判断する訓練と、汚染・漏えい・誤実行からの回復演習を行う
- 問題を止めた人が不利益を受けない文化を作る
NIST AI RMFはAIを社会技術的なシステムとして捉え、人間とAIの役割、責任、監督のあり方をリスク管理に含めています [14]。NIST IR 8579も、RAGベースの内部向けチャットボットについて、モデル単体ではなく、検索、データ処理、アプリケーション構成、アクセス、運用を含む実装上・セキュリティ上の論点を扱っています [15]。
最後に―守るべきなのは、正しい回答だけではない
RAGチャットボットの脅威モデルを作ると、私たちはつい、どの入力を遮断するか、どのデータを暗号化するか、どの権限を削るかを考えます。
もちろん、それは必要です。
でも、人がその回答をどう受け取り、何を根拠に信じ、どこで立ち止まり、誰に異議を言え、間違ったあとにどう戻れるかを描かなければ、実際の事故経路は半分しか見えていません。
STRIDEは、攻撃の種類を見つけるために強い。
RAGのデータフローは、攻撃がどこを通るかを見せてくれる。
Human Factorsは、その攻撃がなぜ通り、なぜ見過ごされ、あるいはどこで止まるのかを見せてくれる。
そしてサイバー判断力は、「最後は人が確認する」という曖昧な言葉を、気づく、意味づける、先を読む、選ぶ、回復する、という具体的な能力へ変えてくれます。
人を最後の砦にするのではなく、人が砦として機能できる条件を設計する。
私は、そこまで入って初めて、RAGの脅威モデルが現実の仕事に近づくのだと思います。
参考文献
[1] P. Lewis et al., "Retrieval-augmented generation for knowledge-intensive NLP tasks," in Advances in Neural Information Processing Systems 33 (NeurIPS 2020), 2020, pp. 9459-9474. [Online]. Available: [https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html](https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html). Accessed: Sep. 9, 2026.
[2] T. N. R. Cyrille and F. Schwarz, "STRIDE-AI: A threat modeling framework for generative AI security assessment," arXiv:2605.17163, 2026, doi: [10.48550/arXiv.2605.17163](https://doi.org/10.48550/arXiv.2605.17163).
[3] H. Hibshi, T. D. Breaux, M. Riaz, and L. Williams, "A grounded analysis of experts' decision-making during security assessments," Journal of Cybersecurity, vol. 2, no. 2, pp. 147-163, Dec. 2016, doi: [10.1093/cybsec/tyw010](https://doi.org/10.1093/cybsec/tyw010).
[4] National Institute of Standards and Technology, "Human-Centered Cybersecurity," NIST Computer Security Resource Center. [Online]. Available: [https://csrc.nist.gov/projects/human-centered-cybersecurity/about](https://csrc.nist.gov/projects/human-centered-cybersecurity/about). Accessed: Sep. 9, 2026.
[5] K. Greshake et al., "Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection," in Proc. 16th ACM Workshop on Artificial Intelligence and Security (AISec '23), Copenhagen, Denmark, 2023, pp. 79-90, doi: [10.1145/3605764.3623985](https://doi.org/10.1145/3605764.3623985).
[6] OWASP GenAI Security Project, "LLM01:2025 Prompt Injection," OWASP Top 10 for Large Language Model Applications. [Online]. Available: [https://genai.owasp.org/llmrisk/llm01-prompt-injection/](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). Accessed: Sep. 9, 2026.
[7] OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026, "ASI09: Human-Agent Trust Exploitation," pp. 33-35, 2026. [Online]. Available: [https://genai.owasp.org/download/52117/](https://genai.owasp.org/download/52117/). Accessed: Sep. 9, 2026.
[8] OWASP GenAI Security Project, "LLM08:2025 Vector and Embedding Weaknesses," OWASP Top 10 for Large Language Model Applications. [Online]. Available: [https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/). Accessed: Sep. 9, 2026.
[9] G. De Stefano, L. Schönherr, and G. Pellegrino, "Rag and roll: An end-to-end evaluation of indirect prompt manipulations in LLM-based application frameworks," arXiv:2408.05025, 2024, doi: [10.48550/arXiv.2408.05025](https://doi.org/10.48550/arXiv.2408.05025).
[10] M. Kinsey, S. Gwynne, E. D. Kuligowski, and M. Kinateder, "Cognitive biases within decision making during fire evacuations," Fire Technology, vol. 55, pp. 465-485, 2019, doi: [10.1007/s10694-018-0708-0](https://doi.org/10.1007/s10694-018-0708-0).
[11] OWASP GenAI Security Project, "LLM06:2025 Excessive Agency," OWASP Top 10 for Large Language Model Applications. [Online]. Available: [https://genai.owasp.org/llmrisk/llm062025-excessive-agency/](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/). Accessed: Sep. 9, 2026.
[12] K. Goddard, A. Roudsari, and J. C. Wyatt, "Automation bias: A systematic review of frequency, effect mediators, and mitigators," Journal of the American Medical Informatics Association, vol. 19, no. 1, pp. 121-127, Jan.-Feb. 2012, doi: [10.1136/amiajnl-2011-000089](https://doi.org/10.1136/amiajnl-2011-000089).
[13] M. R. Endsley and E. O. Kiris, "The out-of-the-loop performance problem and level of control in automation," Human Factors, vol. 37, no. 2, pp. 381-394, Jun. 1995, doi: [10.1518/001872095779064555](https://doi.org/10.1518/001872095779064555).
[14] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, Gaithersburg, MD, USA, Jan. 2023, doi: [10.6028/NIST.AI.100-1](https://doi.org/10.6028/NIST.AI.100-1).
[15] H. Booth et al., Developing the NCCoE Chatbot: Technical and Security Learnings from the Initial Implementation, NIST IR 8579 ipd, National Institute of Standards and Technology, Jul. 2025, doi: [10.6028/NIST.IR.8579.ipd](https://doi.org/10.6028/NIST.IR.8579.ipd).
[16] L. S. Ferro, A. Marrella, and T. Catarci, "A human factor approach to threat modeling," in HCI for Cybersecurity, Privacy and Trust, Lecture Notes in Computer Science, vol. 12788, Cham, Switzerland: Springer, 2021, pp. 139-157, doi: [10.1007/978-3-030-77392-2_10](https://doi.org/10.1007/978-3-030-77392-2_10).
[17] L. Mauri and E. Damiani, "Modeling threats to AI-ML systems using STRIDE," Sensors, vol. 22, no. 17, Art. no. 6662, Sep. 2022, doi: [10.3390/s22176662](https://doi.org/10.3390/s22176662).