Application

Purpose

The Application object is representing any type of application that is running in an environment like for instance;

Operating systems
Client applications
Service applications
Partial applications like libraries
In addition to the above, the following object types are based on the Applciation object, i.e. they inherit the Application's properties but have some additional features;
IDPS
RoutingFirewall

Connections

Nested Applications

Applications can be connected to other applications. By doing that, one of the applications are defined as a parent application and the other application is defined as a child application. When creating such a connection, make the connection starting from the parent application and release it on the child application. Then select the lower option when prompted for the link type: AppExecution (appExecutedApps --> hostApp).

709 — Start from the Parent Application, release the connection on the Child Application and select the lower option.

The connection hierarchy can be verified by enabling the "endpoint labels" in securiCAD Enterprise. The hostApp label is showing which application is hosting the child application.

662 — Ubuntu is hosting Apache which is hosting Wordpress.

One parent application can host many child application but one child application can only have one parent each.

Identity

High and Low privilege user accounts

When modeling an Application, it is recommended to connect at least one Identity object to it. For representing a regular/limited user account, select the LowPrivilegeApplicationAccess and for a high/full privilege user account, select the HighPrivilegeApplicationAccess link type. (In the picture below, the "link labels" are used instead of the "endpoint labels".

947 — root is a high privilege user account and www-data is a low privilege user account.

Execution Privileges

The ExecutionPrivilegeAccess connection is used to define under which user account a certain application is running. In other words, when you gain access to an application, which user account it gives you access to.

952 — Gaining access to the Apache service will provide access to the www-data (low privilege) user account on the Ubuntu operating system.

Group

A Group object connects to an Application object in the same way as an Identity object does. The only difference is that a Group object can have multiple Identity objects and also other Group objects as nested members.

906 — Server Owner is member of sudoers which in turn has HighPrivilegeApplicationAccess to the operating system. N.B: This is a simplified example. The model can be detailed further to also take what actual sudo privileges a user has into account.

ConnectionRule

Connecting an Application object to a ConnectionRule object is defining allowed communication related to it. In other worde, defining specific reacability. Available options are InApplicationConnection for allowing incoming requests, OutApplicationConnection for allowing outgoing requests and ApplicationConnection for defining both incoming and outgoing requests as allowedto the very same application.

Using an InApplicationConnection will make an application act as a service and using an OutApplicationConnection will make it act as a client application.

The "in" and "out" labels only refer to the reachability and the initiation of the requests. Once an incoming request has been made, the connection is considered bidirectional.

1045 — Apache is ready to respond to incoming requests and NW Clients is representing any network capable client software installed in Ubuntu (curl, nslookup, firefox, nc, etc).

Network

Connecting an Application object to a Network object is defining in which way the application is reachable from the (local) network. Possible connections are ClientAccess and NetworkExposure. ClientAccess is used for applications that can initiate connections to other applications on the network while NetworkExposure is used for services that are ready to respond to incoming requests.

1046 — Apache has got NetworkExposure to the LAN and NW Clients have ClientAccess.

Please note that it is not required to relate the LAN and the connection rules for incoming/outgoing requests in any way. The connections to the LAN is about communication coming from and going to any application also connected to the same network, while the connection rules are defining that incoming/outgoing communication is allowed from/to the other endpoint(s) the connection rule is connected to in the model. Therefore, it is not required to detail (or know) technically how one application can make contact with an other application or network. It is, from a threat modeling perspective, enough to state that it is possible.

Data

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.

AppContainment

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.

710 — /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

Please refer to the section describing the Data object in this language reference guide.

IDPS

An Application object can be connected to an IDPS object in three ways; AppProtection, AppExecution (appExecutedApps --> hostApp) and AppExecution (hostApp --> appExecutedApps).
####AppProtection
A connection between an application and an IDPS defines that the application is protected by an solution for intrusion detection and prevention, like for instance web application firewall functionality.

735 — Apache protected by a WAF solution.

AppExecution

The two AppExecution options are for defining which parent application the IDPS (application) is hosted by. An IDPS object is actually inheriting its functionality from the Application object which means that it has all the properties of an application but is also capable of protecting other applications. However, the operating system it is running on (hosted by) can in turn have vulnerabilities and be compromised.

Like with the parent/child application relation, connect from the parent (OS) to the child (IDPS) and select AppExecution (appExecutedApps --> hostApp).

522 — The Snort IDPS is running on a Debian machine.

RoutingFirewall

An Application object can be connected to a RoutingFirewall object in three ways; ManagedBy, AppExecution (appExecutedApps --> hostApp) and AppExecution (hostApp --> appExecutedApps).

A RoutingFirewall object is not representing a physical or virtual actual firewall appliance but instead is representing the management of the firewall functionality. Traffic does not (from a modeling perspective) pass through the RoutingFirewall object. Instead, the firewall policies are represented by the ConnectionRule objects. The ConnectionRule objects can however be connected to a RoutingFirewall object in order to define which firewall is managing them. (Or, from an attacker's perspective, which ConnectionRules I can change if I compromise a certain RoutingFirewall object.)

In relation to an Application object, a RoutingFirewall object can be managed by or hosted by an application. The following example is inspired from a typical PaloAlto setup with centralized management. The firewall appliance is running on the PanOS operating system, it is managed by the Panorama centralized management solution and the RoutingFirewall object ties it together with the different policies defined in it.

1189 — The PaloAlto firewall is running on PanOS and is also managed by the Panorama management solution (which in this case is installed on some other machine, represented as the top right application object).

A more detailed description of the RoutingFirewall object is found in the RoutingFirewall section.

SoftwareVulnerability

A SoftwareVulnerability can be connected to an Application object and is representing the presence of a security issue with the Application. Which actual type of software security issue the Application has is defined by the different properties (defenses) of the SoftwareVulnerability.

Examples of vulnerability types that can be represented;

CVE vulnerabilities, i.e. confirmed, disclosed vulnerabilities with or without exploits.
CWE vulnerabilities.
Server-side vulnerabilities.
Client-side vulnerabilities.
Kernel vulnerabilities.
Misconfigurations.

The exploitability and the impact of a vulnerability is also defined using the defense-properties.

For a detailed description, please see the section describing the SoftwareVulnerability object.

UnknownSoftwareVulnerability

The SoftwareVulnerability object will shortly be decommissioned from coreLang.

SoftwareProduct

Connecting a SoftwareProduct object to an Application object is adding "release" related security properties to the Application.

This makes it possible to connect SoftwareVulnerabilities to the SoftwareProduct to define release-specific vulnerabilities.

The SoftwareProduct object can also, in combination with a Data object, define the origin of an Application. In other words, if the origin of the Application, where the SoftwareProduct is connected to) is compromised, then the Application is also considered compromised.

836 — Defining release-specific vulnerabilities and defining the origin of an Application installation.

System

Connecting an Application object to a System object is defining which hardware it is hosted by. It is often optional to define which hardware an operating system is running on. The addition of System is mainly interesting when also taking hardware vulnerability analysis into account. Since System can also be connected to a PhysicalZone object, the System is also an interesting object for such analysis.

However, a System object does not represent an operating system or a virtual machine. These are represented using nested Application objects instead.

For a virtualized environment, where several systems, or guests, are running on top of a hypervisor, the different operating systems of the guests shall be connected as child application to a parent application which will be representing the hypervisor. This hypervisor can then be connected to a System object.

Properties

AttackSteps

Attack step name	Attack step purpose
AccessNetworkAndConnections	Once access is gained to an Application, you will also have access to any Network or ConnectionRule object it is connected to.
AttemptLocalConnectViaResponse	LocalConnect is, in contrast to NetworkConnect, making contact with this application from a connected/local child or parent application. "ViaResponse" means that this application does not respond to connections, i.e. it is behaving like a client and the attacker need to wait for a session. "Attempt" means that this attack step is before the LocalConnectViaResponse (successful) attack step.
AttemptNetworkConnectViaResponse	NetworkConnect is, in contrast to LocalConnect, making contact with this application via a connected Network or ConnectionRule object. "ViaResponse" means that this application does not respond to connections, i.e. it is behaving like a client and the attacker need to wait for a session. "Attempt" means that this attack step is before the NetworkConnectViaResponse (successful) attack step.
AttemptReverseReach	ReverseReach ispresenting the probability of successfully achieveing a "call home" situation where the Application makes a call back to the Attacker, i.e. the Attacker's starting point in the model. "Attempt" means that this attack step is a prerequisite to the (hidden) ReverseReach attack step which in turn lead to SpecificAccess or FullAccess.
AttemptUseVulnerability	AttemptUseVulnerability is a prerequisite to succeeding with SpecificAccess or FullAcces via a vulnerability.
Authenticate	Gaining SpecificAccess or FullAccess via known, stolen or guessed Credentials.
Deny	Denial of Service.
FullAccess	Succeeding with superuser access.
LocalConnect	LocalConnect is, in contrast to NetworkConnect, making contact with this application from a connected/local child or parent application.
Modify	Altering the Application. Depending on the vulnerability, or if a SoftwareProduct origin has been compromised, the Application might be possible to alter. E.g. adding your own payloads and change application behavior.
NetworkConnect	Making a connection to the application via network. (Via connected Netowrk or ConnectionRule objects allowing connectivity.)
NetworkConnectViaResponse	Making a connection to the application via network. (Via connected Netowrk or ConnectionRule objects allowing connectivity.) However, this case is for when the Application acts as as a client application and the attacker has to rely on user interaction or callback sessions being initiated.
Read	Reading the application code and data.
SpecificAccess	Gaining limited access to the application.
SpecificAccessAuthenticate	Gaining limited access to the application by using credentials.
UnsafeActivityByUser	Succeeding with convincing a user to help with a connection back to the attacker. Some vulnerabilities require user interaction.

Defenses

Defense name	Defense purpose
Disabled	Defines whether the Application exists or not. This is useful from a threat modeling perspective when information about application presence is not known. It can also be used to state that for instance "20% of the servers represented by this application has RDP enabled". It can also be used to represent services that are temporarily enabled, or enabled on schedule.
SupplyChainAuditing	Blocks a supply chain attack by stating that applications/updates/libraries are reviewed before being deployed.