Office 365およびAzureのデータ可用性🔗

データ可用性と収集時間🔗

Secureworks® Taegis™ XDRの取り込み時間は、データの収集、正規化、保存にかかる時間を表します。元のログデータのタイムフレームとXDRの取り込み時刻との間に差異が生じる場合、ソースAPIからのデータの可用性の遅延が含まれることがあります。すべてのAzureおよびOffice 365のデータ収集と、それに伴うデータ可用性は以下の基準に従います。

データは、ポーリング間隔と呼ばれる一定の間隔で定期的にポーリングされます。ポーリング間隔は、収集アプリケーションがAPIにデータをリクエストする間に待機する分数を定義します。各ポーリング間隔ごとに、ポーリング間隔に等しい分数から現在時刻まで、さらに過去4時間分がクエリされます。
- この収集方法により、すべての分が2回クエリされます。1回はポーリング間隔内、もう1回は4時間前です。これは、Microsoftから遅れて到着するデータ（例：最初にクエリされた時点では利用できず、後で利用可能になるデータ）に対応するためです。データが発生してから4時間以上経過して到着した場合は収集されません。重複データはXDRプラットフォームによって重複排除され、最初に記録されたログのみが保存されます。
- 使用される間隔は、XDRで収集されたさまざまなお客様のMicrosoft APIから観測されたデータ可用性に基づいています。ポーリング間隔の目的は、特定のAPIのレート制限を超えずに、できるだけ早くデータを取得することです。データ可用性の変化が観測された場合、ポーリング間隔は変更されることがあります。
XDRコンポーネント間のデータ転送および変換は、ストリーミングまたは継続的に行われます。データ転送には最大10分かかる場合がありますが、通常は1分未満で完了します。
データの書き込みは4分ごとにバッチで行われますが、最大10分かかる場合があります。
データは60～90分以内にインデックス化され、検索可能になりますが、より早く利用可能になる場合もあります。
データから生成される検知は、使用される検知機の性質に依存します。XDRの検知機についての詳細は検知機の概要をご参照ください。検知は検索やインデックスには依存しません。

重要

APIによって過去の時刻でアクティビティログが提供される場合、Event Create Time（イベント作成時刻）と Ingest Time（取り込み時刻）の間にタイムスタンプの差異が見られることがあります。これは、_Event Create Time_が元データの観測タイムスタンプに基づき、_Ingest Time_がSecureworksがAPIからログを収集・正規化した時刻に基づくためです。

データ収集の変数🔗

Microsoft Office 365 Management API🔗

Office 365 Management Activity APIは、データをクエリする際にいくつかの変数を入力できます。このセクションでは、これらの変数がデータ収集時にどのように使用されるかを説明します。

ポーリング間隔：1分
Content Type — XDRは以下のコンテンツタイプを使用します：Audit.AzureActiveDirectory、Audit.Exchange、Audit.SharePoint、Audit.General、DLP.All。
startTimeおよびendTime — 各ポーリング間隔ごとに、startTimeは現在時刻からポーリング間隔を引いた時刻、endTimeは現在時刻に設定されます。また、startTimeは4時間前からポーリング間隔を引いた時刻、endTimeは4時間前に設定されます。これは、Microsoft Management Activity APIが遅れてヒストリカルデータを公開または利用可能にすることが知られているためです。このため、Secureworksは常に4時間前のデータも再度クエリし、すでに記録済みのアクティビティログは削除します。

Microsoft Graph API—Alerts Resource🔗

Microsoft Graph APIのalert resource typeは、データをクエリする際にいくつかの変数を入力できます。以下は、これらの変数がデータ収集時にどのように使用されるかを説明します。

ポーリング間隔：1分
List alertsは、指定した期間の利用可能なアラートのリストを取得するために使用されます。
IDのリストが返された後、Get alertが各新しいアラートの取得に使用されます。アラートのリスト化には_OData_フィルターlastModifiedDateTimeが利用されます。各ポーリング間隔ごとに、アラートはlastModifiedTimeが現在時刻以下（le）かつ現在時刻からポーリング間隔を引いた時刻以上（ge）、および4時間前以下、4時間前からポーリング間隔を引いた時刻以上でクエリされます。これは、Microsoft Graph APIのアラートリソースが遅れてヒストリカルデータを公開または利用可能にすることが知られているためです。このため、Secureworksは常に4時間前のデータも再度クエリし、すでに記録済みのアクティビティログは削除します。

Microsoft Graph API—Directory Audit Resource🔗

Microsoft Graph APIのdirectoryAudit resource typeは、データをクエリする際にいくつかの変数を入力できます。以下は、これらの変数がデータ収集時にどのように使用されるかを説明します。

ポーリング間隔：10分
list directoryAuditsは、指定した期間の利用可能なディレクトリアuditログのリストを取得するために使用されます。
IDのリストが返された後、get directoryAuditが各新しいログの取得に使用されます。アラートのリスト化には_OData_フィルターactivityDateTimeが利用されます。各ポーリング間隔ごとに、auditログはactivityDateTimeが現在時刻以下（le）かつ現在時刻からポーリング間隔を引いた時刻以上（ge）、および4時間前以下、4時間前からポーリング間隔を引いた時刻以上でクエリされます。これは、Microsoft Graph APIが遅れてヒストリカルデータを公開または利用可能にすることが知られているためです。このため、Secureworksは常に4時間前のデータも再度クエリし、すでに記録済みのアクティビティログは削除します。

Microsoft Graph API—Sign In Resource🔗

Microsoft Graph APIのsign-in resourceは、データをクエリする際にいくつかの変数を入力できます。以下は、これらの変数がデータ収集時にどのように使用されるかを説明します。

ポーリング間隔：10分
list signInsは、指定した期間の利用可能なサインインログのリストを取得するために使用されます。
IDのリストが返された後、get signInが各新しいログの取得に使用されます。アラートのリスト化には_OData_フィルターcreatedDateTimeが利用されます。各ポーリング間隔ごとに、ログはcreatedDateTimeが現在時刻以下（le）かつ現在時刻からポーリング間隔を引いた時刻以上（ge）、および4時間前以下、4時間前からポーリング間隔を引いた時刻以上でクエリされます。これは、Microsoft Graph APIのサインインリソースが遅れてヒストリカルデータを公開または利用可能にすることが知られているためです。このため、Secureworksは常に4時間前のデータも再度クエリし、すでに記録済みのアクティビティログは削除します。

Microsoft Azure Active Directory Activity Reports🔗

データは、ポーリング間隔とラグタイムという2つの設定パラメータを使用して定期的にポーリングされます。

ポーリング間隔：10分
ポーリング間隔は、APIがデータをクエリする頻度を指定します（例：10分ごとにAPIが10分間のデータウィンドウをクエリ）。
ラグタイムは、データがクエリされる際にインジェスターが現在時刻からどれだけ遡るかを指定します。複数のラグタイムがあり、データはより頻繁にクエリされます。ラグタイムは、1分、10分、20分、30分、40分、1時間、2時間、4時間前です。

Microsoft Azure Monitor API—Activity Log Resource🔗

ポーリング間隔：30分
list Activity Logsは、指定した期間内のすべてのアクティビティログを取得するために使用されます。
ログはeventTimestamp値を使用してクエリされ、各ポーリング間隔ごとに現在時刻からポーリング間隔を引いた時刻から現在時刻まで、さらに4時間前からポーリング間隔を引いた時刻から4時間前までクエリされます。これは、Microsoft Azure Monitor APIが遅れてヒストリカルデータを公開または利用可能にすることが知られているためです。このため、Secureworksは常に4時間前のデータも再度クエリし、すでに記録済みのアクティビティログは削除します。

データ収集内容と正確性🔗

すべての収集ケースにおいて、データ収集時に使用される変数は追加のログを公開する目的でのみ変更されます。ログ内のデータはoriginal_dataフィールドに保存され、レスポンスや元のログの内容を変更するような入力変数は使用されません。ユーザーがJSON/ログの内容に異常を経験した場合、Secureworksは、ログが保存またはAPIから返された際に不正な形式となる理由を特定するため、ベンダーと協力することを推奨します。

追加リファレンス🔗

Azure Active Directory reporting latencies
Search the audit log in the compliance center—Microsoft 365のデータ可用性およびレイテンシ情報を含みます