- July 18, 2017
By Galina Antova, Claroty
We cannot afford to rely on the same (sub)standard we used in IT security over the past 10 years. We have to act ahead of the threat ‚Äì we have to do something now.
By Galina Antova, Co-founder and Chief Business Development Officer, Claroty
For some time now, security professionals have been warning that there is a real potential of ransomware attacks targeting critical infrastructure/industrial control networks. In fact, in January of this year, Claroty predicted that these attacks would manifest themselves within the year.
The thesis that cyber security experts have been working from – which we agree with – goes something like this:
“We need to recognize that nation-states are not the only threat actors that will be attracted to the industrial control networks that run the world and power our critical infrastructure. As criminals look to expand to new domains, they are recognizing that the critical nature of these networks makes them a prime target for extortion. We’re going to see them target ICS in the near future.”
That thesis is now supported by a number of disclosures and news reports of ransomware being found on the shop floor. To date, the assessment is that this ransomware wasn’t targeted at ICS networks; rather, it found its way there in a spillover or “collateral damage” fashion. The WannaCry ransomware attacks, which spread rapidly around the globe in May, and the Petya/NotPetya ransomware, which seemed directed at Ukraine in June, are two solid examples. While it does not appear that either of these attacks were targeted specifically at industrial control networks, they were both responsible for disruptions to production at major companies around the world. The good news was that WannaCry did not seek to encrypt any file extensions specific to this domain – see our technical analysis here. The bad news is that, with a few minor tweaks to design, it very well could. With respect to Petya/NotPetya, while not targeted at ICS file extensions, its design could have led to major global disruption had it not been so specifically targeted at one region. Unlike WannaCry, Petya/NotPetyadoes not encrypt files one by one per a matching extension list, but encrypts the master file table (MFT) so that the file system is not accessible – effectively bricking the machine. This means that any infected HMI would be locked immediately. While this would not directly impact the underlying process, it would deprive all visibility and monitoring capabilities, which would lead in most cases to shutdown. An alarming case in point of Petya’s impact is that of Reckitt Benckiser, which makes everything from Lysol cleaning fluid to Dr. Scholl’s foot care goods and Mucinex cough mixture. As Fortune reported, they were so badly hit by Petya spillover that… “The attack had disrupted its ability to make and distribute products to customers in multiple markets, hitting its global supply chain. It said some of [its] factories were still not operating normally, a full week after the attack. While some of the lost revenue from the second quarter will be made good in the current one, it warned that ‘continued production difficulties in some factories mean that we also expect to lose some further revenue permanently.’”
Despite the fact that these well-known campaigns were not targeted at industrial networks, there have been a few well-publicized examples of proof of concept (PoC) designs specifically targeting ICS. We’ll point you to the Georgia Tech PoC that was presented at RSA 2017. What we can logically assume is that if researchers wearing white hats with limited resources/funding can develop these PoCs, then well-funded, profit-mongering cyber criminals can’t be far behind. In fact – as we all know – often these “good guy” PoCs serve to give the bad guys some really good ideas.
Consider what Dale Peterson had to say on the issue on the back of S4x17: “Ransomware incidents are occurring in industrial control systems (ICS). We had two recent incidents from Brazil discussed at S4x17, and we have detailed reports from our contacts of many more. The details indicate it is standard, not tailored to ICS, ransomware for computers that has found its way into an ICS. Unfortunately, ICS are likely to see smarter ransomware and targeted attacks to get it onto ICS PLCs, RTUs and controllers”
Dale isn’t alone in his belief that bad stuff is coming. We’ve been saying for some time now that the threat landscape in ICS/OT is evolving from the “cyber pearl harbor” scenario everyone has always talked about (nation on nation/terrorist on nation) to one in which criminals will be engaged. Quick note – we do not believe that the threat from nation-states is diminishing; quite to the contrary, we’ve seen a major campaign probing energy and nuclear power companies disclosed in July. That said, we feel the threat is increasing from crime actors.
Let alone what Dale or I think on the subject – your peers seem convinced that troubled waters are brewing as well. Consider a recent Tripwire study which found that 96 percent of IT Security professionals expect an increase in cyber attacks against the “Industrial Internet of Things” (a.k.a. ICS). It seems clear, we all see the writing on the wall.
So, if everyone is pretty much in agreement that criminals are coming, what should we do about it? Obviously, you have existing fires to fight on the IT side of the house. The priorities there are seemingly endless as the threats are already at the door.
Should you be making the case to rush new solutions and controls into production for your ICS environment NOW even though the threat hasn’t fully manifested?
Is “HELL YES!” too strong of a response?
We have to take the lessons learned from the failures in IT security over the past 10-15 years, learn from them and avoid repeating them in ICS. The stakes are far too high.
See, one could argue rather reasonably that the “cat and mouse” or “whack-a-mole” approach to IT security that we’ve relied upon for the past 10-20 years has been “effective enough.” We’ve played a game with our adversaries wherein we see the early stages of trends in their attack methodologies and rush countermeasures to market. When we’ve done it well, we’ve been ahead of the bell curve and cut off major damage. When we’ve done it poorly, we’ve reacted far too late and responded after much bloodletting. When averaging things out – we’ve done ‘ok’…I suppose.
To truly accept that conclusion, however, you’d have to be willing to accept that the billions in lost Intellectual Property, the tens of millions of stolen identities, the massive intelligence gains through campaigns like the one targeted at the U.S. Office of Personnel Management weren’t that bad.
But the stakes are so much bigger in ICS. In ICS, we aren’t talking about data theft, we’re not talking about micro-level impact where individuals, companies or certain government agencies/agendas are impacted – we’re talking about a macro-level issue related to the potential disruption of essential services that drive the global economy and support day-to-day life.
We cannot afford to rely on the same (sub)standard we used in IT security over the past 10 years. We have to act ahead of the threat – we have to do something now.
What to do?
There are a several steps to take. First, make sure that your governance is sorted out. There is a clear trend line of organizations assigning the CISO (or equivalent) accountability and responsibility for protecting ICS environments from cyber attack. Without this step, the rest is difficult and gains are often minimal and temporary.
Second, conduct a cyber risk assessment for your ICS organization. You don’t have to do a detailed assessment at every plant to gain enough knowledge to get a solid compass setting for planning. No need for analysis paralysis, but you need to do a detailed assessment at a few to gain the necessary understanding of the technical issues you will encounter. And there are ICS-centric risk assessment tools emerging to automate this. In our experience, many organizations are very surprised by the lack of basic hygiene in ICS networks – not just the CVE-related vulnerabilities that these environments face because of patching difficulties, but also the network configuration vulnerabilities that security and ICS teams are often blind to, but nonetheless expose the environment.
Third, implement tools that provide visibility and monitoring for these environments. Network segmentation will be important as well, but tools that provide visibility into how the ICS environment is actually configured and operating can help with segmentation projects, and monitor the environment for threats, at the same time. If you’re still not convinced of the growing threat, we at least encourage you to start talking about this with industry peers, watchdogs like ICS-CERT, groups like SANS ICS, et al. We think you’ll find this incredibly useful and enlightening. Until next time, keep fighting the good fight – the one you’re in today, and the one that looms over the horizon.
About the Author
Galina Antova is the Co-founder and Chief Business Development Officer at Claroty. Prior to co-founding the company, she was the Global Head of Industrial Security Services at Siemens providing comprehensive services for the protection of industrial customers against cyber attacks.Learn More
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe