見えないAIが企業ネットワークの資産台帳を上回る

KnowBe4は、古くからあるセキュリティ上の前提に改めて疑問を投げかけている。承認済みの資産台帳があっても、稼働中のすべての資産が把握されていることの証明にはならない。Google Newsの記事は、従来の記録では見落とされうるAIサービス、隠れたデバイス、その他の資産に焦点を当てている。この組み合わせにより、管理上の弱点が現実のセキュリティ問題へと変わる。

重要な対立は、あるセキュリティベンダーと別のベンダーとの間にあるのではない。静的な記録と継続的な証拠の間にある。調達データベースは組織が所有していると認識するものを示す一方、ネットワーク、エンドポイント、ID、ブラウザのテレメトリーは、人々が実際に利用しているものを明らかにする。

AI機能がソフトウェア、ブラウザ拡張機能、アプリケーション・プログラミング・インターフェース、既存の生産性スイートに広がるにつれ、この隔たりは拡大している。あるサービスは、個別に購入される製品として導入されないこともある。アップデート、個人アカウント、APIキー、従業員所有のデバイスを通じて現れる可能性がある。

したがってKnowBe4の主張は、通常の資産管理を超える。セキュリティチームは物理ハードウェアと並行して、ソフトウェアの振る舞い、データの移動、ID、外部サービスを発見しなければならない。同時に、通常とは異なる接続をすべて悪意あるものとして扱わない必要もある。

Google Newsの記事が示す、より広範な資産台帳の失敗

中核となる変化は単純だ。セキュリティ資産台帳は、承認された所有関係だけでなく、観測された活動を記述しなければならない。

Google Newsの記事は、この問題を3つの資産クラスを通じて提示している。AIツールは外部サービスと組み込みソフトウェアを表す。隠れたデバイスは通常の登録手続きを回避したハードウェアを表す。未知の資産は、テレメトリーでは見えるが信頼できる記録には存在しない、残りすべてを指す。

これらのクラスは重なり合うが、それぞれ異なる問いを生む。個人所有のノートPCが、未管理ブラウザを通じて承認済みのAIサービスへアクセスすることがある。承認済みノートPCが、API経由で未承認のモデルを利用することもある。認可された生産性プラットフォームが、個別の購買手続きを経ずに新しいAI機能を有効化する場合もある。

従来の資産台帳では、ノートPCと生産性スイートは記録できても、リスクのある行動を見落とす可能性がある。AIベンダーを記録していても、どの従業員が利用しているかまでは示せないかもしれない。どちらの記録も、どのデータが境界を越えるのかを説明しない。

これが、デバイス一覧だけでは現代のリスク判断を支えられない理由である。セキュリティチームには、ユーザー、エンドポイント、アプリケーション、ID、データ、宛先を結び付ける関係マップが必要だ。各観測結果は、対処可能になる前に文脈を必要とする。

この問題は生成AIにとどまらない。カメラ、プリンター、研究設備、ビル制御、仮想マシン、コンテナ、一時的なクラウドリソースも、手作業の記録から漏れる可能性がある。標準的な管理エージェントを持たないものもある。次回の定期レビュー前に短期間だけ現れ、消えるものもある。

NISTはこのより広い範囲をCSF 2.0で正式に示した。その資産管理の成果には、ハードウェア、ソフトウェア、システム、サービス、サプライヤー、データ、ネットワークフローが含まれる。このフレームワークは、識別を年1回の棚卸しではなく、継続的なリスク管理としても扱っている。

この違いは重要だ。未知であることは、敵対的であることを意味しない。新たに観測されたデバイスは、文書化待ちの正規交換機である可能性がある。見慣れないドメインは、承認済みベンダーのコンテンツ配信システムに属するかもしれない。AI関連のエンドポイントは、従業員が意識的に有効化したことのない機能を支えている可能性もある。

したがって、発見プロセスは分類のためのキューを作るべきだ。自動的に処罰や隔離を引き起こしてはならない。チームには、所有者、目的、機密性、事業上の重要性を判断するための十分な証拠が必要である。

KnowBe4の見出しが機能するのは、こうした事例を一つの居心地の悪い問いに集約しているからだ。防御側は、名前すら把握できない資産を保護できるのか。その答えは、別のスキャナーを購入することよりも、複数の不完全な視点を照合できるかどうかにかかっている。

Shadow AIはセキュリティチームに両面から圧力をかける

セキュリティリーダーは、有用な業務を妨げたり過度な従業員監視を生んだりせずに、未承認のAI利用を明らかにするよう求められている。

Shadow AIとは、組織の承認済み技術プロセスの外で利用されるAIサービスまたは機能を指す。この用語は、従業員が公開チャットボットを訪れること以上の範囲を含む。個人のAPIアカウント、コーディング支援ツール、ブラウザ拡張機能、組み込み機能、ローカルハードウェア上で動作するモデルも対象となる。

それぞれの経路は異なる証拠を残す。ブラウザからのアクセスは、Webログやドメイン名ログに現れることがある。API活動は、クラウド、リポジトリ、シークレット管理の記録に現れる可能性がある。ローカルモデルは、ファイルが到着した後は外部接続をまったく発生させない場合もある。

この断片化により、セキュリティチームは二つの要求の間に置かれる。経営層は、機密情報が外部システムに入る可能性があるため、信頼できるAI資産台帳を求める。従業員は、調査、下書き、コーディング、分析、コミュニケーションを支援するツールへのアクセスを求める。

包括的な遮断は明確な方針をもたらすが、運用上の可視性は弱い。人々は個人デバイス、モバイル接続、あるいは馴染みの薄いサービスに切り替えられる。その結果、組織は利用状況を把握し、行動を導き、より安全な代替手段を提供する機会を失う。

無制限のアクセスは、反対の問題を生む。従業員は、顧客情報、契約書、ソースコード、会議メモ、社内戦略を、保持ルールが十分に理解されていないサービスへ送信できてしまう。評判の高いプロバイダーであっても、特定のデータ区分には不適切である可能性がある。

MicrosoftのAI app discoveryガイダンスは、行動レベルの制御への移行を示している。そこでは、アクセス、アップロード、貼り付けられたコンテンツ、その他のリスクの高い操作に対する可視性が説明されている。これは、調達リストにアプリケーションが載っているかを確認することとは異なる作業だ。

IDはさらに別の層を加える。会社アカウントと個人アカウントは、同じエンドポイントを通じて同一サービスにアクセスできる。ドメインレベルの監視は宛先を特定できても、適用される契約、保持設定、利用者の権限までは特定できないことがある。

組み込みAIは分類をさらに複雑にする。馴染みのあるアプリケーションが、通常のアップデートを通じて要約、文字起こし、予測、コンテンツ生成を追加する場合がある。基盤となる製品は承認済みのままでも、そのデータ処理の振る舞いは変化する。

そのため、セキュリティチームは関連する二つの資産台帳を維持するよう求められる。第一は技術資産とサービスを対象とする。第二は、承認済みのユースケース、データ区分、ID、所有者、制御要件を対象とする。

この第二の台帳をセキュリティ部門だけが担うことはできない。調達部門は契約を把握している。法務部門は利用規約を理解している。プライバシーチームはデータ処理を評価する。部門責任者は従業員がツールを必要とする理由を知っている。プラットフォーム所有者は設定とログ記録を理解している。

求められる対応は、技術面だけでなく組織面にも及ぶ。セキュリティは、発見結果を所有権に関する判断へ変換する再現可能なプロセスを構築しなければならない。そうでなければ、検知システムはガバナンスを生まないアラートを出し続けるだけになる。

従業員には、利用しやすい報告経路も必要だ。有用なAI機能を見つけた従業員は、自動的に却下されると予想せずにレビューを申請できるべきである。このプロセスにより、需要が完全に管理外の経路へ移る前に可視化される。

AI導入の変化は年次レビューの周期より速いため、この圧力は続くだろう。四半期ごとの資産台帳でも、数日以内に社内で数千件のやり取りを獲得したサービスを見逃す可能性がある。継続的な発見は、より迅速な承認および是正プロセスにつながらなければならない。

継続的な証拠が静的な資産一覧に取って代わる

成功するアプローチは、複数の不完全なシグナルを組み合わせ、その間の不一致を測定する。

単一のセンサーで、すべての資産を特定することはできない。アクティブスキャンは到達可能なシステムを調べるが、センシティブな運用設備を妨害する可能性がある。パッシブ監視はトラフィックを安全に観測するが、通信しないデバイスは見えないままになることがある。エンドポイントエージェントは詳細を提供するものの、未管理ハードウェアにはそうしたエージェントが存在しない。

信頼できる発見プログラムは、各ソースを部分的な証拠として扱う。ネットワーク記録は接続を示す。IDシステムはアカウントと認証を示す。エンドポイントプラットフォームは、インストール済みアプリケーション、プロセス、拡張機能、ローカルファイルを示す。クラウドのコントロールプレーンは、リソースとサービス間の関係を示す。

調達データベースと構成管理データベースも依然として重要である。これらは所有者、契約、ライフサイクル、事業上の文脈を提供する。弱点は無用であることではない。現在の振る舞いではなく、意図を記述していることが多い点にある。

最初の実務的なステップは、信頼できる期待値を定義することだ。チームには、承認済みデバイス、サービス、ID、AIツール、データ区分、ネットワーク経路の一覧が必要である。これらの一覧はベースラインを形成するが、唯一の現実の記述になってはならない。

第二のステップは、観測結果を継続的に収集することだ。DHCPとアドレス解決の記録は、接続されたハードウェアを明らかにできる。ドメイン名とプロキシのログは、外部サービスを明らかにできる。認証ログは、活動をIDに結び付けられる。エンドポイントデータは、通信を開始したプロセスを特定できる。

クラウド環境には、独自の発見経路が必要である。リソースは自動化によって現れ、ワークロードの完了後に消えることがある。コンテナ、サーバーレス関数、マネージドデータベース、一時的な開発環境は、従来のデバイスのようには見えない可能性がある。

AI利用は、アプリケーション層の証拠を追加する。チームは、既知のサービスカテゴリ、ブラウザ拡張機能、OAuth許可、モデル関連のAPIキー、外部宛先への異常な転送を探せる。また、承認済み製品のうち、最近AI機能を追加したものも確認できる。

第三のステップは照合だ。観測されたすべてのオブジェクトは、期待される記録と突き合わせるべきである。期待されるすべての記録には、依然として存在することを示す最近の証拠が必要だ。不一致が作業キューになる。

このキューには明確なカテゴリが必要である。資産は、承認済みかつ文書化済み、承認済みだが未文書化、未承認だが無害、疑わしい、またはすでに存在しないものに分類できる。未知は恒久的な保留領域ではなく、一時的な分類であるべきだ。

優先順位は露出と影響に従うべきである。未知のインターネット公開ゲートウェイは、隔離されたテストデバイスよりも迅速なレビューに値する。規制対象データを受け取るサービスは、公開済みマーケティング文書を処理するサービスよりも大きな注意を要する。

運用技術には、より慎重な対応が必要だ。これらのシステムはしばしば長いライフサイクル、専門的なプロトコル、アクティブスキャンに対する限られた耐性を持つ。複数機関によるOT inventory guidanceは、文書、物理的な点検、ネットワーク由来の情報を組み合わせることを推奨している。

このガイダンスは、デバイスの役割、ホスト名、ネットワークアドレス、メーカー、モデル、オペレーティングシステム、場所、プロトコル、ポート、サービス、ユーザーアカウントなど、有用な属性も示している。これらの属性は、観測されたアドレスをリスク判断へ変換するのに役立つ。

この仕組みは、成功の測定方法を変える。大規模な資産台帳が自動的に優れた資産台帳になるわけではない。有用なプログラムは、カバレッジ、鮮度、照合時間、所有者、未解決の未知資産の経過期間を測定する。

既知の資産が変更後にどの程度「未知」になるかも追跡すべきです。この指標により、オンボーディング、オフボーディング、調達、設定の各プロセスにおける不備が明らかになります。検出を通じて、そのギャップを生んだシステムを改善できます。

目指す結果は、完璧な可視性ではありません。変更を検知し、不確実性を記録し、責任を割り当てる、説明可能なプロセスです。そのほうが、正確性を誰も証明できない見栄えのよいスプレッドシートより価値があります。

AIツールと隠れたデバイスは異なる痕跡を残す

未知の資産は、チームが資産タイプに応じてそのシグナルを調査すれば管理可能になります。

隠れた物理デバイスは通常、ネットワーク層の証拠を残します。アドレスを要求し、名前を解決し、サービスを通知し、ピアと通信し、または外部の宛先へ接続します。ハードウェアアドレスからメーカーを推定できる場合もありますが、その手掛かりは決定的ではありません。

チームは次に、具体的な質問を投げかけられます。どのネットワークセグメントで観測されたのか。いつ初めて出現したのか。一定のスケジュールで再び現れるのか。どのプロトコルを使用しているのか。そのトラフィックはプリンター、カメラ、電話、サーバー、コントローラーのどれに似ているのか。

ネットワークアクセス制御では、認証を必須にしたり、見慣れないデバイスを制限付きセグメントに配置したりできます。ただし、隔離では業務への影響を考慮すべきです。文書化が不十分でも、未知の医療機器、製造機器、建物制御デバイスが重要な機能を支えている可能性があります。

未知のクラウド資産は、別のパターンを示します。アカウント、所有者タグ、デプロイメントテンプレート、サービスIDを持っているかもしれません。調査担当者は、その作成イベントをユーザー、自動化パイプライン、チケット、リポジトリ、またはプロジェクトに結び付けるべきです。

隠れたAIサービスは、宛先が見えていてもユースケースが不明瞭なため、分類がより困難になる場合があります。モデルプロバイダーのドメインが見えても、ユーザーが公開テキストを送信したのか、機密性の高いソースコードを送信したのかまでは分かりません。

ブラウザーとエンドポイントのコンテキストは、そのギャップを埋める助けになります。管理対象ブラウザーなら、閲覧、アップロード、貼り付けたコンテンツ、ダウンロード、アカウント種別を区別できます。エンドポイント制御は、発信元アプリケーションを特定し、情報の機密性に応じたルールを適用できます。

APIベースの利用には異なる証拠が必要です。セキュリティチームは、シークレットストア、ソースリポジトリ、継続的インテグレーションシステム、クラウドゲートウェイ、経費記録、外向きサービスコールを調べるべきです。個人用キーは、中央管理されたアカウントや利用制限を回避できてしまいます。

OAuthの付与にも注意が必要です。OAuthにより、あるサービスがユーザーに代わって別のサービスにアクセスできます。メールボックス、カレンダー、ドライブ、リポジトリにアクセスできるAIアシスタントは、新しいデバイスがなくても重要な資産関係になり得ます。

ローカルモデルは、可視性の問題を逆転させます。推論アクティビティはエンドポイント内にとどまる可能性がありますが、モデルのダウンロードや支援ツールは観測可能なイベントを生み出します。ストレージ使用量の増加、パッケージのインストール、プロセス実行、GPU利用は、有用なコンテキストを提供できます。

組み込み機能にはベンダーレビューが必要です。チームは、承認済みアプリケーションについて、リリースノート、管理設定、サブプロセッサー、契約変更を監視すべきです。既知のベンダーでも、馴染みのある製品名を変えずに新たなデータ経路を導入することがあります。

ナレッジワーカーは、文書化においても課題を生みます。1つのタスク中に複数のツールを組み合わせ、会議レコーダー、チャットボット、文書エディター、プロジェクトプラットフォームの間でコンテンツを移動させることがあります。各ツールが承認済みであっても、その組み合わせたフローがポリシーに違反する可能性があります。

明確なAIナレッジベースを維持することで、チームは承認済みワークフロー、所有者、証拠、データ境界を文書化しやすくなります。文書化は、技術的な観測を置き換えるのではなく、調査を支えるものであるべきです。

分類プロセスはアクションで終えるべきです。承認済み資産は管理対象インベントリに登録します。不必要なサービスはアクセスを失います。設定不備のツールには、より安全な設定を適用します。不審なシステムはインシデント対応へ移行します。不明確なケースは、所有者が現れるまで制限付きアクセスを維持します。

このアプローチは、すべての未知のものを同等に扱うことを避けます。また、スキャナーが名前を出力した時点で資産検出が完了するわけではないことも認識しています。組織は、目的、制御、データ露出を理解しなければなりません。

可視性の向上そのものがセキュリティとプライバシーのリスクになり得る

収集が明確に定義されたセキュリティ目的を超えると、継続的な検出は逆効果になります。

広範な監視に対する最も強い異論は、プライバシーに関するものです。ブラウザー、エンドポイント、ID、ネットワークの記録は、従業員の行動をかなり詳細に明らかにし得ます。これらの記録を組み合わせると調査価値は高まりますが、誤用の可能性も増します。

組織は、何を収集するのか、なぜ収集するのか、誰がアクセスできるのか、どのくらい保持するのかを定義すべきです。シャドーAIプログラムは、セキュリティに関連するイベントに焦点を当てるべきです。従業員の活動をランク付けする一般的なシステムになってはなりません。

個人用デバイスは、特に難しい境界を生みます。企業は、従業員のデバイス全体への可視性を主張せずとも、企業データへのアクセスを管理できます。管理対象アプリケーション、保護されたワークスペース、条件付きアクセスは、その分離を保つことができます。

誤検知も別のリスクです。共有インフラ、コンテンツ配信ネットワーク、ベンダー統合、バックグラウンドサービスによって、通常のトラフィックが見慣れないものに見える場合があります。ドメインやラベルに基づく自動ブロックは、正当な業務を中断させかねません。

分類データベースも急速に古くなります。新しいAIサービスが登場し、ベンダーは製品名を変更し、既存のプラットフォームにはモデルを利用した機能が追加されます。静的なベンダーリストに依存する検知ルールでは、新サービスを見逃し、旧サービスを誤分類します。

暗号化はネットワーク検査を制限します。ゲートウェイは多くの場合、宛先と接続メタデータを確認できますが、ユーザーが何を送信したかを常に判断できるとは限りません。トラフィックの復号は可視性を高める一方で、プライバシー、証明書、パフォーマンス、運用上の懸念を生み出します。

エンドポイント監視は一部のギャップを埋めますが、カバレッジの問題ももたらします。請負業者、管理されていないシステム、モバイルデバイス、専門機器にはエージェントがない場合があります。セキュリティチームは、部分的なカバレッジを確実性として示すのではなく、こうした死角を報告すべきです。

検出と制御を同一視することにもガバナンス上のリスクがあります。AIサービスを見つけても、その利用が必要だったのか、非公式に承認されていたのか、既存の契約の対象だったのかは分かりません。技術的な証拠には、責任を負う事業上の所有者が必要です。

したがって、KnowBe4の枠組みは、すべての未特定資産が危険であることの証明ではなく、可視性に関する警告として扱うべきです。提供されたソースは、測定された侵害、普遍的な検知率、または問題を解決する単一製品を立証していません。

NISTのフレームワークは重要な抑制を提供します。組織に対し、分類、重要度、リソース、ミッションへの影響に基づいて資産の優先順位を付けるよう求めています。これにより、チームがすべての異常に同じ労力を費やすことを防げます。

成熟したプログラムは、センサーの限界も測定します。各レポートには、どのネットワーク、エンドポイント、ID、クラウドアカウント、リモートユーザーが対象だったかを示すべきです。観測されなかったことと、実際に存在しないことを区別する必要があります。

セキュリティチームは、統制された演習を通じて自らの主張を検証できます。承認済みのテストデバイス、一時的なクラウドリソース、ブラウザー拡張機能、AI APIコールを導入できます。目的は、どのシグナルが各ケースを検知するのか、そしてアナリストがどれほど速く分類できるのかを測定することです。

これらのテストには、障害条件も含めるべきです。デバイスが沈黙を保つと何が起きるのか。個人用APIトラフィックは管理対象ゲートウェイを回避できるのか。組み込みAI機能は別個のサービスとして現れるのか。チームはそのデータ所有者を特定できるのか。

答えは環境によって異なります。まさにこのばらつきが、組織が完全な可視性を主張すべきでない理由です。説明可能な目標は、測定可能なカバレッジ、既知の死角、そして着実に短くなる不確実性の期間です。

ネットワーク検出が追いついているかを示す3つのシグナル

次の試験は、組織がより多くのテレメトリーをより迅速で安全な意思決定に変換できるかどうかです。

1つ目のシグナルは、照合速度です。チームは、最初の観測から分類までの時間を測定すべきです。時間が短いほど、検出、所有権、対応のプロセスが連携して機能していることを示します。

この指標は、資産クラスごとに分けるべきです。物理デバイス、クラウドリソース、SaaSアプリケーション、AI API統合には、それぞれ異なる証拠が必要です。これらを1つの平均値にまとめると、深刻な遅延を隠すことがあります。

照合時間が短縮され、誤検知が管理されたままであれば、継続的証拠モデルは支持を得ます。アナリストが解決できる速度を上回ってキューが増えるなら、追加のセンサーは有用な可視性ではなくノイズを生み出しています。

2つ目のシグナルは、組み込み型およびAPIベースAIのカバレッジです。多くの制御は、ブラウザートラフィックのほうが特定しやすいため、Webサイトカテゴリーから始まります。その結果、個人用キー、開発者ワークフロー、ローカルモデル、承認済みプラットフォーム内のAI機能が取り残されます。

組織は、ネットワークログからの検出結果を、エンドポイント、ID付与、クラウドシステム、リポジトリ、ベンダーレビューによる調査結果と比較すべきです。大きな不一致は、監視アーキテクチャがどこで不完全なままであるかを明らかにします。

より広いカバレッジは、KnowBe4の根底にある警告と、ここで提案する対応を強化します。Webドメインリストへの依存が続けば、企業がAIへの露出を理解しているという主張は弱まります。

3つ目のシグナルは、ガバナンスがユニバーサルブロッキングを標準にすることなく迅速化するかどうかです。セキュリティチームには、有用なサービスを未知の状態からレビュー済み・承認済みへ移せるという証拠が必要です。また、リスクの高い利用をID、データクラス、機能によって制限できるという証明も必要です。

健全な承認プロセスには、指名された所有者、定義された証拠要件、明確な意思決定時間が必要です。要求されたサービスがポリシーを満たせない場合には、より安全な代替案を提示すべきです。沈黙や無期限のレビューは、従業員が制御を迂回することを促します。

ベンダーが管理設定、監査イベント、モデルの宛先、データ保持の選択肢をどのように公開するかに注目してください。より優れた製品テレメトリーにより、組み込みAIのガバナンスは容易になります。ログが限定的であれば、顧客は間接的なネットワーク上の手掛かりに依存せざるを得ません。

このGoogle Newsの記事から得られるより広い教訓は、目に見えないすべての資産が悪意を持つということではありません。未解決の資産はすべて、所有権、アクセス、データ、責任に関する未回答の問いを表しているということです。

セキュリティリーダーは今四半期、実務的な1つの問いを投げかけるべきです。記録されていないデバイスまたはAIサービスは、誰かが所有者を割り当てるまでどれほど稼働できるのか。そして、統制された例でその答えを検証すべきです。

結果が数週間単位なら、組織には依然として静的インベントリの問題があります。文書化された証拠と適切な制御を伴って数時間単位であれば、検出は運用上のセキュリティ能力になりつつあります。

次の一手は明確です。1つのネットワークセグメント、1つのクラウド環境、1つの利用頻度の高い従業員ワークフローを選びます。想定される記録を観測されたアクティビティと照合し、すべての不一致を分類して、死角を記録します。この演習は、また1つのインベントリスプレッドシートより多くを明らかにし、組織が既存の制御では見えないものを本当に可視化できるかを示します。