.. include:: vars.rst

.. _section-sec-dds-system-threats: 

DDS System Threats
------------------

One of the key values of |CONNEXT| — and the :link:`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 |DW| publishing samples to a given |TOPIC| *T*, in a certain
domain. A remote monitor in the control room, Bob, has a |DR|
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 |DR|, 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 [#]_ 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 |DRs| 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 |DR|, then
publishing modified data samples with a |DW|. 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_ROUTINGSERVICE|, joins a domain being attacked by malicious |DPs|.

The diagram in :numref:`FigureThreats` 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.

.. figure:: /../shared_content/static/threats.png
    :scale: 50%
    :name: FigureThreats
    :align: center

    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 :ref:`section-sec-securing-domain`, we'll see how the |SP| solve
these problems.

.. [#] There are some measures that you can apply in order to not blindly
   trust everyone that joins the domain, such as the
   :xmltag:`accept_unknown_peers` setting in the DISCOVERY QosPolicy (see
   :link_um:`DISCOVERY QosPolicy (DDS Extension) in the Core Libraries User's
   Manual) <DISCOVERY_Qos.htm#Table_DiscoveryQoS>`. However, these methods are
   not enough when your system is under a security attack.