二人のCISOの物語：エンジニアリング重視のCISOがリスクになり得る理由

出典: Ronstik via Alamy Stock Photo

質問：エンジニアリング重視のCISOとホリスティックなCISOの違いは何か、それは組織にとってどのような意味を持つのか？

SovereignAI COO、David Schwed： 現在、世界中でCISOの大量採用が進んでいます。AIラボ、暗号資産取引所、金融機関が、同じ限られたセキュリティリーダー人材プールを奪い合っています。同時に、2025年はデジタル資産窃盗にとって最悪の年になりつつあり、20億ドル超が年央までに盗まれ、その損失の大半を、取引所Bybitに対する15億ドルの単独ハッキングが占めています。

表面的には、このCISO採用ラッシュは前進のように見えますが、実は分岐点があります。多くの組織は、自分たちがまったく異なる2つのCISOアーキタイプのどちらかを選んでいることに気づいていません。間違ったほうを選ぶと、決意の固い攻撃者と初めて正面衝突した瞬間に崩れ落ちる、もろい「セキュリティ物語」を手にすることになります。

アーキタイプ1：エンジニアCISO

1つ目のタイプはエンジニアCISOであり、多くの場合デフォルトの選択肢です。このタイプは、ITインフラ、アプリケーション開発、クラウドエンジニアリングの現場で育ち、大規模な複雑システムを構築してきたリーダーです。彼らの本能は、セキュリティをエンジニアリングの問題として解こうとすることにあります。強力な予防的コントロール、テクノロジーへの大きな依存、攻撃面を最小化したクリーンなアーキテクチャに注力します。暗黙の前提として、「システムが正しく構築されていれば、脅威の大半は抑え込める」「セキュリティは、十分な暗号技術、分離、オートメーションを駆使すれば、エンジニアリングで解決できる静的な問題だ」と信じています。

このマインドセットは、今年最も注目を集めた採用事例のいくつかにも見て取れます。フロンティアAIラボは、ストリーミング業界を含むコンシューマーテック企業からCISOを採用していますが、そこで培われた「サブスクライバーのデータ保護」のスキルは、そのまま「モデルの重み、プラグイン、データパイプライン、国家レベルの脅威」からの防御に転用できるわけではありません。

中核の誤解：リスクは消えない、移動しただけだ

エンジニアCISOはリスクを排除しているわけではありません。多くの場合、リスクをコアコントロールほど厳しく監視されていないシステムの別の部分へと移しているのです。

単純化した例を考えてみましょう。エンジニアCISOが、次のようなコントロールを設計したとします。「有効なデジタル署名が存在する場合にのみ、この取引を実行せよ」。紙の上では、暗号技術と鍵管理は堅牢に見えます。

しかし攻撃者は、別の機会を見ています。彼らは楕円曲線暗号を破ろうとすることには興味がありません。その代わりに、署名を検証するコードに目を向けます。どこかに、「署名が有効であれば取引を実行する」といった関数があります。もし攻撃者が、「有効」の意味を判定するロジックを変更できたり、そのコードを配布するビルドパイプラインを改ざんできたりすれば、数学を破る必要などまったくないのです。

同じパターンは実際の世界でも見られます。北朝鮮のTraderTraitorグループによるものとされるBybitからの窃盗は、暗号アルゴリズムの破壊ではありませんでした。オペレーション用ウォレットとその周辺インフラを掌握し、捜査当局が動く前に約15億ドルを移動させたことが本質です。

同様の欠陥はAIセキュリティにも見られます。最大のリスクは、攻撃者がプロンプトインジェクションやLLMスタックのサプライチェーンの弱点を突くことです。実務上、最も弱いリンクはモデルそのものではないことがほとんどです。問題は、モデルに与えられた権限、モデルが呼び出せるシステム、そしてそれらのバインディングを誰がどのように変更できるかというガバナンスにあります。

エンジニアCISOは、事実上「こじ開け不可能な錠前」を、すでにきしみ始めているドア枠に取り付けているようなものです。彼らが最も誇りに思う防御は、多くの場合、攻撃者が単に迂回してしまう部分であり、真の脆弱性は、きれいなアーキテクチャ図のすぐ外側にあるグルーコード、パイプライン、人間のワークフローへと押しやられているのです。

アーキタイプ2：ホリスティックCISO

もう一つのタイプがホリスティックCISOです。このリーダーも技術的な深みを重視し、チームに対して十分なエンジニアリングリテラシーを持って異議を唱えられますが、セキュリティを「コードだけで解決できるもの」とは見なしません。あらゆるコントロールを、「人・プロセス・テクノロジー」を結びつけるシステムの一部として捉えます。

彼らが「署名が有効な場合にのみ実行する」というコントロールを見るとき、脅威モデルを拡張します。署名を検証するコードを誰が変更できるのか、緊急変更を誰が承認できるのか、誰が認証情報を管理しているのか、このクリティカルコンポーネントのデプロイワークフローは、通常のコードとはどう違うのか、といった点を問いかけます。

そのうえで、テクノロジーを別の観点から重ねていきます。「重要なアーティファクトをエンドツーエンドで署名・検証しているか？ 最も機微なロジックに対して完全性チェックを行っているか？ 検証コード、ポリシーエンジン、AIの設定に対する異常な変更を監視しているか？」といった問いです。

何より重要なのは、ホリスティックCISOは「いずれ何かがうまくいかなくなる」ことを前提としている点です。彼らは、単なる予防ではなくレジリエンスを構築します。セグメンテーション、被害範囲の縮小、テスト済みのフェイルオーバー、訓練されたインシデントレスポンスなどを備えます。避けられない事態が起きたとき、組織が「折れる」のではなく「しなる」ようにしておくのです。

暗号資産やAIがサイドプロジェクトからクリティカルインフラへと昇格する中で、エンジニアCISO的なマインドセットに戻ることは後退を意味します。これらのシステムは、一度築けば終わりの静的な要塞ではありません。専有コード、オープンソースの依存関係、人間のオペレーターが組み合わさった進化し続けるエコシステムなのです。

エンジニアCISOは、監査人を満足させ、安心感のある図面を生み出す「見かけの堅牢さ」を構築するかもしれません。ホリスティックCISOが構築するのは、現実世界との接触に耐えるために必要だが、しばしば不都合な「本物のレジリエンス」です。