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.
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.
|Attack step name||Attack step purpose|
|CompromiseGroup||Become 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 name||Defense purpose|
|No defenses defined.||A Group object has no defenses defined to it.|
Updated over 1 year ago