Event Category allowed values

[janniten]

Hi,
I'm working with some windows events related to changes in policies (audit policies, group policies, etc).
When I try to fit the event category in one of the allowed categories I'm not able to find a proper category.

Does it have sense to have a category called "policy"
Can be useful to track all events related to modification of auditory, password policies, security policies, etc

Thank you
Regards
Ana

[dainperkins]

Hi Ana, thanks for opening up the issue.

As I think back to the category discussion, we were expecting that any policy related events would fall under IAM (AD, Okta, or host level policy changes)

Something like this (I wrote a few iam related options in type & action)

• event.category: iam
• event.type: host | user | group | admin
• event.action: add_user | remove_group | change_policy | etc.

Would that fit the requirement?

thanks
/d

[janniten]

Hi Dain,
It does make sense to me when talking about changes in AD policies: audit policies, Special group Table, Group Policies, Password Policies,etc. So, I'll use this categorization. Thank you!.

But what if we talk about firewall/UTM policies (like Fortinet's logid=44547). Does also fits in the IAM categorization? That is the only case I have seen so far that I'm not sure if the IAM categorization fits well.
Thank you!
Regards
Ana

[dainperkins]

Ana, (@janniten)

I would say no, but I'm not 100% sure from looking at the docs. Let me dig into this one a little and see how it works out - worse case you can create your own fields (e.g. fortinet.rule etc.)

thanks
/d

[ebeahan]

Looking at Fortinet's log reference for 44547, it seems like this is an event generated when the Fortinet's configuration is changed? Could using event.category: database be appropriate here for that particular event type? Any thoughts @dainperkins ?

Obviously a Fortinet isn't a database, however the configuration file for network appliances are essentially maintaining the system's state the same way a database might for a web application. This will open up event types of access, change, info, and error in the categorization.

[webmat]

I could also see event.category: configuration and event.type: change. I think "configuration" is a bit more general, and could therefore be applicable in more situations. WDYT @janniten? Or do you think a more specific value of "policy" would be warranted?

[dainperkins]

@webmat & @ebeahan

using database seems like it would be confusing for implementers, and its not really indicative of many configuration mechanisms. I like the addition of a configuration category, otherwise had been thinking a combo of:

• event.category:host
• event.type: change, allow|deny
• event.action: configuration_changed

that being said I feel like this is one of those things that would benefit from a more detailed analysis of a typical admin interaction [ connect, authenticate, make changes (includes authz), save changes (includes authz), log off ]

[webmat]

Let's keep in mind that the content of event.action is not dictated by ECS. It's meant to capture the action, as defined by the source.

[dainperkins]

Aye, should have noted that... opens up more options for near term supports of these types of events.

[janniten]

I could also see event.category: configuration and event.type: change. I think "configuration" is a bit more general, and could therefore be applicable in more situations. WDYT @janniten? Or do you think a more specific value of "policy" would be warranted?

Hi @ webmat,
There are many events that I've been working from Windows, Fortinet and Oracle's auditory that would fit better under a configuration category (changes in the audit policy, changes in rule configurations, etc) category. That could help to improve event's classification

Regards!

[janniten]

Hi,
I'm staring to work with some windows events so..more examples....
I'll categorize them as category-> iam end type -> ["change","admin"]
but definitely I think that category -> "configuration" and type -> ["change","admin"] would fit better

EventID	Event
4706	A new trust was created to a domain
4713	Kerberos policy was changed.
4714	Encrypted data recovery policy was changed
4715	The audit policy (SACL) on an object was changed.
4716	Trusted domain information was modified.
4739	Domain Policy was changed.
4906	The CrashOnAuditFail value has changed.
4907	Auditing settings on object were changed.
4908	Special Groups Logon table modified.
4912	Per User Audit Policy was changed.
4616	The system time was changed.
4707	A trust to a domain was removed.
4902	The Per-user audit policy table was created.

Regards!