Parity with Elastic Endpoint

[rw-access]

As part of the EQL integration within Elasticsearch (elastic/elasticsearch#49581), it's important that we have maximum interoperability so that queries can run on the endpoint or on Elasticsearch, and this requires the schemas to be shared between them. There is still a significant delta, so we've been using the endgame.* namespace in the interim for anything unmapped to ECS. Hopefully, this can serve as a meta issue and I'll try to track endpoint-specific mappings from here:

Related Issues

• Case insensitivity (Case sensitivity for keywords #623) which EQL expects in general and seems fairly standard
• Digital signatures (Code signature field set #681)
• DNS (New use case: DNS #10)
• DNS Answers (Mapping for DNS events #596)
• DLL/Driver Fields (Driver and DLL fields #675)
• PE header metadata (PE header metadata #676)
• Process parent field set (Consider adding an equivalent field to endgame.parent_process_name in ECS #597), exit code (Add process.exit_code #600), command line (Add process.command_line #599)
• Unique Pid (Unique PID Fields and Generation #672)
• Windows Registry (Add registry fieldset #673)

Endgame mappings

Within our EQL analytics library, we have several fields that are mapped. I bolded the ones that are used in analytics within the repo, and checked off when mapped to ECS.

• authentication id / logon id -- for Windows, this is an identifier to reference the active token
• command_line-> process.command_line and process.args
• destination_address -> destination.address
• destination_port -> destination.port
• file_name -> file.name
• file_path -> file.path
• hostname -> host.hostname
• image_name (Driver and DLL fields #675)
• image_path (Driver and DLL fields #675)
• original_file_name (PE header metadata #676)
• parent_process_name -> process.parent.name (as of ECS 1.3.0)
• parent_process_path -> process.parent.executable (as of ECS 1.3.0)
• pid -> process.pid
• ppid -> process.ppid
• process_name -> process.name
• process_path -> process.executable
• protocol -> network.transport
• registry_data (Add registry fieldset #673)
• registry_key (Add registry fieldset #673)
• registry_path (Add registry fieldset #673)
• registry_value (Add registry fieldset #673)
• signature_signer (Code signature field set #681)
• signature_status (Code signature field set #681)
• source_address -> source.address
• source_port -> source.port
• total_in_bytes + total_out_bytes -> network.bytes
• unique_pid (Unique PID Fields and Generation #672)
• unique_ppid (Unique PID Fields and Generation #672)
• user this is just a more "qualified" domain + name combo (e.g. NT AUTHORITY\SYSTEM)
• user_domain -> user.domain
• user_name -> user.name
• user_sid -> user.id

Categorization

We also have a concept of enums for subtypes, which is really just a list of accepted values for a given field. This will add a layer of standardization when we standardize values for ECS, which is going to be very necessary if users expect to share across data sources.

Some of the values we've enumerated, which often map to Endgame's event_subtype_full or opcode fields. These all require solving categorization and enumerated values for event.category, event.type and event.action:

• network subtypes
  • incoming
  • disconnect
  • outgoing
• file subtypes
  • modify
  • create
  • delete
• process subtypes
  • create
  • terminate

[webmat]

Thanks for opening this, Ross!

With yesterday's 1.3 release, parent process details can be captured on the event, at process.parent.*. I'm editing the issue body to that effect.

ECS issues to open

• Can you open an issue or PR for adding registry support? There's no doubt in my mind that ECS needs to support registry events. The details of how we structure that can be hammered out over there, without crowding out this issue.
• Could you or @andrewstucki open an issue about unique PIDs? I don't recall the exact details of how Endpoint computes it. I think this would be a useful concept to spread via ECS, if the algorithm is simple enough to explain via schema documentation.

Questions

Here's a few points or questions wrt to the rest of what I see:

• 3 out of 4 fields are mapped for user details. Why isn't user mapped? What kind of value is typically in this field?
• total_in_bytes and total_out_bytes should probably be mapped to source.bytes and destination.bytes.
• What's a logon_id vs a user id?

[andrewstucki]

@webmat , @rw-access here's the unique pid discussion issue: #672

[webmat]

And Ross opened the registry discussion at #671

[webmat]

I'm looking at the body of the issue and I'm wondering why DNS is there. Could you open an issue stating specifically what's missing from your POV, from the current DNS field set?

[rw-access]

Oh sorry, I think DNS is good. I was just being verbose and linked to existing issues.