4 ms·

> All that industrial control stuff with MODBUS and SCADA and other brain damage: it has even less security than the IoT junk, i.e. none! Right... because indu

> All that industrial control stuff with MODBUS and SCADA and other brain damage: it has even less security than the IoT junk, i.e. none! Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them? The problem is Industrial engineers aren't IT or security experts and that's why we have security issues. Plus they're under constant pressure to get production running and meeting deadlines. Next you'll say "but what about stuxnet! that proved that even air gapping isn't secure enough!" Yup. It also proves that using insecure general purpose operating systems (hint, windows) is stupid as well. But it's cheap and familiar so here we are. The problem isn't with the protocols or hardware, it's ignorance with a side of laziness topped with corner cutting. Also many industrial protocols don't run over tcp but instead use raw ethernet packets and have dedicated protocol processors running to keep latencies down to microsecond levels for flipping IO bits. An example is Beckhoff's EtherCAT. So security does not apply to those networks and would be difficult to implement. > Bad as home automation is, it is, incredibly, better than your run of the mill industrial automation! Apples to oranges. We recently bought a machine which has an internal automation network between a Siemens 840d, a Siemens safety PLC and a DSP controller from Adwin. Real time communications is over Profibus and CANopen. between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine. I'd trust that more than any home automation built on webshit.

walterbell 8y ago
> between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine What hardware + hardened OS would you recommend for jump boxes? OpenBSD, Linux, pfSense?
- MisterTea 8y ago
  At work I build, upgrade and maintain existing machines for in house processes so I don't use jump boxes. I have pfSense running on a PC engines APU2 for the company lan, isolated visitor wifi, and isolated 3rd party machine network. We're a small company so I do some IT and contract the rest to an IT pro friend of mine. I do unixy stuff and automation, he does windows stuff. So I would recommend the BSD's as they have been pretty well battle tested in that arena, OpenBSD being my top pick if rolling your own or pfSense if you want easy. PC Engines hardware all around and I order direct. As for our 3rd party machines with jump boxes: I view jump boxes as a security risk if directly connected to corporate lan as they can bypass firewalls. So I kept it simple and created an isolated jump box network from the pfSense that gives them 24/7 remote internet access with zero ability to see anything on the company lan. Our Internal machines are on an isolated network, all hardwired and have static IP addresses, zero internet access. The engineers frequently have to write new CNC programs so I make it easy to share files while isolating the networks; I bridged them using a Debian server running a SAMBA server with two network interfaces. One is connected to the company lan, the other to the dedicated machine lan. The file server has a single share for the engineers with RW access and each machine gets RW access only to its directory in that share. Operators go to the P (program) drive and retrieve the programs. There is no network bridging or routing between the two networks. As far as they know, it's just a file server. That network also terminates in our office and we can connect to it for programming and troubleshooting. One Idea I've been toying with is developing an internal jump box that allows our machines to connect to the corporate lan giving engineers file access while maintaining network isolation. That way I can ditch the second network and go DHCP with reservations all around.
  - walterbell 8y ago
    > There is no network bridging or routing between the two networks. If a fileserver vulnerability helps an attacker to take control of the host, they may be able to move traffic between the network cards. Might be better to have two file servers. The less-exposed server could periodically connect to the more-exposed server to sync files. Would not need open ports on the less-exposed server.
    - MisterTea 8y ago
      This is very true but I look at it like this: If they make it that far, they're in our network so we're thoroughly p0wnd. It's a compromise as air gapping was generating too many complaints from engineers and operators until the boss had enough and said fix it. so we compromised and fixed it.
      - walterbell 8y ago
        If one-way data replication is sufficient, a DIY data diode would provide strong isolation, https://www.sans.org/reading-room/whitepapers/firewalls/tactical-data-diodes-industrial-automation-control-systems-36057 https://www.sans.org/reading-room/whitepapers/firewalls/tact...
sansnomme 8y ago
>Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them? Clearly stuxnet is a myth and bedtime story to frighten children with.

walterbell 8y ago

> between that machine and the rest of the world sits a humble PC Engines box running a custom FreeBSD image that gives them secure remote access to the machine What hardware + hardened OS would you recommend for jump boxes? OpenBSD, Linux, pfSense?

MisterTea 8y ago
At work I build, upgrade and maintain existing machines for in house processes so I don't use jump boxes. I have pfSense running on a PC engines APU2 for the company lan, isolated visitor wifi, and isolated 3rd party machine network. We're a small company so I do some IT and contract the rest to an IT pro friend of mine. I do unixy stuff and automation, he does windows stuff. So I would recommend the BSD's as they have been pretty well battle tested in that arena, OpenBSD being my top pick if rolling your own or pfSense if you want easy. PC Engines hardware all around and I order direct. As for our 3rd party machines with jump boxes: I view jump boxes as a security risk if directly connected to corporate lan as they can bypass firewalls. So I kept it simple and created an isolated jump box network from the pfSense that gives them 24/7 remote internet access with zero ability to see anything on the company lan. Our Internal machines are on an isolated network, all hardwired and have static IP addresses, zero internet access. The engineers frequently have to write new CNC programs so I make it easy to share files while isolating the networks; I bridged them using a Debian server running a SAMBA server with two network interfaces. One is connected to the company lan, the other to the dedicated machine lan. The file server has a single share for the engineers with RW access and each machine gets RW access only to its directory in that share. Operators go to the P (program) drive and retrieve the programs. There is no network bridging or routing between the two networks. As far as they know, it's just a file server. That network also terminates in our office and we can connect to it for programming and troubleshooting. One Idea I've been toying with is developing an internal jump box that allows our machines to connect to the corporate lan giving engineers file access while maintaining network isolation. That way I can ditch the second network and go DHCP with reservations all around.
- walterbell 8y ago
  > There is no network bridging or routing between the two networks. If a fileserver vulnerability helps an attacker to take control of the host, they may be able to move traffic between the network cards. Might be better to have two file servers. The less-exposed server could periodically connect to the more-exposed server to sync files. Would not need open ports on the less-exposed server.
  - MisterTea 8y ago
    This is very true but I look at it like this: If they make it that far, they're in our network so we're thoroughly p0wnd. It's a compromise as air gapping was generating too many complaints from engineers and operators until the boss had enough and said fix it. so we compromised and fixed it.
    - walterbell 8y ago
      If one-way data replication is sufficient, a DIY data diode would provide strong isolation, https://www.sans.org/reading-room/whitepapers/firewalls/tactical-data-diodes-industrial-automation-control-systems-36057 https://www.sans.org/reading-room/whitepapers/firewalls/tact...

sansnomme 8y ago

>Right... because industrial automation networks should never be connected to publicly accessible networks without security in between. PLC's and sensors don't need internet or intranet access so why would you connect them? Clearly stuxnet is a myth and bedtime story to frighten children with.