PI Syslog Interface
From SCADApedia
Syslog is a protocol used for logging messages over a network. Syslog uses the client/server model. A client (e.g. GNU/Linux OS, firewall, IDS, etc.) will send messages to a syslog server. The PI Syslog Interface is a Syslog server that then converts the Syslog log events to a format to send to the PI Server as one or more points. It is a versatile method to get log data into the PI server from most IT devices and applications
Contents |
Syslog Application
A syslog server recieves and stores syslog messages that represent log events. Generic syslog messages contain the follwing three sections: PRI (Facility and Severity), Header, Message. The facility denotes the section of the operating system that created the message (e.g. kernel message, user-level message, security message, etc). The severity is set at the syslog event source at a level from 0:Emergency to 7:Debug which determines what messages are sent to the syslog server. The header contains the date/time of the event and hostname of the system that created the message. The message provides the content of the log message.
PI Syslog Interface
OSIsoft's Syslog Interface listens on the default syslog server port (UDP 514), but this port can be changed if necessary.
- The PI Syslog Interface application will run on most versions of Windows including XP and 2003 Server.
- Syslog messages are truncated at 1024 bits.
- Messages can be filtered to only forward messages that meet a filter or regular expression specified in the Extended Description.
- The maximum queue size in the Syslog Interface is 50,000 messages. This can be increased, but at some point the queue may become too large and cause the interface to shut down. There are four parameters that measure queue performance and can be monitored.
Individual points are defined as follows:
- Location 2 = Syslog Interface Type: Most systems will use the General Interface setting of 5, but there are enhanced event parsing options for Cisco's PIX firewall (0, 1, 2, or 3)and CISCO devices with IOS (4)
- Location 3 = Defines what part of the syslog message will be placed in the point. For example for a Location 3 value of 0 will place the entire syslog message in the point, while a Location 3 value of 4 will only place the host IP address in the point. This shows that multiple points can be created to store different parts of the syslog message.
- Location 5 = Defines the count and rate applied to the criteria set in the Extended Description
- Extended Description = A filter or regular expression that limits what messages are sent to the PI server. The filter capability allows any of the Syslog parameter fields to be filtered. For example, DEVICE=IP address would allow syslog messages from mulitple sources to be placed into separate points. Or SEVERITY= filter would allow different severity levels to be placed in different points. In addition to this build in filtering language, a regular expression can also be used in the Extended Description which provides almost limitless filtering flexibility. The regular expression can also include a substitution capability that returns a custom message that could be more easily understood rather than the regular expression result.
PI Syslog Interface in Portaledge Attack Detection
The syslog server interface can be used to log all system event messages on systems that support syslog. This is an incredibly valuable source of information for detecting cyber attacks and other security incidents. Of course there are a large number, probably the vast majority, of syslog messages that are unrelated to security. A Portaledge implementation question is where the filtering of syslog messages and placement into specific points should be best be performed. There are two basic options and a range between these options.
Option 1 is to simply send all syslog messages in their entirety back to the PI server. The PI server than can process this data using the module database and ACE modules to extract the useful security information and use it in one or more correlation attempts to identify meta security events. This results in more data being sent over the network and stored in the PI server, but it is extremely simple to configure a single point in the PI Syslog Interface.
Option 2 is to create multiple points in the PI Syslog Interface and use the filtering and regular expressions to remove unnecessary information and place helpful security information in a context based on point tag names. For example, each syslog data source could have points for messages at each severity level and perhaps even individual points for specific messages. This option is more work in configuring the interface, but it does reduce network traffic and storage in PI.
After discussions with the OSIsoft team, the Portaledge recommendation is to perform very little if any filtering at the PI Syslog Interface. PI is designed to store large amounts of data and the performance impact is expected to be negligible, and the desire to limit the amount of work for asset owners to deploy Portaledge were the driving factors. In addition, if the data is not sent to the PI server it is lost and could not be used for any after incident analysis.
