| ▲ | drillsteps5 4 hours ago |
| There's huge difference between _sensors_ and _actuators_. You can put sensors online if you don't care too much about data leaking out. You put _actuators_ online... You need to be able to deal with the consequences. |
|
| ▲ | m4x 3 hours ago | parent | next [-] |
| How does this actually work, in practice? If you have read access to sensors, then there's a non-air-gapped network between the control systems and the internet. If your network isn't air gapped, then it's vulnerable, and attackers will side step the "read only" path to affect control system changes. |
| |
| ▲ | icermann 2 hours ago | parent | next [-] | | It's being called a data diode (diodes usually allows current in one direction only). It can be implemented with a fiber optics cable with only the transmitter on the secure side, a laser+photo cell for real air gap, cutting the rx cable in a rs232 or having a microcontroller with an output pin connected to another controllers input pin. By handling it with hardware instead of software you get a very secure partition between the trusted and untrusted side. It's used to monitor for example industrial systems and power plants. Wikipedia calls it unidirectional network: https://en.wikipedia.org/wiki/Unidirectional_network | | |
| ▲ | m4x 2 hours ago | parent | next [-] | | Yes, this is exactly the kind of approach I'm referring to when I say it's possible (though not trivial to implement), but it still doesn't prevent attacks. Air France 447 crashed with extraordinary loss of life because the pilots responded incorrectly to reported sensor readings. Any scenario where authorised staff are able to affect changes in a control system is vulnerable. The attack vectors just change to suit the target system. | | |
| ▲ | devman0 2 hours ago | parent [-] | | AF447 wasn't a security breach. You're talking about an entire separate class of human-machine interaction problem that has little relevance to the lack of security around access to OT operational surfaces. |
| |
| ▲ | Barbing 2 hours ago | parent | prev [-] | | All fancier than a camera pointed at the thermostat readout I’m sure but is the laser & photocell anywhere close to similar in concept? |
| |
| ▲ | isoprophlex 3 hours ago | parent | prev | next [-] | | System a emits telemetry. System b reads telemetry and exposes to the internet. You can't drive my car simply by pointing a webcam on the steering wheel. | | |
| ▲ | m4x 3 hours ago | parent [-] | | Sure, but think through the details. There are ways to expose telemetry through an otherwise air gapped system, but it is actually not easy to implement correctly. My position is that if there's any connection, of any practical type, between the control system and the outside world, an attacker will be able to find ways to break things. Even if it just boils down to "an attacker made our dashboards report numbers wrong and so we closed a valve to prevent an issue that didn't exist, and inadvertently destroyed our own product", the outcome is the same. | | |
| |
| ▲ | htrp 3 hours ago | parent | prev | next [-] | | Difference between a smart thermostat for your ac and an Arduino temperature sensor next to your AC thermostat? | |
| ▲ | drillsteps5 3 hours ago | parent | prev [-] | | There're different devices. You put online some but not the others. Temperature sensor is a sensor. Refrigeration compressor motor is an actuator. GPS positioning of a car is a sensor. Motor to turn the wheel is an actuator. Aircraft altimeter is a sensor. Motors to control control surfaces are actuators. And so on. | | |
| ▲ | m4x 3 hours ago | parent [-] | | Sure, but as stated in reply to a sibling comment, you then just hack the read-only system to mis-report sensor state and interfere with operations that way instead. Or use one of a million other approaches. Attacks won't follow your rules. | | |
| ▲ | drillsteps5 2 hours ago | parent [-] | | I think this comes down to the implementation of a particular system. But in general, since control system (the one that controls things through actuators) is NOT online, one can't interfere with it through online channels. They can interfere with sensors and fake readings reported online for example, probably, but not the ones used by the control system as it's offline. | | |
| ▲ | m4x 2 hours ago | parent [-] | | Indeed, I agree that it's better to have the control systems separate from the telemetry systems and that absolutely does prevent certain types of attack. It's dangerous to think that prevents all types of attack, however. |
|
|
|
|
|
| ▲ | AndrewKemendo 3 hours ago | parent | prev | next [-] |
| Exactly, this is bad security plain and simple |
|
| ▲ | toomuchtodo 3 hours ago | parent | prev [-] |
| This is the way. Read only remote, write access requires on site access. |
| |
| ▲ | drillsteps5 3 hours ago | parent [-] | | Pretty much. Some devices are sensors, like temperature sensors. It's not that they're "read only", it's that... You can't override temperature. For that, you need other devices. Like a switch to a motor that operates refrigeration compressor. That would be an actuator. If you put the data from the sensor online, the worst case scenario is someone unauthorized gets your data. If you build interface to control an actuator online... You can read the article up top. The problem is that all major cloud providers (AWS and Azure for sure, and I'm sure Google as well) have a large number of services targeting IoT devices, both to read and control. So default architectural decision is "We'll just plug these into AWS IoT, it's secure, reliable, highly available, and has all the features we need, all we have to do is to configure what we want and we're all set". Which in reality is not that secure just because of how IoT is designed. But AWS/Azure obviously push for these solutions because it gives them more revenue. |
|
