As our second release of Portaledge Event Modules is forthcoming, I am continuing with a series of posts on Portaledge fundamentals. My goal is to provide an overview of how Portaledge functions, and it role as a Security Event Manager for control systems.

Portaledge relies on a variety of data sources to monitor a system and detect security events. For each security event detected and recorded by Portaledge there is a corresponding event trigger. Each event module in a Portaldge event class monitors the historical data for one or more sets of criteria, watching for potential event triggers and correspondingly, creating and logging the associated event.

A Porteledge event trigger is a single data point or set of aggregated data points sent from the various PI interfaces, such as the PI IP Flow, Ping, and Syslog IT Monitor Interfaces, the OPC and other SCADA Protocol Interfaces, SCADA vendor specific interfaces or other security event data sources. Portaledge polls data from the historical data base and evaluates the data points or aggregated data set against specific criteria. If the criteria meets a trigger definition then an event is created and, the data point/set that caused the event is the event trigger.

Portaledge aggregates data from various Pi points to monitor for triggers. For example; the majority of the enumeration events poll data from over 8 data sources to create a data set representative of a network communication session. The data polled and aggregated is: source system name, source system IP address, source system port, destination system name, destination system IP address, destination system port, session length, and session protocol e.g. TCP, UDP, ICMP etc.

As Portaledge creates and stores events, an “event” is then the base level of correlated data. An event is targeted at a single system or device, i.e. a single IP address. Correlated and chained events within an event class or across event classes will be discussed in future postings.

To better understand the trigger to event process consider the following example: The Enumeration Traffic Monitor module monitors for communications between systems that are “out of bounds” meaning they are not on a list of “approved” communications. For each system in a network the administrator can create a system entry, and with that entry keep a list of systems that are allowed to talk to the system, their associated source and destination ports, and what protocol.

The Enumeration Traffic Monitor, when it executes, creates and parses a list of all the session that occurred over a given time slice. It creates the list by polling the 8 data points mentioned above from the historical data base. It then sorts and parses the list, comparing the sessions against the list of allowed communications. When a sessions is detected that is not allowed an event alert is created and logged.

The trigger is the set of of data creating the out of bounds communication fed to the historian by the IP Flow Interface. The event is a “Enumeration Traffic Monitor Event” noted with an alert that shows the source and destination IPs, the ports, the sessions size and protocol and the time stamp of when the session info was written to the historian.

Post in the Portaledge Series;
Part 1: Portaledge Overview
Part 2: Aggregating and Identifying Security Events
Part 3: PI Points, Tags and the Module Database
Part 4: The PI ACE Engine
Part 5: Triggers and Events
Part 6: Event Class Events
Part 7: Meta Events
Portaledge GUI