（編集部註：本記事全文は 7,026 文字あります）
昨年、とある SaaS 企業のレッドチーム演習のプロセスを取材した記事を公開したところ予想をはるかに超える反響があった。
大きい反響といっても、Google Discover に記事がピックアップされたことで野次馬が大量に集まり、せっかく書いた記事が無惨にも消費される状態（有吉弘行の言う「バカに見つかった」状態）では全くなく、レッドチーム演習に業務上興味を持つ人が一定数、「消費」でなく「精読」するというタイプの読まれ方で、ページの滞在時間も数分間と平均よりも群を抜いて長かった。要は最後までスクロールして目を通してくれたということだ。
レッドチーム演習はそもそも実施する企業自体が少ない。費用もかかるしね。ましてやその過程を共有するなんて高い公共心を持つ企業はもっと少ない。監督官庁が存在する業界などでは、たとえレッドチーム演習を行っても外部にその成果や知見が公開されること自体ありえない。
うっかりしていて年をまたいだことで堂々一昨年すなわちおととしの取材記事になってしまったが、CODE BLUE 2024 の「Googleをハッキングする 社内レッドチームの運営と成長の教訓」と題された講演のレポートを、重要な関連記事としてここで公開しておく。
--
● 標的は Google Glass 関連の知的財産
10 年以上前のある日、Google Glass 開発チームのエンジニアたちのもとに、予期せぬ届け物があった。
届いたのは小さな段ボール箱。中には封筒と、USB 接続のプラズマグローブが入っていた。プラズマグローブとは、ガラス球の中で稲妻のような放電が怪しげに走る、あのインテリア雑貨だ。封筒を開けると、親しげなメッセージカードが現れた。
「おめでとう、Kate！ もう4年になるんですね。あなたの貢献に感謝します。ささやかですが、お祝いの品をお送りします」
人事部門の担当者を名乗る署名があった。Kate は実際に Google で 4 年目を迎えたばかりだった。レッドチームは LinkedIn で、Kate が入社 4 周年を迎えたことを事前に把握していた。彼女だけではない。同じパッケージを受け取ったエンジニアたちは皆、当時 Google が最も力を入れていた新製品 Google Glass の開発に携わっていた。唯一の問題は、このプラズマグローブが Google の公式な記念品ではなかったことだ。
送り主は Google のレッドチーム。攻撃者を模倣し、自社のセキュリティを検証する内部組織である。プラズマグローブには、見た目ではわからない、ある仕掛けが施されていた。USB ポートに接続すると、キーボードとして認識され、事前にプログラムされたキーストロークを高速で送信する。コマンドを実行し、インプラントをダウンロードし、リモートアクセスを確立する。現在では USB Rubber Ducky として広く知られる攻撃手法だが、当時はまだ認知度がそれほど高くはなかった。
レッドチームの狙いは、Google Glass の知的財産、すなわち設計文書や仕様書に外部の攻撃者がアクセスできるかどうかを検証することだった。結果、アクセスは成功してしまった。
それだけではない。レッドチームは獲得したアクセス権と情報を使い、ハードウェアチームに「プロトタイプの受け取り準備」を依頼するメールまで送信することができた。「受け取りに行くから準備しておいて」とは、あまりにも大胆な要求だったし、講演者は「正直、さすがにバレると思った」と振り返る。だが誰も怪しむことはなかったという。
この演習後、複数の脆弱性が修正された。Google は独自の防御ツール「 UKIP（USB Keystroke Injection Protection）」を開発し、オープンソースとして公開もした。
ステファン・フリードリ（Stefan Friedli）は Google レッドチームのグローバルリーダーを務める人物だ。しかし彼の講演の核心は、プラズマグローブに仕込まれた攻撃に関する技術的詳細などではなかった。
● もっと早く気づくべきだったこと
「これまでで最も技術的ではない講演になると思います。同時に、最も共有したかった内容でもあります」
フリードリは冒頭でそう前置きした。レッドチームの定義、ペネトレーションテストとの違い、メリットとデメリット。一通りの説明を終えた後、彼は声のトーンを変えた。
「ひとつだけ、もっと早くフォーカスすべきだったことがあります」
それはストーリーテリング（storytelling）、物語を語る（tell stories）技術だった。
フリードリによれば、Google のレッドチームが従来型の「技術報告書」ではなく「物語形式の報告書（narrative reports）」を作成し始めたところ、組織全体で従業員の関与度と是正活動の取り組みが劇的に増加した（dramatic increase）という。
「突然、物事がほとんど自動的に動き始めたのです」
なぜ物語は、技術レポートにはできなかったことを成し遂げたのか。
● なぜ物語は組織を動かすのか
セキュリティの専門家は、孤立した技術的問題から全体像を描くことに慣れている。パッチが当たっていないアプリケーションがある。それはリモートコード実行につながりうる。横展開が可能になる。深刻だ。
しかし、この文脈を共有していない人々にとって、それは単なる技術用語の羅列に過ぎない。システムの所有者は自分の担当領域に集中している。経営層は脆弱性そのものより、それがもたらす損害に関心がある。
「セキュリティキーの全社展開のような大規模な改善も、ストーリーテリングのアプローチ（storytelling approach）によって推進力と必要なリソースを獲得できました」とフリードリは語る。
物語が有効な理由を、彼はこう説明した。
「物語を語る（tell a story）とき、読者と共有体験（shared experience）を作り出します。それは攻撃者の視点から見た体験です。それによって、技術的なバックグラウンドを持たない人にとっても、リスクや脅威がはるかに理解しやすくなります」
講演冒頭のプラズマグローブを思い出してほしい、と彼は促した。USB キーストローク・インジェクションという脅威は、当時すでにさして新奇なものではなかった。「見て、触って、手に取ることができる物体があり、それに物語（story）が付随している。それとも、脅威の説明文が文字情報だけで提示されるとしたら、あなたならどちらが心に残りますか」
ストーリーテリングは優先順位を変える（Storytelling changes how things are prioritized）。抽象的なリスク評価では動かなかった組織の歯車が、具体的な物語によって回り始めたという。
