Models

The next few sections provide an in-depth look into the threats that target different parts of ABB Ability™ services, and how they are mitigated.​

Threat Model for ABB Ability™ Edge

The following diagram illustrates the threat model for the ABB Ability™ Edge:

Note that "OS Configuration" is a generic term used for the components in an operating system that are used to interact with the device OS. For example, a local administrator could perform an SSH session to modify the configuration, or another administrator may log in to the Edge device to look at audit logs.

The Business Lines are responsible for the Edge Module. Based on its design and interactions, threats need to be enumerated by the Business Lines.

Threat Enumeration and mitigation

​The below table shows the threats enumerated based on the threat model and the mitigation for the identified threats

Entity	Applicable Threat​	Mitigation
PKI Client​	S - CA Server might be spoofed by an attacker	PKI Client verifies the authenticity of the CA Server by verifying the ABB Root certificate that signs the CA issuer certificate.
	T, I - Tampering of Data, Information disclosure​	SCEP over HTTPS ensures that the Certificate signing request and then the certificate itself is protected from tampering.
	R - Repudiation​ (CA Server denies receiving data from PKI Client)	Enable audit logging in both PKI Client and Server​.
	D - Denial of Service - External entity prevents data flow ​	Verify the connectivity between Edge and CA Server and ensure that uninterrupted connectivity is possible.​
Edge Agent​	S - IoT Hub/DPS Server might be spoofed by an attacker​	Edge Agent verifies the identity of the IoT Hub/DPS Service via X.509 certificates issued by Microsoft​.
	T, I - Tampering of Data, Information disclosure​	Edge Agent establishes an outbound TLS connection to protect the confidentiality and integrity of data in transit.​​
	R - Repudiation​ (IoT Hub denies receiving data from Edge)​	Enable audit logging in both Edge Agent and IoT Hub​/DPS Service.
	D - Denial of Service - External entity prevents data flow ​​	Verify the connectivity between Edge and IoT Hub (Internet connectivity) and ensure that uninterrupted connectivity is possible​​.
	E - Elevation of Privileges - IoT Hub/DPS can attempt to elevate privileges in Edge Agent via specially crafted messages/responses.​	​Implement Input validation for C2D messages received in the Edge Agent. Later (when additional C2D scenarios are supported - Ex. RDP), access controls need to be implemented.
OS Configuration	S - An attacker might spoof as a system administrator​	Enforce strong passwords for the administrator account in Edge and implement password policies in the Edge. Log all administrative actions. ​
	T, R, I, D - Attacker attempts to modify configuration, steal secrets (disk) or render the Edge broken​	Ensure System integrity via Secure Boot, Audit logging functionality to capture all actions on the Edge, Usage of TPM and secure storage to protect the Edge secrets and limiting the access rights for non Administrator users to prevent modifications to the Edge OS​. Further, the disk should be encrypted to mitigate the risk of a physical intrusion.
	E - An attacker might attempt to login as a normal user and elevate privileges as Root user​	Minimize the user accounts in Edge. Keep the OS Kernel patched and ensure hardening of the Edge environment. ​
Edge Broker	S - Module and agent can be spoofed	Broker is provisioned with credentials of Module and agent at time of provisioning to authenticate the connect messages from Edge module and Edge Agent. ​
	T, I - 1. Message flow between Module & agent to Broker can tamper and eavesdrop 2. Packets or messages without sequence numbers or timestamps can be captured and replayed in a wide variety of ways​	1. Transport level encryption or application level encryption shall be applied to messages traffic between Module & agent to Broker 2. Edge Broker handles the Packet identifier set in the message and according to QOS parameter set, the packet delivery status is managed by Broker.
	R - Edge Broker denies the reception of messages from Edge module and Edge Agent	Enable Audit logging in Broker for all transaction of messages. ​
	E - Broker can impersonate module or Agent to send messages to Agent and module respectively​	Appropriate Broker Images shall be securely signed and signature verification shall be done in the host of edge before creating a service of Broker. ​

Threat Model for ABB Ability™ Cloud Platform

The following diagram illustrates the threat model for the ABB Ability™ Cloud Platform:

The above is not a diagram of the ABB Ability™ Cloud architecture. Not all Azure/Ability components have been depicted here to keep the diagram readable

Internal communications are marked as binary. The arrows are unidirectional to keep the diagram simple. The direction of the arrow usually signifies the direction of the connection initiation between the components.

The Ability Cloud deployment is organized in Virtual Networks to minimize the attack surface of the components, and is accessible by IP addresses from the allowlist.

Actual deployment uses only one Web Application Firewall (WAF). The above diagram shows two such WAF instances for depicting the diagram clearly.

Azure AD B2C is used by the Ability cloud to customize the authentication flow and to issue Ability specific access tokens. The threat model of Azure AD B2C is the responsibility of Microsoft and is out of scope of this document.

Threat Enumeration and mitigation

​The table below shows the threats enumerated based on the threat model and the mitigation for the identified threats:

Entity	Applicable Threat	Mitigation
IoT Hub​, Device Provisioning Service	S - Spoofing	Devices are identified via CA server issued X.509 certificates. The certificate root is pinned in DPS and IoT Hub​.
	T, I - Tampering of Data, Information disclosure​	Connections to DPS and IoT Hub are accepted only over mutually authenticated TLS channels. TLS provides confidentiality and integrity of messages.​
	R - Repudiation	Audit logs help to prove the message exchange between Cloud and Edge devices.
	D - Denial Of Service	Microsoft provides DDoS protection capabilities as a part of the Azure PaaS offering​​.
Ability CA Server	S - Spoofing​ of end devices for certificate enrollment	CA Server uses the OTP embedded in the Certificate Signing Request to ensure that the right device is performing certificate enrollment.
	T, I - Tampering of Data, Information disclosure	SCEP ensures that the PKCS packet is verified against tampering. Private keys are not sent in the CSR request and hence, no sensitive information is disclosed.
	R - Repudiation	Audit logs in the device and in CA server ensure that the message exchanges are recorded.
	D - Denial of Service​ - CA Server might suffer a DDoS attack which would compromise the availability of the CA Server	Basic Azure DDoS protection is enabled on API Management instances to protect from DDoS attacks, and API Management is protected by the Web Application Firewall.​
Azure Container Registry	S - Spoofing	Authentication should be enabled to ensure that only authenticated entities can push or pull to the container registry.​
	T, I - Tampering of Data, Information disclosure​	Images in the container registry must be encrypted to ensure that the confidentiality of the images is preserved​. Image contents are hashed. The hash is recorded in the app manifest. Any tampering changes the hash which allows for clients to identify tampered images.
	R- Repudiation	Audit logging should be enabled in Azure Container registry to record the image push and pull events​.
	D - Denial of Service​	Azure DDoS protection should be enabled on the Azure Container registry to mitigate DDoS attacks​.
	E - Elevation of Privileges​	Separation of Push and Pull credentials to ensure that the pull credentials do not have write permissions on the registry.​
File Storage	S - Spoofing​	Any entity that gains access to the SAS token can spoof as a valid device. The SAS token used to authenticate the file storage is protected in transit via the TLS tunnel by ensuring that only the Edge Agent has access to SAS token.​
	T, I - Tampering of Data, Information disclosure​	Data in transit is protected by TLS since the clients connect to the file storage via HTTPS. Azure storage is encrypted to prevent information disclosure​.
	R - Repudiation​	Audit logs is enabled to prove the file upload and download transactions​.
	D - Denial Of Service​	Azure PaaS provides basic Denial of Service protection capabilities on Azure Storage.
Re-ingestion Event Hub	S - Spoofing	Event hub authenticates client applications via SAS tokens, which are issued by the Data Access service. The client applications need to ensure that the SAS tokens cannot be hijacked. The SAS token lifetime is limited to a short period to prevent data loss via a stolen SAS token.
	T, I - Tampering of Data, Information disclosure​	Client applications connect to the Event hub using the AMQP or HTTPS protocols, which ensures integrity and confidentiality of the information passed.
	D - Denial of Service	Azure PaaS provides Basic DDoS protection capabilities for the Event Hub.
	E - Elevation of Privileges	Elevation of privileges is prevented by ensuring that the SAS token issued contains only rights to ingest telemetry.
Hot-Path Subscriptions (ServiceBus)	S - Spoofing	ServiceBus authenticates the client applications via SAS tokens, which are issued by the Data Access service. The client applications need to ensure that the SAS tokens cannot be hijacked. The SAS token lifetime is limited to a short period to prevent data loss via a stolen SAS token.
	T, I - Tampering of Data, Information disclosure	Client applications connect to the ServiceBus using the AMQP protocol, which provides integrity and confidentiality of the information passed.
	D - Denial of Service	Azure PaaS provides Basic DDoS protection capabilities for the Event Hub.
	E - Elevation of Privileges	Elevation of privileges is prevented by ensuring that the SAS token issued contains only rights to listen to telemetry and platform events. Telemetry and PlatformEvents are filtered based on the configured user and application rights.
Platform APIs (API Management)	S - Spoofing​	Spoofing of clients using API management is prevented by enforcing access to APIM only via public IP address of selected ABB BL applications added to the allowlist. Further, calls to APIM are subject to the enforcement of the Authentication policy via Azure AD​ B2C.
	T, I - Tampering of Data, Information disclosure​	Only HTTPS must be enabled on API Management to ensure that data transfer is protected from tampering and disclosure​.
	R - Repudiation	Audit logs in API Management and in target platform services should be enabled to ensure that the client transactions are recorded​.
	D - Denial of Service	Basic Azure DDoS protection is enabled on API Management instances to protect from DDoS attacks. Further, platform APIs are only exposed to ABB BL client applications residing on the IP allowlist.
	E - Elevation of Privileges​	Authorization via AuthZ is enforced on all interfaces provided by API Management to ensure that principals having the right access grants can perform the requested action. Further, Input validation at APIM as well as the target services must be implemented to ensure mitigation against script execution and attempts for elevation of Privilege​.
Region APIs (API Management) - Principal Manager	S - Spoofing​	Spoofing of clients using API management is prevented by enforcing Authentication policy via Azure AD​ B2C. Clients accessing the Region APIs must receive an Ability specific Access Token from Azure AD B2C.
	T, I - Tampering of Data, Information disclosure​	Only HTTPS must be enabled on API Management to ensure that data transfer is protected from tampering and disclosure​.
	R - Repudiation​	Audit logs in API Management and in Principal Manager services should be enabled to ensure that the client transactions are recorded​.
	D - Denial of Service	Basic Azure DDoS protection measures are enabled on API Management instances to protect them from DDoS attacks. Additionally, the Region APIM is protected by Azure Web Application Firewall.
	E - Elevation of Privileges​	Authorization via AuthZ is enforced on all interfaces provided by API Management to ensure that the principals which have the appropriate access grants can perform the requested actions. Additionally, Input validation at APIM and the Principal Manager must be implemented to ensure mitigation against script execution and attempts for elevation of Privilege​.
​ABB Ability™ Portal (Admin Portal)	S - Spoofing	Authentication via Azure AD B2C is enforced to prevent anonymous access to Ability Portals​. Session cookies is set to "secure" and "http only" to protect against session hijacking and XSS attacks.
	T, I - Tampering of Data, Information disclosure​	The ABB Ability™ Portal enforces HTTPS to ensure that no data is tampered with or disclosed ​in transit.
	R - Repudiation​	Audit logs at the portal level must be implemented to capture user interactions.
	D - Denial Of Service​	The ABB Ability™ Portal is deployed in a VNET protected by the Web Application Firewall.
	E - Elevation of Privileges​	The ABB Ability™ Portal implements RBAC for the portal resources and implement input validation on all UI components. This is to ensure that any attempts to elevate privileges, traverse directories, etc. are detected and mitigated.
Global ID Generator (GIG) Service	S - Spoofing	Entities that request a new Id must be authenticated either via an ABB Ability™ issued certificate, or allowed identities in API Management that host GIG Service APIs.
	T, I - Tampering of Data, Information Disclosure	HTTPS is enforced on all GIG service interfaces to ensure that the data integrity and confidentiality are ensured.
	R - Repudiation	Audit logs must be used in GIG service to record the entities and interactions.
	D - Denial Of Service	GIG APIs are hosted on API Management protected by the Web Application Firewall.
	E - Elevation of Privileges	GIG Service implements authentication for request of identities and input validation to ensure that a client device or an application does not attempt elevation of privileges.
Certificate Management (CM) Service	S - Spoofing	Spoofing of clients using the CM service is prevented by enforcing an Authentication policy via Azure AD​. Devices and applications accessing the CM service via Global APIs must receive an Ability-specific access token from Azure AD.
	T, I - Tampering of Data, Information Disclosure	HTTPS is enforced on all CM service interfaces to ensure data integrity and confidentiality is maintained.
	R - Repudiation	Audit logs must be used in the CM service to record entities and interactions.
	D - Denial Of Service	CM APIs are hosted on API Management protected by the Web Application Firewall.
	E - Elevation of Privileges	CM service authenticates identity requests and input validation to ensure that client devices or applications do not attempt to elevate their privileges.
CM Portal	S - Spoofing	Authentication via Azure AD must be enforced to prevent anonymous access to Ability Portals​. Session cookies must be set to "secure" and "HTTPS only" to protect from session hijacking and XSS attacks.
	T, I - Tampering of Data, Information disclosure​	The CM portal enforces HTTPS to ensure that no data is tampered with or disclosed ​in transit.
	R - Repudiation​	Audit logs at the CM portal level must be implemented to capture user interactions.
	D - Denial Of Service​	The CM portal is deployed in a VNET protected by the Web Application Firewall.
	E - Elevation of Privileges​	The CM portal implements RBAC for the portal resources and input validation on all UI components. This is to ensure that attempts to elevate privileges, etc. are detected and mitigated.
OAuth Helper	S - Spoofing	Not applicable. OAuth helper is designed to accept requests from anonymous clients.
	T, I - Tampering of Data, Information Disclosure	Not applicable. OAuth helper acts as a proxy between clients and Azure AD B2C to realize Client Credential authentication flow.
	R - Repudiation	Audit logging at the client level must be implemented to record the attempts at authentication flow using the OAuth Helper function.
	D - Denial Of Service	Azure Basic DDoS protection is applied to the OAuth Helper further protected by the Azure Web application firewall.
	E - Elevation of Privileges	OAuth Proxy must perform input validation to ensure that the client application is not attempting to elevate its privileges.
​Ability Storage (*)	S - Spoofing	Service principals should be used to ensure that the clients pass authentication to Azure storage. ​The connection strings are stored in the Azure Key Vault. Clients pass authentication to the Key Vault to retrieve the connection strings.
	T, I - Tampering of Data, Information Disclosure	Authorization is enforced at the application level when requests to retrieve data in the storage are received. The storage needs to be encrypted to ensure the confidentiality of the data.​
	R - Repudiation	Audit logs at the application level must be enabled to record all data transactions.
	D - Denial Of Service	Most of the storages are hidden from public interfaces via VNET to ensure that it is not directly susceptible for DDoS Attacks​. Where such a configuration is not possible, the storage is protected by configuration of Service Endpoints and Azure Basic DDoS protection.
	E - Elevation of Privileges	Authorization via AuthZ must be enforced to ensure that only users with access to the data are allowed to access the data.

Ability Storage is an internal data store that consists of multiple viz databases, Cosmos DB, Time Series Insights, Blob storage, and so on. All these databases are configured within a VNET where possible, and direct access from the internet is prevented. In certain cases where it is not possible to configure databases in a VNET, service endpoints shall be used to limit database access to Ability services. Azure Key Vault is used to protect the connection strings for the databases with the services requiring authentication to Azure Key Vault to retrieve the connection strings. However, since these databases contain sensitive information, they are considered a special case for threat modeling.​

Threat Model for ABB Ability™ Factory proxy

The following diagram illustrates the threat model for Factory Proxy:

Threat Enumeration and mitigation

​The table below shows the threats enumerated based on the threat model and the mitigation for the identified threats:

Entity	Applicable Threat​	Mitigation
Factory proxy	S - Spoofing of Certificate manager and ACR	Factory proxy verifies the identity of Certificate Manager via x.509 certificates issued by Microsoft. Docker Daemon verifies the identity of ACR via x.509 certificates issued by Microsoft.
	T, I - Tampering and Information disclosure of data from Factory Proxy to Certificate Manager service​	Factory Proxy uses TLS connection to protect the confidentiality and integrity of data in transit.
	R - Repudiation​ (Certificate Manager denies receiving of data from Factory Proxy)​	Enable audit logging in both Factory Proxy and Certificate manager Service.
	D - Denial of Service - An external agent interrupts data flowing across a trust boundary in either direction​	All incoming connections which are not initiated by Factory proxy are blocked. Leverage the cloud infrastructure like WAF, API management to mitigate DDOS attacks to Certificate Manager Service. The incoming connections to Factory Proxy are from local network. So it does not face this threat.
	E - Elevation of Privileges - Certificate manager can attempt to elevate privileges in Factory proxy via specially crafted messages/responses​.	Input validation of messages received from Certificate manager shall be performed and reject the responses which contain malicious scripts.
Broker	​S - Module and Proxy can be spoofed​	Broker is provisioned with credentials of Module and proxy at time of provisioning to authenticate the connect messages from module and proxy​.
	T, I - Message flow between Module & Proxy to Broker can tamper and eavesdropped	Transport level encryption or application level encryption shall be applied to messages traffic between Module & Proxy to the Broker.
	T, I - Packets or messages without sequence numbers or timestamps can be captured and replayed in a wide variety of ways	Broker handles the Packet identifier set in the message and according to QOS parameter set, the packet delivery status is managed by the Broker.
	R - Broker denies the reception of messages from module and proxy	Audit Logging enabled in Broker form all transaction of the messages.
	E - Broker can impersonate module or proxy to send messages to Proxy and module respectively.​	​IAppropriate Broker Images shall be securely signed and signature verification shall be done in the Host of Factory proxy before creating a service of the Broker.
OS Configuration	S - An attacker might spoof as a system administrator​	Enforce strong passwords for the administrator account for Host of Factory Proxy and implement password policies. Log all administrative actions​.
	T, R, I, D - Attacker attempts to modify configuration, steal secrets (disk) or render the Edge broken​	Usage of TPM and secure storage to protect the APP ID credentials and Docker Swarm Manager key. Configuration done at time of Installation cannot be modified again.