Unisphere for PowerMax 9.2 Remote Secure Syslog

Syslog History

Syslog Was Developed in the 1980s by Eric Paul Allman (Born September 2, 1955).
Eric is An American Computer Programmer Who Developed Sendmail and Its Precursor Delivermail in the Late 1970s and Early 1980s at Uc Berkeley. In 1998, Allman and Greg Olson Co-founded the Company Sendmail, Inc. The Logging Format Used by the Mta Message Transfer Agent, Known as Syslog. Syslog Was at First Used Solely by Sendmail, but Eventually Became an Unofficial Standard Format Used by Other Unrelated Programs for Logging. Later, This Format Was Made Official by Rfc 3164 in 2001; However, the Original Format Has Been Made Obsolete by the Most Recent Revision, Rfc 5424.

Internet Engineering Task Force

The Internet Engineering Task Force (IETF) is an open standards organization, which develops and promotes voluntary Internet standards, in particular the standards that consist of the Internet protocol suite (TCP/IP). 
It has no formal membership roster or membership requirements. All participants and managers are volunteers, though their work is funded by their employers or sponsors.

The Internet Architecture Board (IAB) oversees the IETF's external relationships and relations with the RFC Editor. The IAB provides long-range technical direction for Internet development. The IAB is also jointly responsible for the IETF Administrative Oversight Committee (IAOC), which oversees the IETF Administrative Support Activity (IASA), which provides logistical, so on support for the IETF. 
The IAB also manages the Internet Research Task Force (IRTF), with which the IETF has several cross-group relations.

Steering Group

The Internet Engineering Steering Group (IESG) is a body that is composed of the Internet Engineering Task Force (IETF) chair and area directors. It provides the final technical review of Internet standards and is responsible for day-to-day management of the IETF. It receives appeals of the decisions of the working groups, and the IESG makes the decision to progress documents in the standards track.

The Syslog Protocol

Syslog utilizes three layers
  o "syslog content" is the management information contained in a syslog message.
  o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
  o The "syslog transport" layer puts messages on the wire and takes them off the wire.
  o An "originator" generates syslog content to be carried in a message.
  o A "collector" gathers syslog content for further analysis.
  o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
  o A "transport sender" passes syslog messages to a specific transport protocol.
  o A "transport receiver" takes syslog messages from a specific transport protocol.

Diagram 1 shows the different entities separated by layer.

+-------------------------+  +----------------------+
 | content                |  | content              |
 |------------------------|  |----------------------|
 | syslog application     |  | syslog application   |
 |                        |  |                      | (originator,
 |                        |  |                      | (collector, relay)
 |------------------------|  |----------------------|
 | syslog transport       |  | syslog transport     | (transport sender,
 |                        |  |                      | (transport receiver)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

How is syslog transported?

There are two common ways to send syslog messages. Although RFC 5424 requires that all syslog implementations must support an encrypted TLS network transport over TCP, most syslog messages are still delivered using the older UDP method. In the UDP version, messages are simply put into the data portion of a UDP packet and sent to the server over UDP port 514. Each message will generally fit into a single packet. UDP is stateless and session less, so there is no acknowledgement. Packets are sent into the network. This has the obvious problem that any kind of network problem could prevent delivery of the packet, in which case you might not know the network is down because it can’t tell you. It also means that sometimes important packets can be lost or damaged in transit.

Basic Principles

 The following principles apply to syslog communication:
 o  The syslog protocol does not provide acknowledgment of message delivery. Though some transports may provide status information, conceptually, syslog is a pure simplex communications protocol.
 o  Originators and relays may be configured to send the same message to multiple collectors and relays.
 o  Originator, relay, and collector functionality may reside on the same system.

Minimum Required Transport Mapping

 All implementations of this specification MUST support a TLS-based     transport as described in [RFC5425].
 All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426]. It is RECOMMENDED that deployments of this specification use the TLS-based transport.
The free-form nature of syslog messages is syslog’s greatest strength, but it’s also syslog’s greatest problem. It’s very difficult to parse through a log including events from dozens of different systems from different vendors and make sense of them simultaneously. Which messages represent what functions? And which ones represent critical events versus mere informational messages?
To deal with these questions, the syslog protocol (which is defined in RFC 5424) provides these free-form messages with special fields called “facility” and “severity.”
(Note that RFC 5424 is the standard for syslog, but not all syslog implementations are RFC 5424-compliant. The syslog protocol has been around for a very long time and there are some pre-standard implementations still in use.)

Security Requirements for Syslog

Syslog messages may transit several hops to arrive at the intended collector. Some intermediary networks may not be trusted by the originator, relay, or receiver because the network is in a different security domain or at a different security level from the originator, relay, or collector. Another security concern is that the originator, relay, or receiver itself is in an insecure network.
There are several threats to be addressed for syslog security.

The primary threats are

  o Masquerade. An unauthorized transport sender may send messages to a legitimate transport receiver, or an unauthorized transport receiver may try to deceive a legitimate transport sender into sending syslog messages to it. 
 
  o Modification. An attacker between the transport sender and the transport receiver may modify an in-transit syslog message and then forward the message to the transport receiver. Such modification may make the transport receiver misunderstand the message or cause it to behave in undesirable ways.

  o Disclosure. An unauthorized entity may examine the contents of the syslog messages, gaining unauthorized access to the information. Some data in syslog messages is sensitive and may be useful to an attacker, such as the password of an authorized administrator or user.

The secondary threat is

o Message stream modification. An attacker may delete one or more syslog messages from a series of messages, replay a message, or alter the delivery sequence. The syslog protocol itself is not based on message order. However, an event in a syslog message may relate semantically to events in other messages, so message ordering may be important to understanding a sequence of events.

The following threats are deemed to be of lesser importance for syslog, and are not addressed in this document:
  o Denial of Service

  o Traffic Analysis

Using TLS to Secure Syslog

TLS can be used as a secure transport to counter all the primary threats to syslog described above

  o Confidentiality to counter disclosure of the message contents.

  o Integrity-checking to counter modifications to a message on a hop-by-hop basis.

  o Server or mutual authentication to counter masquerade.

Note: This secure transport (i.e., TLS) only secures syslog transport in a hop-by-hop manner and is not concerned with the contents of syslog messages. In particular, the authenticated identity of the transport sender (e.g., subject name in the certificate) is not necessarily related to the HOSTNAME field of the syslog message. When authentication of syslog message origin is required, [SYS-SIGN] can be used.

Encrypting Syslog Traffic with TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Dell Security Management Server Syslog and SIEM guide
https://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Rsys Logging
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Events and Alerts for PowerMax and VMAX 9.2 User Guide

Solutions Enabler 9.2 CLI Reference Guide

Unisphere for PowerMax 9.2.0 Online Help