This document summarizes structural and data quality findings derived from the FLORES pipeline outputs. For each minor version, the <major>/<minor>/analysis/ directory contains:
CHANGELOG.md— intra-version field conflicts (description, data type, length) and inter-version diffstraffic_matrix.csv,event_matrix.csv,utm_matrix.csv— field × subtype occurrence counts, showing which fields appear in which log subtypes
The consolidated <major>/fields/ CSVs aggregate across all minor versions of that major:
traffic_fields.csv— all Traffic log fieldsevent_fields.csv— all Event log fieldsutm_fields.csv— all UTM log fieldsaction_descriptions.csv— UTMactionfield values per subtype (one column per subtype, since values diverge too much to consolidate)
UTM is structurally the most heterogeneous log type. Its subtypes (antivirus, IPS, web filter, application control, DNS, DLP, email filter, SSL, ICAP, WAF, SSH, VoIP, GTP, anomaly, casb, virtual-patch, file-filter) are developed independently, and it shows.
action is present in every UTM subtype but means something different in each one. The table below maps each subtype to its length and the values it actually carries (sourced from 7.6.6/analysis/CHANGELOG.md):
| Subtype | Length | Description / values |
|---|---|---|
| APP-CTRL | 16 | pass / block / reject / reset |
| IPS | 16 | detected / dropped / reset / reset_client / reset_server / drop_session / pass_session / clear_session |
| Virus | 18 | blocked / passthrough / monitored / analytics (Sandbox submission); some Virus LOGIDs have no description |
| DLP | 20 | log-only / block / exempt / ban / ban-sender / quarantine-ip / quarantine-interface (several marked "Not in use since FortiOS 5.0") |
| Webfilter | 11 | blocked / passthrough |
| WAF | 17 | Deny / Start / (all others = allowed by firewall policy) |
| SSH | 17 | passthrough / blocked |
| VoIP | 15 | "Action. Eg. block, allow" |
| DNS | 16 | "Security action performed by DNS filter" |
| Anomaly | 16 | "Action" (no further detail) |
| EmailFilter | 8 | (no description) |
| FILE-FILTER | 20 | (no description) |
| ICAP | 17 | (no description) |
| SSL | 20 | (no description) |
| casb | 11 | (no description) |
| virtual-patch | 16 | (no description) |
Six of sixteen subtypes have no description for action at all. The length ranges from 8 (EmailFilter) to 20 (DLP, FILE-FILTER, SSL) with no consistent logic. Compared to traffic (length 16) and event (length 65), this single field illustrates why a unified schema mapping cannot cover all log types.
action_descriptions.csv exists precisely to capture this divergence — one column per UTM subtype — but the six undocumented subtypes above have empty columns.
GTP logs (18 LOGIDs, LOGID range 41216–41228+) are structurally incompatible with the rest of UTM:
- Fields
fromandtoare typedipin GTP butstringin every other UTM subtype (DLP, Virus, EmailFilter, Webfilter, VoIP all usestring, length 128). - GTP-specific fields (
cgsn6,endusraddress6,msgtypename,timeoutdelete,ulimcc,ulimnc,upteid,ugsn6,from6,to6) have no descriptions across all 18 LOGIDs — approximately 150+ undocumented fields. - GTP logs mobile core network traffic (GPRS Tunneling Protocol), a completely different domain from web/endpoint security. It shares the UTM log type classification but has no semantic overlap with other UTM subtypes.
Any unified schema template for UTM will break on GTP's ip-typed fields or require a separate mapping.
UTM has 21 fields with multiple type or length combinations within its own subtypes. Traffic and Event have zero such fields. Selected examples:
| Field | Variants |
|---|---|
msg |
lengths 512, 518, 4096 |
virusid |
types string/uint32, lengths 10/64 |
service |
3 distinct lengths (5, 36, 80) |
direction |
lengths 8 and 4096 |
reason |
lengths 128 (VoIP) and 4096 (ICAP) — 32× difference |
Beyond GTP, undocumented fields are widespread:
| Category | Missing descriptions |
|---|---|
| GTP (18 LOGIDs) | ~150+ fields |
| Virus (73 LOGIDs) | ~80 fields (~42 per LOGID in some cases) |
| ICAP (LOGID 60000) | ~30 fields |
| APP-CTRL | 9 fields |
| DNS | 6 fields |
The CHANGELOG.md in each minor version's analysis/ folder records 133 description conflicts for 7.6.0 alone — cases where the same field name has different or empty descriptions across LOGIDs within the same version.
Across all three log types (Traffic, Event, UTM) in 7.6.0:
| Scope | Field count |
|---|---|
| UTM unique fields | 262 |
| Traffic unique fields | 198 |
| Event unique fields | 390 |
| Total union | 712 |
| Shared across all three | 37 (5.2%) |
Breakdown of overlap:
| Group | Fields |
|---|---|
| Event only | 319 |
| Traffic only | 121 |
| UTM only | 171 |
| Traffic + UTM | 30 |
| Event + UTM | 24 |
| Event + Traffic | 10 |
95% of fields are absent from at least one log type. A unified schema would be overwhelmingly sparse, increasing storage overhead and complicating query patterns. Separate indices or tables per log type (or per subtype) are the practical outcome.
Even within a single log type, subtypes diverge:
- Traffic: HTTP-Transaction has 60 fields; Forward/Local/Multicast have 172 — a 2.9× spread within one log type
- Event: System has 165 fields; REST API has 17 — a 9.7× spread
- UTM: Virus has 99 fields; FORTI-SWITCH has 18 — a 5.5× spread
The 4 cross-type data type conflicts that force incompatible mappings:
| Field | Traffic | Event | UTM |
|---|---|---|---|
channel |
uint32 |
uint8 |
— |
filesize |
— | uint32 |
uint64 |
rcvdbyte |
uint64 |
uint64 |
uint32 and uint64 |
xid |
— | uint32 |
uint16 |
LOGIDs are not evenly distributed across categories — but the count disparity is a symptom of a deeper problem: there is no consistent model for what constitutes a distinct event type.
Each FortiOS team decided independently whether to encode an outcome (block, allow, monitor) as a new LOGID or as a value in the action field of a shared LOGID. Both approaches exist in the same product, with no documented rule governing which to use:
Separate LOGID per outcome — VideoFilter assigns three LOGIDs for the exact same event depending on its result:
13664 LOG_ID_VIDEOFILTER_CATEGORY_BLOCK13665 LOG_ID_VIDEOFILTER_CATEGORY_MONITOR13666 LOG_ID_VIDEOFILTER_CATEGORY_ALLOW
DNS does the same: 54400 LOG_ID_DNS_URL_FILTER_BLOCK vs 54401 LOG_ID_DNS_URL_FILTER_ALLOW. CASB follows suit: 10000 LOG_ID_CASB_ACCESS_BLOCKED, 10001 LOG_ID_CASB_ACCESS_BYPASS, 10002 LOG_ID_CASB_ACCESS_MONITOR.
Antiphishing goes further, splitting by both rule source and outcome — 6 LOGIDs for what is functionally one event type with two variables:
13648 LOG_ID_ANTIPHISH_URL_ALLOW,13649 LOG_ID_ANTIPHISH_FTGD_ALLOW,13650 LOG_ID_ANTIPHISH_DEFAULT_ALLOW13651 LOG_ID_ANTIPHISH_URL_BLOCK,13652 LOG_ID_ANTIPHISH_FTGD_BLOCK,13653 LOG_ID_ANTIPHISH_DEFAULT_BLOCK
Single LOGID, outcome in action — Anomaly uses 3 LOGIDs split by protocol, not by outcome:
18432 LOGID_ATTCK_ANOMALY_TCP_UDP18433 LOGID_ATTCK_ANOMALY_ICMP18434 LOGID_ATTCK_ANOMALY_OTHERS
The action field carries detected/dropped/reset across all three. Virus splits by notification type (WARNING vs NOTIF) rather than outcome — 8192 MESGID_INFECT_WARNING and 8193 MESGID_INFECT_NOTIF cover the same infection event; the action field distinguishes blocked from passthrough from monitored.
The consequence for parsing is that neither LOGID alone nor action alone is a reliable classifier across the board. For VideoFilter, LOGID determines the outcome and action is redundant. For Anomaly, action determines the outcome and the LOGID only tells you the protocol. A SIEM parser must know which pattern a given subtype follows before it can correctly classify an event — and that knowledge is not expressed anywhere in the log stream itself.
| Category | LOGIDs | Unique fields |
|---|---|---|
| System | 628 | 171 |
| Wireless | 201 | 84 |
| VPN | 78 | 63 |
| Switch-Controller | 65 | 39 |
| User | 54 | 41 |
| HA | 37 | 30 |
| SDWAN | 17 | 60 |
| Endpoint | 18 | 36 |
| REST API | 2 | 33 |
| CIFS-auth-fail | 4 | 30 |
| WAN opt | 5 | 28 |
| Security-rating | 3 | 27 |
| web-svc | 2 | 27 |
| Router | 10 | 21 |
| Connector | 6 | 20 |
| Webproxy | 2 | 19 |
| FortiExtender | 11 | 16 |
| Telemetry | 4 | 12 |
System and Wireless together account for the overwhelming majority of Event LOGIDs. Wireless in particular has over 200 LOGIDs covering fine-grained association, roaming, interference, and rogue AP events — most of which are rarely seen in production deployments.
| Subtype | LOGIDs | Unique fields |
|---|---|---|
| Virus | 77 | 103 |
| Webfilter | 65 | 95 |
| APP-CTRL | 15 | 89 |
| DLP | 6 | 86 |
| GTP | 18 | 86 |
| FILE-FILTER | 2 | 75 |
| IPS | 7 | 75 |
| SSL | 21 | 69 |
| EmailFilter | 5 | 63 |
| virtual-patch | 4 | 61 |
| DNS | 13 | 58 |
| WAF | 12 | 55 |
| Anomaly | 3 | 49 |
| VoIP | 7 | 47 |
| SSH | 10 | 46 |
| ICAP | 3 | 44 |
| casb | 3 | 44 |
| FORTI-SWITCH | 1 | 18 |
| Debug | 1 | 12 |
| Subtype | LOGIDs | Unique fields |
|---|---|---|
| Forward | 15 | 186 |
| Sniffer | 2 | 186 |
| Local | 2 | 170 |
| Multicast | 2 | 170 |
| ZTNA | 1 | 170 |
| HTTP-Transaction | 1 | 77 |
Traffic is the most uniform log type: Forward, Sniffer, Local, Multicast, and ZTNA subtypes cluster tightly between 170–186 fields. The exception is HTTP-Transaction, which has a single LOGID and only 77 fields — it captures HTTP-level metadata not present in the others.
The schema is not a ratchet — fields and LOGIDs are both added and removed between minor versions. The inter-version diff section of each analysis/CHANGELOG.md is the authoritative record of these changes.
| Version | LOGIDs added | LOGIDs removed | Fields added | Fields removed |
|---|---|---|---|---|
| 7.6.1 | 22 | 1 | 30 | 2 |
| 7.6.2 | 0 | 0 | 2 | 0 |
| 7.6.3 | 25 | 0 | 17 | 15 |
| 7.6.4 | 17 | 2 | 25 | 3 |
| 7.6.5 | 14 | 0 | 11 | 2 |
Additions consistently outnumber removals, so the net trend is growth — but removals are real. 7.6.3 is the most disruptive: 15 fields removed in the same release that added 17.
Schema churn between minor versions creates several concrete problems:
Field removals break parsing rules. A SIEM ingestion pipeline built against 7.6.2 that extracts or normalizes any of the 15 fields removed in 7.6.3 will silently produce nulls or parsing errors after a FortiGate upgrade — with no indication from the device itself that the field disappeared. Detection rules or dashboards referencing those fields stop working without any alert.
Field additions go unnoticed without version tracking. When 22 new LOGIDs and 30 fields appear in 7.6.1, a SIEM that doesn't track schema versions will either drop the new fields (if using a strict mapping) or ingest them untyped (if using dynamic mapping), both of which degrade data quality. New fields often carry security-relevant context — ignoring them means incomplete detections.
No version field in the log itself. FortiGate logs do not embed the FortiOS version that generated them. A SIEM receiving logs from a mixed fleet (some devices on 7.6.2, some on 7.6.4) cannot distinguish which schema applies to a given log line. Fields that were removed in 7.6.3 may still arrive from older devices, while new fields from 7.6.4 devices will be absent from older ones — in the same index, at the same time.
The only explicit deprecation markers in the 7.6 documentation appear as values within the action field for the DLP subtype (utm_fields.csv, action_descriptions.csv):
| Value | Status | Replacement |
|---|---|---|
ban |
Not in use since FortiOS 5.0 | blocked |
ban-sender |
Not in use since FortiOS 5.0 | quarantine |
quarantine-ip |
Not in use since FortiOS 5.0 | (none stated) |
quarantine-interface |
Not in use since FortiOS 5.0 | (none stated) |
These are values, not fields — the action field itself is still present and active. However, a device that predates FortiOS 5.0 (or has legacy config) could still emit these values. A SIEM normalizing action to a controlled vocabulary would need to decide whether to map them to their replacements or treat them as unknown. There is no equivalent marker for any other field or value across the rest of the schema.
telemetry— new Event subtype, +12 fieldsweb-svc— new Event subtype, +27 fields
New subtypes arrive without announcement in the docs; the analysis/CHANGELOG.md inter-version diff is the only structured record of these additions.