2. DDS System Threats¶
One of the key values of Connext — and the OMG DDS standard <http://www.omg.org/spec/DDS/> — is data-centricity. Applications in the same domain can exchange data freely by just publishing and subscribing to the Topics they are interested in.
Suppose that in a hospital we have a patient monitoring device, Alice, that has a DataWriter publishing samples to a given Topic T, in a certain domain. A remote monitor in the control room, Bob, has a DataReader interested in Topic T. After Alice and Bob discover each other, they will start exchanging data samples for Topic T.
Both Alice and Bob are legitimate applications, so they should be able to communicate as they were designed to. In this case, nothing should prevent them from communicating. However, consider that a person from outside the hospital’s organization has been able to connect to the hospital’s network. This person has a device, Eve, with a DataReader, that isn’t supposed to subscribe to Topic T. In a non-secure scenario, Eve and Alice will discover each other, then Alice will start sending data samples to Eve. Note that the original version of the DDS and RTPS standards do not define any mechanism to verify whether Eve is authorized 1 to subscribe to Topic T. Although eavesdropping is not always a problem on every Topic or every system, the medical data in Topic T is very sensitive and should be protected against eavesdropping. In other words, we should have a mechanism to guarantee that only authorized DataReaders are able to subscribe to Topic T and to make sense of data published to it.
A more severe problem comes when a malicious participant, Mallory, breaks into the network and joins the domain to publish random data to Topic T. Even worse, in a non-secure scenario she could easily perform tampering and/or replay attacks by subscribing to the Topic with a DataReader, then publishing modified data samples with a DataWriter. This could have severe consequences, such as nurses and doctors in the control room receiving false alarms regarding the vital signs of random patients, causing serious problems to the hospital.
Finally, these attacks could cross DDS Domains if an infrastructure service, such as RTI Routing Service, joins a domain being attacked by malicious DomainParticipants.
The diagram in Figure 2.1 depicts these attacks in a system with the following participants:
Alice: a legitimate application publishing to Topic T, allowed to publish these samples.
Bob: a legitimate application subscribing to Topic T, allowed to access that information.
Eve: an eavesdropper trying to subscribe to Topic T without authorization - to perform unauthorized subscription (1).
Trudy: an intruder trying to publish into the databus without authorization - to perform unauthorized publication (2).
Mallory: a malicious insider (for instance, authorized to subscribe to data but not to publish) trying to perform tampering and replay (3).
Trent: an Infrastructure Service that legitimately subscribes to and publishes data.
![_images/threats.png](_images/threats.png)
Figure 2.1 Threats affecting the OMG DDS standard in a non-secure scenario.¶
Given its data-centricity, traditional security solutions — mostly focused on securing a pipeline for byte exchange — do not fit OMG DDS well. Moreover, using a pipeline requires one-to-one sessions between peers, which doesn’t allow multicast, so scalability is limited. In Securing a DDS Domain, we’ll see how the Security Plugins solve these problems.
- 1
There are some measures that you can apply in order to not blindly trust everyone that joins the domain, such as the
accept_unknown_peers
setting in the DISCOVERY QosPolicy (see DISCOVERY QosPolicy (DDS Extension) in the Core Libraries User’s Manual). However, these methods are not enough when your system is under a security attack.