6 ms·

Chemical plants (and other such facilities) should not be Internet connected. The equipment and tools should not even have a network stack. Workers in such a

by rsync 9y ago

Chemical plants (and other such facilities) should not be Internet connected. The equipment and tools should not even have a network stack. Workers in such a facility should not have their general purpose phones and computers with them. This is not a panacea - there are conceivable attack vectors for non networked equipment - but it raises the bar significantly and should be the bare minimum of acceptability for designing and running these plants.

liotier 9y ago
> Chemical plants (and other such facilities) should not be Internet connected Ok. > The equipment and tools should not even have a network stack How do you imagine sensors and actuators will be operated instead ? People running about everywhere with handheld radios, reading gauges and turning valves ? I know a guy who develops simulators for refinery operation. He explained to me how each refinery is a unique setup, cold-starting one takes a couple of days of non-stop valve twiddling with eyes on gauges and has plenty of ways to end in a fiery inferno if you do it wrong. Computerized control systems are not optional.
- raverbashing 9y ago
  You don't need tcp/ip for that
  - liotier 9y ago
    Sure, you can do it with a couple of analog electrical wires running from each valve and gauge to a central computer... You still have a computer and software (and a thick cable routing mess) and you only took some network protocol out of the attack surface (and you still need one to connect the workstations...)
    - raverbashing 9y ago
      You don't need to control everything centrally, you can compartmentalize your control (and also enforce limits) Don't bring a thermal overrun detection to the central computer and have it shutdown a burner. Do this locally
      - liotier 9y ago
        I found the name for that concept: https://en.wikipedia.org/wiki/Subsumption_architecture https://en.wikipedia.org/wiki/Subsumption_architecture - subsumption architecture puts some of the intelligence in the lower level systems. While the higher level controls can tell the lower level systems what it wants, it can't do things that the lower system determines is dangerous.
    - semi-extrinsic 9y ago
      Typically all these are on Modbus or similar though. Only the SCADA controller itself is on ethernet (in addition to modbus).
  - heavenlyblue 9y ago
    What difference does it make what kind of stack they're using?
    - justin66 9y ago
      A computer reading a bunch of serial lines can be a lot safer than one communicating with a bunch of nodes via TCP/IP. For starters, you're talking about a massive reduction in the amount of code needed.
      - heavenlyblue 9y ago
        I don't believe so: if that computer is reading a bunch of serial lines forgets to check the bounds of it's own buffer - then Houston's got a problem. That's all it takes. At least we've got a set of verified, battle-tested, multi-platform TCP/IP stacks. More importantly, they have been built with generalisation in mind, meaning that a single implementation would encapsulate all of the use-cases. But instead we've got those half-baked implementations of "oh my god, it takes me only a few hours to establish a radio link" protocols just increasing the attack surface. You're speaking of a semi-technical solution to a problem that is directly caused by the race to the bottom in the manufacturing industry (they probably have installed that equipment a few decades ago, just before they fired the last of the employees).
        justin66 9y ago
        > I don't believe so: if that computer is reading a bunch of serial lines forgets to check the bounds of it's own buffer - then Houston's got a problem. That's all it takes. That's not even an argument. You can put a buffer overflow in anything. The key thing is this: the larger your code is, the more likely you are to have one. Using serial lines isn't going to make your code larger if you're just taking sensor readings or something. Far from it. > At least we've got a set of verified, battle-tested, multi-platform TCP/IP stacks. Think about this in terms of Linux or any other Unix or bigger RTOS, if that's most straightforward: in the kernel, there's much, much less code needed to make a UART appear as a device node than there is to make an entire TCP/IP stack and network PHY work. In the kernel it's all "battle-tested" code, none of it more so than the UART drivers. In terms of software quality, relying on the serial port and not using the TCP/IP stack means you're exposed to fewer potential errors simply because there's much, much less code being used. (edit: the same basic idea applies if you're talking about something more sophisticated than a UART, like a CAN bus, which is still way less code than a TCP/IP stack) > But instead we've got those half-baked implementations of "oh my god, it takes me only a few hours to establish a radio link" protocols just increasing the attack surface. In terms of system engineering, you're exposed to fewer potential attack vectors if someone needs to plug into your system via a serial line versus accessing the system from anywhere you're connected to using the highly fragile resource of TCP/IP routing, but even connecting via a short-range radio link need not be much more complicated than that. Use a radio modem that connects via serial if you're using a real computer. Similarly, if it's a tiny embedded thing the radio is probably exposed via a serial interface. Adding TCP/IP just adds code and attack vectors. That's fine if you truly need it...
- reaperducer 9y ago
  > Computerized control systems are not optional They were before computerized control systems existed. People have been cracking petroleum molecules since 1891. https://en.wikipedia.org/wiki/Cracking_(chemistry) https://en.wikipedia.org/wiki/Cracking_(chemistry)
  - craftyguy 9y ago
    Not at the scale you have today.
    - dredmorbius 9y ago
      Perhaps scale is part of the problem?
- rsync 9y ago
  "How do you imagine sensors and actuators will be operated instead ?" I don't have to imagine it - I can just look back to how it was done before the widespread adoption of general purpose computers and their networks. The systems, and their controls, should be as dumb as possible and should fail in as boring manner possible.
chisleu 9y ago
But, but, how are we going to put JS-powered reactive front ends on the VPN so engineers can telecommute? I agree with you that they should not be connected, but you can have things disconnected and still be read-only. IE, one way optical feeds.
tritium 9y ago
The only way true isolation will emerge, is by regulatory mandate of a purpose defined hardware implementation, with a separate protocol, different datagrams (instead of TCP/IP/UDP packets) and independent land line plants, undersea cables, satellites and more. Otherwise, you'll always have some goon plugging in a wi-fi router, rigging it to a sat phone with a modem, all just to play quake with their friends, while they idle on some crane barge, or wherever their stuck, bored on some hurry-up-and-wait project plan. Even then, you'll still have wonder about silicon bugs, or tempest and row-hammer style attacks, for anything software ever touches, when a given industry fails to identify such threats themselves.
- tonyedgecombe 9y ago
  That's only likely to happen after a disaster, right now complacency rules.
- reaperducer 9y ago
  >purpose defined hardware implementation, with a separate protocol, different datagrams (instead of TCP/IP/UDP packets) and independent land line plants, undersea cables, satellites and more. If you come up with a different network, then the attackers will just switch to that network. Remember, the internet used to be lots of different networks. I'm old enough to remember bang paths, BITNET, and e-mail taking a week or more to make it across the Atlantic. Even back then, there were vulnerabilities, and even cross-network vulnerabilities. And a private satellite is a terrible idea for "security." In a previous life I used to have to operate a satellite uplink, and I can tell you that replacing a transponder's intended content with your rogue content is really quite easy if you just put your mind to it. (It's happened before.)
  - friedButter 9y ago
    > e-mail taking a week or more to make it across the Atlantic Any reading material behind this? Really interesting, would like to read up on what caused such a delay
    - 9y ago
dorfsmay 9y ago
"(Stuxnet) is typically introduced to the target environment via an infected USB flash drive. The worm then propagates across the network". https://en.wikipedia.org/wiki/Stuxnet https://en.wikipedia.org/wiki/Stuxnet
- ShorsHammer 9y ago
  Ironically also, Stuxnet is the reason Iran has such advanced cyber-offensive capabilities today and the reason for this article.
everdev 9y ago
> Chemical plants (and other such facilities) should not be Internet connected That merely hardens the target, but does not protect it. Stuxnet was delivered via USB to an Iran nuclear facility and had the exact same intent of triggering physical damage, which it apparently did successfully. A decade ago, disconnecting from the Internet would have been considered security, but things have progresses and security needs to as well. https://en.m.wikipedia.org/wiki/Stuxnet https://en.m.wikipedia.org/wiki/Stuxnet
- rsync 9y ago
  "Stuxnet was delivered via USB to an Iran nuclear facility and had the exact same intent of triggering physical damage, which it apparently did successfully." In my admonition against networked, general purpose computers, I purposely neglected to also mention that the plant engineers should not shoot themselves in the face, with an actual gun, upon starting their work shift. I neglected to mention this in the same way that I neglected to mention that you should not have a PC running Windows anywhere near your critical infrastructure. The failures that allowed stuxnet to occur were NOT "casualties on the battlefield of modern cyber warfare" - they were the clownish actions of idiots who got owned by autorun.inf[1] (among other things). [1] http://www.eweek.com/security/how-stuxnet-malware-used-autorun-trick-to-infect-pcs http://www.eweek.com/security/how-stuxnet-malware-used-autor...

by rsync 9y ago

liotier 9y ago

> Chemical plants (and other such facilities) should not be Internet connected Ok. > The equipment and tools should not even have a network stack How do you imagine sensors and actuators will be operated instead ? People running about everywhere with handheld radios, reading gauges and turning valves ? I know a guy who develops simulators for refinery operation. He explained to me how each refinery is a unique setup, cold-starting one takes a couple of days of non-stop valve twiddling with eyes on gauges and has plenty of ways to end in a fiery inferno if you do it wrong. Computerized control systems are not optional.

raverbashing 9y ago
You don't need tcp/ip for that
- liotier 9y ago
  Sure, you can do it with a couple of analog electrical wires running from each valve and gauge to a central computer... You still have a computer and software (and a thick cable routing mess) and you only took some network protocol out of the attack surface (and you still need one to connect the workstations...)
  - raverbashing 9y ago
    You don't need to control everything centrally, you can compartmentalize your control (and also enforce limits) Don't bring a thermal overrun detection to the central computer and have it shutdown a burner. Do this locally
    - liotier 9y ago
      I found the name for that concept: https://en.wikipedia.org/wiki/Subsumption_architecture https://en.wikipedia.org/wiki/Subsumption_architecture - subsumption architecture puts some of the intelligence in the lower level systems. While the higher level controls can tell the lower level systems what it wants, it can't do things that the lower system determines is dangerous.
  - semi-extrinsic 9y ago
    Typically all these are on Modbus or similar though. Only the SCADA controller itself is on ethernet (in addition to modbus).
- heavenlyblue 9y ago
  What difference does it make what kind of stack they're using?
  - justin66 9y ago
    A computer reading a bunch of serial lines can be a lot safer than one communicating with a bunch of nodes via TCP/IP. For starters, you're talking about a massive reduction in the amount of code needed.
    - heavenlyblue 9y ago
      I don't believe so: if that computer is reading a bunch of serial lines forgets to check the bounds of it's own buffer - then Houston's got a problem. That's all it takes. At least we've got a set of verified, battle-tested, multi-platform TCP/IP stacks. More importantly, they have been built with generalisation in mind, meaning that a single implementation would encapsulate all of the use-cases. But instead we've got those half-baked implementations of "oh my god, it takes me only a few hours to establish a radio link" protocols just increasing the attack surface. You're speaking of a semi-technical solution to a problem that is directly caused by the race to the bottom in the manufacturing industry (they probably have installed that equipment a few decades ago, just before they fired the last of the employees).
      - justin66 9y ago
        > I don't believe so: if that computer is reading a bunch of serial lines forgets to check the bounds of it's own buffer - then Houston's got a problem. That's all it takes. That's not even an argument. You can put a buffer overflow in anything. The key thing is this: the larger your code is, the more likely you are to have one. Using serial lines isn't going to make your code larger if you're just taking sensor readings or something. Far from it. > At least we've got a set of verified, battle-tested, multi-platform TCP/IP stacks. Think about this in terms of Linux or any other Unix or bigger RTOS, if that's most straightforward: in the kernel, there's much, much less code needed to make a UART appear as a device node than there is to make an entire TCP/IP stack and network PHY work. In the kernel it's all "battle-tested" code, none of it more so than the UART drivers. In terms of software quality, relying on the serial port and not using the TCP/IP stack means you're exposed to fewer potential errors simply because there's much, much less code being used. (edit: the same basic idea applies if you're talking about something more sophisticated than a UART, like a CAN bus, which is still way less code than a TCP/IP stack) > But instead we've got those half-baked implementations of "oh my god, it takes me only a few hours to establish a radio link" protocols just increasing the attack surface. In terms of system engineering, you're exposed to fewer potential attack vectors if someone needs to plug into your system via a serial line versus accessing the system from anywhere you're connected to using the highly fragile resource of TCP/IP routing, but even connecting via a short-range radio link need not be much more complicated than that. Use a radio modem that connects via serial if you're using a real computer. Similarly, if it's a tiny embedded thing the radio is probably exposed via a serial interface. Adding TCP/IP just adds code and attack vectors. That's fine if you truly need it...
reaperducer 9y ago
> Computerized control systems are not optional They were before computerized control systems existed. People have been cracking petroleum molecules since 1891. https://en.wikipedia.org/wiki/Cracking_(chemistry) https://en.wikipedia.org/wiki/Cracking_(chemistry)
- craftyguy 9y ago
  Not at the scale you have today.
  - dredmorbius 9y ago
    Perhaps scale is part of the problem?
rsync 9y ago
"How do you imagine sensors and actuators will be operated instead ?" I don't have to imagine it - I can just look back to how it was done before the widespread adoption of general purpose computers and their networks. The systems, and their controls, should be as dumb as possible and should fail in as boring manner possible.

chisleu 9y ago

But, but, how are we going to put JS-powered reactive front ends on the VPN so engineers can telecommute? I agree with you that they should not be connected, but you can have things disconnected and still be read-only. IE, one way optical feeds.

tritium 9y ago

The only way true isolation will emerge, is by regulatory mandate of a purpose defined hardware implementation, with a separate protocol, different datagrams (instead of TCP/IP/UDP packets) and independent land line plants, undersea cables, satellites and more. Otherwise, you'll always have some goon plugging in a wi-fi router, rigging it to a sat phone with a modem, all just to play quake with their friends, while they idle on some crane barge, or wherever their stuck, bored on some hurry-up-and-wait project plan. Even then, you'll still have wonder about silicon bugs, or tempest and row-hammer style attacks, for anything software ever touches, when a given industry fails to identify such threats themselves.

tonyedgecombe 9y ago
That's only likely to happen after a disaster, right now complacency rules.
reaperducer 9y ago
>purpose defined hardware implementation, with a separate protocol, different datagrams (instead of TCP/IP/UDP packets) and independent land line plants, undersea cables, satellites and more. If you come up with a different network, then the attackers will just switch to that network. Remember, the internet used to be lots of different networks. I'm old enough to remember bang paths, BITNET, and e-mail taking a week or more to make it across the Atlantic. Even back then, there were vulnerabilities, and even cross-network vulnerabilities. And a private satellite is a terrible idea for "security." In a previous life I used to have to operate a satellite uplink, and I can tell you that replacing a transponder's intended content with your rogue content is really quite easy if you just put your mind to it. (It's happened before.)
- friedButter 9y ago
  > e-mail taking a week or more to make it across the Atlantic Any reading material behind this? Really interesting, would like to read up on what caused such a delay
  - 9y ago

dorfsmay 9y ago

"(Stuxnet) is typically introduced to the target environment via an infected USB flash drive. The worm then propagates across the network". https://en.wikipedia.org/wiki/Stuxnet https://en.wikipedia.org/wiki/Stuxnet

ShorsHammer 9y ago
Ironically also, Stuxnet is the reason Iran has such advanced cyber-offensive capabilities today and the reason for this article.

everdev 9y ago

> Chemical plants (and other such facilities) should not be Internet connected That merely hardens the target, but does not protect it. Stuxnet was delivered via USB to an Iran nuclear facility and had the exact same intent of triggering physical damage, which it apparently did successfully. A decade ago, disconnecting from the Internet would have been considered security, but things have progresses and security needs to as well. https://en.m.wikipedia.org/wiki/Stuxnet https://en.m.wikipedia.org/wiki/Stuxnet

rsync 9y ago
"Stuxnet was delivered via USB to an Iran nuclear facility and had the exact same intent of triggering physical damage, which it apparently did successfully." In my admonition against networked, general purpose computers, I purposely neglected to also mention that the plant engineers should not shoot themselves in the face, with an actual gun, upon starting their work shift. I neglected to mention this in the same way that I neglected to mention that you should not have a PC running Windows anywhere near your critical infrastructure. The failures that allowed stuxnet to occur were NOT "casualties on the battlefield of modern cyber warfare" - they were the clownish actions of idiots who got owned by autorun.inf[1] (among other things). [1] http://www.eweek.com/security/how-stuxnet-malware-used-autorun-trick-to-infect-pcs http://www.eweek.com/security/how-stuxnet-malware-used-autor...