DCS security vs paranoia

makr8100

Member
Join Date
Jan 2018
Location
USA
Posts
31
I'm working on a DCS system that would use a server to act as a gateway between a LAN of PLC's and the corporate LAN. There would be no PLC's accessible via other networks. My idea was shot down by my employer's IT department due to DCS systems being "inherently insecure". They also mentioned Chinese and Russian hackers potentially breaching their firewall, therefore making the gateway server a target for tunneling and login attempts. They would be open to using it on restricted devices that were not accessible via the corporate LAN. Is this typical of IT departments or is my company just paranoid? Just curious as I would be trying to make this a viable system to compete with the likes of FactoryTalk and Indusoft Web Studio.
 
Every case will be different when it comes to cyber security and it will be based on risk as well. Some companies will simply not allow it if they are aware that they are a high value target from hackers.

You didn't mention, but does your gateway server sit between firewalls?

The DCS being inherently insecure may be a fair comment though as Windows patching has a high likelihood of breaking stuff and upgrading the control system with a more secure version carries a high price tag (not accounting disruption to process).
 
Your company is not paranoid.
DCS are "inherently insecure" because it is practically not possible to have a strict regimen of applying all Windows updates, browser updates, antivirus updates, and IT managing users and policies. Trying to do so will be a nightmare on the DCS side.
And often such updates require a reboot for them to take effect, which is a deal-breaker for a DCS that has to run 24/7.
But it should be possible to connect the two sides by dedicated gateways that are designed for this purpose. Something like this: https://w3.siemens.com/mcms/industr...etwork-security/scalance-s/pages/default.aspx
 
I'm working on a DCS system that would use a server to act as a gateway between a LAN of PLC's and the corporate LAN. There would be no PLC's accessible via other networks. My idea was shot down by my employer's IT department due to DCS systems being "inherently insecure". They also mentioned Chinese and Russian hackers potentially breaching their firewall, therefore making the gateway server a target for tunneling and login attempts. They would be open to using it on restricted devices that were not accessible via the corporate LAN. Is this typical of IT departments or is my company just paranoid? Just curious as I would be trying to make this a viable system to compete with the likes of FactoryTalk and Indusoft Web Studio.
No, they are not paranoid but at the same time, they should have some kind of IT/OT interface design to support data-communication need between the control and IT side.

I think everyone on this site should be familiar with the "Purdue Model". You can google it. The topic of IT/OT is too big to cover here with a few paragraph but Rockwell and Cisco got some good documentation on it if you search for "Rockwell / Cisco CPWE". Keep in mind they all are derivation of the Purdue model.
 
I'm working on a DCS system that would use a server to act as a gateway between a LAN of PLC's and the corporate LAN. There would be no PLC's accessible via other networks. My idea was shot down by my employer's IT department due to DCS systems being "inherently insecure". They also mentioned Chinese and Russian hackers potentially breaching their firewall, therefore making the gateway server a target for tunneling and login attempts. They would be open to using it on restricted devices that were not accessible via the corporate LAN. Is this typical of IT departments or is my company just paranoid? Just curious as I would be trying to make this a viable system to compete with the likes of FactoryTalk and Indusoft Web Studio.

This is fairly typical of IT departments, in my experience.

I would not expose the DCS to any external communication that I did not have to.

Our DCS is on it's own switches, runs on a separate Hypervisor machine, with it's own SAN. One communication external is via ethernet to the PLC system. The other is a 'one-way' path through the firewall to our PI system. The PI system on the Application Station polls for changes, does it's own exception reporting, and buffers information to be sent through the firewall(s) to head office. The PI buffer in the control domain initiates communication to the DMZ, which then sends it onward. No initiation from the DMZ to the control domain.

The number of hacks available for script kiddies (attacks well documented for security issues in common DCS and PLC systems) that only require downloading an app and starting it ... is disturbing. And they can pound away at your system 24/7 from anywhere.

Many of these systems track the versions of software you use - not just controls, but windows, sql, etc. When an update is available, the hack is exploited and an update is available to the script kiddies to go and take advantage for every system they logged with the vulnerability. Within a few hours. It's sort of scary!

So ... if someone wants into your system, I don't think there is any such thing as PARANOID.
 
Paranoid, but with good reason.

I do connect DCS systems to remote locations. Specifically for remote operation of units (gas turbines) in off hours at unmanned sites, and/or for one manned sites to be able to do loop checks for maintenance. Many companies do this.

For one manned sites to do better maintenance, i use a physical disconnect that has to be turned on/off when needed. This turns on access to a firewall and dedicated wireless gateway. The site can then use a dedicated maintenance laptop to access the DCS LAN. Of course, the laptop must use an encrypted method of access such as TeamViewer or an encrypted VNC. In addition to the encytion, you can even program some firewalls and routers to only allow traffic from a specific MAC address. So, only the dedicated laptop can pass traffic and nothing else. For routers, this is called the "access control list". Routers and firewalls can also be programmed to only pass certain "ports and services". If you don't want to allow an particular access method such as RDP, you can block that.

For unmanned site access, we set up a dedicated VPN tunnel that is encrypted, then the remote access software is also an encrypted method as mentioned before.

The software used is determined by the OS you are trying to access. Older systems like a GE 7FA with MkV controls using old Cimplicity 4.xx running on Windows NT can't handle TeamViewer, so an encrypted VNC needs to be used. Also, Windows XP can run TeamViewer, but Windows XP embedded can't. Odd stuff like an older Siemens TXP system running on SCO Unix can't even be remoted to.

Whats your DCS and its interface software(HMI) and the OS its running on. I might be able to give you some tips on how to securely remotely access it. Also, do you have a historian such as OSIsoft PI? If so you already have a leg into the DCS that may go offsite back to corporate headquarters or some other centralized location. Challenge IT on how that is acceptable but another remote connection is not. That would presumably be a remote connection that could be exploited.

Of course, there is no fool proof method, but you can always make a case based on the benefits and how risk averse you want to be. It sounds like your IT department just doesn't want to do the legwork. Like i said before many companies have been doing this for many years. The methods of remotely connecting have been getting better and more secure over the years. You wouldn't believe how much of the power industry is unmanned, remotely operated.

Dedicated VPN tunnels, properly established and maintained firewalls and routers, encrypted access software, updated and maintained AV software on the DCS and remote access point, and if for onsite use a physical disconnect for when the connection is not in use.
 
It is pretty much the job of someone who works in cyber security to be paranoid, because the reality is that someone is always trying to attack, all the time. Most of them are just scanning the internet to see who has weak security they can try to get into. Sometimes its just for fun, sometimes its malicious. However, some of them are really targeting you, and that really is a thing that happens at industrial facilities.
 
The gateway/server will be Linux running Apache to provide an API and login system. It's theoretical as it doesn't exist here yet (or anywhere for that matter). The only systems on the LAN are machines controlled by the IT department, and then whatever may have breached the external firewall. I'd hope that they do their diligence on that, but regardless there are many ways to lock down Apache. Additionally the user would have to have a valid login session just to access information, so then it comes down to the security of the app that I write. If they want encryption I can definitely set up https if they provide me an SSL cert.

My goal in starting this project is that our production supervisors and our entire maintenance team has company issued smart phones. I'd like to set up monitoring of the production line and certain machines to alert maintenance of problems and allow production to monitor product throughput. Data logging/historian and ultimately OEE software is a long term goal, I just want to read I/O at this point.

IT's complaint was that the corporate network was not appropriate and that if we were to implement the system we should have yet another LAN with separate devices. We already have a second LAN for OEE software (garbage IMHO) and iPads that we are supposed to use to monitor production while we're on the floor. Additional device, takes too long to find info, etc. Phone alerts would streamline a ton. Anyways, so LAN #3 and yet another device to carry seems unnecessary to me.
 
wait, when you say DCS, do you mean Distributed Control System? Which would be the definition most people here would assume.

What you are describing sounds like a Jump Server or maybe a read-only SCADA. Without seeing some kind of logical diagram I can't really figure out what you are trying to do. What I would suggest is to start with the Purdue Model and see how you can fit your system into the model. Otherwise I'm afraid we are all making the wrong assumptions.
 
PLC LAN to server, server runs Apache web server, PHP on the server to handle the socket connections to field protocols, then forward the field protocols into JSON REST data for web front ends, software, mobile apps, etc. The server also maintains a user list for I/O permissions. Without a valid login session the server won't respond with data. In a sense it's SCADA because only 1 device will contact the PLC's, but from a user standpoint it's DCS because multiple user devices will have access simultaneously. I've never heard the term Jump Server so maybe?
 

Similar Topics

Hi everyone How i can configure a periodic report of the list of alarms? Thanks
Replies
0
Views
58
Hi Everyone, I am currently trying to communicate ControlLogix PLCs via EtherNet/IP with Delta V DCS. There is a VIM2 card configured for...
Replies
1
Views
183
Hi, I need to read three 4-20mA signals from a DCS(ABB) in a remote 6 channel analog input module with RS485 modbus port. When I connected...
Replies
2
Views
467
I have a DCS instruction, that is set up for an E-STOP. I have the restart type and cold start type both set as automatic. I can test the e-stop...
Replies
2
Views
354
Hello All, New to this forum. I'm reviewing two programs from two different integrators we have used. Both are using Guardlogix 5094-IB16S/A...
Replies
7
Views
1,433
Back
Top Bottom