Industrial cybersecurity - The facts

Operation Technology incidents are especially memorable because of their distinct cyber-physical impact. And that played a nasty trick on OT security.

All the hype began in 2010 with Stuxnet. The Stuxnet worm was as much a fascinating technological advancement as it was an act of political warfare. It wouldn’t have looked out of place in a Mission Impossible movie. Long story short: US/Israel intelligence agencies (as is supposed) created a sophisticated piece of Windows malware. It penetrated an Iranian nuclear plant’s network and caused uranium centrifuges to be damaged by tampering with their technical parameters. You can read more about Stuxnet in our previous blog post, The EU’s response to cyberwarfare.

The case is remarkable, and no wonder it triggered countless new cybersecurity offerings, followed by a wave of marketing materials all crying "You must control your OT parameters with exceptional OT security tools!". Fair enough, but there was a slight issue with the threat model.

Hypnotized by the buzz, many neglected to notice that the threat actor was a collection of nation-states with unlimited offensive resources; something that’s hard to compete with, having an average of 5-10% of IT spending for defense. Just like many closed their eyes on anti-virus overlooked the malware before its payload triggered at the cyber-physical edge. But the idea of cross-cutting cyber-physical protection based on technology process monitoring owned the minds.

The market has spent almost a decade trying to understand that technology process monitoring for security purposes costs a lot and eventually gets minimal effect on security posture.

For many, it is still a surprise that no other such attack like Stuxnet has ever been registered. Instead, all the following well-known breaches against OT infrastructure had the primary goal of (or resulted in) making OT infrastructure access unavailable for personnel. But doesn’t that sound equally dangerous?

To achieve that goal, a hacker (surprisingly) needs no OT knowledge at all. A typical scenario for an OT or SCADA attack is:

That’s it. The technology process was disrupted, headlines were in the media, and the hackers used zero "SCADA skills". It may seem a bit simplified, but it’s easy to introduce additional malicious actions (like randomly clicking SCADA buttons on the operator’s dashboard), and that’s how the actual attacks go in real life. For example, check out the next famous cyberattack on Ukranian electric substations in 2014-2016 in another previous blog post.

As we’ve seen, causing industrial system damage oftentimes requires no specialized OT hacking knowledge at all. It makes sense that a hacker wanting to invest as little as possible to achieve the largest possible media furor should want to target OT environments.

Unfortunately, in the real world, many OT environments still lack the very basic and common security countermeasures that are prevalent in IT environments. This needs to change.

While it’s a widely exaggerated theory that "SCADA is very different," it’s still got Ethernet, Windows, and TCP/IP - all the same IT technologies for hackers to turn against OT. From that perspective, building solid OT protection requires establishing a defense-in-depth strategy with all its well-known layers like Network, Software, and Hardware Security.

You may hear from a security perspective what you "can’t" do with OT:

Thanks to these, passive network monitoring replaced first-choice security technology for OT, claiming it’s fast to deploy and safe for the industrial environment.

The problem is that network monitoring tools (NTA/NDR) alone have a natively limited number of actionable insights. And it was one of the reasons why technology parameter monitoring has been added to industrial NTA offerings, as an attempt to enhance product value. Still, it was the wrong direction, as we know now.

According to NIST SP 800-82 Industrial Controls guidelines, there are a lot of important log events that have to be continuously tracked in an industrial environment, like:

Being just a part of a SOC Visibility Triad (events management, evolved anti-malware, network detection), passive network monitoring cannot fulfill that alone and must be complemented with a SIEM system for the security team to get enriched and actionable insights throughout the whole kill chain.

Although, there are a couple of issues that stop SIEM adoption in OT:

Simply put, you must carefully design a log collection system while planning SIEM expansion to OT, and pass a FAT (Factory Acceptance Test) if necessary.

Compared to specific industrial network monitoring as a first-choice tool to secure an OT network (albeit, firewall and antivirus are the number one), SIEM has a good advantage. Security engineers are familiar with SIEMs and can start working with them immediately. As a part of an OT network security program covered by log collection and analysis, SIEMs can increase your security posture dramatically, leaving fewer blind spots for a real hacker to hide in.

And establishing industrial security events management and, at least, generic network monitoring (NTA-like) enables an insightful mechanism to detect a hacker before he starts tampering with technology parameters. Is this what we aim for?

NXLog Enterprise Edition has the capabilities to help CISOs and security engineers in charge of OT security solve these challenges quickly:

Need a log collection tool to help secure your OT environment? Try NXLog Enterprise Edition for free today, or get in touch to learn more.