[superuser2]

>The attach surface argument was never relevant when networks were physically isolated.

If the network is designed according to this philosophy, then it will be trivial for an insider to breach the airgap. That could be someone who hates his boss, someone who's about to be fired, somebody getting paid by a competitor, somebody getting paid by a criminal enterprise planning on shorting the stock, somebody coerced or coopted by a state actor.

If the process control network is soft and chewy for anyone who can put his finger on an ethernet or USB port, you are still far from secure - as Iran learned, by the way.

Windows Embedded is relatively sane, but that's not going to have Java and Windows Media Player and antivirus software hanging out, and it's (in part) designed to let you whittle its size and attack surface down to exactly what you need. But vanilla Windows having marketshare is just baffling to me.

[ForcesOfOdin]

Seems to me, an insider wouldn't need to "breach the air gap". Quite literally they could just walk over to the controls.

So defending against the disgruntled employee, or impostor employee, armed invading non-employees,...that should be the problem realm for onsite security and management, not software designers.

But yes, you're right. That is baffling. People are fcking terrible with computers, and for most of the roles they shouldn't have to be more competent. The controls should be about as flexible as an atm machines user interface.

[superuser2]

>Quite literally they could just walk over to the controls.

Control systems may not be designed for IT security, but they are designed for safety. You would expect:

- Limits that prevent an operator from pushing a parameter to an obviously insane value

- Alarms that sound audibly and visibly on other control panels, in a control room, etc. when a situation is heading out of control or is actively dangerous

- Automated failsafes that take action to correct dangerous situations

- Audit trails that indicate what buttons were pushed, possibly by whom

- Logical access control so that i.e. line workers cannot change configuration, damaged equipment can be immobilized, a particularly sensitive operation enforces a 2-man rule, etc.

- When an employee is fired (or goes home for the night), he can no longer influence the plant in any way.

All of these would make sabotage by walking up to the controls difficult - at the very least, someone else would know about it in time to evacuate, and at best, the system would automatically correct itself while locking you out and sounding an alarm at your supervisor's desk.

If I've pwned the control system, then I can push parameters beyond the engineers' limits while MITMing and falsifying reports from sensors so that everything appears to be normal, no failsafes kick in, and no alarms go off until everybody is dead. Forensic examination of the audit log would not show me doing anything strange.

If it's my last day and I've plugged a tiny, GSM-enabled, PoE attack platform into an ethernet port, the the fact that security has taken my badge won't stop me - I can do all this from home.

[jschwartzi]

Not all of these things can be solved by a control system alone, at least not without a ton of investment in RFID and other auto-id infrastructure. Some human is still going to have to administrate your system, and he or she needs to be educated and trained, and they need to value security.

In the article's case, for example, they made it sound like the "hacker" basically conned someone into giving him access to the remote management interface. The only way you can fix a problem like that in software is to make the interface totally inaccessible.