| >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. |
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.