Do you know how secure -- or mature -- your IoT ecosystem is? If not, you're not alone.
Fortunately, the Industrial Internet Consortium, now incorporating OpenFog, is here to help with its "IoT Security Maturity Model (SMM) Practitioner's Guide." A follow-up to IIC's 2018 release of "IoT SMM: Description and Intended Use," the new document offers tips to help enterprises align maturity models in their IoT environments, providing guidance for practitioners.
"It's the next level of detail that practitioners, assessors and others setting maturity targets can use to go through with a technical-process, fine-tooth comb and say, 'These are our business requirements and here's what that maps to in terms of where we need to be at for different security practices,'" said contributing author Sandy Carielli, director of security at Entrust Datacard.
Co-written by authors from Kaspersky Lab, Microsoft and RTI, the Practitioner's Guide aims to help enterprises overcome a major security challenge: Where to prioritize and focus their limited security budgets.
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.
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.
Internal versus external assessments
Opting for an internal or external assessment depends on many factors, but often comes down to resources. Some large enterprises have internal assessment organizations already doing vulnerability assessments and security architectures, while smaller businesses likely don't. However, Carielli noted that sometimes organizations perform an internal and external assessment.
"I'm not going to say one is better than the other; it really does depend on what resources you have at your disposal internally and externally," she said. "Maybe you have a great relationship with a vendor that is already coming in and doing security assessments for you every six months and you can add this to their backlog of things to do."
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.
Security level versus security maturity versus security maturity level
Per the IIC guidance, security level is "a measure of confidence that the system is free of vulnerabilities and functions in an intended manner." This involves looking at the tools and techniques the organization uses.
Security maturity is "the degree of confidence that the current security state meets all organizational needs and security-related requirements." For example, industrial controls in a smart manufacturing setting will have a different security profile and security needs than that of a smart lighting system.
Lastly, security maturity level is the "measure of the understanding of the current security level, its necessity, benefits and the cost of its support."
"It's about the understanding of the security requirements that are being tied to the business case and tied to the implementation -- and if you're really able to build out and secure an environment that makes sense for you," Carielli said.
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.