今回のHelp Net Securityインタビューでは、TricentisのCISOであるErika Dean氏が、テスト環境から本番データを排除する取り組みと、代替手段がすでに十分な水準に達していると考える理由について語ります。同氏はまた、レッドチーム演習でプロンプトインジェクションの穴を発見し、修正が完了するまで1週間リリースを保留した経緯についても説明しています。
Dean氏は、AIベンダーを不採用とする決め手について、データの保存場所や保持期間に関する回答が曖昧な場合が多いと語ります。さらに、人員が限られる小規模なセキュリティチームがまず着手すべき3つの取り組みについても挙げています。
エンタープライズセキュリティ、コンプライアンス、プロダクトセキュリティの3領域を統括されていますが、個人として最も時間を割いていないのはどれですか。そして、それがおそらく誤った配分である理由は何でしょうか
正直に言うと、私が個人としてハンズオンで最も時間を割いていないのはガバナンスとコンプライアンスの領域です。ただ、現在の脅威情勢を踏まえると、それが誤った配分だとは考えていません。
コンプライアンスは今も、そしてこれからも当社のセキュリティプログラムの根幹をなす要素です。特にTricentisは顧客向けサービスを提供する企業であり、顧客側にも独自のコンプライアンス義務があるためです。変わったのはその運用方法で、証跡収集や監査に自動化を取り入れ、プログラムにセルフサービス的な要素を強く組み込むことで、重要性を損なうことなく日々の負担を軽減しています。
これにより、私はエンタープライズセキュリティとプロダクトセキュリティに、より多くの時間を割けるようになりました。この領域では、私のチームがTricentisと顧客を守るための技術的な統制を導入・運用しています。脅威アクターがAIを活用して脆弱性をより速く突き、新たな攻撃手法を展開する中、今もっともレバレッジの効く時間の使い方はここにあると考えています。
テスト環境は、本番環境と同等の統制を欠いたまま本番データのコピーを保持していることで悪名高い領域です。社内ではこの問題にどう対応していますか。また、それをうまく扱えていない顧客を見かけた場合、どのようなアドバイスをしますか
社内でも、顧客に推奨しているのと同じ要件を課しています。つまり、下位の環境で本番データを使わないということです。これまでのキャリアを振り返ると、QA環境や非本番環境で本番データを活用している企業を複数見てきました。例えば、小切手画像の検証や社会保障番号(SSN)の検証プロセスなどの負荷テストは、非常に高い精度と独特な特性が求められるため、歴史的に難しいとされ、企業はデフォルトで本番データを使う傾向にありました。金融サービスや医療といった機密性の高い業界でさえ、本番データを使用しているケースがあります。
QA環境内の統制は、本番環境ほど強固でないことが少なくないため、そのセグメンテーションを確実に維持することが重要です。そのため、私は本番データをQA環境やテスト環境からできる限り排除し、代わりの方法でテストを行うことを常に推奨しています。技術は大きく進歩しており、こうした課題を解決する別の手段はほぼ必ず存在します。
現在、どのベンダーのエージェントに関する売り込みも似たり寄ったりに聞こえます。あなたのチームが差し止めた、あるいは延期したAI機能と、その背景にある具体的な技術的懸念について教えてください
これまでのキャリアの中で、延期や方向転換を余儀なくされたAI製品や機能は確かにありました。特にAI黎明期、各社がエージェント機能の実装に躍起になっていた頃は顕著でした。特定の製品名は明かせませんが、パターンとしてはこう説明できます。各社がエージェント機能を通じてチャットボットをより人間らしく魅力的にしようと躍起になる中、私のチームはプロンプトインジェクションのリスクを指摘しました。攻撃者がシステムが本来公開すべきでない機密情報を引き出すよう巧妙に設計した入力を送り込む、といった手口です。
ローンチ前にレッドチーム演習を実施したところ、まさにそのギャップが見つかり、バックエンド側で問題が解消されるまでリリースを保留しました。スケジュールには1週間の遅れが生じましたが、その代償として避けられたのはデータ漏えいでした。したがって、すべてのセキュリティテストが完了し、実装前にバグが解消されるまでローンチを延期することは、エージェント型AIの初期段階と同様、今日でも必要な措置です。私の基本姿勢は、エンジニアリングやプロダクト開発のスピードを損なわないよう後押ししつつも、セキュリティを犠牲にはしないというものです。
自社のスタックに組み込むモデルプロバイダーやAIベンダーをどのように評価していますか。実際に不採用とした事例と、その決め手となった要因を教えてください
モデルプロバイダーやAIベンダーについては、まずセキュリティの観点から評価し、社内利用や自社製品への組み込みに安心して踏み切れるかどうかを判断します。主に評価するポイントは、データがどのように利用・保存されているか、どのようなセキュリティ統制を導入しているか、データ保持期間はどうなっているか、そしてベンダー自体の耐障害性です。
また、アーキテクチャや、それが自社のエコシステム内でどのように実装されるか、さらにはユーザーにその技術をどう利用してほしいかという観点も検討します。ほとんどの企業が何らかの形でAIを取り入れており、それらすべてを社内での利用を許可する前に当社の基準に照らして評価する必要があります。優れたAIベンダーは、エンタープライズ側がLLMの利用方法を設定でき、企業の観点からエージェントの動作を制限できるようになっています。例えばコーディングアシスタントを導入する場合、当社は自社スタック上での展開を目指し、エンタープライズ統制を活用して、プロンプトがAIベンダー側で実行される前に必ず当社のセキュリティチェックを通過するようにしています。
不採用とした具体的なベンダー名は明かせませんが、何が不採用の決め手になるかはお話しできます。最もよくある危険信号は、データの保存場所、保持期間、そして自社モデルの学習に使用されるかどうかについて明確に答えられないベンダーです。データの所在地や保持期間について明確な回答が得られない場合、製品自体がどれほど優れていても、それだけで即座に取引を打ち切ります。2つ目はアーキテクチャです。直接プロバイダーとやり取りしているのか、それとも他社のモデルをラップして提供しているベンダーなのかという点で、これによって実際に誰が自社のデータを管理しているのか、そして自社が何をコントロールできるのかが変わってきます。ベンダーがそのチェーンを説明できない、あるいは説明しようとしない場合、私たちはその話を打ち切ります。
あなたよりもはるかに少ない人員しか持たない、小規模なソフトウェアベンダーのセキュリティリーダーに対して、最初に取り組むべき3つのことを挙げるとすれば何でしょうか
セキュリティ組織が極めて小規模であっても、まず取り組むべき3つのことをお伝えします。1つ目は、脆弱性管理プログラムを立ち上げることです。企業にはセキュリティ上の脆弱性をスキャンし、特定できる体制が必要です。
2つ目は、モニタリング体制を整えるか、それを代行してくれる企業を雇うことです。アラート、あるいは誰かが不正な行為をしていないかを把握する手段がなければ、データや会社が侵害されるまで問題に気づくことはできません。AIは特に、少人数のチームがアラートのトリアージや新たなアラートの構築を行う際に威力を発揮し、数年前には持ち得なかったレバレッジを与えてくれます。
3つ目は、コーポレートセキュリティに重点を置き、少なくとも暗号化、アンチウイルス/マルウェア検知、パッチ適用、データ損失の監視といった基本的なエンドポイント統制を備えることです。小規模企業であっても、自社と顧客を守るための基本的な対策は欠かせません。正しく活用すれば、AIは大規模チームと小規模チームの間にあるギャップを埋める助けとなります。
翻訳元: https://www.helpnetsecurity.com/2026/08/26/erika-dean-tricentis-production-data-in-testing/
