An IoT security maturity model for IT/OT convergence

The top IoT security challenges

Before jumping into securing an IoT environment, it's important to understand the risks -- especially because they aren't necessarily the same risks standard IT environments face.

Sandy Carielli

One of the biggest challenges in securing IoT, Carielli said, is the convergence of IT and operational technology (OT) networks -- both the technology and the people running them. IT and security teams are used to being aligned, but bringing OT teams into the mix means there are new stakeholders to take into account.

"On the IT security side, we're used to operating in a certain way," Carielli said. "We're used to saying, 'One Sunday a month for a couple hours we're going to shut down and apply patches.' It's OK from an IT perspective, but those paradigms don't work for OT." Shutting down a plant or factory, even for a couple of hours on a Sunday, could cost millions of dollars in lost production. And shutting down utilities, such as a smart grid, simply isn't feasible.

"It's incumbent upon security folks to start to understand how operational technologies need to do business and how those may differ from what they're used to," Carielli said.

IT security teams must also accept the fact that OT system lifecycles are much longer than those of IT systems, Carielli noted. This introduces legacy and brownfield equipment and applications IT teams aren't familiar with -- some of which have been in place for decades.

Additionally, OT systems generally never connected to the internet in the past as they do today, so security wasn't built in from the start. Many industrial systems must be retrofitted with security controls -- which requires OT teams to adapt.

"Security teams need to be able to share information with the operational folks about the impact of security," Carielli said. "It's very much a two-way education street."

At this point, starting with the basics is key. "If the baseline that you're building upon hasn't been assessed and secured, and if you haven't really considered what the security risks and requirements are from the beginning, then you'll find yourself later having to go much deeper and undo plumbing -- that's not fun," she said.

How the 'IoT Security Maturity Model' fits in

When they set out to build a security maturity model, the Practitioner's Guide's authors knew they didn't have to reinvent the wheel. But while there is plenty of security guidance available, most models focus on either IT security or OT security -- not both. Either that, or guidance is industry-specific and can't easily be applied across wider applications.

"From a technology standpoint, a lot of the basic technical considerations are very similar -- thinking about data protection, access control, patch management," Carielli said. "Where I think there's additional thinking and complexity required is on the combination of IT and OT and looking at that holistically."

The goal in creating the IoT SMM and Practitioner's Guide, she said, was to create something that covered all the bases -- including procedures, supply chain and relationships with third parties -- and allowed organizations to go through the process of setting IT/OT security targets and measuring against them.

Determining your enterprise's IoT security maturity level

"I can imagine that looking at [the Practitioner's Guide] for the first time -- and even just asking the question of 'how secure do I need to be?' -- is daunting for any organization. That's what really drove us to create this," Carielli said.

To start off, she has a couple of pointers.

Before anything else, it's important to get all stakeholders -- business, operational, technical and security -- together to look at the different security practices listed in the maturity model to determine which your particular organization needs. This may include talking with employees that handle third-party vendors and supply chain partners.

Next, look at the top-level domains outlined in the IoT security maturity model -- governance, enablement and hardening -- and assess the maturity required for each in your company. From there, look at the subdomains -- for example, enablement includes the subdomains of identity and access management, asset protection and data protection. These break down further into practices -- for example, under identity and access management, the IIC guidance recommends practices including establishing and maintaining identities and access control.

"If you start with the three domains, then it starts to feel a little less daunting, and then you can dive down into the next level of detail if needed," Carielli said. "When we designed this, we created a hierarchy so that you can assess at different levels and roll it up if needed."

From here, the Practitioner's Guide suggests assigning a comprehensiveness level to each security domain, subdomain and practice. These range from Level 0, None, meaning no assurance or practices are applied, to Level 4, Formalized, where established, semiformal and formal methods are used.

Next, stakeholders can chart their current comprehensiveness levels and set security target goals. After targets are set, Carielli added, it's time to bring in assessors. Security assessors are instrumental in determining an organization's actual security levels, as well as the gaps between their current levels and target levels. Assessors can also help organizations decide which security mechanisms to prioritize.

From here, it's a continuous cycle of categorizing and improving.

"You can start to build out this assessment of where your current state is versus your target, and then you can build out your planning roadmap going forward," she said. "Then, periodically go through and say, 'OK, how do we have to advance our current state? How much closer are we to our target maturity?'"

Such an assessment, Carielli noted, may need to be done quarterly, biannually or annually.

The Practitioner's Guide offers templates to help organizations map their comprehensiveness levels, as well as any industry- or system-specific considerations. Filled-out sample templates are also included.

What's next for the IoT SMM?

There are three levels of scope in the IoT Security Maturity Model: Level 1, General; Level 2, Industry specific; and Level 3, System specific. The Practitioner's Guide focuses on the general.

In the next wave of IoT SMM publications, the IIC hopes to collaborate with industry groups to produce industry-specific profiles that provide industry- or system-level scope and map the IoT SMM to their frameworks. "Until those are place," Carielli said, "the challenge that implementers will face is having a consistent reference for industry-specific levels in the maturity model."

Carielli also said the IIC is expanding its stable of case studies -- the Practitioner's Guide offers three -- as well as considering training sessions to get assessors trained on the framework so they can integrate it into their own offerings.

Check out the "IoT Security Maturity Model: Practitioner's Guide" here.