whack-a-mole は負けている

モグラたたきは負けである

セキュリティエンジニアリングの分野で、製品のセキュリティエンジニアリングに従事する2つのタイプの人物を対比させたいと思います。第一に、「アイデンティティとしてのセキュリティ」の人々です。これは、Hackersで称賛され、電話盗聴時代にまでさかのぼる、セキュリティをカウンターカルチャーとする考え方につながります。これは、トムソンによる「ワークイズム」を反映しており、仕事は単に生計を立てる手段ではなく、アイデンティティ、目的、コミュニティを構築する方法です。セキュリティの場合、このアイデンティティは、他者とは違う、他の人が気づかないことを見抜く、エッジの効いた誤解されがちな方法で賢くあることによって築かれる傾向があります。単なるセキュリティ専門家を超えた、ハッカーのペルソナを持つ人物です。システムよりも賢い、スタイリッシュなアウトサイダー。他の人が見逃す洞察を見つける探偵。

ハッカーのエトスに問題があるわけではありません。システムが破綻する場所を見つけ、予期せぬ、あるいは間違った方法で機能する場所を見つけるという考え方は、明らかに非常に価値があります。キャリア、カンファレンス、プロフェッショナルコミュニティはすべて、脆弱性の発見を報酬とし、それがより驚くべきものであるほど良いとされます。同様に、ハッカーの美学はそれ自体で確立されています。現時点では、それは主流です。毎年DEF CONには約25,000人が参加しています。

予期せぬ洞察を重視することは、ハッカーだけのものではありません。2000年代には、書籍『Freakonomics』が非常に人気がありました。それはまた、一見単純またはそれほど重要でない社会現象に対して、驚くべき説明を提示するという形をとりました。何か予期せぬものを見つけられれば、あなたは非常に賢くクールであるに違いない！しかし、驚きが本当に知性の指標であるべきでしょうか？その考え方をさらに進め、ポール・グレアム風の「結局〜」というミスディレクションを行うことができます。Yを信じると言う代わりに、Xを予想したが調査した結果、Yが真実であることが判明した、と言うのです。そうすれば、Yを正当化する必要はなく、Xが偽であると述べるだけです。

あなたが選ぶアイデンティティは、美学を超えて重要です。問題の定義は本質的に関連する世界観を運び、特にその世界観を中心にアイデンティティ、コミュニティ、職業を築いた場合、世界観を変えることは非常に困難です。根本的な問題に対処する解決策の証拠であっても、世界観を検証しない方法では拒否される可能性があります。具体的な例として、ノードハウスとシェレンバーガーは、2004年の悪名高いエッセイ「環境主義の死」で、気候変動活動におけるこの失敗モードに対処しています。環境活動家は、人々が「環境」を「特別な利益」として保護することに同意させたいと考えており、それには技術的な政策介入が必要だと主張しました。これは、キャップ・アンド・トレードや炭素排出量制限など、「環境」に関連する形での解決策が必要であることを意味しました。温室効果ガスを削減するという望ましい結果をもたらすものの、「環境的」とは十分にみなされない解決策、例えばクリーンエネルギーコストの削減（使用量の増加を伴う）、高収量農業（有機農産物だけではない）、そして行動変容よりも技術的代替がうまく機能するという考え方は拒否されました。皮肉なことに、この物議を醸したエッセイから20年が経過した現在、これらの拒否された解決策の多くが最終的に実現したことがわかります。太陽光発電とバッテリー技術の進歩、そして電気自動車やその他の再生可能エネルギーは、2010年代には多くの政府補助金を受けていましたが、2000年代の環境主義の受け入れられた世界観を検証した政策よりも、温室効果ガス排出量の削減に貢献しました。

セキュリティにおいて、技術的に印象的な脆弱性を繰り返し発見、悪用、パッチ適用することのように見えない解決策は、「アイデンティティとしてのセキュリティ」を持つ人物の世界観を満たさない場合、見過ごされる可能性があります。特に、探偵として行動することを好む場合です。攻撃者のマインドセットと一貫した脅威モデルは、安全なシステムを構築するために重要です。しかし、それらは必要条件ではありますが、十分条件でしょうか？また、それらは良い出発点でしょうか？私たちは、料理人に「シェフのように考えろ」と指示して料理を教えるわけではありません。

ここで、第二のタイプの人々、すなわち「堅牢性としてのセキュリティ」の人々に移ります。結局のところ、セキュリティ分野には、障害条件、エッジケース、不整合が発生した場合でも、望ましい特性を維持する正しいシステムを構築することに主に動機づけられている人々がいます。セキュリティは、攻撃者に直面した場合でも、あらゆる条件下で適切に動作する、適切にエンジニアリングされたシステムを構築する一部です。

その違いを説明するために、脆弱性報奨金プログラム（VRP）、別名バグバウンティについて人々がどのように考えているかを見てみましょう。VRPの目的は何でしょうか？最低限、VRPは、攻撃者に悪用される前に製品でパッチを適用できるように、セキュリティ問題の連絡窓口として機能します。十分に大きな製品（または特にプラットフォーム）を実行している場合、セキュリティ問題に関する連絡を受けるでしょう。少なくとも一部のセキュリティレポートは有効であり、パッチが必要になります。VRPは、組織が製品の一部に取り組んでいる個々の機能チーム以外の、人々によって提出された外部および内部のセキュリティバグレポートに対応する能力を持つことを強制する標準的なプロセスです。参加者があなたにとって生産的な方法でバグを報告することを経済的に奨励します。VRPは、発見されたバグの数が相対的な支払い価格よりも速く増加する限り成功すると言う、非常に直接的な経済的議論があります。VRPによって発見されるバグが多いほど良いのです。

バグの発見とパッチ適用を超えて、VRPはセキュリティチームの戦略を通知するために使用でき、また使用されるべきです。VRPは、標準的な製品管理アプローチにおける顧客の役割の代替として、可能な限り近いものです。攻撃者はあなたのユーザーではなく、セキュリティの全範囲は未知の未知数です。攻撃対象領域全体を列挙するわけではありませんが、VRPは攻撃者の方法論に関する洞察を得て、セキュリティチームの作業を検証するための、繰り返しの一貫した方法であり、未知の未知数のサイズと影響を制限することができます。VRPでどのような種類のバグが発生しているか、製品のどこで発生しているか、なぜ発生しているか、どのチームがそれらを所有しているか、これらすべてが、バグがまれになる未来に向かって構築されているセキュリティロードマップの入力となり得ます。VRPは双方向の道でもあります。脆弱性研究者はインセンティブに反応するため、セキュリティチームが仮説を検証してセキュリティイニシアチブを正当化したい場合、VRPのルールと報酬を調整して、仮説を検証し、他のチームやリーダーシップにロードマップを正当化するための証拠として使用できる提出を奨励したり、仮説が間違っていることを示す提出を奨励したりすることもできます。VRPの結果がロードマップが現実に結びついていないことを示唆している場合、セキュリティチームはその仮説を却下して別のことを試すことができます。VRPの最も良い点の1つは、バグハンターが探すものが、製品に取り組んでいる人々の信念によって制約されないことです。

VRPがより広範な戦略の入力として使用される場合、VRPの全体的な目標は、すべてのバグを完全に列挙して安全な製品を持つことではありません。VRPの目的は、セキュリティの問題に対処することです。議論の余地がありますが、VRPを通じて外部から来るバグに対処することは、それらのバグを優先する最悪の方法です。なぜなら、それは本質的に割り込み駆動型であり、バグを修正するチームによって容量管理されていないからです。VRPバグのパッチ適用は、モグラたたきの別のケースです。実際に何かを安全にすることは、セキュリティチームの責任であり、彼らはバグが発生しないようにする（例：安全なコーディングを通じて）、またはバグがもはや重要でなくなるようにする（例：影響を低減するアーキテクチャ変更を通じて）べきです。VRPにおけるこの区別、つまりすべてのバグを列挙することと、セキュリティの問題を時間とともに削減するための戦略を通知することの間には、「堅牢性としてのセキュリティ」の litmus test があります。

より多くの問題をさらに迅速に見つけることは良いことであるという極性がありますが、それは問題を知らずにいるよりも、問題を見つけて修正する方が良いからです。しかし、それはあなたのシステムが意図したとおりに機能していない証拠でもあるため、悪いことでもあります。問題を発見することは診断指標です。それはあなたのセンサーが機能していることを証明します。問題の種類の発生状況を追跡することは、結果指標です。同じ種類の問題が繰り返し発生しないことを保証することが、成功の真の兆候です。

すべてのバグまたはインシデントは失敗であり、失敗は起こりますが、たとえ非常に速く対応していたとしても、常に発生しているなら、私たちはそれに怒るべきです。セキュリティ以外では、サイト信頼性エンジニアリング（SRE）を考えてみましょう。サービスが継続的にダウンタイムやその他のSLOに違反するエラーを発生させ、最終的にエラーバジェットを消費する場合、SREチームは、用語の元の定義の下で、機能開発とリリースを停止し、機能よりも信頼性にリソースを移動し、製品チームと協力して体系的な修正を構築および展開することを許可されます。SLOコンプライアンスがエラーバジェット内に戻ったら、製品作業は継続されます。つまり、長期的な主な目標は堅牢性であり、SLO非準拠インシデントを迅速に解決することは二次的です。SREアプローチはモグラたたきではありませんが、SREチームが介入し、製品チームの目標を中断する可能性がある場合に、リーダーシップレベルでの調整が必要です。

残念ながら、セキュリティにおいては、モグラたたきが目標になりすぎることははるかに簡単です。解決されたインシデントのグラフが右肩上がりに増加するグラフを作成できるため、メトリクスとコンプライアンスゲームには優れています。場合によっては、解決時間も時間とともに短縮されるかもしれません！また、他のチームのロードマップに介入するよりも、組織的な調整をあまり必要としないため、独自の運命を所有しているように見えるセキュリティチームを簡単に持つことができます。実際のセキュリティ成果の所有権を取ることは恐ろしいです。なぜなら、攻撃者は未知だからです。しかし、モグラたたきをプレイすることは負けです。

たたかれたすべてのモグラは、攻撃者にとっての機会です。問題に反応することに最適化し、それを迅速に解決するだけ（そして場合によっては、同じ穴を繰り返し、繰り返し、繰り返し、繰り返したたいている）では、成功しているように感じられるかもしれませんが、実際には負けています。勝つとは、そもそも問題がないことです。時間とともに解決されたインシデントのグラフが右肩上がりに増加することよりも良いのは、あるバグクラスの発生状況のグラフが時間とともに右肩下がりになり、ゼロに近づくことです。脆弱性を発見してパッチを適用することは、セキュリティチームが必要とするスキルですが、良い北極星ではないことを認識することは、あなたのキャリアと世界観が、他の人が見えない巧妙なバグを見つけることに基づいている場合、恐ろしいかもしれません。これは、問題を中心にアイデンティティを築いた場合、あらゆる解決策があなたのアイデンティティへの攻撃のように見えるという緊張につながる可能性があります。あなたがセキュリティに関わった理由は、しばしば問題に対する考え方に影響を与え、ノードハウスが言ったように、あなたの世界観と解決策はそれを反映します。あなたは、予期せぬ洞察を見つけ、パズルを解くのが好きだからセキュリティに関わったのですか、それともシステムを構築するのが好きで、セキュリティはその中で最も興味深い場所の1つだからですか？

セキュリティは予期せぬ洞察に関するカウンターカルチャーであるという考え方は十分に広まっており、たとえあなたがそれにアイデンティティを築いていなくても、主にセキュリティに取り組んでいない人々でさえ、天才ハッカーの集団が成功したセキュリティチームの意味だと考えています。残念ながら、セキュリティに対するあなたの認識が、セキュリティの探求であるならば、安全なシステムを構築できる可能性は低いでしょう。あなたは、自分の重みに耐えきれなくなるまで、モグラたたきを続けるだけでしょう。

ハッカーのマインドセットは、システムがどのように失敗するかを理解するのに役立つかもしれません。そして、その失敗が悪意のある目的で悪用できる場合、セキュリティは単にセキュリティの欠陥を見つけること以上のものです。良いセキュリティチームは、根本的な原因と体系的な修正について批判的に考え、システムを以前よりも根本的に優れたものに構築することによって勝ちたいと考えています。攻撃者の能力と脅威モデルを明確にし、効果的に無限の検索空間で問題を検索することを超えて、より多くの防御者がシステムについて真実であるべき不変量（invariants）を定義する必要があります。攻撃者がそれを行うかどうかに関わらず、これらの不変量を破ることは悪いことです。良いセキュリティチームは、悪いものを探すのではなく、良いものからの逸脱を探しています。多くの場合、これらの不変量は、言語、インターフェース、安全な抽象化を通じてコードに実装でき、grepのような単純なツールを使用してCIで強制できます。他の不変量は、アーキテクチャと運用管理を通じて強制される場合があります。脆弱性は、不変量が欠けている、間違っている、または強制されていない証拠です。成功とは、これらの不変量を継続的に更新およびエンコードして、脆弱性のクラス全体が再発しなくなることを意味します。

AIエージェントの時代には、システムの検証可能なプロパティがさらに必要とされています。脆弱性の発見は、現在、これまでで最も安価です。エージェントは修復にも役立ちますが、脆弱性の発見ほど効果的ではありません。一見すると、AIが発見と修復をこれまで以上に安価にしているなら、反応的なアプローチがついにスケールするのでしょうか？しかし、AIを使っても、モグラたたきは依然として負けです。より安価な診断が、本質的に結果を変えるわけではありません。常に別のバグを見つけられるなら、次のバグにパッチを適用する限界的な利益はゼロです。

「脆弱性大発生」に関する従来の知恵は、私たちが局所的最小値にいるということであり、過去30年間のセキュリティ負債がすべて一度に呼び出されているということです。それをパッチ適用して乗り越えれば、やがてソフトウェアは全体的により安全になり、脆弱性を発見・悪用する予想コストは上昇するでしょう。

これは、私たちが物事を積極的に改善する役割を担った場合にのみ真実になります。より良い未来は単に起こるのではなく、それを実現する必要があります。努力なしに物事は改善せず、この場合、ジェボンズのパラドックスが現状維持と戦っています。エージェントを使用すると、モグラたたきをさらに速くプレイすることを選択できます。同時に、ソフトウェアエンジニアはエージェントを使用して指数関数的に多くのコードを記述しています。「スキャン」のトークンコストは時間とともに低下しますが、それを行うための複雑さとコストは、指数関数的に増加しているコード行とともに増加します。これは、AIによる脆弱性ハンティングが、防御者にとってファジングと同じ欠点を持つことを示唆しています。脆弱性の最初のセットがポップアウトした後、防御者がすべての脆弱性を列挙しようとするコストは指数関数的ですが、攻撃者が有用な脆弱性を見つけるコストは多項式です。十分に大きなプロジェクトでは、脆弱性を発見するためにAIのみを使用しても、脆弱性がまれな未来につながることは決してありません。

これは起こる必要はありません！防御者もコーディングエージェントと脆弱性ハンティングエージェントを持っています。今こそ、それらを利用して、構築によって脆弱性を防ぐことができる体系的な問題点を特定し、対処する時です。バグ修正で脆弱性大発生を乗り越えることはできません。良い結果が得られるのは、より良くすることを選択した場合のみであり、より多くのモグラたたきをプレイすることを選択した場合ではありません。AIをスケールさせるためには、防御者はシステムの不変量を明確に述べ、次にAIを利用して不変量の検証可能な強制を実装できる必要があります。これは、AIを使用する非セキュリティエンジニアにも役立ちます。彼らは自身のコーディングエージェントに対して、より検証可能な結果を得ることができ、より生産的なエージェント駆動開発を可能にします。

発見の無限のストリームを生成することは、セキュリティの専門知識、人間またはAIのいずれにとっても良い使い方ではありません。もしあなたがモグラたたきをプレイするだけなら、あなたは負けるでしょう。私たちはセキュリティを、探偵であることが価値あるアイデンティティであるため、解決すべき終わりのない謎として見るべきではありません。代わりに、防御者の役割は、失敗を新しい、より広範で、より強力な不変量に変え、これらの不変量をシステムにエンコードして、エンジニア（およびエージェント）が同じクラスの問題を常に再発見する必要がないようにすることです。その結果が負けのように感じられるなら、それはアイデンティティが目標としてのセキュリティに取って代わったからです。

ライアン・ロポポロ氏が最初に「見えないのか？我々は今、モグラたたきをさらに速くプレイできるのだ！」と私に言ったことに感謝します。初期ドラフトへのフィードバックをくれたデブ・アカーウェ氏、アレックス・クレマー氏、アレックス・ゲイナー氏、マット・ライリー氏に感謝します。