How Shell E&P assesses and addresses control system security risks

June 13, 2007
Dan McDougall of Shell Exploration and Production speaks about the company’s drive to ensure security of its global assets at the Honeywell User Group Americas 2007 Symposium in Phoenix.
Closely tied to Shell’s current Smart Field initiative--to continuously optimize oil and gas production and recovery--is the company’s drive to ensure security of its global assets, began Dan McDougall of Shell Exploration and Production in his address this morning to the Honeywell User Group Americas 2007 Symposium.

“Enterprise IT security doesn’t work unless everybody follows the same rules from Brunei to the Gulf of Mexico to Europe,” he said. “But in the process control domain, we have more flexibility because we have that firewall between the process and the corporate environment.”

In order to better communicate the relative importance of control system security to asset managers, Shell links its security assessments to the overall issue of technical integrity, McDougall explained, including risk assessment and management; defense-in-depth, with accountability at the asset level; and embedded audit and review processes.

“We are talking about a different kind of integrity than the enterprise IT people are, so we have to explain what we mean, and then they get it,” McDougall added. “There’s about an 80% overlap between what the IT guys have done and what we’ve done, but that 20% difference is critical, and makes or breaks your process.”

McDougall’s recommendations for any control system security project start with getting management buy-in early. Translate the issue at hand into business language, using risk assessments for specifics and linking the project justification to technical integrity (process safety) processes. “When talking to management, highlight exposures, but don’t overstate, because emotion and fear leads to poor business decisions,” McDougall said. “Companies deal with risk everyday, and asset managers understand how to prioritize it.”

Be explicit in security requirements, McDougall added, using external standards as a guide and making the scope of security requirements clear. “Engineering, IT and operations all need to be involved, and we’ve found it essential to ensure all parties understand their responsibilities and boundaries.”

“Remember that only about 20% of the scope is technology—the remainder is governance, people and procedures,” McDougall concluded. Above all, link security to business value, and do it in stages. “If you go for too much too fast, you’ll scare them off.”