Identity

Purpose

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.

Connections

Application

Please see the Application section.

Data

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.

Group

Please see the Group section.

RoutingFirewall

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.

IDPS

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.

Credentials

Please see the Credentials section.

System

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.

User

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.

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.

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.

Properties

AttackSteps

Defenses