「技術者として楽しいか楽しくないか」それが自分の基準なのだと Tenable Network Security Japan株式会社 セキュリティエンジニアリング部長の阿部 淳平（あべ じゅんぺい）は取材で答えた。
だからこそ阿部は、今在籍している Tenable から声をかけられたとき、すぐには首を縦に振らなかったという。元同僚から Tenable への誘いの連絡が来たのは 2018 年頃のことだった。阿部の第一印象は率直だった。
「脆弱性管理はレガシーなイメージがあって、テクノロジー的に魅力がないと思いました（阿部）」
● 常に「フロンティア」を選んできたキャリア
セキュリティ技術者としての阿部のキャリアはジェイズ・コミュニケーション社でスタートする。Juniper のネットワーク製品を軸に IPS や SIEM 等を担当し、約 6 年半でセキュリティエンジニアとしての基盤を築いた。それに続くネットワンシステムズ社では、「ファイアウォールは死んだ」という強烈なキャッチコピーを当時広告で展開した Palo Alto Networks 社の次世代ファイアウォール製品のプリセールスを担う。同時に阿部は、日本でまだ誰も扱っていない製品を海外から発掘する仕事にも関わった。すなわち Tanium、Carbon Black といった黎明期の EDR 製品を評価し、国内市場への展開の可能性を探った。その後フォーティネットジャパン社、タニウム社を経て現在の Tenable へ至る。
阿部のキャリアに共通するのは、常に「その時点で最も新しい技術が動いているフィールド」を選んできたことだ。「技術者として楽しいか楽しくないかが、私の判断基準です」と阿部は語った。
「新しい領域に携われることが面白い。枯れた領域だと自分の知見も広がらないし、やりがいもない（阿部）」
こんな例を挙げてくれた。ジェイズ・コミュニケーション時代、IPS 製品では Winny に代表される P2P トラフィックをうまく検知することができなかった。IPS はポート番号やパケットのパターンをもとに既知の攻撃シグネチャを検知する仕組みであり、Winny のようにポートを動的に変えたり、トラフィックを偽装したりするアプリケーションの前では限界があった。
ところが次世代ファイアウォールはポートやプロトコルではなくアプリケーションそのものを識別できる。Winny であれ何であれ、通信の中身を見てアプリケーションを特定できるため、IPS で検知できなかった問題が一気に解決された。「それまでできなかったことが新しい技術でできるようになる。その瞬間が面白い」と阿部は言う。
そんな阿部の目には、Tenable がやっていることは、十年一日のごとく脆弱性をスキャナで検知して、検証や調整を行い淡々とパッチを当て続けるクリエイティビティのかけらもない仕事と映るのは致し方ないことだった。
● 「レガシー」という先入観が覆るまで
しかし実際に Tenable 製品を見てさわって、話を聞くうちに阿部の評価は変わっていく。
まず驚いたのは、Tanium ですら基本オンプレで動いていた 2018 年前後に、すでに Tenable が完全なクラウドネイティブの SaaS として稼働して脆弱性管理を提供していた点だ。しかも競合製品の多くが、最初に作ったオンプレミスベースのアプリケーションを単にクラウドに載せ替えただけのケースが多かったのに対して Tenable は純粋にクラウドネイティブの SaaS として設計されていた。
カバレッジの幅も想定を超えていた。サーバだけでなく、ネットワーク機器や IoT デバイスまでを最初からスコープに収め、OT（製造システム）への対応も始めていた。OT が使う産業用プロトコルは TCP / IP とは全く異なる体系を持ち、発電所固有、工場固有のものまで存在する。それをひとつひとつ対応していくには相当の技術的蓄積が必要なのだが、Tenable にはその蓄積がすでにあったのだ。
また、スコアリングのアプローチも先進的だった。脆弱性の深刻度評価といえば CVSS スコアが一般的だった当時、Tenable は早くから独自の脅威スコア（VPR：Vulnerability Priority Rating）を持っていた。実際の攻撃可能性や、悪用の蓋然性を加味したリスクベースの評価は、カーネギーメロン大学ソフトウェア工学研究所が開発した SSVC（Stakeholder-Specific Vulnerability Categorization）に近い発想だった。
そして何より同社のコンセプト「エクスポージャーマネジメント」の一貫性である。個々の脆弱性を検知・修正するという従来の発想を超え、組織が攻撃者にどれだけ「さらされているか（エクスポージャー）」を、IT・OT・クラウド・ID といったあらゆる攻撃対象領域にわたって継続的に把握・評価し、リスクを能動的に減らし続けるアプローチだ。他社が XDR といったマーケティング上有利なその都度の流行語に読み換えていくなかで Tenable はブレなかった。
レガシーだと思っていた領域が実はそうではない先端領域であることに阿部は気づいた。
● 入社直後、最初の大仕事
2018 年 3 月に入社した阿部が最初に直面したのは、大手金融機関の大規模な脆弱性管理導入プロジェクトだった。入社間もないタイミングで、難度の高い案件に放り込まれた形だ。
海外ベンダーとして避けられない日本語環境への対応問題があった。加えて「基本的にシステムへの影響はない」と謳うスキャンが、顧客サーバーのログ領域に書き込みを発生させるという想定外の挙動も見つかった。なぜ書き込みが起きるのか、どのプロセスが原因か、どうすれば止められるかを解明しながら、本社開発チームへの報告と顧客へのコミュニケーションを同時並行で進めた。
金融機関の導入プロジェクトはステークホルダーが多く何かあれば責任問題になる。「動くのか」という問いに答え続けるために、条件を整理し、事象を再現し、開発チームと粘り強く交渉し、顧客の信頼を獲得した。それを入社直後にやり遂げた。
● Tenable にしかできないこと
他社との差別化を、阿部は三つの軸で語る。
最初に挙げるのは繰り返しになるが「コンセプトの先見性と一貫性」だ。全領域にわたるエクスポージャーマネジメントというビジョンを、まだ実現できていない段階では業界から「大風呂敷」と揶揄されながらもずっと掲げ続け、ずっとブレていない。独自の脅威スコアリングも業界に先んじていた。
次が「広さと深さ」である。IT・OT・クラウド・AI へとカバレッジ領域を拡張し続けており、また、脆弱性単体の評価だけでなく、複数の脆弱性を組み合わせて攻撃の成功確率を検証する、攻撃者目線の評価「アタックパス（攻撃経路）分析」まで単一のソリューション内で提供する。個々のリスク評価から総合的な評価まで一気通貫で扱える製品は多くない。
最後が事前対策への特化だ。フォレンジックでもインシデントレスポンスでもなく「攻撃される前にリスクを把握し、軽減する」という最も費用対効果が高いアプローチだけに愚直に徹する。攻撃が起きる前の段階に向き合い続けることが、Tenable のアイデンティティだ。
● 「単純だと思っていた仕事」の複雑さ
当初、阿部が業務に抱いていたイメージはシンプルなものだった。「脆弱なソフトウェアを見つけて修正する。以上。」しかし現実は違っていた。たとえば OSS のライブラリに脆弱性が発見されたとき、自社環境でそのライブラリを使っているかどうかを確認する作業は容易ではない。Log4j の脆弱性のように、自分たちのアプリケーションが直接使っているライブラリだけでなく、そのライブラリがさらに別のライブラリを使っているという依存関係が何重にも連鎖しているからだ。
また、たとえ Windows のパッチをあてていなくても、レジストリの値によっては実際には影響を受けないケースもある。Microsoft はパッチと同時に「特定のレジストリ値を変更することで脆弱性を無効化できる」回避策を公開することがあるからだ。パッチが未適用であってもレジストリ設定で攻撃経路が成立しない場合、対応の優先順位を下げても構わない。
「入社当時これほど複雑な仕事だとは想像できていなかった（阿部）」
つまり、パッチ未適用 ＝ 危険、では必ずしもない。システムが置かれたコンテキスト（設定状態）まで深く見に行かなければ、本当のリスク（Exposure）は測ることはできない。「スキャンしてパッチを当てるだけ」ではなく「コンテキストを理解してリスクを解釈する仕事」なのだ。阿部が「複雑」と語った背景には、こうした技術的な奥深さがある。
また、脆弱性管理の担当者は、組織の中で孤立しやすい立場にあるという。セキュリティの観点からパッチ適用を求めれば、サーバー担当者から「なぜやらないといけないのか」と反発される。重要性を理解しているのは自分だけ、そんな状況に陥りやすい。
こうした現場の実態を理解するにつれ、阿部が対話する対象は変化していった。セキュリティ担当者だけでなく、IT 部門、そして経営層。ランサムウェア被害の報道が相次ぎ、脆弱性管理が経営課題に上がるようになったここ 2 ～ 3 年で脆弱性管理に本気で取り組む企業の数は明らかに増えたと阿部は振り返る。
● 次に目指すもの ～ CTEM チームの普及
阿部が考える将来像は、エクスポージャーマネジメントを担う専任組織「 CTEM チーム」の普及だ。
CTEM（Continuous Threat Exposure Management：継続的脅威エクスポージャー管理）とは、2022 年に Gartner が提唱したフレームワークで、たとえば年一あるいはサービスリリース前などに脆弱性診断やペネトレーションテスト等を「断続的」に行うのではなく、攻撃者の視点から自組織の露出されたリスクを「継続的」に把握・評価・対処し続けるという考え方で、Tenable が提唱し続けてきたコンセプトと重なる。
今日、大企業に限れば CSIRT を持つ企業は増えてきた。しかし攻撃が来る前に体系的に備えるチームは、グローバルの大企業やホールディングス構造を持つ一部の組織に留まり、日本ではまだほとんど見当たらない。「インシデントレスポンスチームはあるのに、エクスポージャーマネジメントチームがきちんと組織化されているところはほとんどない」と阿部は言う。
記者はこれまでサイバーセキュリティインシデントの被害発生のリリースや調査報告書を年に数百件は仕事の上で読んできたが、リリースにある「今後の対策」の欄には、ほぼ必ず EDR の導入等が記されている。しかし「エクスポージャーマネジメントの本格実施」などという記述を見たことは記憶の範囲内でただの一件もない。
経営学者のスティーブン・コヴィーは著書の中で、仕事を「緊急性」と「重要性」の二軸で四象限に分類した。
（1）緊急かつ重要な「危機対応」、（2）重要だが緊急ではない「予防・計画」、（3）緊急だが重要ではない「目先の急ぎ仕事」、最後に（4）緊急でも重要でもない「無駄」である。この中でコヴィーが最も注力すべきと説いたのは第 2 領域、すなわち「重要だが緊急ではない」領域だ。火事が発生してから消すのではなく、火事が起きないように備えることがそれにあたり、阿部が言う CTEM チームやエクスポージャーマネジメントはまさにこの領域に属する。
ただ、この正論には厄介な問題がある。ランサムウェア攻撃に臨機応変に対応したシステム部門の技術者は時にヒーローになるが、そもそも攻撃が起きないように日々備えていた技術者は感謝すらされない。本誌がかねてから指摘してきた「ゴールキーパーの比喩」がここでも当てはまる。難しいシュートを横っ飛びで止めたキーパーは称賛される。しかし相手の動きを正確に読み、最初から正しい位置に立っていたキーパーは「真正面に飛んできたボールを取っただけ」と評価される。エクスポージャーマネジメントとは、まさに後者の仕事である。
しかし、だからこそ、この領域には「計画を持って取り組める」という本質的な強みがある。アラートが鳴ってから動くのではなく、鳴らないために動く。インシデントレスポンスチームのバーンアウトが業界の慢性的な問題となっている今、プロセスの上流に投資することの意義はかつてなく大きい。
サイバーセキュリティ業界は長らく「攻撃された後の物語」を好んできた。ランサムウェア被害、情報漏えい、緊急対応、復旧劇。そこには危機もドラマもある。しかし阿部が語るエクスポージャーマネジメントは、その物語そのものを発生させないための営みだ。ドラマはない。英雄も生まれない。ただ、それこそが本来あるべきセキュリティなのだろう。
--
そもそもセキュリティ業界はなぜ予防よりも事故対応を称賛するのか。それなりに余韻のある結びの文を書いた直後に身も蓋もない正論を言ってしまうが（金融などの業界以外では）会社は事故が起こらない限り予算を出さないからだ。というか起こっても出さないところもある。
だから阿部淳平と Tenable の戦いは、脆弱性や攻撃者との戦いである以前に、「まだ起きていない危機」に向き合う重要性を組織に理解してもらうための戦いなのかもしれない。
