Detect

If you accept that a zero risk environment is impossible to achieve then we need to consider how we adapt to this norm.  The OT network has a special role in the Automation system touching every device from sensor to server it is the lifeblood of the automation system.

If we can understand what normal looks like then indicators of abnormal can be more easily identified.  This is not as complex and activity as it may initially seem provided some good product selection decisions were made at the outset.  If not there is not much that can be done by the network to protect the applications that it serves.

Let’s assume suitably featured, managed devices have been selected for the network’s backbone.  Configuring all devices to share a common network time clock (NTP Server) and then pointing the SYSLOG sexting stop a centralised and common machine is the first step towards your network Security Operation Centre.

Other sensors can be configured that will trigger on utilisation thresholds being exceeded these events could be indicators of compromise or could be normal activity e.g. automated backups.  This is why you need to be aware of what normal looks like so you can respond to the abnormal.

The aim is to have your sensors reporting back to a central system that present the volumes of data as information you can react to.  There is little point in presenting information that is irrelevant and only adds to confusion.

From here the work moves from the device configuration to the central server.  The server will collect data, process the data, and the present information in a consistent way.  IT4A’s approach is to group data by events, thresholds and alerts.  These metrics will relate to each network

Events

  • These are normal activities that happen from time to time and need either resolution or simply recording for reference when they occur.  Normal events might be link down, power loss, soft and hard restart, device successful login, etc.  Each event would have a related procedure that assisted the operator with resolution.

Thresholds

  • These are indicators of performance, specifically a change in performance that may indicate abnormal network usage.  Other indicators such as interface counters that sense line related errors may also be relevant.

Alerts

  • These are security related messages from all devices in relation to invalid login attempts but mainly firewalls and other security related appliances that indicate an attack may be taking place.  This could be any from dropped packets indicating a unauthorised scan in progress to a denial of service attempt on a firewall interface.  

The events, thresholds and alert messages that emirate from a device are proprietary, in some cases they follow a standard severity structure classifying messages from debug (most data) through to emergency.  

 

 0       Emergency: system is unusable

 1       Alert: action must be taken immediately

 2       Critical: critical conditions

 3       Error: error conditions

 4       Warning: warning conditions

 5       Notice: normal but significant condition

 6       Informational: informational messages

 7       Debug: debug-level messages

 

Ideally a device will be configureable to limit messages to a subset of the eight above, the subset will depend upon the device.

"I can honestly say that with IT4A working alongside us we assembled the right team and managed to achieve all our goals successfully"

Nuclear Sector,
Project Manager