Threat Modeling Report

Description: General Threat Model for EdgeX Foundry - inclusive of security elements (Nginx, SecretStore, etc). This revision additionally documents mitigations gained when EdgeX is deployed under a rootless Docker daemon (see https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/). Threats whose Possible Mitigation field contains "Additional mitigation when running EdgeX in rootless Docker:" have been revised to reflect the reduced blast radius (no host-root via container escape, user-namespace UID remapping, host filesystem isolation, and unprivileged ownership of container volumes and the Docker socket). In a second pass, threats whose Possible Mitigation contains "Additional mitigation when EdgeX container images are signed" have been revised to reflect supply-chain integrity provided by Sigstore/cosign, Docker Content Trust or Notary v2 when signature verification is enforced at pull/admission time with the signing key protected by an HSM or KMS; that mitigation is paired with SBOM and SLSA provenance attestations and timely patching, since signing covers image authenticity only. All revisions are appended to the original author's text inside Possible Mitigation.

Assumptions: EdgeX is platform agnostic, but this Threat model assumes the underlying OS is a Linux distribution. EdgeX can run containerized or non-containerized (natively). This Threat Model assumes EdgeX is running in a containerized environment (Docker). EdgeX micro services can run distributed, but this Threat Model assumes EdgeX is running on a single host (single Docker deamon with a single Docker network unless otherwise specified). Many different devices/sensors can be connected to EdgeX via its device services. This Threat model treats all sensors/devices the same (which is not always the case given the varoius protocols of support). Per https://docs.edgexfoundry.org/4.0/threat-models/secret-store/threat_model/, additional hardening such as secure boot with hardware root of trust, and secure disk encryption are outside of EdgeX control but would greatly improve the threat mitigation.

External Dependencies: Operating system and hardware (including devices/sensors) Device/sensor drivers Possibly a cloud system or external enterprise system that EdgeX gets data to A message bus broker (such as an MQTT broker)

Notes:

Threat Model Summary:

Diagram: EdgeX Foundry (Big Picture)

Validation Messages:

EdgeX Foundry (Big Picture) Diagram Summary:

Interaction: configuration

Id	Note	Date	Added By
1	Tampering with Data - This is a threat where information in the system is changed by an attacker. For example, an attacker changes an account balance Unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet	26/08/2022 02:40:40	DESKTOP-SL3KKHH\jpwhi
2	XSS protections: filter input on arrival (don't do), encode data on oputput (don't do), use appropriate headers (do), use CSP (dont do)	26/08/2022 02:54:16	DESKTOP-SL3KKHH\jpwhi
3	priority is determined by the likelihood of a threat occuring and the severity of the impact of its occurance	26/08/2022 03:11:40	DESKTOP-SL3KKHH\jpwhi
4	Repudiation - don't track and log users actions; can't prove a transaction took place	26/08/2022 03:13:14	DESKTOP-SL3KKHH\jpwhi
5	Elevation of privil - authorized or unauthorized user gains access to info not authorized	26/08/2022 03:16:24	DESKTOP-SL3KKHH\jpwhi
6	Remote code execution: https://www.comparitech.com/blog/information-security/remote-code-execution-attacks/ buffer overflow sanitize user inputs proper auth use a firewall	26/08/2022 03:21:28	DESKTOP-SL3KKHH\jpwhi
7	Privilege escalation attacks occur when bad actors exploit misconfigurations, bugs, weak passwords, and other vulnerabilities	27/08/2022 21:57:18	DESKTOP-SL3KKHH\jpwhi

1. Spoofing of Source Data Store Configuration Files [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Configuration Files may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Configuration files are used to seed EdgeX configuration service (core-keeper) before the services are started. Configuration files are made part of the service container (deployed with the container image). The only way to spoof the file is to replace the entire service container with new configuration or to transplant new configuration in the container - both require privileaged access to the host. Additional mitigation when running EdgeX in rootless Docker: the Docker daemon, container processes and bind-mounted volumes are owned by an unprivileged host user rather than root. A compromised container that escapes its namespace inherits only that unprivileged user's permissions, so it cannot read or overwrite configuration files baked into other service containers, replace a service image on disk, or transplant configuration into a running container without first compromising the rootless-Docker user account itself. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

2. Weak Access Control for a Resource [State: Not Applicable] [Priority: Low]

Category:	Information Disclosure
Description:	Improper data protection of Configuration Files can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	Disclosure of configuration files is not important. Configuration data is not considered sensitive. As long as the configuration files are not manipulated, then access to configuration files is not deemed a threat. All secret configuration is made available through SecretStore. Additional mitigation when running EdgeX in rootless Docker: containers cannot access non-root host directories, so the files backing this resource are reachable only via the service's own API or by compromising the unprivileged host user that owns the rootless daemon. This narrows the filesystem-side attack surface that a colocated, lower-privileged process could otherwise reach. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

Interaction: data

3. Spoofing of Source Data Store PostgreSQL [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	PostgreSQL may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	If someone was able to provide a container that was spoofing as PostgreSQL , the service would not know that the response came from something other than PostgreSQL. However, PostgreSQL is run as a container on the EdgeX Docker network. Replacing/spoofing the PostgreSQL container would require privileaged (root) access to the host. Additional adopter mitigation would include putting TLS in place between EdgeX and PostgreSQL (with TLS cert in place). A spoofing service (in this case PostgreSQL), would not have the appropriate cert in place to participate in the communications. Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the PostgreSQL container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

4. Authenticated Data Flow Compromised [State: Mitigation Implemented] [Priority: Low]

Category:	Tampering
Description:	An attacker can read or modify data transmitted over an authenticated dataflow.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX containers communicate via a Docker network. A hacker would need to gain access to the host and have elevated privileages on the host to access the network traffic. For additional security, EdgeX can also run in a rootless Docker environment (see: https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/). If an adopter deploys EdgeX services in a distributed environment across multiple hosts, overlay network encryption can be enabled to secure inter-host communication (see example: https://github.com/edgexfoundry/edgex-examples/tree/update-custom-trigger-multiple-pipelines/security/remote_devices/docker-swarm)
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

5. Weak Access Control for a Resource [State: Mitigation Implemented] [Priority: Low]

Category:	Information Disclosure
Description:	Improper data protection of PostgreSQL can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	Access control credentials for PostgreSQL are secured in SecretStore (provided to EdgeX services at bootstrapping but otherwise unknown). Access without credentials is denied.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: published message

6. Potential Excessive Resource Consumption for EdgeX Foundry or Message Bus Broker [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or Message Bus Broker take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	The EdgeX message broker is an MQTT broker like Mosquitto and runs as a container in a Docker network that, by default with security on, does not allow direct access to the broker. Access to publish or subscribe to cause it to use excessive resources would require authorized access to the host as the port to the internal message broker is protected. In other words, EdgeX mitigates unauthorized attacks resulting in DoS event, but would not mitigate authorized attacks (such as a service producing too many message than the broker can handle) that result in a DoS event.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

7. Spoofing of Destination Data Store Message Bus [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Message Bus may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Message Bus. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	The message bus when requiring a broker (MQTT broker for example) is run as a container on the EdgeX Docker network. Replacing/spoofing the broker container would require privileaged access to the host. Message broker host and port are part of services' configuration (covered under threats against configuration) Additional mitigation when running EdgeX in rootless Docker: the Docker daemon, container processes and bind-mounted volumes are owned by an unprivileged host user rather than root. A compromised container that escapes its namespace inherits only that unprivileged user's permissions, so it cannot read or overwrite configuration files baked into other service containers, replace a service image on disk, or transplant configuration into a running container without first compromising the rootless-Docker user account itself. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the message-bus broker container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: queries & data

8. Spoofing of Destination Data Store PostgreSQL [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	PostgreSQL may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of PostgreSQL. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	If someone was able to provide a container that was spoofing as PostgreSQL, the service would not know that the response came from something other than PostgreSQL. However, PostgreSQL is run as a container on the EdgeX Docker network. Replacing/spoofing the PostgreSQL container would require privileaged (root) access to the host. Additional adopter mitigation would include putting TLS in place between EdgeX and PostgreSQL (with TLS cert in place). A spoofing service (in this case PostgreSQL), would not have the appropriate cert in place to participate in the communications. Database host and port are part of services' configuration (covered under threats against configuration) Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the PostgreSQL container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

9. Authenticated Data Flow Compromised [State: Mitigation Implemented] [Priority: Low]

Category:	Tampering
Description:	An attacker can read or modify data transmitted over an authenticated dataflow.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX containers communicate via a Docker network. Docker containers do not share the host's network interface by default and instead is based on virtual ethernet adapters and bridges. A hacker would need to gain access to the host and have elevated privileages on the host to access the network traffic. For additional security, EdgeX can also run in a rootless Docker environment (see: https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/). If an adopter deploys EdgeX services in a distributed environment across multiple hosts, overlay network encryption can be enabled to secure inter-host communication (see example: https://github.com/edgexfoundry/edgex-examples/tree/update-custom-trigger-multiple-pipelines/security/remote_devices/docker-swarm)
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

10. Potential SQL Injection Vulnerability for PostgreSQL [State: Mitigation Implemented] [Priority: Low]

Category:	Tampering
Description:	SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQL Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX peresistence implementation uses the golang with proper SQL statements to prevent any SQL injection https://go.dev/doc/database/sql-injection
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

11. Potential Excessive Resource Consumption for EdgeX Foundry or PostgreSQL [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or PostgreSQL take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	PostgreSQL runs as a container in a Docker network that, by default with security on, does not allow direct access to the database. Access to query or push data into it to cause it to use excessive resources would require authorized access to the host as the port to the database is protected. In other words, EdgeX mitigates unauthorized attacks resulting in DoS event, but would not mitigate authorized attacks (such as a service making too many queries or pushing to much data into it) that result in a DoS event. EdgeX does have a routine with customizable configuration that "cleans up" and removes older data so that "normal" or otherwise expected use of the database for persistenct does not result in DoS.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: query

12. Spoofing of Destination Data Store SecretStore [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	SecretStore may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of SecretStore. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	If someone was able to provide a container that was spoofing as SecretStore, the service would not know that the response came from something other than SecretStore. However, SecretStore is run as a container on the EdgeX Docker network. Replacing/spoofing the SecretStore container would require privileaged (root) access to the host. Additional adopter mitigation would include putting TLS in place between EdgeX and SecretStore (with TLS cert in place). A spoofing service (in this case SecretStore), would not have the appropriate cert in place to participate in the communications. EdgeX services that use SecretStore must use the go-mod-secrets client or a SecretStore service token to access its secrets (which is revoked by default). See https://docs.edgexfoundry.org/4.0/security/Ch-SecretStore/#using-the-secret-store SecretStore host and port are configured from static configuration or environment overrides (trusted input), making it difficult to misdirect services access to SecretStore. See EdgeX Threat Model documentation (https://docs.edgexfoundry.org/4.0/threat-models/secret-store/threat_model/#threat-matrix) for additional considerations and mitigation. Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the SecretStore (OpenBao) container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

13. Potential Excessive Resource Consumption for EdgeX Foundry or SecretStore [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or SecretStore take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	SecretStore runs as a container in a Docker network that, by default with security on, does not allow direct access to the secret store. Access to query or push data into it to cause it to use excessive resources would require authorized access to the host as the port to the database is protected. In other words, EdgeX mitigates unauthorized attacks resulting in DoS event, but would not mitigate authorized attacks (such as a service making too many queries or pushing to many secrets into it) that result in a DoS event.
Mitigator:	Third Party
Mitigation Status:	Mitigation reviewed

Interaction: query

14. Spoofing of Destination Data Store Device/Sensor (REST authenticated) [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Device/Sensor (REST authenticated) may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Device/Sensor (REST authenticated). Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication in place the REST caller would not get the proper authenticated by a spoofed Nginx and thereby deny any query request.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

15. The Device/Sensor (REST authenticated) Data Store Could Be Corrupted [State: Mitigation Implemented] [Priority: High]

Category:	Tampering
Description:	Data flowing across query may be tampered with by an attacker. This may lead to corruption of Device/Sensor (REST authenticated). Ensure the integrity of the data flow to the data store.
Justification:	<no mitigation provided>
Possible Mitigation:	REST requests and responses to/through Nginx are encrypted by default.
Mitigator:	Third Party
Mitigation Status:	Mitigation reviewed

16. Data Store Denies Device/Sensor (REST authenticated) Potentially Writing Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Device/Sensor (REST authenticated) claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

17. Data Flow query Is Potentially Interrupted [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the network communication connection causing major disruption of service (ex: removing or cutting off comms to a critical temperature resource of a heating or cooling machine). EdgeX has no means to protect the network connection. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

18. Data Store Inaccessible [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the network communication connection causing major disruption of service (ex: removing or cutting off comms to a critical temperature resource of a heating or cooling machine). EdgeX has no means to protect the network connection. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

Interaction: query

19. Data Store Inaccessible [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or MQTT broker causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the connection to the external MQTT broker, the broker itself, or subscriber to the broker. Physical and sytem security is required to protect these and mitigate this threat. Query requests that do not receive a response would result in an error that could be responded to.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

20. Data Flow query Is Potentially Interrupted [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or MQTT broker causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the connection to the external MQTT broker, the broker itself, or publisher to the broker. Physical and sytem security is required to protect these and mitigate this threat.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

21. Potential Excessive Resource Consumption for EdgeX Foundry or Device/Sensor (via external MQTT broker - authenticated) [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or Device/Sensor (via external MQTT broker - authenticated) take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX could send too many requests for data that cause the broker or subscriber to go offline or appear unresponsive - depending on the capabilities of the broker or subscribing application. In the opposite direction, an MQTT publisher could be tampered with or improperly configured to send too much data (overwhelming the EdgeX system or MQTT broker) causing a DoS. Other than writing the device service to filter data to avoid the “too much” data DoS, this threat is not mitigated.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

22. Data Flow Sniffing [State: Mitigation Implemented] [Priority: High]

Category:	Information Disclosure
Description:	Data flowing across query may be sniffed by an attacker. Depending on what type of data an attacker can read, it may be used to attack other parts of the system or simply be a disclosure of information leading to compliance violations. Consider encrypting the data flow.
Justification:	<no mitigation provided>
Possible Mitigation:	Requires encryption of the communications (on both the EdgeX and device/sensor ends) which is not in place by default. MQTTS could be implemented by the adopter with the appropriate MQTT broker.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

23. Data Store Denies Device/Sensor (via external MQTT broker - authenticated) Potentially Writing Data [State: Mitigation Implemented] [Priority: High]

Category:	Repudiation
Description:	Device/Sensor (via external MQTT broker - authenticated) claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications. Log level on the message bus may also be elevated.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

24. The Device/Sensor (via external MQTT broker - authenticated) Data Store Could Be Corrupted [State: Mitigation Implemented] [Priority: High]

Category:	Tampering
Description:	Data flowing across query may be tampered with by an attacker. This may lead to corruption of Device/Sensor (via external MQTT broker - authenticated). Ensure the integrity of the data flow to the data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Requires encryption of the communications (on both the EdgeX and device/sensor ends) which is not in place by default. MQTTS could be implemented by the adopter with the appropriate MQTT broker.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

25. Spoofing of Destination Data Store Device/Sensor (via external MQTT broker - authenticated) [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	Device/Sensor (via external MQTT broker - authenticated) may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Device/Sensor (via external MQTT broker - authenticated). Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication in place the spoofing MQTT query sendor (or the spoofed external message broker) would not be properly authenticated and thereby be unable to publish. The EdgeX framework has the support to store secrets to authenticate devices. Broker host and port are part of services' configuration (covered under threats against configuration)
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

26. Spoofing the EdgeX Foundry Process [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	EdgeX Foundry may be spoofed by an attacker and this may lead to unauthorized access to Device/Sensor (via external MQTT broker - authenticated). Consider using a standard authentication mechanism to identify the source process.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication in place the spoofing MQTT publisher of a query (or the spoofed external message broker) would not be properly authenticated and thereby be unable to make its request. The EdgeX framework has the support to store secrets to authenticate devices. Broker host and port are part of services' configuration (covered under threats against configuration) Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for any EdgeX Foundry service container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: query or actuation

27. Spoofing the EdgeX Foundry Process [State: Not Applicable] [Priority: High]

Category:	Spoofing
Description:	EdgeX Foundry may be spoofed by an attacker and this may lead to unauthorized access to Device/Sensor. Consider using a standard authentication mechanism to identify the source process.
Justification:	<no mitigation provided>
Possible Mitigation:	Without an authentication protocol, there is no mitigation for this threat. The device would not be able to determine that the Spoofing EdgeX caller is not EdgeX.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

28. Spoofing of Destination Data Store Device/Sensor [State: Needs Investigation] [Priority: High]

Category:	Spoofing
Description:	Device/Sensor may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Device/Sensor. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Due to the nature of many protocols, an outside agent could spoof a legitimate device/sensor. This is of particular concern if the device service auto provisions the devices/sensors without any authentication. Auto provisioning shold be limited to pick up trusted devices. Protocols such as BACnet do allow for authentication with the device/sensor. Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system, but there is no ability in EdgeX directly to protect against a spoofed device/sensor that does not authenticate (which is the norm in some older OT protocols).
Mitigator:	Adopter
Mitigation Status:	Mitigation written

29. The Device/Sensor Data Store Could Be Corrupted [State: Not Applicable] [Priority: High]

Category:	Tampering
Description:	Data flowing across query or actuation may be tampered with by an attacker. This may lead to corruption of Device/Sensor. Ensure the integrity of the data flow to the data store. I.e. - example: a man in the middle attack on the wire between EdgeX and the wired device/sensor or an attack on the sensor (giggling a vibration sensor)
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence on a sensor or device or intercept/use of the data to the device/sensor is one of the biggest threats to an edge system and one of the hardest to mitigate. If tampered with, a sensor or device could be used to send the wrong data (e.g., force a temp sensor to send a signal that it is too hot when it is really too cold), too much data (overwhelming the edge system by causing the sensor to send data too often), or not enough data (e.g., disconnecting a critical monitor sensor that would cause a system to stop). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and mitigate this threat. Additional optional mitigation ideas require modifications to the EdgeX device service. The device service could be constructed to filter data to avoid the “too much” data DoS. The device service can be constructed to report and alert when there is not enough data coming from the device or sensor or the sensor/device appears to be offline (provided by the last connected tracking in EdgeX). Wrong data can be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). All of these have limits and only mitigate the data from being used in the rest of EdgeX once received by the device service. Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could also be used to detect anomalous sensor/device communications and isolate the sensor from the system.
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

30. Data Store Denies Device/Sensor Potentially Writing Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Device/Sensor claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

31. Data Flow Sniffing [State: Not Applicable] [Priority: High]

Category:	Information Disclosure
Description:	Data flowing across query or actuation may be sniffed by an attacker. Depending on what type of data an attacker can read, it may be used to attack other parts of the system or simply be a disclosure of information leading to compliance violations. Consider encrypting the data flow.
Justification:	<no mitigation provided>
Possible Mitigation:	Securing the data flow to/from a device or sensor is dependent on the OT protocol. In the case of most simple and typically older OT protocols (Modbus or GPIO as examples), there is no way to secure the communications with the device/sensor under that protocol. Critical sensors/devices of this nature should be physically secured (along with their physical connection to the EdgeX host).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation reviewed

32. Potential Excessive Resource Consumption for EdgeX Foundry or Device/Sensor [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or Device/Sensor take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX could send too many requests for data or actuation requests that cause the sensor / device to go offline or appear unresponsive - depending on the sophistication of the device/sensor. In the opposite direction, a device/sensor could be tampered with or improperly configured to send too much data (overwhelming the EdgeX system) causing a DoS. Other than writing the device service to filter data to avoid the “too much” data DoS, this threat is not mitigated.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation reviewed

33. Data Flow query or actuation Is Potentially Interrupted [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and mitigate this threat. Query or actuation requests that do not receive a response would result in an error that could be responded to.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

34. Data Store Inaccessible [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and mitigate this threat. Query or actuation requests that do not receive a response would result in an error that could be responded to.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

Interaction: query or actuation

35. Data Store Inaccessible [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and mitigate this threat. Query or actuation requests that do not receive a response would result in an error that could be responded to.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

36. Data Flow query or actuation Is Potentially Interrupted [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and mitigate this threat. Query or actuation requests that do not receive a response would result in an error that could be responded to.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

37. Potential Excessive Resource Consumption for EdgeX Foundry or Device/Sensor (physically connected authenticated) [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or Device/Sensor (physically connected authenticated) take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX could send too many requests for data or actuation requests that cause the sensor / device to go offline or appear unresponsive - depending on the sophistication of the device/sensor. In the opposite direction, a device/sensor could be tampered with or improperly configured to send too much data (overwhelming the EdgeX system) causing a DoS. Other than writing the device service to filter data to avoid the “too much” data DoS, this threat is not mitigated.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

38. Data Flow Sniffing [State: Not Applicable] [Priority: High]

Category:	Information Disclosure
Description:	Data flowing across query or actuation may be sniffed by an attacker. Depending on what type of data an attacker can read, it may be used to attack other parts of the system or simply be a disclosure of information leading to compliance violations. Consider encrypting the data flow.
Justification:	<no mitigation provided>
Possible Mitigation:	Securing the data flow to/from a device or sensor is dependent on the OT protocol. In the case of something like BACnet secure (which is based on TLS - see https://www.bacnetinternational.org/page/secureconnect), the flow between EdgeX and the BACnet device can be encryped. The Device Service would need to be written to use that secure communications. In cases where there is no way to secure the communications with the device/sensor under that protocol, then mitigation is via physical security of the device/sensor (along with their connection to the EdgeX host).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation reviewed

39. Data Store Denies Device/Sensor (physically connected authenticated) Potentially Writing Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Device/Sensor (physically connected authenticated) claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

40. The Device/Sensor (physically connected authenticated) Data Store Could Be Corrupted [State: Mitigation Implemented] [Priority: High]

Category:	Tampering
Description:	Data flowing across query or actuation may be tampered with by an attacker. This may lead to corruption of Device/Sensor (physically connected authenticated). Ensure the integrity of the data flow to the data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication and encrypting the data between EdgeX and the device/sensor (ex: using TLS), the data on the wire can be protected. The physcial security of the device/sensor still needs to be achieved to protect someone tampering with the device/sensor (ex: holding a match to a thermostat). As with device/sensors that are not authenticated, additional optional mitigation ideas to mitigate unprotected devices/sensors require modifications to the EdgeX device service. The device service could be constructed to filter data or report and alert when there is not enough data coming from the device or sensor or the sensor/device appears to be offline. Wrong data can be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). All of these have limits and only mitigate the data from being used in the rest of EdgeX once received by the device service. Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could also be used to detect anomalous sensor/device communications and isolate the sensor from the system.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation needed

41. Spoofing of Destination Data Store Device/Sensor (physically connected authenticated) [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	Device/Sensor (physically connected authenticated) may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Device/Sensor (physically connected authenticated). Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication protocol in place (as examplified by BACnet secured or ONVIF cameras with security on), the spoofing device or sensor would not be able to properly authenticated and thereby be denied the ability to send data, be queried. The EdgeX framework has the support to store secrets to authenticate devices.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

42. Spoofing the EdgeX Foundry Process [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	EdgeX Foundry may be spoofed by an attacker and this may lead to unauthorized access to Device/Sensor (physically connected authenticated). Consider using a standard authentication mechanism to identify the source process.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication protocol in place (as examplified by BACnet secured or ONVIF cameras with security on), the device would not get the proper authenticated requests and thereby deny any query or actuation request.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: read

43. Spoofing of Destination Data Store Configuration Files [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Configuration Files may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Configuration Files. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Configuration files are used to seed EdgeX configuration service (core-keeper) before the services are started. Configuration files are made part of the service container (deployed with the container image). The only way to spoof the file is to replace the entire service container with new configuration or to transplant new configuration in the container - both require privileaged access to the host. Additional mitigation when running EdgeX in rootless Docker: the Docker daemon, container processes and bind-mounted volumes are owned by an unprivileged host user rather than root. A compromised container that escapes its namespace inherits only that unprivileged user's permissions, so it cannot read or overwrite configuration files baked into other service containers, replace a service image on disk, or transplant configuration into a running container without first compromising the rootless-Docker user account itself. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

44. Potential Excessive Resource Consumption for EdgeX Foundry or Configuration Files [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	Does EdgeX Foundry or Configuration Files take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	Config file does not consume resources other than file space. Configuration file is deployed with the service container and therefore, without access to the host and Docker, its size is controlled.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: request

45. Elevation Using Impersonation [State: Mitigation Implemented] [Priority: Low]

Category:	Elevation Of Privilege
Description:	EdgeX Foundry may be able to impersonate the context of Nginx in order to gain additional privilege.
Justification:	<no mitigation provided>
Possible Mitigation:	There is no current ability to authenticate Nginx as a caller of EdgeX services from any other local process on the system. However, Impersonating EdgeX would require access to the host system and the Docker network. With this access, many other severe issues could occur (stopping the system, sending incorrect data, etc.). Additional mitigation when running EdgeX in rootless Docker: impersonating an EdgeX service from another local process requires access to the host system and the Docker network. Under rootless Docker the daemon, its socket (/run/user/<uid>/docker.sock) and the bridge network are owned by an unprivileged user, and a compromised container cannot escalate to host root to attach to that network or manipulate other containers. The attacker must first compromise the specific unprivileged user that owns the rootless daemon, raising the bar significantly compared with rootful deployments. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

46. Spoofing the Nginx External Entity [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Nginx may be spoofed by an attacker and this may lead to unauthorized access to EdgeX Foundry. Consider using a standard authentication mechanism to identify the external entity.
Justification:	<no mitigation provided>
Possible Mitigation:	If someone was able to provide a container that was spoofing as Nginx, the service would not know that the response came from something other than Nginx. I.e. - there is no current ability to authenticate Nginx as a caller of EdgeX services from any other local process on the system. However, Nginx is run as a container on the EdgeX Docker network. Replacing/spoofing the Nginx container would require privileaged (root) access to the host. Additional adopter mitigation would include putting TLS in place between EdgeX and Nginx (with TLS cert in place). A spoofing service (in this case Nginx), would not have the appropriate cert in place to participate in the communications. Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the Nginx API-gateway container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

Interaction: request

47. Weakness in SSO Authorization [State: Mitigation Implemented] [Priority: Low]

Category:	Elevation Of Privilege
Description:	Common SSO implementations such as OAUTH2 and OAUTH Wrap are vulnerable to MitM attacks.
Justification:	<no mitigation provided>
Possible Mitigation:	In EdgeX, Nginx is configured to use JWT token authentication. OAUTH2 and OAUTH are not allowed as of EdgeX v4 (Ireland release - see https://docs.edgexfoundry.org/4.0/security/Ch-APIGateway/#configuration-of-jwt-authentication-for-api-gateway). JWT token expires in one hour by default.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

48. Data Flow request Is Potentially Interrupted [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Nginx can be configured the rate limiting to prevent a DoS attack. See https://blog.nginx.org/blog/rate-limiting-nginx
Mitigator:	Third Party
Mitigation Status:	Mitigation written

49. External Entity Nginx Potentially Denies Receiving Data [State: Not Applicable] [Priority: Low]

Category:	Repudiation
Description:	Nginx claims that it did not receive data from a process on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Nginx provides logging, but if it did not see a request from a browser or API caller like Postman, then nothing gets issued to EdgeX.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

Interaction: response

50. Weakness in SSO Authorization [State: Mitigation Implemented] [Priority: Low]

Category:	Elevation Of Privilege
Description:	Common SSO implementations such as OAUTH2 and OAUTH Wrap are vulnerable to MitM attacks.
Justification:	<no mitigation provided>
Possible Mitigation:	In EdgeX, Nginx is configured to use JWT token authentication. OAUTH2 and OAUTH are not allowed as of EdgeX v4 (see https://docs.edgexfoundry.org/4.0/security/Ch-APIGateway/#configuration-of-jwt-authentication-for-api-gateway). JWT token expires in one hour by default.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

Interaction: response

51. Data Flow response Is Potentially Interrupted [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Nginx can be configured the rate limiting to prevent a DoS attack. See https://blog.nginx.org/blog/rate-limiting-nginx
Mitigator:	Third Party
Mitigation Status:	Mitigation written

52. External Entity Browser/API Caller Potentially Denies Receiving Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Browser/API Caller claims that it did not receive data from a process on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Nginx provides logging to document all requests.
Mitigator:	Third Party
Mitigation Status:	Mitigation written

Interaction: sensor data

53. Spoofing the EdgeX Foundry Process [State: Not Applicable] [Priority: High]

Category:	Spoofing
Description:	EdgeX Foundry may be spoofed by an attacker and this may lead to information disclosure by Device/Sensor. Consider using a standard authentication mechanism to identify the destination process.
Justification:	<no mitigation provided>
Possible Mitigation:	Without an authentication protocol, there is no mitigation for this threat. The device would not be able to determine that the Spoofing EdgeX caller is not EdgeX.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

54. Spoofing of Source Data Store Device/Sensor [State: Not Applicable] [Priority: High]

Category:	Spoofing
Description:	Device/Sensor may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Due to the nature of many protocols, an outside agent could spoof as a ligitimage device/sensor. This is of particular concern if the device service auto provisions the devices/sensors without any authentication. Auto provisioning shold be limited to pick up trusted devices. Protocols such as BACnet do allow for authentication with the device/sensor. Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system, but there is no ability in EdgeX directly to protect against a spoofed device/sensor that does not authenticate (which is the norm in some older OT protocols).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation reviewed

55. Potential Data Repudiation by EdgeX Foundry [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	EdgeX Foundry claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

56. Weak Access Control for a Resource [State: Not Applicable] [Priority: High]

Category:	Information Disclosure
Description:	Improper data protection of Device/Sensor can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	Securing the data flow to/from a device or sensor is dependent on the OT protocol. In the case of most simple and typically older OT protocols (Modbus or GPIO as examples), there is no way to secure the communications with the device/sensor under that protocol. Critical sensors/devices of this nature should be physically secured (along with their physical connection to the EdgeX host).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation reviewed

57. Potential Process Crash or Stop for EdgeX Foundry [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	EdgeX Foundry crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	Stopping EdgeX services requires host access (and access to the Docker engine, Docker containers and Docker network) with eleveated privileges or access to the EdgeX system management APIs (requiring the Nginx JWT token).
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

58. Data Flow sensor data Is Potentially Interrupted [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

59. Data Store Inaccessible [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

60. EdgeX Foundry May be Subject to Elevation of Privilege Using Remote Code Execution [State: Not Applicable] [Priority: Low]

Category:	Elevation Of Privilege
Description:	Device/Sensor may be able to remotely execute code for EdgeX Foundry.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX does not execute random code based on input from a device or sensor (as if it was from a web application with something like unsanitized inputs). All data is santized by extracting expected data values from the sensor input data, creating an EdgeX event/reading message and sending that into the rest of EdgeX. The data coming from a sensor could be used to kill the service (ex: buffer overflow attack and sending too much data for the service to consume for example - see DoS threats). The device service in EdgeX can be written to reject to large of a request (for example). In some cases, a protocol may offer dual authentication, and if used, help to mitigate RCE. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

61. Elevation by Changing the Execution Flow in EdgeX Foundry [State: Mitigation Implemented] [Priority: High]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into EdgeX Foundry in order to change the flow of program execution within EdgeX Foundry to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence on a sensor or device is one of the biggest threats to an edge system and one of the hardest to mitigate. If tampered with, a sensor or device could be used to send the wrong data (e.g., force a temp sensor to send a signal that it is too hot when it is really too cold). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and device/sensor and mitigate this threat. Wrong data can be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

Interaction: sensor data

62. External Entity Megaservice - Cloud or Enterprise Potentially Denies Receiving Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Megaservice - Cloud or Enterprise claims that it did not receive data from a process on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Application services can use elevated log level to log all exports.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

63. Spoofing of the Megaservice - Cloud or Enterprise External Destination Entity [State: Not Applicable] [Priority: Low]

Category:	Spoofing
Description:	Megaservice - Cloud or Enterprise may be spoofed by an attacker and this may lead to data being sent to the attacker's target instead of Megaservice - Cloud or Enterprise. Consider using a standard authentication mechanism to identify the external entity.
Justification:	<no mitigation provided>
Possible Mitigation:	Spoofing as the browser or any tool or system of EdgeX is immaterial. Any browser or API tool like Postman would need to request access using the API gateway token. With the token, they are considered a legitimate user of EdgeX. In the case of a megacloud or enterprise, most communication is from EdgeX to that system vs sending requests to EdgeX (as an export)
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

64. Data Flow sensor data Is Potentially Interrupted [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Data flow is in one direction (exporting from EdgeX to the cloud). If the data is deemed critical and if by some means the data flow was interrupted, then store and forward mechisms in EdgeX allow the data to be sent once the communications are re-established. If using MQTT, the quality of service (QoS) setting on a message broker can also be used to ensure all data is delivered or it is resent later.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

Interaction: sensor data

65. Data Flow sensor data Is Potentially Interrupted [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Data flow is in one direction (exporting from EdgeX to the external message bus). If the data is deemed critical and if by some means the data flow was interrupted, store and forward mechisms in EdgeX allow the data to be sent once the communications are re-established. If using MQTT, the quality of service (QoS) setting on a message broker can also be used to ensure all data is delivered or it is resent later.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

66. External Entity Message Topic Potentially Denies Receiving Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Message Topic claims that it did not receive data from a process on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Application services can use elevated log level to log all exports.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

67. Spoofing of the Message Topic External Destination Entity [State: Not Applicable] [Priority: Low]

Category:	Spoofing
Description:	Message Topic may be spoofed by an attacker and this may lead to data being sent to the attacker's target instead of Message Topic. Consider using a standard authentication mechanism to identify the external entity.
Justification:	<no mitigation provided>
Possible Mitigation:	Spoofing as the browser or any tool or system of EdgeX is immaterial. Any browser or API tool like Postman would need to request access using the API gateway token. With the token, they are considered a legitimate user of EdgeX. In the case of an external message bus, most communication is from EdgeX to that system vs sending requests to EdgeX (as an export).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

Interaction: sensor data

68. Spoofing the EdgeX Foundry Process [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	EdgeX Foundry may be spoofed by an attacker and this may lead to information disclosure by Device/Sensor (physically connected authenticated). Consider using a standard authentication mechanism to identify the destination process.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication protocol in place (as examplified by BACnet secured or ONVIF cameras with security on), the device would not get the proper authenticated requests and thereby deny any query or actuation request.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation needed

69. Spoofing of Source Data Store Device/Sensor (physically connected authenticated) [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	Device/Sensor (physically connected authenticated) may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication protocol in place (as examplified by BACnet secured or ONVIF cameras with security on), the spoofing device or sensor would not be able to properly authenticated and thereby be denied the ability to send data, be queried. The EdgeX framework has the support to store secrets to authenticate devices.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

70. Potential Data Repudiation by EdgeX Foundry [State: Mitigation Implemented] [Priority: High]

Category:	Repudiation
Description:	EdgeX Foundry claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

71. Weak Access Control for a Resource [State: Not Applicable] [Priority: High]

Category:	Information Disclosure
Description:	Improper data protection of Device/Sensor (physically connected authenticated) can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	Securing the data flow to/from a device or sensor is dependent on the OT protocol. In the case of something like BACnet secure (which is based on TLS - see https://www.bacnetinternational.org/page/secureconnect), the flow between EdgeX and the BACnet device can be encryped. The Device Service would need to be written to use that secure communications. In cases where there is no way to secure the communications with the device/sensor under that protocol, then mitigation is via physical security of the device/sensor (along with their connection to the EdgeX host).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation reviewed

72. Potential Process Crash or Stop for EdgeX Foundry [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	EdgeX Foundry crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	Stopping EdgeX services requires host access (and access to the Docker engine, Docker containers and Docker network) with eleveated privileges.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

73. Data Flow sensor data Is Potentially Interrupted [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

74. Data Store Inaccessible [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or remove a device/senosr causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

75. EdgeX Foundry May be Subject to Elevation of Privilege Using Remote Code Execution [State: Not Applicable] [Priority: Low]

Category:	Elevation Of Privilege
Description:	Device/Sensor (physically connected authenticated) may be able to remotely execute code for EdgeX Foundry.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX does not execute random code based on input from a device or sensor (as if it was from a web application with something like unsanitized inputs). All data is santized by extracting expected data values from the sensor input data, creating an EdgeX event/reading message and sending that into the rest of EdgeX. The data coming from a sensor could be used to kill the service (ex: buffer overflow attack and sending too much data for the service to consume for example - see DoS threats). The device service in EdgeX can be written to reject to large of a request (for example). In some cases, a protocol may offer dual authentication, and if used, help to mitigate RCE Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

76. Elevation by Changing the Execution Flow in EdgeX Foundry [State: Mitigation Implemented] [Priority: High]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into EdgeX Foundry in order to change the flow of program execution within EdgeX Foundry to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence on a sensor or device is one of the biggest threats to an edge system and one of the hardest to mitigate. If tampered with, a sensor or device could be used to send the wrong data (e.g., force a temp sensor to send a signal that it is too hot when it is really too cold). EdgeX has no means to protect the "wire" to a physically connected device/sensor. Physical security is required to protect the wire and device/sensor and mitigate this threat. Wrong data can be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

Interaction: sensor data

77. Spoofing of Source Data Store Device/Sensor (REST authenticated) [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Device/Sensor (REST authenticated) may be spoofed by an attacker and this may lead to incorrect data delivered to Nginx. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication in place the REST caller would not get the proper authenticated by a spoofed Nginx and thereby deny any query request.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

78. External Entity Nginx Potentially Denies Receiving Data [State: Mitigation Implemented] [Priority: Low]

Category:	Repudiation
Description:	Nginx claims that it did not receive data from a process on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

79. Weak Access Control for a Resource [State: Mitigation Implemented] [Priority: High]

Category:	Information Disclosure
Description:	Improper data protection of Device/Sensor (REST authenticated) can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	REST requests and responses to/through Nginx are encrypted by default.
Mitigator:	Third Party
Mitigation Status:	Mitigation reviewed

80. Data Flow sensor data Is Potentially Interrupted [State: Mitigation Implemented] [Priority: Low]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Nginx can be configured rate limiting to prevent a DoS attack. See https://blog.nginx.org/blog/rate-limiting-nginx
Mitigator:	Third Party
Mitigation Status:	Mitigation written

81. Data Store Inaccessible [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the network communication connection causing major disruption of service (ex: removing or cutting off comms to a critical temperature resource of a heating or cooling machine). EdgeX has no means to protect the network connection. Physical security is required to protect the wire and device/sensor and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

82. Weakness in SSO Authorization [State: Mitigation Implemented] [Priority: High]

Category:	Elevation Of Privilege
Description:	Common SSO implementations such as OAUTH2 and OAUTH Wrap are vulnerable to MitM attacks.
Justification:	<no mitigation provided>
Possible Mitigation:	In EdgeX, Nginx is configured to use JWT token authentication. OAUTH2 and OAUTH are not allowed as of EdgeX v4 (see https://docs.edgexfoundry.org/4.0/security/Ch-APIGateway/#configuration-of-jwt-authentication-for-api-gateway). JWT token expires in one hour by default.
Mitigator:	Third Party
Mitigation Status:	Mitigation written

Interaction: sensor data

83. Elevation by Changing the Execution Flow in EdgeX Foundry [State: Mitigation Implemented] [Priority: Low]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into EdgeX Foundry in order to change the flow of program execution within EdgeX Foundry to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Access to publish data through the external MQTT broker is protected with authentication. Wrong data can also be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

84. EdgeX Foundry May be Subject to Elevation of Privilege Using Remote Code Execution [State: Mitigation Implemented] [Priority: Low]

Category:	Elevation Of Privilege
Description:	Device/Sensor (via external MQTT broker - authenticated) may be able to remotely execute code for EdgeX Foundry.
Justification:	<no mitigation provided>
Possible Mitigation:	EdgeX does not execute random code based on input from a device or sensor (as if it was from a web application with something like unsanitized inputs). All data is santized by extracting expected data values from the sensor input data, creating an EdgeX event/reading message and sending that into the rest of EdgeX. The data coming from a sensor could be used to kill the service (ex: buffer overflow attack and sending too much data for the service to consume for example - see DoS threats). The device service in EdgeX can be written to reject to large of a request (for example). In some cases, a protocol may offer dual authentication, and if used, help to mitigate RCE Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

85. Data Store Inaccessible [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or MQTT broker causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the connection to the external MQTT broker, the broker itself, or publisher to the broker. Physical and sytem security is required to protect these and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

86. Data Flow sensor data Is Potentially Interrupted [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence could break the communication connection or MQTT broker causing major disruption of service (ex: removing or cutting off comms to a critical temperature sensor of a heating or cooling machine). EdgeX has no means to protect the connection to the external MQTT broker, the broker itself, or publisher to the broker. Physical and sytem security is required to protect these and mitigate this threat. The device service does track "last connected" and that timestamp could be monitored for outside of normal reporting ranges.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

87. Potential Process Crash or Stop for EdgeX Foundry [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	EdgeX Foundry crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	Stopping EdgeX services requires host access (and access to the Docker engine, Docker containers and Docker network) with eleveated privileges or access to the EdgeX system management APIs (requiring the Nginx JWT token).
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

88. Weak Access Control for a Resource [State: Mitigation Implemented] [Priority: High]

Category:	Information Disclosure
Description:	Improper data protection of Device/Sensor (via external MQTT broker - authenticated) can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	Requires encryption of the communications (on both the EdgeX and device/sensor ends) which is not in place by default. MQTTS could be implemented by the adopter with the appropriate MQTT broker.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

89. Potential Data Repudiation by EdgeX Foundry [State: Mitigation Implemented] [Priority: High]

Category:	Repudiation
Description:	EdgeX Foundry claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level (set writable configuration log level to DEBUG in the device service) can be used to log all data communications. Log level on the message bus may also be elevated.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

90. Spoofing of Source Data Store Device/Sensor (via external MQTT broker - authenticated) [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	Device/Sensor (via external MQTT broker - authenticated) may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication in place the spoofing MQTT publisher of sensor data (or the spoofed external message broker) would not be properly authenticated and thereby deny any request. The EdgeX framework has the support to store secrets to authenticate devices.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

91. Spoofing the EdgeX Foundry Process [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	EdgeX Foundry may be spoofed by an attacker and this may lead to information disclosure by Device/Sensor (via external MQTT broker - authenticated). Consider using a standard authentication mechanism to identify the destination process.
Justification:	<no mitigation provided>
Possible Mitigation:	With authentication in place the spoofing MQTT receiver of sensor data (or the spoofed external message broker) would not be properly authenticated and thereby be unable to receive. The EdgeX framework has the support to store secrets to authenticate devices.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: service secrets

92. Weak Access Control for a Resource [State: Mitigation Implemented] [Priority: Medium]

Category:	Information Disclosure
Description:	Improper data protection of SecretStore can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	The SecretStore root and service level tokens are revoked after setup and then all interactions is via the programmatic interface (with properly authenticated token). There are additional options to SecretStore Master Key encryption provided here: https://docs.edgexfoundry.org/4.0/threat-models/secret-store/vault_master_key_encryption/
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

93. Spoofing of Source Data Store SecretStore [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	SecretStore may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	If someone was able to provide a container that was spoofing as SecretStore, the service would not know that the response came from something other than SecretStore. However, SecretStore is run as a container on the EdgeX Docker network. Replacing/spoofing the SecretStore container would require privileaged (root) access to the host. Additional adopter mitigation would include putting TLS in place between EdgeX and SecretStore(with TLS cert in place). A spoofing service (in this case SecretStore), would not have the appropriate cert in place to participate in the communications. Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the SecretStore (OpenBao) container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Interaction: subscribed message

94. Weak Access Control for a Resource [State: Mitigation Implemented] [Priority: Low]

Category:	Information Disclosure
Description:	Improper data protection of Message Bus Broker can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	When running EdgeX in secure mode the MQTT broker is secured with a username/password. This in turn creates a Secure MessageBus. See https://docs.edgexfoundry.org/4.0/security/Ch-Secure-MessageBus/. MQTTS can used for internal message bus communications but not provided by EdgeX
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

95. Spoofing of Source Data Store Message Bus Broker [State: Mitigation Implemented] [Priority: Low]

Category:	Spoofing
Description:	Message Bus Broker may be spoofed by an attacker and this may lead to incorrect data delivered to EdgeX Foundry. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	The message bus when requiring a broker (MQTT broker for example) is run as a container on the EdgeX Docker network. Replacing/spoofing the broker container would require privileaged access to the host. Additional mitigation when EdgeX container images are signed (e.g., with Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: an attacker cannot substitute a tampered or imposter image for the message-bus broker container via a compromised registry, a man-in-the-middle of `docker pull`, or a tampered local image cache. The signing key must be protected by an HSM or KMS and verification must be enforced by the runtime (for example a cosign policy controller or content-trust-enabled daemon). Image signing covers image authenticity only; pair it with SBOM and SLSA provenance attestations for build-time integrity and with timely patching, because a legitimately signed image with an exploitable flaw is still exploitable. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation reviewed

Diagram: EdgeX Service to Service HTTP comms

EdgeX Service to Service HTTP comms Diagram Summary:

Interaction: HTTP

96. EdgeX Service A Process Memory Tampered [State: Needs Investigation] [Priority: High]

Category:	Tampering
Description:	If EdgeX Service A is given access to memory, such as shared memory or pointers, or is given the ability to control what EdgeX Service B executes (for example, passing back a function pointer.), then EdgeX Service A can tamper with EdgeX Service B. Consider if the function could work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it.
Justification:	<no mitigation provided>
Possible Mitigation:	Not applicable in containerized environments. Separate processes running in separate containers. Additional mitigation when running EdgeX in rootless Docker: user-namespace and PID-namespace isolation means a compromised service cannot ptrace, signal or read the memory of processes in sibling containers. UID 0 inside container A maps to a different unprivileged host UID than UID 0 inside container B, so cross-service in-memory tampering via /proc, ptrace or shared kernel facilities is blocked unless the attacker first compromises the unprivileged host user that owns the rootless daemon. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Mitigation written

97. Elevation Using Impersonation [State: Needs Investigation] [Priority: High]

Category:	Elevation Of Privilege
Description:	EdgeX Service B may be able to impersonate the context of EdgeX Service A in order to gain additional privilege.
Justification:	<no mitigation provided>
Possible Mitigation:	Impersonating another EdgeX service would require access to the host system and the Docker network. Ports to the service APIs is restricted except through Nginx. If extra security is needed or if an adopter is running EdgeX services in a distributed environment (multiple hosts), then overlay network encryption can be used (see example: https://github.com/edgexfoundry/edgex-examples/tree/update-custom-trigger-multiple-pipelines/security/remote_devices/docker-swarm). Alternately, TLS can be used to encrypt all traffic. Service-to-service calls behind Nginx are unauthenticated in the current implementation. Additional mitigation when running EdgeX in rootless Docker: impersonating an EdgeX service from another local process requires access to the host system and the Docker network. Under rootless Docker the daemon, its socket (/run/user/<uid>/docker.sock) and the bridge network are owned by an unprivileged user, and a compromised container cannot escalate to host root to attach to that network or manipulate other containers. The attacker must first compromise the specific unprivileged user that owns the rootless daemon, raising the bar significantly compared with rootful deployments. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

Diagram: EdgeX Service to Service message bus comms

EdgeX Service to Service message bus comms Diagram Summary:

Interaction: message bus (MQTT, NATS)

98. Elevation Using Impersonation [State: Mitigation Implemented] [Priority: Medium]

Category:	Elevation Of Privilege
Description:	EdgeX Service B may be able to impersonate the context of EdgeX Service A in order to gain additional privilege.
Justification:	<no mitigation provided>
Possible Mitigation:	All services are required to authroize to the message bus, but all services authorized on the message bus have equal privilege to send and receive messages. Impersonating another EdgeX service would require access to the host system and the Docker network. Ports to the service message bus is restricted to internal communications only. If extra security is needed or if an adopter is running EdgeX services in a distributed environment (multiple hosts), then overlay network encryption can be used (see example: https://github.com/edgexfoundry/edgex-examples/tree/update-custom-trigger-multiple-pipelines/security/remote_devices/docker-swarm). Alternately, secure MQTT (MQTTS) message bus communications can be used. Additional mitigation when running EdgeX in rootless Docker: impersonating an EdgeX service from another local process requires access to the host system and the Docker network. Under rootless Docker the daemon, its socket (/run/user/<uid>/docker.sock) and the bridge network are owned by an unprivileged user, and a compromised container cannot escalate to host root to attach to that network or manipulate other containers. The attacker must first compromise the specific unprivileged user that owns the rootless daemon, raising the bar significantly compared with rootful deployments. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

99. EdgeX Service A Process Memory Tampered [State: Mitigation Implemented] [Priority: High]

Category:	Tampering
Description:	If EdgeX Service A is given access to memory, such as shared memory or pointers, or is given the ability to control what EdgeX Service B executes (for example, passing back a function pointer.), then EdgeX Service A can tamper with EdgeX Service B. Consider if the function could work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it.
Justification:	<no mitigation provided>
Possible Mitigation:	Not applicable in containerized environments. Separate processes running in separate containers. Additional mitigation when running EdgeX in rootless Docker: user-namespace and PID-namespace isolation means a compromised service cannot ptrace, signal or read the memory of processes in sibling containers. UID 0 inside container A maps to a different unprivileged host UID than UID 0 inside container B, so cross-service in-memory tampering via /proc, ptrace or shared kernel facilities is blocked unless the attacker first compromises the unprivileged host user that owns the rootless daemon. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

Diagram: Access via VPN

Access via VPN Diagram Summary:

Diagram: Host Access

Host Access Diagram Summary:

Diagram: Open Port Protections

Open Port Protections Diagram Summary:

Diagram: Device Protocol Threats - Modbus example

Device Protocol Threats - Modbus example Diagram Summary:

Interaction: Binary RTU (GET or SET)

100. Spoofing of Destination Data Store Modbus Device/Sensor [State: Needs Investigation] [Priority: High]

Category:	Spoofing
Description:	Modbus Device/Sensor may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Modbus Device/Sensor. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	As there are no means to secure Modbus communications via the protocol exchange, the Modbus device/sensor and its wired connection must be physically secured to insure no spoofing or unauthorized collection of data or actuation with the device.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

101. Potential Excessive Resource Consumption for Modbus Device Service or Modbus Device/Sensor [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	Does Modbus Device Service or Modbus Device/Sensor take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	As an unprotected (physically) Modbus device/sensor can be used to create a DOS attack (sending too much data), or send erroneous/faulty data, or disrupted / cut off and thereofore not send any data, the device service must be written to monitor and thwart the flow of too much data, notify when data is outside of expected ranges and notify when it appears the device/sensor is no longer connected and reporting. Provisioning of the device using known or specific ranges of MAC addresses (or IP addresses if using Modbus TCP/IP), etc. can help onboarding with an unauthorized device.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

102. Spoofing the Modbus Device Service Process [State: Needs Investigation] [Priority: High]

Category:	Spoofing
Description:	Modbus Device Service may be spoofed by an attacker and this may lead to unauthorized access to Modbus Device/Sensor. Consider using a standard authentication mechanism to identify the source process.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized by the Protocol, any service (any spoof) could appear to be the EdgeX device service and either get data from or (worse) actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire). Additional mitigation when running EdgeX in rootless Docker: spoofing the device-service process on the host requires compromising the unprivileged user account that runs the rootless Docker daemon. A compromised container cannot gain host root and therefore cannot register itself as the device-service container or open the corresponding device files unless the operator has explicitly granted access (for example, by chmod 666 on the serial port as documented for rootless EdgeX). The rootless-Docker guide warns that those permission relaxations carry their own risk. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

103. The Modbus Device/Sensor Data Store Could Be Corrupted [State: Needs Investigation] [Priority: High]

Category:	Tampering
Description:	Data flowing across Binary RTU (GET or SET) may be tampered with by an attacker. This may lead to corruption of Modbus Device/Sensor. Ensure the integrity of the data flow to the data store.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized by the protocol, the communication across the wire could be tampered with or shut off to cause DOS attacts or actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire).
Mitigator:	Adopter
Mitigation Status:	Mitigation written

104. Data Store Denies Modbus Device/Sensor Potentially Writing Data [State: Not Applicable] [Priority: High]

Category:	Repudiation
Description:	Modbus Device/Sensor claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	It is unlikely that a Modbus device/sensor has a log to provide an audit of requests.
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

105. Data Flow Sniffing [State: Not Applicable] [Priority: High]

Category:	Information Disclosure
Description:	Data flowing across Binary RTU (GET or SET) may be sniffed by an attacker. Depending on what type of data an attacker can read, it may be used to attack other parts of the system or simply be a disclosure of information leading to compliance violations. Consider encrypting the data flow.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized nor encrypted by the Protocol, any service (any spoof) could appear to be the EdgeX device service and either get data from or (worse) actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire).
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

106. Weak Credential Transit [State: Needs Investigation] [Priority: High]

Category:	Information Disclosure
Description:	Credentials on the wire are often subject to sniffing by an attacker. Are the credentials re-usable/re-playable? Are credentials included in a message? For example, sending a zip file with the password in the email. Use strong cryptography for the transmission of credentials. Use the OS libraries if at all possible, and consider cryptographic algorithm agility, rather than hardcoding a choice.
Justification:	<no mitigation provided>
Possible Mitigation:	Modbus does not support any type of authentication/authorization in communications. Physical security of the device and wire are the only ways to thwart information disclosure.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

107. Data Flow Binary RTU (GET or SET) Is Potentially Interrupted [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized by the protocol, the communication across the wire could be tampered with or shut off to cause DOS attacts or actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire).
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

108. Data Store Inaccessible [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized by the protocol, the communication across the wire could be tampered with to cause DOS attacts or actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire).
Mitigator:	Adopter
Mitigation Status:	Mitigation written

Interaction: Binary RTU Response (GET or SE

109. Spoofing of Source Data Store Modbus Device/Sensor [State: Needs Investigation] [Priority: High]

Category:	Spoofing
Description:	Modbus Device/Sensor may be spoofed by an attacker and this may lead to incorrect data delivered to Modbus Device Service. Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	As an unprotected (physically) Modbus device/sensor can be used to create a DOS attack (sending too much data), or send erroneous/faulty data, or disrupted / cut off and thereofore not send any data, the device service must be written to monitor and thwart the flow of too much data, notify when data is outside of expected ranges and notify when it appears the device/sensor is no longer connected and reporting. Provisioning of the device using known or specific ranges of MAC addresses (or IP addresses if using Modbus TCP/IP), etc. can help onboarding with an unauthorized device.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

110. Weak Access Control for a Resource [State: Not Applicable] [Priority: Low]

Category:	Information Disclosure
Description:	Improper data protection of Modbus Device/Sensor can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	As Modbus is a simple protocol (reporting data or reacting to accuation requests), it is not possible for the device or sensor to gain other data from the device service (or EdgeX as a whole).
Mitigator:	No mitigation or not applicable
Mitigation Status:	Cannot mitigate or not appilcable

111. Spoofing the Modbus Device Service Process [State: Not Applicable] [Priority: High]

Category:	Spoofing
Description:	Modbus Device Service may be spoofed by an attacker and this may lead to information disclosure by Modbus Device/Sensor. Consider using a standard authentication mechanism to identify the destination process.
Justification:	<no mitigation provided>
Possible Mitigation:	As there are no means to secure Modbus communications via the protocol exchange, the Modbus device/sensor and its wired connection must be physically secured to insure no spoofing or unauthorized collection of data or actuation with the device. Additional mitigation when running EdgeX in rootless Docker: spoofing the device-service process on the host requires compromising the unprivileged user account that runs the rootless Docker daemon. A compromised container cannot gain host root and therefore cannot register itself as the device-service container or open the corresponding device files unless the operator has explicitly granted access (for example, by chmod 666 on the serial port as documented for rootless EdgeX). The rootless-Docker guide warns that those permission relaxations carry their own risk. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

112. Potential Data Repudiation by Modbus Device Service [State: Mitigation Implemented] [Priority: High]

Category:	Repudiation
Description:	Modbus Device Service claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Use of elevated log level can be used to log all data communications from a device/sensor.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

113. Potential Process Crash or Stop for Modbus Device Service [State: Mitigation Implemented] [Priority: Medium]

Category:	Denial Of Service
Description:	Modbus Device Service crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	Stopping EdgeX services requires host access (and access to the Docker engine, Docker containers and Docker network) with eleveated privileges.
Mitigator:	EdgeX Foundry
Mitigation Status:	Mitigation written

114. Data Flow Binary RTU Response (GET or SET Is Potentially Interrupted [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized by the protocol, the communication across the wire could be tampered with or shut off to cause DOS attacts or actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire).
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

115. Data Store Inaccessible [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	As the communication to a Modbus device / sensor is not authenticated/authorized by the protocol, the communication across the wire could be tampered with to cause DOS attacts or actuate the device illegally. Given the nature of Modbus, the only way to protect against this threat is to physically secure the device and connectivity (wire).
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

116. Modbus Device Service May be Subject to Elevation of Privilege Using Remote Code Execution [State: Needs Investigation] [Priority: High]

Category:	Elevation Of Privilege
Description:	Modbus Device/Sensor may be able to remotely execute code for Modbus Device Service.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence on a sensor or device is one of the biggest threats to an edge system and one of the hardest to mitigate. If tampered with, a sensor or device could be used to send the wrong data (e.g., force a temp sensor to send a signal that it is too hot when it is really too cold), too much data (overwhelming the edge system by causing the sensor to send data too often), or not enough data (e.g., disconnecting a critical monitor sensor that would cause a system to stop). The device service can be constructed to filter data to avoid the “too much” data DoS. The device service can be constructed to report and alert when there is not enough data coming from the device or sensor or the sensor/device appears to be offline (provided by the last connected tracking in EdgeX). Wrong data can be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Mitigation Research needed

117. Elevation by Changing the Execution Flow in Modbus Device Service [State: Not Applicable] [Priority: High]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into Modbus Device Service in order to change the flow of program execution within Modbus Device Service to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Outside influence on a sensor or device is one of the biggest threats to an edge system and one of the hardest to mitigate. If tampered with, a sensor or device could be used to send the wrong data (e.g., force a temp sensor to send a signal that it is too hot when it is really too cold), too much data (overwhelming the edge system by causing the sensor to send data too often), or not enough data (e.g., disconnecting a critical monitor sensor that would cause a system to stop). The device service can be constructed to filter data to avoid the “too much” data DoS. The device service can be constructed to report and alert when there is not enough data coming from the device or sensor or the sensor/device appears to be offline (provided by the last connected tracking in EdgeX). Wrong data can be mitigated by having the device service look for expected ranges of values (as supported by min/max attributes on device profiles). Physical security of the sensor and communications (wire) offer the best hope to mitigate this threat. Commercial 3rd party software or extensions to EdgeX (see, for example, RSA’s Netwitness IoT: https://www.netwitness.com/en-us/products/iot/) could be used to detect anomalous sensor/device communications and isolate the sensor from the system. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Cannot mitigate or not appilcable

Diagram: Open Bao

Open Bao Diagram Summary:

Interaction: PKCS11 Request

118. Spoofing of Destination Data Store Storage [State: Mitigation Implemented] [Priority: High]

Category:	Spoofing
Description:	TPM may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of TPM. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Spoofing is not possible with TPM
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

119. The Storage Data Store Could Be Corrupted [State: Not Started] [Priority: High]

Category:	Tampering
Description:	Data flowing across PKCS11 Request may be tampered with by an attacker. This may lead to corruption of TPM. Ensure the integrity of the data flow to the data store.
Justification:	<no mitigation provided>
Possible Mitigation:	TPM is believed not to be corrupted. Additional mitigation when running EdgeX in rootless Docker: container layers and bind-mounted volumes (including OpenBao's storage backend, log directories and key material) are owned by the unprivileged host user that runs the rootless daemon and live under that user's $XDG_DATA_HOME/docker tree, not under root-owned host paths. Other host users and escaped containers cannot bypass in-application access controls by reading or writing those files directly. This raises the cost of any filesystem-level disclosure or tampering attack but does not remove the need for at-rest encryption of the data the rootless user does control. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

120. Data Store Denies Storage Potentially Writing Data [State: Mitigation Implemented] [Priority: High]

Category:	Repudiation
Description:	TPM claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	It is mitigated using pkcs11 interface. If there is an error with PKCS11 interface, it would log,
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

121. Authorization Bypass [State: Mitigation Implemented] [Priority: High]

Category:	Information Disclosure
Description:	Can you access TPM and bypass the permissions for the object? For example by editing the files directly with a hex editor, or reaching it via filesharing? Ensure that your program is the only one that can access the data, and that all other subjects have to use your interface.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

122. Weak Credential Storage [State: Mitigation Implemented] [Priority: High]

Category:	Information Disclosure
Description:	Credentials held at the server are often disclosed or tampered with and credentials stored on the client are often stolen. For server side, consider storing a salted hash of the credentials instead of storing the credentials themselves. If this is not possible due to business requirements, be sure to encrypt the credentials before storage, using an SDL-approved mechanism. For client side, if storing credentials is required, encrypt them and protect the data store in which they're stored
Justification:	<no mitigation provided>
Possible Mitigation:	Additional mitigation when running EdgeX in rootless Docker: credential material persisted in container volumes (including OpenBao seal keys and SecretStore-issued tokens) is owned by an unprivileged host user, not root. A container escape only yields that unprivileged user's permissions, so attempts to exfiltrate credentials by reading host-level paths from a compromised neighbour container are blocked. Encryption (seal/unseal, salted hashes) remains the primary control; rootless Docker reduces the blast radius of a host-side compromise. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation reviewed

123. Potential Excessive Resource Consumption for OpenBao Server (Hosted on Device) or Storage [State: Mitigation Implemented] [Priority: High]

Category:	Denial Of Service
Description:	Does OpenBao Server (Hosted on Device) or TPM take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

124. Data Flow PKCS11 Request Is Potentially Interrupted [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

125. Data Store Inaccessible [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	It is assumed that TPM will always be always available.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

Interaction: Read

126. Storage is not protected. Its a part of file system. [State: Not Started] [Priority: High]

Category:	Tampering
Description:	Storage may be spoofed by an attacker and this may lead to incorrect data delivered to OpenBao Server (Hosted on Device) . Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Storage should be encrypted. Additional mitigation when running EdgeX in rootless Docker: container layers and bind-mounted volumes (including OpenBao's storage backend, log directories and key material) are owned by the unprivileged host user that runs the rootless daemon and live under that user's $XDG_DATA_HOME/docker tree, not under root-owned host paths. Other host users and escaped containers cannot bypass in-application access controls by reading or writing those files directly. This raises the cost of any filesystem-level disclosure or tampering attack but does not remove the need for at-rest encryption of the data the rootless user does control. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

127. Weak Access Control for a Resource [State: Not Started] [Priority: High]

Category:	User-defined
Description:	Improper data protection of Storage can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	OpenBao uses role based access, TTL for keys, Sets limit of how many times a key can be used.
Mitigator:	Adopter
Mitigation Status:	Mitigation written

Interaction: Request

128. Replay Attacks [State: Not Applicable] [Priority: High]

Category:	Tampering
Description:	Packets or messages without sequence numbers or timestamps can be captured and replayed in a wide variety of ways. Implement or utilize an existing communication protocol that supports anti-replay techniques (investigate sequence numbers before timers) and strong integrity.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

129. Collision Attacks [State: Needs Investigation] [Priority: High]

Category:	Tampering
Description:	Attackers who can send a series of packets or messages may be able to overlap data. For example, packet 1 may be 100 bytes starting at offset 0. Packet 2 may be 100 bytes starting at offset 25. Packet 2 will overwrite 75 bytes of packet 1. Ensure you reassemble data before filtering it, and ensure you explicitly handle these sorts of cases.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

130. Potential Data Repudiation by OpenBao Server (Hosted on Device) [State: Mitigation Implemented] [Priority: High]

Category:	Repudiation
Description:	OpenBao Server (Hosted on Device) claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Data repudiation is not possible coz openbao logs everything related to its encryption services.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

131. Weak Authentication Scheme [State: Needs Investigation] [Priority: High]

Category:	Information Disclosure
Description:	Custom authentication schemes are susceptible to common weaknesses such as weak credential change management, credential equivalence, easily guessable credentials, null credentials, downgrade authentication or a weak credential change management system. Consider the impact and potential mitigations for your custom authentication scheme.
Justification:	<no mitigation provided>
Possible Mitigation:	Role based access would enable strong authentication mechanism. Need to investigate.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

132. Potential Process Crash or Stop for OpenBao Server (Hosted on Device) [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	OpenBao Server (Hosted on Device) crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	Client crashing is not applicable for this threat model.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

133. Data Flow Request Is Potentially Interrupted [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	Out of scope of this threat model.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

134. Elevation Using Impersonation [State: Needs Investigation] [Priority: High]

Category:	Elevation Of Privilege
Description:	OpenBao Server (Hosted on Device) may be able to impersonate the context of Client in order to gain additional privilege.
Justification:	<no mitigation provided>
Possible Mitigation:	Role based access would mitigate this. Additional mitigation when running EdgeX in rootless Docker: impersonating an EdgeX service from another local process requires access to the host system and the Docker network. Under rootless Docker the daemon, its socket (/run/user/<uid>/docker.sock) and the bridge network are owned by an unprivileged user, and a compromised container cannot escalate to host root to attach to that network or manipulate other containers. The attacker must first compromise the specific unprivileged user that owns the rootless daemon, raising the bar significantly compared with rootful deployments. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

135. OpenBao Server (Hosted on Device) May be Subject to Elevation of Privilege Using Remote Code Execution [State: Needs Investigation] [Priority: High]

Category:	Elevation Of Privilege
Description:	Client may be able to remotely execute code for OpenBao Server (Hosted on Device) .
Justification:	<no mitigation provided>
Possible Mitigation:	Overflows in data, or remote code execution needs investigation.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

136. Elevation by Changing the Execution Flow in OpenBao Server (Hosted on Device) [State: Not Started] [Priority: High]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into OpenBao Server (Hosted on Device) in order to change the flow of program execution within OpenBao Server (Hosted on Device) to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Role based access would mitigate this. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

Interaction: Response

137. OpenBao Server (Hosted on Device) Process Memory Tampered [State: Not Started] [Priority: High]

Category:	User-defined
Description:	If OpenBao Server (Hosted on Device) is given access to memory, such as shared memory or pointers, or is given the ability to control what Client executes (for example, passing back a function pointer.), then OpenBao Server (Hosted on Device) can tamper with Client. Consider if the function could work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it.
Justification:	<no mitigation provided>
Possible Mitigation:	Mitigation when running EdgeX in rootless Docker: user-namespace and PID-namespace isolation means a compromised service cannot ptrace, signal or read the memory of processes in sibling containers. UID 0 inside container A maps to a different unprivileged host UID than UID 0 inside container B, so cross-service in-memory tampering via /proc, ptrace or shared kernel facilities is blocked unless the attacker first compromises the unprivileged host user that owns the rootless daemon. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

138. Replay Attacks [State: Not Started] [Priority: High]

Category:	Spoofing
Description:	Packets or messages without sequence numbers or timestamps can be captured and replayed in a wide variety of ways. Implement or utilize an existing communication protocol that supports anti-replay techniques (investigate sequence numbers before timers) and strong integrity.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

139. Collision Attacks [State: Not Applicable] [Priority: High]

Category:	Tampering
Description:	Attackers who can send a series of packets or messages may be able to overlap data. For example, packet 1 may be 100 bytes starting at offset 0. Packet 2 may be 100 bytes starting at offset 25. Packet 2 will overwrite 75 bytes of packet 1. Ensure you reassemble data before filtering it, and ensure you explicitly handle these sorts of cases.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

140. Potential Data Repudiation by Client [State: Not Applicable] [Priority: High]

Category:	Repudiation
Description:	Client claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

141. Weak Authentication Scheme [State: Needs Investigation] [Priority: High]

Category:	Information Disclosure
Description:	Custom authentication schemes are susceptible to common weaknesses such as weak credential change management, credential equivalence, easily guessable credentials, null credentials, downgrade authentication or a weak credential change management system. Consider the impact and potential mitigations for your custom authentication scheme.
Justification:	<no mitigation provided>
Possible Mitigation:	Role based access need to be present.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

142. Potential Process Crash or Stop for Client [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	Client crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	if client crashes, the problem would be on the client side.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

143. Data Flow Response Is Potentially Interrupted [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

144. Elevation Using Impersonation [State: Not Applicable] [Priority: High]

Category:	Elevation Of Privilege
Description:	Client may be able to impersonate the context of OpenBao Server (Hosted on Device) in order to gain additional privilege.
Justification:	<no mitigation provided>
Possible Mitigation:	Mitigation when running EdgeX in rootless Docker: impersonating an EdgeX service from another local process requires access to the host system and the Docker network. Under rootless Docker the daemon, its socket (/run/user/<uid>/docker.sock) and the bridge network are owned by an unprivileged user, and a compromised container cannot escalate to host root to attach to that network or manipulate other containers. The attacker must first compromise the specific unprivileged user that owns the rootless daemon, raising the bar significantly compared with rootful deployments. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

145. Client May be Subject to Elevation of Privilege Using Remote Code Execution [State: Not Applicable] [Priority: High]

Category:	Elevation Of Privilege
Description:	OpenBao Server (Hosted on Device) may be able to remotely execute code for Client.
Justification:	<no mitigation provided>
Possible Mitigation:	Mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

146. Elevation by Changing the Execution Flow in Client [State: Needs Investigation] [Priority: High]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into Client in order to change the flow of program execution within Client to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

147. Cross Site Request Forgery [State: Needs Investigation] [Priority: High]

Category:	Elevation Of Privilege
Description:	Cross-site request forgery (CSRF or XSRF) is a type of attack in which an attacker forces a user's browser to make a forged request to a vulnerable site by exploiting an existing trust relationship between the browser and the vulnerable web site. In a simple scenario, a user is logged in to web site A using a cookie as a credential. The other browses to web site B. Web site B returns a page with a hidden form that posts to web site A. Since the browser will carry the user's cookie to web site A, web site B now can take any action on web site A, for example, adding an admin to an account. The attack can be used to exploit any requests that the browser automatically authenticates, e.g. by session cookie, integrated authentication, IP whitelisting. The attack can be carried out in many ways such as by luring the victim to a site under control of the attacker, getting the user to click a link in a phishing email, or hacking a reputable web site that the victim will visit. The issue can only be resolved on the server side by requiring that all authenticated state-changing requests include an additional piece of secret payload (canary or CSRF token) which is known only to the legitimate web site and the browser and which is protected in transit through SSL/TLS. See the Forgery Protection property on the flow stencil for a list of mitigations.
Justification:	<no mitigation provided>
Possible Mitigation:
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

Interaction: Response

148. Spoofing of Source Data Store Storage [State: Not Applicable] [Priority: High]

Category:	Spoofing
Description:	TPM may be spoofed by an attacker and this may lead to incorrect data delivered to OpenBao Server (Hosted on Device) . Consider using a standard authentication mechanism to identify the source data store.
Justification:	<no mitigation provided>
Possible Mitigation:	TPM cannot be spoofed.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

149. Potential Data Repudiation by OpenBao Server (Hosted on Device) [State: Not Applicable] [Priority: High]

Category:	Repudiation
Description:	OpenBao Server (Hosted on Device) claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.
Justification:	<no mitigation provided>
Possible Mitigation:	Since OpenBao mantians record of all the events, its not easy to Deny users action. Each key would have its record of TTL, no of times used and date its created.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

150. Weak Access Control for a Resource [State: Needs Investigation] [Priority: High]

Category:	Information Disclosure
Description:	Improper data protection of TPM can allow an attacker to read information not intended for disclosure. Review authorization settings.
Justification:	<no mitigation provided>
Possible Mitigation:	Need to investigate more on Role based access in OpenBao
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

151. Potential Process Crash or Stop for OpenBao Server (Hosted on Device) [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	OpenBao Server (Hosted on Device) crashes, halts, stops or runs slowly; in all cases violating an availability metric.
Justification:	<no mitigation provided>
Possible Mitigation:	Process crash could lead openbao to DOS. Need to investigate.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

152. Data Flow Response Is Potentially Interrupted [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	An external agent interrupts data flowing across a trust boundary in either direction.
Justification:	<no mitigation provided>
Possible Mitigation:	It is assumed that the TPM is always up and available.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

153. Data Store Inaccessible [State: Not Applicable] [Priority: High]

Category:	Denial Of Service
Description:	An external agent prevents access to a data store on the other side of the trust boundary.
Justification:	<no mitigation provided>
Possible Mitigation:	It is assumed that the TPM is always up and available.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

154. OpenBao Server (Hosted on Device) May be Subject to Elevation of Privilege Using Remote Code Execution [State: Not Applicable] [Priority: High]

Category:	Elevation Of Privilege
Description:	TPM may be able to remotely execute code for OpenBao Server (Hosted on Device) .
Justification:	<no mitigation provided>
Possible Mitigation:	Only specific users will have commands that talk to the TPM. OpenBao would have full access.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

155. Elevation by Changing the Execution Flow in OpenBao Server (Hosted on Device) [State: Mitigation Implemented] [Priority: High]

Category:	Elevation Of Privilege
Description:	An attacker may pass data into OpenBao Server (Hosted on Device) in order to change the flow of program execution within OpenBao Server (Hosted on Device) to the attacker's choosing.
Justification:	<no mitigation provided>
Possible Mitigation:	Role based access should be present where OpenBao commands can be run with specific privilages. Additional mitigation when running EdgeX in rootless Docker: even if remote code execution succeeds inside a service container, the attacker only obtains the privileges of the unprivileged host user that owns the rootless-Docker daemon, via user-namespace UID remapping. UID 0 inside the container is not UID 0 on the host, so post-exploit actions that normally rely on host root - loading kernel modules, attaching to other containers' processes, mounting host paths, opening raw sockets, or modifying system services - are blocked even after a successful container escape. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed and signature verification is enforced at pull or admission time (e.g., Sigstore/cosign with a policy controller, or a content-trust-enabled daemon): the supply-chain path for introducing a backdoored or maliciously rebuilt image is closed, provided the signing key is protected by an HSM or KMS. Signing does not prevent exploitation of a flaw inside a legitimately signed image, so it must be combined with SBOM and SLSA provenance attestations, vulnerability scanning of the signed artifact, and timely patching. See https://www.sigstore.dev/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

Interaction: Write

156. Storage is not protected. Its a part of filesystem. [State: Not Started] [Priority: High]

Category:	Information Disclosure
Description:	Storage may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Storage. Consider using a standard authentication mechanism to identify the destination data store.
Justification:	<no mitigation provided>
Possible Mitigation:	Storage should be Encrypted.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

157. Storage is not protected. Its a part of filesystem [State: Not Started] [Priority: High]

Category:	Information Disclosure
Description:	Can you access Storage and bypass the permissions for the object? For example by editing the files directly with a hex editor, or reaching it via filesharing? Ensure that your program is the only one that can access the data, and that all other subjects have to use your interface.
Justification:	<no mitigation provided>
Possible Mitigation:	Storage should be Encrypted. Additional mitigation when running EdgeX in rootless Docker: container layers and bind-mounted volumes (including OpenBao's storage backend, log directories and key material) are owned by the unprivileged host user that runs the rootless daemon and live under that user's $XDG_DATA_HOME/docker tree, not under root-owned host paths. Other host users and escaped containers cannot bypass in-application access controls by reading or writing those files directly. This raises the cost of any filesystem-level disclosure or tampering attack but does not remove the need for at-rest encryption of the data the rootless user does control. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

158. Weak Credential Storage [State: Not Applicable] [Priority: High]

Category:	Information Disclosure
Description:	Credentials held at the server are often disclosed or tampered with and credentials stored on the client are often stolen. For server side, consider storing a salted hash of the credentials instead of storing the credentials themselves. If this is not possible due to business requirements, be sure to encrypt the credentials before storage, using an SDL-approved mechanism. For client side, if storing credentials is required, encrypt them and protect the data store in which they're stored
Justification:	<no mitigation provided>
Possible Mitigation:	With the Unseal and seal mechanism, The credentials are stored in encrypted form. Additional mitigation when running EdgeX in rootless Docker: credential material persisted in container volumes (including OpenBao seal keys and SecretStore-issued tokens) is owned by an unprivileged host user, not root. A container escape only yields that unprivileged user's permissions, so attempts to exfiltrate credentials by reading host-level paths from a compromised neighbour container are blocked. Encryption (seal/unseal, salted hashes) remains the primary control; rootless Docker reduces the blast radius of a host-side compromise. See https://docs.edgexfoundry.org/4.1/security/Rootless-Docker/. Additional mitigation when EdgeX container images are signed (e.g., Sigstore/cosign, Docker Content Trust or Notary v2) and signature verification is enforced at pull or admission time: the supply-chain path for introducing a tampered or imposter image is closed, provided the signing key is rooted in an HSM or KMS and verification is policy-enforced by the runtime. Signing does not prevent exploitation of a flaw inside a legitimately signed image; pair it with SBOM and SLSA provenance attestations and timely patching. See https://www.sigstore.dev/ and https://docs.docker.com/engine/security/trust/.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

159. Potential Excessive Resource Consumption for OpenBao Server (Hosted on Device) or Storage [State: Needs Investigation] [Priority: High]

Category:	Denial Of Service
Description:	Does OpenBao Server (Hosted on Device) or Storage take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout.
Justification:	<no mitigation provided>
Possible Mitigation:	Extensive resource usage could potentailly lead to DOS. Need to investigate.
Mitigator:	Adopter
Mitigation Status:	Mitigation needed

Not Started	8
Not Applicable	36
Needs Investigation	25
Mitigation Implemented	90
Total	159
Total Migrated	0