** 本記事は、Standing on the Windows platform, waiting for change の翻訳です。最新の情報は英語記事をご覧ください。**
今週、ソフォスは Microsoft の Windows エンドポイントセキュリティエコシステムサミットに参加しました。カーネルドライバーのアップデートが世界中の何百万台ものマシンをクラッシュさせた先日の CrowdStrike 事件を踏まえ、産業界と政府機関の両方から参加者が集まり、カーネルアーキテクチャ、アップデートデプロイメントプロセスなどについて議論が交わされました。そして何よりも、世界を保護するため、これまで不明瞭であった Windows のセキュリティエコシステムにどのように透明性を持たせ、コミュニティの全面的な関与のもとで進化させることができるか、というテーマについて深く掘り下げられました。今回は予備的協議であり、ポリシーの検討ではありませんでしたが、注目すべきテーマが複数浮上しました。
そのうちの 1 つは、Windows プラットフォームがどのように進化すれば、セキュリティ企業がカーネルドライバーやユーザースペースフッキング、あるいはその他のテクニックを使ってプラットフォームと俊敏かつ積極的に相互運用する必要性を減らし、同時に攻撃者がプラットフォームのコアを把握するのを防止できるのか、ということです。この目標を実現するには、業界横断的なインプットと、過去にどのような試みが成功したかという経験が鍵となります。もう 1 つのテーマはデプロイメント、つまりソフトウェアやアップデートを何百万人ものユーザーに安全に、そして混乱を最小限に抑えて提供する方法です。
今回の議論の中で、Microsoft はソフォスを優れたプラクティスおよび結果の例として挙げました。本記事では、ソフォスが現在の Windows プラットフォームとどのように相互運用しているか、およびその理由を説明します。さらに、Windows プラットフォームを進化させる (高レベルでの) 方法について説明します。これらの進化は、サードパーティのセキュリティベンダーが Windows プラットフォームとの相互運用に必要な技術とアクセスのバランスを調整するのに有用だと考えられます。また、Microsoft とソフォスの両社がサミットで議論した「安全なデプロイプラクティス」(SDP) についても説明します。本記事の最後に、Mac 製品および Linux 製品の基本的変更の管理について 3 件の経験を紹介し、今後の業界における対話の指針となる可能性を示します。
本記事は、ロードマップというよりは、現状についての背景情報と一般的な情報を提供するためのものです。防御力とセキュリティの遠大な目標達成に向けて要件を定義することは本記事の範囲を超えるものですが、慎重な議論が行われている今、脅威状況を概観する価値があります。
ソフォスがカーネルドライバーを使用する理由
他の情報セキュリティ企業と同様、ソフォスもカーネルドライバー、ユーザースペースフッキングなど、いくつかのテクニックを組み合わせて、基盤となる Windows プラットフォームとの相互運用を行っています。それぞれのセキュリティ企業には独自の方法があります。ソフォスも以前、ソフォスの手法に関する情報を公開しましたが、一般的に、最新のサイバーセキュリティ製品のユーザーの必要を満たすセキュリティ機能を提供するには、カーネルドライバーによるシステムアクセスが必要です。必要な機能には以下が含まれます。
可視化
- 現実に忠実な、ほぼリアルタイムでのシステム活動の可視化
保護
- 悪意のある行為やコンプライアンスに反する行為を単に観察するだけでなく、事前に防止する能力を提供
- 観測された悪意のある行為やコンプライアンスに反する行為に迅速に対応し、修復または復元する能力を提供
改ざん防止
- OS 自体の一部が侵害された場合でも、セキュリティ製品が設定通りに動作しているという安心感を提供
安定性/相互運用性
- セキュリティ製品をインストールしても Windows プラットフォームやサードパーティ製ソフトウェアおよびハードウェアの安定性が低下することはないという安心感を提供
パフォーマンス
- システム全体の性能与える影響が予測可能かつ許容可能な範囲内で、上記の能力を提供
低消費電力*と最新のスタンバイ機能
- 低電力モード時にも上記の機能を提供。つまり、他の活動が実行されていても、セキュリティ製品は継続的に可視化と保護を提供
* 低消費電力モード時のデッドロックを回避するため、他の Windows プラットフォーム機能が適切に動作し、依存関係を動的に解決します
現在ソフォスが使用する Windows ドライバー
ソフォスは現在 5 つの Windows カーネルドライバーを使用しています。ELAM (Early Launch Anti-Malware) ドライバー、ファイルやプロセスのアクティビティを傍受するドライバー 2 つ、ネットワークのアクティビティを傍受するドライバー 2 つです。これらのカーネルドライバーについては、以前詳しく説明しましたので、以下で要約します。要点は以下の通りです。
- ELAM ドライバーは Windows 側から要求されるドライバーです。セキュリティベンダーはエンドポイント保護 (以前用いられていた「アンチウイルス」という単語から「AV」とも呼ばれる) 製品を登録し、ユーザーデバイス上の Windows Defender を無効にするため、ELAM ドライバーを提供する必要があります。
- 2 つのファイルドライバーは、Windows API では現在利用できない詳細なプロセスジャーナリングとイベント記録のほか、改ざん防止機能、プロセスフック、ランサムウェアのブロッキングを提供します。
- 2 つのネットワークドライバーは、Web セキュリティ、侵入防止のためのパケット検査、DNS 保護、ゼロトラストネットワークアクセス用ネットワークストリームのリダイレクトを提供します。
本項目の最後で、DLL をカーネルおよびユーザースペースのプロセスに注入する方法について簡単に説明します。本記事では 5 件のドライバーそれぞれの機能を要約するに留めますが、興味のある方は上記リンク先の記事を参照されることを再度推奨します。
SophosEL.sys
SophosEL.sys は ELAM ドライバーです。Microsoft Windows を扱うすべてのセキュリティベンダーと同様に、ソフォスも AM-PPL (Anti-Malware Protected Process Light) サービスとプロセスを起動するために ELAM ドライバーを提供する必要があります。AV として登録できるのは AM-PPL プロセスだけです。前述の通り、このプロセスがユーザーデバイス上の Windows Defender を無効にします。さらに、AM-PPL プロセスには、ユーザーインターフェイスから強制終了できないなどの保護機能が組み込まれています。SophosEL.sys はブートプロセスの初期段階で Windows カーネルによってブロックされたドライバーのロードを阻止します。さらに、SophosEL.sys にはソフォス固有のコード署名証明書の「フィンガープリント」が含まれており、このフィンガープリントを利用することでソフォスは AM-PPL プロセスおよびサービスを実行できます。
SophosED.sys
SophosED.sys は上述した 2 つのファイルシステムドライバーの 1 つ目で、ソフォスのメインのマルウェア対策ドライバーです。ファイル名の「ED」は Endpoint Defense (エンドポイント防御) の略です。SophosED.sys が処理する機能には、Sophos System Protection サービス (SSPService.exe) にイベントを提供するものがあり、同期コールバック (SSPService.exe が決定を返すまで SophosED.sys は活動を一時停止します) と非同期イベント (SophosED.sys はイベントのシリアルバージョンと関連パラメータを非同期通知用のキューに追加します) が混在しています。このドライバーが処理するその他の機能は以下の通りです。
- 「シャドー」プロセス/スレッド/モジュール追跡システムをコンテキストとともに維持する
- 低レベルのシステムアクティビティイベントをソフォスのイベントジャーナルに記録し、フォレンジック調査と分析を行う
- 独立した認証メカニズムにより、ソフォスのインストールと構成プロセスを改ざんから保護する
- ソフォス由来のバイナリに対する独立した認証メカニズムを提供
- 新しく起動したプロセスに SophosED.dll を注入
- 必要な時にソフォスのネイティブアプリケーションが実行されることを起動時に確認
- ソフォスのプロセス、サービス、ドライバー間のセキュアな通信を提供、ファイルの一貫したハッシュ化、メモリスキャンのサポート
hmpalert.sys
この HitmanPro Alert ドライバーは、上述した 5 つのカーネルドライバーに含まれるもう 1 つのファイルシステムドライバーであり、CryptoGuard を実行します。このドライバーは、ランサムウェアによるファイルの一括暗号化の検出と防止、新しく起動したプロセスへの hmpalert.dll の注入などの機能を備えています。
sntp.sys
ネットワークフィルタドライバー sntp.sys は、ソフォスがネットワークフィルタリングを実装するために必要なコアネットワーク傍受機能を提供します。ファイル名の「sntp」は Sophos Network Threat Protection (ソフォスネットワーク脅威保護) の略です。このドライバーは以下の 4 機能を備えています。HTTP および HTTPS Web トラフィックをフィルタリングして、Web セキュリティ、DLP (データ漏洩防止)、Sophos Web Protection を使用した許容可能な使用ポリシーの実施を行う機能。HTTP または HTTPS Web トラフィック、DNS クエリおよびレスポンス、一般的な TLS ストリームのアクティビティを解析して、ソフォスイベントジャーナルおよび Sophos Central データレイクに記録する機能。L2 パケットを傍受および注入して、Sophos IPS (Intrusion Prevention System) を実行する機能。発信フローを一時停止/遅延させて、さらなる検査やシステム間の調整を実行する機能。
SophosZtnaTap.sys
SophosZtnaTap.sys は 2 つ目のネットワークフィルタドライバーで、ソフォス製の OpenVPN TAP ドライバーです。ソフォスはこのドライバーを使用して ZTNA (ゼロトラストネットワークアクセス) エージェントを実装します。このドライバーは DNS リクエストを傍受し、ZTNA で保護されたアプリケーションに対応する場合にはトンネル IP アドレスで応答し、IP トラフィックをアプリケーションにトンネリングします。
DLL インジェクション
ソフォスは、SophosED.sys と hmpalert.sys に実装された独自のメカニズムにより、DLL をプロセスに注入します。 現在のところ、ユーザースペースやカーネルでは、DLL インジェクションを要求するメカニズムはサポートされていません。注入された DLL は、アプリケーションによって実行される API 呼び出しの可視化と保護を提供します。
今後の指針: より安全なオペレーションに向けたステップ
以下の 2 つ のセクションでは初めにソフォスがアップデートと機能ロールアウトのプロセスで行った選択の概要を説明し、次に Windows プラットフォームがサードパーティのカーネルドライバーへの依存を減らすために (高レベルで) どのような進化を遂げることができるかを説明します。カーネルドライバーへの依存を減らすことは、価値のある目標です。
安全なデプロイ: 制御されたロールアウトと機能フラグ
前述の通り、今回のサミットでは、SDP (安全なデプロイプラクティス) が大きな議題となりました。Microsoft と同様、ソフォスも段階的なソフトウェア展開と機能フラグをサポートするために、ソフトウェアアーキテクチャに多大な投資を行ってきました。ソフォスの目標は、ソフォス製品を可能な限り安全で信頼性の高いものにすると同時に、お客様に可能な限り広範な可視性と制御を提供することです。ソフォスのプロセスや経験を Microsoft や同業他社と議論することで、Windows エコシステム全体で共有される完全かつ豊富なプラクティスが生まれると信じています。
今年掲載した記事で説明したように、ソフォスは新しいソフトウェアをリリースし、新機能を段階的に提供するための堅牢なメカニズムを進化させてきました。また、ソフォスのメカニズムにより、単一のお客様や単一のソフトウェアバージョンから全世界のユーザーに至るまで、機能を迅速に無効化できます。さらに、Sophos Central では、ソフトウェアのアップデートや構成を組織内で管理できる包括的な機能を提供しています。
独自のカーネルドライバーを使用するものであれ、Windows プラットフォームに組み込まれた機能を使用するものであれ、すべてのセキュリティ製品はシステムの動作を変更する定期的なアップデートを必要とします。上述のように動作を変更するシステムは、システムの変更が安定して機能するように、少しずつリリースされるべきです。安全なデプロイのためのベストプラクティスを共有するための議論は、私たちにとっては今回のサミットのハイライトであり、エコシステムの発展を通じてパッチやアップデートに対するお客様の信頼を大幅に向上させることにつながる分野です。この議論は、すべての人のインターネットセキュリティを強化するものでもあります。
サードパーティ製カーネルドライバーへの依存を減らす
次に、ソフォスがカーネルドライバーで実装している機能の一部を簡単に説明します。上述のように、カーネルドライバーの必要性が減少するように Windows プラットフォームを進化させる場合、これらの機能を搭載することが有効です。
繰り返しになりますが、「進化」はさまざまな利害関係者からのオープンなコミュニケーションとインプットを必要とするプロセスです。「ローマは一日にしてならず、Windows もまた然り」です。また、変更を適用する際には、攻撃者がそれぞれの変更を台無しにするかもしれないことを考慮に入れる必要があります。私たちは、議論を開始するための情報として、今回の情報を提示します。
以下は、現在使用されているすべてのプラットフォーム機能の完全なリストではありません。本記事では、私たち自身の経験に基づき、ソフォスが役立つと考える特定の機能の「最初のパス」についての説明とともに、可能性のある 8 つの進化について見ていきます。この 8 件は、さらなる議論とより正確な定義
へのきっかけとして提示されるものです。ソフォスは Microsoft と協力し、頻繁に小さな変更を繰り返し適用しながら、すべての要件を洗練させることを望んでいます。
ファイルやディレクトリへのアクセスを許可/ブロックする API
セキュリティベンダーがプロセスによってアクセスされるファイルとディレクトリを検査し、そのようなアクセスを許可/ブロックするのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。 メカニズムには、ファイルを開こうとする試みに関するイベントを受信し、その後のファイルアクセスを処理するための決定を保持・管理し、決定に対する更新や変更を管理することが含まれます。
レジストリへのアクセスを許可/ブロックする API
セキュリティベンダーがプロセスによってアクセスされるレジストリキーと値を検査し、そのようなアクセスを許可/ブロックするのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。
プロセスの動作を制御する API
セキュリティベンダーがシステム上のプロセスの活動を監視し、適切なアクションを取るのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。このような仕組みには、Windows カーネルがカーネルモードドライバーに提供するサポートを (多少の修正は必要とするでしょうが) 模倣できるでしょう。繰り返しになりますが、以下の情報は現時点では単なるガイダンスであり、網羅的なものではありません。
プロセスアクティビティコールバック: 子プロセス開始、プロセス終了、スレッド開始、スレッド終了、スレッドコンテキストセット、APC スケジュール、画像ロードなどのイベントを処理する機能。セキュリティベンダーが活動を許可またはブロックできます。
ファイルアクティビティコールバック: ファイル/ディレクトリの作成、オープン、変更、名前の変更などのイベントを処理する機能。
- たとえば、ソフォスはランサムウェアの可能性があるドキュメントの不審な変更を追跡します。ランサムウェアは、ファイルをその場で暗号化するか、暗号化されたファイルをオリジナルと一緒に作成し、オリジナルとコピーを入れ替える (オリジナルを削除し、コピーの名前をオリジナルに変更する)、またはオリジナルを書き換える (オリジナルを再度開き、暗号化されたコンテンツを上書きする) ことで、検出を回避しようとします。書き込みは、通常のファイル書き込みを使用するか、書き込み用にファイルをメモリマッピングすることで実行されます。サポートされるメカニズムは、解析が実行できるように十分なコールバックを提供する必要があります。
- 同様に、レジストリキーの作成、削除、名前の変更、リンク、キー/値のアクセス、変更などのイベントを処理し、その操作を許可またはブロックする機能も開発する価値があるでしょう。
- 新しいドライバー、ハードウェアまたはソフトウェアデバイスがインストールされるなどのイベントを処理し、インストール段階で審査する機能も役立つでしょう (不正なドライバーについては以下のセクションも参照してください)。また、ドライバーデバイスに接続するプロセスを確認し、アクセスを許可/ブロックする機能も同様です。この機能は複雑で、デバイススタックの構築や、デバイスおよびデバイスに対して IOCTL を発行するプロセスのフィルタリングを可視化する機能を含む可能性があります。
ネットワークアクセスを制御する API
最新のエンドポイント保護戦略には、ネットワーク保護も含まれます。そのため、セキュリティベンダーがネットワークデバイスを包括的に保護するのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。 任意のネットワークフローを受信・認可し、フロー内のデータを解析して潜在的に変更し、宛先との通信の前に実行する機能もメカニズムの一部に含まれるでしょう。
最新のゼロトラストデプロイメントアプローチの場合、このメカニズムには、ベンダー固有のゲートウェイを介したトラフィックの傍受とリダイレクト、DNS リクエストのフィルタリングと応答、登録されたアプリケーションへのアクセスの認証/認可、リダイレクトされたトラフィックへの認証トークンのキャプチャまたは注入などの機能も含まれる可能性があります。もちろん、これらの機能の悪用を防止するための制御も必要です。
カーネルドライバーを認可/ブロックする API
セキュリティベンダーが不正なドライバーを防ぐのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。 カーネルドライバーは AM-PPL セキュリティプロセスを含むあらゆるプロセスを終了させられるため、マルウェア攻撃でよく用いられます。
また、たとえばセキュリティ製品の API やユーザーインターフェイスを使用して動作、ドライバー、アプリケーションを認可する以外にも、セキュリティベンダーがローカルやドメインの管理者がセキュリティ製品の決定を上書きしたり、破壊したりすることを防ぐのに使用できる、サポートされたユーザースペースメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。
さらに、セキュリティベンダーが候補となるカーネルドライバーに関する詳細な情報 (ファイル名、ドライバーサイズ、ハッシュ、シグネチャなど) を受け取り、カーネルドライバーのブロックとロードを管理するのに使用できる、サポートされたメカニズムを提供することも Windows プラットフォームにとって役立つ可能性があります。
カーネルオブジェクト (プロセス、ファイル、レジストリキー、ネットワーク接続など) にコンテキストを関連付けるための API
ファイルやプロセスなどのカーネルオブジェクトについて、セキュリティベンダーが改ざん防止されたコンテキストを維持するために使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。このコンテキストには、オブジェクトが Windows の一部であるかどうか、所定のセキュリティソリューションの一部であるかどうか、または別の製品に関連するかどうかに関する情報、オブジェクトが検査されたかどうか、いつ検査されたか、どのような決定に達したかに関する情報、さらにファイルハッシュやオブジェクトの一意の識別子などオブジェクトに関連するその他の情報が含まれることがあります。リブートしてもコンテキストが保存されるように設定できれば、役立つ可能性があります。
DLL インジェクションまたは同等のメカニズム
セキュリティベンダーが DLL を注入したり、注入された DLL によって現在提供されている機能を実現したりするのに使用できるメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。現在注入される DLL は、たとえば上述のような、フッキングと低レベルでの保護の両方を提供しています。
フッキング: 注入された DLL はさまざまな API をフックし、プロセスが悪意のあるものである場合や、正規のプロセスにマルウェアが注入された場合など、プロセスコードからの API コールに関する情報を報告します。これらの API コールのいくつかは、Event Tracing for Windows (ETW) でもカバーされていますが、ETW を介して収集された情報は、効果的な保護に必要ないくつかのパラメータを欠いています。
また、ETW は常に非同期です。同期メカニズムがあると役立つ可能性があります。理想的には、どのような API コールを行うか、どのようなレベルで行うか、特定のイベントが同期か非同期かをセキュリティベンダーが制御できるべきです。 たとえば、システムコールをインターセプトするのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。
低レベルの保護: 注入された DLL は、検出/保護メカニズムも提供します。 たとえば、(マルウェアによる) フックの解除からの保護、マルウェアによるフックの防止、OS が提供する以上のメモリページ保護、API をバイパスしようとする試み (システムコールを直接使用する、PEB やリンクされた情報に直接アクセスする) の検出などがあります。
また、Windows が提供する自身の DLL の完全性 (「ユーザーモードでのPatchGuard」など) のような、新しい Windows 保護メカニズムを提供することも役立つ可能性があります。もう 1 つのオプションは、Windowsが提供する非同期コールバック (既存の Microsoft Threat Intelligence Secure ETW に類似) および同期コールバック (新しい要素) で、メモリ割り当て、スレッドコンテキストの設定、カーネルの例外 (ユーザーモードに戻される前の例外に関するコールバックなど) 処理など、プロセス内イベントに関するものです。もちろん、これらのメカニズムや類似したメカニズムは、システム性能にどのような影響を与えるかを考慮して開発されるべきです。
改ざん防止と AM-PPL
セキュリティプロセスが無効化、終了、アンインストールされないように保護する機能に使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。現在、このメカニズムは AM-PPL (ELAM ドライバーを必要とします) とソフォスのドライバーによって提供されています。ELAM ドライバーがない場合、セキュリティベンダーは保護されたプロセスの起動を許可するために、他の「信頼の起点」を必要とします。
AM-PPL によって現在提供されている保護は、セキュリティ製品が自分自身を保護する積極的な役割 (バイナリやレジストリキーを保護するなど) を果たさない限り、悪意のある攻撃者がセキュリティ製品をアンインストールしたり、改ざんしたりできるという意味で不完全です。セキュリティ製品やファイル、プロセス、レジストリキー、IPC などのさまざまなコンポーネントや機能を保護するのに使用できる、サポートされたメカニズムを提供することは Windows プラットフォームにとって役立つ可能性があります。
理想的には、この追加的なレベルの保護は、セキュリティ製品自体によってのみ (アップデート／アンインストール目的で) 放棄できるようにし、必要であれば他の手段でセキュリティ製品を削除できるようにすべきです。
一歩先へ: Mac および Linux
最後のセクションでは、それぞれ Linux と macOS で同様の問題がどのように処理されてきたかについて 3 点詳述します。これらの事例が、Windows プラットフォームに対するヒントとなるかもしれません。
Linux におけるソフォス ｰ その 1: eBPF による XDR の可視化
eBPF は、Linux カーネルでカーネル内の観測可能性フックを提供する技術です。BPF とは、元々は初期のパケットフィルタリング技術である Berkeley Packet Filter の略でしたが、この技術は現在は用いられていません。Microsoft は、eBPF for Windows を実験的に移植しています。
Linux では、ソフォスは eBPF プローブを使用して、プロセス、ファイル、ネットワークのアクティビティを監視します。このプローブは情報を収集し、基本的なステートレスフィルタリングを実行します。ユーザースペースはイベントのストリームを操作し、アクティビティを分析します。
eBPF の主なセキュリティ機能は検証プロセスです。eBPF プログラムがバイトコードにコンパイルされ、カーネルにロードされるためには、さまざまな制約を守る必要があります。たとえば、Linux は文字列パターンマッチング関数を提供していませんし、この関数は検証プロセスの複雑性に関する制限により eBPF バイトコードに実装できません。Linux eBPF kprobes はアトミックコンテキストで実行され、ページング不可能なカーネルメモリにのみアクセスできます。
これらの制約により、eBPF for Windows が上記のようなユーザースペースの「認可/ブロック」インターフェイスを支援するのは困難です。しかし、eBPF for Windows はカーネル内のシステムアクティビティイベントを動的に収集し、事後分析のためにユーザースペースに送信するためのソリューションとなり得ます。
Linux におけるソフォス ｰ その 2: Fanotify を使用したファイルスキャン
バージョン 5.1 以降、Linux にはファイル操作を傍受するための fanotify API が搭載されています。ソフォスは当初、オンアクセスファイルスキャン機能を実装するために Linux カーネルドライバー (Talpa) を使用していましたが、アーリーアダプターとして fanotify に移行しました (さらに、今日の標準へと発展させることに貢献しました)。現在、最新の Linux 用ソフォス製品は、fanotify を使用して非同期にファイルイベントを収集し、必要に応じてバックグラウンドでファイルをスキャンし、スキャン結果に基づいて対応アクションをトリガーします。
fanotify への移行は、ソフォスにとって大きな投資が必要でした。異なる Linux ディストリビューションベンダーが、異なるリリースサイクルで fanotify をサポートしたカーネルを提供したため、ソフォスは Talpa カーネルドライバーと fanotify 実装の両方をサポートし続ける必要がありました。ソフォスが一貫したインターフェイスを使用できるようになるまでには、fanotify を使用したカーネルへの変更が様々な Linux ディストリビューションに浸透する必要がありました。 Microsoft プラットフォームのエコシステムでは、さまざまなバージョンの OS が使用されています。 Windows プラットフォームへの変更を検討する際には、この事実を考慮に入れることが重要かもしれません。
macOS におけるソフォス: macOS Big Sur と kexts
Apple は、新しいエンドポイントセキュリティ API を、使用を義務付ける1年前に導入しました。ソフォスは kexts (macOS のカーネル拡張機能) から新しい API への移行に 1 年もの時間を費やしましたが、お客様はその間 kexts を使用したバージョンの OS とセキュリティ製品を継続的に受け取り、実行し続けました。次の macOS のメジャーリリースでは、すべてのベンダーへのカーネルアクセスが削除されました。ここでも、異なるバージョンの OS へのアップデートを管理し、ユーザーが OS をアップデートする際にセキュリティソリューションのアップデートと設定をスムーズに行えるようにすることに伴う問題を検討するのが役立つ可能性があります。 さらに、どのような道を歩むにせよ、Windows エンドポイントエコシステムの好ましい進化を促すことを期待して、この事例の要点を振り返ります。
- リリース当初、Apple のエンドポイントセキュリティ API は製品のコンテキストで kexts を置き換えられませんでした。そのため、製品に API を使用できず、実環境での経験が積めませんでした。
- Microsoft の Canary チャネルや Dev チャネルとは対照的に、新しいリリースはすべての Apple Insiders に同時に配信されました。
- Apple は API に関する詳細な計画、推奨事項、開発者ガイドラインを共有しませんでした。
- 多くの重要なエンドポイントセキュリティAPIがベータサイクルの後半にリリースされ、不具合が報告されたため、ステータスを検証するためにリリースのたびに再テストが必要となりました。
- Apple はセキュリティベンダーに対し、OS の一般提供がいつになるのか、ガイダンスも事前通知も行いませんでした。
- Apple は、カーネル API を引き続き利用する機能を提供していますが、そのためには同時にユーザー側で複数の重要な OS セキュリティ機能を無効にする必要があります。そのため、ユーザーもベンダーもレガシーカーネル API を使い続けるのではなく、エンドポイントセキュリティ API に切り替えるようになりました。これらのカーネル API へのアクセスを可能にする単一の「スイッチ」を提供するという別のアプローチでは、同じ効果は得られなかったかもしれません。
結論
変化は容易ではありません。しかし、最近のサイバーセキュリティイベントや、現在のソフトウェアのトレンドからも分かるように、避けられるものでもありません。今週の Microsoft サミットで行われた議論の成果が明らかになるのは数か月後または数年後かもしれません。また、このサミットでもたらされるかもしれない変化の中には、抜本的ゆえに破壊的なものになるものもあるでしょう。また、エンドポイントセキュリティエコシステム全体が使用できるように OS ネイティブのセキュリティインターフェイスの拡張セットを Windows がネイティブで提供することのメリットと、今日のエンドポイントセキュリティエコシステムが持つ独自のイノベーションとコントロールの多様性を犠牲にするモノカルチャーリスクを比較・検討する必要があります。とはいえ、透明性とオープンなコミュニケーションは、防御者とお客様の双方にとって迅速に成果を向上させる最善の方法だと考えています。いますぐ始めましょう。
コメントを残す