Mapping event_data to ECS

[latundetoks]

Hi,

For Windows system, security and sysmon, most events arelogged under the parent field "event_data.*" .

Some of these map easily into ECS like: IpPort,IpAddress,ProcessId. While others are not so straighforward: LmPackageName,TargetLogonId.

Is there a need for a top level for event_data or can they be patched under some other field such host.*.

Would like to know some guidelines on how these can be mapped into ECS without breaking future changes and keeping consistent with the goals of ECS.

Security Events:

"event_data": {
      "ProcessName": "-",
      "LogonGuid": "{6823A8C7-1FF6-3D97-7BE9-BCEE2D}",
      "LogonType": "3",
      "IpPort": "54313",
      "SubjectLogonId": "0x0",
      "TransmittedServices": "-",
      "KeyLength": "0",
      "LmPackageName": "-",
      "TargetLogonId": "0x1408bb25f",
      "SubjectUserName": "-",
      "IpAddress": "10.13.38.45",
      "SubjectDomainName": "-",
      "ImpersonationLevel": "%%1833",
      "ProcessId": "0x0",
      "TargetUserName": "N133973",
      "LogonProcessName": "Kerberos",
      "TargetDomainName": "DOMAIN",
      "SubjectUserSid": "S-1-0-0",
      "AuthenticationPackageName": "Kerberos",
      "TargetUserSid": "S-1-5-21-117609710-1482476501-18016745317"
    }

Sysmon Events

"event_data":{
		"DestinationIsIpv6":"true",
		"Image":"C:\\\\Program Files (x86)\\java.exe",
		"Initiated":"true",
		"ProcessGuid":"{BBBBBBBBB-CCCCC-0000-AAAAAAAAAAAA}",
		"ProcessId":"4924",
		"Protocol":"udp",
		"SourceIsIpv6":"true",
		"SourcePort":"5400",
		"UtcTime":"2018-11-22 19:27:56.107"
}

[MikePaquette]

@latundetoks As you say, some of the fields in event_data will map to ECS core fields, but (most of the) others are very much specific to windows events. Early this year, we discussed that they could live under service.windows.event_data.* but current ECS thinking is that these vendor-specific fields are outside the ECS core and extended objects/prefixes/namespaces, so you might consider 1) copying relevant event_data fields to the corresponding ECS fields 2) putting the rest (or all) of them at the top level under a vendor prefix such as windows.event_data.* Note: In doing so, there is some slight risk that someone else would use the windows.* top level objects, since these are not defined by ECS. If you were concerned about this, you could use a custom prefix such as mywindows.event_data.*

[willemdh]

Hello, imho windows is a very big component and at least the usual event log data, aka application, system and security should have core ecs fields asap to prevent that every ecs user start using its own implementation...

[DpoBoceka]

Hi.
Many people are using Elastic stack as their primary SIEM platform because it's no cost and quite flexible also. So it is sort of weird there is no final conclusion regarding the windows events mapping, although there are some fields to fill the need in already . For example, we can use service.* for describing the service-related events. Yes, it goes on the contrary with original meaning of service.* which's provided by ECS, but does it really matter in terms of Security Analyst? The one isn't going to collect the devops-related logs at all, or he'd have it stored in completely different index at the very least, so the searches won't interfere with each other, will they? You wouldn't you use in your searches something like
mywindows.event_data.service.name: "something-awful" OR mywindows.event_data.task.name:"something-bad" OR (mywindows.event_data.process.name: "bitsadmin.exe" AND mywindows.event_data.destination.hostname:"well-known-ioc")
I'd go nuts before I complete the line by hand correctly :)
We don't need to put the event_data into the event.* because almost all the valuable data consists of fields from there, so the rest of it just not much essential.
It would be just great if ECS covered up the "siem use-case" aswell and were a tad more open to considering it. If that'll be the case I'd contribute myself.
Hope we'll come to a solution, thank you!