[New Rule] Added user account

[janniten]

Summary

Detecting when an user is being created is important not only because it can be an indicator that the system is compromised and an attacker is trying to increase access to a system/domain but also when legal activities needs to be audited for compliance
There is one detection rule for windows "User Account Creation" that is base on the analysis of process execution and process execution arguments.
This rule is cross-plataform and it is based on ECS event fields (category, type and outcome) and it works well for the standard winlogbeat logs, auditbeat logs and also for custom logs mapped into ECS (example Fortinet's logid 0100032132)

[threat-punter]

Hi @janniten. Thanks for opening this pull request 🥳

I really like how you're utilizing ECS in your queries to alert on behavior across different platforms.

I believe that some security teams, especially those that are monitoring large networks, will not want to be alerted each time a new user account is created. Do you have any ideas or suggestions on how to narrow the scope of this rule to alert on suspicious behavior and minimize false positives for security analysts?

[janniten]

Hi @threat-punter,
I understand your point in this context:

• the security operations are well defined and controlled (proper segregation of duties are in place, audit trails are configured in order to keep track Admin/Sec Admin's activities)
• large networks where you only need to detect an user creation done by an intruder (I think that is the goal of the exixting rule based on process execution)

My thoughts:
In my experience (working in mid-size Telco companies) the security operation is never so well defined and segretated. In addition if the company are under strong security regulations such as Sarbanex and Oxley or PCI you need to detect and react to this kind of activities even when done by admins.
Maybe if we think in with the mind set in the compliance side it could be nice to have detection rules that can be mapped to compliance controls (PCI, CIS, etc) and have "Compliance Dashboards". I did something like that many years ago using Zabbix in order to have PCI compliance deviations.
That is why I though of this rule.
One way to narrow the rule is to add context specific information, for example not user.name: (sec_adm1 or sec_adm2 or...) . (**) Probably this kind of "compliance/control" rules should have context information in order to detect deviations of the baseline of operation.

Now I'm using this rule in an hospital, where there are many "hands" creating users across different platforms. and since they don't have an Identity Management platform nor dedicated security administrators we need to keep track this activities

I can close the PR if the rule is not useful in general, no problem :)
Anyway just to satisfy my curiosity I'll try to map the 20 CIS critical controls into DR to see what I get

Thank you!

(**) there are some experimental changes in ECS 1.7.0 that uses a different way to model user relationships in an event.
https://github.com/elastic/ecs/releases (elastic/ecs#1017)

In this case, the way to narrow should be to use the user.effective field

[threat-punter]

Thanks for your detailed response @janniten. I think that this will be better suited as a custom rule for security teams, who want to alert on every user creation event.