サイバーセキュリティは今やプルーフ・オブ・ワークのように機能する

 (dbreunig.com)
6 ポイント 投稿者 GN⁺ 13 일 전 | 1件のコメント | WhatsAppで共有
  • AnthropicのLLM「Mythos」 は、複雑なネットワーク攻撃シミュレーションで人間よりも速く高精度に実行し、アクセスは限られた中核開発者にのみ許可されている
  • AI Security Instituteのテストで、Mythosは 32段階の企業ネットワーク攻撃シミュレーション を10回中3回完全成功させ、トークン予算を増やすほど性能が向上した
  • この結果は、セキュリティが 攻撃者より多くのトークンを投入してはじめて防御できる構造、つまり プルーフ・オブ・ワーク型の競争 に変わりつつあることを示している
  • LiteLLM・Axiosのサプライチェーン攻撃 以後、オープンソース依存をLLMに置き換えたり、トークンを投入してセキュリティを強化しようとする試みが広がっている
  • セキュリティは技術的創造性よりも 投入資源量が決定要因 となり、開発プロセスに 「ハードニング」段階 を追加する流れへとつながっている

セキュリティが「プルーフ・オブ・ワーク」のように機能する構造

  • AnthropicのLLM「Mythos」 がコンピュータセキュリティ課題で優れた性能を示し、一般公開されず中核的なソフトウェア制作者にのみアクセスが許可されている
    • Mythosは複雑なネットワーク攻撃シミュレーションを人間よりはるかに速く実行する
    • AI Security Institute（AISI）の評価でも、従来モデルより一段高い サイバー攻撃遂行能力 を証明した
  • 「The Last Ones」 という32段階の企業ネットワーク攻撃シミュレーションで、Mythosは10回中3回完全成功
    • AISIは各試行に 1億トークン（約12,500ドル） を使用
    • テストされたモデルの中でMythosだけが攻撃全体を完遂し、トークン予算を増やすほど性能が継続的に向上した
  • この結果は、セキュリティの経済学が 「攻撃者が使うトークンより多くのトークンを使わなければ防御できない」 という単純な式に帰着することを示す
    • セキュリティ強化は創造性よりも 資源投入量 によって決まる
    • これは暗号資産の プルーフ・オブ・ワーク（Proof of Work） メカニズムに似た構造で、より多くの計算資源を投入した側が勝つ

新しいセキュリティ経済の示唆

  • オープンソースソフトウェアの重要性がさらに高まる

    • 最近の LiteLLM と Axios のサプライチェーン攻撃以後、一部では依存コードをAIエージェントで再実装しようという提案が出てきている
    • Andrej Karpathyは「依存関係は再評価されるべきであり、単純な機能はLLMで直接実装したほうがよい」と述べた
    • セキュリティがトークン投入量に比例するなら、企業がオープンソースライブラリにトークンを投入してセキュリティを強化するほど安全になる可能性がある
    • しかし広く使われるOSSは攻撃価値が高く、攻撃者もまたより多くの資源を投入する誘因がある

  • 開発プロセスに「ハードニング」段階を追加

    • 現在、開発者は 開発 → コードレビュー の2段階プロセスに従い、各段階で異なるモデルを使っている
    • Anthropicはコードレビュー専用サービス（Code Review）を提供しており、レビュー1回あたり15〜20ドル水準
    • 今後は 開発 → レビュー → ハードニング の3段階サイクルが一般化する可能性がある
      1. 開発: 機能実装およびユーザーフィードバックに基づく反復
      2. レビュー: 文書化、リファクタリング、品質改善
      3. ハードニング: 予算が許す範囲で 自動脆弱性探索 を実施
    • 最初の段階では人間の時間、最後の段階では コストが制約要因 として作用する

コスト構造とセキュリティの限界

  • コードを書くこと自体は依然として 安価 だが、セキュリティを確保するには 攻撃者より多くのトークンを購入 しなければならない
  • モデルの推論効率が改善しても、セキュリティ強化コストは攻撃価値によって決まる ため、完全なコスト削減は難しい
  • 結果として、セキュリティは技術的創造性よりも 市場ベースの資源競争 へと移行する様相を見せている

関連記事

1件のコメント

 
GN⁺ 13 일 전
Hacker Newsの意見

  • コードベースへのアクセス権が核心だ。現在のLLMベースのセキュリティスキャンは、実質的には単純な bash スクリプトのようなもので、すべてのファイルを走査しながら「脆弱性を見つけてくれ」というプロンプトを投げる形になっている
    しかし、防御側がソース全体を制御できるなら、はるかに効率的に動かせる。たとえば PR 単位で変更されたファイルだけをスキャンしたり、セキュリティ関連コードにより多くのトークンを投入したりできる。攻撃者は毎回スキャンをやり直さなければならないが、防御側は一度のスキャンであらゆる潜在的脆弱性を先回りして見つけられる
    結局のところコストの非対称性があり、防御側が効率面で有利になる。攻撃者は複数段階のエクスプロイトチェーンを完成させなければならないが、防御側はその中で最も弱い輪を一つ塞げばよい

    • 攻撃者は多く、防御者は一つなのに、規模の経済が防御側に有利だという主張は納得しにくい。コードにアクセスできないと仮定するのはセキュリティ上よくない。すべてのセキュリティレビューはソースアクセスを前提としている
    • それでもこのアプローチはソフトウェア開発コストを押し上げる。「どうせうちだけは狙われないだろう」といった甘い姿勢は通用しない
    • 最近のポッドキャスト Security Cryptography Whatever で言及されていたように、今はハーネス改善よりも「次のモデルを待つ戦略」のほうが効率的だという点が興味深かった
    • 問題は、このアプローチによって「ある開発者の PC が感染したサプライチェーン攻撃」レベルの事件が、「ソースコード全体の流出と自動監査」へと拡大しうることだ。こうした世界はスタートアップにとって暗い森のような環境になる気がする
    • 防御側はすべての部分を強化しなければならないが、攻撃側はたった一つの脆弱性を見つければいい

  • 記事で言及されていたAI Security Institute(AISI) が気になって調べてみたが、主に DeepMind や OpenAI 出身者が参加している組織だった。セキュリティ業界の人間はほとんどいない。そのため「システムを強化するには、より多くのトークンを使うべきだ」という結論は、ややAI 業界中心の論理に聞こえる。なぜ形式検証(formal verification) のような代替案が言及されていないのかも疑問だ。NVIDIA がこうした論理を GPU 販売に利用できるかもしれないとも思う

    • これに反対しそうな著名なセキュリティ研究者が誰なのか気になる。実際には多くの研究者がこの主張に同意しているようだ。今の議論の焦点は、LLM がfuzzing レベルの革新なのか、それ以上なのかにある
    • 参考までに、AISI は英国政府傘下の機関で、科学・イノベーション・技術省(DSTI)に属している。ただし、グラフを単純な線形で描くなど、分析手法にはやや物足りなさがある

  • Tony Hoare の言葉どおり、「ソフトウェア設計には二つのアプローチがある。単純すぎて欠陥がないか、複雑すぎて欠陥が見えないかだ」という引用が印象的だ

    • 完全に単純にしたからといって、すべての攻撃を防げるわけではないが、攻撃面を減らす効果は大きい。たとえば、ネットワークメッセージを処理する前に必ず署名検証を行うよう設計すれば、署名されていないメッセージを受け入れにくくなる。現在の多くのシステムは必要以上に脅威モデルが広い
    • ただし、「複雑さ」の基準は人間と LLM で異なる。人間には複雑に見えても、LLM には単純かもしれない。だからこのアプローチがどれほど有効なのかは疑問だ

  • セキュリティは常に相手がどれだけ金を使うかのゲームだった。LLM が登場したからといって原理が変わったわけではない。Karpathy が言う「依存よりコピー」という哲学も、すでに Go 言語の格言として存在している。「セキュリティは隠蔽で得られない」という原則も昔からの事実だ

    • ただし隠蔽(obscurity) が完全に無意味というわけではない。防御のいくつもの層の一つとしては役に立つ。システムを完全に透明だと仮定して強化したうえで、その上に少しの不透明さを加えるのが理想的だ
    • 「攻撃者が使うトークンより多くのトークンを使わないと防御できない」という話は新しくない。物理セキュリティでも同じだった。結局、AI 時代にもAI で AI を防御しなければならない。まずは開発者が使うコード生成モデルのプロンプトから点検すべきだ

  • 記事の内容にはおおむね同意する。「賢さで点数を稼ぐわけではない」という文句はやや危うい。依然としてサイバーセキュリティの本質は人間のシステムにある。GPU 時間を多く使うことも必要だが、最終的には組織のセキュリティ文化と規律が勝敗を左右する。原子力や航空産業のように、事故の後になってようやく生まれるレベルの規律が必要だ。
    関連する文脈として、1年前の この記事 は今の状況をほとんど予言のように説明している

  • 「システムを強化するには攻撃者より多くのトークンを使う必要がある」という主張について、私は過去にTicketmaster API の自動化のために自分でスクリプトを書いた経験がある。彼らは PerimeterX で防御を強化していたが、3日で回避できた。最近では ChatGPT のCloudflare Turnstileを回避する方法も同様に実装した。
    数千万ドルを投じて作られたセキュリティ製品が、実際には無用の長物であることを示す事例だった
    関連 HN 投稿

  • LLM が見つけたセキュリティインシデントは本当に新しい脆弱性なのか、それとも既存のセキュリティ知識の延長線上にあるものなのか気になる。後者なら、なぜ私たちはそれを自力で体系的に見つけ出せないのか疑問だ

  • この研究がProof of Workのように見えるのは、AISI が「トークンを多く使うほど成果が伸び続ける」と述べていたからだ。つまり、攻撃成功率がトークン消費量に比例するという仮定だ。しかし実験は 32 段階のネットワーク侵入シナリオで、それを完遂したモデルは Mythos だけだった。単純なコードライブラリでは収穫逓減点がもっと早く来るかもしれない
    オープンソースプロジェクトでは、防御側と攻撃側の両方でトークン消費が増えるため、この限界点により早く達する可能性がある

    • Mythos はすべての試行で成功したわけではなく、実験ネットワークにも実際の防御体制はなかった。それでも AI を過小評価する理由はない。3か月後のモデルはまた別のレベルになっているだろう
    • サイバーセキュリティには詳しくないが、32 段階から 33 段階へ進むのに必要なトークンコストの増加率が重要なのだと思う。防御が各段階で独立しているなら、攻撃成功確率は p^N で急減する

  • 結局のところ問いはこれだ——人間が書いたコードベースを守るほうが安いのか、それともエージェントの軍団が生成したコードを守るほうが安いのか

  • 今のようにモデルをコードベース全体に無差別に投げ込むのは非効率だ。私が試したところ、source-to-sink trace を構造的に探索するようモデルを調整すると、コストは大きく下がった。
    もはやシステムがコード全体の文脈を可視化し、亀裂の入りやすい箇所を正確に指摘する時代になった。これはソフトウェア品質向上における大きな転換点になるだろう