elastic / ecs

Elastic Common Schema
https://www.elastic.co/what-is/ecs
Apache License 2.0
997 stars 413 forks source link

Software - Source/Destination and/or Client/Server #416

Open neu5ron opened 5 years ago

neu5ron commented 5 years ago

Looking into the ECS documentation I don't see a schema for software. I think this is different than user agent, which is more along the lines of HTTP user agent or such. This would include things like software name, major version, minor version, minor2, minor3, etc...

Therefore, I would like to discuss and propose adding or documenting a schema for software specifically for source and destination. I would be open to using source.user_agent. for this as well. But would like to discuss if software makes sense first.

This is especially useful in network data. For example when an ssh client makes a connection to an ssh server the client/source & destination/server software informatino is logged. Example data: source/client: OpenSSH_12.6p1 destination/server: Cisco-5.9

Using example data above

"source.software.original": "OpenSSH_12.6p1",
"source.software.name": "OpenSSH",
"source.software.version.major": 12,
"source.software.version.minor": 6,
"source.software.version.additional": "p1",
"destination.software.original": "Cisco-5.9",
"destination.software.name": "Cisco",
"destination.software.version.major": 5,
"destination.software.version.minor": 9,
webmat commented 5 years ago

"service" is related, but is more geared towards describing running software. Users may even use a different service name than the actual software that's running. So not a good fit indeed.

Another thing that comes to mind is the concept of "package". But once again, software is a more general concept. A package is just one of the ways to acquire software.

Also agree on user_agent. Not a fit at all. But based on your examples, the usage pattern you seem to have in mind is parsing a software identification string into its parts.

context

For the sake of discussion, how to you get your hands on these values? Is it via enrichment based on an asset inventory? Is it a some form of detection in your events/logs (like a UA can be present in a web log)? Or is it from active probing, like nmap, vulnerability scans or other?

webmat commented 5 years ago

To be clear, I like the idea of having the concept of "software". It could probably be used to reduce duplication in ECS. Fields about software are all over ECS :-)

neu5ron commented 5 years ago

so in bro and suricata there are a few different thingsthings like ssh.log with client&server software info. Also, windows logs will have software information riddled through a lot of logs.

Examples for Bro, which many would apply to suricata (just not have field names handy at the moment):

jamiehynds commented 2 years ago

@neu5ron sorry, it's been awhile on this issue, but curious to get your thoughts as to whether the package fieldset would meet the use case, or would you still be keen to see a software fieldset?