Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECS event object fields order #316

Closed
willemdh opened this issue Feb 4, 2019 · 3 comments
Closed

ECS event object fields order #316

willemdh opened this issue Feb 4, 2019 · 3 comments

Comments

@willemdh
Copy link
Contributor

willemdh commented Feb 4, 2019

Hello, Imho it would be nice if the event object field descriptions were a little more clear in which fields are more general <> specific then others. It would also be nice to know which ones will have fixed values and which will be free to use as we (es users) want?

Not sure if I'm right, please correct me if I'm wrong, but the order seems more or less like this now.

event.kind > event.module > event.dataset > event.category > event.action > event.outcome

Where does event.type fit in all this?

I'm also a bit worried about several obvious fields which we are asked to use with caution...

event.type => Reserved for future usage. => Please avoid using this field for user data.
event.kind => In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.
event.category => In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.

Migrated several datasets to ecs in the meantime and I will definitely need 1 or more of the above fields in order to be able to structure my data.

Imho event.category should not be limited by a list of 'acceptable values'?

@webmat
Copy link
Contributor

webmat commented Feb 7, 2019

Yes I agree the current state is not very clear. We're working on this, and should clarify all of this soon.

@willemdh
Copy link
Contributor Author

willemdh commented Apr 15, 2019

Just to add an example to why we need some clarification to the categorization event fields:

This is a syslog event I'm trying to map to ecs from our Brocade switches:

<190>Apr 15 14:39:13 BROCADE raslogd: AUDIT, 2019/04/15-14:39:13 (CEST), [MAPS-1130], INFO, MAPS, admin/admin/1.1.25.147/http/Fabric Manager, ad_0/BROCAD/FID 128, 7.4.2c, , , , , , , Actions RASLOG,SNMP configured.

There are 2 types of Brocade logs: Brocade Switch logs and Brocade Advisor logs. The above logs is from Brocade Switch type:

See also http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-a00005955en_us-1.pdf for official Brocade documentation.

So I mapped:

event.module: brocade
event.dataset: brocade.switch
event.category: AUDIT
event.type: MAPS
event.action: RASLOG,SNMP configured
host.name: BROCADE
process.name: raslogd
log.level: INFO
user.name: admin

I see multiple issue with my above mapping:

event.category => In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.
=> So where would I have to put the category 'AUDIT'?
event.type => Reserved for future usage
=> So where would I have to put the subcategory 'MAPS'?

Please enlighten me so that I learn to understand where I'd have to put the above fields.

Also (but unrelated to this issue) is htat I seem to miss a field to put the user access level. In the above example:

admin/admin/1.1.25.147/http/Fabric Manager

the second admin is like the role of the user => Would it be an idea to have an ecs field user.role?

Grtz

@willemdh
Copy link
Contributor Author

Closing this, as this document makes things a lot more clear => https://docs.google.com/document/d/1TxpruDWAfd_5JavWyjpPEia4nMqt0YIIo1zRxAeu05g/edit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants