Innovative 
Cybersecurity for the 
Power Grid

StationGuard is a passive IDS that does not interact with your equipment. The connection via mirror ports (also known as SPAN ports) ensures that the IDS cannot send any packets into the network.​​​​​

All events and alerts detected by StationGuard are immediately reported in the StationGuard and GridOps user interfaces, logged on the sensors along with forensic evidence, and routed. In addition, your staff can be separately notified of events and alerts via email according to your reporting and escalation paths. 

Because StationGuard is a passive IDS, it does not actively interfere with network traffic or execute commands/switches. In addition, it is possible to implement automated processes that execute pre-programmed automatic responses (e.g., via a SIEM system). This would allow a SIEM or SOAR system to automatically activate firewall rules to block the IP addresses in question after a StationGuard alert, for example. 

Yes, LDAP/Active Directory integration can be managed and configured through the GridOps central management system. 

To ensure secure access to your StationGuard instances, you can define different roles and access rights via our central management system GridOps. For example, you can specify that only authorized personnel can make configuration changes or enter maintenance mode. With Role-Based Access Control (RBAC), threats can be reduced and even eliminated. 

GridOps has a vulnerability database that monitors all your assets or resources live for vulnerabilities. This database contains all security advisories published by device vendors for each asset. GridOps has a built-in device database that can identify sub-components, plug-in cards, and their firmware versions to provide the most accurate vulnerability management for protection and control devices. 

With our built-in vulnerability management, GridOps shows you 

• which of your protection and automation devices are affected by a disclosed vulnerability (CVE or Security Advisory), 
• automatically assesses their criticality based on CVSS, and 
• shows you remediation options, such as a firmware update or configuration advisories. 

For IT and OT protocols, our attack detection system includes advanced and effective anomaly detection based on our integrated Deep Packet Inspection (DPI) to protect against cyber-attacks at an early stage. We perform a detailed analysis of transmitted data packets and their content on the network. 

Supported OT protocols include IEC 61850 MMS, GOOSE, IEC 62439-3 PRP and HSR (with RedBox), IEC 60870-5-104; DNP3; Modbus TCP; IEC 62056 (DLMS/COSEM); IEEE C37.118 (Synchrophasor); IEEE 1703-2012 / ANSI C12.22 (AMI Protocol); IEC 60870-6 (ICCP/TASE.2 - UCA 2.0); SIEMENS S7; EtherCAT; Profinet; etc. 

Supported IT protocols include FTP; HTTP; HTTPS (without decryption, but with application detection); RDP; NTP; NetBIOS (Windows File Sharing); ARP; DHCP; MySQL; MSSQL; PostgreSQL; SSH (without decryption, but with application detection); Telnet; ICMP / ICMPv6; RIPv2; SSDP; MDNS; etc. 

An additional feature of our StationGuard intrusion detection system is the integrated functional monitoring of the plant network. This allows you to monitor not only cybersecurity parameters, but also the proper operation of your automation systems and networks to detect deviations from the target state of the plant. This can include interoperability problems between devices, configuration errors, exceeded transmission times and failed time synchronization. 

The key difference between StationGuard and other OT IDSs is how the baseline is created. StationGuard uses a whitelist mechanism, which could also be considered a baseline, but the point is how the baseline is created. With other IDSs, the baseline is learned from the traffic seen in the first two weeks, for example. But you‘re not going to see everything that happens in the lifecycle of a substation, and that‘s going to cause too many false positives for these learning-based systems. StationGuard takes advantage of the system‘s specification by importing project files, such as 61850 SCL format. And by importing the project files and then manually specifying the device roles, StationGuard knows the purpose of each device and the function and traffic that will occur. From there, StationGuard can establish that baseline. This results in far fewer false alarms than the learning approach.

That‘s a common problem that we see because when you go into substations and you‘re doing maintenance, it‘s likely that you‘re going to trigger a lot of cybersecurity alarms, for example, on the intrusion detection system. And so it makes sense to tell the intrusion detection system that maintenance is going on. And we also saw that maintenance is much more frequent than three to five years, because there are many occasions when somebody does something in the substation. So those alerts are more frequent than you might think. And that is why StationGuard has this maintenance mode, where you can tell the IDS that there is maintenance going on in the substation, and then - and only then - additional activities are allowed by the maintenance teams. Not everything, but certain maintenance activities, accessing web interfaces, using engineering protocols. But during the rest of the time this activity is forbidden. And because of that, you have high detection accuracy during normal operation. And you still have low false alarms during maintenance.

Yes. Threat intelligence for this deep OT space is somewhat different than threat intelligence for IT. So there are very few exploits that are only known for these OT devices and their vulnerabilities, but there are many known vulnerabilities. So what we provide is a vulnerability database that we have tailored specifically for these devices, where we have implemented device type matching specifically for all of the OT devices in the power grid, so we can provide the vulnerabilities that you need to look out for. Then the threat intelligence source, that is through our detection engine, updates. So we have a wide range of detection capabilities in our detection engine and we provide continuous threat intelligence updates in the form of detection engine updates to all of our StationGuard sensors out there.

For GOOSE, there‘s the IEC 62351 standard to enable GOOSE security, and the most important thing there is to add authentication to GOOSE messages, who sent them, and to prevent anyone from tampering with them. However, IEC 62351 is not yet widely used in substations. There are very few utilities using it, maybe even in pilot projects. So the technology is not there yet for widespread use. To that end, StationGuard has implemented over 35 different checks for the GOOSE protocol, because there is a wide range of possible attacks, because GOOSE is based on multicast, and basically anybody can send a GOOSE message that fits in. And so there are all kinds of different patterns of how to spoof GOOSE messages and how to disrupt GOOSE communication and so on. And this can also be done in a sneaky way. And a StationGuard can detect all of them.

In SAS communications, all devices use OT protocols, and we classify them based on their role and the function of the device. And then StationGuard knows their behavior and watches closely what they do. For these protocols, StationGuard can really identify the activity. So it can decide or know who is allowed to control a breaker and which other device is only allowed to send simple setting commands, for example. So they are both sending commands over OT protocols, but what they are controlling is completely different, and StationGuard can distinguish that. And then other things like IP cameras, CCTV, for example, they also have their device role and they are only supposed to communicate with these protocols and they are not allowed to use any of the critical OT controllable protocols there. And that‘s how it separates the devices from each other and even their criticality. For RTUs, it can also separate, for example, read-only RTUs and controlling RTUs, so you can also separate the criticality there.

Of course, if you just plug in your equipment, this will trigger unknown device alarms because there‘s suddenly a new device that shouldn‘t be there. That will trigger alarms. But what you can do is you can just accept that device, assign a role to it. You can even reuse the roles that you have for the previous device there, and it will work seamlessly. Then you can even delete the old device if you have removed it from the system. Another option is that you can simply drop the new version of the 61850 SCD file of the project and then station that will update all the devices based on it.

I would say all of them. So we have very deep support for the MMS and GOOSE protocols. Sampled Values is also supported. Along the line, which is not directly 61850, but related, are the redundancy protocols, HSR and PRP, which are also supported. Time synchronization protocols, PTP and NTP are also related to 61850, but not directly in the standard series, are also supported. And of course the SCADA communication protocols, IEC 60870-5-104 and DNP3, are implemented very deeply. So for -104, for example, we also differentiate this criticality of what is being done, what is being controlled, is it a breaker, is it not a breaker, for all of these protocols.

Update of StationGuard can be done as soon as you have connection (remote or local) to it.

Implementing patches in any operational technology (OT) system requires a thorough risk assessment. Patching is not always necessary; alternative mitigation strategies can often serve as a substitute for direct patching. If patching is deemed necessary, it is advisable to first apply these patches to identical assets in a controlled laboratory environment to ensure that the integrity of their configuration remains intact. It is then essential to temporarily suspend operations within the OT network to prevent any unforeseen disruptions that may occur during the patching process. This suspension can either be a pre-planned operational downtime or it can be performed during an unforeseen business interruption. Temporarily suspending operations provides an opportunity to perform extensive testing of the configuration of your assets to confirm their operational safety. A practical example of such a suspension could be the de-energizing of an electrical substation to ensure a safe environment for patch implementation.

We have done some studies with SDN switches from SEL. We found many advantages of using SDN together with StationGuard. SDN switches have dedicated mirror ports that can be used by StationGuard. Then StationGuard would verify the security of the traffic allowed through the SDN switch. For example, checking the integrity of the protocols, detecting if there are any spoofed connections. The configuration of the SDN can also be verified by StationGuard, since if there is an allowed traffic by mistake, it will be detected by SG. Configuration verification can be done vice versa.

We provide SW release twice a year. We have many other testing solutions which are used in OT networks with OT protocols. This side of our business gives us the knowledge of the patterns used in OT protocols which then allow us to create the allow list rules.

I am not clear with this question but to give an answer for my understanding, StationGuard supports Active directory and RBAC.

Yes, StationGuard is not IEC 61850 protocol dependent. It supports more than 300 IT protocols and more than 30 OT protocols. FTP, HTTPS are also supported.

StationGuard is not a SIEM solution. StationGuard provides its logs to SIEM solution via syslog.

If it is map to TCP/IP, yes.

Question is not clear here, but it will detect the traffic coming out of the IOT devices, if it is in a monitored zone.

With our extensive deep packet inspection list, we are proud to support over 300 IT protocols and over 30 OT protocols. This comprehensive coverage allows us to effectively monitor and analyze diverse OT environments, ensuring robust security and operational insight across diverse infrastructures.

StationGuard uses a model-based approach rather than a learning-based approach to baseline creation. With StationGuard, users manually define the system model by adding inputs through predefined rule sets and function sets. This differs from the learning-based approach, where the IDS system listens to the network over a period of time to establish a baseline of normal communications. The key difference lies in the verification process: while the learning-based approach requires ongoing verification of network activity, StationGuard users verify and configure everything into the system model up front, allowing for more targeted detection of anomalies after the fact. This approach gives users greater control and confidence in identifying potential threats on their network. But it is of course possible to train the system further on the basis of this safe initial state.

StationGuard uses multiple methods for system monitoring and asset inventory, providing both passive and active monitoring capabilities. Passive monitoring: StationGuard passively monitors the system without interfering with network communications. This approach allows for non-intrusive observation of network activity, providing insight into system behavior and potential threats. Active polling: StationGuard uses active components to actively poll devices on the network. This querying is not intended to block traffic, but rather to retrieve live name plate information from devices. By actively querying devices, StationGuard enriches its asset inventory with real-time data, improving visibility and understanding of the network environment. By leveraging both passive monitoring and active discovery, StationGuard provides a comprehensive approach to system monitoring and asset inventory management, ensuring thorough visibility and effective threat detection without disrupting network operations.

StationGuard can classify encrypted protocols based on information available in the packet headers, allowing identification even when traffic is encrypted. However, StationGuard does not currently decrypt traffic to obtain protocol details. This decision is based on the rarity of encrypted protocols in OT environments, particularly in power grids, and the associated complexities, such as troubleshooting difficulties. Because there hasn‘t been significant customer demand for decrypting encrypted traffic, StationGuard has not yet implemented this functionality. However, StationGuard can still classify protocols even if they are encrypted, since protocol information is often available on the network despite the encryption.

It‘s important to recognize that the effectiveness of StationGuard sensors is highly dependent on environmental conditions. A best practice is to monitor as many networks as possible to ensure comprehensive coverage of the network. In local OT networks, it is critical to focus on monitoring main switches, as these switches facilitate communication between the main DCS SCADA or local SCADA and servers. Leveraging the mirroring option within switches, which is commonly supported, allows for efficient monitoring of network traffic. In addition, when monitoring external connections that pass through a router, routing the traffic behind the router allows monitoring of incoming and outgoing traffic at the station. It‘s important to note, however, that the implementation of these practices should be tailored to the specific environment, as effectiveness may vary based on unique network configurations and conditions.

StationGuard classifies the protocol and verifies the integrity of the protocol to ensure it conforms to expected standards and behavior.

OMICRON has developed a novel Allowlist approach based on its many years of expertise in the field of power analysis. In contrast to conventional signature- or learning-based IDS approaches, this approach enables our StationGuard IDS to be used immediately without a learning period and with improved detection of security-relevant events and faults. The typical commissioning time for StationGuard is 1-3 hours per plant network. After this time, StationGuard is fully parameterized and ready for use without any additional training time.

StationGuard has been designed from the ground up to allow plant operators to operate and configure the intrusion detection system. The training required can be estimated to be as little as one day. StationGuard's built-in knowledge of the system gives it the advantage of requiring little system or IT knowledge from the operators themselves. However, our experts are always available on site or by phone for planning and configuration. 

To ensure a smooth and optimal start of the StationGuard IDS, we support you with our best practice approach. To this end, we first discuss your deployment and application requirements, as well as the structural design of your operator's plant. Our staff will then perform the user-specific pre-configuration of your StationGuard. Installation and integration are carried out by our expert staff at your site. 

If desired, we can work with your staff to perform a security assessment of your OT networks and systems. 

StationGuard and GridOps can easily connect to SIEM and ticketing systems (such as Splunk, FortiSIEM or ServiceNow) via built-in plug-ins. Our easy-to-understand alerts can also be forwarded via the Syslog protocol. 

Asset data, e.g., from OMICRON ADMO or ERP systems, can be imported into StationGuard to complete the asset information. By exporting the asset or working capital list from StationGuard to ticket systems, you can easily update, reconcile, and document your asset inventory. 

Integration with ticketing systems allows you to automatically create tickets to handle IDS alerts. Tickets can also be automatically assigned to the employee(s) responsible for the asset or location through an imported asset directory.

To protect against cyber-attacks during testing or maintenance of your equipment, we support you with a specially developed "maintenance mode". This can be quickly and easily enabled or disabled via StationGuard. To ensure that no false alarms are triggered even when authorized tasks are being performed, the engineering PCs and test equipment used can be registered in advance in StationGuard. This method can also be used to monitor the activities of service providers during commissioning. This flexible approach allows StationGuard to monitor assets prior to factory acceptance. 

Implementing patches in any operational technology (OT) system requires a thorough risk assessment. Patching is not always necessary; alternative mitigation strategies can often serve as a substitute for direct patching. If patching is deemed necessary, it is advisable to first apply these patches to identical assets in a controlled laboratory environment to ensure that the integrity of their configuration remains intact. It is then essential to temporarily suspend operations within the OT network to prevent any unforeseen disruptions that may occur during the patching process. This suspension can either be a pre-planned operational downtime or it can be performed during an unforeseen business interruption. Temporarily suspending operations provides an opportunity to perform extensive testing of the configuration of your assets to confirm their operational safety. A practical example of such a suspension could be the de-energizing of an electrical substation to ensure a safe environment for patch implementation.