Okta WICとEDR:CrowdStrike Falconの連携
浅葉 正史はじめに
またブログの更新が随分滞ってしまい、久しぶりの投稿になってしまいました。
今回は、前回の予告通り、Okta Workforce Identity Cloud（以降「Okta」と記述を省略させて頂きます）とCrowdStrike社のEDR Falcon（以降「Falcon」と記述を省略させて頂きます）との連携について記述します。
OktaとFalconの連携で出来る二つのこと
OktaとFalconを連携してどのようなことが出来るかについて調べてみましたが、以下二つの連携が可能であることがわかりました。
- Falconのセンサー（デバイスにインストールするソフト）が収集した情報を元にした対象デバイスのセキュリティ評価を元に、該当デバイスからのOkta連携アプリへのアクセス許可/拒否を制御する
- Falconのアラート検知をトリガーに、自動的に、対象のOkta IDに対してセッションの切断、パスワードリセット、MFA認証要素リセットとといった措置を実施する
Falconによるデバイスのセキュリティ評価に基づくOkta連携アプリのアクセス制御
まず一つめの、Falconによる対象デバイスのセキュリティ評価値を元にしたOktaのアプリのアクセス制御を実際にやってみました。
後述の、Falcon側で必要な機能を有効化するのに少し手間取ったのはありましたが、それ以外は非常に簡単に実装できました。
なお、EDRのデバイス評価値をOktaの認証制御に使用できるようにすることを、Oktaでは「エンドポイントセキュリティ統合（Endpoint security integrations）」と言うようです。以下が、Okta社のエンドポイントセキュリティ統合の公式ドキュメントのリンクとなります。
https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/edr-integration-main.htm
以下リンクのページに記載がありますが、Oktaのエンドポイントセキュリティ統合には以下のような前提条件があります
https://help.okta.com/oie/ja-jp/content/topics/identity-engine/devices/edr-integration-prereqs.htm
- Windows PCとMac PCにのみ対応。モバイルデバイスは非対応。
- 認証方法として、Okta FastPassを使用する必要がある
- Mac PCは「管理対象デバイス(Managed devices)」（MDM等で管理されているデバイス）としてOktaに登録されている必要がある。
以下が、私が検証環境で実際に実装してみた手順となります。
FalconのセンサーがインストールされているWindows PCで検証を行いました。
➀FalconのZero Trust Assessment機能の有効化
Falcon側の「Zero Trust Assessment」という機能が有効になっている必要があるため、まず機能が有効であるかを確認します。
Falconのセンサーをインストール済のWindows PCで以下のフォルダ内に、data.ztaというファイルが存在し、かつファイルサイズが0byteでないことを確認します。
C:\ProgramData\CrowdStrike\ZeroTrustAssessment
上記ファイルが存在しない、または存在するがサイズが0byteである場合は、FalconのZero Trust Assesment機能が有効になっていないため、有効にする必要があります。
機能を有効にするには、CrowdStrikeのサポートへサポートチケットを起票し、機能の有効化を依頼します。
※参考：CrowdStrikeのサポートポータル内の記事（以下リンク先ページの参照にはFalconのIDが必要です）
https://supportportal.crowdstrike.com/s/article/ka16T000001xiDPQAY
私の場合、サポートチケットを起票してからその日のうちに機能を有効化した旨の返信がありましたが、その後も何故かdata.ztaは0byteのままで機能は使用できず、何度かサポートとメールをやり取りを繰り返しているうちに、原因不明のまま数日経過後に機能が利用可能となりました。ですが、そういうのはおそらくレアケースなのだと思います。
➁FalconのセンサーがインストールされたWindows PCにOkta Verifyをインストール
➂CrowdStrikeエンドポイントセキュリティ統合プラグインの設定
Windows PCに、Okta VerifyがOktaへFalconのシグナル情報を連携するためのプラグインの設定を行います。
以下内容のPowerShellスクリプトを作成し実行します
$content = "{`r`n`t`"name`": `"com.crowdstrike.zta`",`r`n`t`"description`": `"Okta provided integration with CrowdStrike Falcon endpoint collecting the zta score.`",`r`n`t`"type`": `"FILE`",`r`n`t`"format`": `"JWT`",`r`n`t`"location`": `"%ProgramData%\\CrowdStrike\\ZeroTrustAssessment\\data.zta`",`r`n`t`"availabilityChecks`": [`r`n`t`t{`r`n`t`t`t`"type`": `"SERVICE_RUNNING`",`r`n`t`t`t`"value`": `"csagent`"`r`n`t`t}`r`n`t]`r`n}"
$path = $env:ProgramData + "\Okta\OktaVerify\Plugins\"
$filePath = $path + "com.crowdstrike.zta.json"
if (-not (Test-Path $path))
{
New-Item $path -ItemType Directory
}
[System.IO.File]::WriteAllText($filePath, $content)
スクリプトを実行すると 、以下のフォルダにcom.crowdstrike.zta.jsonファイルが作成されます。
C;\ProgramData\Okta\OktaVerify\Plugins
以下リンクは、プラグイン設定についての公式ページです。
④Okta上でエンドポイントセキュリティ統合の作成
Okta管理コンソールにて、［Security（セキュリティ）］［Device integrations（デバイス統合）］に移動し、［Endpoint security（エンドポイントセキュリティ）］タブをクリック、［Add endpoint integration（エンドポイント統合の追加）］をクリックします。
[CrowdStrike]を選択します。
連携したいデバイスのOSを選択し、［Add（追加）］をクリックします。
以下リンクは、エンドポイントセキュリティ統合の作成についての公式ドキュメントです。
⑤アプリケーションの認証ポリシーの設定
Oktaで、Falconのセキュリティ評価値でアクセス制御を行いたいアプリケーションの「認証ポリシー」の設定を行います。
今回の検証では、「CrowdStrike連携検証用ポリシー」という認証ポリシーを新規作成しOkta Dashboardに割り当てました。
作成した認証ポリシーには、ルールを二つ追加し、優先順に以下3つのルールを持つポリシーとしました。エンドポイントセキュリティ統合の対象としたWindowsデバイスのためのルールと、対象とならないWindows以外のデバイスのルールを分けています。
- 「Windows-CrowdStrikeのOS評価80以上」（追加作成）
- 「Windows以外」（追加作成）
- 「Catch-all Rule」（ポリシー作成時から存在するデフォルトルール）
1番目のルール「Windows-CrowdStrikeのOS評価80以上」の設定
IF部分（条件指定しない設定箇所は割愛）
- 「Device state is」:「Registered」
- 「Device management is」：「Not managed」（Windows PCでの検証のためNot managedでもOK）
- 「Device platform is」:「Windows」
- 「The following custom expression is true」：「device.provider.zta.os >= 80」
THEN部分
- 「Access is」：「Allowed after successful authentication」
- 「User must authenticate with」：「Possesion factor」
- 「Possession factor constraints are」： 「Phishing resistant」
2番目のルール「Windows以外」 の設定
IF部分で「Device platform is」でWindows以外の全てのプラットフォームを指定し、THEN部分は任意の二要素認証でログイン可能としました。
3番目のルール「 Catch-all Rule」の設定
1番目・2番目のルールに該当しないデバイス、つまりOS評価が80未満のWindowsデバイスはアクセス拒否するために、「Access is」を「Denied」 に設定しました。
1番目のルール「Windows-CrowdStrikeのOS評価80以上」の 「The following custom expression is true」に設定している「device.provider.zta.os >= 80」の部分が、Falconから取得したデバイスのOS評価のスコアが80以上の場合という条件指定となります。
EDRから受け取る情報を「EDRシグナル（信号）」と呼ぶようなのですが、以下リンクにOktaがEDRから取得できるシグナル情報についての記載があります。
取得可能なデバイスのセキュリティ評価値は以下3種類で、それぞれが100点満点で100が最もセキュリティが高い評価となるようです。
- OS評価：device.provider.zta.os
- センサー評価：device.provider.zta.sensorConfig
- 全体的な評価：device.profile.zta.overall
※参考：セキュリティスコアについてのCrowdStrike Falconのマニュアルページ （アクセスにはFalconのIDが必要。また以下リンクはus-2セルのリンクであるため、別セルの契約の場合はリンクの「us-2」部分の変更が必要）
https://falcon.us-2.crowdstrike.com/documentation/page/bc52e49b/zero-trust-assessment#ie3f64b9
デバイスの各評価のスコアは、Falconの管理コンソールの「ゼロトラストアセスメント」の画面でも確認可能です。
ちなみに、今回私が検証に使用したWindows PC評価値は、「センサー評価」が4と何故か低く、そのため「全体的な評価」も29と低い値となっていたため、100点満点で比較的まともな数字に見えた「OS評価」の値を使って検証をしました。
また、もう一点補足として、1番目のルール「Windows-CrowdStrikeのOS評価80以上」で、「Device state is」部分を「Registered」とし、「The following custom expression is true」部分にEDRのシグナル使用した式を入れると、認証にはOkta FastPassの使用を強制される動作となりました。そのため、「Possession factor constraints are」の部分については「Phishing resistant」にしなくても動作は変わりません。
実装手順は以上となります。
実際に、検証用Windows PCでOkta DashboardにログインしようとするとFastPassでの認証を求められ、認証後に以下のエラーの画面となりました。 こちらは認証ポリシーでアクセスを拒否された際に表示されるOktaのデフォルトの画面となります。
これは検証用Windows PCのOS評価が77であり80未満だからで、試しに認証ポリシーの「device.provider.zta.os >= 80」部分を「device.provider.zta.os >= 70」に変更すると通常通りログインできるようになりました。
なお、EDRのシグナルを使用した認証ポリシーのアプリケーションに、Okta Fastpassで認証すると、Oktaのシステムログのポリシー評価時のログの中でEDRのシグナルの内容を確認することができます。 以下は認証失敗時のログです。
実際に試してみて、実装自体は非常に簡単でした。
ただ、認証失敗時のエラー画面が利用者にとっては何故認証失敗したかがわからない内容であるため、実際に本機能を使うにあたっては、利用者のデバイスのEDRセキュリティスコアが組織の定める基準以下であることを利用者に伝える仕組みが別途必要となりそうだなとは思いました。Falcon側のフロー機能（Fusion SOARワークフローというフロー機能がある）を使って別途利用者への通知を行う等。また、認証ポリシーのアクセス拒否時のエラー画面は、Oktaの管理コンソールの[Customizations(カスタマイズ)]-[Other(その他)]-[Application Access Error Page(アプリケーションアクセスエラーページ)]の設定で、任意のURLにリダイレクトするように変更することも可能です。ヘルプデスクのポータルサイトに認証エラー時の考えらえる要因を記載したページを作成するなどし、エラー時はそのページにリダイレクトする設定にすることでも、利用者にとってのわかり辛さを軽減することができるかもしれません。
また、本機能を実装する上で一番難しく肝となる部分は、どの評価値を使い、どの程度のスコアを認証拒否の閾値とするかの設計であると思います。閾値については、FalconのZero Trust Assesment機能を有効にしてから一定期間運用し、自社の正常な状態のデバイスの評価値がどれくらいかをモニタリングしながらチューニングするのかなとは思うのですが、今回私が使用した検証用PCのセンサー評価が4点/100点満点だった点など疑問は残っています。これはOktaを主題としたブログなので、今回は残念ながら妥当な閾値をどのように決めるかという部分をここで深堀することはできないのですが、お客様企業システムのセキュリティ強化を支援するエンジニアの端くれとして、そういったノウハウも身につけていきたいものだなとは思いました。
Falconのアラート検知をトリガーとしたOktaIDのセッション切断／パスワード・MFA認証器リセット
冒頭のに記載した「OktaとFalconの連携で出来る二つのこと」の二つ目、Falconのアラート検知をトリガーにして自動でOktaのIDのセッションを切断したり、パスワードやMFA設定をリセットする連携について。
攻撃によるデバイスの侵害が検知された場合、EDR Falconの機能で該当デバイスを自動的にネットワークから隔離することが可能です。しかし、デバイスが侵害された以上、デバイス上の認証情報（ブラウザ等に保管されているパスワードやcookie等）が搾取された可能性も否定できず、該当デバイスの利用者の使用しているIDのセッションやパスワードやMFA認証器をリセットして、搾取された認証情報を使用しての他デバイス（攻撃者のデバイス等）からのアクセスも防止する対応も併せて必要となると思います。FalconとOktaを連携することにより、そのような対応も自動化することが出来るようです。
以下リンクは、こちらもFalconのIDがないと参照できないページとはなりますが、Falconの公式マニュアルのOktaとの連携について記載箇所となります（us-2セルのリンクであるため、別セルの契約の場合はリンクの「us-2」部分の変更が必要）
https://falcon.us-2.crowdstrike.com/documentation/page/cc573d83/okta-identity-management
実装方法はおおまかに以下のような流れになります
➀Okta側にFalconとの連携用のAPIを作成する
➁Falcon側で➀で作成したOktaのAPIに接続するコネクタを作成する
➂Falcon側にあるワークフロー機能（Fusion SOARワークフロー）で、Falconのアラート検知をトリガーにOktaコネクタを使用したアクション（Okta IDのセッション切断/パスワードリセット/MFAリセット）を自動実行するフローを作成する
Okta側で行うことはAPIを作成するだけ。あとはFalcon側の作業となります。
この機能を実装するにはFlaconの通常のサブスクリプションだけでは出来ずFalcon Next-Gen SIEMというアドオン が別途必要であるため、残念ながら弊社の検証環境で実際に検証することはできませんでした。ただ、ドキュメントを参照する限りはこちらも簡単に実装できそうな印象でした。
おわりに
今回のブログは以上となります。
また、不定期となりますが、適宜Oktaについてのブログを更新していきたいと思います。
