from the Separation between Control, Plant and Business Network department...
Industrial Automation NetworksTypical electrical substation automation legacy architectures employed RTU's to communicate with protection relays and other IED's over a serial RS232/RS485 based communication protocols. SCADA Servers in turn used to communicate with RTU's on dedicated serial lines to update their real time databases. "Plant" and "Business" networks used to communicate with SCADA servers to obtain the required process data but never used to communicate directly with RTU's or mission critical Relays. This inherently provided the vital separation between the "Control" and "Plant/Business" Networks.
However the modern Relays and IED's are beginning to be equipped with Ethernet Ports and communication protocols that communicate over TCP/IP. SCADA servers can now directly connect to these field devices over LAN/WAN networks to exchange real time information over Ethernet. While the benefits are obvious and unprecedented, it also presents a serious security drawback.....It exposes these mission critical devices to hackers from upper layers!!!
My Questions
1) Are there any studies/ research for solution to this problem? Please provide some links if you know of any.
2) Any proven and robust solutions out there? If yes, how do we test/evaluate?
3) Is anyone aware of best practices that can be implemented to mitigate the security problems?
Thanks in Advance
Jai Belagur
PSE Inc.
However the modern Relays and IED's are beginning to be equipped with Ethernet Ports and communication protocols that communicate over TCP/IP. SCADA servers can now directly connect to these field devices over LAN/WAN networks to exchange real time information over Ethernet. While the benefits are obvious and unprecedented, it also presents a serious security drawback.....It exposes these mission critical devices to hackers from upper layers!!!
My Questions
1) Are there any studies/ research for solution to this problem? Please provide some links if you know of any.
2) Any proven and robust solutions out there? If yes, how do we test/evaluate?
3) Is anyone aware of best practices that can be implemented to mitigate the security problems?
Thanks in Advance
Jai Belagur
PSE Inc.
Check out the white paper(s) at ControlGlobal.com on security vulnerability assessment for a modern control system
http://www.controlglobal.com/whitepapers/2005/044.html
Just yesterday, I read of a demo that a group did revealing the weaknesses of interconnected plant systems, and how various exploits of the industrial side were accomplished, but I can't locate the link.
http://www.controlglobal.com/whitepapers/2005/044.html
Just yesterday, I read of a demo that a group did revealing the weaknesses of interconnected plant systems, and how various exploits of the industrial side were accomplished, but I can't locate the link.
Hi,
Interesting issue. Here's how I handled such a scenerio in a tobacco plant.
Connect the office desktops and servers (including SCADA database server) under one network. Then connect all the IP-enabled devices (PLCs, relays, RTUs) under another network.
The two systems will be physically separated. Now, use a hardware firewall to interconnect the two. The firewall should have two network interfaces (NICs), and it should be configured for allowing only traffics to/from the RTU, not the other devices on the automation network.
This should make the automation network secure from outside attacks, but the SCADA server will still be vulnerable.
Regards
Yeasir Rahul
www.voltsmith.com
Interesting issue. Here's how I handled such a scenerio in a tobacco plant.
Connect the office desktops and servers (including SCADA database server) under one network. Then connect all the IP-enabled devices (PLCs, relays, RTUs) under another network.
The two systems will be physically separated. Now, use a hardware firewall to interconnect the two. The firewall should have two network interfaces (NICs), and it should be configured for allowing only traffics to/from the RTU, not the other devices on the automation network.
This should make the automation network secure from outside attacks, but the SCADA server will still be vulnerable.
Regards
Yeasir Rahul
www.voltsmith.com
"Plant" and "Business" networks/applications still will not communicate directly with RTUs. Even though RTUs now use Ethernet as well as TCP/IP, that does not a complete protocol make. Above Ethernet and TCP/IP you still need an application protocol such as Modbus/TCP, FF-HSE, PROFINET etc. These application protocols are not understood by "Plant" and "Business" applications. Therefore you still need "SCADA servers" in between to convert from the Ethernet and TCP/IP based RTU protocols to OPC or "Plant" and to make data available in SQL servers and as HTML/XML for "Business".
This separation can still persist even in the age of Ethernet and IP
BTW: legacy and proprietary technologies are not secure. Although not document, they are by no means "obscure". They are very easy to hack because they are not encrypted.
Definitely you should not connect RTUs directly to the "Plant" and "Business" networks. Even if control networks now use Ethernet and IP, they are not "directly" connected. In most cases the control network still remain totally non-connected. Even though the technology is Ethernet and IP, the control-network is not hooked to the rest of the enterprise. If you do connect the control-network to the rest of the enterprise, this is done through a router as a minimum and preferably through a DMZ or firewall. For best security use a web server on the control-network side to bring the data across using HTTP/HTTPS
Security is covered in chapter 10 of the book "Software for Automation: Architecture, Integration, and Security": www.isa.org/autosoftware
Jonas
This separation can still persist even in the age of Ethernet and IP
BTW: legacy and proprietary technologies are not secure. Although not document, they are by no means "obscure". They are very easy to hack because they are not encrypted.
Definitely you should not connect RTUs directly to the "Plant" and "Business" networks. Even if control networks now use Ethernet and IP, they are not "directly" connected. In most cases the control network still remain totally non-connected. Even though the technology is Ethernet and IP, the control-network is not hooked to the rest of the enterprise. If you do connect the control-network to the rest of the enterprise, this is done through a router as a minimum and preferably through a DMZ or firewall. For best security use a web server on the control-network side to bring the data across using HTTP/HTTPS
Security is covered in chapter 10 of the book "Software for Automation: Architecture, Integration, and Security": www.isa.org/autosoftware
Jonas
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2010 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
Any sufficiently advanced technology is indistinguishable from a rigged
demo.



