# True security threat to PLCs,HMIs, and other industrial equipment



## Peewee0413 (Oct 18, 2012)

Stuxnet - Wikipedia







en.m.wikipedia.org


----------



## Peewee0413 (Oct 18, 2012)

MAC filters.......


----------



## Wardenclyffe (Jan 11, 2019)

How 30 Lines of Code Blew Up a 27-Ton Generator


A secret experiment in 2007 proved that hackers could devastate power grid equipment beyond repair—with a file no bigger than a GIF.




www.wired.com


----------



## gpop (May 14, 2018)

mburtis said:


> So obviously network security is a huge deal. Even more so if you have complex automation equipment connected to a computer that is connected to the internet. What I always wonder is this, if a "hacker" was to get into the system what's the true vulnerability of industrial components like PLCs and HMIs.
> 
> I mean could a run of the mill hacker really mess up a process by changing programming in the plc or an hmi? Typically robot hacks or general hacks are going to just be looking for data in a windows system to hold for ransom, or just generally crash, right? Can a plc get a virus?
> 
> ...



Most of what you have to fear is ransomware programs that will spread through a network then encrypt all the databases at the same time. It takes a while to purge all the computers and reload windows then reload the hmi's and if one computer on the network is not cleaned correctly it ended up spreading and your back to square one. This is why you need to keep multiply back ups of the programs. 
Ransomware programs are sold online and most want-to-be hackers are using purchased programs and fishing rather than being true hackers. The people who wrote the programs also do not want to upset there own government so there are safety's built into the programs. This explains why some of the programs check if the keyboard is in Russian before encrypting. 

Stuxnet was a totally different beast and if someones going to spend that much time and effort there is not much you can do against a targeted attack. All they required was a way to delivery it to a non-networked system.  Not mentioning a person that may or may not visit this site.


----------



## gpop (May 14, 2018)

Forgot to add if a person can get into your hmi and press buttons they can get to a network switch that probably has a lower security setting. This is why all panels are now coming standard with tamper alarms and padlocks.


----------



## wiz1997 (Mar 30, 2021)

Where I currently work and other places I have worked the "machine network" is never connected to the "office network" to avoid outside interference.

It's never happened to me, but I have heard where the "machine network" and the "office network" were connected and someone in the office tried to look at a machine and fouled up the machine, just a story I've heard.

I have always been told to keep the two seperated.
Security protocols are different I am told.

If I ever need factory help on a machine they have to be granted access by me, through my laptop to access the PLC or HMI.

I have had problems with the IT guys connecting one of our maintenance laptops (machine network) to the office network which immediately wiped out the PLC programs on the laptop.

I'm sure there is some way to make them compatible, but why would you want to take the chance of some outsider poking around in the machines?


----------



## mburtis (Sep 1, 2018)

I wasn't so much asking about this in terms of doing anything I was mostly just curious what sort of vulnerability actually existed. In my mind stand alone plc and hmi type equipment has always seemed more immune to any potential threats just due to the fact that's its not a windows based computer. My niave brain figures that most hackers are going to want to hit the most companies with a single program, so they are going to focus on windows based data that they can encrypt or destroy. I know literally nothing about this type of stuff though.

The hard core attacks are very interesting in terms of the damage that they could cause. Really interesting although terrifying stuff. Again though those have to be highly targeted so probably not that big of a threat to your standard plant?

What got me thinking about all this is our SCADA system that is connected to the outside world for a remote access laptop. We have had security issues with it and the IT guy is all fired up about running everything through his network and blah blah. I've been working on setting up standalone HMIs so that if the computer crashes, we just walk over to the hmi and carry on with life. I was debating if a physical layer of protection between the computer and the HMIs and PLCs was needed or if these devices sorta had natural immunity to most basic attacks. If something gets into the computer I don't really care as long as it can't mess up the PLCs.


----------



## splatz (May 23, 2015)

There are a lot of hackers, but luckily there aren't a lot of master hackers. It doesn't take much to thwart the simple ones but in my opinion that's not enough, especially if you are a high value target. High value targets are not just banks and military, utility companies, government networks (all levels), health care, transportation, etc. etc. are too. Don't kid yourself, there are state sponsored malicious hackers knocking on the doors of these networks night and day, incredibly naive to think otherwise.

Remote access to a computer on the same network as your industrial automation is a huge vulnerability and has to be managed extremely carefully. (This is not a new thing, google up wardialing). If a bad guy with any skill or persistence gains access to that computer it gives them a foothold from which to launch more attacks, seek out vulnerabilities, etc.

There are vulnerabilities that you know about, and vulnerabilities you don't know about. Some of them nobody knows about yet. They make trouble for you when the bad guys learn about them and exploit them before the good guys find out about them and patch them.

Simple operating systems like traditional PLCs are very simple and for that reason far less prone to vulnerabilities / exploits. In more sophisticated devices, old school development practices, where every line of code in the system is subject to review, is a big factor too, but that's increasingly a thing of the past. Linux's community development is pretty much devoid of real review, security is more aimed at hoping to discover and quickly patch what sneaks in after the fact. There are lots of things running embedded linux (busybox, etc. etc.) that may not even be on the radar. Many security cameras run stripped down linux, programmable thermostats, security cameras, lots of things. Exploits of vulnerabilities in embedded linux has been the source of lots and lots of breaches of varying seriousness.

There are some people that get breached because they were careless, but lots that get breached that thought they were careful, it's usually something they didn't think of that bites them in the ass.


----------



## SWDweller (Dec 9, 2020)

wiz1997 said:


> Where I currently work and other places I have worked the "machine network" is never connected to the "office network" to avoid outside interference.
> 
> It's never happened to me, but I have heard where the "machine network" and the "office network" were connected and someone in the office tried to look at a machine and fouled up the machine, just a story I've heard.
> 
> ...


You need to corner the IT department if they are erasing your programming.
Or you are leaving the program in memory and a reboot looses it.
I used to load computer jokes, like "let the screen decay" into the front office computers for April fools. My boss only shut off his computer on weekends, when he lost the screen decay program he called me in and told me to reload it. He liked the looks of people gave looking at his screen when it slowly dissolved. I never heard from anyone else about the practice so I always assumed either they liked the diversion or they did not know what to do about it. 
This was also back in the days of 8086 machines. No log in pass word. When we got to the 286 machines log in became a requirement.


In my experience machine networks are hugely more active than office networks. PLC's can be way to chatty because of the speed of the program. A bridge solves the problem for the most part. Because of the speed and the processes connected to the PLC's I would never allow them to work on the same network. Many bad things could happen. I am used to places where life safety is at hand when you are messing with networks. One of the many reasons I dislike wireless.


----------



## paulengr (Oct 8, 2017)

The biggest threat going forward is that for 99.9% of industrial equipment the code is closed source. It’s one thing I’d say a PLC uses an interpreter or a JIT compiler to run code and all communications are limited to non-executable code. But this is not true of say Siemens PLCs which contain DLLs or AB “Logic” processors where the code editor is effectively a compiler and raw binary executable code is loaded into the processor. It’s a completely proprietary interface but protection by obscurity has been shown to be far less secure than thought. Stuxnet proves how vulnerable these systems are.

Most security recommendations are limited to things like firewall designs. None provide provable security such as we see with types assembly languages or say the JVM. So the goal is to restrict movement of potentially malicious code. For instance placing every PLC in its own network with IO on a separate physical network (and preferably a different protocol from the PC “front end”), and restricting all inter-PLC of PLC-SCADA communications to different protocols and ports that are not available on the business side or internet-facing networks via multiple firewalls that don’t have any ports in common.


----------



## rm187 (Jun 15, 2019)

paulengr said:


> The biggest threat going forward is that for 99.9% of industrial equipment the code is closed source. It’s one thing I’d say a PLC uses an interpreter or a JIT compiler to run code and all communications are limited to non-executable code. But this is not true of say Siemens PLCs which contain DLLs or AB “Logic” processors where the code editor is effectively a compiler and raw binary executable code is loaded into the processor. It’s a completely proprietary interface but protection by obscurity has been shown to be far less secure than thought. Stuxnet proves how vulnerable these systems are.
> 
> Most security recommendations are limited to things like firewall designs. None provide provable security such as we see with types assembly languages or say the JVM. So the goal is to restrict movement of potentially malicious code. For instance placing every PLC in its own network with IO on a separate physical network (and preferably a different protocol from the PC “front end”), and restricting all inter-PLC of PLC-SCADA communications to different protocols and ports that are not available on the business side or internet-facing networks via multiple firewalls that don’t have any ports in common.


I have to disagree on something.
Stuxnet shows how time/money are the true dictator of hacking. Stuxnet was created by a nation-state. So it may not apply to our discussion. Its record-breaking use of zero-days; The clear directed nature of knowing exactly what chip, exact locations and networks....

Anyway..

A airgapped / security driven plc network are the only way for even basic security anymore. There are the two options - Open source or closed, and as you and others have learned. Closed source is always worse and way more full of holes. Open source is clear winner. History has shown this time and time again. And most hackers [ex hollywood movie idea] become security experts [see defcon]

And even for a lone hacker, it comes down to time and money. Certain things can be hacked form just sitting at the computer. Most systems we are talking about will eventually require a stolen badge, breaking into the building, more real physical criminal activity. Now your in a different area mafia and larger enterprises which pay the hackers as underlings..Now we are back to the corp-espionage and nation-states....

But its pretty much anything can be hacked..... period... given enough time to research.... and test/attack. And we have seen its really about whos in control..https/tls exploit was know for years NSA using it everywhere. intel cpu meltdown and spectre... in silicone exploit...was known for years internally..


----------



## just the cowboy (Sep 4, 2013)

All networks need to be secure even PLC's. If you can remote in so can a hacker, all they need to do is jump in and change a setpoint then jump out. They can then ransom you with a threat to overdose finished water or overflow your lift stations. Remember if they can get in they can study your code all day long. 
That is why I don't even have ANY remote connections or ANY connections with IT. Also leave ALL your processors in run mode not remote/run that way if someone does get in they can't download a new program that will auto execute a time bomb.


----------



## mburtis (Sep 1, 2018)

Lots of good input on this. I have a very basic knowledge of it all so its all terrifying to me. I would rather go back to chart recorders, 4-20 panel gauges and giant walls of lights. If it wasn't for the remote access with the laptop things would be easier. Just unplug the dang thing. I don't think I'll ever convince anyone to give that up though. Mostly I'm just a curious mind trying to learn. The security aspect of our system is in the hands of the IT guy now. He gets pretty fired up about the security stuff so hopefully it's in good hands. Pretty sure he has everything separated/isolated virtually within his firewalls and switches. I need to schedule a meeting with him and actually discuss various things and have him explain it all. I need to start pushing on collectively developing a SCADA master plan as well so everyone is on the same page.


----------



## Djea3 (Mar 8, 2019)

Old SCHOOL.
When I was a Manufacturing Engineer, we handled this very easily. No office and management level computers were on the manufacturing systems at all. We were air gapped. No equipment was run wirelessly, all cat 5/6 for machine controls and the engineering programming systems were part of that system.
When receiving new programs and or blue prints etc, they came in from an office system. They were manually copied and moved into the engineering side with dual malware checks (2 providers, one at each system). We did NOT use cloud base or offsite server base backup for any engineering/manufacturing/financial systems. One backup was made and stored on site, it was copied and went home with the Plant Manager and Plant Foreman, every week they took updates and every month exchanged a full backup, 3 months backup at every location. We could wipe the entire system and start again in a shift or so.
Also, we used Dos/redhat/ and VERY EARLY windows systems to run the plant and engineering. I know it sounds a little crazy and harder to get the programs but it was very safe and actually cheap. Later we had to upgrade to Windows but kept it air gapped and no internet connections or wireless connections. Every machine had boot discs and software load/configure discs at hand.
Our shop ran over 100-120 people 24/5-7 a lot of the time. Some of our equipment could run all weekend unmanned.
We never had a computer caused shut down in Engineering, but did in sales and management (attacks). We did have workstation and internal servers die, but we could replace and be running in a few hours.
Incidentally, we had proprietary shop order and time/material tracking/billing. That data was air gapped and held separately but parallel to the Engineering system, never on the web or wireless and never to an outside server.
I was the one that insisted we not be "online" in production/cost tracking/billing side. The sales/billing people hated me because they had to manually copy from internal to external systems in all communications to customers (with malware scans).
Every shop workstation has a wired scanner to scan the barcodes for work and employees etc.
All this made ISO9000 a real pain to document.
I have no idea if that could even be done today?


----------



## Wirenuting (Sep 12, 2010)

Even a simple dial in can be a killer when someone connects to a remote panel and selects all points then “alarm by command”. 
had someone do that and dumped a research facility just minutes after I left for the day. The only thrimg the front end HMI saw was the command.


----------

