Nile SIEM Event Schema

introduction the security information and event management (siem) event schema defines the standardized structure and format of event data sent to siem platforms it plays a critical role in enabling effective security monitoring, threat detection, and compliance auditing by enforcing a consistent structure across various event types, the schema ensures accurate representation and seamless integration with security analytics tools supported event categories the nile siem event schema currently supports the following categories alerts real time notifications automatically generated by nile in response to predefined security conditions or anomalies audit events comprehensive logs of user and system activity, designed to support audit trails, compliance requirements, and forensic investigations end user device events telemetry and behavioral data from user devices that help monitor endpoint activity and identify potential security risks event format and integration nile uses a push based integration approach to deliver event data to siem systems this is implemented using the industry standard http event collector (hec) protocol with events formatted in json this ensures that event data is both structured and easily consumable by modern siem solutions important notes syslog based integrations are not supported all events are pre processed , well defined , and delivered exclusively in structured json format to maximize compatibility and simplify parsing please refer version 1 siem event schema for the latest json schema example of a complete payload below is a detailed overview of the siem schema based on various event types { "time" 1739963820, "sourcetype" " json", "event" { "version" "1 0", "id" "076096cf 93d8 41c7 92a1 0d7d0a4bda84", "audittime" "2025 04 09t04 53 59+00 00", "user" "cl hit test\@gmail com", "sourceip" "14 99 4 110", "agent" "mozilla/5 0 (windows nt 10 0; win64; x64) applewebkit/537 36 (khtml, like gecko) chrome/122 0 6261 128 safari/537 36", "auditdescription" "created ssid 'pipeline ssid building psk'", "entity" "ssid", "action" "create", "additionaldetails" { "newvalue" { "name" "pipeline ssid building psk", "ssid" { "security" "wpa2 personal", "segmentnames" \[ "pl segment building wo radius clhit" ] }, "tags" \[ "all" ] } }, "eventtype" "audit trail" } } time epoch time of the event sourcetype indicates the payload format, which is always json event actual siem event eventtype type of event supported values "audit trail" "nile alerts" "end user device events" "test" payload details for different event types audit events example of audit event payload ( eventtype =="audit trail") { "version" "1 0", "id" "076096cf 93d8 41c7 92a1 0d7d0a4bda84", "audittime" "2025 04 09t04 53 59+00 00", "user" "cl hit test\@gmail com", "sourceip" "14 99 4 110", "agent" "mozilla/5 0 (windows nt 10 0; win64; x64) applewebkit/537 36 (khtml, like gecko) chrome/122 0 6261 128 safari/537 36", "auditdescription" "created ssid 'pipeline ssid building psk'", "entity" "ssid", "action" "create", "additionaldetails" { "newvalue" { "name" "pipeline ssid building psk", "ssid" { "security" "wpa2 personal", "segmentnames" \[ "pl segment building wo radius clhit" ] }, "tags" \[ "all" ] } }, "eventtype" "audit trail" } version the version of the audit event schema id a uuid representing the event action indicates the type of action performed, such as “create,” “update,” “test,” “login,” “logout,” etc entity specifies the type of entity where the action was performed, such as “user,” “segment,” “dhcp,” “radius,” “mab,” etc additionaldetails contains information about the change it includes two fields “newvalue” and “oldvalue ” for an update event, both values are populated; for a create event, only the new value is provided the content of these fields depends on the entity type sensitive information like passwords or keys is excluded agent the user agent part of the http request auditdescription a human readable description of the event errormessage if the operation fails, this contains a descriptive error message; otherwise, it is null sourceip the ip address from which the action was performed audittime the timestamp of the event in iso 8601 format (yyyy mm dd't'hh\ mm\ ssxxx) user the user who performed the action end user events example of end user event payload ( eventtype =="end user device events") { "version" "1 0", "id" "8e2fc3b9 dbad 46f2 9a69 3fea72a7108d", "clientmac" "58 47\ ca 73\ cb\ e6", "clienteventseverity" "info", "clienteventtimestamp" "2025 04 30t09 33 52+00 00", "clienteventdescription" "dhcp renew request success", "connectedssid" "", "connectedbssid" "", "connectedport" "0/11", "connectedswitch" "0b 15 10 20 05 49", "clientusername" "clhit minis1", "clientlastknownipaddress" "10 151 82 63", "clienteventadditionaldetails" { "server ip" "10 132 14 2", "sourceserialnum" "e00a00064648", "ip address" "10 151 82 63" }, "eventtype" "end user device events" } id user device event id this will be uniquely generated for every user device event clientmac mac address of the end user device clienteventseverity severity of the event possible values info indicates success or informational events critical indicates failure scenarios clienteventtimestamp the timestamp of the event represented in iso 8601 format (yyyy mm dd't'hh\ mm\ ssxxx) clienteventdescription describes various client events related to authentication events for wireless (enterprise, psk, upsk, open, sso, captive portal, guest, etc ) and wired clients (mab, radius mac auth, dot1x) examples authorized event, disassociation event, authentication failed event dhcp and dns success and failure events for wireless and wired clients radius errors, including configuration errors, timeouts, null negotiation segments, etc , for wireless and wired clients client sticky errors and successes static ip, ip conflict errors, and success events (functionality yet to be enabled in production) sso and guest transition events credential related events example "clienteventdescription" "dhcp renew request success" connectedssid ssid name for wireless clients, ssid represents the actual ssid to which the client is connected example "ssid" "nile" connectedbssid bssid of the ssid for wireless clients, it represents the bssid to which the client is connected example "bssid" "26 15 10 2b 01\ c2" for wired clients, it represents the switch mac address example "bssid" "24 15 10 20\ c9 12" connectedport port details to which wired client is connected example port 0/40 connectedswitch switch serial number or mac address to which wired client is connected clientusername username of client example john doe\@company com clientlastknownipaddress last known ip address of client this will be current ip address for online client and last known ip address for offline or error clients clienteventadditionaldetails a json string containing formatted additional information, which can be null it may include server ip and serial numbers for dhcp, dns servers, etc in some events, it may also contain the client's ip address example "additionaldetails" "{\\"server ip\\" \\"10 4 5 1\\",\\"sourceserialnum\\" \\"a00a00076253\\",\\"ip address\\" \\"10 4 5 38\\"}" alerts example of alerts payload ( eventtype =="nile alerts") { "version" "1 0", "id" "ee0452ca fd53 4034 a3cf eb0a13287567", "alertsubscriptioncategory" "security alerts", "alerttype" "security", "alertstatus" "resolved", "alertsubject" "nile alert resolved \[security]", "alertsummary" "impersonation attack honeypot ap (bssid 26 15 10 21 13\ dc) spoofing a valid nile ap ssid pipeline ssid building psk has been detected in the air ", "impact" "this ap is not authorized to advertise network wifi service with the same ssid as nile service user devices may accidentally connect to the impersonating ap that is attempting a man in the middle intrusion this is a security issue ", "customer" "blr r2i hw cl hit hw", "starttime" "2025 04 09t05 06 11+00 00", "duration" "12 minutes", "site" "blr r2i hw cl hit s2", "building" "blr r2i hw cl hit s2 b1", "floor" "clhit testhw s2 b1 f1", "additionalinformation" "https //docs nilesecure com/nile security alerts", "eventtype" "nile alerts" } version the version of the alert event schema id uuid of the alert events will be sent when an alert is created and resolved this id can be used to correlate the information alertsubscriptioncategory these are the nile alerts categories, for example "nile service alerts" "infrastructure alerts" "application alerts" "security alerts" alerttype this indicates the type of alerts, for example “aqi” "high temperature" "link" "poe" alertstatus status of the alert valid values are "created" and "resolved" alertsubject describes the alert alertsummary textual summary of the alert impact describes the impact of the alert customer customer name site / building / floor names of the site, building, and floor respectively duration the duration of the alert, presented as descriptive text such as "10 minutes" or "1 hour 12 minutes" as seen in the nile portal starttime the start time of the alert in iso 8601 format (yyyy mm dd't'hh\ mm\ ssxxx) note this same schema is used for alerts over webhook integration