A regular workstation consist of several modeling objects. These represent the operating system, network applications, identities for limited/specific and full access to the workstation, the local storage and the hardware.
Representing a workstation can be done more or less detailed depending on if the workstation itself is interesting to analyze or not.
The simplified version consist of an operating system, a client application with network access and a user. This way, the workstation can act as a< potential starting-point for an attack.
The vulnerabilities used above represent one unknown vulnerability for the network client and one for the operating system. The defense parameters are as follows.
The simplified model of a workstation as described above is a suitable representation if the workstation in itself is not of main interest to the security analysis. However, there are more aspects to a workstation and therefore, we have also included a more detailed model here as well.
The operating system is modeled as the parent application to all other applications run by the operating system. One aspect that can be added is the origin of the operating system, since it is originating from somewhere and it also receives updates periodically. To represent this, add a SoftwareProduct object to the operating system Application object. Then, add a Data object and label it for instance "Software Vendor" and connect the SoftwareProduct object to the Data object using an Origin type of connection.
If applications and updates are being tested and reviewed before installation, this can be defined by setting the SupplyChainAuditing defense of the Application and/or the SoftwareProduct to 1. If we lack information about the software review process, we can set 0,5. If the company accepts updates without prior review, then the SupplyChainAuditing should be set to 0 which is also the default value.
The "Workstation User account" Identity pbject in the simplified model was connected to the operating system using LowPrivilegeApplicationAccess. We can also represent local admin by connecting an additional Identity with HighPrivilegeApplicationAccess to the operating system.
Depending on which Identity a user possess (or an Attacker manage to impersonate), parts of or the entire storage of a system is accessible. Therefore, we can detail this access by adding multiple Data objects to the operating system and connect them to different Identity objects.
In addition to web browsers, there are several other applications that, depending on configuration and permissions, are allowed to do network communication, such as specific business system clients (thick clients), powershell, MSSQL and Windows Explorer. However, the decision to add these explicitly to the model or not can be dependent on if we have specific information about them. E.g. if we have information about the configuration of MSSQL, then we can add it to distinguish it from other network-capable applications but if not, it is fine to let one Application represent multiple actual Applications on a workstation.
Antivirus and local firewall functionality is covered under the IDPS concept that is inspecting incoming binaries for well-known signatures and also heuristic inspection detecting suspicious behavior.
To represent this, an IDPS object can be added to the workstation model. Connect it to both the operating system and to the Browser application using the AppProtection type of connection. This way, we define that this application is protecting the other applications.
However, since the antivirus (IDPS) application is running on the local operating system, and can be managed by the local administrator, we need two more connections. Connect "OS of Workstation" to "IDPS" and select the "AppExecution (appExecutedApps --> hostApp)" to make the IDPS a child application of the operating system. Then add a connection from the "Workstation Admin" Identity to the IDPS and select "HighPrivilegeApplicationAccess" for that connection.
Finally, set the defense Effectiveness of the IDPS to a suitable value. The default value is 0 but 0,5 is recommended if we have no specific information about how efficient the antivirus solution is or how up to date it is kept.
For defining the physical location of this workstation, add a System object to the "OS of Workstation" Application object and, in turn, connect a PhysicalZone object to the System object.
In order to re-use this workstation model, it is recommended to save it as a separate model and then use "Import Model" to add it to a different model where the rest of the architecture is going to be modeled.
Connecting the Workstation sub-model to a main model is done by connecting the Application object representing network-software to a Network using the ClientAccess type of connection.
The workstation model becomes a group when being imported and can then be collapsed.
Updated about 1 year ago