Portaledge is a tool being developed by Digital Bond with Department of Energy funding that uses OSIsoft’s PI server interfaces to aggregate security events from IT and control system data sources and then correlate them through PI’s ACE correlation engine to detect cyber attacks.

In considering the collection of these security events in PI, an obvious side benefit occurred to the team. As we monitor the network for intrusions and attacks a multitude of secondary information is gathered, useful in quantifying network performance and health. We could use these security events to calculate security metrics and even populate a security dashboard for the control center.

It is important to differentiate between Portaledge events/meta-events and possible metric endpoints. The events and meta-events will generate alarms, the metrics are merely measurements of what may be occurring on the network.

Identifying metrics that provide a good snapshot of what is occurring security wise in a networked environment has been a challenge faced by IT professionals and constitutes the first half of the “good metric” equation. As metrics must be meaningful and hence measurable, identifying metrics that are actually useful and quantifiable is often a challenge. Good metrics are useful in driving decision making; bad metrics are worthless or even worse than that because they can provide a false sense of security or create unnecessary work.

Some possible metrics measurable through Portaledge include:

  • Communication through external access paths can be monitored, quantified and correlated through various firewall and Switch/Router interfaces. Quantifiable data in the genre could include raw traffic amounts (bandwidth), and volume of “failed” messages.
  • Out of range/uncharacteristic communications. On a control system there is a limited set of interconnections (communication paths) between systems. When a given system starts to talk to another system in an uncharacteristic manner it is worth noting. This type of event can be generated by both the IDs and by system logs.
  • Vulnerability management and patching could be supplemented by using Portaledge to ensure that products such as Bandolier are being ran on a regular basis and that patches are being applied.
  • ARP traffic volume. ARP request are ubiquitous on todays networked environments and so ARP scanning for network discovery is a favorite “stealth” enumeration technique. Spikes in ARP traffic volume can be indicative of this type of scan and may be worth monitoring.

These example metrics represent some easily discernible metrics that Portaledge could be leveraged to produce. I am sure many other relevant and valuable metrics exist that could be easily monitored with Portaledge. Any ideas and suggestions for possible metrics are appreciated.

The second part of leveraging metrics is that once the metrics have been identified, what is the best way to monitor the endpoints? How does one translate network transactions into metric data? Again this is where Portaledge shines. Interfaces exist to integrate many network events and where an interface does not exist a custom interface can be developed. Many events can be driven through existing interfaces with a little tweaking eg creating a new custom Snort event that talks through the Snort interface.