The Group object is representing a set of Identities with the same level of access.

Groups can therefore have the same privileges to applications and data as identities have.

N.B: A Group is a set of Identities, not Users.



A Group object connects to an Application object in the same way as an Identity object does. The only difference is that a Group object can have multiple Identity objects and also other Group objects as nested members.


Server Owner is member of sudoers which in turn has HighPrivilegeApplicationAccess to the operating system. N.B: This is a simplified example. The model can be detailed further to also take what actual sudo privileges a user has into account.


A Group can be connected to a Data object via ReadPrivileges, WritePrivileges and DeletePrivileges to represent the Group's access privileges to it.

IDPS and RoutingFirewall

Since both IDPS and RoutingFirewall are extended versions of the Application object, the same properties applies. Please see the Application description above.


Connecting an Identity to a Group represents that the Identity is member of the Group. Please see the example above with "Server Owner" being member of the "sudoers" group.

Nested Group Objects

Nesting Group objects is representing inherited memberships and access rights.


Both Domain Admins of Finance and Tech are members of Enterprise Admins. If you are Enterprise Admins, you inherit the access rights of Finance and Tech, but not the other way round.



Attack step nameAttack step purpose
CompromiseGroupBecome member of the group. This is not an attack targeting the group itself but instead is performed targeting an Identity that is member of the Group.
N.B: An important attack vector within Active Directory structures is performing different operations targeting Group objects as such. This is not covered in coreLang but will instead be covered in an Active Directory extension of coreLang.


Defense nameDefense purpose
No defenses defined.A Group object has no defenses defined to it.