4 ms·

Please expound upon this "data diodes are a relatively cheap way to monitor them in complete safety". I'm familiar with the concept, but do not know they are in

Please expound upon this "data diodes are a relatively cheap way to monitor them in complete safety". I'm familiar with the concept, but do not know they are in widespread use, and off-the-shelfish enough to be considered "cheap". To me, the fundamental problem is that our protocol stacks are all built on an assumption of bidirectional interaction, making "data diodes" require bespoke engineering to define the correct data structures of a type that can be thrown over a wall. Like sure it's easy to cut one ethernet pair, or one serial line wire, but building up a software stack that can use that for one-way communication still seems like a hassle.

mikewarot 2mo ago
The software stack is the hassle. Let's assume you want to monitor the SCADA system doing water treatment, or some other critical task, on an air-gapped network. You add server to the network, it's purpose is to query, the SCADA system and get the status, error logs, process parameters, whatever you need, and spool them into a directory on a drive. A second process on that server then spools them off via a one-way optical link (high speed optocoupler, specially modified fiber link, etc) using some sort of protocol that broadcasts all the collected information, along with some form of error correction, on a continuous basis. It will do this until the end of time, never knowing if the information was recieved. The outside server then monitors the broadcast stream, using it to update it's own directory with the relevant data, and makes it available like any normal server to an internet connection. Because the connection has only one physical link, and it CAN NOT be reversed, ingress of control is completely prevented. Yet you can monitor the system from the outside, and never have to worry about compromise of the air-gapped network. A pair of raspberry pi's with ethernet (and not wifi/bluetooth) could do the job. Once it works, the "outside" host could be hacked, but it won't, CAN'T influence the other host, so things remain actually safe from remote hacking. [1] https://en.wikipedia.org/wiki/Unidirectional_network https://en.wikipedia.org/wiki/Unidirectional_network
- mindslight 2mo ago
  What you're describing is a whole bunch of bespoke engineering. That is the opposite of cheap. It would be interesting to go down this design path trying to make a generic product. I'd aim to dovetail into the bespoke engineering that PLCs already involve. I'd be tempted to design it as something like a modbus target (that PLC engineers would set up the system to write data to), except that modbus sucks rocks as a data format, never mind lacking the abstractions to do express multiples of the same systems. So then I guess you're left with some schema language that you're trying to appeal to PLC engineers to write securely. Maybe akin to the IEC 61131-3 Functional Block Diagram language, but with a very clear "this is the airgapped dividing line" ? But in the general case, you still need to get control data back into most systems system. So your data link will likely still be bidirectional, but with the goal to keep the protocol small and simple, to keep the attack surface small. The main problem is that it still only takes one PLC engineer to connect the two sides of the network for their own expedience. From what I can tell this is how the horror stories abound. PLCs generally use ethernet/IP these days, so one has to do deliberate work to segment the networks. And it just takes one too-smart-for-their-own-good person who wants to make that PLC available from their desk/home/vacation to ruin it.
  - mikewarot 2mo ago
    There are plug and play devices that do multiple flavors of SCADA, but as you've said, they aren't trivial, thus not cheap.
  - mikewarot 2mo ago
    > only takes one PLC engineer to connect the two sides of the network for their own expedience The fuzzy way we depreciate the term Engineer shows up in situations like this. An actual Professional Engineer, with a state issued license, would be assuming liability for their actions, and would know better than to bypass an air gap in this manner. Someone who uses the term willy-nilly, as most programmers seem to do these days, has no such restraints, nor caution, nor deep consideration of consequences.
    - mindslight 2mo ago
      As a former professional embedded design engineer, I'm not terribly swayed by arguments that "real engineering" involves licenses from the state. Nor do I think that personal liability is a great avenue for moving the needle here, as that would really just be creating indirect regulation through insurance companies (with a specific focus on what the Professional Engineer might be found liable for), while creating an ongoing tax (the insurance premiums) for anyone involved in such work. Why not just write and mandate those codes directly? something like the National Electric Code but focused on best practices for setting up secure control networks. (And while the NEC does enter into the PE dynamic, there is plenty of work subject to the NEC but that doesn't involve a PE)

mikewarot 2mo ago

The software stack is the hassle. Let's assume you want to monitor the SCADA system doing water treatment, or some other critical task, on an air-gapped network. You add server to the network, it's purpose is to query, the SCADA system and get the status, error logs, process parameters, whatever you need, and spool them into a directory on a drive. A second process on that server then spools them off via a one-way optical link (high speed optocoupler, specially modified fiber link, etc) using some sort of protocol that broadcasts all the collected information, along with some form of error correction, on a continuous basis. It will do this until the end of time, never knowing if the information was recieved. The outside server then monitors the broadcast stream, using it to update it's own directory with the relevant data, and makes it available like any normal server to an internet connection. Because the connection has only one physical link, and it CAN NOT be reversed, ingress of control is completely prevented. Yet you can monitor the system from the outside, and never have to worry about compromise of the air-gapped network. A pair of raspberry pi's with ethernet (and not wifi/bluetooth) could do the job. Once it works, the "outside" host could be hacked, but it won't, CAN'T influence the other host, so things remain actually safe from remote hacking. [1] https://en.wikipedia.org/wiki/Unidirectional_network https://en.wikipedia.org/wiki/Unidirectional_network

mindslight 2mo ago
What you're describing is a whole bunch of bespoke engineering. That is the opposite of cheap. It would be interesting to go down this design path trying to make a generic product. I'd aim to dovetail into the bespoke engineering that PLCs already involve. I'd be tempted to design it as something like a modbus target (that PLC engineers would set up the system to write data to), except that modbus sucks rocks as a data format, never mind lacking the abstractions to do express multiples of the same systems. So then I guess you're left with some schema language that you're trying to appeal to PLC engineers to write securely. Maybe akin to the IEC 61131-3 Functional Block Diagram language, but with a very clear "this is the airgapped dividing line" ? But in the general case, you still need to get control data back into most systems system. So your data link will likely still be bidirectional, but with the goal to keep the protocol small and simple, to keep the attack surface small. The main problem is that it still only takes one PLC engineer to connect the two sides of the network for their own expedience. From what I can tell this is how the horror stories abound. PLCs generally use ethernet/IP these days, so one has to do deliberate work to segment the networks. And it just takes one too-smart-for-their-own-good person who wants to make that PLC available from their desk/home/vacation to ruin it.
- mikewarot 2mo ago
  There are plug and play devices that do multiple flavors of SCADA, but as you've said, they aren't trivial, thus not cheap.
- mikewarot 2mo ago
  > only takes one PLC engineer to connect the two sides of the network for their own expedience The fuzzy way we depreciate the term Engineer shows up in situations like this. An actual Professional Engineer, with a state issued license, would be assuming liability for their actions, and would know better than to bypass an air gap in this manner. Someone who uses the term willy-nilly, as most programmers seem to do these days, has no such restraints, nor caution, nor deep consideration of consequences.
  - mindslight 2mo ago
    As a former professional embedded design engineer, I'm not terribly swayed by arguments that "real engineering" involves licenses from the state. Nor do I think that personal liability is a great avenue for moving the needle here, as that would really just be creating indirect regulation through insurance companies (with a specific focus on what the Professional Engineer might be found liable for), while creating an ongoing tax (the insurance premiums) for anyone involved in such work. Why not just write and mandate those codes directly? something like the National Electric Code but focused on best practices for setting up secure control networks. (And while the NEC does enter into the PE dynamic, there is plenty of work subject to the NEC but that doesn't involve a PE)