This report was compiled from articles filed by the ControlGlobal.com editors during the Honeywell Symposium. Find more coverage of the event at ControlGlobal.com, keyword Honeywell User Group.
Closely tied to a current Shell project, known as the Smart Field initiative, to continuously optimize oil and gas production and recovery is the companys drive to ensure the security of its global assets. So began Dan McDougall of Shell Exploration and Production in his address to the Honeywell User Group Americas 2007 Symposium in June.
Enterprise IT security doesnt work unless everybodyfrom Brunei to the Gulf of Mexico to Europefollows the same rules, said McDougall. But in the process-control domain, we have more flexibility because we have that firewall between the process environment and the corporate environment.
In order to better communicate the relative importance of control system security to asset managers, explained McDougall, Shell links its security assessments to the overall issue of technical integrity, including risk assessment and management; defense-in-depth, with accountability at the asset level; and embedded audit and review processes.
We talk about a different kind of integrity than the enterprise IT people, so we have to explain what we mean, and then they get it, added McDougall. Theres about an 80% overlap in what the IT guys have done and what weve done, but that 20% difference is critical, and makes or breaks your process.
McDougalls recommendations for any control system security project start with getting an early management buy-in. Translate the issue at hand into business language, using risk assessments for specifics and linking the project justification to technical integrity processes.
When you talk to management, highlight your exposures, but dont overstate them, because emotion and fear lead to poor business decisions, said McDougall. Companies deal with risk every day, and asset managers understand how to prioritize it.
Be explicit in security requirements, added McDougall, using external standards as a guide and making the scope of security requirements clear. Engineering, IT and operations all need to be involved, and weve found it essential to ensure all parties understand their responsibilities and boundaries.
McDougall cautioned that its wise to remember that only about 20% of the scope is technology. The remainder is governance, people and procedures, he said. Above all, link security to business value, and do it in stages.
CERN, the European physics lab and birthplace of the World Wide Web, tested 59 different PLCs and found huge numbers of failures in those controllers. That was the emphasis of a report from control system security expert Eric Byres of British Columbia-based Byres Security in another presentation at the symposium. PLCs were not designed for security, said Byres. No sane IT department allows unprotected PCs or laptops, so why are PLCs immune?
When he was director of the Internet security lab at the British Columbia Institute of Technology, Byres started a program to design a micro-firewall for what he calls edge devices such as PLCs, field controllers, field instruments and final control elements.
There needs to be a shift in how we look at security, explained Byres. There have been dozens of cyber incidents in every process and manufacturing vertical, and the average cost of a malware incident is about $68,000, and the average sabotage cost is even higher.
Honeywell global security architect Kevin Staggs added that process safety and cyber security go hand-in-hand. Security is a key Honeywell initiative, said Staggs, and defense-in-depth is a key strategy for ensuring it.
Security is a journey, not a destination, explained Staggs. Honeywell is significantly engaged in standards committees like SP99 and SP100. Weve published a Networking and Security Planning Guide to help customers get up to speed on state-of-the-art procedures and practices as they implement their own security policies, said Staggs.
IT isnt the enemy, added Staggs. We need to learn from each other, he argued. Most IT practices can be applied directly, and those that cant must be discussed and negotiated into new practices that work in the process environment.
