About massaito

この記事では、2つのXQLクエリの結果を結合するコマンドJoinとUnionについて紹介します。   Cortex XDRはCortex XDR Pro per Endopointで収集したEDRのデータや、 NGFWファイアウォールログ、クラウドなどサードパーティログを取り込むことができますが、 JoinやUnionコマンドを使うことで、これらのログのデータ横断的な調査・分析、 BIOC、Correlation Ruleなどを用いた脅威検出にご利用いただくことができます。   Join、Union共に、クエリ結果を結合するコマンドであることには変わりはないのですが、 結合の考え方が異なりますので、簡単に説明します。     Joinとは JoinコマンドはSQLのJoinと似た概念のコマンドで、Inner join, Right join, Left joinといった結合方法が用意されています。 2つのクエリの結果セットを結合する条件を設定し、列で結合します。     例えば、以下のような2つの結果セット(result A,result B)があったとします。   result A # host_id host_name 1 01 server01 2 02 server02   result B # id admin_name 1 01 admin_a 2 02 admin_b     result AのHOST_IDとresult BのIDを条件一致のキーすることによって、 以下のように結合されます。(列に追加)   # host_id id host_name admin_name 1 01 01 server01 admin_a 2 02 02 server02 admin_b     xdr_dataデータセットと、endpointsデータセットをjoinで結合する   以下のようなXQLを考えてみます。   dataset=xdr_data | dedup actor_process_image_name ,agent_hostname, agent_id | top 3 agent_id | join type = left ( dataset=endpoints | dedup endpoint_name, endpoint_id | fields endpoint_id, endpoint_name, ip_address , tags , endpoint_isolated , endpoint_type ) as ep ep.endpoint_id= agent_id   前半のクエリ dataset=xdr_data | dedup actor_process_image_name ,agent_hostname, agent_id | top 3 agent_id では、agent_idで集計したTOP3のAgent_IDが返ってきます。     後半のjoinコマンドで実行するクエリ、 dataset=endpoints | dedup endpoint_name, endpoint_id | fields endpoint_id, endpoint_name, ip_address , tags , endpoint_isolated , endpoint_type では、 以下のような結果が返ってきます。       as ep ep.endpoint_id= agent_idでは、endpoint_idとagent_idを条件一致のキーとしており、これによって以下の結果が返ってきます。 緑の枠が前半のクエリの実行結果を示しており、水色の枠が後半のクエリの実行結果を示しています。   またjoin typeをleft joinとしてるため、前半のクエリ結果(3件)と、条件に一致する後半のクエリ結果が結合した状態で取得されます。         Unionとは unionコマンドは、2つのクエリの結果セットを行で結合します。 例えば、以下のような２つの異なる結果セットがあった場合、   result A #1 servername host_ip 1 Server01 xx.xx.xx.xx 2 Server02 yy.yy.yy.yy     result B # mobile_name host_ip 1 iPhone A zz.zz.zz.zz 2 Android B uu.uu.uu.uu   以下のように結合するイメージです。(行に追加) # servername mobile_name host_ip 1 Server01   xx.xx.xx.xx 2 Server02   yy.yy.yy.yy 3   iPhone A zz.zz.zz.zz 4   Android B uu.uu.uu.uu       結合する際にフィールド名を一致させるようXQLで変換しておく、 例えばservernameとmobile_nameをhost_nameに変換すると、 以下のような結果が返ります。   # host_name host_ip 1 Server01 xx.xx.xx.xx 2 Server02 yy.yy.yy.yy 3 iPhone A zz.zz.zz.zz 4 Android B uu.uu.uu.uu     xdr_dataデータセットと、ngfwデータセットをunionで結合する   以下のようなXQLを考えてみます。 エンドポイントデータのネットワーク通信ログとNGFWのトラフィックログを結合します。   dataset=xdr_data   | filter action_remote_ip != null and agent_hostname != null and actor_process_image_name != null   | fields actor_process_image_name ,agent_hostname, action_remote_ip   | limit 5   | union     (       dataset=panw_ngfw_traffic_raw         | fields from_zone ,dest_ip , source_ip         | limit 5     )     まず、前半のクエリの結果を確認します。 dataset=xdr_data   | filter action_remote_ip != null and agent_hostname != null and actor_process_image_name != null   | fields actor_process_image_name ,agent_hostname, action_remote_ip   | limit 5   プロセスイメージ名、エージェントホスト名、通信先のIPアドレスが5件結果として返ってきました。   後半のクエリの結果を確認します。 dataset=panw_ngfw_traffic_raw | fields from_zone ,dest_ip , source_ip | limit 5   ゾーン、宛先IP、ソースIPが5件結果として返ってきました。     上記2つのクエリをunionで結合すると、以下のように行で結合していることがわかります。 水色の枠がエンドポイントデータのネットワーク通信ログ、緑色の枠がNGFWのトラフィックログを示しています。   ただし宛先IPアドレスが別々のフィールド名として結合するため、使い勝手があまり良くありません。   そこで元のXQLの前半のクエリでaction_remote_ipフィールドをdest_ipに変換しておきます。 変換する場合は、<元のフィールド名 as 任意のフィールド名>　という形で指定します。   dataset=xdr_data   | filter action_remote_ip != null and agent_hostname != null and actor_process_image_name != null   | fields actor_process_image_name ,agent_hostname, action_remote_ip as dest_ip   | limit 5   | union     (       dataset=panw_ngfw_traffic_raw       | fields from_zone ,dest_ip , source_ip       | limit 5     )   そうすると、以下のようにフィールド名とそのデータが統合され結果が返ってきました。     このように、複数のデータセットを結合して、データを検索したい場合、同じ意味を持つフィールド名を統一しておくと、 検索の効率性が大きく向上します。     Tech Doc joinに関する詳細はこちら unionに関する詳細はこちら           ... View more

Cortex XDRはiOSをサポートし、iPhone/iPadを保護します。   iOS対応の特徴 iOS 15.0以降をサポート 悪意のあるURLを含むSMS/MMSメッセージをブロック 迷惑電話やメッセージをブロック スパム通話やフィッシングとしてメッセージをレポート ジェイルブレイクされたデバイスを検知 手動、MDM、JAMFを用いた展開が可能   iOSエージェントのHome画面    AppStoreの画面     All Endpointsの画面   こちらのブログも併せてご確認ください。   Tech Doc 製品の詳細についてはこちら ... View more

この記事では、iploc,viewというstageコマンドを使用して、グローバルIPアドレスの位置情報を地図にする 方法について説明します。   Live communityで掲載したApache HTTPサーバーのAccessログを取り込み、その後ログをパースする方法、 に続く記事となりますので、事前に読んでいただけると理解が深まるかと思います。   パースされたAccessログのアクセス元のIPアドレスの位置情報を使って、 HTTPサーバーがどの国・地域からアクセスされているのかを可視化します。 ちなみにここで紹介するiplocコマンド、viewコマンドはCortex XDR Pro per Endpointライセンスでも使用可能です。       iplocとは？ iplocを使用すると、IPアドレス(IPv4)の位置情報に関する属性を返します。   viewとは？ viewを使用すると、特定のフィールドをハイライトしたり、グラフでデータを可視化することができます。 ここではグラフを作成するモードで使用しますが、グラフに使用するX軸のフィールド、 Y軸として使用するフィールドをあらかじめ検討しておく必要があります。   XQLを作成する   以前の記事で、accessログをパースして、remote_ipというアクセス元のグローバルIPアドレスのフィールドを作成しました。 まず、このremote_ipを重複排除(dedup)し１つのフィールドだけにして(fields)、iplocコマンドで位置情報を取得します(iploc)。 その後remote_ipを位置情報のloc_country単位で集計し(comp count)、remote_ipの集計値をソートします(sort)。 以下のXQLはそれを表現したものです。   dataset=apache_httpserver_raw | dedup remote_ip | fields remote_ip | iploc remote_ip loc_city , loc_continent ,loc_country ,loc_latlon ,loc_region ,loc_timezone | comp count (remote_ip) as number_of_ip by loc_country | sort desc number_of_ip   実行すると、以下のような結果が得られると思います。     viewコマンドを使ってmapにする   上のXQLにgraphコマンド(青字)を追加します。graphコマンドはXQLのUI上から追加することも可能です。 typeでmapを指定し、X軸をloc_country、Y軸をremote_ipの集計値とします。   dataset=apache_httpserver_raw | dedup remote_ip | fields remote_ip | iploc remote_ip loc_city , loc_continent ,loc_country ,loc_latlon ,loc_region ,loc_timezone | comp count (remote_ip) as number_of_ip by loc_country | sort desc number_of_ip | view graph type = map xaxis = loc_country yaxis = number_of_ip default_limit = `false`   XQLのUIから追加する場合、Query Resultsのタブから「Graph」を選択し、   Char EditorのGraph Typeから「Map」を、DataのX-axisに「loc_country」、Y-axsisに「number_of_ip」を 選択すると、   以下のように地図に集計値がプロットされます。   Chart Editorの「Add to Query」をクリックすると、   XQLにクエリが差し込まれます。このクエリを保存したり、Widget Libraryに追加して ダッシュボードなどで再利用可能にすることができます。     クラウドサービスプロバイダーのVirtual Private Cloudのフローログのデータや、 SaaSアプリケーションのログデータに含まれるパブリックIPアドレスを使用して アクセス傾向を分析するケースで役立つかもしれません。   Tech Doc iplocコマンドの詳細はこちら viewコマンドの詳細はこちら ... View more

この記事ではCortex XDRに取り込んだrawデータをパースする方法について説明します。 またこちらの記事で説明したデータをパースすることを前提としていますので、 ご一読いただければと思います。   Parsing Rulesを使う データをパースするにはParsing Rulesを使います。 rawデータをパースすることもできますが、既存の構造化データ(CSV,TSVなど)において ある特定のフィールド内の文字列を別の意味のフィールドとして切り出したい場合も、 このParsing Rulesを使うことができます。   ３つのセクション:INGEST, COLLECT,CONST Parsing Rulesは3つのセクションがあり、用途によって使い分けます。 以下の例はINGESTセクションを用いたもので、INGESTセクション配下にrawデータのパースルールを記述します。   COLLECTセクションも基本同じですが、broker VMでパースする場合に使用します。 COLLECTセクションを使用することで、broker VM側で不要なデータを排除したり、 新たなフィールドを追加することができます。   CONSTは、プログラミング言語で出てくるようなconstと同じように定数を設定するセクションです。 CONSTで設定した変数は複数のINGESTセクションで再利用することができます。   サンプルのデータはこちらです。   Apache HTTPサーバーのアクセスログのサンプルレコード(_raw_logに書かれるデータ) 90.208.149.198 - - [28/Jan/2023:12:07:53 +0000] "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361"   Parsing Rules   以下のようにルールを追加します。あくまでサンプルなので、より良いスマートな方法があれば 色々試してみてください。   青字は、brokerVMでデータ取り込みの際指定したvendor, product、その結果作成されたdatasetの名前を設定します。 青い太字のところが最終的にrawデータから抽出するフィールドです。   [INGEST:vendor = Apache , product = httpserver , target_dataset = apache_httpserver_raw, no_hit = keep] alter remote_ip = trim(arrayindex(split(_raw_log),0)) ,remote_log_name = trim(arrayindex(split(_raw_log),1)) ,userid = trim(arrayindex(split(_raw_log),2)) ,datetime = trim(arrayindex(regextract(_raw_log, "\[.+\]") ,0),"[]") ,others = regextract(_raw_log, "\".*\"" ) | alter others = split(trim(arrayindex(others,0)), "\" " ) ,method = trim(arrayindex(others,0),"\"") ,useragent =trim(arrayindex(others,2)," ") ,status = arrayindex(split(arrayindex(others,1)," "),0) ,length = arrayindex(split(arrayindex(others,1)," "),1) ,referrer = trim(arrayindex(split(arrayindex(others,1)," "),2),"\"") | alter request_method = arrayindex(split(method," "),0) ,path = arrayindex(split(method," "),1) ,http_version = arrayindex(split(method," "),2) | fields remote_ip,datetime,remote_log_name,userid,request_method,path,http_version, status,length,referrer,useragent,_raw_log,_collector_type,_log_source_file_name_broker_ip_address,_broker_device_name,_bundle_id,_broker_hostname,_collection_timestamp,_collector_name,_collector_type,_broker_ip_address,_broker_device_id,_reporting_device_ip,_log_source_file_name,_log_source_file_path,_final_reporting_device_ip;   XQLの解説 上記のサンプルログを例に簡単にXQLの解説(青字)します。   alter remote_ip = trim(arrayindex(split(_raw_log),0)) ログを半角スペースで区切り、配列の1番目のを取得 90.208.149.198 - - [28/Jan/2023:12:07:53 +0000] "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361" ,remote_log_name = trim(arrayindex(split(_raw_log),1)) ログを半角スペースで区切り、配列の2番目のを取得 90.208.149.198 - - [28/Jan/2023:12:07:53 +0000] "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361" ,userid = trim(arrayindex(split(_raw_log),2)) ログを半角スペースで区切り、配列の3番目のを取得 90.208.149.198 - - [28/Jan/2023:12:07:53 +0000] "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361"   ,datetime = trim(arrayindex(regextract(_raw_log, "\[.+\]") ,0),"[]")  ログから[]で括られている文字列を配列として取得し、配列の1番目のを取得、その後[]を除去 90.208.149.198 - - [28/Jan/2023:12:07:53 +0000] "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361" ,others = regextract(_raw_log, "\".*\"" ) ログからカンマ(")で括られた文字列を配列として取得  90.208.149.198 - - [28/Jan/2023:12:07:53 +0000] "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361"   | alter others = split(trim(arrayindex(others,0)), "\" " ) othersを配列に変換(3つの要素になる)  "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361" ,method = trim(arrayindex(others,0),"\"")  "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361" ,useragent =trim(arrayindex(others,2)," ")  "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361" ,status = arrayindex(split(arrayindex(others,1)," "),0)  "PUT /explore HTTP/1.0" 200 5037 ,length = arrayindex(split(arrayindex(others,1)," "),1)  "PUT /explore HTTP/1.0" 200 5037 ,referrer = trim(arrayindex(split(arrayindex(others,1)," "),2),"\"")  "PUT /explore HTTP/1.0" 200 5037 "hxxp://thompson.com/register.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/5361 (KHTML, like Gecko) Chrome/14.0.873.0 Safari/5361"   | alter request_method = arrayindex(split(method," "),0) methodを配列に変換(3つの要素になる)し、1番目の要素を取得 "PUT /explore HTTP/1.0" 200 5037    ,path = arrayindex(split(method," "),1) methodを配列に変換(3つの要素になる)し、2番目の要素を取得 "PUT /explore HTTP/1.0" 200 5037 ,http_version = arrayindex(split(method," "),2) methodを配列に変換(3つの要素になる)し、3番目の要素を取得 "PUT /explore HTTP/1.0" 200 5037   サンプルログの選択とシミュレーション Simulateタブを選択したの後、テストするログデータにチェックを入れ、Simulateボタンをクリックします。    Parsinng Ruleでパースされた結果がLogs Outputに表示されます。 「Show more」を選択すると、    パースされたフィールドが生成されていることを確認できます。 意図したフィールドをパースできなかった場合は、ルールの修正とSimulateを繰り返して 調整してみてください。       XQLで確認する   datasetを指定するとParsing Rulesで抽出されたフィールドが生成されていることを確認できます。 このようにして、rawデータをパースしXQLによる検索、ダッシュボードの作成、相関分析などに ご利用いただくことができます。 今回ルール作成に使った関数(trim, arrayindex, split, regextract)の詳細は 以下にリンクを記載しておきますので参考にしてみてください。     Tech Doc Parsing Rulesについてはこちら XQLの関数についてはこちら   ... View more

この記事ではサードパーティのログを取り込むための１つの例として、 Broker VMのFiles and Folders Collectorを使用してログをCortex XDRに送信する方法、 送信したデータをXQLを使用して抽出する方法について説明します。   設定の勘所をお伝えすることを目的にしているので、設定の内容や動作について保証するものではないことをご承知おきください。 またBroker VMの詳細設定はTech Docsを確認してください。(この記事の一番下にリンクを付けています) Broker VMのsyslogを用いたログ収集機能の設定方法にご関心がある場合はこちらの記事をご確認ください。   サンプルとして、Ubuntu20.04サーバーに構築されたApache HTTPサーバーのログを取り込んでみます。 ログファイルはApache HTTPサーバーの以下のディレクトリに作成しており、 アクセスログデータを常時追記しています。   ログのサンプル 76.109.62.29 - - [30/Jan/2023:14:10:22 +0000] "GET /posts/posts/explore HTTP/1.0" 404 5159 "hxxp://www.rasmussen-lee.net/blog/category/list/home.asp " "Mozilla/5.0 (compatible; MSIE 8.0; Windows CE; Trident/5.1)"     /mnt/logs/ffc/apachelogs       具体的には以下のような構成です。Broker VMはnfsでHTTPサーバーの指定ディレクトリにアクセスします。 | HTTPサーバー(/mnt/logs/ffc/apachelogsディレクトリ) | <----(nfs)---- | broker VM | --------> | Cortex XDR |   ログディレクトリを共有する 上記の/mnt/logs/ffc/apachelogsディレクトリを共有します。     broker VMでログディレクトリの設定を行う configurations Data Broker Broker VMsから Files and Folders Collector機能を使用するbroker VMを選択し、 Files and Folder Collector - Configureを選択します。     Shared Folder Connectionに以下のように設定します。 Folder Path nfs://<hostname/IPaddress>/mnt/logs/ffc/apachelogs サーバで共有設定したディレクトリパスを設定します。 nfsでアクセスすることを検討する場合、ユーザー名パスワード名がdisableになります。   [File and Folder Settings] Include *.log Log Format Raw 拡張子がlogのファイルを取り込み対象とします。 ログフォーマットはRaw以外にJSON/CSV/TSV/PSV/CEF/LEEF/Corelight/CISCOが選択することができますが、 今回取り込むApache HTTPサーバーのログはどれにも当てはまないのでRawを選択しています。   Mode TAIL ModeはTAILモードとBATCHモードの2種類あります。 新しいデータが追記されていくログファイルを監視して取り込む場合TAILモードを選択します。 追記されることのない静的なファイルを取り込む場合はBATCHモードを選択します。 このサンプルではTAILを選択します。   [Data Source Mapping] Vendor Apache Product Httpserver Vendor, Productは任意の文字列を設定します。ここで指定した名前でdataset(apache_httpserver_raw)が作成されます。        [Test Connnection]をクリックし、指定したディレクトリにアクセスできるかを確認します。   成功すると、以下のようなアイコンが表示されます。     Generate Previewをクリックすると、    Previewに共有フォルダから読み込んだデータが表示されます。   問題がなければ「Save」ボタンをクリックします。   Datasetを確認する   <Vendor>_<Product>_rawという命名規則でDatasetが作成されることを確認します。 この例ではapache_httpserver_rawというdatasetが作成されます。   指定したディレクトリのlogファイルを取り込みます。 実際にTAILモードに設定していただくとファイルに追記されたデータを監視して Cortex XDRに取り込まれることを確認することができます。     XQLでデータを検索できることを確認する 作成されたデータセットを指定すると、検索することができます。   <XQLクエリの例> dataset = apache_httpserver_raw   _RAW_LOGフィールドにアクセスログが表示されていることがわかります。   実際に取り込んだデータを活用して以下のようなダッシュボードを作ることもできます。 例えば右下のサーバの脆弱性情報はログファイル名に含まれるサーバー名とCortex XDR Pro per Endpointの Host Insights-Add-onで取得された脆弱性情報をXQLでデータを結合することで取得しています。   このようなダッシュボードを作成するためには、_raw_logフィールドのデータをパースし 意味あるデータに切り出す必要があります。パースする方法の概要をこちらの記事で説明しておりますので、 ご興味があれば参照ください。   Tech Doc 共有ディレクトリからのデータ取り込みについての説明はこちら broker VMのfiles and folders collectorの設定はこちら     ... View more

この記事では、Cortex XDRにMicrosoft 365のデータを取り込む方法について説明します。 Cortex XDRは Microsoft Office 365 Management Activity API、Microsoft Graph APIを使用してデータを収集します。   Microsoft Graph APIを使用してAzure ADの認証ログや監査イベントを収集する場合は、Microsoft Azure Premium1 あるいは Premium 2が必要になります。   必要なライセンスや設定における詳細はこの記事の最後にあるTech Docのリンクからご確認ください。     監査ログの有効化 まずMicrosoft管理センターで、監査をログを有効にします。     アプリケーションの登録   Azure Active Directoryを選択します。   「+新しいアプリケーションを選択」します。   お使いのアプリの名前はなんですか？の欄で名前を入れて、 「ギャラリーに見つからない場その他のアプリケーションを統合します。」を選択肢、 「作成」ボタンをクリックします。 ここではアプリの名前を「labCortexJP」とします。     labCortexJPという名前のアプリが登録されました。 「APIのアクセス許可」を選択し「+アクセス許可の追加」をクリックします。       「アプリケーションの許可」を選択し、必要なアクセス許可にチェックを入れていきます。 ここで追加するのは以下のスクリーンショットのとおりです。               最後に「アクセス許可の追加」をクリックします。     「＜XXXX＞に管理者の同意を与えます」を選択し、   「管理者の同意の確認を与えます」の画面で「はい」をクリックします。     これでAPIのアクセス許可が追加されました。     クライアントIDを控える アプリケーションIDを控えておきます。Cortex XDR側の設定の時に必要となります。     クライアントシークレットの作成 証明書とシークレットで、「+新しいクライアント シークレット」を選択します。   説明と有効期限を設定し、「追加」ボタンをクリックします。       シークレットが生成されるので「値」に表示された文字列を控えておきます。   Cortex XDRの設定 Settings → Configurations → Data Collection → Collection Integrationsを選択します。 Tenant Domain、控えておいたアプリケーションクライアントID、シークレットの値を設定します。 APIのチェックボックスは以下の通りとします。 Alerts from Microsoft Graph Security APIとEmailsについては別の機会で説明したいと思います。       「Test」ボタンをクリックしAPI接続が成功すると、「Connection Established」と表示されるので、 「Enable」ボタンをクリックします。   これでMicrosoft 365のインスタンスが作成されました。     データ取り込みの確認 設定画面から 以下のようにLast hour, Last dayなどに数値が入ってくることが確認できれば取り込んでいる、という判断ができます。     XQLで確認する XQLでデータがXDRに取り込まれているか確認してみます。   例えば、OnedriveでFileUploaded操作を取得する場合、以下のようなクエリで確認することができます。   dataset = msft_o365_sharepoint_online_raw | filter _collector_name = "<your collector name>" and Operation = "FileUploaded" and workload = "OneDrive" | fields _time, userid, clientip ,sourcefilename, FileSizeBytes,workload,operation,useragent ,objectid         他のアプリのDatasetはTech Docに記載されておりますので、必要に応じてご確認ください。 またフィールドについての詳細な情報はOffice 365 Management Activity APIのスキーマが参考になると 思いますのでこちらも合わせてご確認ください。 Tech Doc Microsoft 365のデータ取り込みに関する詳細はこちら   ... View more

この記事では、XQLで記述したクエリを用いたBIOCルールによって Linuxサーバの設定ファイルの変更監視する方法について説明します。   また、本記事の内容はお客様の運用環境において要求される事項と必ずしも一致するものではなく、 動作を保証するものではありませんのでご承知おきください。     指定のディレクトリ、およびファイルを監視する Linuxサーバで、ファイルのアクセス権、所有者の変更、Remove, Rename, Write, Createイベントが 発生した時にアラートを出力するようにします。 以下のファイル及びディレクトリを監視対象としてみます。   ・/etcディレクトリ直下の拡張子.confのファイル ・/bootディレクトリ内のファイル及びサブディレクトリ ・/etc/crontab ・/etc/cron.dailyディレクトリ内のファイル及びサブディレクトリ ・/etc/cron.hourlyディレクトリ内のファイル及びサブディレクトリ ・/etc/cron.weeklyディレクトリ内のファイル及びサブディレクトリ ・/etc/cron.monthlyディレクトリ内のファイル及びサブディレクトリ     XQLクエリは以下のとおりです。 監視対象となるファイルパス「action_file_path」は 正規表現で記述しています。より良い正規表現があると思うので色々試して見てください。 また、見てただいてわかるとおり正規表現を使う場合は「~=」という演算子を使います。   dataset = xdr_data | filter agent_os_type = ENUM.AGENT_OS_LINUX and   event_type = ENUM.FILE and     event_sub_type in ( ENUM.FILE_CHANGE_MODE, ENUM.FILE_CHANGE_OWNER, ENUM.FILE_REMOVE ,ENUM.FILE_RENAME, ENUM.FILE_WRITE, ENUM.FILE_CREATE_NEW ) and     (        action_file_path ~= "^\/etc\/[\w]+(.conf)$" or        action_file_path ~= "^/etc/crontab$" or        action_file_path ~= "^\/etc\/cron\.daily\/.+" or        action_file_path ~= "^\/etc\/cron\.hourly\/.+" or        action_file_path ~= "^\/etc\/cron\.weekly\/.+" or        action_file_path ~= "^\/etc\/cron\.monthly\/.+" or        action_file_path ~= "^\/boot\/.+"     )  | filter action_file_path !~= ".+(.swp|.swx)$"     BIOCルールを作成する 上にXQLを使ってBIOCルールを作成します。 ルールを作成する画面で以下のようにクエリをテストし成功すると条件に一致したイベントが検出されます。 期待しない結果が出てくる場合はここでXQLのチューニングを行います。     EVENT_SUB_TYPEとACTION_FILE_PATHのところを拡大   action_file_pathに含まれる値の内訳     ルールの名前、Severity、MITRE ATT&CKにおけるTactic/Techniqueなどを設定し作成します。 OKボタンをクリックすると、   BIOC Rulesの画面に作成したルールが表示されます。     監視対象のファイルを操作する ここでは２つの操作を実施してみたいと思います。 １つ目は、sshでLinuxサーバ(ホスト名ubuntusvr、IP 192.168.68.114)リモートアクセスして、 /etc/resolv.confの編集を行い最終行にちょっとしたコメント行を追加し、     ２つ目は、/etc/cron.dailyディレクトリにあるbsdmainutilsの名前を変更してみます。 (sudo mv bsdmainutilsbsdmainutils.renameのところ)     インシデントを確認する サーバのログデータがクラウドに送信されるとBIOCルールによって判定されインシデントが作成されました。     Linux File Monitoringというアラート名で2つのHigh Severityのアラート（赤いところ）が表示されています。     /etc/resolv.confの操作で発生したアラートを確認する まず１つ目のアラートを確認してみます。 INITIATOR_PATHにvimが、FILE_PATHに/etc/resolv.confが表示されており、 vimによってresolv.confが操作されたということがわかります。   このアラートからCausality Chainを確認すると、 Bのマーク（オレンジ枠のところ）赤く塗られて強調表示されており、ここで検知したことがわかります。   Bマークの下のアイコンをクリックするとvim(エディタ)を用いて編集したことがわかります。(CMDに書かれたコマンド)     余談ですが、２つ左隣のアイコン（黄色の枠）を見ると、ユーザーがrootに変更になったことがわかります。 vimをsudoコマンドで起動した後に該当ファイルを編集したので、このようなプロセスの連鎖になっています。     また、プロセスの連鎖をもう少し左側にさかのぼっていくと雲のマークのアイコンがあります。 白枠のメッセージに 「sshd has been controlled from a remote host; connection details: local IP address: 192.168.68.114, local port: 22, remote IP address: 192.168.68.104, remote port: 57507」   と書かれておりsshによってリモートアクセスが行われ、そこが起点になっていることがわかります。 実際にsshでリモートアクセスして操作していたので、同じ結果がCausality Viewに表示されています。     /etc/cron.dailyディレクトリにあるファイル操作で発生したアラートを確認する 次に２つ目のアラートを確認してみます。 INITIATOR_PATHに/usr/bin/mvが、FILE_PATHに/etc/cron.daily/bsdmainutils.renameが表示されており、 mvによってbsdmainutils.renameが操作されたということがわかります。     上の例と同様、このアラートからCausality Chainを確認すると、 Bのマーク（オレンジ枠のところ）赤く塗られて強調表示されており、ここで検知したことがわかります。 （よく見ると上の例のCausality Chainと同じでsshが起点になってます。）     Bマークの下のアイコンをクリックするとmvを用いて名前を変更していたことがわかります。(CMDに書かれたコマンド)   このようにして、サーバの変更監視にBIOCルールを活用することもできます。 実際には運用環境に合わせて適切なXQLを記述する必要があると思いますが 、 監視の必要性がある場合は参考にして見てください。   Tech Doc BIOCルールのついての詳細はこちら 正規表現におけるXQLの演算子についてはこちら   ... View more

この記事では、ダッシュボードの作成方法について説明します。   ダッシュボードは「widget」という部品を組み合わせて作られています。 「widget」自体はXQLを用いて作成します。 Cortex XDRは定義済みのwidgetも用意しているので、 必要に応じてそれらを再利用して独自のダッシュボードを作成することも可能です。   ここではこの記事で記載した「直近30日アクセスのないデバイス情報を抽出する」ためのXQLを用いてwidgetを作成し、 それをダッシュボード上に配置してみたいと思います。   widgetを作成する   | Dashboards & Reports | - | Customize  | - | Widget Library | から 「 + Create custom XQL widget」を選択します     NameとXQLを設定します。 Nameは過去30日間アクセスのないデバイスとし、XQLは上記の通り記事から引用します。 クエリ実行あと、期待する結果が返ってくることを確認し「Save widget」をクリックします。     Widget Libraryに過去30日間アクセスのないデバイスと言う名前でWidgetが作成できたことを確認します。   widgetを配置してダッシュボードを作成する    Dashboard Managerから「+ New Dashboard」をクリックします     Dashboard NameとDashboard Typeを選択します。 名前はMy Test、タイプはBlankを選択します。    作成したWidgetをドラッグアンドドロップします。    貼り付けたWidgetによりデータが表示されることを確認します。問題がなければ「Next」をクリックします。    ここではダッシュボードを他のCortex XDRユーザーと共有しないため、「Private」を選択します。   「Generate」をクリックします。    My Testという名前でダッシュボードが作成されました。     ダッシュボードを表示する   Dashboardに作成したダッシュボード表示されるので選択します。      Dashboardに貼り付けたWidgetが表示されました。   ここではダッシュボードに１つのWidgetだけ設定しましたが、 Widgetを複数作って１つのダッシュボードで設定し表示することもできますので、 上記のサンプルを参考にしていただきながら、ご自身のダッシュボードを作成して見てください。   Tech Doc ダッシュボードの詳細はこちら   ... View more

  組織の場合、本社・事業所・工場・海外拠点など、リモートワークの場合自宅の環境・公衆Wi-Fiであったり、 様々なネットワークが存在します。場所によってルールの強度を変えたいときに、Host Firewall機能の   ・端末情報を用いたポリシー適用の条件の設定 ・名前解決によるロケーションチェックの機能   用いることで、それぞれロケーションに合わせてHost Firewall ポリシーへ動的に変更することが可能です。 この記事では例を挙げて、Host Firewallポリシーを動的に割り当てる方法について説明します。 Host Firewallの概要を理解するにはこちらを参照ください。   端末情報を用いた条件設定でポリシーを動的に割り当て 端末のIPアドレスを条件に指定する   端末のIPアドレスをポリシーの適用条件に用いることで、ポリシーを動的に変更します。 例えば以下のスクリーンショットのように拠点AのIPレンジがX.X.X.X、拠点BのIPレンジがY.Y.Y.Yの場合といったように、 拠点毎のポリシーを作成しておきます。 （以下のスクリーンショットの青枠のところ）   端末はそれぞれの拠点のネットワークに接続した時に、割り当てられたIPアドレスが評価され、拠点毎のポリシーが適用されます。 どのIPレンジにも含まれないIPアドレスが割り当てられた場合、一番最後に適用されるWindows Defaultというポリシーが適用されます。 「社内のIPアドレスレンジ以外のアドレスが割り当てられた場合」という条件にして社外ルールを作成することも アイデアの１つとしてあると思います。 （以下のスクリーンショットのオレンジ枠のところ）         IPレンジで拠点・事業所など社内ネットワークを表現する場合、 「Range」という演算子を使って社内ネットワークのIPアドレスの範囲で定義し、 端末のIPアドレスを評価するようにします。     一方、社外ネットワークを表現する場合、 「Not In Range」という演算子を使って社内ネットワークのIPアドレスの範囲で定義し、 端末のIPアドレスを評価するようにします。     指定したホストの名前解決を用いて内部・外部ネットワークを判定しFWルールを動的に割り当て   この方法はAgent SettingsにあるNetwork Location Configurationという機能を用います。 社内ネットワークにいる場合、内側からしかアクセスできないシステムなどがあると思います。 そのシステムの名前解決ができることを根拠にして内部ネットワークに位置する、 という判断をするのがこの機能の役割です。 反対に名前解決できなければ外部ネットワークに位置すると判断されます。   内部ネットワークと判断されると、Host Firewallプロファイル内のInternal Rule Groupsで定義したFirewallルールが適用されます。外部ネットワークと判断されると、Host Firewallプロファイル内のExternal Rule Groupsで定義したFirewallルールが適用されます。 つまり、会社の外にいると社外用のFWルールが、社内にいると社内用のFWルールを適用する、 といった運用ができるようになります。   例えば、以下のようにHost Firewallプロファイル内でInternal Rule Groups(ルールなし)とExternal Rule Groups(外用のルールあり)が構成されており、   Network Location Configurationにと或るホストとIPアドレスを定義するとします。   端末側において、設定したホストの名前解決ができている場合、   内部ネットワーク用のルール(Internal Rule Groups)が適用され、管理コンソールで以下のようなメッセージが表示されます。   一方、名前解決ができない場合、   外部ネットワーク用のルール(External Rule Groups)が適用され、管理コンソールで以下のようなメッセージが表示されます。       このように社内・社外でルールを分けて適用したい場合、Cortex XDRは２つの方法を持っています。 運用環境に合わせてこれらの機能を活用いただければと思います。     Tech Doc Network Location Configurationの詳細はこちら       ... View more

この記事では、Cortex XDR Prevent及びXDP Pro per Endpointが標準機能として持っている ホストファイアウォール機能について紹介します。   ホストファイアウォール機能は   ・インバウンド・アウトバウンド双方のファイアウォールルールの作成 ・端末情報を活用したポリシーの動的な割り当て ・名前解決を用いたロケーションの識別による内部・外部ルールの割り当て   などきめ細かなルールを作成することができます。 この記事ではベーシックなインバウンド・アウトバウンドのファイアウォールルールの作成方法について ご紹介します。   ホストファイアウォールルールの構造について   ホストファイアウォールルールは以下のような構造になっております。 ポリシーは上から順に評価されます。ポリシの評価を行う条件は端末情報（ホスト名やIPアドレスなど）が用いられますが、 条件に一致した一番最初のポリシーが端末に適用されます。どの条件にも一致しない場合、 一番最後に定義された「Windows Default」というポリシーが適用されます。   (1)ポリシーA (Extention Policy)   | -- (2) プロファイル(Host Firewall Profile)         |-- (3) Internal Groups         |        |-- (4) Rule Group         |        |        | - Group01 - Block 139,445/TCP Inbound         |        |        |            |        |        | - Group02 - Block 20/21/TCP Outbound         |-- (3) External Groups         |        |-- (4) Rule Group         |        |        | - Group01 - Block 139,445/TCP Inbound         |        |        |         |        |        | - Group03- Block 20/21/80/TCP Outbound         |  (1)ポリシーBA (Extention Policy)   | -- (2) プロファイル(Host Firewall Profile)   |  (1)Windows Default (Extention Policy)   基本的にCortex XDRはAgentに対してポリシーを適用することで各種セキュリティ機能が有効になりますが、 これはHost Firewallについても同じです。   ProfileとGroups(Internal Groups/External Groups) Host Firewallの場合Host Firewall Profileというプロファイルでルールを作成していきます。 プロファイルの中ではInternal GroupsとExternal Groupsの２つのグループに分かれており、 内部ネットワークに位置すると認識され時にInternal Groups、外部ネットワークに位置すると認識された時にExternal Groupsが適用されます。 この内部・外部の識別は別の記事で説明したいと思いますが、識別を必要としない場合Internal Groupsにルールを定義していきます。   Rule Group Internal Groups ,External GroupsいずれもGroupsという言葉が含まれているとおり、 複数のルールグループを定義することができます。 例えば、あるルールグループは社内共通、別のルールグループは事業部個別のルールといったように ルールグループを組み合わせて柔軟な制御ができます。   以下ではサンプル設定を元にHost Firewallポリシーの作り方を説明します。   Rule Groupを作成する | Endpoints | - | Host Firewall |から「New Group」をクリックします。     ここでは例として、ファイル共有を使用した外部アクセスをブロックしてみます。 ルールグループの名前を「ファイル共有アクセス制限」とし「+ New Rule」をクリックします。   ルールを以下の通り設定します。 Name: ファイル共有アクセスのブロック Platform: Windows, macOSにチェック Protocol: TCP(6) Direction: Outbound Action: Block Remote Port: 139,445     DirectionがOutboundの場合、ポート番号の他にIPアドレス（Remote IP Address）なども条件に指定することができます。 Inboundの場合も同様です。   また、以下のスクリーションショットにあるとおり、 アプリケーションやサービスの名前で範囲を制限することも可能です。 なおブロックした時のアクションを記録したい場合は「Report Matched Traffic」をEnabledにします。   ルールが定義できたら「Create」をクリックします。 以下のようにグループ内にルールが定義されるのを確認したら「Create」をクリックします。     | Endpoints | - | Host Firewall | - | Rule Groups |から作成したグループを確認できます。 このルールグループは他のプロファイルなどで再利用可能です。   Extensions Profileを作成する 次に Host Firewall Profileを作成するためにExtensions Profilesから「+ Add Profile」をクリックし、 「Create New」を選択します。       ここではWindowsからHost Firewallを選択します。     「事業所A」という名前のプロファイルとし、 Internal Rule Groupsに対して、先程作成したルールグループを設定してみます。「+ Add Group」をクリックします。   作成した 「ファイル共有アクセス制限」にチェックし、「Add (x Selected)」をクリックします。   Internal Rule Groupsに対して、ルールグループ「ファイル共有アクセス制限」が追加されました。 「Create」をクリックすると、     Host Firewallプロファイルが作成されました。   PolicyにHost Firewallプロファイルを割り当てる 作成した「事業所A」というHostFirewallプロファイルを「事業所A用ポリシー」というExtensions Policy Ruleに割り当てます。 （この例では事前に「事業所A用ポリシー」という名前のポリシーを作成しています。） 「事業所A用ポリシー」をクリックし、ペンのアイコン選択します。          Host Firewallから「事業所A」プロファイルを選択し、Nextをクリックします。   確認画面でチェックボックスにチェックを入れ、「OK」ボタンをクリックします。   適用対象を選択します。ここではあるホスト名を持つ端末だけに適用し、「Next」をクリックします。   最後に確認画面が表示されるので問題がなければ「Done」をクリックします。   最後必ず「Save」ボタンをクリックしてください。   Saveするとこのようにポリシーが追加され、Targetに指定された条件の端末にHost Firewallポリシーが適用されます。     端末側の表示を確認する 端末側のMicrosoft Defender Firewallを開くと、 Cortex XDRが管理しているためアクセスできなくなっております。     試しにWindowsサーバー(ここではIPアドレスが192.168.68.102)の共有フォルダにアクセスすると、 アクセスできなくなり、以下のメッセージがOSから返ってきます。       管理コンソールでイベントを確認する ルールを作成する時に、「Report Matched Traffic」をEnabledにしましたが、 こうするとブロックした時のイベント(Allowの時は許可イベント)を管理コンソールで確認することができます。 | Endpoints | - | Host Firewall | - | Host Firewall Events | を選択するとイベントビューが表示されます。 このビューは１つのレコードが、60分毎にエンドポイントで集計されたデータになっています。         XQLを使用してイベントを検索する Host Firewallのイベントは「host_firewall_events」というdatasetに保存されるため、 これを用いてイベントの検索・分析も可能です。     Tech Doc Host Firewallの機能詳細についてはこちら   ... View more

この記事では、Filterコマンドと、Dedupコマンドについてご紹介します。 XQLの概要を理解したい場合は、こちらの記事も合わせてお読みください。   Filter 指定したフィールドをキーにして結果をフィルタリングします。 例えばfilterに以下のように設定すると、agent_hostnameにpc001を含むデータだけが検索結果として表示されます。 filter agent_hostname = "pc001"   and演算子やor演算子を組み合わせて複数のフィールドの値を条件に検索することも可能ですし、 (=)だけでなく様々な比較演算子があるので、こちらも併せてご確認ください。   filter action_remote_port = 3389 and agent_os_type=ENUM.AGENT_OS_WINDOWS   Dedup 指定したフィールドをキーにして検索結果の重複を排除します。    dedup actor_process_image_name   dedupもfiterl同様に、複数のフィールドをキーにして検索結果の重複を排除ができます。   dedup actor_process_image_name, agent_hostname       例：RDP(3389)を使用したプロセス名を列挙する XQLは、リモートポートが3389でかつWindows OSで発生したイベントだけにフィルターし、 検索結果をプロセスのイメージ名(actor_process_image_name)で重複排除し、 実際に3389ポートを使用したプロセス名だけを列挙します。   dataset = xdr_data | filter action_remote_port = 3389 and agent_os_type=ENUM.AGENT_OS_WINDOWS | dedup actor_process_image_name     まず、リモートポートが3389でかつWindows OSで発生したイベントだけ抽出します。 dataset = xdr_data | filter action_remote_port = 3389 and agent_os_type=ENUM.AGENT_OS_WINDOWS     1,092件の結果が出てきました。actor_process_image_nameに注目すると、 1,092件のイベントのうちmstsc.exeを含むイベントが53.48%, mstsc.exeを含むイベントが46.52%、 であることがわかります。     ここでdedupを使ってactor_process_image_nameをキーに重複排除します。 dataset = xdr_data | filter action_remote_port = 3389 and agent_os_type=ENUM.AGENT_OS_WINDOWS | dedup actor_process_image_name     powershell.exeを持つイベントは複数件ありましたが重複排除され1件、 同様にmstsc.exeを持つイベントも1件となり、これでRDP(3389)を使ったプロセス名を抽出することができました。     Tech Doc Filterコマンドの詳細はこちら Dedupコマンドの詳細はこちら   ... View more

この記事ではXQLを使って直近30日間アクセスのない端末を検索してみます。 直近30日間アクセスのない端末の定義は、 現在の時間とエンドポイントの管理情報の「Last seen」の時間差を取って30日以上開きのあるもの、 としています。 Last seenの詳しい説明はこちらを確認してください。   作成したクエリは以下のとおりです。   dataset = endpoints | alter 30days_before_from_now = to_timestamp(add(to_epoch(current_time()),-2592000)) | filter last_seen <= 30days_before_from_now | fields endpoint_name ,30days_before_from_now, last_seen   実際にクエリを実行すると、直近30日間アクセスのない端末の名前、last_seen、今から30日前の日時が、 出力されます。     以下ではこのXQLクエリについて簡単に解説します。 まず、この部分ですが、 to_epoch(current_time()) current_time()関数で現在時間を取得し、to_epoch関数でepoch timeに変換します。 epoch timeに変換するのは、次のadd関数で時間を足し算するときに正の整数にする必要があるからです。 (epoch timeは正の整数)   次にadd関数でepoch timeに変換した現在時間から-2592000秒足した時間、つまり30日前の時間を求めます。 2592000は30日間を秒に直した数値（30days x 24h x 60m x 60s）です。 add(to_epoch(current_time()),-2592000)   その後to_timestamp関数で、epoch timeをタイムスタンプ型に変換し、 alterコマンドで30days_before_from_nowという変数に30日前の時間を設定します。 これでおおよそ30日前の時間が求められます。 alter 30days_before_from_now = to_timestamp(add(to_epoch(current_time()),-2592000))   30days_before_from_nowとlast_seenを比較し、 last_seenの方が小さいデータだけ、つまり30日前からアクセスのないデータだけに フィルタリングします。 filter last_seen <= 30days_before_from_now   最後にエンドポイント名、30日前の時間、last_seen、３つのフィールドだけを抽出します。 fields endpoint_name ,30days_before_from_now, last_seen     ダッシュボードで管理する XQLはWidgetにしてダッシュボードに埋め込めば、都度検索しなくても常時確認することができます。   Tech Doc to_epoch関数, add関数, to_timestamp関数についてはこちら alterコマンドについてはこちら         ... View more

Cortex XDRはインシデント対応の機能として、端末隔離の機能があります。 隔離をした時、あるいは隔離を解除するときに端末側でメッセージを表示することができます。         ただしメッセージはいずれも表示されてから数秒後に消えてしまうので、 エンドユーザーが隔離状態にあるのか分かりにくい、といった事情がありました。   隔離時のメッセージを常時表示する Agent Settingの以下の２つの設定を有効にすることで、隔離時のメッセージが常時表示されるため、 エンドユーザーが端末の状態を把握しやすくなります。 *エージェントはver7.8以降であることに注意してください。   Persistent Isolation Notification Blocked Connectivity Notification     これによってメッセージは常時表示されますが、ユーザーが「x」ボタンを押すと閉じてしまうので その点注意してください。 もしうっかり閉じてしまっても、アイコンやコンソールに表示される「隔離済み」という情報から 端末が隔離状態であることを確認することができます。       Tech Doc 設定箇所の説明についてはこちら   ... View more

Compコマンドは集計するための機能で、以下のような機能を提供しています。   approx_count, approx_quantiles, approx_top,avg, count, count_district, earliest, first, last, latest, list, max, min, sum, values   この記事では、count、avgという集計機能についてご紹介します。 XQLを簡単に理解したい場合は、こちらの記事も合わせてお読みください。   Count 指定したフィールドをキーにして検索結果のレコードを集計します。   ここではサンプルデータとして、３つのホスト("www.spotify.com ","www.google.cp.jp ","edge.microsoft.com")に アクセスしたエージェントの名前、アクセス先ホスト名、プロセスのイメージ名、宛先IPアドレスを抽出し、 そのデータに対してcount機能を使ってみようと思います。   まず以下のXQLでサンプルデータを抽出します。 config timeframe between "2022-12-12 10:00:00 +0900" and "2022-12-12 11:00:00 +0900" | preset = xdr_agent_network | fields agent_hostname, action_external_hostname , actor_process_image_name , action_remote_ip | filter action_external_hostname in ("www.spotify.com "," www.google.co.jp ","edge.microsoft.com")   15件見つかりました。   次にcount機能を使って、上の15レコードをaction_external_hostname毎にレコード数を集計します。 上のXQLに1行追加(青字のところ)したのが以下のXQLになります。   config timeframe between "2022-12-12 10:00:00 +0900" and "2022-12-12 11:00:00 +0900" | preset = xdr_agent_network | fields agent_hostname, action_external_hostname , actor_process_image_name , action_remote_ip | filter action_external_hostname in ("www.spotify.com ","www.google.co.jp ","edge.microsoft.com") | comp count(action_external_hostname) as number_of_count by action_external_hostname   XQLを実行すると15件のレコードがアクセス先のホスト(action_external_hostname)毎に集計されたことが 分かります。       さらに、集計のフィールドにagent_hostnameを加える(青字のところ)と、 15件のレコードが、action_external_hostnameとagent_hostnameが集計のキーとして使用されます。 config timeframe between "2022-12-12 10:00:00 +0900" and "2022-12-12 11:00:00 +0900" | preset = xdr_agent_network | fields agent_hostname, action_external_hostname , actor_process_image_name , action_remote_ip | filter action_external_hostname in ("www.spotify.com ","www.google.co.jp ","edge.microsoft.com") | comp count(action_external_hostname) as number_of_count by action_external_hostname ,agent_hostname   実際に実行すると、agent_hostnameフィールドがキーとして追加され集計されていることがわかります。     AVG avgはinteger型（整数）のフィールドの値を集計し、平均値を求めることができます。 ここではサンプルデータとして、指定した時間帯に発生したファイルアクティビティのログから、 ある端末のファイルサイズが0以上のログを5件抽出します。   config timeframe between "2022-12-09 10:00:00 +0900" and "2022-12-09 10:30:00 +0900" | preset = xdr_file | fields agent_hostname, action_file_name, action_file_size ,action_file_name | filter action_file_size > 0 and agent_hostname = "WIN-0TNTTQOMGDR" | limit 5   実際に実行すると、ファイル名と、そのサイズを抽出します。 2つのファイルとそれぞれにファイルサイズがあることがわかります。     avgを追加して、ファイル名（action_file_name）毎に平均値を求めるXQLを追加します。 （青字のところ）   config timeframe between "2022-12-09 10:00:00 +0900" and "2022-12-09 10:30:00 +0900" | preset = xdr_file | fields agent_hostname, action_file_name, action_file_size ,action_file_name | filter action_file_size > 0 and agent_hostname = "WIN-0TNTTQOMGDR" | limit 5 | comp avg(action_file_size) as avg_action_file_size by action_file_name   XQLを実行すると、ファイル毎の平均値が表示されていることがわかります。     このようにCompコマンドには様々な集計用の機能が用意されています。 他の集計機能については別の記事でご紹介していきたいと思います。   Tech Doc countについてはこちら avgについてはこちら       ... View more

 Cortex XDRはレスポンスアクションとして、端末側で任意のスクリプトを実行できる機能があります。 Cortex XDRが持つビルトインのスクリプトの他、お客様が自作したインシデント対応用スクリプトなども 実行することができます。   ここでは、簡単なサンプルスクリプトを用いて自作のスクリプトを実行する方法について説明します。 なとスクリプトはPython 3.7に対応している必要があります。   使用するスクリプトは、端末のホスト名とtrueという文字列をDictionaryで返すという単純なものです。 import socket def sample_script(): hostname=socket.gethostname() return { "hostname": hostname, "test": "true" }     自作スクリプトの設定 Script Library「New Script」ボタンをクリックします。   青字のBrowseをクリックしコードをアップロードします。上記のファイルをsample.pyという名前で アップロードしてみます。     Script Nameにアップロード時のファイル名が埋め込まれます。これは編集可能です。 そのほかDescriptionやSupported OS、Timeoutなども設定します。   Inputで Run by entry endpointを選択し、エントリポイントとする関数を選択します。 この例では「sample_script」という関数しかないので、「sample_script」を選択します。   Outputでは、sample_scriptの戻り値を設定します。 DictionaryオブジェクトだったのでOutput TypeでDictionaryを選択します。 この例では２つのキーを定義してしているので、それらを設定します。 Friendly Nameを設定すると、実行結果をスクリプトの変数名ではなく指定した名前に置き換えて表示します。   上記のDefenitionsに記載された項目（General, Input, Output）はManifest fileというファイルを アップロードしていただき設定するやり方もあります。こちらは一番下にあるTech Docのリンクから ご確認ください。     「Create」をクリックすると、    Scripts Libraryに登録されます。     スクリプトの実行  作成したスクリプトを右クリックし「Run」を選択します。   以下のような画面に遷移します。   スクリプトを実行したいエンドポイントを選択します。   設定内容を確認して実行すると、   実行結果の確認   All Actionsで実行ステータスを確認できます。 Completed Successfullyになっていればスクリプトの実行が 完了しています。     実行した結果から「Additional Data」をクリックすると、   結果を確認できます。 変数「hostname」「test」に入ってきた値を確認できます。   3台の端末で実行して全て成功   「test」はtrueしか返さないので3件のtrueが得られた   「agent host name」はそれぞれの端末のホスト名が得られた      青色の「Generate report」をクリックすると、Reportsから実行結果をpdfファイルでダウンロードできます。     スクリプトの実行結果を同じ画面ですね。   ご参考 Response ActrionでCISベンチマークを実施するスクリプトを実行するサンプルが紹介されておりますので、 １つのアイデアとして参考にしていただければと思います。 https://live.paloaltonetworks.com/t5/cortex-xdr-discussions/dtrh-cis-benchmarking-3rd-party-data-ingestion-data-parsing/m-p/511039#M2461   Tech Doc カスタムスクリプトの設定の詳細はこちら ... View more