0:00:02 エミリー・ウェアマウス: Frontier AI モデルがもたらす可能性のあるリスクについて多くの議論がなされてきましたが、今日のゲストは別の視点を提供してくれます。彼はセキュリティチームの中のレッドチーム員で、使うフロンティアモデルを効果的に活用しています。 それでは、セキュリティ・ビジョナリーズ・ポッドキャストへようこそ、モヒト・クラムコリーさん。モヒットはNetskopeセキュリティチームのレッドチームのシニアエンジニアで、モヒットさん、参加できて嬉しいです。
0:00:26 モヒト・クラムコリー：ありがとうございます。お招きいただきありがとうございます。ええ、ポッドキャストに出演できて嬉しいです。はい。
0:00:31 エミリー・ウェアマウス:あなたはいくつかのブログ記事を書かれており、その記事で話されていた内容は、あなたとあなたの広範なチームがレッドチームの取り組みの中でこれらのモデルを使うとしている研究だったので、私が連絡を取るきっかけとなりました。それらについて少しお話ししたいのですが、いくつか異なる、いわば実験があります。彼らがあまりにも小さく聞こえないといいのですが。使うといういくつかの異なる実験やモデルがあり、私は多くの質問をして、これまでに得た詳細や発見を明らかにしたいと思っています。 フロンティアAIモデルへのアクセスを得て以来、そしてNetskopeは今年6月に「Glasswing」に参加したと聞いていますが、あなたのチームは非常に有益な実験を行っています。もし私の理解が正しければ、あなたはNetskope自身のセキュリティ製品の前にフロンティアモデルを導入し、深刻なセキュリティバグ、特にメモリ破損のバグを見つけられるかどうかを調べているのですね。
0:01:26 エミリー・ウェアマウス: 今、リスナーの皆さんは非常に幅広い教会から来ています。ですので、モヒットさん、脆弱性研究に直接触れたことがないリスナーのために説明してもらえますか?メモリ破損バグとは何か、そしてなぜセキュリティ欠陥のカテゴリーの中でも特に危険で見つけにくいと考えられるのでしょうか?
0:01:45 モヒト・クラムコリー:はい、もちろん、もちろんです。うん、まさにその通りだ。では、あなたが正しく指摘したように、メモリ破損が自らバグるものから始めましょう。 つまり、メモリ破損バグは、ソフトウェアが自身に割り当てられたメモリ空間を誤った方法で処理した場合に発生する。つまり、これはオペレーティングシステムによって管理されますが、割り当てと決定はソフトウェア自体によって行われます。そのため、このような事態が発生すると、OS内で複数の他の影響を引き起こす可能性のある脆弱性が生じ、これは想定外の動作となります。では、なぜ危険なのでしょうか？なぜなら、それをよりよく理解することがなぜ危険なのか、少し立ち戻って考えてみる必要があるからです。つまり、オペレーティングシステムは大きく2つの部分に分けられる。つまり、一方はユーザーモード、もう一方はカーネルモードになるということです。つまり、ユーザーモードはすべてのプログラム、つまり私たちのプログラム
動作
場所であり、カーネルモードはオペレーティングシステムに関連するものです。0:02:44 Mohit Kulamkolly:そして、ユーザーモードは、特定のアクションなどを実行するために、カーネルから必要なものを何度も必要とします。つまり、ここから攻撃対象領域が始まるのです。つまり、プログラムがユーザーモード内でクラッシュした場合、そのプログラムはユーザーモード内に留まることになります。そしてカーネルに何かを要求し始めると、攻撃者はそれを見たり、使うしたりもできます。 そうして、その経路を通じてオペレーティングシステム内のシステムをクラッシュさせることも可能になり、それがさらなる脆弱性につながるのです。そのため
他の脆弱性と比べ
非常に危険なのです。0:03:15 エミリー・ウェアマウス: そして、これらのAIモデルをメモリ破損のバグに向けることで、何を突き止めようとしていたのですか?
0:03:22 モヒト・クラムコリー:つまり、Netskopeはクライアントのオペレーティングシステムのシステム内、エンティティ内で動作します。そしてそこから、脆弱性が引き起こされた場合、それはメモリ破損の脆弱性となります。先ほども申し上げたように、システムのダウンタイムや権限昇格の脆弱性など、様々な問題を引き起こす可能性があります。ここでの目的は、 Netskope Client 内の脆弱性がOSに影響を与えるものにエスカレーションできるかどうかを調べることでした。 つまり、私たちはプログラムから抜け出し、単なる Netskope Client の墜落よりもはるかに壊滅的な視点に向かっているのです。 そう、それ
目標だった
です。0:04:03 エミリー・ウェアマウス: そして、AIツールの使い方について見る前に、Frontier AIがなかった頃は、通常どのようにして脆弱性を探しますか?
0:04:13 モヒト・クラムコリー:攻撃対象が何かを突き止めようとする前に、つまり、ユーザーモードからカーネルモードへの通信を行うためのAPIが存在するということです。まずは、どんなAPIがあるのか、プログラムがどのように書かれているのかをブラックボックスの視点から試す必要があります。 ブラックボックスと言っても、ソースコードなどは一切ありません。だから、その時から始めるんだ。 そこから、送信したペイロードやデータがシステム内や特定のオペレーティングシステム内でクラッシュを引き起こすかどうかを試す。 そして、この障害の原因となっているペイロードや命令を特定するために、何度も何度も試行錯誤を繰り返します。だからこそ、私たちは自分たちでファザーを開発しようと試すのです。 それが今私たちが詳細に説明したことです。そこで、これらの脆弱性
特定する
に役立つファザーを開発しました。0:05:10 モヒト・クラムコリー: しかし、AIがこの状況に関わることで、この分野に踏み込むにははるかに多くの専門知識が必要になる、まったく新しいレベルのテストにエスカレートしました。 そして
AIの登場によって、それをさらに発展させることができるの
。0:05:29 エミリー・ウェアマウス：それでは、あなたのブログ記事から引用させていただきます。最初の段階で、使う OpenAI 5.5 を担当したという点で、私の理解は合っていますか?
0:05:38 モヒト・クラムコリー:サイバーモデル。
0:05:39 エミリー・ウェアマウス:あなたは、AIに「バグを見つけて」と尋ねて、その答えを信じるだけではダメだ、というのがあなたの出発点だったと言いました。実際の人間のバグハンターが使うのと同じ道具を与え、その主張はすべて実際の稼働システムと照らし合わせて検証しなければなりません。それでは、それらの点を順番に見ていきましょう。まず、なぜ危険なのでしょうか？私たちはこのことを知っているかもしれない。脆弱性を発見したというモデルの言葉を鵜呑みにすることが、なぜ危険なのか、具体的に教えてください。その検証フェーズをスキップすると、どのような問題が発生する可能性がありますか？
0:06:09 Mohit Kulamkolly:ええ、もちろんです。だから、もっと深く掘り下げる前に、しばらく先にこの発言に反論するかもしれない。なぜなら、それが新しい実験でMythosが教えてくれたことだからだ。これらのサイバーモデル、OpenAI 5.5、あるいはサイバーモデルでは、膨大な量のデータ、すべてのセキュリティ脆弱性や発見に基づいて訓練されています。つまり、情報ではなく推測に基づいて判断しなければならない状況では、幻覚を見ることが可能になるのだ。つまり、モデルに脆弱性を見つけるように指示するだけでは、モデルが知っているのは脆弱性のことだけになってしまうのです。したがって、それは最初に立てた仮定に基づいて結論を出さなければならない。つまり、ある意味では良いことであり、それは後ほど明らかになった。最初に論文を書き出す際には、調査結果についてできる限り確実な結論を導き出す必要がある。そこで私たちは、よし、今知っていることをもとに始めようと決めました。
0:07:11 モヒト・クラムコリー: 試す を詳しく説明し、その後、私たちが知らないこととモデルができることについての章に入ります。
0:07:17 エミリー・ウェアマウス:わかりました。それでは、実際にここで構築したものを詳しく説明してください。このようなセットアップのラボは実際にはどのようなものですか?
0:07:24 Mohit Kulamkolly:ええ、具体的な詳細には触れずに、非常に大まかに言うと、脆弱性研究者に必要なツールを提供するということです。つまり、特定の動作を実行するためには、それが必要だということです。つまり、ソフトウェアが動作する仮想ミッションが存在するということです。これらのツールが稼働する仮想ミッションが存在する。そこで、それら全てを繋ぎ合わせ、点と点を繋ぎ合わせて、モデルにこの情報を与え、そして、私が過去の脆弱性探索の経験に基づいて検討する非常に具体的な方法で脆弱性を探すように指示しました。こうして私たちはこのゲームを始めるのです。 これが、ラボの概略図です。
0:08:12 エミリー・ウェアマウス：これから少し難しい質問をさせていただきます。ここ1、2週間で、エージェントやAIがサンドボックスから抜け出し、与えられた任務に答えるかもしれない行動を取るという話が多くありましたが、私たちが快適に感じる形ではありませんでした。これらの実験が試す、脱出するかもしれないと予想して、何か特別なガードレールを設けていますか? そうならないようにするにはどうすればいいですか？
0:08:36 Mohit Kulamkolly:ええ、それはとても良い質問です。特にこの文脈では、エージェントに特定のタスクを実行するように指示する場合、非常に具体的な方法で実行するようにとは言いません。それが私が最初にやったことであり、それがエージェントの制限要因になるかもしれないと理解したのです。そこでそれを突破するために、私たちは個別のサンドボックス環境を作りました。つまり、すべてのバーチャルミッションにはサンドボックス環境があり、それを壊したりアクセスしたりすることは、私たちが明示的に許可しなければアクセスできません。特にWindowsマシンなどのテストケースでは、Dockerコンテナなどのコンセプトを使う代わりに、仮想ミッションが最も効果的です。 これが、私たちが個々のツールに対して構築した隔離レベルと、ツールがそれに対して持つアクセス方法の種類です。そして、私たちは適切なインターネットアクセスがない別のシステムとミッションで
これらのテスト
すべて実施しています。0:09:34 エミリー・ウェアマウス:インターネットから隔離することが、暴走する能力を制限するための重要なことの一つだと思います。あなたが書いた記事の中で、このシステムはクラッシュを意図的に許容するターゲットマシンと、デバッガーでそれを監視する別のマシンを中心に構築したと述べていましたね。なぜそれらを別々に保持したのですか。また、クラッシュする前に停止するのではなく、実際にクラッシュさせることがなぜ有用なのですか。
0:09:58 Mohit Kulamkolly:ええ、それがこのメモリ破損の脆弱性の概念全体であり、これが興味深い理由です。つまり、プログラムがメモリを誤って扱っていることを探すと、フェイルセーフ段階に進むのです。 つまり、それがクラッシュステージで起こることなのです。つまり、個々のバグをテストしようとしている場合、個々のペイロードを微視的なレベルでテストしようとしている場合、バグが存在することを最初に確認する最良の方法は、クラッシュするかどうかを確認することです。そして、もし異常なクラッシュが発生した場合は、メモリの取り扱いに何らかの問題があることを意味します。その後、どのように事態をエスカレートさせるか、どのようなシステム運用を回避する必要があるかなどについて話し合うことができます。つまり、これらの問題は後の段階で出てくるのです。しかし、あなたが言及した興味深い点に付け加えると、クラッシュする直前に一時停止してみてはどうでしょうか？
0:10:53 モヒト・クラムコリー:そういうシステムもあるんですね。ですから、それも社内で行っています。これは、クラッシュ直前に試すように拾い上げ、何百万回も再生して新しい脆弱性のバリエーションを見つけるためのスナップショットファジングインフラです。
、それが全体
背景です。0:11:12 エミリー・ウェアマウス：この実験の段階について、もう一つ質問があります。私はさらに質問する権利を留保しますが、今のところは1つ質問できたと思っています。どうやら、このモデルの初期におけるバグに関する仮説の多くは間違っていたようだ。それはソフトウェアに対する時代遅れの前提だと。 そして、なぜあなたはそれが起こっていると判断したのか、疑問に思いました。そして、もし何かあったとすれば、モデルは間違いを犯し、その間違いの段階を経たことから何を学んだと思いますか？
0:11:43 Mohit Kulamkolly:ええ、こういうソフトウェアの場合、テストが難しいのは、それが展開される環境に大きく依存するからです。例えば、オペレーティングシステムに小さな調整が加えられると、例えば機能があったり、バックグランドで動作すべきプログラムが動作しなかったりすると、ソフトウェアは本来の動作をしなくなります。 つまり、システムが脆弱性のある環境に適応する必要があるだけでなく、同時に、そこから得られる結果に基づいて次のステップを判断する必要がある理由の一つはこれです。つまり、単に「よし、これが標準的な手順だ、それで進め」というだけではないのです。ですから、システムがそれを受け入れているか、ソフトウェアがその標準的な運用手順を受け入れ、ペイロードを投入する前に動作を起こす必要があります。
0:12:39 Mohit Kulamkolly:なぜなら、ここにAIを導入しないと、大量のペイロードを送信しても、AIやソフトウェアが応答しないからです。では、どうすればテストできますか？それが、モデルがそのような修正を行った理由です。ええ。
0:12:54 エミリー・ウェアマウス:そうですね。ここまでお話ししてきたのは、第一段階のことでした。つまり、人間であるあなたがすべての手順を設計し、その後、AIはあなたが設計したプロセス内でタスクを実行するように指示されたということですね。今、あなたの第二段階に進みたい。 今、第二フェーズではモデルを変えて、代わりにクロード・ミュソスでプレイし始めました。 変更する理由があったのでしょうか、それとも元々は両方の方法で実験を行う予定だったのでしょうか？あるいは、別のモデルに移行することで得られるメリットがあったのでしょうか？
0:13:30 Mohit Kulamkolly:特にありません。新しい高級ツールと新しいアナログが手に入っただけです。
0:13:34 エミリー・ウェアマウス:誰しもそういう経験ありますよね。わかった。そして今回の2つ目では、何が違っていたのか試すとスケッチしていきます。そうすれば、もう少し詳しく説明してもらえると思います。 つまり、あなたがすべての手順を設計してからモデルに実行を指示するのではなく、モデルに何を調査するかを決定させたのです。次に、発見したバグを実際のシステムで検証するように要求しました。そして、この件に関して非常に重要な要素と思われるのは、その証明に対して、独立した別のコピーを作成し、二重チェックを行う必要があったことです。つまり、処理工程の多くをシステムに任せることになる一方で、作業負荷から人間の手をより多く排除するため、システムが行うべきチェック項目も増えることになるのです。OpenAI実験の締めくくりから、なぜこのような設計に至ったのか教えていただけますか?
0:14:30 モヒト・クラムコリー:私たちはMythosでテストを始めるときにOpenAIから学びました。つまり、内部には、あらゆるセキュリティ機能やあらゆるモデルが搭載されているということです。つまり、それらはすべて基本的に予測システムなのです。新しいソフトウェアを開発したと言っても、彼らは与えられた文脈に基づいて非常に効率的に次に何が来るかを予測しているだけです。つまり、文脈を制限すればするほど、あるいは文脈を制約すればするほど、そこから生み出される情報の種類も減少していくことになる。そこで、OpenAIとテストを行った際に、ファジングツールを作成しました。私たちは、その上にさらに構築するように依頼しました。今度は、ファザーを付けたからこそ、そこから唯一作れたものがその延長線上にあるのかを確かめたかったのです。
0:15:21 Mohit Kulamkolly:そこで、ファザーを取り除いて、ファザーの構築方法と、それを自分で構築する方法を教えました。ご自身で操作していただいても構いませんし、プログラムのこの特定のインターフェースにアクセスするために、ご自身が適切だと思う方法で操作していただいても構いません。だから、私たちはその方法で試してみたかったのです。だから、それを囲むようにガードレールを設置する代わりに。結果的にとてもうまくいった。こうして私たちは、モデルがどのように動作するのか、そして脆弱性を発見するためにどのような独創的な方法が用いられたのかを理解しました。それ
問題
核心です。0:15:57 エミリー・ウェアマウス：今回はより多くの権限を委譲することになったため、何か特別な配慮が必要でしたか？物事を構成するさまざまな方法や、設ける必要があると感じた追加のガードレールはありましたか?
0:16:10 Mohit Kulamkolly:ええ、より多くの隔離です。より隔離された環境が、その成功の鍵だったと思う。そのモデルは、当社のシステムには対応していません。そこで、このテスト専用のノートパソコンを別途用意しました。そこは電力網から切り離された場所だった。そして、今回は全力で取り組んだんです。そのため、システムにあるツールを使うように求めるのではなく、ますます隔離されるようにしました。
以上です。0:16:35 エミリー・ウェアマウス:わかりました。そして、その生成結果を二重チェックする仕組みを組み込むことで、モデルが導き出す結論に対する追加の安全策にもなると思います。
0:16:47 モヒト・クラムコリー:はい、はい。はい。
0:16:49 エミリー・ウェアマウス:それが正しいと確信してしまうのをどうやって防いだのですか？どうやってその二重チェックを、それができないほど十分に分離したのですか。つまり、先週私たちが目にしたことの一つは、あるエージェントが社内で承認を得るために、文字通り従業員のディープフェイク動画を作成するという手段にまで及んだということだ。つまり、AIは人を説得する方法を知っているということだ。それが単に自分自身やこの二次チェックによって、行っていることが正しいと確信しているだけではないことを、どのように確認しましたか？
0:17:21 Mohit Kulamkolly:ええ。これに関して最も重要な点は、以前にも議論したとおり、モデルが予測システムであり、コンテキストが重要な要素となるということです。ここでも同じ概念、つまり文脈について触れたいと思います。つまり、モデルが何か間違ったことをする場合、ほぼ常に、100%の確率で、適切なコンテキストがないか、あるいは不適切なコンテキストを持っていることが原因だと言えるでしょう。つまり、2つの異なるシステムが存在する理由は同じなのです。つまり、モデルが新しい作品を見るとき、それは単に単純な文脈から窓へと見ていることを意味します。このようにすれば、以前に生じた誤った前提を一切踏襲しないことになる。ですから、あなたが言及したケースも同様で、結局はモデルが何を達成する必要があるかに帰着します。 つまり、あるエージェントの目標は
別のエージェントの目標
は限らないということです。0:18:16 エミリー・ウェアマウス：
、面白いわ
。0:18:18 モヒト・クラムコリー:そして、あなたがおっしゃったことに基づくと、当初の目的はその特定の従業員のディープフェイクを作成することではなく、この承認システムを回避することだったのかもしれません。つまり、それはできる限りのあらゆる不正行為を行うが、モデルは自身のコンテキストからは何も有害なことをしていないが、外部のコンテキストからは有害なことをしている。つまり、文脈こそが重要だ。ええ。
0:18:40 エミリー・ウェアマウス:つまり、2 つのステージの間に摩擦を少し組み込んだということですね。つまり、自分の作業をチェックしていない場合は、別の AI エージェントが作業をチェックして、両者が協力しないようにし、2 つの間に一定の区別を保つということですね。それは本当に興味深い設計上
ポイントです
。0:18:58 モヒト・クラムコリー:まさにその通りです。ええ。
0:19:00 エミリー・ウェアマウス:では、この調査で何がわかったのか教えてください。それはどのように機能したのですか？結果はどうでしたか？
0:19:08 Mohit Kulamkolly:ええ、最初に行ったこの2つの実験から多くの良い結果が得られました。つまり、オープンソースソフトウェアだけでも、約17～18個の脆弱性を発見できたということです。これらのソフトウェアはNetskopeが製品開発に使うものです。しかし、これらの脆弱性は上流のパッケージで発見され、その後、それを管理している適切な担当者に報告されました。そして、私が発見したメモリ破損の脆弱性もありました。つまり、メモリ破損の脆弱性も15～20件あったということだ。そして最後に、差分チェックのために、4、5個のサンプルが見つかりました。これは、20,000 の脆弱性が発見されたという一般的な規模の話ではなく、私が話しているのは 15 ～ 20 という小規模な規模の話です。ここで注目すべき理由、あるいは重要な点は、顧客から報告されたりNetskopeで報告された各脆弱性がIMFに報告されるということです。
0:20:15 モヒト・クラムコリー:したがって、IMFの事件はその被災者にとって大きな損失をもたらすでしょう。つまり、製品の中にそれを見つけることで、私たちは多くの費用を節約でき、そして私たちが何に取り組んでいるかについてお客様からの信頼を確保できるのです。
0:20:35 エミリー・ウェアマウス:ええ。今、あなたの記事から特に興味深く探求したいことを書き出しました。モデルがカーネル側にバグを発見し、メモリが内部でどのように割り当てられるかについての微妙な点を解明するまでクラッシュが発生しなかったという話をしましたね。その特定の例について、大まかに説明していただけますか？
0:20:59 Mohit Kulamkolly:はい、もちろんです。つまり、この脆弱性は設定解析器にあったのだと思います。この構成パーサーは基本的にレジストリ値を正確に割り当てられたプール割り当てにコピーし、使う文字列長のコピー関数に変換しました。 そして、この文字列リンクコピー機能には、本来備わっているはずの送信チェック機能がありませんでした。つまり、境界外チェックです。そのため、これは典型的な境界外脆弱性であり、非常に簡単に悪用される可能性があります。つまり、この脆弱性にたどり着くには、満たさなければならない前提条件が5つか6つほどあったということです。したがって、前提条件は、ソフトウェアが特定の種類のサービス名を受け入れるかどうか、あるいは受け入れるものが別のものなのか、または受け入れるバージョンが異なるのかを確認するだけの簡単なものになります。これらはすべて前提条件です。
0:21:54 Mohit Kulamkolly:つまり、すべての前提条件が満たされた後でも、クラッシュは発生しなかったということです。そこでデバッガにジャンプしてアロケーターを愚かにしなければなりませんでした。 そして、OSがどうやら「null terminator」と呼ばれるものを付け加えていることが判明しました。これは非常によくあることです。 そして、アロケータはそのバッファを丸めて、基本的に完全なテーブルにしたのです。そのため、行き過ぎた読むが、私たちが着地した場所に着地しなかったのです。 そして、どのようにしてそれが起こっているのか、アロケータのジオメトリを解明し、障害を引き起こすと予想されるものに完全に一致するようにエクスプロイトを変更したのです。それが、非常に大まかなレベルで起こったことです。ええ。
0:22:35 エミリー・ウェアマウス:私があなたに説明を求めた理由の一つは、衝撃的な瞬間を体験したかったからです。つまり、この複雑さと詳細な層を考えると、もしあなたが手作業でその結果に到達した世界を想像するとしたら、どれくらいの時間、何人時かかるでしょうか？それは具体的にどのようなものになるのでしょうか？それとも
それは偶然にしか起こらない
お考えですか？0:23:02 モヒト・クラムコリー:つまり、何日も何日もかかる作業になるでしょう。そして、あなたが言ったように、それも事故だったということになるでしょうね。つまり、これらのことを解明するのは非常に難しいのです。デバッガを見てアロケータがどこで間違ったのかを見つけようとすると、そこに表示される膨大な情報から意味を見出す必要があるからです。あなたが調べている特定の分野の専門家ではないかもしれませんが、点と点をつなぎ合わせるためには、これらのことをすべて知っておく必要があります。ですから、繰り返しますが、これらの問題
偶然遭遇することもあれば、この脆弱性を発見するために何ヶ月も何時間も費やすこと
あるのです。0:23:40 エミリー・ウェアマウス：あなたの記事の中で、私が興味深いと思った点がもう一つありました。AIを使っても、このバグを特定するのに数日と数千回の試行錯誤を要した。つまり、人間が同じようなことをするには何日もかかるだろうとおっしゃっていましたね。AIを稼働させたとしても、この作業には数日と数千回の試行を要した。そのプロセスを動かし続けたものは何だったのか？失敗した試みと、最終的に成功した試みの間には、何が変わったのか？なぜタイムアウトしなかったのか？つまり、もし何千回もの試行ではなく、何十万回もの試行が必要だったとしたら、諦めて見つからなかっただろうか？私はそこでいくつか異なる質問をしました。お好きなものをお選びください。
0:24:18 モヒト・クラムコリー:いや、理にかなっている。実際、その脆弱性、あるいはその特定の事例を発見するプロセスが困難だった理由は、そのソースコードがなかったからです。シンボル表も何もなかった。これは完全なブラックボックステストです。つまり、こういった脆弱性を発見しようとする場合、脆弱性そのものにたどり着く前に、いくつもの微妙な点が存在するということです。つまり、AIによるタイムアウトの部分に関しては、その設計方法によっては、最初の仮説がうまくいく場合もあれば、うまくいかない場合もあるという、多くの反発に直面することになるでしょう。一方の仮説が完成するのを待ってから、もう一方の仮説に取り掛かる、というようなことはしてはいけません。つまり
直線的な流行ではなく、ほとんどが平行的な流行だった
です。0:25:09 モヒト・クラムコリー:つまり、エージェントは必要に応じてサブエージェントを生成し、これらのイデオロギーを探求して、適切なアプローチ方法を見つけたり理解したりするのです。だから、ほとんどの場合タイムアウトしなかったのです。こうした脆弱性を発見するには、特に複雑さと入手できる情報が少ないことから、数日間かかるのだと思います。でも、サブエージェントがうまく機能したん
。0:25:34 エミリー・ウェアマウス:では、少し視野を広げてお話しましょう。リスナーの皆さんは、あなたが発表されたこの2つの記事が読む価値のあるものであることを理解してくださっていると思います。ですので、この詳細を読む場所について、ショーノートに詳しく記載します。 しかし、あなたが実施した具体的な実験から少し視野を広げて、より広い文脈でこれが何を意味するのか、そして、リスナーの中には、自分の環境について考える際に、これらの最先端のモデルすべてに現時点でアクセスできない人もいるかもしれないが、これは何を意味するのかを考えてみましょう。まず最初に頭に浮かぶのは、この種の能力がNetskopeだけのものではないかどうかということです。これらのモデルにアクセスできる組織は非常に多く、フロンティアモデルと見なされていないモデルでさえ、より賢くなっています。
0:26:17 エミリー・ウェアマウス: もしこの手法がコードやシステムのバグを見つけやすく、それに似たツールが誰でも利用可能であるなら、あなたのような研究チームを持たず、他の人に使うシステムを受けている平均的なセキュリティチームにとっては、こうした問題を攻撃し発見することは何を意味するのでしょうか? 業界が直面しているその課題を見て、どのように感じますか?
0:26:47 モヒット・クラムコリー: はい、最終的にはケースやケースのあらゆる開発の視点で、セキュリティの進歩によりモデルはどんどん安くなっていくでしょう。 ですから、今後起こることは、他のモデルのいくつかも、今や誰もがオープンソースのオープンウェイトモデルにアクセスできるようになり、これらのことを探求できるようになることです。ですから、どんなセキュリティ研究チームにも、何をしようとしているにせよ、始めることをおすすめしたいのは、これらのAIに適切なツールを提供することです。 そして、AIに適切なツールを与えれば与えるほど、驚くような発見が増え、AIはこれらのことを解明するために、より多くのことを自ら探求できるようになるでしょう。つまり
それ
既存の別のツールに接続するために必要な複雑なツールとして見るのではなく、0:27:42 モヒト・クラムコリー: 例えば、ツールを接続するために使う必要があるMCPサーバーが必要で、そのためのMCPサーバーがない場合、つまり、ゼロから書き上げて、その上に構築していく必要があるということです。つまり、その側に到達するには、乗り越えなければならない学習曲線があるということです。つまり、MCPサーバーも公開されているAPIに過ぎず、それをAIに接続するだけだと考えてください。それだけのことです。つまり、単純なコードなんです。試す それを解明しようと。 そして、もしツールを接続できなければ、もし接続できなければ、自分で何かを書くか、使うに書かせる必要があります。 そういう意味で、感覚的なもの、目や鼻、耳など道具を使い始めるときに。 そして、それらがすべて揃ったら、ツールやAIがあなたの望む方法で情報を処理し始め、より良い結果が得られます。
0:28:37 モヒト・クラムコリー：ええ、私
そう考えて
ます。0:28:40 エミリー・ウェアマウス：このようなアプローチは、ソフトウェア企業やテクノロジー企業がソフトウェアを出荷する方法を大きく変えると思いますか？スケジュールは変更されるのでしょうか？それは人々の期待やコストに変化をもたらすだろうか？それらの影響はどのようなものだと思いますか？
0:28:57 Mohit Kulamkolly:間違いなくそうです。そう、先ほども言ったように、AIが進歩すればするほど、セキュリティ上の脆弱性を発見するコストはどんどん安くなっていくでしょう。つまり、修理費用は高くなるということです。このレートで、今ソフトウェアを出荷しています。つまり、これらの脆弱性に対する修正には費用がかさみ、実行もより困難になるだろう。つまり、NetskopeがAIが存在する以前からこの技術を持っているように、私たち自身のSDLC開発ができているのです。だから、そのソフトウェアに関しては、二の次という発想はない。申し訳ありませんが、セキュリティは二の次ではありません。製品そのものについて考え始めるとき、ホワイトボードから最初に思いつくアイデアです。つまり、その特定のアプローチを採用するのであれば、PRD（製品要件定義書）または製品要件ドキュメントが準備できた直後に
AIに製品の脅威モデル
構築させるということです。0:29:54 モヒト・クラムコリー:つまり、それ自体が、製品自体を開発する際に何を想定すべきかというヒントになるということです。つまり、AIのためのコンテンツコンテキストがもっと必要だ。いずれにせよ、AIはこういったものを構築するだろう。つまり
AIにもっと多くのコンテキストを与えることで
ソフトウェアの後期段階でそのような脆弱性が存在しないようにできるのです。0:30:08 エミリー・ウェアマウス: これは非常に興味深いアイデアです。なぜなら、これらの実験を通じて、すでに複雑に構築されたものをAIに調べさせ、問題点を見つけることになるからです。しかし、実際に製品コンセプトやアーキテクチャのスケッチができた段階で、実際に使うシステムを導入できると示唆しています。AIシステムが計画に穴を開けて、セキュリティの厳密さを最初から本当に実行させようとしているのですね。 うまく機能しないかもしれないものに時間と労力を費やす必要はありません。問題が起こる前に見つけ始めることができます。
0:30:45 モヒト・クラムコリー: まさにその通りです。
通り
。0:30:47 エミリー・ウェアマウス:それについては全く考えていませんでした。ですから、セキュリティチームが何かをしたい場合、特にデジタル資産の一部を担当するセキュリティチームがそうです。今それはベンダーだからかもしれませんし、スタック内でプライベートアプリケーションやプライベート要素を構築している場合もあります。 もし彼らがこのようなことを初めてやろうとする場合、あなたが最初に心配するかもしれない、彼らが飛ばしてしまう可能性のあるステップは何ですか？そして、あなたが彼らを引き戻したいと思うのはどのステップですか？彼らが自分たちで始められることについて少し話してくれましたね。 何か持ち上げたいものがあるけど、まずこれをやってみて？
0:31:26 モヒト・クラムコリー:ええ。わかった。いや、それは理にかなっている。だから、これらの研究結果に関して私が特に感じているのは、AIに関しては、幻覚の部分については全く考えないようにしようということです。AIがすべての脆弱性を発見したとしましょう。つまり、AIが2万件の脆弱性を発見できたとしても、その2万件の発見内容を開発者に押し付けて、「とにかく修正しろ」と言うのは正しくない。だから、そこだけは注意すべき点だ。脆弱性を見つけるのは一つのことですが、修復計画を立てることも重要な要素です。 ですから、これらの脆弱性を話し始める前に、まず開発者と話し合い、どこから脆弱性を見始めるべきか、そしてそこにある重要な要素が何かを理解する必要があります。 つまり、そうした相乗効果が得られた場合にのみ、これらの脆弱性も有用となるのです。さもなければ、それは修正されていない脆弱性の長いリストに20,030,000件も積み重なるだけです。
0:32:26 モヒト・クラムコリー: だから、私がこれらの高度なツールに深く取り組んだり始める前に、まず最初に考えておくべきことの一つはここです。
0:32:34 エミリー・ウェアマウス：それは素晴らしい指摘ですね。ですから、やっていることの詳細や厳密さ、ガードレール、アプローチを正確に把握しつつ、少し視野を広げて自分のプログラムが他の人に与える影響を考え、他人のキューを500倍も増やして嫌われるからといって始めてはいけません。
0:32:54 モヒト・クラムコリー:その通りです。
0:32:56 エミリー・ウェアマウス：素晴らしい。モヒトさん、今日はこの件についてお話するためにご参加いただき、本当にありがとうございました。読む記事を読んだ瞬間、どうしてもあなたを呼ばなければと思ったので、時間を作ってくださって本当に感謝しています。 そして、これがあなたの最後の実験ではないことも感じています。私たちはそれを第1段階、第2段階と表現しましたが、あなたの目の輝きから察するに、おそらく既に第3段階が始まっているのでしょう。リスナーの皆さんは
あなたの活動や発見について最新情報を得るには
どこに行けば良いでしょうか？0:33:23 モヒト・クラムコリー:もちろんです。うん。これらの作業の大部分はNetskopeのウェブサイトにあるレンズブログで記録されています。そして、もし他に何か追加の情報があれば、Netskopeのコミュニティサイトにも投稿します。でも、このテストに関して
さらに多くのことが起こるでしょう。0:33:41 エミリー・ウェアマウス：素晴らしい。ポッドキャストにまた出演してもらって、出来事が起こるたびに話を聞く必要があるかもしれませんね。
、どうもありがとうございました。0:33:47 モヒト・クラムコリー：ありがとう、エミリー。
0:33:48 エミリー・ウェアマウス: あなたはSecurity Visionariesのポッドキャストをお聴きいただき、このエピソードを楽しんでいただけたなら、ぜひ私たちの過去のカタログをぜひご覧ください。お気に入りのポッドキャストプラットフォームで聴くことができます。また、最近のエピソードはYouTubeにもアップロードしていますので、私たちが笑顔で皆さんとお話している様子をご覧になりたい方は、ぜひご覧ください。それでは
お楽しみください
また次回お会いしましょう。
){kind=icon}
