The Credentials object is representing any type of credential asset like;
- 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.
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.
Credentials can be connected to Data in four different ways; InfoContainment, EncryptionCredentials, SigningCredentials and Replica.
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.
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.
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.
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.
When more granular credential modeling is required, it can be acquired by using nested Credentials objects.
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)".
|Attack step name||Attack step purpose|
|AttemptAccess||Prerequisite to Read/Write/Delete/Use.|
|AttemptUse||Prerequisite to using credentials.|
|CredentialTheft||Succeeding with stealing the credentials. Can be due to reading a data set where the credentials are present.|
|CredentialsReuse||Succeeding with using the same credentials for authenticating as other identities. If one set of credentials is stolen from a user and the user has the PasswordReuse defense (partially or entirely) disabled, this attack step is applicable. Also, related to the Unique credential defense.|
|Delete||Deleting credentials from a Data the attacker has gained Write access to.|
|Deny||Denying the Data object holding the Credentials also lead to denying the Credentials.|
|GuessCredentials||Succeeding with a dictionary attack targeting the Credentials. Related to the NotGuessable defense on Credentials.|
|Read||Reading the Credentials. Prerequisite to AttemptUse.|
|Use||Using Credentials to authenticate and impersonate an Identity.|
|UseLeakedCredentials||Same as CredentialTheft but related to the NotDisclosed Credentials defense parameter.|
|Defense name||Defense purpose|
|NotDisclosed||Represents the (inverted) probability that the Credentials are disclosed/leaked.|
|NotGuessable||Represents the probability that the Credentials are strong enough not to be retrieved using a dictionary attack.|
|NotPhishable||Represents the probability that the Credentials are not possible to reuse even if successfully phished. Such credentials are for instance time limited login tokens.|
|Unique||Represents the probability that this particular credential is not used elsewhere in the model as well.|
Updated 12 months ago