Credentials

Purpose

The Credentials object is representing any type of credential asset like;

• Passwords
• Login keys
• Encryption keys
• Signing credentials/keys
• MFA tokens
• Hashing keys

The main purpose of credentials in a model is to represent how difficult it would be to guess, find, steal, use and reuse them.Some of these actions depend on the User properties NoPasswordReuse and SecurityAwareness. Others depend on the location of where these credentials can be found or if they might have been disclosed.

It is in most cases recommended to connect a Credentials object to each Identity object in a model.

Connections

Identity

Connecting a Credential object to an Identity object represents the Credentials necessary to use the Identity. If a user or an attacker possess the Credentials, it can impersonate the Identity.

For MFA, please see the Nested Credentials section below.

Data

Credentials can be connected to Data in four different ways; InfoContainment, EncryptionCredentials, SigningCredentials and Replica.

InfoContainment

InfoContainment is the most commonly used connection type and represents that the Credentials can be read from the Data once Read is achieved on Data. This connection is suitable for representing both a location (like a configuration file) where the Credentials fan be retrieved but also for default Credentials or disclosed/leaked Credentials.

For system-to-system communication, it is not unusual that for instance a web application has the credentials of a database stored in configuration files. This is modeled as follows.

If Credentials are either trivial/default or might have been leaked with some probability, it can be modeled using an InfoContainment to a (public) location that the attacker has got access to.

**EncryptionCredentials""

If a Credentials object is connected to a Data object with EncryptionCredentials, the Data is encrypted with the Credentials. In other words, in order to Read the Data, you also must gain access to the Credentials object.

SigningCredentials

The SigningCredentials connection is used for stating that you can not do Write on Data unless you also have the Credentials object connected with SigningCredentials. This is useful for modeling supply chain structures where signing of applications is used. You need to both gain Write access to the Data (representing for instance a software repository) and also gain access to the Credentials object in order to successfully Write to that Data.

Replica

Since, technically speaking, the Credentials object inherits from the Information object in coreLang, the Information property Replica is also present for Credentials. If the Credentials are replicated then writing, deleting, or denying them requires disabling the replicas which require access to all of the connected Replicas.

Nested Credentials

When more granular credential modeling is required, it can be acquired by using nested Credentials objects.

MFA

When an additional token is required for using the Credentials, this is modeled by connecting an additional Credentials object to the first Credentials object. In the following example, it is not enough to know the (default) username and password, but the attacker also need to gain access to the token in order to use the Credentials that are linked to the Identity.

When connecting a token (represented by an additional Credentials object) to a Credentials object, start from the "Username & Password" and release the connection at the "Token". Select the upper link type, i.e. "ConditionalAuthentication (requiredFactors --> credentials)".

Properties

AttackSteps

Defenses