Infrastructure stakeholders have a critical need to make sense of, comply with and, more importantly, make beneficial use of today's current and evolving cyber security standards. Differences in scope, goals, applicability, level of detail and an environment of constant change make this a challenge.
The overlap of various standards generated by separate organizations that have common objectives leads to trouble figuring out which standards best apply to particular needs. It can lead users who attempt to use these standards to conclude that the standards process itself doesn't work.
A Tuesday morning session at ABB Automation and Power World this week in Orlando did its best to present an understandable overview of the work being done via NERC-CIP and ISA99, and practical implementations of ideas generated by the Roadmap to Secure Control Systems in the Chemical Sector.
Four levels of security standards and regulations exist, some of which are enforced by regulatory authorities such as the North American Electrical Reliability Corporation (NERC). There also are baseline standards, not routinely enforced, that describe commonly accepted practices. Next come interoperability standards that attempt to minimize vendor-to-vendor product differences. Finally, there are the corporate standards that often add the particular details that individual companies require for implementation and internal compliance.
Tim Roxey, director of reliability assessment in NERC's technology division, explained that his agency "is not quite a regulator. We're not a federal group; not a private group. We're a 'tweener,' a not-for-profit funded by the load-serving entities that enforces the standards that the industry wrote for itself."
Roxey explained that the compliance section is extremely stringent and imposes penalties for violations of its standards. His area deals with security and the CIP-002 through 009 standards that deal with critical infrastructure protection. The various versions that have evolved and continue to evolve are focused on the need to more precisely describe a process to account for critical assets with minimal subjectivity. "The parts of version 2 that described how to identify a critical asset were replaced by ‘Here are your critical assets. Get rid of this subjectivity and go directly to the objective criteria,'" Roxey said.
Roxey provided a good example of why there's much work to be done to objectively identify critical assets. "Only about 10% of the entire bulk power system assets were identified as critical," remarked Roxey. "But after a critical outage, it turns out you need about 70% of the bulk power system back in service in order to drop on a service such as Manhattan, let alone all the others' interconnected loads. So how can only 10% of the assets be critical?" In addition, Roxey pointed to the work needed to fit industrial controls problems with IT solutions. "And that doesn't necessarily work so well." He encouraged a visit to the NERC web site at www.nerc.org.
Eric Cosman, engineering solutions IT consultant with Dow Chemical and co-chair of the ISA99 committee, explained that ISA99 is a series of standards designed to address industrial automation and control systems whose compromise could endanger public or employee safety, shake public confidence, violate regulatory requirements, lose proprietary or confidential information, create an economic loss or impact national security.
ISA99 applies manufacturing and control systems electronic security in the broadest possible sense, encompassing all types of plants, facilities and systems in all industries. "We cast a wide net because we didn't want to solely focus on hardware and software systems such as DCS, etc."
Cosman pointed out that to avoid this work becoming too internalized and cloistered, ISA99 links to a broad range of other standards groups, including the Microsoft Manufacturing Users Group, ISA 84 Safety, IEC and ISA100 Wireless. Roxey added that the ISA99 work is being used by the International Electrotechnical Commission in producing the multi-standard IEC 62443 series.
Reminding the audience that this is entirely a volunteer effort and while encouraging interested parties to review drafts and raise comment, Cosman said, "You'll get out of this effort as much as you put into it."
He noted that the Roadmap to Secure Control Systems in the Chemical Sector, published by the U.S. Department of Homeland Security Office of Infrastructure Protection and the National Cyber Security Division, builds on existing government and industry efforts to improve the security of industrial control systems owned and operated within the chemical sector. Members of the Chemical Sector Cyber Security Program's Industrial Automation and Control Systems (IACS) Working Group were among the cross-sector team of chemical sector stakeholders, government agencies and asset owners and operators that came together with a common set of goals and objectives to develop the roadmap.
"This is the voice of the chemical sector about what we need to do over the next 10 years," Cosman said. "It's for control system operators, security managers, engineers and IT personnel."
The roadmap gives an overview of the industrial control systems landscape and its need for ongoing attention from a security perspective. It also includes a vision for more secured industrial control systems in the chemical sector. The document also outlines recommended strategies and provides milestones to focus specific efforts and activities for achieving its vision over the next 10 years, addressing the chemical sector's most urgent challenges, longer-term needs, and practices that may help reduce IACS risks. Implementation of the roadmap will be a major focus area for industrial automation and control systems experts in the chemical industry moving forward. More information is available via www.us-cert.gov/control_systems.
Moderator Ragnar Schierholz of ABB Corporate Research closed the session with a reminder that the audience look to its industry associations' cyber security activity for guidance, and echoed earlier remarks: "Just because you're compliant doesn't mean you're safe. Compliance for the sake of compliance by just ticking off boxes, but not living that policy doesn't give you any security. But on the reverse side, if you do cyber security right, usually compliance is only a matter of documentation."
