Once the pain of a risk assessment is over, a few managers look at each other and decide on what changes they would like to make. Usually an IT expert comes in to install new network security hardware or someone is tasked with revising documentation; but rarely does anyone tinker with assigning responsibility. Nobody wants these responsibilities. Why? Because, like safety, security failures are bound to happen. Who would sign up for being on the hot seat to answer for the latest security breach? There isn’t likely to be an increase in salary for doing this, so why bother?
And so another year goes by with nobody specifically being responsible for security. The CISO usually prances around and preens as if somebody on the security staff knows something and can save the day; but the reality is that they can’t. Security can not be enforced from the outside. Just as a safety officer cannot find a phone booth, change to his superhero costume, and swoop in to save the hapless operators from hurting themselves; security has to start from the front line.
The first step is to put some additional money on the table. Security is EVERYONE’S responsibility. This has to come from the factory floor and work its way up.
Start by training operators on what sorts of features the ICS/SCADA system has to indicate security problems. For example, training operators to monitor the PLC cycle time and network traffic rates is a very helpful practice.
Second, start teaching plant superintendents and plant engineers subjects such basic systems administration and access management tools, and why they should use these measures. In most cases they see only the hassle of doing this, but not the benefit such as attribution of mistakes or poor behavior.
Third, regular review of all logs, alarms, and system configuration documents is essential. All plant staff need to confirm that everything from instrument configuration to the HMI screen and the historian is consistent with what they expect.
Fourth, someone should be designated by the plant superintendent to keep track of vulnerabilities, patches, threats, and all system version control information. A source code control system is essential for tracking what is already there and who put it there. All SCCS information written by an employee who leaves should be reviewed.
This kind of vigilance and effort doesn’t come cheap. C-Level executives need to understand that with these duties there will be additional performance improvements. Pay should be increased accordingly. Once they become proficient in this sort of thing, the operations staff will also be able to perform many routine integration and upgrade tasks themselves. So training them and paying them more will result in a more agile and proficient operation that should experience fewer problems. Those problems that do emerge should hopefully be detected earlier and restored to working order faster. This should also enable staff to diagnose an actual attack sooner.
There is a Return On Investment here. Even if security weren’t an issue, this is usually worth doing. I have been asking for years why this isn’t more commonplace. So, why not?
