Security | Event Logging for Auditing

[ruffsl]

This issue serves to track ideas for specifying the security event logging to be used in SROS2. Ideally this specification should be extensive enough to enable security monitoring and auditing frameworks. In particular this will be critical for auto generation of policies, or learning security profiles by demonstration. In anticipation that ROS2 will enable larger and more elaborate computation graphs; auditing and constructing complete policies manually for such networks at scale will not only be tedious for users and thus inhibit security adoption, but would be error prone as well due to the evolved human factors. Given that ROS2 is also decentralized, there is no longer an opportunity to monitor events from a central arbiter, as first approached in SROS1. This necessitates that SROS2 should define security logging mechanisms, either through dedicated topic channels or local disk storage, to provide the foundation enabling higher level automated security tooling.

Additionally, it would be advantageous if the standard translated easily to logging structured used by other secure middleware transports (i.e., DDS Secure's builtin plugins), but is not necessarily too ingrained to inhibit being a common format among transports vinders. Much of this issue may be also contingent upon the design decisions for application logging for in ROS2 in general.

Some ideal qualities for such a format may also include:

• human readable
  • format should be clear and concise
  • otherwise may prove difficult to audit or debug
• machine parsable
  • consumable for metafile auto generation
  • importing and exporting should preserve original structure
• expressive power
  • suitable for defining all SROS2 security exchanges
  • capable of extension for future security transport plugins

Additional, there are some aspects of the standard we may wish to decide on as well:

• file format
  • what file format encoding should be used (e.g., ASCII, Binary, other)
• logging level
  • supported logging levels and what would the denonte (e.g., ERROR, WARNING, DEBUG, etc.)
• templating
  • what template format should be followed for reliable parsing (e.g., CLF, syslog, ROS1, other)

[clalancette]

@ruffsl @mikaelarguedas Is the design document for this something we expect to target for bouncy, or is it a long-term task?

[mikaelarguedas]

This should be develop along the logging of ROS 2 itself (including extend the current set of logging levels and logging over topics). As logging is not currently listed on the Roadmap for Bouncy I'd say after

[ruffsl]

To tack onto the list of things to look into developing, I was recently thinking that ROS2 security logs could make use of a Distributed Ledger Technology (DLT), e.g. like blockchain or similar to afford security users a immutable log archive: Distributed Immutabilization of Secure Logs