What does it take to secure industrial IoT endpoints? To start, read 13 pages. That's what makes up the Industrial Internet Consortium's "Endpoint Security Best Practices," the first of a six-part follow-up series to the IIC's 2016 Industrial Internet Security Framework.
Combining key industrial IoT security guidance and compliance frameworks, including IEC 62443 and NIST SP 800-53, the new paper distills thousands of pages into something Dean Weber, CTO at Mocana Corporation, said is as close to plain English as possible for everyone from industrial plant owners and operators to systems integrators, manufacturers, policymakers, insurers and certifying organizations to understand.
Achieving industrial IoT security
The "Endpoint Security Best Practices" document, authored by Weber, Steve Hanna, senior principal at Infineon Technologies AG, and Srinivas Kumar, VP of engineering at Mocana, outlines security architectures for three different levels of industrial security and lays out the security requirements for each level.
At the low-risk "basic" level, secure communications, cryptographic services, secure boot, endpoint identity and root of trust are key.
"The basic level is what you would be looking to put into a system which is not critical to the operation of your industrial plant and where there aren't any safety concerns," Hanna said. "There might be some reliability concerns, but the impact of a system getting hacked would be fairly low."
The enhanced level takes it a few steps further, adding endpoint configuration and management. And at the high-risk "critical" level, security information and event management, as well as policy and activity dashboards are included.
The critical level, Hanna said, includes those systems that can't take any risk, as there could be a major safety or financial impact if they went down.
Challenges of IIoT security
Industrial IoT security may seem easy laid out in the IIC's "Endpoint Security Best Practices" 13-page document, but Weber noted several challenges -- or perceived challenges -- that prevent proper security, the first being the sheer scale of IIoT.
"When you think about every meter, every gravitometer, every accelerometer, every density function, every magnetometer ... the number of sensors rolling up into the number of [programmable logic controllers] rolling up into the number of ICS SCADA control systems is humongous," Weber said. Discovering, approving, inventorying and managing all of these endpoints can be daunting.
Another challenge? The physical location of IIoT devices.
"One of the reasons people are concerned is they can't get out to these systems, they aren't physically addressable," Weber said. "Plus, they may not be on the network for more than a couple of milliseconds every month, or they may be in network segments that are not easily addressable from a centralized location."
Communications and standardization is another issue. There are no single internet connectivity or communications standards in the industrial world, and a not a clear winner in sight. Networks and protocols are so wide-ranging in the nascent IIoT market, moving to a connected environment -- and ensuring endpoints, networks, control systems, and reporting and logging are on the same page -- can seem like a lot of work.
"One of the things we're proposing is that new communications systems associated with enrollment need to be delivered," Weber said. "There are a number of different systems out there that can work in this environment, and there's a whole new series of protocols associated with the distribution and management of certificates on these devices. Otherwise we're going to end up with a very proprietary solution model whereby one manufacturer is going to choose one method, another manufacturer chooses another method and there won't be a lot of interoperability between the elements in terms of the identification and authorization components."
The state of industrial IoT security today
"You can see pretty clearly by taking a look at, for example, the ISASecure website, that there are manufacturers that are putting some effort into securing their endpoints. Generally, they're [programmable logic controllers]," Infineon's Hanna said. However, the level manufacturers are securing devices to on ISA Secure -- IEC 62443 level 1 -- is at the most primitive security level. "It's designed to make sure that you don't shoot yourself in the foot," he added, saying it was comparable to using shared passwords across a plant. And, according to Hanna, only one endpoint on ISASecure has been certified to level 2.
"Industrial equipment manufacturers are striving for higher levels of security," Hanna said, "And they should be praised, not mocked. But they are not even close to having achieved a higher level."
So, how hard will it be for manufacturers to get to the desired higher level of IIoT security?
"We're talking about fundamental capabilities, like having a unique identity for each endpoint, using cryptographic algorithms to authenticate and communicate securely, doing secure root," Hanna said. "These are all techniques that are used in all of our mobile phones today. Taking that level of security and carrying it over to an industrial plant, it's not asking too much. Even the higher levels aren't an extraordinary reach. But certainly the basic level is easily achievable in most industrial endpoints today."
One advantage, Weber added, is that most plant networks today have already been built to be safe and reliable. "Adding a cybersecurity component to them, while sometimes onerous to the safety and reliability folks, is really the third leg of the stool," Weber said. "It's not that difficult. The difficult part is just understanding the volumes of information that are out there."
Certainly, reading the hundreds of pages of IEC 62443, NIST SP 800-53 and IIC's IISF may not be the easiest of tasks, let alone discerning which industrial IoT security bits and pieces are applicable to a plant's particular situation. Hence the creation of the six IIC white papers, the other five of which include topics such as security and configuration management, communication and connectivity protection and data protection.
"The purpose of this is for people that begin the process, not the end game," Weber said. "You still have to go out and actually attribute the secure attestation of whatever element it is that you're trying to say is valid. But this at least gets you in the ballpark of 'How does this thing actually make me secure?' ... 'How does this help me with my compliance or regulatory validation efforts?' -- And really that's what we tried to do."
Need more info? Just check out the footnotes the IIC's "Endpoint Security Best Practices" -- Hanna said, "It includes lots and lots of footnotes" -- to find the associated sections of the IEC or NIST publications where you can find details and justifications for the requirements.