The Identity object is representing a user identity or role. In the context of traditional environments it represents a user account. An Identity can be owned by a User or a Group, can be protected by necessary Credentials and can give access to Applications and Data.

The level of access an Identity provides is defined by the connections between the Identity object and Application objects (like Application, and derivatives like Routing Firewall, IDPS, System) and Data object.

The account specific properties, like password quality and similar, are defined in the Credential object connected to the Identity object.



Please see the Application section.


An Identity can be connected to Data in three different ways; WritePrivileges, ReadPrivileges and DeletePrivileges. By selecting one of the different connections, the access level granted to the Identity is defined.


The Identity "Nomen.Nescio" (representing Nonen.Nescio's user account) has WritePrivileges on the Data representing the home directory of Nomen.Nescio.


Please see the Group section.


A RoutingFirewall is derived from the Application type of object. Therefore, connecting an Identity to a RoutingFirewall object is defining which Identity (user account) has which access to (administering) the RoutingFirewall.
Please see the Application section for more information.


An IDPS is derived from the Application type of object. Therefore, connecting an Identity to a IDPS object is defining which Identity (user account) has which access to (administering) the IDPS.
Please see the Application section for more information.


Please see the Credentials section.


A System object is representing the actual hardware an Application (including operating system software and hypervisors) is running on. Connecting an Identity object to a System object defines which Identity has access to managing the hardware.
Please see the System section for more information.


Connecting an Identity to a User defines which User has access to which Identities. In the following example, the user "Nomen Nescio" (without a dot) owns the "Nomen.Nescio" Identity/user account.


The Identity "Nomen.Nescio" belongs to the User "Nomen Nescio".

Nested Identities

Identity objects can be connected to other Identity objects. This is used to represent which Identities automatically grant access to other Identities.

A simple example is a Windows user Identity which is set up to be allowed to execute commands as the local Administrator Identity.

When connecting an Identity to another Identity, we get to select between the options "CanAssume (childId --> parentId)" and "CanAssume (parentId --> childId)" for defining which Identity can assume which other Identity.

Similarly to nesting Applications, start the connection from the parent Identity (like Nomen.Nescio) and end it at the child Identity (like Administrator) and select the second option ("CanAssume (parentId --> childId"). In this context, Administrator is the child Identity since it is the Identity that is "secondary" or "assumable" from the "original" Identity of Nomen.Nescio.


The Identity Nomen.Nescio can assume the Identity Administrator.

A more complex example is when, in an Active Directory environment, an Identity has the SeImpersonate privilege. However, due to the granularity and complexity of an Active Directory structure, it is recommended to use automatic model generation to create Active Directory models.



Attack step nameAttack step purpose
AssumeSucceeding with executing in the context of the Identity.
AttemptAssumePrerequisite attack step to Assume.


Defense nameDefense purpose
DisabledThe likelihood of an Identity not being present. When representing several actual (implemented) systems with a single set of objects, the Disabled property can be used to define how likely it is that a certain Identity with related connections/properties is present.