The Data object is representing any type of location where information might be stored and extracted. For instance;

  • File systems
  • Databases and/or tables
  • Configuration files
  • Runtime memory
  • Dataflows/communication



A Data object can be connected to an Application object in three different ways; AppContainment, SendData and ReceiveData. AppContainment is used for defining data at rest while SendData/ReceiveData is used for data in transit.


An AppContainment connection to a Data object is defining which data set (like a file, a file system, a database table and so on) that an Application has access to. Or, from an attacker's perspective, if you gain access to the Application, which Data you gain access to.


/var/www is accessible both from the Apache application and from the operating system, while the entire file system is only accessible from the operating system.

/var/www is accessible both from the Apache application and from the operating system, while the entire file system is only accessible from the operating system.

SendData and ReceiveData

The SendData and ReceiveData connections between Application and Data objects are used to define data flows between the Applications.


Applications with data flows represented.


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.


The WebServer's configuration contains the Credentials used to access the DatabaseContent via the DatabaseUserIdentity Identity.

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.


Representing leaked or default credentials is done using InfoContainment to a public Data object. The likelihood of the Credentials being leaked can be adjusted using the DataNotPresent property of the Data (rockyou.txt) object.


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.


In order to successfully write to a software repository where signing is in place, the Credentials used for signing also needs to be acquired.


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 Data Objects

Nesting Data objects can be done to represent sub-sets of data which are contained in the same parent data set.


User directories are part of the main file system.

Group and Identity

A Group can be connected to a Data object via ReadPrivileges, WritePrivileges and DeletePrivileges to represent the Group's access privileges to it.

The same is valid for an Identity object connected to a Data object.

N.B: A User object can not be connected to a Data object, since the User will make use of its Identity to access the Data object. (A Group object is not a group of Users, but instead a group of identities.)

IDPS and RoutingFirewall

Both IDPS and RoutingFirewall can be connected to Data (via AppContainment, SendData and ReceiveData), since they are extensions of the Application object. For more details, see the Application description above.


Connecting an Information object to a Data object using the InfoContainment connection represents the presence of that Information in the Data. Using the Replica connection allows for connecting one Information object to several Data objects, making it less sensitive to Delete and Deny attacks. (All replicas need to be denied/deleted fir the Information to be denied/deleted.)


Since it is not possible to compromise a backup via the Information object, offline backups can be represented using the Replica connection type.


A Data object can be connected to a Network object in order to detail which networks a certain communication is traveling over. For a non-switched network (like for instance WiFi), the integrity of the data is dependent on the strength (and integrity) of the encryption key used to encrypt it. For a switched network, it is also protected by the EavesdropDefense parameter of the Network. Side note: this is to large extent distinguishing between wireless and wired networks.


Connecting a SoftwareProduct object to a Data object denotes that the SoftwareProduct is originating from the Data object. In other words, the Data is representing the software repository.
If a Credentials object is also connected to the Data object, the binaries of the software are signed and in order to alter them, the attacker also need to gain access to the signing credentials.


Connecting a Data object to a System object is representing "raw" storage solutions. For instance, Oracle databases can be set up to use raw storage devices, i.e. without a filesystem.



Attack step nameAttack step purpose
AccessAccessing the Data (in order to then read it).
ApplicationRespondConnectWhen used for representing a data flow between applications, this attack step is for responding to the data flow.
AttemptAccessPrerequisite to Access.
AttemptAccessFromIdentityPrerequisite to Access, making use of an impersonated Identity.
CompromiseAppOriginThen the Data is representing an application origin (repository) this attack step is for compromising the application hosted by the Data.
DeleteDeleting the Data.
DenyDenying the Data.
EavesdropWhen used for representing a data flow between applications, this attack step is for eavesdropping the data flow.
ExtractWhen the Data is connected to Information or Credentials, this attack step is for extracting the content.
MainInTheMiddleWhen used for representing a data flow between applications, this attack step is for tampering with the data flow.
ReadReading from the Data.
ReadContainedInformationReading the Information or Credentials within the Data.
WriteWriting to the Data.


Defense nameDefense purpose
DataNotPresentRepresenting the probability that the connected information, for instance a Credential object is actually present within the Data. This is used for representing for instance the probability of leaked or default credentials.