These documents help developers ensure that they’ve considered multiple threats and options while still implementing safeguards in a way that fits within their architectures.
ISA 99 is one of the earliest security specifications, and it’s become one of the most popular. It’s been certified by the International Electrotechnical Commission (IEC), which lets global companies use the same specification for all designs.
“When ISA 99 got international certification as IEC 62443, it really gave the standard a huge kick,” says Eric Byres, chief technology officer for Belden’s Tofino Security. “Companies don’t want to comply with standards for every country, so this was important.”
Several other groups provide advice on security. The National Institute of Standards and Technology (NIST) provides a number of documents for cryptography and other aspects of data protection. The National Industrial Security Program also provides guidelines that include techniques for removing data from unwanted equipment.
Many U.S. companies are using documents created by the North American Electric Reliability Corp. for electrical utility suppliers. Its critical infrastructure protection (NERC CIP) is seeing increased use in a range of industries that aren’t involved with distributing power.
“IEC 62443 is being widely looked at, if not adopted, in many automation processes,” says Dan Schaffer, business development manager, networking and security, at Phoenix Contact. “I’ve also seen a number of non-electric industries such as water and oil start to follow NERC CIP. I believe this is because NERC CIP is quite detailed about the dos and don’ts without doing a lot of navel-gazing or theorizing that other standards tend to have.”
Though standards provide helpful advice, using them doesn’t guarantee that a program will result in true security. Developers have to determine which aspects of a standard are needed and which don’t fit. Then they have to put them into production correctly.
“Standards are recommendations for best procedures,” says Gary Williams, technology manager of cybersecurity and communications at Invensys, now part of Schneider Electric. “If they’re implemented correctly, users will be able to link things together easily. These best practices give people guidance on what to do. They don’t specify every requirement.”
Design teams can just focus on the intent of the specifications, which is to protect networks and data, rather than on meeting the requirements of the standard. On the other hand, developers can sometimes conform to the specification without doing much to safeguard the network.
“There is potentially a big difference between being secure and being compliant,” Schaffer says. “A loose, poorly written or unclear section of a standard can be followed to the letter of the law but not really implement great security.”
Standards can be studied by hackers as well as by industry designers, but that doesn’t reduce the effectiveness of protective schemes designed using these specifications. Good designs and defense in depth can combine to safeguard networks—even if hackers are using the same standards and guidelines when they write malware.
“You don’t need to hide the way the system is designed: Knowing how a lock works doesn’t open every door,” Byres says. “A lot of people think secrecy is the key, but it’s not.”
Most technologists feel that that far more benefits than problems come with security standards. Some note that even when source code is readily available, hackers have trouble attacking end products.
“The good side of standards outweighs the bad,” says Carl Henning, deputy director for PI North America. “If you look at Linux, it’s an open standard. But you don’t hear much about Linux breaches.”
