When working with SCADA, understanding events is vital to prevent incidences and severe consequences for the facility. In most cases, it’s challenging to detect what is a harmless occurrence among dozens of events and what is a technical problem.
Every single action we take within our system will be logged as an event. This leads to a long, detail-rich list of events that must be analyzed. As events aren’t necessarily associated with alarms, hazardous events may take place without triggering any notification for the security team to get involved.
Understanding SCADA/OT events is a priority for organizations to act on time and prevent potential incidents.
In the following lines, we will talk about SCADA events, what they are, and how to deal with them.
Real-Life Examples of SCADA/OT Events
SCADA events are created on the system every time a detectable occurrence takes place. Such occurrence may be a minor action carried out by someone in the organization or a major operational disruption that may be the result of a cyberattack.
Regardless of the apparent meaning of an event, this feature allows organizations to be informed in great detail, sometimes spotting disguised intrusions and preventing potential incidents.
Every single event tells us a story. Something that may look minor may mean much more.
One example is a change in the controller’s firmware version. Controllers will receive one or two firmware updates in their lifetime. When an update takes place, an event is created for the team to be informed.
Now, what happens if SCADA creates frequent events indicating a change in the firmware version? Because we know that an update scenario will only happen once or twice, frequent events indicating such frequency must be investigated swiftly.
Another example is when a change in controller key state is detected. This event refers to physical changes in the key of the controller. Engineers switch keys in order to connect physically to the controller and conduct planned changes. The problem is that changes trigger events and not alarms, causing most cases to go unnoticed.
However, if the organization reports that no engineers have been working on controllers or switching their keys, that could mean that a malicious agent had access to it.
An event is also created when a controller connects remotely with a device outside the facility, something that usually happens when a manufacturer wants to do maintenance work or apply updates. Being a high-risk operation (at least from a cybersecurity perspective), the organization must review the outside communication and make sure that it was with an authorized party and not with a malicious agent.
Acting On Time
SCADA/OT events allow facilities to understand the state of their systems. Harmless-looking events may be holding a different reality. That’s why organizations must take the time to observe, monitor, and analyze the created events.
When it comes to events, the reality is often hidden in the details. If changes in controller key state, for example, take place outside working hours, this may be a major indicator of a cyberattack. The same with the conditions of an outside communication disguised as authorized or the time between firmware updates.
These small, harmless details aren’t enough to trigger alarms, but they must be carefully observed as an essential task for security teams to keep the infrastructure safe and operations running.
