Integration for DDS Security Builtin Logging Plugin

[ruffsl]

When designing, auditing, or monitoring security policies for complex applications, comprised of many internal and external interfaces, as with distributed computation graphs in ROS2, feedback in form of security event logging can provide valuable insight into potential misconfigurations or abnormalities during development, testing, and deployment.

To further improve our security assistive tooling for SROS2, it would be pertinent to integrate security event logging to facilitate advanced features such as: Log-driven profile generation of access control policies, interoperability testing between multiple integrated systems, as well as continuous monitoring for security abnormalities. To an extent, much of this may be readily achievable by leveraging existing DDS Security Builtin Logging Plugin Interfaces.

---

Background

The Logging plugin provides the capability to log all security events, including expected behavior and all security violations or errors. The goal is to create security logs that can be used to support audits. The rest of the security plugins will use the logging API to log events.

The Logging plugin will add an ID to the log message that uniquely specifies the DomainParticipant. It will also add a time-stamp to each log message.

The Logging API has two options for collecting log data. The first is to log all events to a local file for collection and storage. The second is to distribute log events securely over DDS.

Section 8.6.1, DDS Security specification (v1.4)
https://www.omg.org/spec/DDS-SECURITY/About-DDS-SECURITY

The DDS Security specification from OMG defines 5 Service Plugin Interfaces:

Table 43 – Summary of the Builtin Plugins

SPI	Plugin Name	Description
Authentication	DDS:Auth:PKI-DH	Uses PKI with a pre-configured shared Certificate Authority
AccessControl	DDS:Access:Permissions	Permissions document signed by shared Certificate Authority
Cryptography	DDS:Crypto:AES-GCM-GMAC	AES-GCM for encryption. AES-GMAC for message authentication
DataTagging*	DDS:Tagging:DDS_Discovery	Send Tags via Endpoint Discovery
Logging*	DDS:Logging:DDS_LogTopic	Logs security events to a dedicated DDS Log Topic

(*) denotes that default implementations for SPI is optional

The most notable SPI here being that for Logging, as explained in sections 8.6, and 9.6 in the DDS Security spec. These sections detail the plugin model, parameter options, message IDL, and runtime behavior. A conforming logging plugin essently captures and records security events that may crop up at runtime in other security plugins, along with helpful identifying contexts to triage the event.

Recorded events may either be distributed by writing them to disk locally via log file, or publishing them over the DDS network, specifically over the topic name DDS:Security:LogTopic, with the following governance setting:

<topic_rule>
  <topic_expression> DDS:Security:LogTopic</topic_expression>
  <enable_discovery_protection>FALSE</enable_discovery_protection>
  <enable_read_access_control>TRUE</enable_read_access_control>
  <enable_write_access_control>FALSE</enable_write_access_control>
  <metadata_protection_kind>SIGN</metadata_protection_kind>
  <data_protection_kind>ENCRYPT</data_protection_kind>
</topic_rule>

The above rule states that any DomainParticipant with permission necessary to join the DDS Domain shall be allowed to write the BuiltinLoggingTopic but in order to read the BuiltinLoggingTopic the DomainParticipant needs to have a grant for the BuiltinLoggingTopic in its permissions document. (Section 9.6)

Progress

This was something originally I had started in SROS1 (distributed security logging, no DDS plugins), but found the ROS1 logging mechneme deficient of rich context that would render such events debuggable for large graphs, nor did it have the message structure to interject supplementary context. Additionally, the all or nothing of TLS hindered SROS1’s ability securely introspect distributed events from nodes failing to join the network to begin with.

The Logging SPI in DDS Security largely resolves these issues, via granular governance settings, structured IDL formats, abstraction over distribution (be it via files or topics), and perhaps most importantly a standard interface to introspect the internal state of the accompanying security plugins.

However, from my interpretation, while the specification is explicit in what supplementary context must be included given the message IDL, it's still a bit handwavy with respect to what the Free-form message string should contain, or how its formatted. I also suspect the meat of the info we’d like to parse out will reside therein, e.g:

• QoS and topic-name that was denied due to insufficient permissions?
• Requested permission type that was denied (read, write, relay)?
• Invalid certificate how (expired validity, broken CA chain, void signature)?

I haven’t yet tested any Logging plugins from DDS vendors, primarily as I don’t think Fast-RTPS shipps with a default plugin implementation given Logging is listed as optional plugin. I’m not so sure Fast-RTPS even has a logging SPI so that we could write our own plugin. Also, given that RTI recently released a newer version, I’ve been stalling until ROS2 compiles with Connext v6.0 before I commit any more time investigating the state of logging there. Does anyone know the progress for Security Logging SPI on Opensplice (Vortex or I guess Cyclone now?). My fear is that each vinder will have some quirky way of conveying the same info, like they already do with warning messages, making the inferencing downstream tedious.

Perhaps some readily addressable tasks for improving integration could include supporting more advance governance.xml file templating, as we’ll have to amend it to include the relevant permissions for DDS:Security:LogTopic topic when uses wish to distribute log events over DDS. Another task could be investigating the logfile format, as parsing/translating static log files seems a bit less involved than subscribing to raw DDS topics and IDL. However, any parsing interfaces in exposing security events for downstream tooling, e.g. log-driven profile generation, should probably be abstract enough for both file or network stream sources.

[acrowell-soartech]

As part of this effort, I'll suggest a feature that I already requested over at ros2/rmw#174, but which they suggested would be better tracked here:

Feature request

Feature description

The DDS Security standard includes a Logging plugin that handles logging of security events to a special topic. This is implemented and available in RTI Connext, but currently must be enabled via source code, and the corresponding configuration is not exposed in any way by RMW. This should be changed to allow users to enable either DDS Security logging to the topic or a specified file through startup configuration.

Implementation considerations

One reasonable way to present this to the user would be to make this configurable via environment variables which, if set, can configure whether logging to the secure topic, to a file, or both are to be enabled. For example, we could have:

RMW_SECURITY_LOG_TO_TOPIC=true/false
RMW_SECURITY_LOG_TO_FILE= <path to file>

The default setting in the absence of an override should be to log to the topic, but not to a file.

[acrowell-soartech]

Also, it's probably worth mentioning that I have spent a little time playing with the Logging support in RTI Connext.

There is documentation of the type of security log events and corresponding messages here: RTI Security Plugins 5.3.0 Guide on page 1-22. From what I've seen, looking at the log output to a file, the output is pretty much just the message documented there in the "Message" column, which currently isn't all that insightful for many messages, such as "failed to verify certificate," which doesn't appear to provide any context other than that a failure of some sort occurred.

From the looks of the 6.0.0 manual: here it doesn't look like it has changed significantly since then.

[ruffsl]

Yea, looking at Table 11.2 Log Messages in the Connext v6.0.0 manual, it doesn't look the existing default messages give much more insight into security events other than merely raising awareness, not necessary enough situational context to be immediately actionable for automated tooling.

Perhaps we can extend the default implementation via the standardized SPI to supplement more info. Have you looked at the Service Plugin Interface for Connext? Is it relatively consistent across DDS vendors? I'm not sure FastRTPS follows the complete SPI model specified OMG, but perhaps Opensplice does.

[mikaelarguedas]

FWIW when looking into implementing support for the Builtin Plugin last year; no open source implementation had support for it, and Connext didn't provide the security libraries in their debs. This was the motivation for not implementing it at the time as it would be hard to provide/validate abstraction or compare results with a single middleware implementation supporting it.

SPI	Fast-RTPS	OpenSplice	Connext
Authentication	✔️	🚫	✔️ **
AccessControl	✔️	🚫	✔️ **
Cryptography	✔️	🚫	✔️ **
DataTagging*	🚫	🚫	✔️ **
Logging*	🚫	🚫	✔️ **

** Not available in the ROS2 debian packages

That being said, looking into this may provide valuable insight as of what type of information we could collect from these logs and how it could contribute for auditing, generating and amending policies 👍