SOC Prime’s LogTotal now supports log exports from four major SIEM and EDR platforms: Google SecOps, CrowdStrike Falcon LogScale / Next-Gen SIEM, Microsoft Defender for Endpoint (MDE), and Microsoft Sentinel. Each platform uses its own file formats, field names, and data model. LogTotal handles those differences automatically, so security teams can upload exports as they are and get the same depth of analysis from every source. Support for Splunk, IBM QRadar, and OpenSearch/Elasticsearch is coming next.
What’s new: four platforms, one analyzer
The newly supported platforms each bring a different data model and different export options:
| Platform | Data model | Vendor-documented exports |
| Google SecOps | Unified Data Model (UDM), produced by parsers that normalize raw logs | Detection events as CSV, up to 100,000 events |
| CrowdStrike Falcon LogScale / Next-Gen SIEM | Native Falcon sensor field names; third-party data parsed to the CrowdStrike Parsing Standard (CPS), based on ECS | CSV, JSON, and plain text |
| Microsoft Defender for Endpoint | Advanced hunting schema, with tables such as DeviceProcessEvents | Advanced hunting results as an Excel workbook; CSV from guided mode |
| Microsoft Sentinel | Log Analytics tables queried with KQL; optional ASIM normalization | Query results as CSV from the Logs window |
No conversion scripts, field renaming, or custom parsers are needed for any of them.
Same event, four different descriptions
Every platform records the same activity in its own way. A single process launch carries different field names depending on where it was exported from:
| What a detection looks for | Google SecOps (UDM) | Falcon LogScale / NG-SIEM | Microsoft Defender for Endpoint | Microsoft Sentinel (ASIM) |
| Command line of the new process | target.process.command_line | CommandLine | ProcessCommandLine | TargetProcessCommandLine |
| New process image | target.process.file.full_path | ImageFileName | FolderPath + FileName | TargetProcessName |
| Parent or initiating process | principal.process.file.full_path | ParentBaseFileName | InitiatingProcessFileName | ActingProcessName |
The differences go beyond names:
- Different names for the same field. One concept, such as a command line, carries a different name on each platform.
- Different structure. UDM nests fields under principal and target, while MDE and Falcon use flat column names. Some values are split across fields, such as MDE’s FolderPath and FileName.
- Different naming within one platform. Next-Gen SIEM keeps native Falcon names for sensor telemetry and uses ECS-based CPS names for third-party data. Both can appear in a single export.
Usually, analysts bridge these gaps by hand before a single rule can run. With LogTotal, these differences are not your problem.
How LogTotal handles file formats
LogTotal detects the file format for you. SOC Prime documents automatic detection of EVTX, CEF, JSON, and syslog, with no manual conversion. LogTotal accepts uploaded or pasted .log, .json, .jsonl, .evtx, .csv and .txt files of up to 3 GB or 3,000,000 events and processes up to 1.7 million events in under a minute.
The platforms covered here differ most in how they package records:
- A single JSON array. LogScale’s JSON export wraps all events in one array. LogTotal reads each element as a separate event.
- CSV exports. Google SecOps, MDE advanced hunting, and Sentinel Logs export query results as CSV files, with each column header named after a field in that platform’s schema.
You do not need to flatten nested JSON, rename columns, or reorder fields before upload. Sanitization then runs locally in your browser on the parsed events, so the same identifiers are tokenized consistently whichever format they arrived in.
How LogTotal handles field names and mappings
LogTotal maps each platform’s field names to the fields its detection logic expects, so one rule evaluates correctly against all four schemas. Users do not maintain mappings, write parsers, or choose a schema.
This builds on mapping work SOC Prime already does for its detection content. SOC Prime’s platform support matrix lists rules for Google SecOps written against the UDM data schema, and Kusto queries for MDE and Sentinel written against their default schemas. LogTotal applies the same knowledge to exported files.
After mapping, events from all four platforms go through the same pipeline: about 1,000,000 detection rules and 13,000 threat labels, correlated with Higher Order Sigma rules and agentic AI into attack chains mapped to MITRE ATT&CK.
What this means for security teams
LogTotal takes care of format and schema differences for you. In practice:
- Export the way you already do. Use your platform’s standard export and upload the file as is.
- Mix sources in one investigation. Logs from different platforms are analyzed with the same rules and correlation, so findings are comparable.
- Keep your identifiers private. Sanitization replaces hostnames, IPs, usernames, and secrets with stable HMAC tokens before upload. You keep the key and can map tokens back internally.
- Get the same depth on every platform. Rule coverage does not depend on which SIEM or EDR produced the file.
For best results, export the fields that carry detection value, such as process, command line, parent process, user, host, and network details, rather than a reduced summary view. Where a platform offers both, prefer the full event export over a column subset.
Planned for Nearby Future
Support for exports from Splunk, IBM QRadar, and OpenSearch/Elasticsearch is planned. These platforms bring their own conventions, such as Elastic’s ECS field names. The experience will stay the same: export, upload, and let LogTotal handle formats and field mappings.