Bob Huba, Emerson Process Management’s cybersecurity expert, says the replay of the “how much” security question should be another question—secure from what? He says, “Without a vulnerability assessment to know what threats you need to protect against, you can’t know if you have sufficient protections in place to mitigate these threats. Yes, you can take a worst-case vulnerability scenario, but then you run the risk of wasting time and money on too much protection and potentially putting your security emphasis on the wrong solutions that don’t make you more secure.”
Ralph Langner, of Langner Communications, a European security consultancy, says, “An automated industrial process is insecure if foreseeable failures or manipulation attempts of automation equipment, SCADA installations or network devices can cause significant or unknown damage. In real life, it’s often easy to determine required mitigation controls to get away from insecure. However, there is a difference between health, safety and environment (HSE) risks and risks relating only to money. For HSE, the budget for mitigation is largely determined by ethics, legislation and compliance, whereas for monetary consequences, budget decisions have to match anticipated monetary loss. Only some of the potential negative outcomes from security HSE events are regulated. For other risks, there is no compliance, but there are still security issues that need to be mitigated. For example, there is no need to patch systems or to install firewalls to be compliant. Companies do so anyway to reduce risk.”
Creating a “Culture of Security”
Marcus Sachs says we have failed to create a culture of security. Huba says we have to succeed. “Creating a secure system goes beyond just complying with a specification,” adds Huba. “It takes creating a ‘culture of security,’ where security is treated as everybody’s job, and they understand the consequences of dangerous behaviors. In my experience, compliance deals more with meeting the minimum, and trying to see what can be ‘gotten away with’ when the auditor is not looking. Complying is something management puts in place and audits―not something an employee does or participates in. Compliance happens around employees not because of them. You will never create a secure industrial control system without employee participation.”
Steve Carson, of Multitrode agrees. “Security focuses on the technology is because it is topical. However, the clearest security weaknesses are always in people’s practices―passwords written in books next to computers, no locks on gates, or when you can just follow a random contractor in through the security gate after he’s been given access.” Multitrode manufactures lift station controls and monitoring devices for water and wastewater utilities.
Doing, Not Saying
So, what should end users be doing to both keep their plants secure and the auditors off their backs? Kevin Staggs, engineering fellow and global security architect, Honeywell Process Solutions, gives a standard formula for determining security. “At a minimum, a plant should isolate the process control network (PCN) from the corporate network. This isolation should be done using a firewall configured to deny all traffic except for connections required between specific PCN nodes and corporate network nodes. The PCN should not be able to reach the Internet directly. A good configuration would also include a DMZ (demilitarized zone) between the corporate network and PCN. The data servers for moving information between the PCN and corporate networks would be located in the DMZ. A best practice for determining how much cybersecurity is required is to perform a PCN cybersecurity assessment of your system.”
In the end, getting the secure systems you need and want at a price the bean counters are willing to pay becomes a balancing act.
Paul Francis, Multirode’s chief technical officer, concludes, “To answer the question ‘How much security is enough?’ implies that there’s a one-size-fits-all solution for every situation, or that you even necessarily know when you’re done, as opposed to it [security] being a continual journey. Just because your system ‘complies’ with a particular directive or set of guidelines does not imply that it’s necessarily inherently secure. Best practice guidance, regulations and compliance documentation all provide critical input into the process, but to achieve adequate security in depth (a single layer is not usually enough) means you have to assess the specifics relating to items such as your geography, communications infrastructure, employee policies and control, technical architecture, protocol support, physical access, training, criticality of data and systems, government or other regulatory body requirements, risk profile and much more. Regular auditing and testing of that framework will then help evolve the model further.”
Walt Boyes is Control’s editor in chief. Nancy Bartels is Control’s managing editor.
We developed sources for this story by posting questions on the SoundOff! Blog, Twitter and the SCADA listserv and got far more responses than we had room for here. For the best in-depth comments from our respondents, and other security resources, go to www.controlglobal.com/0904_SCADA.
Ernie Rakaczky, Principal Security Architect, IPS says it all comes down to the understanding the following definitions and then taking the required actions: