.jpeg){kind=logo}
Zero Trust に投資している方へ質問があります。アクセス権を付与した後はどうなるのでしょうか？
誰が認証したか、という問題ではない。デバイスがチェックに合格したかどうか、という問題でもない。ポリシー上、その接続が許可されていたかどうか、という問題でもない。これらは重要な問いであり、今後も絶対に問い続けなければならない。私が問いたいのは、それとは別の点だ。信頼されたユーザー、デバイス、あるいはAIエージェントが、承認されたセッション内に入った後、その信頼が依然として正当であるかどうかを、どうやって確認すればよいのだろうか？
なぜなら、現代の攻撃の多くはそこに潜んでいるからです。玄関の外から無理やり押し入ろうとするのではなく、企業がすでに信頼している認証情報、アプリケーション、サービスを利用して、正当なアクセス経路の内部から侵入してくるのです。
「アクセス」とは決断のことです。「信頼」とは、常に変化するものです。
継続的な評価は、すでにZero Trust の原則の一つとなっています。課題は、セッション全体を通じて攻撃者の行動の証拠とアクセス決定を結びつけることで、これを実践に移すことです。Netskopeは、そのために不可欠な役割を果たします。Web、SaaS、クラウド、およびプライベートアプリケーションにわたって、組織がコンテキストに応じたアクセス決定を行い、それを徹底できるよう支援します。こうした制御は極めて重要です。
しかし、午前9時に正しいアクセス判断が下されたからといって、午前9時5分に正当な行動が取られるとは限らない。
セッションは認証されていても悪用される可能性があります。IDは認証に成功していても、侵害される可能性があります。承認されたアプリケーションであっても、コマンド＆コントロール活動を行う可能性があります。接続は暗号化されていても、攻撃の一環となる可能性があります。
だからといって、Zero Trust が失敗したということではありません。これは、私たちがアクセス制御に対して、本来意図されていない質問を投げかけてしまうことがあるということを意味しています。アクセスポリシーは、接続を許可すべきかどうかを示してくれます。しかし、それだけでは、その接続を通じて行われるすべての処理が、その後も妥当であるかどうかは判断できません。
その2つ目の質問は行動に関するものです。そして、行動は変わるものです。
攻撃者は一つの環境を把握している。なぜSOCはそうできないのか？
SaaSアプリケーションや社内サービスへの正当なアクセス権を持つリモート勤務の従業員を想像してみてください。攻撃者はその従業員のIDを乗っ取ります。そして、承認された経路を通じてログインし、利用可能なシステムを調査し、普段使用されていないサービスを利用し、より価値の高いリソースへと狙いを定めて動き始めます。
それぞれのステップを単独で見れば、ごくありふれたものに見えるかもしれません。ログインの成功。HTTPS接続。クラウドAPIへのリクエスト。新しい宛先。
ここで、アナリストの立場を考えてみましょう。セキュアなアクセスは全体の一部に過ぎません。アイデンティティ管理もまた別の側面です。ネットワーク検知もまた別の側面です。SaaSやクラウドツールが残りの部分を担っています。アナリストは統合層としての役割を担い、攻撃者が動き続ける中で、何が起きたかを手作業で再構築することになります。
私はそれを「攻撃者の発言を拾うこと」と呼ぶが、私たちに必要なのは「攻撃の全容」だ。アラートの件数よりも、防御側が次の3つの質問にどれだけ迅速に答えられるかの方が重要だ。「これは本当か？」「重要か？」「次に何をすべきか？」
NetskopeとVectra AIが共にもたらす変化
だからこそ、NetskopeとVectra AIの連携は私にとって重要なのです。単に2つのロゴを並べるだけのことでも、SOCダッシュボードにフィードをもう1つ追加することでもありません。重要なのは、アクセス許可の決定を、アクセスが許可された後に攻撃者が実際に何を行うかという情報と結びつけることなのです。
Netskopeは、セキュアなアクセス環境と制御機能を提供します。Vectra AIは、AIネイティブな行動検知機能により、 Attack Signal Intelligence 、不審な活動を特定し、関連する行動を結びつけ、調査が必要なIDやホストの優先順位を決定します。
Netskope Cloud TAP を使用すると、ポリシーに基づいて選択された、Netskope インフラストラクチャを通過する Web トラフィックを、顧客が管理するクラウドオブジェクトストレージにコピーすることができます。Netskope Stitcher は、そのトラフィックを取得し、専用の Vectra 仮想センサーに再生します。センサーはそれを処理し、分析のために拡張されたメタデータを Vectra プラットフォームに送信します。また、この統合により、観測されたリモートユーザーのアクティビティを、対応する Netskope ユーザー ID と関連付けることも可能です。
なぜそれが重要なのでしょうか？それは、VectraAIの行動分析機能により、ペイロードの復号化を必要とせずに、そのトラフィックの中から攻撃者の兆候を検知できるからです。これには、一見すると通常の暗号化された通信の中に、攻撃者が隠そうとする不審なパターンも含まれます。そして、その観測結果は、他の接続されたネットワーク、ID、クラウド、SaaSなどの情報源からの行動データと併せて評価することができます。
帰り道もあります。
Netskope Cloud Threat Exchangeとの連携により、VectraのAI検知結果から導き出されたIPアドレスやドメインなどの特定の侵害の兆候（IoC）をNetskopeと共有することができ、Netskope側では、設定済みのポリシーにおいてこれらの情報を活用して適用を行うことができます。
「観察する。理解する。優先順位をつける。行動する」。これがワークフローだ。テクノロジーは、このプロセスを容易にするものであって、アナリストにまた新たな略語だらけのコンソールを覚えさせるものであってはならない。
防御側にとって、継続的な脅威検知とは何を意味するのか
まずは、侵害されたリモートユーザーから検討しましょう。問題は、単にNetskopeがそのセッションを許可したかどうかだけではありません。その時点で入手可能な情報に基づけば、許可すべきだったはずです。問題は、その後の行動が、偵察、コマンド＆コントロール、認証情報の悪用、横方向の移動、あるいは攻撃の進行を示すその他の兆候に見え始めているかどうかです。
また、SOCチームの1日の業務についても考えてみましょう。アナリストがアクセスログ、ネットワークの証拠、ID関連のイベント、クラウドのアラートを手作業でつなぎ合わせなければならない場合、彼らは意思決定を行う代わりに、限られた時間をコンテキストの整理に費やすことになってしまいます。相関付けられ、優先順位が付けられた攻撃者の行動パターンは、彼らに調査の出発点を与え、行動を起こすための明確な根拠となります。
これは、1つの統合機能だけで、すべてのパケットを魔法のように把握したり、あらゆる攻撃を阻止したりできるという主張ではありません。Cloud TAPのカバー範囲は、Netskopeがキャプチャするトラフィックや、お客様が選択した導入方法によって異なります。また、行動検知は、セキュアアクセス、エンドポイント保護、あるいはポリシーの適用に代わるものでもありません。これらの制御機能はそれぞれ異なる役割を担っています。重要なのは、それらの役割が互いに補完し合うようにすることです。
Zero Trust を連続関数にする
私が得た教訓はこうだ。Zero Trust アーキテクチャは、セッションが承認された後も、かなり長い期間にわたって継続的な評価をサポートしなければならない。
人、デバイス、ワークロード、サービスアカウント、AIエージェントはすべて、信頼できる接続を通じて動作します。その中には、侵害されたり悪用されたりするものもあるでしょう。攻撃者は、悪意のある活動を通常の業務と見分けがつかないように見せかけ続けるでしょう。
あらゆるつながりを否定したところで、その問題は解決できません。また、あらゆるつながりをいつまでも信頼し続けたところで、その問題は解決できません。
アクセスを確実に保護し、継続的な監視を通じてその後の挙動を評価する必要があります。Netskopeは、誰が、あるいは何が、どのアプリケーションやデータにアクセスできるかを特定するのに役立ちます。Vectra AIは、アクセス後の活動が攻撃者の手口を物語り始めたタイミングを防御担当者が認識し、どの事象に注目すべきかを判断するのに役立ちます。
私がNetskopeとVectra AIの組み合わせに感じる可能性とは、まさにこれです。やみくもな信頼を減らし、脈絡のない断片的な発言を減らし、ビジネスを守る人々にとって、より迅速に状況を把握できるようにすることです。
ドアをくぐったからといって、その日一日、攻撃者に疑いの余地を与えてはならないからだ。
安全なアクセス。継続的な攻撃防御。Zero Trust が単なるアクセス制御の枠を超えた存在となるのは、まさにこのためです。