攻撃者は、防御側の手を煩わせることを好みます。攻撃者が検知されずに活動するための最も効果的な手口の1つは、侵害されたデバイスのセキュリティツールを無効にすることです。

時には、ユーザーが当事者に代わって面倒な作業をこなしてくれることもあります。業務の妨げになっていると感じたユーザーが、いら立ちからセキュリティサービスを無効にしてしまうと、攻撃者に同じ機会を与えることになります。アップデートの失敗など、意図しないアクションも同様です。

残念ながら、多くの防御担当者は、重要なセキュリティツールが実行されているかどうかの確認も怠っており、その結果、重大なブラインドスポットを生み出しています。多くの組織は、定期的なコンプライアンスチェックに頼っていますが、これでは監査と監査の間に大きなギャップが生じてしまいます。セキュリティツールが機能していたかどうかを組織が知るのは、侵害が起きて手遅れになった後、というケースがあまりにも多いのが現状です。

このたび、macOSおよびWindows向けのOkta Verifyクライアントに高度なポスチャチェック機能が導入されることになりました。この機能により、すべての認証フローが永続的なツーリングウォッチドッグに変わります。アカウントが認証を試みた瞬間にosquery SQLクエリを実行することで、管理者は必須のセキュリティツールが展開されているだけでなく、アクティブに実行されていることも確認できます。防御機能がなければ、デバイスはアクセスできません。

以下では、この機能の活用方法について見ていきますが、まずはその重要性からご説明します。

見過ごされているギャップ

ほとんどの組織では、EDRエージェントからMDMデバイス、さらにはそれ以上のものに至るまで、すべての管理対象エンドポイントに搭載すべきツールが明確にリスト化されています。導入されるツールの組み合わせは組織によって異なりますが、各カテゴリーのセキュリティツールは、十分に防御された環境に不可欠な一貫した目的を果たします。

問題は、何かを展開したからといって、それがまだ実行されているとは限らないことです。エージェントがクラッシュしたり、サービスが無効になったりすることがあります。ノートPCの動作を速くしたいユーザーが原因の場合もあれば、最初に強制終了すべきプロセスを正確に把握しているマルウェアが原因の場合もあります。VPNクライアントがサービスを中断させる更新プログラムをリリースしたものの、チームがその問題に気付いたのは数週間後、ヘルプデスクのチケットにあるパターンが見られてからでした。プロセスの不在を具体的に探していない限り、通常の監視ではこうした問題は検出されず、ほとんどのチームはそこまで行っていません。

こうした問題は、ほとんどのコンプライアンスチェックがセキュリティツールの存在を一度しか検証せず、その後コンプライアンス違反の状態に陥っても再検証しないという事実によって、さらに深刻化します。高度なポスチャチェックでは、この仕組みが逆になります。チェックは認証イベントごとに実行されるため、午前9時に実行を停止したツールは、午前9時5分にユーザーのアクセスを拒否する結果となります。

実環境における防御機能の無力化

攻撃者は、セキュリティオペレーションを無力化できれば、それだけで大きな目的を達成したも同然だと熟知しています。こうした行為はあまりにも蔓延しているため、MITRE ATT&CKには防御機能の無効化と呼ばれる戦術が存在し、18種類の技術で構成されています。最も一般的な技術の1つはT1685:ツールの無効化または変更です。これについては、以下のOktaのツール監視クエリで焦点を当てています。

攻撃者は多くのカテゴリーのセキュリティツールを無効化しますが、ランサムウェアの侵入時にはEDRキラーの使用が一般的になっており、多くの場合、攻撃者は暗号化の前にEDRを無効化します。例えば、Gentlemenランサムウェアのオペレーターは、osqueryd.exeなどのテレメトリプロセスを無効にするために、自らの「GentleKiller」マルウェアを利用します。同様に、Reynolds ランサムウェアは、Bring Your Own Vulnerable Driver(BYOVD)という手法を使用します。脆弱なドライバーを悪用して、さまざまなプラットフォーム上のローカルEDRエージェントのプロセスを強制終了させます。ツールが無効になっているデバイスが保護されたリソース(アプリとデータ)に認証できないようにすることで、攻撃者がデータを暗号化する前に阻止できます。

ウォッチドッグパターン

この記事でご紹介する検出クエリは、ユーザーのデバイスに対する「デジタルヘルスチェック」としてこの問題に対応します。このクエリはokta/customer-detectionsリポジトリでご確認いただけます。クエリは、単一のプロセスを探すだけでなく、スコアカードのように機能します。このクエリでは、必須のセキュリティツールカテゴリごとにアクティブに実行されているとデバイスに1ポイントが付与され、合計スコアが目標に達した場合にのみ、そのデバイスは「合格」となります。各セキュリティツールカテゴリには、それぞれに共通テーブル式(CTE)が割り当てられています。関連するプロセスが現在アクティブな場合は1を、そうでない場合は0を返します。最終結果ではすべてのカテゴリが集約され、必須ツールがすべて確認された場合にのみ認証が許可されるようになります。

デバイスがどのように評価されるかの例を以下に示します…

テレメトリーは渡されていますか?はい、スコアは1です
デバイスでEDRが実行されていますか?はい、スコアは1です
デバイスでMDMが実行されていますか?はい、スコアは1です
デバイスでDLPが実行されていますか?はい、スコアは1です
デバイスでVPN/ZTNAが実行されていますか?いいえ、そのためスコアは0です
デバイスでDNSセキュリティが実行されていますか?はい、スコアは1です
デバイスで脆弱性管理が実行されていますか?はい、スコアは1です

結果:7件中6件が失敗!そのため、デバイスはアクセスを許可されません。

7つのカテゴリがあり、それぞれがmacOSとWindowsに対応するその分野の主要ベンダーを対象としています。

WITH telemetry_running AS (
    -- Fleet Orbitスーパーバイザー + osqueryデーモン
    SELECT COALESCE(COUNT(*), 0) AS total
    FROM processes
    WHERE name IN ('osqueryd', 'orbit', 'osqueryd.exe', 'orbit.exe')
),
edr_running AS (
    -- CrowdStrike Falcon | SentinelOne | VMware Carbon Black Cloud |
    -- Microsoft Defender for Endpoint | Elastic Security | Palo Alto Cortex XDR |
    -- FireEye/Trellix | Sophos | Trend Micro | ESET
    SELECT COALESCE(COUNT(*), 0) AS total
    FROM processes
    WHERE name IN (
        'com.crowdstrike.falcon.Agent', 'CSFalconService.exe', 'falcon-sensor',
        'SentinelAgent', 'SentinelAgent.exe', 'sentineld',
        'cbagentd', 'CbDefense.exe',
        'wdavdaemon', 'MsMpEng.exe', 'MsSense.exe',
        'elastic-agent',
        'CyveraConsole', 'CyServer.exe',
        'xagt', 'xagt.exe',
        'SophosScanD', 'SAVAdminService.exe',
        'iCoreService', 'Ntrtscan.exe',
        'esets_daemon', 'ekrn.exe'
)
),

残りの5つのCTEも、MDM、DLP、VPN/ZTNA、DNSセキュリティ、脆弱性管理について同じパターンに従います。これらはすべて、1つのスコアリングステップに集約されます。

final_score AS (
    SELECT
        CASE WHEN telemetry_running.total > 0 THEN 1 ELSE 0 END
        + CASE WHEN edr_running.total > 0 THEN 1 ELSE 0 END
        + CASE WHEN mdm_running.total > 0 THEN 1 ELSE 0 END
        + CASE WHEN dlp_running.total > 0 THEN 1 ELSE 0 END
        + CASE WHEN vpn_ztna_running.total > 0 THEN 1 ELSE 0 END
        + CASE WHEN dns_security_running.total > 0 THEN 1 ELSE 0 END
        + CASE WHEN vuln_scanner_running.total > 0 THEN 1 ELSE 0 END
ASスコア
    FROM telemetry_running, edr_running, mdm_running, dlp_running,
         vpn_ztna_running, dns_security_running, vuln_scanner_running
)
選択
    CASE WHEN score = 7 THEN 1 ELSE 0 
    END AS security_tools_healthy
FROM final_score;

 このクエリの構成に関する注意点をいくつか以下に示します。

  • カテゴリの対象範囲を測定します。各カテゴリに適用されるCASE WHEN total > 0 THEN 1ロジックは、すべてのシグナルを合計する前に、個々に1の上限を設定するものです。これがなければ、5つのプロセスを生成する単一のツールでスコアに1ではなく5と加算されてしまい、4つのツールカテゴリが欠落しているデバイスでも、非常にビジーなEDRエージェントが1つあるだけで合格してしまいます。この上限は、チェックが実際に測定している対象、つまりプロセスの数ではなく、カテゴリの対象範囲を徹底するものです。

  • さまざまなベンダーを正規化し、一貫したシグナルに変換します。このクエリでは、より単純なWHERE句ではなく、独立したCTEを使用して、さまざまなツールベンダー間の正規化を行います。デバイスが、CrowdStrikeとSentinelOneのどちらを実行しているかにかかわらず、EDRカテゴリは常に「1」になります。モノリシックなアプローチでのWHERE句は生のプロセス数を返しますが、それでは意味がありません。EDRがどれだけ多くのプロセスを生成したとしても、1つのツールとしてしか評価されないからです。

  • macOSとWindowsの両方に対応しています。クロスプラットフォームのポスチャチェックを作成する際の課題の1つは、macOSツールには同等のWindowsツールがないことが多く、その逆もまた同様であることです。このチェックは次のように処理します。macOSデバイスは、JamfDaemon、kandji-daemon、mosyled、またはaddigy-agent経由のMDMに対してスコア1を付けます。Windowsデバイスは、Intune MDMのプロセスであるMicrosoft.Management.Services.IntuneWindowsAgent.exeに対してスコア1を付けます。プラットフォーム固有のEDRプロセス名についても同様です。各カテゴリは同じCTE内で両方のプラットフォームに対応するように設計されているため、しきい値は両方のオペレーティングシステムでscore = 7のままです。したがって、プラットフォーム固有のクエリバリアントは必要ありません。

ニーズに合わせて活用する

すべての組織が、7つすべてのツールカテゴリを導入しているわけではありません。たとえば、脆弱性管理にEDRを使用する組織もあれば、エンドポイントではなくネットワークレイヤーでDNSセキュリティを処理する組織もあります。各CTEのプロセス名リストは、各カテゴリの主要ベンダーを対象としているため、組織全体でチェックをほとんど、あるいはまったく変更することなく機能させることができます。ただし、このクエリは出発点であり、最終的な構成ではありません。このチェックを適用モードで導入する前に、環境に合わせてカスタマイズし、テストする必要があります。

  1. まず、okta/customer-detectionsリポジトリ内で特定の検出クエリを見つけます。プロジェクトをクローンすることをお勧めします。

  2. 次に、固有の環境に合わせてクエリを調整します。各CTEを確認し、ベンダーのプロセス名がリストに含まれていることを確認します。含まれていない場合は追加します。それから、実際に必要なカテゴリ数に合わせてしきい値を下げます。(例:5つのツールを使用するスタックでは、「=7」ではなく、「=5」を使用します。)osqueryiを使用してローカルでチェックを実行し、検証することをお勧めします。組織で必要とされるセキュリティスタックに完全に適合するまで、プロセス名を精査し、スコアのしきい値を調整します。

  3. フリートに対してクエリを1週間監視モードで実行します。これにより、どのカテゴリが実際のデバイスで0と記録されているかを把握できます。多くの場合、ツールが想定された状態から逸脱していることを示す最初の兆候となります。

  4. クエリが期待どおりに動作することを確認してから、強制モードで実行します。

ループを閉じる

このツール監視チェックは、一見すると地味に思えるかもしれませんが、導入する価値のある重要な基盤となります。このチェックにより、費用をかけて展開したセキュリティスタックが、環境に認証しようとしているすべてのデバイスで実際に実行されていることを確認できます。

今後数日にわたり、高度なポスチャチェックをまったく異なるチャレンジに使用した場合に何が起こるかを探っていきます。

アイデンティティ施策を推進