We’ve just published an update to our previous IoT Security Maturity Model (SMM) 62443 mappings publication, adding the service provider role. Please see the press release for some details and the previous blog post for an introduction.
This joint work of the Industry IoT Consortium (IIC) and the International Society of Automation (ISA) extends the previous work to complete the mappings.
This document extends our previously published technical report, the IoT Security Maturity Model (SMM): Practitioner’s Guide. That document describes the principles and process for setting targets and assessments for security maturity, breaking down the expanse of security concerns into eighteen practices in the three domains of governance, enablement and hardening. These practices include governance, technical and non-technical controls and operational aspects. This is shown in the following diagram from the Practitioner’s Guide:
Each practice description gives information and guidance on the four comprehensiveness levels of minimum (1) , ad hoc (2), consistent (3) and formalized (4) with descriptions of each, including what needs to be done to achieve the level, and indicators of accomplishment (useful for assessments). A key idea is that unlike other maturity models, higher levels are not necessarily better. Rather, the appropriate comprehensiveness level for each practice should be chosen to match the need, limiting investment to what is required and makes sense.
The SMM is designed to be extensible, with profiles that expand the scope to industry or system specifics, and with mappings that relate the guidance to other frameworks and requirements.
Profiles are one way of extending the SMM Security Maturity Model. While the practitioner’s guide describes the general case, or general scope, it also permits guidance appropriate to industry or system specific scope to be added to the general guidance. For example, we have previously published in collaboration with the OMG the IoT SMM: Retail Profile for Point-of-Sale Devices offering additional guidance relevant to retail. It includes industry scope level guidance, such as using Data Security Standard (PCI-DSS), Payment Application Data Security Standard (PA- DSS), and the PIN Transaction Security Devices (PTS) to achieve the consistent comprehensiveness level (level 3) for the compliance management practice, to give an example. It also includes device scope guidance for the compliance management level 3 with the requirement to ensure compliance with PIN Transaction Security Devices.
Another way of extending the SMM is with mappings. This newest publication is a set of mappings to the 62443 standards. This provides a linkage between the guidance for a specific comprehensiveness level in a practice to related 62443 requirements. One way to use this is to determine the maturity target, setting comprehensiveness levels for each practice using the Practitioner’s Guide for guidance. Once this is done then the mappings for the appropriate comprehensiveness levels (and the lower ones which must also be met to achieve a comprehensiveness level) can be used to review the appropriate 62443 requirements.
The current 62443 mappings focus on the needs of Asset Owners and Product Suppliers as defined in that document, a subsequent revision will add service providers. The following diagram from the mappings publication (derived from ISA documentation) shows the roles:
We are working on a later update to add Service Providers to the mappings document.
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.