# Threat Model
# Overview
There is always at least one person looking for ways to undermine system security in order to take advantage of vulnerabilities in the system for their own gain. This document is designed to inform you how hackers and other people may take advantage of security weak points and exploits, what security measures we have put in place to prevent it, and what you can do to further ensure that you and your data do not get into the wrong hands.
Most of the data produced with the help of ABB systems comes from devices within customer installations. Cloud-to-cloud ingestion of data is possible. This data flows from the on-premises devices (optionally through a field gateway) to the Cloud Gateway via the internet and gets stored in databases in the public cloud. The data is then consumed by specific processes and presented to end users. This allows us to divide the overall flow into several zones:
- On-Premise Device zone
- Edge zone
- Ability Platform Cloud zone
- Client application zone
Zones are broadly considered network isolation areas. Each zone is separated from the others by a trust boundary. The following diagram shows the threat model from a high-level system context point of view:
At this high level, the system processes have been abstracted and denoted at their high-level functions.
"Binary" data flow is a general term used to indicate internal data transfers within a zone. These could be legacy protocols, messaging protocols (AMQP/MQTT/HTTPS), or even RPC calls.
The arrows in the above diagram are simplified. Their direction shows the general direction of data flow, however, they do not necessarily depict the directions of connection triggers. Note that the connections across trust boundaries are bi-directional.
The components depicted in each of the zones above are subject to STRIDE, enabling a complete view of threats to the platform. The following sections provide an in-depth look into each of the above zones to address the threat model and the threats associated.
# On-Premise Device Zone
This zone is typically the Operational Technology (OT) network that consists of various industrial devices. It is an indicator of a private network that is not usually reachable through the internet. However, the devices in this zone can be bridged to the internet via the Edge Zone. Threats in this zone arise from Human-Machine interaction, and in the case of brownfield devices, this zone often implements the least secure features. Because of this, users are advised to take extra care by assessing modules in order to make sure that no information that no information becomes public if it was not designed to do so.
# Edge Zone
This zone is quite literally the Edge of the network. This zone typically contains Edge devices that provide connectivity to Cloud components. Additionally, this zone implements Edge/Fog computing. Devices in this zone are Internet facing and are subject to incoming threats from the public internet. These Edge devices implement stringent security controls managed by ABB Ability™ - some are examples are: trusted computing, isolated local networks from the public ones, and intelligent routing of information between the two networks.
Often, industrial devices can be connected directly to the cloud. In such cases, directly connected devices are located in the Edge zone, and the threats and mitigations on the Edge zone apply to these devices.
The following is a list of possible threats to Edge/Directly Connected Devices:
# Spoofing
Strong Identity management backed by hardware-based security is required to protect Edge devices, that is, to prevent their identities from being stolen. The cryptographic key materials are secured by ABB with the help of hardware based TPMs (Trusted Platform Module), and the public key is bound to the device via an X.509 certificate. Since the private key is secured by a TPM, the identity of the Edge cannot be stolen for spoofing purposes.
TRI (Tampering, Repudiation, Information Disclosure) - ABB has various mechanisms in the Edge to protect against "TRI" threats: software integrity verification via secure boot, Docker container image verification, mutually authenticated TLS connections to ensure mitigations against data tampering and information disclosure, and audit logging to mitigate against repudiation.
Denial of Service - An Edge can be denied availability to the ABB Ability™ Platform by an attacker disrupting the connectivity between the Edge and Internet. Business Areas should mitigate Denial of Service attacks by implementing temporary buffering of information in the Edge for periods of disruption, as well as network planning and redundant connectivity options to the cloud.
A local user who has access to a given device can attempt to disrupt the operations using various methods. Device access must be controlled and checked regularly. Generally, users who operate the plant should not be given administrator access.
Elevation of Privileges - Edges do not accept any incoming connections from the internet. For local HMI interaction, audit logging is implemented to ensure that user interactions are captured, and Linux user management capabilities are utilized to implement access restrictions on the host OS.
# ABB Ability™ Platform Zone
This zone hosts the core of the ABB Ability™ Platform. Starting from the registration and ingestion points, this zone includes all the PaaS services from Azure that work together to form the core platform including the message routing services, databases and access services. The components in this zone are hosted in a public cloud via Microsoft Azure, and therefore are subject to constant threats applicable to services on a public cloud. Along with the mitigations by the cloud provider, additional security controls and mitigations such as virtualization of network resources, configuration of public interfaces need to be implemented.
The following is a list of possible threats to the ABB Ability™ Platform:
# Spoofing
Edge device spoofing - An attacker can attempt to spoof an Edge device to insert malicious data into the platform. ABB has worked to prevent this by enforcing strong authentication via Ability-issued X.509 certificates for Edge devices. This is applicable both at the DPS and IoT Hub levels.
Edge device spoofing by hijacking the SAS token for the file upload service - The file upload service uses SAS tokens to authenticate upload sessions. Unauthorized copying of SAS tokens would allow attackers to spoof using stolen SAS tokens and upload malicious files. This is prevented by ABB in two ways: the SAS token is passed securely through the m-TLS channel, and the token expires after a preset amount of time.
Client application spoofing - Users and client applications can retrieve data from the platform attempt by attempting to spoof their identities. ABB has enforced strong authentication measures via Azure AD to prevent this by authorizing both Applications and Users. At the reinjection Event hub, client applications can be spoofed via a stolen SAS token. Users need to ensure that they implement sufficient SAS token protection in their applications.
# Tampering
Tampering with Data in Transit - An attacker might attempt to tamper with the data being transmitted from Edge devices to the ABB Ability™ Platform. This is prevented by ensuring that all data is transmitted over mutually authenticated TLS tunnels that provide integrity protection of data in transit.
Tampering with Data at Rest - The ABB Ability™ Platform stores data in Azure databases, for example, Cosmos DB, Time Series Insights, and so on. An attacker might attempt to access these databases and modify the data in them. This is prevented by storing database access keys in a key vault with authorization, as well as ensuring that databases are either part of a VNET that prevents direct access to the databases from the internet, or they are configured with service endpoints that prevent connections outside the ABB Ability™ network boundary.
Tampering with Data in use - An attacker might attempt to tamper with data received at API interfaces. This is prevented by enabling HTTPS access to APIs and also by ensuring that only client applications on the allowlist can access ABB Ability™ APIs, while arbitrary applications/clients cannot.
Repudiation - Various entities, such as Edge client applications, can claim that they did not perform an action that they indeed performed. Extensive audit logging helps to mitigate the threat of Repudiation.
Information Disclosure - Can occur at various interfaces, such as the ingress interfaces of DPS, IoT Hub, and the file upload service. It can also happen within the ABB Ability™ Platform interfaces where data is moved between different services. Information disclosure can occur in databases, and it can also happen at the ABB Ability™ API interfaces. The following mitigations are used to prevent information disclosure:
Using mutually authenticated TLS sessions between Edge devices and Ability Ingress interfaces. Mutual authentication is achieved by CA-issued X.509 certificates, and the TLS tunnels provide confidentiality and integrity protection of data being exchanged.
Configuring internal ABB Ability™ services inside a VNET prevents their direct exposure to the internet, and thus makes it difficult to extract data out of these services.
Encryption of data at rest in Ability databases helps to mitigate the threat of information disclosure for data stored in them.
At the API level, using HTTPS along with strong authentication (Via Azure AD) and authorization (Ability RBAC Service) measures helps to mitigate the risk of information disclosure. Also, the public interfaces are protected by a Web Application Firewall that protects these interfaces from common threats.
Denial of Service - the ABB Ability™ Platform is hosted in Microsoft Azure, and the threats applicable to the Azure cloud in terms of Denial of Service also apply to the services in the ABB Ability™ Platform. Along with the mitigations provided by Azure, additionally Geo redundancy and additional DDoS protection mechanisms should be enabled in the platform interfaces to mitigate this threat.
Elevation of Privileges - an attacker might attempt to elevate their privileges and perform actions that are not authorized, for example, configuration changes. This is prevented via strong authentication using Azure AD and user authorization (Ability RBAC Service).
# Client Application Zone
This zone hosts the clients of the ABB Ability™ Cloud Platform. They can interact with the platform interfaces to access the information stored in the platform, and provide value added services. This zone contains applications and services developed by the Business Lines and are subject to threats similar to any application or service developed on a public cloud.
Applications are the first point of contact to users and attackers alike. It is imperative that the applications are hardened, and the application interfaces are exposed via the API Manager and Web Application Firewall.