.. include:: ../vars.rst

.. |STRIDE_S| replace:: :habbr:`#aed6f1:S:Spoofing`
.. |STRIDE_T| replace:: :habbr:`#E9967A:T:Tampering`
.. |STRIDE_R| replace:: :habbr:`#fad7a0:R:Repudiation`
.. |STRIDE_I| replace:: :habbr:`#d5f5e3:I:Information Disclosure`
.. |STRIDE_D| replace:: :habbr:`#d5dbdb:D:Denial of Service`
.. |STRIDE_E| replace:: :habbr:`#FF99FF:E:Elevation of Privilege`

.. |DOMAIN_TB| replace:: *Domain Trust Boundary*
.. |DOMAIN_OUTSIDER| replace:: *Domain Outsider*
.. |DOMAIN_OUTSIDER_PROTECTION| replace:: *Domain Outsider Protection*
.. |DOMAIN_INSIDER| replace:: *Domain Insider*
.. |DOMAIN_INSIDER_PROTECTION| replace:: *Domain Insider Protection*

.. |TOPIC_TB| replace:: *Topic Trust Boundary*
.. |TOPIC_OUTSIDER| replace:: *Topic Outsider*
.. |TOPIC_OUTSIDER_PROTECTION| replace:: *Topic Outsider Protection*
.. |TOPIC_INSIDER| replace:: *Topic Insider*
.. |TOPIC_INSIDER_PROTECTION| replace:: *Topic Insider Protection*

.. |META_TRAFFIC| replace:: *Meta Traffic*
.. |USER_TRAFFIC| replace:: *User Traffic*



.. _chapter-threat-modeling:

*********************************************************************
Using STRIDE Threat Modeling to Analyze Security Risks in DDS Systems
*********************************************************************

Introduction to Threat Modeling
===============================

A threat model is an abstraction that helps you evaluate risks. Threat
modeling is a structured process for identifying potential security threats and
vulnerabilities, quantifying the risk of each, and prioritizing mitigation
techniques. When developing a software product, having a defined threat model
is key to a focused defense.

A critical part of threat modeling is to identify trust boundaries. A trust
boundary is a logical boundary where program data or execution changes its
level of trust. Knowing the trust boundaries of a system allows you to better
focus the threat analysis in the areas of concern.


Simplified DDS Security Threat Model
====================================

We could summarize the |SEC_SPEC| threat model as "the network
is the adversary". The goal of the |SEC_SPEC|
is to protect the data in motion exchanged between
DDS applications through an untrusted network.

The DDS Security threat model is depicted in the following figure, where the
area of interest is the untrusted network:

.. figure:: ../static/dds-security-threat-model.png
  :scale: 100%
  :name: Simplified DDS Security Threat Model
  :align: center

  Simplified DDS Security Threat Model

For an overview of the potential DDS threats within the untrusted network,
please refer to
:ref:`p1_welcome/overview:Description of DDS System Threats`.
For an in-depth review of the DDS Security threat model, please refer to
:ref:`p3_advanced/threat_modeling:Detailed DDS Security Threat Model`.

Introduction to STRIDE
======================

|STRIDE_S|\ |STRIDE_T|\ |STRIDE_R|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E| is a
`threat modeling framework <https://en.wikipedia.org/wiki/STRIDE_model>`__
used to identify and categorize potential
security threats in a system. It helps security teams analyze potential
vulnerabilities and risks by breaking them down into six categories:

- Spoofing (|STRIDE_S|): Unauthorized access by impersonating another user or
  system (e.g., fake authentication or identity theft).
- Tampering (|STRIDE_T|): Malicious modification of data or code, either in
  transit or at rest (e.g., altering database records or files).
- Repudiation (|STRIDE_R|): The ability for a user to deny their actions
  without any evidence, often due to a lack of proper logging or auditing
  (e.g., denying responsibility for an action like a transaction).
- Information Disclosure (|STRIDE_I|): Unauthorized access to confidential or
  sensitive information (e.g., leaking sensitive data due to insufficient
  encryption or access controls).
- Denial of Service (|STRIDE_D|): Disrupting or degrading the availability of
  a system or service, making it unavailable to legitimate users (e.g.,
  flooding a server with traffic to overwhelm it).
- Elevation of Privilege (|STRIDE_E|): Gaining unauthorized access to higher
  privileges or permissions than a user is supposed to have (e.g., exploiting a
  vulnerability to become an administrator).

This chapter explains how to use
|STRIDE_S|\ |STRIDE_T|\ |STRIDE_R|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E|
to analyze the different threats that the
:ref:`p3_advanced/threat_modeling:Detailed DDS Security Threat Model` considers
and see how :ref:`p3_advanced/threat_modeling:DDS Security Threat Protection`
helps protect your system against those threats.


Detailed DDS Security Threat Model
==================================

DDS Security Trust Boundaries
-----------------------------

In the model we introduced earlier
(:ref:`p3_advanced/threat_modeling:Simplified DDS Security Threat Model`) we
established only one trust boundary (the one surrounding the untrusted network)
as the focus of the DDS Security threat model. In reality,
we can identify two additional kinds of trust boundaries within the unstrusted
network trust boundary, which are derived from the data-centric approach of
DDS:

- |DOMAIN_TB|: A logical boundary between what is inside a |DOMAIN|
  (data, applications running authorized |DPs|) and what is
  outside the |DOMAIN|.
- |TOPIC_TB|: A logical boundary between what is inside a |TOPIC| (data,
  applications running authorized |DWs| and/or |DRs|) and what is
  outside the |TOPIC|.

.. figure:: ../static/dds-security-threat-model-detailed.png
  :scale: 80%
  :name: Detailed DDS Security Threat Model
  :align: center

  Detailed DDS Security Threat Model [#FOOTNOTE_DP_VS_DWDR]_

Using the above boundaries, we can differentiate four unique attacker roles
associated with a DDS system:

Attacker roles derived from the |DOMAIN_TB|:
  - |DOMAIN_OUTSIDER|: For a given |DOMAIN|, a |DOMAIN_OUTSIDER| refers to any
    actors with access to the physical network where the |DOMAIN| runs, but
    which are not authorized to join the |DOMAIN|. This includes (but is
    not limited to) any applications authorized to run on different |DOMAINs|.
    As a generalization, a |DOMAIN_OUTSIDER| is any actor that does not hold
    valid |DOMAIN| credentials (i.e., the right |PSK| secret passphrase, and/or
    certificates & private keys associated with a |PermissionsDoc|'s Grant).
  - |DOMAIN_INSIDER|: Any actors with authorized access to a given |DOMAIN|.
    An example |DOMAIN_INSIDER| is a malicious attacker that has stolen
    valid credentials for a |DOMAIN| (i.e., certificates and private keys) and
    then creates a |DP| using the stolen credentials. Another example is
    a malicious attacker that has compromised a device running a |DP| with
    valid certificates, and therefore can operate with the same privileges as
    the compromised device's |DP|.

Attacker roles derived from the |TOPIC_TB|:
  - |TOPIC_OUTSIDER|: For a given |TOPIC|, a |TOPIC_OUTSIDER| refers to any
    actors with authorized access to the |DOMAIN| where the |TOPIC| belongs, but
    which are not authorized to interact with the |TOPIC|.
    An example of a |TOPIC_OUTSIDER| is a malicious attacker that has
    compromised a device running a |DP| with valid credentials and permissions
    to join a |DOMAIN| but without permissions to publish or subscribe to the
    attack target |TOPIC|.
  - |TOPIC_INSIDER|: Any actors with authorized access to a given |TOPIC|.
    An example of |TOPIC_INSIDER| is a malicious attacker that has stolen the
    credentials for a |DP| with permissions to publish in a |TOPIC| and then
    creates a |DP| using the stolen credentials.


DDS Traffic Categorization
--------------------------

Before moving into how DDS Security protects against different threats, it is
essential to understand how the DDS databus operates. In a |DOMAIN|, there
are two kinds of data traffic exchanged to support the databus operation:

- |META_TRAFFIC|: Data exchanged to support the operation of the |DOMAIN|. It
  includes the traffic associated with builtin |TOPICs| supporting key
  functionality such as discovery, authentication, and liveliness. The
  |META_TRAFFIC| data contains information such as GUIDs, |TOPIC| names, type
  names, and locators.
- |USER_TRAFFIC|: Data exchanged between user application |DWs| and
  |DRs|. It includes traffic associated with user application |TOPICs|.
  The contents of the |USER_TRAFFIC| data depend on the definition of the user
  |DWs| and |DRs|.

.. warning::

  Confidentiality consideration: While the databus exchanges user
  data exclusively through |USER_TRAFFIC|, |META_TRAFFIC| contains
  |USER_TRAFFIC|-related information that could be sensitive depending on the
  system security policy (for example, the user |TOPICs| names could be
  sensitive according to policy).

.. warning::

  Availability consideration: Since |META_TRAFFIC| is used to
  support the operation of the |DOMAIN|, a proper risk evaluation for a given
  user |TOPIC| must consider |META_TRAFFIC| threats. For example, if a successful
  attack tampers with the discovery information associated with a user |TOPIC|,
  this could result in a successful |STRIDE_D| attack for that |TOPIC|.


DDS Security Threat Protection
------------------------------

DDS Security provides the following threat protection levels (derived from the
trust boundaries and attacker roles defined in
:ref:`p3_advanced/threat_modeling:DDS Security Trust Boundaries`, and ordered
from a lower level of trust to higher level of trust):

- |DOMAIN_OUTSIDER_PROTECTION|: Also known as
  :ref:`p1_welcome/overview:Domain-Level Protection`,
  mitigates attacks initiated by actors not
  authorized to join the |DOMAIN|. For example, actors without the right
  |PSK| secret passphrase to join the |DOMAIN|.
- |DOMAIN_INSIDER_PROTECTION|: A form of
  :ref:`p1_welcome/overview:Granular Protection Inside Domains`,
  mitigates attacks initiated by actors
  authorized to join the |DOMAIN|. For example, a malicious actor that has
  stolen the right credentials to join a |DOMAIN| and then creates a |DP|
  using those credentials.
- |TOPIC_OUTSIDER_PROTECTION|: A form of
  :ref:`p1_welcome/overview:Granular Protection Inside Domains`,
  mitigate attacks initiated by actors not
  authorized to publish and/or subscribe to/from a given |TOPIC|.
  For example, a malicious actor that has
  stolen the credentials for an Identity authorized to join a |DOMAIN|, but
  not authorized to publish or subscribe to the attack target |TOPIC|.
- |TOPIC_INSIDER_PROTECTION|: A form of
  :ref:`p1_welcome/overview:Granular Protection Inside Domains`,
  mitigate attacks initiated by actors
  authorized to publish and/or subscribe to/from a given |TOPIC|.
  For example, a malicious actor that has
  stolen the credentials for an Identity authorized to join a |DOMAIN| and
  publish to the attack target |TOPIC|.

In the following sections we will cover these protection levels in depth,
detailing what |RTI_SP_PRODUCT| features support these protection levels.
In order to be effective, certain mechanisms associated with a given level of
protection may require users to also enable certain lower-trust protection
mechanisms (for example, |STRIDE_D| |TOPIC_OUTSIDER_PROTECTION|
requires enabling |DOMAIN_INSIDER_PROTECTION|).

.. note::

  While other combinations are possible to achieve similar levels of
  protection, in this section we prioritize the combinations that ensure the
  right level of protection while keeping the configuration as simple as
  possible.


Domain Outsider Protection
--------------------------

.. figure:: ../static/dds-security-threat-model-domain-outsider.png
  :scale: 80%
  :name: Domain Outsider Attacker
  :align: center

  Domain Outsider Attacker [#FOOTNOTE_DP_VS_DWDR]_

This level of protection mitigates attacks initiated by actors not authorized
to join the |DOMAIN|. This protection is effective against attacks targeting
|META_TRAFFIC| and/or |USER_TRAFFIC|.

Examples of preventable |DOMAIN_OUTSIDER| attacks are:

- |STRIDE_S|\ |STRIDE_T|\ |STRIDE_E| :

  - An attacker publishes user |TOPIC| data while impersonating a legitimate
    |DP|.
  - An attacker publishes malicious discovery information while impersonating a
    legitimate |DP|, triggering user |TOPIC| data to be corrupted.
  - An attacker publishes malicious liveliness information while impersonating
    a legitimate |DP|, preventing legitimate |DPs| from
    detecting the disconnection of the impersonated |DP|.

- |STRIDE_I|:

  - An attacker reads DDS application's system meta information such as
    username.
  - An attacker reads user |TOPIC| data.

- |STRIDE_D|:

  - An attacker exploits RTPS protocol operation to force legitimate DDS
    applications to flood the network with discovery messages.
  - An attacker exploits RTPS sequence numbers to force legitimate DDS
    applications to drop any messages for a |TOPIC|.
  - An attacker exploits a day-zero vulnerability in |CONNEXT| to crash a DDS
    application by injecting malicious RTPS messages to the network.

To enable |DOMAIN_OUTSIDER_PROTECTION|, |RTI_SP_PRODUCT| provides the
following options:

- |LIGHT_SP_BUILTIN|:

  - |META_TRAFFIC| and |USER_TRAFFIC| threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires:

      - Setting the :property:`dds.sec.access.rtps_psk_protection_kind`
        property to a value other than :xmlval:`NONE` (default).

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E| protection
      requires:

      - Setting the :property:`dds.sec.access.rtps_psk_protection_kind`
        property to :xmlval:`ENCRYPT`.

- |SP_BUILTIN|:

  - |META_TRAFFIC| and |USER_TRAFFIC| threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires:

      - Setting the :xmltag:`rtps_psk_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:rtps_psk_protection_kind (domain_rule)`)
        in the |GovernanceDoc| to a value other than :xmlval:`NONE` (default).

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E| protection
      requires:

      - Setting the :xmltag:`rtps_psk_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:rtps_psk_protection_kind (domain_rule)`)
        in the |GovernanceDoc| to :xmlval:`ENCRYPT`.

  - |USER_TRAFFIC| only threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_E| protection requires:

      - Setting the :xmltag:`rtps_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:rtps_protection_kind (domain_rule)`)
        in the |GovernanceDoc| to a value other than :xmlval:`NONE`.

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_E| protection requires:

      - Setting the :xmltag:`rtps_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:rtps_protection_kind (domain_rule)`)
        in the |GovernanceDoc| to :xmlval:`ENCRYPT` or
        :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`.


Domain Insider Protection
-------------------------

.. figure:: ../static/dds-security-threat-model-domain-insider.png
  :scale: 80%
  :name: Domain Insider Attacker
  :align: center

  Domain Insider Attacker [#FOOTNOTE_DP_VS_DWDR]_

This level of protection mitigates attacks initiated by actors authorized to
join the |DOMAIN|. This protection is effective against attacks targeting
|META_TRAFFIC| and/or |USER_TRAFFIC|.

Examples of preventable |DOMAIN_INSIDER| attacks are:

- |STRIDE_S|\ |STRIDE_T|\ |STRIDE_E|:

  - An attacker publishes malicious discovery information while
    impersonating a legitimate |DP|, triggering user |TOPIC| data to be
    corrupted.
  - An attacker publishes malicious liveliness information while
    impersonating a legitimate |DP|, preventing legitimate
    |DPs| from detecting the disconnection of the impersonated
    |DP|.

- |STRIDE_D|:

  - An attacker exploits RTPS sequence numbers to force legitimate DDS
    applications to stop receiving discovery or liveliness information.

To enable |DOMAIN_INSIDER| protection, |RTI_SP_PRODUCT| provides the
following options:

- |SP_BUILTIN|:

  - |META_TRAFFIC| and |USER_TRAFFIC| threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires all of
      the following:

      - Setting :xmltag:`enable_join_access_control` to :xmlval:`TRUE`
        (see :ref:`p2_core/access_control:enable_join_access_control (within a domain_rule)`).
      - Setting the :xmltag:`rtps_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:rtps_protection_kind (domain_rule)`)
        in the |GovernanceDoc| to :xmlval:`SIGN_WITH_ORIGIN_AUTHENTICATION` or
        :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`.

  - |META_TRAFFIC| only threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires all
      of the following:

      - Setting :xmltag:`enable_join_access_control` to :xmlval:`TRUE`
        (see :ref:`p2_core/access_control:enable_join_access_control (within a domain_rule)`).
      - Setting the :xmltag:`discovery_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:discovery_protection_kind (domain_rule)`)
        and the :xmltag:`liveliness_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:liveliness_protection_kind (domain_rule)`)
        to :xmlval:`SIGN_WITH_ORIGIN_AUTHENTICATION` or
        :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`.

.. warning::

  |DOMAIN_INSIDER_PROTECTION| is only effective if every |DP| in the |DOMAIN|
  has unique credentials (i.e., Identity Certificate and the associated
  private keys cannot be shared across multiple |DPs|).
  |DPs| sharing credentials will share the same Identity and therefore
  no |DOMAIN_INSIDER_PROTECTION| is possible among them.

.. note::

  If your |SP_BUILTIN| system is configured with one unique set of credentials
  associated with all the |DPs| in the same |DOMAIN| and this is acceptable
  by your security policy, you should consider switching to using
  |LIGHT_SP_BUILTIN|.
  |LIGHT_SP_BUILTIN| is a lightweight, easy to configure and
  deploy solution with an equivalent protection level
  (|DOMAIN_OUTSIDER_PROTECTION|) to using |SP_BUILTIN|
  with the same credentials for all of the |DPs| in the system.


Topic Outsider Protection
-------------------------

.. figure:: ../static/dds-security-threat-model-topic-outsider.png
  :scale: 80%
  :name: Topic Outsider Attacker
  :align: center

  Topic Outsider Attacker [#FOOTNOTE_DP_VS_DWDR]_

This level of protection mitigates attacks initiated by actors not authorized
to publish and/or subscribe to/from a given |TOPIC|. This protection is effective
against attacks targeting |USER_TRAFFIC|.

Examples of preventable |TOPIC_OUTSIDER| attacks are:

- |STRIDE_S|\ |STRIDE_T|\ |STRIDE_E|:

  - An attacker publishes user |TOPIC| data while impersonating a legitimate
    |DP|.

- |STRIDE_I|:

  - An attacker reads user |TOPIC| data.

- |STRIDE_D|:

  - An attacker exploits RTPS sequence numbers to force legitimate
    DDS applications to drop any messages for a user |TOPIC|.

Additionally, examples of preventable |META_TRAFFIC| related |TOPIC_OUTSIDER|
attacks are:

- |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|:

  - An attacker publishes malicious discovery information while impersonating
    a legitimate |DP|, triggering user |TOPIC| data to be corrupted.
  - An attacker exploits RTPS sequence numbers to force legitimate DDS
    applications to stop receiving discovery or liveliness information for
    a user |TOPIC|.


To enable |TOPIC_OUTSIDER_PROTECTION|, |RTI_SP_PRODUCT| provides the
following options:

- |SP_BUILTIN|:

  - |USER_TRAFFIC| only threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires all
      of the following:

      - Setting :xmltag:`enable_read_access_control`
        (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
        and :xmltag:`enable_write_access_control`
        (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
        to :xmlval:`TRUE`.
      - Setting the :xmltag:`metadata_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
        in the |GovernanceDoc| to a value other than :xmlval:`NONE`.

    - |STRIDE_I| protection requires all of the following:

      - Setting :xmltag:`enable_read_access_control`
        (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
        and :xmltag:`enable_write_access_control`
        (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
        to :xmlval:`TRUE`.
      - Setting the :xmltag:`metadata_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
        to :xmlval:`ENCRYPT` or :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`.

        - Alternatively (only needed if using Persistence Service),
          granted by setting the :xmltag:`data_protection_kind` |GovRule|
          (see :ref:`p2_core/cryptography:data_protection_kind (topic_rule)`)
          to :xmlval:`ENCRYPT`.

  - |META_TRAFFIC| related threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires all
      of the following:

      - Enabling |DOMAIN_INSIDER_PROTECTION| (at least, for the
        |META_TRAFFIC|).
      - Setting :xmltag:`enable_read_access_control`
        (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
        and :xmltag:`enable_write_access_control`
        (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
        to :xmlval:`TRUE`.
      - Setting :xmltag:`enable_discovery_protection`
        (see :ref:`p2_core/cryptography:enable_discovery_protection (topic_rule)`)
        and :xmltag:`enable_liveliness_protection` to :xmlval:`TRUE`
        (see :ref:`p2_core/cryptography:enable_liveliness_protection (topic_rule)`).
      - Setting the :xmltag:`metadata_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
        to a value other than :xmlval:`NONE`.

.. warning::

  |TOPIC_OUTSIDER_PROTECTION| is only effective if every |DP| in the |DOMAIN|
  has unique credentials (i.e., Identity Certificate and the associated
  private keys cannot be shared across multiple |DPs|).
  |DPs| sharing credentials will share the same Identity and Permissions Grants
  and therefore no |TOPIC_OUTSIDER_PROTECTION| is possible among them.


Topic Insider Protection
------------------------

.. figure:: ../static/dds-security-threat-model-topic-insider.png
  :scale: 80%
  :name: Topic Insider Attacker
  :align: center

  Topic Insider Attacker [#FOOTNOTE_DP_VS_DWDR]_

This level of protection mitigates attacks initiated by actors authorized
to publish and/or subscribe to/from a given |TOPIC|. This protection is
effective against attacks targeting |USER_TRAFFIC|.

Examples of preventable |TOPIC_INSIDER| attacks are:

- |STRIDE_S|\ |STRIDE_T|\ |STRIDE_E|:

  - An attacker without write permission for a |TOPIC| publishes user |TOPIC|
    data to the |TOPIC|.
  - An attacker with write permissions for a |TOPIC| publishes user |TOPIC|
    data while impersonating a legitimate |DP|.

- |STRIDE_I|:

  - An attacker reads from a |TOPIC| while only having permissions for writing
    (not reading).

- |STRIDE_D|:

  - An attacker exploits RTPS sequence numbers to force legitimate DDS
    applications to drop messages from a different legitimate |DP|.

Additionally, examples of preventable |META_TRAFFIC| related |TOPIC_INSIDER|
attacks are:

- |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|:

  - An attacker publishes malicious discovery information while impersonating a
    legitimate |DP|, triggering user |TOPIC| data to be corrupted.
  - An attacker exploits RTPS sequence numbers to force legitimate DDS
    applications to stop receiving discovery or liveliness information for a
    user |TOPIC|.

To enable |TOPIC_INSIDER_PROTECTION|, |RTI_SP_PRODUCT| provides the
following options:

- |SP_BUILTIN|:

  - |USER_TRAFFIC| only threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires all
      of the following:

      - Setting :xmltag:`enable_read_access_control`
        (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
        and :xmltag:`enable_write_access_control`
        (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
        to :xmlval:`TRUE`.
      - Setting the :xmltag:`metadata_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
        to a value other than :xmlval:`NONE` in combination with either:

        - setting the :xmltag:`rtps_protection_kind` |GovRule|
          (see :ref:`p2_core/cryptography:rtps_protection_kind (domain_rule)`)
          in the |GovernanceDoc| to :xmlval:`SIGN_WITH_ORIGIN_AUTHENTICATION` or
          :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`, **or**
        - setting the :xmltag:`metadata_protection_kind` |GovRule|
          (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
          to :xmlval:`SIGN_WITH_ORIGIN_AUTHENTICATION` or
          :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`

    - |STRIDE_I| by unauthorized actors with publish permissions to the |TOPIC|
      protection requires all of the following:

      - Setting :xmltag:`enable_read_access_control`
        (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
        and :xmltag:`enable_write_access_control`
        (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
        to :xmlval:`TRUE`.
      - Setting the :xmltag:`metadata_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
        to :xmlval:`ENCRYPT` or :xmlval:`ENCRYPT_WITH_ORIGIN_AUTHENTICATION`.

        - Alternatively (only needed if using Persistence Service),
          granted by setting the :xmltag:`data_protection_kind` |GovRule|
          (see :ref:`p2_core/cryptography:data_protection_kind (topic_rule)`)
          to :xmlval:`ENCRYPT`, in combination with setting publish-only
          permissions for applications that are only authorized to write
          (not read) to a |TOPIC|.

  - |META_TRAFFIC| related threat protection:

    - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| protection requires all
      of the following (same configuration as in |TOPIC_OUTSIDER|
      |META_TRAFFIC| related |STRIDE_S|\ |STRIDE_T| |STRIDE_D|\ |STRIDE_E|
      protection):

      - Enabling |DOMAIN_INSIDER_PROTECTION| (at least, for the
        |META_TRAFFIC|).
      - Setting :xmltag:`enable_read_access_control`
        (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
        and :xmltag:`enable_write_access_control`
        (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
        to :xmlval:`TRUE`.
      - Setting :xmltag:`enable_discovery_protection`
        (see :ref:`p2_core/cryptography:enable_discovery_protection (topic_rule)`)
        and :xmltag:`enable_liveliness_protection` to :xmlval:`TRUE`
        (see :ref:`p2_core/cryptography:enable_liveliness_protection (topic_rule)`).
      - Setting the :xmltag:`metadata_protection_kind` |GovRule|
        (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
        to a value other than :xmlval:`NONE`.

.. warning::

  |TOPIC_INSIDER_PROTECTION| is only effective if every |DP| in the |DOMAIN|
  has unique credentials (i.e., Identity Certificate and the associated
  private keys cannot be shared across multiple |DPs|).
  |DPs| sharing credentials will share the same Identity and therefore
  no |TOPIC_INSIDER_PROTECTION| is possible among them.

.. [#FOOTNOTE_DP_VS_DWDR] For simplicity, this figure does not represent |DPs|.
   |DWs| and |DRs| depicted close together correspond to a unique |DP|, while
   individual |DWs| and |DRs| correspond to unique |DPs|.

Configuration Examples for Common Threat Scenarios
==================================================

To reinforce the concepts introduced in previous sections, we now provide a set
of example scenarios with different threat requirements and we provide the
recommended configuration to address those risks.

Automotive Network Insider
--------------------------

Automotive system example where we need to protect the vehicle’s monitoring and
control |DOMAIN| from unauthorized |DOMAIN_OUTSIDER|\ s’
|STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E| threats in the
form of malicious actors with physical access to the network in which the
|DOMAIN| is running.

.. figure:: ../static/threat-model-automotive.png
  :scale: 80%
  :name: Automotive Network Insider
  :align: center

  Automotive Network Insider

For examples of threats at this level, refer to
:ref:`p3_advanced/threat_modeling:Domain Outsider Protection`.

.. _network-insider-configuration:

Configuration
.............

- |LIGHT_SP_BUILTIN|: This is the recommended configuration
  if you don’t need to provide protection for other threat levels
  (|DOMAIN_INSIDER|, |TOPIC_OUTSIDER|, |TOPIC_INSIDER|). This configuration
  provides a lightweight, easy to configure and deploy solution that
  effectively addresses the identified threats:

    - :property:`dds.sec.access.rtps_psk_protection_kind` property set to
      :xmlval:`ENCRYPT`.

.. _network-insider-resulting-protection:

Resulting protection
....................

.. list-table:: Automotive example threat protection
   :widths: 20 20
   :header-rows: 1

   * - Protection level
     - Threats protected
   * - |DOMAIN_OUTSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E|
   * - |DOMAIN_INSIDER_PROTECTION|
     - **NONE**
   * - |TOPIC_OUTSIDER_PROTECTION|
     - **NONE**
   * - |TOPIC_INSIDER_PROTECTION|
     - **NONE**

Industrial Automation Malicious 3rd-Party App
---------------------------------------------

Industrial automation example where we need to protect the monitoring and
control |DOMAIN| from unauthorized |DOMAIN_OUTSIDER|\ s
|STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E|.
The |DOMAIN| also runs medium-trust 3rd-party applications, and therefore
we need to protect a particularly security-sensitive user |TOPIC| from
malicious |TOPIC_OUTSIDER| |STRIDE_I| threats.
In the event of a security breach in one of the 3rd-party
applications, temporary service disruption by a |DOMAIN_INSIDER| is ok, but
the user |TOPIC| data shall never be leaked, as it contains proprietary
secrets.

.. figure:: ../static/threat-model-industrial.png
  :scale: 80%
  :name: Industrial Automation Malicious 3rd-Party App
  :align: center

  Industrial Automation Malicious 3rd-Party App

For examples of threats at this level, refer to
:ref:`p3_advanced/threat_modeling:Domain Outsider Protection` and
:ref:`p3_advanced/threat_modeling:Topic Outsider Protection`.

.. _malicious-industrial-domain-insider-configuration:

Configuration
.............

- |SP_BUILTIN|:

  - To ensure protection against this scenario’s |DOMAIN_OUTSIDER| threats:

    - :xmltag:`enable_join_access_control`
      (see :ref:`p2_core/access_control:enable_join_access_control (within a domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`TRUE`.
    - :xmltag:`rtps_psk_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:rtps_psk_protection_kind (domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`ENCRYPT`.

  - To ensure protection against this scenario’s |TOPIC_OUTSIDER| threats:

    - :xmltag:`enable_read_access_control`
      (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
      and :xmltag:`enable_write_access_control`
      (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
      set to :xmlval:`TRUE`.
    - :xmltag:`metadata_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
      set to :xmlval:`ENCRYPT`.

.. literalinclude:: ../snippets/example_governance_stide_none_i_none.xml
  :language: xml


.. _malicious-industrial-domain-insider-resulting-protection:

Resulting protection
....................

.. list-table:: Industrial automation example threat protection
   :widths: 20 20
   :header-rows: 1

   * - Protection level
     - Threats protected
   * - |DOMAIN_OUTSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E|
   * - |DOMAIN_INSIDER_PROTECTION|
     - **NONE**
   * - |TOPIC_OUTSIDER_PROTECTION|
     - |STRIDE_I| (complete) |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
       (limited: related |DOMAIN_INSIDER| |META_TRAFFIC| attacks are still
       possible)
   * - |TOPIC_INSIDER_PROTECTION|
     - **NONE**


Medical System Malicious Device
-------------------------------

Medical example where we need to protect the medical system |DOMAIN| from
unauthorized |DOMAIN_OUTSIDER|\ s
|STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|.
Also, we need to protect the patient
monitoring topic from being |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
from a potential hacked security camera within the hospital (which runs in
the same |DOMAIN|, but uses a different |TOPIC|).

.. figure:: ../static/threat-model-medical.png
  :scale: 80%
  :name: Medical System Malicious Device
  :align: center

  Medical System Malicious Device

For examples of threats at this level, refer to
:ref:`p3_advanced/threat_modeling:Domain Outsider Protection`,
:ref:`p3_advanced/threat_modeling:Domain Insider Protection`, and
:ref:`p3_advanced/threat_modeling:Topic Outsider Protection`.

.. _malicious-hospital-domain-insider-configuration:

Configuration
.............

- |SP_BUILTIN|:

  - To ensure protection against this scenario’s |DOMAIN_OUTSIDER| threats:

    - :xmltag:`enable_join_access_control`
      (see :ref:`p2_core/access_control:enable_join_access_control (within a domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`TRUE`.
    - :xmltag:`rtps_psk_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:rtps_psk_protection_kind (domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`SIGN`.

  - To ensure protection against this scenario’s |DOMAIN_INSIDER| threats:

    - :xmltag:`discovery_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:discovery_protection_kind (domain_rule)`)
      and the :xmltag:`liveliness_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:liveliness_protection_kind (domain_rule)`)
      to :xmlval:`SIGN_WITH_ORIGIN_AUTHENTICATION`.

  - To ensure protection against this scenario’s |TOPIC_OUTSIDER| threats:

    - :xmltag:`enable_read_access_control`
      (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
      and :xmltag:`enable_write_access_control`
      (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
      set to :xmlval:`TRUE`.
    - :xmltag:`enable_discovery_protection`
      (see :ref:`p2_core/cryptography:enable_discovery_protection (topic_rule)`)
      and :xmltag:`enable_liveliness_protection`
      (see :ref:`p2_core/cryptography:enable_liveliness_protection (topic_rule)`)
      set to :xmlval:`TRUE`.
    - :xmltag:`metadata_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
      set to :xmlval:`SIGN`.

.. literalinclude:: ../snippets/example_governance_stde_stde_stde_none.xml
  :language: xml

.. _malicious-hospital-domain-insider-resulting-protection:

Resulting protection
....................

.. list-table:: Medical example threat protection
   :widths: 20 20
   :header-rows: 1

   * - Protection level
     - Threats protected
   * - |DOMAIN_OUTSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
   * - |DOMAIN_INSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
   * - |TOPIC_OUTSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
   * - |TOPIC_INSIDER_PROTECTION|
     - **NONE**


Aviation Services Malicious Device
----------------------------------

Aviation example where we need to protect the aviation services
|DOMAIN| from unauthorized |DOMAIN_OUTSIDER|
|STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E| attacks. Also, we need to
protect the *ATC positioning* topic from
unauthorized writes or reads from planes that publish into that |TOPIC|
(i.e., |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E|
|TOPIC_INSIDER_PROTECTION|).

.. figure:: ../static/threat-model-aviation.png
  :scale: 80%
  :name: Aviation Services Malicious Device
  :align: center

  Aviation Services Malicious Device

For examples of threats at this level, refer to
:ref:`p3_advanced/threat_modeling:Domain Outsider Protection`,
:ref:`p3_advanced/threat_modeling:Domain Insider Protection`,
:ref:`p3_advanced/threat_modeling:Topic Outsider Protection`, and
:ref:`p3_advanced/threat_modeling:Topic Insider Protection`.

.. _malicious-aviation-domain-insider-configuration:

Configuration
.............

- |SP_BUILTIN|:

  - To ensure protection against this scenario’s |DOMAIN_OUTSIDER| threats: 

    - :xmltag:`enable_join_access_control`
      (see :ref:`p2_core/access_control:enable_join_access_control (within a domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`TRUE`.
    - :xmltag:`rtps_psk_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:rtps_psk_protection_kind (domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`SIGN`.

  - To ensure protection against this scenario’s |DOMAIN_INSIDER| threats
    (also a requirement to protect against |TOPIC_INSIDER| threats):

    - :xmltag:`rtps_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:rtps_protection_kind (domain_rule)`)
      in the |GovernanceDoc| set to :xmlval:`SIGN_WITH_ORIGIN_AUTHENTICATION`.

  - To ensure protection against this scenario’s |TOPIC_OUTSIDER| and
    |TOPIC_INSIDER| threats:

    - :xmltag:`enable_read_access_control`
      (see :ref:`p2_core/access_control:enable_read_access_control (topic_rule)`)
      and :xmltag:`enable_write_access_control`
      (see :ref:`p2_core/access_control:enable_write_access_control (topic_rule)`)
      set to :xmlval:`TRUE`.
    - :xmltag:`enable_discovery_protection`
      (see :ref:`p2_core/cryptography:enable_discovery_protection (topic_rule)`)
      and :xmltag:`enable_liveliness_protection`
      (see :ref:`p2_core/cryptography:enable_liveliness_protection (topic_rule)`)
      set to :xmlval:`TRUE`.
    - :xmltag:`metadata_protection_kind` |GovRule|
      (see :ref:`p2_core/cryptography:metadata_protection_kind (topic_rule)`)
      set to :xmlval:`ENCRYPT`.

.. literalinclude:: ../snippets/example_governance_stde_stde_stide_stide.xml
  :language: xml

.. _malicious-aviation-domain-insider-resulting-protection:

Resulting protection
....................

.. list-table:: Aviation example threat protection
   :widths: 20 20
   :header-rows: 1

   * - Protection level
     - Threats protected
   * - |DOMAIN_OUTSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
   * - |DOMAIN_INSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
   * - |TOPIC_OUTSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_I|\ |STRIDE_D|\ |STRIDE_E|
   * - |TOPIC_INSIDER_PROTECTION|
     - |STRIDE_S|\ |STRIDE_T|\ |STRIDE_D|\ |STRIDE_E|
       + |STRIDE_I| (from write-only applications)
