This Security Maturity Model (SMM) provides a way of understanding the areas that impact security maturity by structuring the practices into the domains of governance, enablement, and hardening (think of governance, security by design and secure operations). Subdomains structure this more finely, into topics such as security program management, threat modeling, establishing and maintaining identities, physical protection, patch management and monitoring practice, to name only a few of the eighteen practices described in the Security Maturity Model (SMM) Practitioner’s Guide.
The Security Maturity Model (SMM) has a table for each of the 18 practices defining objectives, and the description, actions and indicators of accomplishment for the various maturity levels. These include minimum (1), ad hoc (2), consistent (3) and formalized (4). Importantly the model does not assume that a higher number is better, but rather describes a process toward achieving the right match to the needs and situation. The model also allows for extensibility to provide guidance for an industry or system, when appropriate to go beyond the general guidance. An example (to discuss in a different blog post) is the IoT SMM: Retail Profile for Point-of-Sale Devices which was developed jointly by the IIC SMM team and the OMG Retail Task Group.
There is much more to the IIC IoT Security Maturity Model (SMM) Practitioner’s Guide, such as discussion of the process of setting targets and performing an assessment.
This new version of the SMM improves the clarity and usefulness of the Practitioner’s Guide by adding new guidance to the numerous practice tables, clarifying scoring and the case studies, correcting minor errors and incorporating reader feedback, all without changing the underlying model.
When thinking about trustworthiness it is not enough to think of the trustworthiness of a component, be it hardware or software or a technology like AI, since trust in the outcome and the consequences depend on the entire system. This system consists of the organization and people who have accountability and maintain governance, the architecture, design, and technologies which must have sufficient quality, and the processes used that relate to the integrity and sustainability of the system.
A system also includes the external environment and all that it entails, including expectations, influence, rules, regulations and so on. As an example, privacy expectations can influence whether a system is viewed as trustworthy.
We rely on many systems to function and to do so safely and securely often without too much thought, whether it is utilities such as the electric grid, transportation such as airlines, automotive or rail travel, medical care or the delivery of goods. We normally expect and trust systems to “simply work”. Occasionally we are unpleasantly surprised such as with the fires in California and elsewhere leading to loss of electrical service after the event, planes crashing due to design issues, autonomous cars not negotiating lanes safety, or supply chains being disrupted.
We place enormous trust in the systems we rely upon. As these systems depend more and more on software to function it becomes essential to understand software and in particular how to have software that can be relied upon for a trustworthy system.
Trusting software requires confidence in the organization that produced it (“Do they do things in a way that inspires confidence? Does the leadership care about quality, safety, and so on or just profits? ” etc.), confidence in the actual products (“Was the airplane assembled properly or were incorrect bolts used?”), and confidence in the service associated with the system (“Is maintenance performed regularly and properly?”).
We have just published a new article on Software Trustworthiness Best Practices. In this paper we outline the entire lifecycle, including the importance of communicating and validating requirements, proper architecture and design, providing enough support for implementation and testing (including tools), validating, operating and decommissioning software. We also raise the value of software protection which is not always considered. The following diagram from the paper shows the lifecycle:
The paper includes practical discussions of issues such as software updates, end-of-life strategy and software protection – all topics that can be ignored when focused on software implementation. The appendix includes a software lifecycle checklist that should be helpful as well as some examples of failures related to software.
Software trustworthiness is essential to creating trustworthy systems and considerations of the topics and practices in the paper should help with the journey toward more trustworthy systems.
This IoT Security Maturity Model is timely, needed and new since it incorporates business, process, technology and operations aspects, and considers the security need from an integrated perspective including various contexts (end-end, device, edge, cloud, etc) and viewpoints such as information technology (IT) as well as Operational Technology (OT).
The IoT Security Maturity Model is a strategic document addressing the challenge of how to invest appropriately to address security needs and as a strategy provides an approach and model as well as actionable guidance. The need is to invest appropriately to address concerns, without investing too much or too little and by focusing in the areas that matter. The strategy is holistic, considering business, process, technology and operations.
An important concept is that of maturity. This is not the same as security levels, since it is about the degree of fit of the solution to the need. Thus if a situation does not require much security then even if few security mechanisms are applied the solution can be mature, since it is possible to demonstrate confidence that the correct approach has been taken.
The general approach is for business owners and technology owners to work together to set targets, then perform an assessment to determine the current state, identify and mitigate gaps, and then repeat this process periodically as threats, technologies and business concerns change. This creates a continuous improvement cycle.
The model has domains of governance (roughly process), enablement (technology) and hardening (operations) as well as the corresponding sub-domains and practices as shown in the following figure from the SMM:
Each domain, sub-domain and practice can have a comprehensiveness
level associated with it, indicating the depth and completeness of
that item, ranging from none, to minimal (1), ad hoc (2), consistent
(3) and formalized (4). In addition, the model is extensible to
address the needs of specific verticals (e.g. manufacturing, retail,
medical etc) through the use of scope, to enable specifics relative to
certain comprehensiveness levels to be defined. Scope also allows
system specifics as well. A set of comprehensiveness levels including
scope may be defined as an industry profile.
The IoT Security Maturity Model has a table for each of the eighteen practices, providing detail for each of the comprehensiveness levels, including an objective that can be used by business stakeholders, as well as a general description of the level, what needs to be done to achieve it, and indicators of accomplishment. Such indicators can be used to determine in an assessment if the level has been achieved.
The IoT Security Maturity Model includes examples drawn from different verticals for each of the practice comprehensiveness tables as well as case studies at the end. The case studies are based on real assessments that were done previously, recast into the IoT Security Maturity Model to demonstrate that it works for real cases as well as to provide examples that can be understood.
Best Practices from the IIC and elsewhere can be used to provide detailed guidance on addressing the gaps. We are also working on additional guidance in the form of mappings from IoT Security Maturity Model comprehensiveness levels to details in other frameworks like the IIC Security Framework, and IEC 62443, the NIST Cybersecurity Framework and others (e.g. comprehensiveness level 3 maps to this specific guidance). We also are looking to work with partners on creating profiles for verticals.
Thinking long term we have looked at how this model might also be
applicable to the concept of Trustworthiness, which includes security,
safety, reliability, resilience and privacy taken together and outlined
some thoughts on this in the IIC Journal of Innovation Trustworthiness
issue.
This post just introduces the IoT Security Maturity Model. For more complete details, definitions and explanations please refer to the Practitioner’s guide itself. If you would like to participate in further developing this work please join us at the IIC.
