IoT Security Maturity Model:
Practitioner’s Guide
Version 1.0
2019-02-25

IoT SMM Practitioner’s Guide

Acknowledgements

Copyright © 2019, Industrial Internet Consortium, now incorporating OpenFog, a program of
Object Management Group, Inc. (“OMG”).

ACKNOWLEDGEMENTS
Security Applicability Task Group, co-chaired by Ron Zahavi (Microsoft) and James Clardy (NetFoundry), which is a subgroup of the Security Working Group co-chaired by Sven Schrecker (LHP
Engineering Solutions) and Jesus Molina (Waterfall Security Solutions).
EDITORS
Sandy Carielli (Entrust Datacard), Frederick Hirsch (Fujitsu), Ekaterina Rudina (Kaspersky), Ron
Zahavi (Microsoft).
AUTHORSThe following persons contributed substantial written content to this document:
Sandy Carielli (Entrust Datacard), Matt Eble (Praetorian), Frederick Hirsch (Fujitsu), Ekaterina
Rudina (Kaspersky), Ron Zahavi (Microsoft).
CONTRIBUTORSThe following persons contributed valuable ideas and feedback that significantly improved thecontent and quality of this document:
Marcellus Buchheit (Wibu-Systems).
TECHNICAL EDITOR
Stephen Mellor (IIC staff) oversaw the process of organizing the contributions of the above
Editors, Authors and Contributors into an integrated document.

IIC ISSUE REPORTING
All IIC documents are subject to continuous review and improvement. As part of this process, we
encourage readers to report any ambiguities, inconsistencies or inaccuracies they may find in thisDocument or other IIC materials by sending an email to admin@iiconsortium.org.

2019-02-25- ii -

Version 1.0

IoT SMM Practitioner’s Guide

Contents

CONTENTS
1 Overview ............................................................................................................................ 8
1.1

Relationship with Other IIC documents ................................................................................. 8

Part I: Model
2 The Security Maturity Model .............................................................................................. 9
2.1
2.2
2.3
2.4
2.5

Security Maturity vs. Security ................................................................................................ 9
Requirements ..................................................................................................................... 10
Scope .................................................................................................................................. 10
Audience ............................................................................................................................. 11
Relationship to Other Models and Frameworks ................................................................... 11

3 Domains, Subdomains & Practices .................................................................................... 12
3.1
3.2
3.3

Comprehensiveness Levels .................................................................................................. 14
Scope Levels ........................................................................................................................ 14
Visualizing the Level Values ................................................................................................. 15

4 Template .......................................................................................................................... 15
4.1
4.2

Extensibility ........................................................................................................................ 16
Extending the Practices ....................................................................................................... 16

5 Process for Applying the Model ........................................................................................ 21
5.1
5.2
5.3
5.4
5.5

Establishing the Context ...................................................................................................... 21
Creating the Security Maturity Target ................................................................................. 22
Determining the Comprehensiveness Levels........................................................................ 22
Determining the Scope ........................................................................................................ 24
Checking for Consistency of the Security Maturity Target .................................................... 25

6 Conducting a Security Maturity Assessment ..................................................................... 27
6.1
6.2
6.3
6.4
6.5
6.6

Achieving a Level ................................................................................................................. 28
Performing Gap Analysis ..................................................................................................... 29
Planning the Roadmap ........................................................................................................ 31
Making Security Enhancements ........................................................................................... 32
Continuous Improvements .................................................................................................. 32
Subsystems ......................................................................................................................... 33

Part II: The Core of The Security Maturity Model
7 Governance Domain ......................................................................................................... 34
7.1

Strategy and Governance Subdomain .................................................................................. 34
7.1.1
Security Program Management Practice .......................................................................... 34
7.1.2
Compliance Management Practice ................................................................................... 37
7.2 Threat Modeling and Risk Assessment Subdomain .............................................................. 39
7.2.1
Threat Modeling Practice.................................................................................................. 39
7.2.2
Risk Attitude Practice ........................................................................................................ 41
7.3 Supply Chain and External Dependencies Management Subdomain .................................... 43
7.3.1
Product Supply Chain Risk Management Practice ............................................................ 43
7.3.2
Services Third-Party Dependencies Management Practice .............................................. 45

2019-02-25- iii -

Version 1.0

IoT SMM Practitioner’s Guide

Contents

8 Enablement Domain ......................................................................................................... 47
8.1

Identity and Access Management Subdomain ..................................................................... 47
8.1.1
Establishing and Maintaining Identities Practice .............................................................. 47
8.1.2
Access Control Practice ..................................................................................................... 49
8.2 Asset Protection Subdomain ............................................................................................... 51
8.2.1
Asset, Change and Configuration Management Practice ................................................. 51
8.2.2
Physical Protection Practice .............................................................................................. 54
8.3 Data Protection Subdomain ................................................................................................ 56
8.3.1
Protection Model and Policy for Data Practice................................................................. 56
8.3.2
Implementation of Data Protection Practices Practice .................................................... 59

9 Hardening Domain ............................................................................................................ 62
9.1

Vulnerability and Patch Management Subdomain ............................................................... 62
9.1.1
Vulnerability Assessment Practice .................................................................................... 62
9.1.2
Patch Management Practice ............................................................................................. 65
9.2 Situational Awareness Subdomain ...................................................................................... 67
9.2.1
Monitoring Practice .......................................................................................................... 67
9.2.2
Situational Awareness and Information Sharing Practice ................................................ 69
9.3 Event and Incident Response, Continuity of Operations subdomain .................................... 71
9.3.1
Event Detection and Response Plan Practice ................................................................... 71
9.3.2
Remediation, Recovery and Continuity of Operations Practice ....................................... 74

Part III: Comprehensiveness Level Definition Guide
10 Comprehensiveness Level Definition Guide ...................................................................... 76

Part IV: Case Studies
11 Case Study Approach ........................................................................................................ 83
11.1
11.2
11.3
11.4

Case Study Background and Problem Description ................................................................ 83
Factors to Consider in the Case Study System Analysis ........................................................ 83
Prioritizing the Security Domains ........................................................................................ 84
Validating the Security Needs for Subdomains and Practices ............................................... 85

12 Case Study 1: Smarter Data-Driven Bottling Line ............................................................... 87

12.1 Background, Problem Description and Approach Using SMM .............................................. 87
12.2 Factors to Consider in the Case Study System Analysis ........................................................ 87
12.3 Prioritizing the Security Domains ........................................................................................ 88
12.4 Considering the Security Needs for Subdomains .................................................................. 89
12.4.1 Security Needs for Governance ........................................................................................ 89
12.4.2 Security Needs for Enablement ........................................................................................ 90
12.4.3 Security Needs for Hardening ........................................................................................... 90
12.5 Validating the Purpose of Security Practices ........................................................................ 91

13 Case Study 2: Automotive Gateway Supporting OTA Updates........................................... 98

13.1 Background, Problem description and Approach using SMM ............................................... 98
13.2 Factors to Consider in the Case Study System Analysis ........................................................ 98
13.3 Prioritizing the Security Domains ........................................................................................ 99
13.4 Considering the Security Needs for Subdomains ................................................................ 100
13.4.1 Security Needs for Governance ...................................................................................... 100

2019-02-25- iv -

Version 1.0

IoT SMM Practitioner’s Guide

Contents

13.4.2 Security Needs for Enablement ...................................................................................... 101
13.4.3 Security Needs for Hardening ......................................................................................... 101
13.5 Validating the Purpose of Security Practices ...................................................................... 102

14 Case Study 3: Consumer (Residential) Security Cameras ..................................................110

14.1 Background, Problem Description and Approach using SMM ............................................ 110
14.2 Factors to Consider in the Case Study System Analysis ...................................................... 110
14.3 Prioritizing the Security Subdomains ................................................................................. 111
14.4 Considering the Security Needs for Subdomains ................................................................ 112
14.4.1 Security Needs for Governance ...................................................................................... 112
14.4.2 Security Needs for Enablement ...................................................................................... 113
14.4.3 Security Needs for Hardening ......................................................................................... 113
14.5 Validating the Purpose of Security Practices ...................................................................... 114
14.6 Defining Next Steps and Roadmap .................................................................................... 119

Part V: Annexes
Annex A Revision History ....................................................................................................120
Annex B Acronyms .............................................................................................................121
Annex C Glossary ................................................................................................................122
Annex D References ............................................................................................................124
Index ....................................................................................................................................125
Authors and Legal Notice......................................................................................................127

Use of Information—Terms, Conditions and Notices ................................................................... 127

FIGURES
Figure 3-1: IoT Security Maturity Model Hierarchy.................................................................................. 13
Figure 3-2: Visualization of two-dimensional approach in measuring security maturity ........................ 15
Figure 5-1: IoT Security Maturity Model Process ..................................................................................... 21
Figure 5-2: Subdomain Consistency Check, reducing Subdomain value .................................................. 23
Figure 5-3: Subdomain Consistency Check, increasing Subdomain value ............................................... 24
Figure 6-1: States and transitions between the comprehensiveness and scope levels for security
practices ................................................................................................................................. 28
Figure 6-2: Gap Analysis for Security Maturity Target ............................................................................. 30
Figure 6-3: Gap Analysis for Security Maturity Target ............................................................................. 30
Figure 6-4: Gap Analysis for Security Maturity Target ............................................................................. 31
Figure 6-5: SMM Improvement Cycle ...................................................................................................... 33
Figure 12-1: Initial target values for security domains............................................................................... 89

2019-02-25-v-

Version 1.0

IoT SMM Practitioner’s Guide

Contents

Figure 12-2: Refined target values for security subdomains ..................................................................... 91
Figure 12-3: Target values for the Security Practice .................................................................................. 94
Figure 12-4: Validated security maturity target at the level of security domains ..................................... 95
Figure 12-5: Validated security maturity target at the level of security subdomains................................ 96
Figure 13-1: Initial target values for security domains for the Automotive Gateway Supporting OTA
Updates case study .............................................................................................................. 100
Figure 13-2: Refined target values for security subdomains for the Automotive Gateway Supporting OTA
Updates case study .............................................................................................................. 102
Figure 13-3: Target values for the Security Practices for the Automotive Gateway Supporting OTA
Updates case study .............................................................................................................. 106
Figure 13-4: Validated security maturity target at the level of security domains for the Automotive
Gateway Supporting OTA Updates case study .................................................................... 107
Figure 13-5: Validated security maturity target at the level of security subdomains for the Automotive
Gateway Supporting OTA Updates case study .................................................................... 108
Figure 14-1: Initial target values for security domains for the Consumer Security Cameras case study 112
Figure 14-2: Initial target values for security subdomains for the Consumer Security Cameras case study.............................................................................................................................................. 114
Figure 14-3: Target values for the Security Practices for the Consumer Security Cameras case study ... 117
Figure 14-4: Refined values for the Subdomains for the Consumer Security Cameras case study ......... 118
Figure 14-5: Refined values for the Domains for the Consumer Security Cameras case study ............... 119

TABLES
Table 4-1:

SMM Table Template ............................................................................................................. 16

Table 4-2:

SMM Table Template with industry and system specific considerations .............................. 17

Table 4-3:

SMM Table Template with industry and system specific description and indicators ........... 18

Table 4-4:

SMM Practice Table Example ................................................................................................. 20

Table 7-1:

Security Program Management ............................................................................................. 36

Table 7-2:

Compliance Management ...................................................................................................... 38

Table 7-3:

Threat Modeling ..................................................................................................................... 40

Table 7-4:

Risk Attitude ........................................................................................................................... 42

Table 7-5:

Product Supply Chain Risk Management ............................................................................... 44

Table 7-6:

Services Third-Party Dependencies Management ................................................................. 46

2019-02-25- vi -

Version 1.0

IoT SMM Practitioner’s Guide

Contents

Table 8-1:

Establishing and Maintaining Identities ................................................................................. 48

Table 8-2:

Access Control ........................................................................................................................ 50

Table 8-3:

Asset, Change and Configuration Management .................................................................... 53

Table 8-4:

Physical Protection ................................................................................................................. 55

Table 8-5:

Protection Model and Policy for Data .................................................................................... 58

Table 8-6:

Implementation of Data Protection Practices ....................................................................... 61

Table 9-1:

Vulnerability Assessment ....................................................................................................... 64

Table 9-2:

Patch Management ................................................................................................................ 66

Table 9-3:

Monitoring ............................................................................................................................. 68

Table 9-4:

Situational Awareness and Information Sharing ................................................................... 71

Table 9-5:

Event Detection and Response Plan ...................................................................................... 73

Table 9-6:

Remediation, Recovery and Continuity of Operations .......................................................... 75

Table 10-1: Comprehensiveness Level Definition Guide .......................................................................... 76
Table 10-2: Comprehensiveness Level Definition Guide .......................................................................... 78
Table 10-3: Comprehensiveness Level Definition Guide .......................................................................... 82
Table 12-1: Created security maturity target summary........................................................................... 97
Table 13-1: Created security maturity target summary ......................................................................... 109

2019-02-25- vii -

Version 1.0

IoT SMM Practitioner’s Guide

1: Overview

1 OVERVIEWIn April 2018 the Industrial Internet Consortium (IIC) published the first of two documents
relating to the IoT Security Maturity Model. The first document, IoT Security Maturity Model:
Description and Intended Use 1, is for stakeholders to understand the purpose, need and intent
of the model. This second document, the practitioner’s guide, provides the model’s details anddescribes how it is to be used.
The IoT Security Maturity Model (SMM) enables Internet of Things (IoT) providers to set security
targets and invest in security mechanisms that meet their requirements, without over-investingin unnecessary security mechanisms. Security maturity is a measure of the understanding of thecurrent security level, its necessity, benefits and cost of its support.
The SMM provides a conceptual framework to help organizations select and implement theappropriate security controls from the myriad options. It helps an organization determine what
their security maturity target state should be and assess their current state. Repeatedly
comparing the target and current states identifies where further improvement can be made.

1.1

RELATIONSHIP WITH OTHER IIC DOCUMENTS

We rely on the concepts discussed in the Industrial Internet Reference Architecture (IIRA) 2 andthe Industrial Internet Security Framework (IISF) 3.
The IISF captures the information technology (IT) and operational technology (OT) dimensions ofindustrial internet of things security and describes security domains and various techniques. This
document offers an additional dimension to the concepts, security techniques and mechanisms
described there. The SMM addresses IT and OT systems and systems that reside at the endpoint,on the network or in the cloud, providing guidance on the maturity required to address specific
IoT scenarios and the mechanisms to use to achieve that maturity.
The IIC Vocabulary 4 provides terminology and definitions for all IIC documents. Acronyms andadditional terms relevant to this model are defined in the appendices.
We recommend that both business and technical stakeholders review the first document, IoT
Security Maturity Model: Description and Intended Use 5 before tackling this document, the IoT
Security Maturity Model: Practitioner’s Guide.

See [IIC-SMMD2019]
See [IIC-IIRA2017]3
See [IIC-IISF2016]
4
See [IIC-IIV2018]5
See [IIC-SMMD2019]1
2

2019-02-25-8-

Version 1.0

IoT SMM Practitioner’s Guide

2: The Security Maturity Model

Part I: Model
2 THE SECURITY MATURITY MODEL
There is no silver bullet that can address security needs for every system. Organizations havediffering needs, and different systems need different strengths of protection mechanisms. The
same technology can be applied in different ways and to different degrees, depending on needs.
The SMM helps organizations determine the priorities that drive their security enhancements
and the maturity required to achieve them.
The model fosters effective and productive collaboration among business and technicalstakeholders. Business decision makers, business risk managers and owners of IoT systems,
concerned about proper strategy for implementing mature security practices, can collaborate
with the analysts, architects, developers, system integrators and other stakeholders who areresponsible for the technical implementation.
To drive proper investment, the IoT Security Maturity Model includes both organizational andtechnological components. Organizations use the model to set their target maturity, understandtheir current maturity and determine what they need to do to move to a higher maturity state.

2.1

SECURITY MATURITY VS. SECURITY

Maturity is about effectiveness, not the arbitrary use of mechanisms. The SMM aligns thecomprehensiveness (degree of depth, consistency and assurance of security measures) andscope (degree of fit to the industry or system needs) of security needs with the investment inappropriate practices.
Not all systems require the same strength of protection mechanisms or procedures to meet theirsecurity requirements. The organizational leadership determines the priorities that drive thesecurity enhancement process, making it possible for the mechanisms and procedures to fit theorganization’s goals without going beyond what is necessary. The implementations of security
mechanisms and processes are considered mature if they are expected to be effective in
addressing those goals. It is the security mechanisms’ appropriateness in addressing the goals,
rather than their objective strength, that determines the maturity. Hence, security maturity is
the degree of confidence that the current security state meets all organizational needs andsecurity-related requirements, and security maturity is a measure of the understanding of thecurrent security level, its necessity, benefits and cost to support. Factors to weigh include thespecific threats to an organization's industry vertical, regulatory and compliance requirements,
the organization's threat profile and the unique risks present in an environment.
Security level, 1 on the other hand, is a measure of confidence that system vulnerabilities are
addressed appropriately and that the system functions in an intended manner. The SMM does
not say what the appropriate security level should be. Rather, it provides guidance and structure
1

According to the IEC 62443 3-3

2019-02-25-9-

Version 1.0

IoT SMM Practitioner’s Guide

2: The Security Maturity Modelfor organizations to select the maturity appropriate for their industry and system. Some users
will apply the model to create industry- and system-specific profiles, which a broader audiencecan then use to assess maturity in a specific vertical or use case.

2.2

REQUIREMENTS

When developing the SMM, the authors were guided by the following requirements.
Real-world applicability: The method for setting the security maturity target must consider
functionality, safety, regulatory and legal requirements or guidelines, risk management, security
and privacy policies, performance, costs and other business considerations. It must also consider
known and emerging threats and affordable ways of countering them. The outcome of theprocess and the guidance for attaining the target should be directly applicable to the IoT
infrastructure in question and therefore be actionable.
Consideration of different perspectives: The SMM facilitates a description of security maturity
from different viewpoints including business and implementation views. It helps define security
maturity goals from an organizational perspective and security maturity requirements from animplementation perspective. The model helps align these definitions and thus drive collaboration
among all stakeholders who are working towards security maturity enhancement.
Appropriate security guidance: The SMM provides guidance for the assessment and further
enhancement of security maturity that aligns security capabilities with a particular use case.
Guidance should be practical and actionable.
Adaptable to changing threat environment: As infrastructure and threats evolve, the security
target must be adaptable (e.g. firmware updates or patching) to remain relevant in the long run.
It is insufficient to implement security measures only at the system design stage for systems withlong operational lifespans.
Extensibility: IoT business models, products, guidelines, regulations, technologies and types oforganizations will evolve. The SMM needs to be flexible enough to accommodate any changes.

2.3

SCOPE

The SMM explains how security practices may be aligned with existing security concerns in an
effective way. It provides the classification and detailed description of security practices, criteria
for their security maturity, relevant security concerns, techniques and capabilities, allowing forthe assessment and planning of their implementation according to the established strategy. It
also provides recommendations on the process for this assessment and implementation.
The details and recommendations are based on the strategic approach built during thecollaborative work of security engineers and business risk owners. This approach is defined by
the IoT Security Maturity Model: Description and Intended Use 1. The practitioner’s guide does1

See [IIC-SMMD2019]2019-02-25- 10 -

Version 1.0

IoT SMM Practitioner’s Guide

2: The Security Maturity Model

not focus on the development of the strategy itself, relying on it as input into the process definedby this document.

2.4

AUDIENCE

The audience for this document includes:
Security practitioners responsible for their organization’s systems. Practitioners translatemanagement objectives into the appropriate level of target security maturity.
Security assessment professionals, both internal to the organization, or independent third
parties, who conduct current state assessments using the model and identify gaps between thecurrent and target states.
Industry groups that will extend the model in industry- and system-specific ways.
Users of this SMM should be able to determine and clearly communicate the answers to thesequestions:
•
•
•

2.5

Given the organizational requirements and threat landscape, what is my solution’s target
maturity state?
What is my solution’s current maturity state?
What are the mechanisms and processes that will take my solution’s maturity from its
current state to its target state?

RELATIONSHIP TO OTHER MODELS AND FRAMEWORKS

This IoT Security Maturity Model is the first model of its kind to assess the maturity oforganizations’ IoT systems in a way that includes governance, technology and systemmanagement. Other models address part of what is addressed by the SMM: they may address aparticular industry, IoT but not security, or security but not IoT. The SMM covers all these aspects
and points to existing models to recognize existing work and avoid duplication.
Many related frameworks focus on security levels and security controls required to meet thoselevels. IIC will provide associated mappings between the SMM and the most popular frameworks.
This will help practitioners identify which controls to implement as they plan to address gaps
between current and target security maturity states.
The model fosters effective and productive collaboration among business and technicalstakeholders. Business decision makers, business risk managers and operational users of IoT
systems, concerned about proper strategy for implementing mature security practices, cancollaborate with the analysts, architects, developers, system integrators and other stakeholders
who are responsible for the technical implementation.

2019-02-25- 11 -

Version 1.0

IoT SMM Practitioner’s Guide

3: Domains, Subdomains & Practices

3 DOMAINS, SUBDOMAINS & PRACTICESThe domains of governance, enablement and hardening determine the priorities of security
maturity enhancements at the strategic level. Governance influences and informs every security
practice including business processes, legal and operational issues, reputation protection andrevenue generation. Enablement uses architectural design to address business risks, andhardening defines countermeasures to deal with specific threats before and after the fact. The
subdomains reflect the means of obtaining the priorities at the planning level, and practices
define typical activities associated with subdomains and identified at the tactical level. Figure 31 displays the hierarchy of the model displaying the domains, the associated subdomains andtheir practices.

2019-02-25- 12 -

Version 1.0

IoT SMM Practitioner’s Guide

Figure 3-1:

3: Domains, Subdomains & Practices

IoT Security Maturity Model Hierarchy

There are two orthogonal dimensions to the evaluation of the security maturity:
comprehensiveness and scope. Comprehensiveness captures the degree of depth, consistency
and assurance of security measures that support security maturity domains, subdomains orpractices. For example, a higher level of comprehensiveness of threat modeling implies a more
automated systematic and extensive approach. Scope reflects the degree of fit to the industry or
system needs. This captures the degree of customization of the security measures that support
security maturity domains, sub domains or practices. Such customizations are typically required
to address industry-specific or system-specific constraints of the IoT system.
Comprehensiveness and scope help score and prioritize security maturity practices. Certain
systems may not require the highly sophisticated or narrowly scoped implementation of all
security practices. Such implementation may be over-engineered, given the particular system

2019-02-25- 13 -

Version 1.0

IoT SMM Practitioner’s Guide

3: Domains, Subdomains & Practices

and the threats that it faces. The security maturity of the system should be determined against
the requirements that best meet its purpose and intended use.

3.1

COMPREHENSIVENESS LEVELS

There are five comprehensiveness levels for every security domain, subdomain and practice,from Level 0 to Level 4, with larger numbers indicating a higher degree of comprehensiveness.
Every comprehensiveness level covers all the requirements set by the lower levels, augmenting
them with additional ones.
Level 0, None: There is no common understanding of how the security practice is applied and no
related requirements are implemented (as this level has no assurance or practices applied, we
do not discuss it further).
Level 1, Minimum: The minimum requirements of the security practice are implemented. There
are no assurance activities for the security practice implementation.
Level 2, Ad hoc: The requirements for the practice cover main use cases and well-known security
incidents in similar environments. The requirements increase accuracy and level of granularity
for the environment under consideration. The assurance measures support ad hoc reviews of thepractice implementation to ensure baseline mitigations for known risks. For this assurance, one
may apply measures learned through successful references.
Level 3, Consistent: The requirements consider best practices, standards, regulations,classifications, software and other tools. The tools establish a consistent approach to practice
deployment. The assurance validates the implementation against security patterns, secure-bydefault designs and known protection approaches and mechanisms.
Level 4, Formalized: A well-established process forms the basis for practice implementation,
providing continuous support and security enhancements. The assurance of the implementation
focuses on the coverage of security needs and timely addressing of issues that appear to threaten
the system of interest. This assurance uses semi-formal to formal methods.

3.2

SCOPE LEVELS

There are three levels of scope for every security facet, from Level 1 to Level 3, with higher
numbers indicating a narrower and more specific scope.
Level 1, General: This is the broadest scope. The security practice is implemented in the computer
systems and networks without any assessment of its relevance to the specific sector, equipmentused, software or processes to be maintained. The security capabilities and techniques areapplied as they were in the typical environment.
Level 2, Industry specific: The scope is narrowed from the general case to an industry-specificscenario. The security practice is implemented considering sector-specific issues, particularly
those regarding components and processes that are prone to certain types of attacks, and known
vulnerabilities and incidents that took place.
2019-02-25- 14 -

Version 1.0

IoT SMM Practitioner’s Guide

4: Template

Level 3, System specific: This is the narrowest scope. The security practice implementation isaligned with the specific organizational needs and risks of the system under consideration,
identified trust boundaries, components, technologies, processes and usage scenarios.

3.3

VISUALIZING THE LEVEL VALUES

Visualization helps understand the goals and ongoing progress of security maturity
enhancement. Figure 3-2 shows how comprehensiveness and scope levels for security maturity
domains may be illustrated on the same diagram. Each circle represents one of 9 selected
practices. The example describes an IoT system that accepts an ad hoc approach to threat
modeling and security strategy governance. Stricter but still general requirements are applied toasset, change and configuration management, and identity and access management. Incident
management and information sharing and communication are specific to the sector because
stakeholders want to know about relevant security incidents and track appropriate indicators ofcompromise. Finally, vulnerability and patch management, supply chain management andsituational awareness are specific for the system because of the need to minimize possible
disruptions of supported processes.
We discuss visualization alternatives further in the next section.

Figure 3-2: Visualization of two-dimensional approach in measuring security maturity

4 TEMPLATE
Each SMM practice has a corresponding table describing the comprehensiveness at the generalscope level. Table 4-1 shows a template for the practice table. For each comprehensiveness level,
the table describes the objective and general considerations. General considerations include:••

a description of the level,
what needs to be done to achieve that level and2019-02-25- 15 -

Version 1.0

IoT SMM Practitioner’s Guide•

4: Template

indicators of accomplishment to help assessors determine if the organization has met therequirements of the level.

<Practice-Name><Practice Description>
ComprehensivenessLevel 1

ComprehensivenessLevel 2ComprehensivenessLevel 3ComprehensivenessLevel 4

Objective

Objective Description

Objective Description

Objective Description

Objective Description

Generalconsiderations

Level Description

Level Description

Level Description

Level Description

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Considerations

Considerations

Considerations

Considerations

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Considerations

Considerations

Considerations

Considerations

Table 4-1:

4.1

SMM Table Template

EXTENSIBILITYThe SMM can be extended in several ways. The scope of each practice can be extended byindustry, system, or both. In addition, over time, the model may be extended with the additionof new subdomains and practices.

4.2

EXTENDING THE PRACTICESThe SMM is designed to be extensible across a wide array of industries and systems. It addresses
the general scope, which looks at common security maturity best practices in the industry. Thereis an opportunity to add industry-specific and system-specific scope to any or all of the practices.
The IIC will collaborate with a wide range of industry groups to encourage development of
profiles—practice tables that go beyond general scope and include industry- and system-specificrequirements for different comprehensiveness levels. For example, a retail group may create
profiles of some or all practices that include best practices and regulatory requirements specificto the retail industry; they may also create system specific profiles for commonly used devices
such as card readers or security cameras. A health care profile may include specific guidance
related to HIPAA, while a system-specific profile could address considerations for, say, FDA preand post-market guidance for implanted medical devices.
Industry and system profiles need not be created for every practice in the model. An industry
may decide that the general scope is sufficient for most of the governance-related practices butthat a few of the enablement practices necessitate an industry-level point of view.
When extending for industry or system-specific considerations, the practice table as seen in Table
4-2, expands to include two additional rows.
2019-02-25- 16 -

Version 1.0

IoT SMM Practitioner’s Guide

4: Template<Practice-Name><Practice Description>
ComprehensivenessLevel 1

ComprehensivenessLevel 2ComprehensivenessLevel 3ComprehensivenessLevel 4

Objective<Objective Level 1><Objective Level 2><Objective Level 3><Objective Level 4>Generalconsiderations<List of Level 1 general <List of Level 2 general <List of Level 3 general <List of Level 4 generalconsiderations>considerations>considerations>considerations>

Industryspecificconsiderations<List of industry specific considerations>

System-specificconsiderations<List of system specific considerations>

Table 4-2:

SMM Table Template with industry and system specific considerations

Industry-specific considerations include the sector-specific issues, particularly components andprocesses that are prone to certain types of attacks, known vulnerabilities, incidents that took
place in similar systems and possible harm to this kind of operational technology as well as sector
specific priorities including legal and regulatory guidance.
While the general row in the table included headings for achieving the level and indicators ofaccomplishment, the industry row should include a general description of the industry-specificissues as noted above and for a comprehensiveness level with industry-specific considerations:••what needs to be done to achieve that level andrelevant industry guidelines for that level.

System-specific considerations include the specific security-relevant business needs and risks forthe system under consideration, identified trust boundaries, components, technologies,
processes, and usage scenarios that combine the general and domain-specific objectives in aunique manner.
As the general and industry rows in the table included headings and structure described above,the system row should include a description of the system and how it is used in the larger IoT
infrastructure and for a comprehensiveness level with industry-specific considerations:••what needs to be done to achieve that level andindicators of accomplishment that can assist assessors in identifying if the organization
has met the requirements of the level

Table 4-3 displays the industry and system specific considerations within the template.

2019-02-25- 17 -

Version 1.0

IoT SMM Practitioner’s Guide

4: Template<Practice-Name><Practice Description>
ComprehensivenessLevel 1

ComprehensivenessLevel 2ComprehensivenessLevel 3ComprehensivenessLevel 4

Objective<Objective Level 1><Objective Level 2><Objective Level 3><Objective Level 4>Generalconsiderations<List of Level 1 general <List of Level 2 general <List of Level 3 general <List of Level 4 generalconsiderations>considerations>considerations>considerations>

Industryspecificconsiderations

Industry-specific security needs (e.g., facilitating safety, keeping continuous execution etc.)
Accepted and recommended approaches to the practice implementation
Known constraints
What needs to be done to achieve the specific level and the indicators for accomplishment forthat level

System-specificconsiderations

System description and connected industries
System-specific security needs (e.g., facilitating safety, keeping continuous execution etc.)
Recommended approaches to the practice implementation
Known constraints
What needs to be done to achieve the specific level and the indicators of accomplishments forthat level

Table 4-3:

SMM Table Template with industry and system specific description and indicators

Establishing a target maturity state, while accounting for industry and system-specificconsiderations, facilitates generation of security profiles. These profiles capture systems’ target
security maturity and can act as templates for evaluating security maturity of a specific area ofuse, common use-case or system of interest.
Table 4-4 is an example of a partially filled-in threat modeling practice using the above template.
Practice: Threat Modeling of Medical Devices (cont. from page 18)
including a handheld that collects patient telemetry and a base station aggregates patient vitals and shares data
across a hospital network.
ComprehensivenessComprehensivenessComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Consider general IT
security issues asthreats

Perform vulnerability
analysis to identify
threats. Address in an
ad-hoc manner

Describe and classify
threats in an accurate(optionally formal)
way

Generalconsiderations

At this level, threats
are only based on
known typical IT
security threats.

At this level, theorganization performs
vulnerability
assessments tounderstand threats asthey pertain to theorganization. The
organization can

At this level, accepted At this level, threat
formal threat
modeling is built intomodeling methods are business processes
used, and automated and driven by businessgoals and risk profile.
tools are used forthread modeling.

2019-02-25- 18 -

Reveal and describe
IT, OT and IoT factors
both known andspecific that may put
the system at risk

Version 1.0

IoT SMM Practitioner’s Guide

4: Template

Practice: Threat Modeling of Medical Devices (cont. from page 18)
discern specific IT, OT
and IoT threats.

2019-02-25

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Collect the available
information about
typical IT security
vulnerabilities andincidents andrecognize those thatare relevant asthreats.

Perform avulnerability
assessment for IT, OT,
and IoT (At this level,
they are typicallymanaged separately).
Use the generally
accepted vulnerability
evaluation schemes(such as Common
Vulnerability Scoring
System) [CVSS].

Describe the threats
during the analysis
using generally
acceptedclassifications like
CAPEC or OWASPTop10.

Validate the security
threats against
objectives set
according to businessneeds.

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Business-level
documents mention
general security
threats, such as
sensitive data
disclosure, denial ofservice attacks, orinfiltration withmalware.

A vulnerability
assessment report isavailable andidentifies common
and typical threatsvalid for the identified
use cases.

Identified tools anddocumented methods
for the threat
assessment.
An assessment reportthat consistently
describes theclassified threats,vulnerable
technologies,
exploitation method
or attack pattern,level of risk andpossible resolutions.

The accepted
methodology forthreat analysis andmodeling thatcomprises a part of
the rhythm of thebusiness, accounts forbusiness goals andrisk, and is performed
consistently.
The periodic
assessment reports
demonstrating threat
analysis experience- 19 -

Base the threat model
upon the set of clearly
identified security
Optionally use thetools to describe the assumptions aboutsystem environment
architecture of the(including physicalsystem toautomatically identify security),trustworthinessthreats and possible
constraints, and key
resolution.
actor’s behavior. IT,
Address the IT, OT,
OT, and IoT threats
and IoT-specific (forare integrated.
example, edge device
Organize thephysical compromise)
particular threats andthreats.
attack vectors as aConsider the results ofconsistent hierarchicalthreat modeling andstructure, including allrisk assessments as a
identified security
part of formal
issues.
processes to address
and prevent theidentified concerns.

Version 1.0

IoT SMM Practitioner’s Guide

4: Template

Practice: Threat Modeling of Medical Devices (cont. from page 18)
and lessons learned
over time.
Industry-specific What needs to be done to achieve Level 3
considerations
Note: FDA guidance can be interpreted to require that a medical device manufacturer reach orexceed a level 3 comprehensiveness in threat modeling as part of a pre-market submission.
The threat model accounts for FDA guidance for post-market management of cybersecurity inmedical devices
Industry Guidelines for Level 3
FDA requirements for pre-market submissions related to cybersecurity:
https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf
FDA post-market guidance on managing cybersecurity in medical devices:
https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm482022.pdf
What needs to be done to achieve Level 4
Threat model includes not only the device in isolation, but the medical environments in which
the device will operate.
Threat model includes scenarios in which the device could allow its users to violate HIPAA
standards (such as by leaking Personally Identifiable Information (PII)) and seeks to mitigate
those opportunities.
HandheldSpecific
Considerations

The handheld collects only anonymized patient telemetry data. Its exposed attack surfaces are
Bluetooth LE, USB, and physical access.

System-specificconsiderations

The base station aggregates patient telemetry with PII, making the data it stores and transmits
HIPAA relevant. Its exposed attack surfaces include Bluetooth LE, USB, Wi-Fi, Ethernet, andphysical access.

Table 4-4:

SMM Practice Table Example

Over time, the model may evolve via the addition of new subdomains and practices. This enables
the model to maintain relevance as new security and IoT disciplines emerge. Such extensions
may be added to future iterations of the model.

2019-02-25- 20 -

Version 1.0

IoT SMM Practitioner’s Guide

5: Process for Applying the Model

5 PROCESS FOR APPLYING THE MODEL
Figure 5-1 displays a typical SMM Process. . We expect most organizations to first establish amaturity target. Business level stakeholders define the target using some form of a businessobjectives questionnaire. Technical level stakeholders take such objectives and translate theminto more detailed security requirements based on their understanding of the system. Once atarget has been created or a relevant industry profile identified, organizations would conduct anassessment to capture the current maturity state. The security maturity of the target state andcurrent state can be compared to identify gaps and opportunities for improvement. Based on the
gap analysis, business and technical stakeholders can establish a roadmap, take actions, andmeasure the progress. After implementing enhancements, organizations can perform anotherassessment. The cycle repeats to ensure that the appropriate security target is always maintainedin an ever-changing threat landscape.

Figure 5-1: IoT Security Maturity Model Process

5.1

ESTABLISHING THE CONTEXT

Before creating a maturity target or conducting a maturity assessment it is important to establish
the context for the activity. First, there is a need to identify if the assessment addresses acomplete end-to-end system, or a subsystem such as the cloud or edge, or a gateway device? Is
the organization being assessed a solution provider, an end user or is it a vendor of a device oran IoT platform? Depending on the context it is possible that some of the practices may not be
relevant and should be marked as Not Applicable.

2019-02-25- 21 -

Version 1.0

IoT SMM Practitioner’s Guide

5.2

5: Process for Applying the Model

CREATING THE SECURITY MATURITY TARGETThe security maturity target establishes the ultimate security maturity state for a system. The
target includes a consistent set of security practices, providing all stakeholders an understandingof the general security goals and the purpose of each security practice. The job of establishing
the security maturity target falls to business stakeholders, and it should be carried out prior to
any investment in enhancing security.
Once the security maturity target is available, it may be used in subsequent applications of theSMM, to create a target profile or evaluate a current maturity state assessment.
For a specific type of organization or system, it is useful to have a specific profile named a security
maturity target profile. Using security maturity target profiles simplifies the process ofestablishing the target for common use cases. Establishing a library of security maturity target
profiles for common scenarios is a subject for further development.
Most devices, networks and systems do not require the highest comprehensiveness and scopelevels for every security domain, subdomain or practice. A system’s security maturity target isdefined as the set of all desirable values of comprehensiveness and scope for every security
maturity domain, subdomain and practice.
The security maturity target is defined when referring to the comprehensiveness and scope forsecurity maturity practices as seen in Table 4-4 (the SMM Table Practice Example, page 20). Eachpractice table has four columns, one for each comprehensiveness level. The objective in eachlevel describes the general considerations that should be met. Guidance is provided in the formof general considerations.
How to create the security maturity target is described in the following three sections.

5.3

DETERMINING THE COMPREHENSIVENESS LEVELS

There are several steps to determine the comprehensiveness level as described below.
Establish the goal for each security domain—governance, enablement and hardening—according
to the global vision of its role in the targeted maturity state. Define goals for each domain basedon the overall goal. The goal chosen from this set determines the minimum comprehensivenessand scope levels for the whole domain. Security maturity sub-domains and practices consideredwithin the domain will inherit these levels at this step. This first step provides a rough definitionof the security maturity target.
The Comprehensiveness Level Definition Guide Section 10, page 76 of this document lists
comprehensiveness levels for domain goals.
It is possible to obtain the rough security maturity target by inheriting comprehensiveness andscope levels at the next tiers of the SMM hierarchy so that:••the subdomains get the same comprehensiveness levels as the upper domains andthe practices get the same comprehensiveness levels as the upper subdomains.

2019-02-25- 22 -

Version 1.0

IoT SMM Practitioner’s Guide

5: Process for Applying the Model

To get a detailed security maturity target, consider the established levels for domains as the baselevel for subdomains. If a subdomain is determined to be at a higher level than its inherited value,then the domain has achieved the originally set base level “+”. (The “+” indicates that this thislevel has been achieved, and more.) The domain does not move to a higher level unless all its
subdomains are marked at a higher level. If any element of the subdomain fails to meet the higher
level, then it is deemed to be at the lower level and the domain itself is reduced and considereda lower level with the “+” identifier. If all the subdomains are at the same lower level, the domain
must also be reduced to the lower level to maintain consistency.
Then consider the needs covered by the security maturity subdomains in each domain. These
include threats and continuous changes of threat landscape, compliance needs, andrequirements from regulatory authorities. The prior step provided the initial comprehensivenessand scope levels for the domain. This step specifies whether there are specific security-related
needs that require attention beyond the established baseline.
The Comprehensiveness Level Definition Guide Section 9 of this document lists
comprehensiveness levels for domain goals.
It is possible to stop here and obtain the security maturity target by inheriting practicecomprehensiveness and scope levels from the subdomains.
To get the detailed security maturity target, consider the established levels for applying the initiallevels of subdomains as the base level for their practices. If a practice is determined to be at ahigher level than its inherited value, then the subdomain is considered to have achieved theoriginally set base level “+”. The subdomain does not move to a higher level unless all its practices
are marked at a higher level. If the practice is deemed to be at a lower level, the subdomain must
be reduced and considered a lower level “+”. If all the practices are at the same lower level, thesubdomain must also be reduced to the lower level to maintain consistency. In the example in
Figure 5-2, the subdomain is initially set to a 2 and its practices inherit the 2. Upon analysis, it isdetermined that one practice is a 1 and another is a 3. The subdomain must then be reduced tomatch the lowest level 1, but can be described as a 1+.

Figure 5-2: Subdomain Consistency Check, reducing Subdomain value

If at some point all the practices match a higher level, as shown in Figure 5-3. The subdomain
value may be increased to match that of the practices.
2019-02-25- 23 -

Version 1.0

IoT SMM Practitioner’s Guide

5: Process for Applying the Model

Figure 5-3: Subdomain Consistency Check, increasing Subdomain value

The consistency check must flow through the hierarchy to determine if changes at the subdomain
level have affected the values of the domains above them.
Then clarify the purpose of every security practice within the subdomain. As subdomain
prioritization emphasizes specific security needs, practice prioritization clarifies how thepractices address these needs. Some practices may be entirely applicable and some only partially.
Target comprehensiveness and scope levels for each practice reflect the level of assurance incovering subdomain needs.
This step considers the comprehensiveness and scope needed to implement security capabilities,
thus providing a greater level of detail to the security maturity target. A detailed summary oftypical practice purpose definitions corresponding to comprehensiveness levels is provided in theComprehensiveness Level Definition Guide (Section 10, page 76).

5.4

DETERMINING THE SCOPE

To determine the scope for all practices, complete the following steps.
Check whether each security domain has specific requirements across the industry. If so, assign
the industry-specific level to the domain and underlying subdomains and practices. Describe theindustry-specific requirements for the domain, their source and how they apply.
Then check whether each security domain has specific requirements across several industries or
only for the system. If so, assign the system-specific level to the domain and underlying
subdomains and practices appropriately. Describe the system-specific requirements for thedomain, their source and how they apply.
For each subdomain, if no changes were made for the parent domain, check whether the
subdomain has specific requirements across the industry. If so, assign the industry-specific levelto the subdomain and underlying practices. Describe the industry-specific requirements for the
subdomain, their source and how they apply.
Otherwise, specify the industry-specific requirements for all subdomains, the source of theserequirements and how they apply.
For each subdomain, if no changes were made for the parent domain, check whether the
subdomain has the specific requirements across several industries or only for the system. If so,
assign the system-specific level to the subdomain and underlying practices. Describe the systemspecific requirements for the subdomain, their source and how they apply.

2019-02-25- 24 -

Version 1.0

IoT SMM Practitioner’s Guide

5: Process for Applying the Model

Otherwise, specify the system-specific requirements for all subdomains, the source of theserequirements and how they apply.
If a subdomain scope is determined to be at a higher level than its inherited value, then thedomain is considered to have achieved the originally set base level “+” (for example, Industry+or System+). The domain only moves to a higher level when all its subdomains are marked at ahigher level. If the subdomain is deemed to be at a lower level, the domain must be reduced andconsidered a lower level “+”. If all the subdomains are at the same lower level, the domain mustalso be reduced to the lower level to maintain consistency.
Then, for every practice, if no changes were made for the parent subdomain, check whether thepractice has specific implementation across the industry. If so, assign the industry-specific levelto the practice. Describe the industry-specific requirements for this practice implementation,
their source and how they apply.
Otherwise, specify the industry-specific requirements for the practice implementation, thesource of these requirements and how they apply.
Then for every practice, if no changes were made for the parent subdomain, check whether thepractice implementation poses the specific requirements across several industries or only for thesystem. If so, assign the system-specific level to the practice. Describe the system-specificrequirements for this practice implementation, their source and how they apply.
Otherwise, specify the system-specific requirements for the practice implementation, the sourceof these requirements and how they apply.
If a practice scope is determined to be at a higher level than its inherited value, then the
subdomain is considered to have achieved the originally set base level “+”. The subdomain moves
to a higher level when all its practices are marked at a higher level. If the practice is deemed to
be at a lower level, the subdomain must be reduced also and considered a lower level “+”. If all
the practices are at the same lower level, the subdomain must also be reduced to the lower levelto maintain consistency.

5.5

CHECKING FOR CONSISTENCY OF THE SECURITY MATURITY TARGETAs the security maturity model defines a hierarchy for the security practices, facilitating the clear
and logical representation of priorities for these practices, the security maturity target should bevalidated for its consistency against the model. If the target is inconsistent, enhancement will
face challenges in prioritization and road-mapping.
Validation comprises the following checks:
Validate the subdomains and practices against the actual needs and purpose definitions. Perform
this check in cases where the comprehensiveness and scope levels are assigned to subdomains
and practices according to the levels of upper domains or subdomains. The stakeholders put thegoals, needs and purpose definitions describing the organization’s target security state andreview them, applying changes where needed. For every change, consider whether the change
corresponds to the same level, or whether to increase the level for this subdomain or practice.
2019-02-25- 25 -

Version 1.0

IoT SMM Practitioner’s Guide

5: Process for Applying the Model

The level may be decreased along with the consistency checks outlined in the prior section, but
it is not recommended.
Check for the consistency of target comprehensiveness definition. Any definedcomprehensiveness level for the subdomain must be equal to or greater than the level set for
the upper domain. Any defined comprehensiveness level for the practice must be equal to or
greater than then level set for the upper subdomain. If the check is not passed, decrease the levelof the upper domain or subdomain appropriately. The levels of underlying subdomains andpractices keep their values.
Check for the consistency of target scope definition. Any defined scope for the subdomain must
be equal to or more specific than the level set for the upper domain. Any defined scope for thepractice must be equal to or more specific than level set for the upper subdomain. If the check is
not passed, decrease the level of the upper domain or subdomain appropriately. The levels of
underlying subdomains and practices keep their values.

2019-02-25- 26 -

Version 1.0

IoT SMM Practitioner’s Guide

6: Conducting a Security Maturity Assessment

6 CONDUCTING A SECURITY MATURITY ASSESSMENT
A documented summary of fully or partially implemented security capabilities facilitates
establishing a roadmap for maturity enhancements. The current security maturity state is thecurrent maturity state of implemented security practices for the given system in a similar format
to the security maturity target. Typically, a security assessment evaluates each security practiceby auditing controls through evaluating controls’ effectiveness through technical testing or
penetration testing. We may then compare it against the target state so as to identify gaps andproduce a roadmap to achieve target state.
To determine the current security state:
Determine the coverage of the assessment: Options include the entire organization, only selectedparts of the organization, or only specific security practices. For each of the security practices
that will be assessed, which stakeholders should be included and which implemented controls
should be evaluated? If a stakeholder cannot be included or a specific control cannot be
evaluated in a reasonable time (for example, a supplier in another country), are there otheravenues by which their security could be evaluated?
Determine assessment method: The next step is to determine a method for the assessment.
Considerations include:•••

Will the review be conducted by an in-house team or a third party?
Will the testing method include policy reviews, interviews, audit, and penetration testing?
What framework will be used to enumerate and evaluate possible controls?

Testing that focuses on evaluating the true effectiveness of controls provides a more accurate
picture of security, but also tends to be more time consuming. The expertise required may also
not exist in house.
Stakeholder preparation: Preparation increases the likelihood that the assessment can becompleted in a reasonable time and that its final results are accurate. You should:
•
•
•
•
•

identify stakeholders and points of contact and obtain management buy-in,socialize the assessment and its goals with those stakeholders not involved in its planning,schedule interviews with the relevant stakeholders for the assessment team,gather relevant policies, documentation, contracts, previous assessment reports, etc. andprepare any accesses required for penetration testing, such as things like network access,and domain credentials.

Assessment: After preparation, the team should review the implemented security practices.
Reporting: The assessment team should document their findings in a formal report tomanagement and other relevant stakeholders. It should interpret the team’s findings throughthe lens of the organization’s specific industry and business profile. It should address eachsecurity practice and its relevant controls and a low level of detail so it is useful for reaching thetarget. It may include a system for scoring or measuring each control and practice, to provide theorganization with metrics for relative prioritization, change over time, and other comparisons.
2019-02-25- 27 -

Version 1.0

IoT SMM Practitioner’s Guide

6.1

6: Conducting a Security Maturity Assessment

ACHIEVING A LEVELThe organization meets a comprehensiveness level when it meets all the indicators of that level.
Transitioning between comprehensiveness levels is contingent upon clearly documenting thecharacteristics and requirements of the given level. Clarifying this information is necessary due
to the variability in how the level is defined for different scenarios:••••

For the minimal comprehensiveness level, define the practice implementation goals andthe appropriate minimal measures.
For the ad hoc comprehensiveness level, describe the use cases and baseline measuresrequired for their support.
For the consistent comprehensiveness level, document the recognized best practices,
standards, regulations, and supporting tools where applicable.
For the formalized comprehensiveness level, document the supporting process definition.

The transitions between the scope levels are determined by the sector specific issues and systemspecific needs and risks identified during the security maturity target definition.
Therefore, before the security maturity assessment (and as a part of this assessment) the
stakeholders must agree on the exact definitions of the comprehensiveness and scope levels,
corresponding to the current guide, as shown on the Figure 6-1.

Figure 6-1: States and transitions between the comprehensiveness and scope levels for security
practices

Some organizations will need to demonstrate some, but not all, of the required items of a higher
level. For example, if an organization has met all conditions for Level 2 but only some for Level 3,
they can be considered a Level 2+; but they need to meet all the conditions of Level 3 before they
2019-02-25- 28 -

Version 1.0

IoT SMM Practitioner’s Guide

6: Conducting a Security Maturity Assessment

can be considered a Level 3. Similarly, if an organization has met all items of a Level 1, 90% ofLevel 2 and some of Level 3, they would be recognized as a Level 1+.
Unlike the target levels, which are set and can be inherited, the current state assessment isperformed bottom up by evaluating the practices in detail. A subdomain is identified by thelowest level of its practices. If the practices have different levels, the subdomain is identified as
the lowest level “+”. The subdomain does not move to a higher level unless all its practices aremarked at a higher level. In the case of comprehensiveness, this may be designated as Level 2+,
if some practices are above Level 2, and in the case of scope, as “industry+” if some of the scopes
are at the system scope level.
Once the values are set of the subdomains, a similar summary and check can be performed at
the domain level. If the subdomains have different levels, the domain is identified as the lowest
level “+”. The domain does not move to a higher level unless all its subdomains are marked at ahigher level. In the case of comprehensiveness, this may be designated as Level 2+ if some
subdomains are above Level 2, and in the case of scope, as “Industry+” if some of the scopes areat the system scope level.

6.2

PERFORMING GAP ANALYSIS

With the target state and current state in hand, the organization can perform a gap analysis to
identify appropriate areas for security improvements and investment. For those controls where
there is a difference between the two states, note the size of the gap to assist with prioritizing in
the roadmap. Also note any situations in which a specific control may be short of the target state,
but the potential ensuing risk is mitigated by another control. This process should yield a list of
security controls that are short of target state, the gap between current and target state for thosecontrols, and notes of any controls where the risk might be mitigated through other means.
Based on the comparison between target and current states, business and technical stakeholders
can measure the progress and negotiate the steps for security maturity enhancement. Three
possible visualizations for gap analysis are shown in Figure 6-2, Figure 6-3 and Figure 6-4. Figure
6-2 shows a heat map based on the levels of the target and current comprehensiveness andscope. The heat map displays the gaps for each, where red indicates a large gap, yellow a small
gap and green as no gap.
Figure 6-3 uses a bar chart to compare comprehensiveness levels between the target and current
state, with the differences between the bars showing the gap. Shading can be used to display andcompare the scope (in this example, general scope is an empty bar, industry scope is a patternedbar, and system scope is a filled bar).
The third visualization in Figure 6-4 is a radar or spider chart showing the current and target
comprehensiveness states, with the difference between the levels representing the gap. In thischart, the symbols are used to visualize the scope, with different symbols for the general, industry
and system scopes. Where the symbols do not match between current and target, this indicatesa gap in scope levels.

2019-02-25- 29 -

Version 1.0

IoT SMM Practitioner’s Guide

6: Conducting a Security Maturity Assessment

Gaps in the maturity are determined by gaps in the comprehensiveness and scope. If gaps exist
for a particular practice, the maturity for that practice is lower than desired and needs to be
improved. If no gaps exist (score is even, or current state is higher than the target) then thematurity of the organization is sufficient or ahead of the need.

Figure 6-2: Gap Analysis for Security Maturity Target

Figure 6-3: Gap Analysis for Security Maturity Target

2019-02-25- 30 -

Version 1.0

IoT SMM Practitioner’s Guide

Figure 6-4:

6.3

6: Conducting a Security Maturity Assessment

Gap Analysis for Security Maturity Target

PLANNING THE ROADMAP

Next, use the results of the gap analysis to build a roadmap for future security improvements.
The roadmap prioritizes the activities according to the identified gaps, major business andsecurity needs and concerns, available resources and expertise and accepted business practices.
Security maturity can be enhanced by improving the comprehensiveness and by shifting thescope. If one of these dimensions doesn’t need to improve, the steps for improving the other one
may be planned and executed. If both comprehensiveness and scope need to improve, thestakeholders should consider the comparative importance of comprehensiveness and scope forthat practice, and the possibility of improving one before another (see Table 4-3, page 18).
Then for each practice where the current state was short of target:••••

identify where the comprehensiveness should be improved immediately due to regulatory,
legal, or contractual obligations,
identify where the scope should be improved immediately due to regulatory, legal, or
contractual obligations
identify which remediations would yield the target state. Use best practice guides to identify
the most effective control improvements andprioritize the remediation according to regulatory, legal, or contractual obligations.

2019-02-25- 31 -

Version 1.0

IoT SMM Practitioner’s Guide

6: Conducting a Security Maturity Assessment

For each potential remediation, identify its cost in money and organizational resources. Clarify
the effect of the remediation and what resulting security improvements would occur.
Develop a roadmap for security improvement. The roadmap should prioritize remediations thatwould satisfy legal or regulatory requirements and those that would result in the mostimprovement at lowest cost. Other considerations when developing the roadmap include:••••

possible dependencies between security controls. i.e., situations in which a change toControl A would not lead to an improvement until an improvement is made in Control B,
improvements that may affect multiple controls,
time and resources required to implement each remediation andtime and resources required before an implemented change is fully effective.

Then establish ownership, milestones, and deadlines for each remediation item.
The gap analysis helps the organization develop a roadmap to improve its security posture andmaturity. Understanding the gaps informs the organization as to the relative priority of different
security requirements and controls. The model identifies the conditions needed to achieve acertain level of comprehensiveness and scope.

6.4

MAKING SECURITY ENHANCEMENTS

Organizations can leverage best practices, such as those being defined by the IIC, to apply specificcontrols and processes to help them move to a target maturity state. An example is the Endpoint
Best Practices [IIC-Practices-Endpoint] guidance.
The organization should execute the roadmap, enacting the identified remediations to drive theorganization towards its target state. The improvement process is more effective with senior
executive sponsorship, so consider implementing a stakeholder steering committee to meet
regularly and track progress. This ensures accountability and can implement course corrections,in the event improvements do not go according to plan.

6.5

CONTINUOUS IMPROVEMENTS

Figure 5 showed the IoT Security Maturity Model Process. A persistent mature system security
state is only achievable via continued security assessments and improvements, orchestrated overtime. Consequently, we iterate over a Plan-Do-Check-Act cycle (Act, in this case, means accepting
a new baseline if the check on the result of the improvement step is successful). The cycle begins
by establishing the target for security maturity for a specific system. Then an iterative high-levelprocess of security maturity improvement begins, as shown in Figure 6-5. The pace of change insecurity threats and approaches to mitigate them determine how frequently to execute the cycle.

2019-02-25- 32 -

Version 1.0

IoT SMM Practitioner’s Guide

Figure 6-5:

6.6

6: Conducting a Security Maturity Assessment

SMM Improvement Cycle

SUBSYSTEMSThe SMM can apply to an entire solution or to its components. In some cases, an organization
manages the entire solution and can evaluate the solution using a single set of tables. In othercases, such as an organization that manages its infrastructure at the edge but uses a third-party
communications network and a third-party cloud, the organization may wish to create a separate
set of SMM tables for each subsystem. The cloud provider may employ highly mature processes
for managing its infrastructure, including staff background checks, physical security, and patch
management processes. In this case, the SMM may indicate that the current comprehensivenessfor patch management is level 4. Conducting a separate assessment of devices at the edge, which
may be unprotected in the field, may indicate the current comprehensiveness for patch
management is level 2.
If targets are set differently for different subsystem, evaluate whether the differences introduce
additional risks into the overall system. Depending on the scenario, a level 2 at the edge may
indicate a deficiency that can pose additional risk into the cloud. However, for some scenarios,
the difference may be acceptable. Consider attacks from insiders or attackers using insider
credentials in your strategy. Segmentation alone may not remove insider attack risks and canprovide a false sense of security, so consider the impact of insider attacks on a system withmultiple segments. One example is obtaining information from one segment (e.g., the cloud) andusing that information to attack another segment (e.g., an enterprise system). Another ischanging data in one segment to sabotage operations elsewhere. A third example iscompromising a privileged user with accounts on multiple segments.

2019-02-25- 33 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Part II: The Core of The Security Maturity Model
This part presents the core of the SMM in a set of practice tables grouped by domain(governance, enablement, and hardening) and subdomains. Each table corresponds to a SMM
practice and describes the general scope considerations for each defined comprehensivenesslevel.
Following each table is an example, using various industry use cases, to demonstrate how anorganization might use the table to pick a target state or to evaluate its current state.

7 GOVERNANCE DOMAIN
The security governance domain is at the heart of security. It influences and informs every
security practice (each of the governance, enablement and hardening domains has six security
practices) including business processes, legal and operational issues, reputation protection andrevenue generation.

7.1

STRATEGY AND GOVERNANCE SUBDOMAIN

Security strategy and governance supports organizational strategy as well as providing security
and compliance with regulations, laws and contractual obligations. It also supports reputation
management and meeting customer expectations.
7.1.1 SECURITY PROGRAM MANAGEMENT PRACTICE
Security Program Management (cont. from page 34)
This practice is critical for the planning and timely provision of security activities, control over the process andresults and optimal decision-making procedure for fulfillment of security related demands.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Describe generalsecurity provisions.

Generalconsiderations

This level represents a This level represents
basic understanding
acting based on theof security concerns
desired plan andand the desire tocreating the
document them.
appropriateorganization.

2019-02-25

Create a security
program aligned withorganizational
structure andsystems.

- 34 -

Align the security
program withappropriate widely
recognized security
standards.

Manage security
program over time:
Implement clear
planning, timely
provision and control
of security activities
with periodic
assessments.

This level represents
awareness of external
standards andregulations andincorporates theminto the management
practices.

This level provides forcontinuous
improvement andmanagement overtime.

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Security Program Management (cont. from page 34)
What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Document the
Achieve situational
Identify andAlign the security
internal and external document systems,
awareness by tracking
program withissues relevant to
networks, andappropriate standards threats, regulatory
security management. processes to berequirements andto meet regulatory
evolving technologies
managed to address requirements or to
Identify security
over time.
the security issues.
achieve consistency
management
across the
structure, measures, Plan the resources for
Set the timeframes fororganization,
responsibilities, andperiodic reviews andsecurity management,
including subsidiaries.
methods to
updates of measures,
communication,communicate thisplan the efforts andtraining andIncorporate
information toresources.
awareness.
understanding of
personnel.
standards into
Conduct periodic
Create skill centers forsecurity management,
training and
Coordinate and align the identified roles.
communication,awareness-building androles and
Senior executives
training andtesting activities.
responsibilities
support security
awareness programs.
including expertise in initiatives andScale integrated teams
devices, networks and understand their roles Integrate teams
by creating an IoT
IoT infrastructure
and responsibilities.
across skill centers.
center of excellencewith internal roles
OT stakeholders
Perform criticaland adjust teams forand external partners. provide operational
infrastructure andproof of concept, pilot,
viewpoint.
sector-specific (IT andsystem scaling, andOT) risk analysis to
production phases.
inform theorganization’s
determination of risk
tolerance.
Ensure that thirdparty stakeholders(e.g., suppliers,
customers, partners)
understand their roles
and responsibilities.
Indicators ofaccomplishment

Indicators ofaccomplishment

Documents covering Accepted information
general goals,
security program andinterested parties,
policy.
priorities and scope ofDocuments covering
security management,
resources including
awareness measures.
systems, processes,
A dedicated staff with devices, anddefinednetworks, required

2019-02-25- 35 -

Indicators ofaccomplishment

Indicators ofaccomplishment

Establishedcommunications
between thestakeholders andexternal authorities.

Documented plan andprocess for periodic
review and assessmentof the security
management program.

Assessment reports
demonstrating
conformance ofEstablished anddocumented
mechanisms for

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Security Program Management (cont. from page 34)
responsibilities forsecurity.

budget, and thedivision of
responsibilities.

security management ongoing situational
practices to theawareness related to
relevant standards
threats.
Integrated teams
have been
established.

Table 7-1:

Established andmaintained assurance
program roadmap
supported by allinterested parties.

Security Program Management

A mid-size manufacturing plant determines that its security program needs to bealigned with the IEC 62443-2-1 industry standard, so it sets a maturity target for
Examplesecurity program management at comprehensiveness level 3: consistent. The current
state assessment indicates that its security program structure does not follow thestandard and relies on existing internal organizational structure. The current statecomprehensiveness for security program management is level 2, ad hoc.

2019-02-25- 36 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

7.1.2 COMPLIANCE MANAGEMENT PRACTICE
Compliance Management (cont. from page 37)
This practice is necessary when strict requirements for compliance with evolving security standards is needed.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Create organizationalawareness of theneed for compliance.

Analyze andunderstandcompliancerequirements for
implementation.

Ensureimplementation
meets obligatorycompliancerequirements andaudit leads tocertification.

Manage compliancewith systematic
techniques including
automation and wellestablished assessment
process.

Generalconsiderations

At this level, theorganization's
adherence tocompliance regimes isinconsistent.

At this level, theorganization
demonstrates anunderstanding of its
compliancerequirements and has
the ability to perform
assessments orchoose to outsourcethem.

At this level,
mandatory andregulatory
requirements areincorporated.

At this level, acontinuous process isestablished and an
automated solution is
introduced.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Identify and monitor
the general securityrelated compliancedrivers, including
compliance with
protocols, plug andplay and consortia
certification.

Define a plan to meetexternal compliancerequirements basedon details research of
relevant complianceregime.

Perform theProactively staycompliance audits and abreast of upcoming
consider regulatorychanges to complianceguidelines from theregimes and ensure
controlling authorities adherence to thoseto align the systems, changes before they
networks, orcome into effect.
processes with theAutomate and conduct
appropriate
on a regular basis therequirements.
collection, analysis,
storing and retrieval of
Systematically, but
audit data.
independently,
Keep the current andmanage thecompliance for IT, OT historic audit data per
project centralized andand IoT.
allow access toapproved individuals
only.

Check if theimplemented
Outsource all or most practices accuratelyof the activities
represent
regarding keeping the requirements andsystem compliant to reconsider if they
security standards.
diverge.
Perform theconformance andcomplianceassessment activities
using an internal oroutsourced team.

2019-02-25- 37 -

Establish a process forassessment for thoserequirements from theregulatory authorities

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Compliance Management (cont. from page 37)
that do not allow
automated checks byimplementing thesimilar scheme ofobtaining and storing
the data.
Consider IT, OT, andIoT holistically.
Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Documented
motivation andsecurity-related
compliance drivers.

Approved
requirements andallocated time andresources to ensurecompliance.

Complete set of
documents verifying
and assuring
compliance withsecurity-related
requirements.

Policies and tools used
to automate theprocesses surrounding
the audit data lifecycle.

Informal complianceassessment results
and identified gaps.

Detailed pass/failresults of these
activities aredelivered to projectstakeholders forevaluation.

Valid certificates andother supporting
evidence.

A centralized programand plan containing a
response statement
for each requirementthat captures theconcept of whatshould be done toensure therequirement is met ornote why it does not
apply.

Table 7-2:

The required data isaccessible and notstove piped within
separate parts of theorganization.
Established policy forthe organization oncontributing the input
or comments into
compliance regimesthat effect it and may
have personnel solely
responsible for its
compliance and risk
programs.

Compliance Management

A large OEM in the automotive industry develops state-of-the-art components andtechnologies that must comply with safety and emerging security standards. The
ExampleOEM needs to automate processes for compliance management and participate in
the development of security recommendations for the new technologies. Therefore,
it sets its maturity target for compliance at comprehensiveness level 4. Upon current
state assessment the organization learns that while it is following the required
procedures, they are being automated. The current state comprehensiveness forcompliance management is level 3, consistent.

2019-02-25- 38 -

Version 1.0

IoT SMM Practitioner’s Guide

7.2

7: Governance Domain

THREAT MODELING AND RISK ASSESSMENT SUBDOMAIN

The threat modeling and risk assessment subdomain identifies gaps in specific configurations,products, scenarios and technologies and prioritizes countermeasures accordingly.
7.2.1 THREAT MODELING PRACTICE
Threat Modeling (cont. from page 39)
This practice aims at both revealing known and specific factors that may place the functioning of a given system
at risk and accurately describing these factors.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Consider general IT
security issues asthreats.

Perform vulnerability
analysis to Identify
threats. Address in an
ad-hoc manner.

Describe and classify
threats in an accurate(optionally formal)
way.

Reveal and clearly
describe IT, OT and IoTfactors both known
and specific that may
put the system at risk.

Generalconsiderations

At this level, threats
are only based on
known typical IT
security threats.

At this level, theAt this level, acceptedorganization performs formal threat
vulnerability
modeling methods
assessments toare used, andunderstand threats as automated tools arethey pertain to theused for threadorganization.
modeling.
The organization candiscern specific IT, OT
and IoT threats.

At this level, threat
modeling is built intobusiness processes anddriven by businessgoals and risk profile.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Collect the available
Perform a
information about
vulnerability
typical IT security
assessment for IT, OT,
vulnerabilities andand IoT. (At this level,incidents andthey are typicallyrecognize those which managed separately).
are relevant asthreats.
Use the generally
accepted vulnerability
evaluation schemes(such as Common
Vulnerability Scoring
System or CVSS).

Describe the threats
during the analysis
using generally
acceptedclassifications like
CAPEC or OWASPTop10.

Validate the security
threats against
objectives set
according to businessneeds.

Optionally use thetools to describe thearchitecture of thesystem to identify
threats automaticallyand possible
resolution.

Base the threat model
upon the set of clearly
identified security
assumptions aboutsystem environment(including physicalsecurity),trustworthinessconstraints, and key
actor’s behavior.

Address the IT, OT,
IT, OT, and IoT threats
and IoT-specific (forexample, edge device are integrated.

2019-02-25- 39 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Threat Modeling (cont. from page 39)
physical compromise)threats.
Organize the particularthreats and attack
Consider the results
vectors as a consistentof threat modelinghierarchical structure,and risk assessments including all identified
as a part of formal
security issues.
processes to address
and prevent theidentified concerns.
Indicators ofaccomplishment

Indicators ofaccomplishment

Business-level
documents mention
general security
threats, such as
sensitive data
disclosure, denial ofservice attacks, orinfiltration withmalware.

The accepted method
A vulnerability
Identified tools andassessment report is documented methods for threat analysis andmodeling comprising aavailable andfor the threatpart of the rhythm ofidentifies common
assessment.
the business, accounts
and typical threats
An assessment reportfor business goals andvalid for the identified
that consistently
risk, and is performed
use cases.
describes theconsistently.
classified threats,
The periodic
vulnerable
assessment reports
technologies,
exploitation method demonstrating threat
analysis experience andor attack pattern,
lessons learned overlevel of risk andpossible resolutions. time.

Table 7-3:

Indicators ofaccomplishment

Indicators ofaccomplishment

Threat Modeling

An automotive manufacturer considers possible threats for interfering with the
Example operations of a vehicle key fob. They set their target maturity comprehensivenesslevel to 1 as they consider certain IT threats, such as a DoS attack that may prevent a
key fob from operating and allowing the driver to open the door. Over time, newthreats, such as an amplification of the vehicle proximity signal emerge and the
manufacturer needs to consider the possibility that a door can be opened when the
key fob is far away. The manufacturer realizes they need to perform additional threat
modeling and resets their target maturity comprehensiveness level from 1 to 2.

2019-02-25- 40 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

7.2.2 RISK ATTITUDE PRACTICE
Risk Attitude (cont. from page 41)
This practice enables an organization to establish a strategy for dealing with risks according to risk management
policy, including conditions for acceptance, avoidance, evaluation, mitigation and transference.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Informally define risk Establish proceduresnotion at a high level. for detailed risk
assessment,
differentiating theimportance of risks.

Generalconsiderations

At this level, there is At this level, risk is
At this level, risk is
no formal approach to better understood but driven by business
managing risk and it is managed in an ad-hoc objectives and best
only defined inmanner.
practices andgeneral terms.
common methods areapplied.

At this level, risk
management is part ofcontinuous processes
and business cycles.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Apply a general risk
Apply a more detailed
management
approach to risk
approach for all types analysis, assessmentof informationand concrete
security risks, as well countermeasures.
as other types of risks.
Multiple mitigations
Optionally, involve
are applied to eachthird parties tothreat.
perform the risk
Countermeasures
analysis.
mitigate theconsequences of a
successful attack on
any one vector.

SystematicallyIntegrate risk
measure andmanagement withappropriately manage strategy.
risks.

What needs to bedone to achieve thislevel

Systematically
Establish a continuous
address IT, OT, andprocess of risk
IoT. (At this level, they management toare typically managed include appropriate
separately).
decisions based on
identified risks.
Identify, prioritize andanalyze potential
Establish the risksecurity threats,
management strategy
vulnerabilities, andand identify the harm
consequences using
and its likelihood of
accepted methods.
threats.

Use methods thatcharacterize risks
Consider external and quantitatively or
qualitatively andinternal issues thatstructure as scenario
are relevant to the
purpose of the system based or asset based.
of interest and that
Third parties are partaffect its ability toachieve the intended of the process.
outcomes.

Integrate IT, OT and
IoT.
Identify the alternative
courses of action andresponses, evaluate
and determine if they
are consistent withorganizational risk
tolerance.

Consider risks related
to outsourcing, thirdparty contractors orother partners in the
supply chain. Consider
devices at this level.

2019-02-25- 41 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Risk Attitude (cont. from page 41)
Enable procedures toaddress risks andensure the system ofinterest can achieve
its intended
outcomes; prevent, or
reduce, undesired
effects; and achieve
continual
improvement.
Consider IT, OT and
IoT independently
with a discrete
coordination withthird parties.
Indicators ofaccomplishment
The definition of mainrisks that reflects
their types, theirpriorities, how they
connected to thevarious issues(business, regulatorycompliance, security,
safety, etc.) and how
they may beconnected to security
threats.
Consideration ofcommon risks
associated withtraditional
information(electronic or paper),classical IT systems
and applications,business partners,
joint ventures,
outsourcing partners,
and the like.

Indicators ofaccomplishment

Indicators ofaccomplishment

The approved,
A risk assessment
probably quantitative, method applicable toscale for measuring
IT-, OT- and IoTrisks.
related processes.

A roadmap for theperiodic evaluation ofrisks, their types, theirconnections with both
external and internal
The description of
Risk-handling strategy
factors and theircase-based security- describing avoidance,interconnections.
related risks
mitigation,
associated withacceptance, andThe periodic reports tointernal and external transference criteria the business about
factors including their with appropriate
newly identified risks
empirical quantitative actions.
and required changes
rates according to theto the risk handlingscale.
strategy.

Table 7-4:

2019-02-25

Indicators ofaccomplishment

Risk Attitude- 42 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

A restaurant supplier provides the technology for managing customer wait times
using pagers provided at check in. The supplier does not consider the possible break
Examplein into such devices to be a high risk or a high impact event and sets their target
maturity comprehensiveness level at 1. A third-party assessment confirms that the
supplier solution and restaurant environment operate at this level.

7.3

SUPPLY CHAIN AND EXTERNAL DEPENDENCIES MANAGEMENT SUBDOMAIN

Supply chain and the external dependencies management subdomain aim at controlling andminimizing a system’s exposure to attacks from third parties that have privileged access and canconceal attacks.
7.3.1 PRODUCT SUPPLY CHAIN RISK MANAGEMENT PRACTICE
Product Supply Chain Risk Management (cont. from page 43)
This practice addresses the need to enable trust for contractors or suppliers and to ascertain the absence ofhidden threat sources, ensuring the integrity of the supply chain.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Establish integrity
procedures for
suppliers and their
supplied components
and monitor theiraccomplishment.

Implement analysis,contracts andmethods forreviewing andprotecting the supply
chain.

Obtain certificates or Codify the supply chain
other security
risk management
assurance artifacts for policy and processes.
essential
components.

Generalconsiderations

At this level, basic
direct measures for
integrity control areapplied.

At this level, analysis
and methods areadded to track
measures and theireffectiveness.

At this level, bestpractices are applied,
and an assurance
program enacted to
track progress.

At this level, theapproach isstandardized across the
supply chain.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Implement a
The analysis of certain Identify processsupply chain threats is defined supply chains. standardized process
to address supply-chain
added and all-source
Implement a set ofrisk with respect tointelligence analysis ismethods to address
information systems
used to tailor
supply-chain risk withand system
acquisition strategies,
Such measuresrespect to computercomponents, and totools, and methods.
include at leastsystems, networks
educate the acquisition
Implement the
tamper evidence
and their
workforce on supplymethods forprotection duringcomponents, and tochain threats, risk, andreviewing andshipping andeducate therequired security
warehousing, physical protecting
acquisition workforce
controls.
access control of the development plans,on threats, risk andUse the acquisition andevidence, andpersonnel providing
required security
procurement processes
documentation that
integration andcontrols.
maintenance, wiping are commensurate
early in the system
Implement common
measures to reduce
the risks posed by the
supply chain agentsand third parties.

2019-02-25- 43 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Product Supply Chain Risk Management (cont. from page 43)
memory and factory
reset of theequipment before its
disposal.

with the role of thedevelopment life cycle
Consider anappropriate system or
to provide an
integrated end-to-end
component, its level
important vehicle toprovisioning solution.
of criticality andprotect the supply
exposure to attacks. Manage third-party
chain.
Ensure thevulnerabilities andApply the measures at
Ensure that aauthenticity ofrisks by requiring
each phase of thecomprehensive
supplier to validatethem to be addressed
supply chain andverification processthat counterfeit orby the third parties.
makes suppliers
alternate components contract separately.
consistently adhere to
are not substituted en
Identify the
Conduct random
security requirements.
route.
dependencies andaudits of suppliers to
critical functions for
Anticipate third-party
Consider the entire
verify theirrisks and createdelivery of criticalsupply chain,compliance withservices.
incident plans tobeginning with
contractual
handle potential
measures at the chip
obligations.
situations and provide
manufacturer, and all Consider provisioning
redundancy.
the way to the cloud. solutions forindependent
Establish resilience
components.
requirements for thirdparty critical services
for all operating states(e.g., normal operations, under attack,during recovery).
Indicators ofaccomplishment

Indicators ofaccomplishment

Documents (separateor the part of security
program) refer to thebasic measures for
integrity control ofvaluable components.

Documents
identifying theparticular cases to becontrolled at thecontractual level.

Indicators ofaccomplishment

Indicators ofaccomplishment

A roadmap for periodic
evaluation of risks
posed by the untrusted
supply chain torationalize the validityof assurance
Contracts may specify Security-assurance
requirements andContracting forthe documentation
requirements assponsor theservices and work
protection
certificates and otherappropriate
covers the awareness requirements.
documents to becertification incentives
and responsibilities
provided.
Document templates
for suppliers (iffor the basic integrity
Security assurance
for the identified
needed).
control measures.
reports or certitypical cases (e.g.,
inspection checklists fications are available
to demonstrate theand return forms)
appropriate measurestaken for appropriate
levels of supply-chain
threats.

Table 7-5:

2019-02-25

A document
describing the supply
chains relevant to themain businessprocesses.

Product Supply Chain Risk Management- 44 -

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

A distributor of non-versatile wearable such as fitness bracelets determines thattamper-protection packaging is sufficient to ensure the device has not been
Examplecompromised between the manufacturer and the point-of-sale. The distributor
determines that comprehensiveness level 1 is sufficient as the target for this case.
7.3.2 SERVICES THIRD-PARTY DEPENDENCIES MANAGEMENT PRACTICE
Services Third-Party Dependencies Management (cont. from page 45)
This practice addresses the need to enable trust for partners and other third parties. The ability to have assuranceof the trust of third parties requires understanding of the business and trust infrastructure and possible hidden
threat sources.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Monitor the
reputation ofcontractors andestablish basic
contracts.

Provide quality of the Obtain third-party
services with SLAs and evidence for the
KPIs in the contracts. service quality.

Codify the trust
management policy forcontractors.

Generalconsiderations

At this level, basic
agreements are
established with third
parties to ensurecompliance withsecurityrequirements.

At this level,
At this level, the SLAs,
conformance to the
KPIs, etc. are tracked
agreements isand reports provided.
tracked, and SLAs,
KPIs, etc. are defined.

At this level, anassessment isconducted to evaluate
third parties against
potential risks.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Require all third-party
agents including
technology providers,
partners, contractors
and managed services
to comply with thesecurity requirementsin accordance withestablishedagreements.

Implement theEstablish theRequire a security
defined agreements
contracts, businessassessment to beranging fromexchange
conducted before theagreements, and SLAs extensive control
acquisition or(contracts), to very
define KPIs andoutsourcing to ensure
measurable outcomes limited control
it does not pose(acquire external
and responses tosignificant risks.
noncompliance. The services).
Consider the
KPIS and SLAs for IT,
Ensure the clear
permeation of trust
OT, and IoT areunderstanding ofand document andseparate.
which level ismonitor the basis for
Requirements set by acceptable for thetrust.
system of interest andthe regulating
Identify chains of trust
supporting this levelauthorities are
and consider the trustby the organizational
considered asof every involved party
measures.
obligatory.
and its impact on theConsider the chains of whole level of trust to
Provide thetrust.
the chain.
compliance with2019-02-25- 45 -

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Version 1.0

IoT SMM Practitioner’s Guide

7: Governance Domain

Services Third-Party Dependencies Management (cont. from page 45)
regulations such as
Note that these
GDPR and quality
agreements can berequirements such as
made in a variety ofBaldrige.
ways, as requirements
for the agreements
are very basic andmay not prevent
abuses that exploit
the weaknesses ofcomplex agreements.

Note that risk
management for useof external services isshared with third
parties according tobusiness and legal
agreements.
Track and report IT-,OT- and IoT-incidents
with tools. (At thislevel, they are
typically managed
separately).
Push the quality
requirements andcompliance ofregulations into thethird-party
organizations.

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

General documented SLAs, KPIs are defined Third-party
agreements with third per establishedassessment reports
parties for required
contracts.
covering the SLAs,
security
KPIs and associated
Security policies
requirements.
QoS.
covering timeframes,
General separation of commitment forDocumented
security-related
updates, patches, and requirements forduties andmaintenance ofconducting the
responsibilities
devices that may be in forensic activities inamong parties.
the field for years,
case of incident andand the responsibility the appropriate
for the incidents in
responsibility.
case of violation.

Table 7-6:

Share the risk
management relating
to the use of thirdparty services withthird parties according
to business and legal
agreements andregulatory needs.
Codify the approach sothat requirements andcomplete system view
are well understood.
Treat IT, OT, and IoT
holistically.

Indicators ofaccomplishment
The roadmap for
periodic evaluation ofrisks posed by theuntrustedmaintenance,
identification of new
external agents that
may affect security,and update ofcontractual obligations
accordingly.
Clearly identified anddocumented
connections withlegislation andregulatory
requirements.

Services Third-Party Dependencies Management

A manufacturer of vehicles for public transportation relies on many parts providers,software developers and integrators, resulting in a very complex integration effort.
ExampleSecurity, safety and privacy of information are all important. The manufacturer mustensure that the requirements, trust and risk are all managed across the complete setof partners in the supply chain. Therefore, it sets the maturity target at2019-02-25- 46 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

comprehensiveness level 4, formalized. During a current state assessment, theorganization discovers that it manages KPIs and SLAs, but that it still treats aspects oftrustworthiness and IT and OT separately. It sets its comprehensiveness level at level2, ad hoc.

8 ENABLEMENT DOMAIN
The security enablement domain is based on established security policy and addresses thebusiness risks using the best available means. Security policy and controls are subject to periodic
review and assessment.

8.1

IDENTITY AND ACCESS MANAGEMENT SUBDOMAIN

The identity and access management subdomain aims to protect the organization and control
the use of resources by the identified agents to reduce the risk of information leakage, tampering,theft or destruction.
8.1.1 ESTABLISHING AND MAINTAINING IDENTITIES PRACTICE
Establishing and Maintaining Identities (cont. from page 47)
This practice helps to identify and constrain who may access the system and their privileges.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Basic people anddevice identity.

Dynamic device
identity.

Device identity
management isunified with people
and system-identity
management.

Maintain and control
the use of identities ofpeople, systems andthings throughout theirlifecycle.

Generalconsiderations

At this level, devices
are managed andtracked with simple,
static identifiers.
People may be
managed atorganizational level.

At this level, criticalAt this level, thedevices areorganization
authenticated and the comprehensively
role-based identities manages theare introduced.
identities of people,
systems and thingsand begins to
implement roots oftrust.

At this level, theorganization manages
the full identity
lifecycle and requires
roots of trust for all
identities.

2019-02-25- 47 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Establishing and Maintaining Identities (cont. from page 47)
What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Ensure that valuabledevices in theorganization can be
identified andmanaged.

Identify equipment to
be authorized andprovide theappropriate schemeand technical means
for its identification
and authentication.

Implement inventoryof equipment,
systems and devices
and human identity
management
automatically.

Implement automatedunified identity
management that
addresses the entire
identity lifecycle.

Define the roles forthe staff members
involved into the key
scenarios.

Implement identity
Integrate authenproofing in accordance
tication schemes,
with relevant
including multi-factor regulations or systemauthentication where requirements.
appropriate.

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Ensure that those
who need access canaccess the assets.

Indicators ofaccomplishment

Valuable devices have Each device has aa unique identifier.
unique persistentidentity.
There is anorganizational
Certificates are usedmechanism for thefor mutual
identification of staff authentication withmembers and visitors. other devices and thecloud.

Identity management Unified identity
management covers
uses a known
registration andsolution.
identity issuance,
Key management
usage, re-issuance,
infrastructure may
updating suspension,
support identity
expiration andmanagement by
revocation.
providing trust
All people, systems andanchors for
Human identities arethings go back to aauthentication.
associated with roles.
hardware root of trust.
Authentication
requirements areUser identity proofing
commensurate withmeets system
the risk of therequirements.
transaction.

Table 8-1:

Establishing and Maintaining Identities

A financial institution accepts transactions from a variety of devices and smart
industrial components. The institution must understand and manage the identities
Exampleof all components from cradle to grave. Therefore, it sets the maturity target forestablishing and maintaining identities to comprehensiveness level 4, formalized.
During the assessment, the financial institution realizes that while it manages the full
identity lifecycle for devices, it has not set up hardware roots of trust for many critical
identity elements; hence its current comprehensiveness level for establishing andmaintaining identities is level 3, consistent. The financial institution prioritizes
hardware roots of trust in their roadmap, with a goal of moving to level 4 in the next
assessment.
2019-02-25- 48 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

8.1.2 ACCESS CONTROL PRACTICE
Access Control (cont. from page 49)
This practice’s policy and implementation allow a business to limit access to resources to only the specificidentities that require access and only at the specific level needed to meet organizational requirements.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Constrain the abilityof external agents toaccess devices and IT
components.

Generalconsiderations

At this level, basic
At this level, access
access controls arecontrols consider
applied to devices and both internal andto IT components in a external threats.
IT and OT access are
siloed manner andstill managed
focused mostly on
separately. Third
external threats.
party systems may be
implemented to
manage user accessrights.

At this level, access to At this level, access
IT and OT
control expands tocomponents is
include governanceconsidered
and lifecycle.
holistically, andorganizations begin toautomate accesspermission
assignment.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Implement genericaccess control basedon common-purpose
mechanisms
supported byapplication, service,
operating system,
network or device.

Describe the goals foraccess control forboth external andinternal agents withthe available use
cases.

Ensure that access
control policy isappropriate for bothIT and OT
components.

Define and implement
access management
and lifecycle practices
that address access to
IT and OT systems,
including deprovisioning once users
no longer require
access.

Constrain the abilityof both internal andexternal agents toaccess devices and IT
components.

Manage access todevices and IT
components in a
unified, consistentmanner.

Implement a consistentprocess for managing
access over the
lifecycle of both users
and IT and OT systems,
enforcing access
control with highassurance, monitoring,
testing, and revoking
the rights in a way thatmeets business needs
and constraints.

Define the reference
points at which tomonitor and control
Ensure that theseaccess and implement
common-purpose
access control
Ensure the consistency
mechanisms provide To minimize exposure requirements.
of access control acrossproper segregation of and risk the Trusted
the whole organization
external and internal Computing Base
Subject highlyor system.
agents and limit
should be as small as privileged users to
Conduct access control
access to externalpossible.
screening.
periodic testing
agents.
(penetration testing,2019-02-25

Verify the access
control policy against
these goals.

- 49 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Access Control (cont. from page 49)
red/blue teamexercises).
Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

External perimeter isdefined at the
network level, withlimited permissions
for those accessing
externally, including
employees accessing
remotely.

Organization has
implemented rolebased access control
for both IT and OT
components, but
implementations andpolicies are silo-ed.

Role-based access
control is in place andaddresses both IT and
OT components in a
unified manner.

Access control
governance andlifecycle policies are
documented.

Accounts aresegregated at
operating system orapplication level, andguest accounts areconstrained.

Roles, rights andmanagement are
documented.

Access control rules
follow principle of
least privilege.

Access control at theconnected, enterpriselevel is supported by
Privileged users
understand their roles network, applicationand system level
and responsibilities.
technologies.
For individual
systems, services, and Access control
practices areapplications, access
control is enforced at automated in at least
the proper level and some cases.
appropriately
described, for bothinternal and external
actors.

Access control
practices are mostly
automated, including
governance andlifecycle practices.
Access-control
practices aremonitored and tested
periodically.

Compartmentalization
should be used toprevent breaches
from propagating
between device
components,
hardware, andsoftware.

Table 8-2:

Access Control

A retailer is implementing a state-of-the-art security system, with connected cameras
and inventory sensors. The retailer realizes that camera information is sensitive andExamplethat access must be controlled carefully. They determine that they need to look ataccess control holistically for both IT and OT components in their security system,and they set the target comprehensiveness for access control at level 3, consistent.
During their first assessment, they realize that the previous Chief Information
Security Office (CISO) developed an access-control policy focused only on protecting

2019-02-25- 50 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

against external actors, so they are currently at comprehensiveness level 1, minimal.
They have a lot of work to do to reach their target.

8.2

ASSET PROTECTION SUBDOMAIN

The asset management subdomain is put in place to protect physical and digital assets. This is anarea of strong collaboration between IT and physical security teams.
8.2.1 ASSET, CHANGE AND CONFIGURATION MANAGEMENT PRACTICE
Asset, Change and Configuration Management (cont. from page 51)
This practice constrains the types of changes allowed, when those changes can be made, approval processes andhow to handle emergency change scenarios.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Manageconfigurations andchanges of isolated
assets.

Manage assets as asystem of systems,with hierarchies andinherited policies.

Generalconsiderations

At this level,organizations areaware of which assets
are critical.

At this level,
At this level, asset and At this level, the asset
organizations begin to configuration
management policy
implement formal
management
addresses cradle-toasset management,
programs apply
grave lifecycle of IT andchange management equally to IT
OT assets.
and inventory(hardware andprograms.
software) and OT
assets.
A standard protocol
for device updates
and security renewal
allows to proactively
mitigate emerging
threats and reinstate
the security on
devices that havebeen compromised.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevelManage IT and OT
assets in an
integrated manner.

What needs to bedone to achieve thislevel

Establish andEnsure that asset
Create an asset
document acceptable inventory and assign a management, change
use for critical assets. designated owner for management andconfiguration
valuable assets.
management policies
Classify and label thecover IT and OT
physical andassets.
information assets

2019-02-25- 51 -

Manage the process forthe asset lifecycle fromprovisioning to
replacing, including
emergency changes.

What needs to bedone to achieve thislevel
Expand asset
management policy toprovide a lifecycle
structure for managing
IT and OT assets fromprocurement andenrollment to

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Asset, Change and Configuration Management (cont. from page 51)
Ensure that
acceptable use rules
are followed. These
rules can address
device and media
handling, access
restrictions, limiting
asset distribution to aminimum required tosupport thefunctionality, etc.

decommission andDevelop guidelines for
disposal.
protecting software
Develop procedures
assets, including bootEnsure policy
for handling,process integrity,
addresses bothprocessing, storing,
software integrity
individual components
and communicating(e.g., malware
and complete systems
assets consistent with detection), memory(e.g., plane engine andtheir classification.
protection and securecomplete plane) at all
updates.
stages of the lifecycle.
Create baseline
configurations for
Incorporate principle
systems, change andof least functionality
configurationby configuring
management
systems to provide
procedures where
only essential
appropriate.
capabilities.

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Critical assets havedocumented
acceptable use
policies.

An inventory listing
the assets such as
equipment,
information,
hardware or softwareand considering bothindividual assets andhierarchicalcollections of assets.

Asset, change andconfigurationmanagement
practices integrated
across IT and OT.

Procedures are in place
for hardware
decommissioning anddisposal, withconsideration for thesensitivity of the datathat was processed by
the hardware.

Development andtesting environments
are fully separated
and segmented fromproduction
environments.

2019-02-25

involved in the mainuse cases.

Asset, change andconfigurationmanagement
practices may vary by ConfigurationThe description of the region to address
management
local requirements,
procedures withprocedures establish asuch as GDPR.
connections to use
process for identifying
cases.
items (devices,
Change management
hardware, software,
The asset
procedures include
firmware andmanagement policy is assessments of the
documentation)
appropriate to thepotential security
throughout the systemassets managed and impact of changes.
development life cycle
the system complexity
Assets are disposed of and for managing theand provides thein accordance withconfiguration of thoseframework for asset
regulatory anditems.
management,
environmental
including assignment
As the system
guidelines.
of owners and roles
continues through its
and responsibilities.
lifecycle, new items are
identified and some
Change-management
existing items may noprocedures include
longer need to be
identifying andunder configuration
recording thecontrol.
significant changes to- 52 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Asset, Change and Configuration Management (cont. from page 51)
equipment, softwareand procedures.
Configurationmanagement
procedures address
roles and
responsibilities.

Asset planningconsiders capacity
requirements and looks
to ensure sufficient
capacity to maintain
resource availability.

Baseline
configurations aremaintained andupdated.

Table 8-3:

Asset, Change and Configuration Management

A global health care network manages a large number of connected devices andrelated IT assets, along with sensitive patient data. Given the risk of misuse of those
Exampleassets, the health care network sets a target of comprehensiveness level 4,
formalized, for asset, change and configuration management. During theirassessment, they determine that their formal asset management program applies
more to their OT and device assets than to their IT assets. They are starting to look at
how their practices need to differ based upon regional requirements. Their current
state is comprehensiveness level 2, ad hoc.

2019-02-25- 53 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

8.2.2 PHYSICAL PROTECTION PRACTICE
Physical Protection (cont. from page 54)
This practice’s policies address the physical security and safety of the premises, its people and its systems toprevent theft and ensure the ongoing safe operation of equipment.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Generally, constrain
Establish and manage Automate finer
the access to physical physical security
grained physicalassets.
perimeters.
access control,
customizing
constraints for factors
such as time andmanner of physicalaccess.

Generalconsiderations

At this level, theorganization limits
physical access todevices on a one-offbasis.

At this level, theorganization deploys
physical security
controls for groups
and spaces inaccordance withdefined policy or
requirements.

What needs to bedone to achieve thislevel
Adopt physicalsecurity policies toprotect devices from
accidental or
intentional physicaldamage oroperational
disruption.

What needs to be
What needs to be
What needs to bedone to achieve this done to achieve this done to achieve this
level
level
level
Clearly define security
Define trust zones inAutomate identity
perimeters, with their
IT system architecture
management andsiting and strengthand establish physicalalerting systems todependent upon the
security perimeters inmanage and report on
assets contained within
IT and OT
physical access tothe perimeter and thedeployments tolocations and assets.
results of a risk
separate and protect
assessment.
the systems within
Enforce moreeach zone.
granular access
control rules, such as
time of day.

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Physical security
policies in place forindividual devices.

Security perimeters(barriers such as
walls, card-controlled
entry gates ormanned reception
desks) correspond toestablished trust

Existing IT accessmanagement andmonitoring
infrastructure isextended to manage
access to OT andother physical assets.

Physical barriers,
where applicable,
prevent unauthorized
physical access andenvironmental
contamination.

2019-02-25- 54 -

Address all aspects ofphysical security andsafety, prevent theft,and ensure ongoingsafe operation.

At this level, theAt this level, physicalorganization
protections are wellleverages its identity defined and consistent
management andacross themonitoring systems to organization, address
manage access toboth security andphysical assets.
safety and are
periodically reviewed
and assessed.

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Physical Protection (cont. from page 54)
zones and protect
areas that contain IT
and OT systems.
Access rules enforce
perimeters to limit
human access tocritical IT and OT
systems.
Group policies are inplace to manage
collections of physicalassets.

For physically isolated
components, use ofremovable media anddevices isappropriately
restricted, preferablywith physical lockingof the relevant
connectors andinterfaces.

Physical protection
requirements are
periodically reviewed
and updated at
different stages of theassets’ lifetimes.
The monitoring andalarm systems, whereapplicable, establish
the required level ofresistance to physicalbreak-ins.
Assurance measures
ensure that there areno gaps in theperimeter or areas
where a break-in could
easily occur.

Table 8-4:

Physical Protection

A garment manufacturing plant that produces casual apparel relies upon a handfulof critical systems (both physical machines and the IT system monitoring their
Exampleperformance) to produce their output. Their goal is to protect workers and prevent
assembly line disruptions by establishing perimeters around these critical assets.
Therefore, the plant sets its maturity target for physical protection atcomprehensiveness level 2, ad hoc. When assessing their current state, they note thephysical barriers and proximity cards that control access to their critical systems anddetermine that their current state matches their target.

2019-02-25- 55 -

Version 1.0

IoT SMM Practitioner’s Guide

8.3

8: Enablement Domain

DATA PROTECTION SUBDOMAIN

The data protection subdomain prevents unauthorized data disclosure or manipulation of data,
both for data at rest, in transit and in use. This is important for security, privacy, regulatorycompliance, legal and intellectual property protection.
8.3.1 PROTECTION MODEL AND POLICY FOR DATA PRACTICE
Protection Model and Policy for Data (cont. from page 56)
This practice identifies whether different categories of data exist and considers the specific objectives and rules fordata protection.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Declare that IT and OT Develop data
data should beclassification systems
protected fromwithin discrete
unauthorized access. environments.

Data protection policy Categorize andis unified across IT
consistently protect
and OT.
the data according to
the requirements ofstakeholders
throughout the data
lifecycle.

Generalconsiderations

At this level, basic IT
and OT dataprotections are inplace in accordancewith relevant
regulatory
requirements.

At this level, data isclassified according to
its business andsecurity impacts, butclassification of IT and
OT data is siloed.

At this level, data
At this level, data is
protection policy
considered throughout
looks holistically at all its entire lifecycle andtypes of data, and the in accordance withorganization begins to change andautomateconfiguration
classification andmanagement.
policy.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Implement dataprotection policy
based upon relevantlaws and regulation.

Expand dataprotection policy toinclude dataclassification, tying
the data to its
business and security
objectives withindifferent IT and OT
environments.

Create unified data
policy to address data
generated from andprocessed through IT
and OT sources.

Expand data protection
policy to include thecomplete data lifecycle.

Address the security
concerns for data inmotion, data at restand data in use.

2019-02-25- 56 -

Substantiate dataprotection rules byreferring relevant
standards, guidelines,
and best practices.

Integrate the dataprotection policy withchange andconfiguration
management policy.

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Protection Model and Policy for Data (cont. from page 56)
Determine specificmeasures forprotecting different
classes of data.
Indicators ofaccomplishment

Indicators ofaccomplishment

Policy that reflects
applicable federallaws, directives,
regulations, policies,
standards andguidance.

Indicators ofaccomplishment

Policy defines types of Data classification
data to be protected policy considers theaccording to business business context ofand security
the data.
requirements.
For each class of data
Policy specificallyconsidered
Data residency andaddresses PII,
confidential, policy
regional requirements confidential data and describes required
influence policy.
business critical data. protection measures(e.g., encryption,
Policy stipulates
Access control andaccess control, dataprotection ofother policies areflow control) andPersonally Identifiable aligned with
their required
Information (PII)
protection
implementation (e.g.,according to generally requirements forencryption
recognized rules and different classes ofalgorithms).
regulatorydata.
requirements.
Where encryption
The concrete data
algorithms areprotection measures
recommended, policy(encryption, accessallows for multiple
restrictions, media
options, wherecontrol, isolation oravailable, andbackup) may not berecommends
listed or may bealgorithm agility (thereferred to only
ability to update
generically.
algorithms as needed
Policy, if necessary,with minimal impact
sets constraints onon the rest of theexternal connections, system).
Internet services,
The policy also
cloud storage, anddescribes data
other applications
integrity measuresthat may cause
and their required
intentional or
implementation.
unintentional dataleakage.
Similarly, the policy
may set constraints
on removable media
and BYOD to facilitate
data confidentiality.

2019-02-25- 57 -

Indicators ofaccomplishment
The security policy
defines the types ofsensitive information,
the security goals andthe means used to getthese goals for every
information unit within
the defined trustzones.
For each data type,policy defines how it isrouted into the system,
how it is stored, andthe retention period.
If information istransferred between
components within one
trust zone, the policy
may set the rules forthis transfer andaccountability ormonitoring
requirements.
When informationmust be transferred
between trust zones
with different rules andrequirements, thesecurity policy provides
guidance on
designated policy
enforcement points
betweeninterconnected
systems.
Such guidance may
include prohibiting
information transfer(i.e., allowing readonly), enforcing oneway information flows

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Protection Model and Policy for Data (cont. from page 56)
The policy, if
necessary, sets
backup andredundancy
requirements toaddress data integrity.
Policy specifies
storage life anddestruction policies
for data.

and implementing
trustworthy regradingmechanisms toreassign security
attributes and security
labels.
The policy may
consider mandating
specific architectural
solutions to help
enforce specificsecurity policies.
The policy may
mandate that teams
develop solutions withalgorithm agility in
mind.

Table 8-5:

Protection Model and Policy for Data

A food manufacturing plant is concerned that their secret recipes might be stolen,
through theft or reverse engineering of OT processes. They determine that their data
Exampleprotection policy needs to be unified across IT and OT, and they set their target
comprehensiveness for protection model and policy for data to level 3, consistent.
During the assessment, they note that they have fairly thorough data classification
policies, but they are separate for different environments and not unified across IT
and OT. Therefore, their current maturity is comprehensiveness level 2, ad hoc.

2019-02-25- 58 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

8.3.2 IMPLEMENTATION OF DATA PROTECTION PRACTICES PRACTICE
Implementation of Data Protection Practices (cont. from page 59)
This practice describes the preferred application of data protection mechanisms to address confidentiality,
integrity and availability.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Take advantage of
Apply additionalbuilt-in protection
mechanisms tocontrols (OS, network, protect data groups.
services).

Implement systematic Ensure the required
data protection
protection of each datameasures across the element in transit, atentire system.
rest and in use.

Generalconsiderations

At this level, dataprotection occurs at
the system level,using system-level
controls but few, ifany, third-party
products.

At this level, theorganizationconsiders whether
built-in controls are
sufficient to meetdata protection
requirements fordifferent sub-systems
and considers
whether additional
mechanisms or
products are needed.

At this level, theAt this level, theorganization protects organization
data across the entire implements
system, using multiple mechanisms to protect
mechanisms at
data throughout thedifferent layers.
lifecycle, including at
the destruction phase.
In many cases, dataprotection measures
are automatedWhat needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Use built in controls
to meet the dataprotection policy
requirements.

Assess dataprotection strategy
for broader subsystems or for larger
groups of data.

Implement dataprotection
requirements
systematically.

Ensure that key
management is in place
to protect access toencrypted data.

Ensure that dataprotection controls
Implement relevant
are chosen to fit the
network anddata protection policy
application controls toand rules, asconstrain access torecommended by thedata such as network
standards and best
segmentation,practices.
filtering, virtual
machines, gateways
In many cases, dataand other measuresprotection measures
to manage data flow.
are automated.

Conduct periodic
assessment of data
flow control
mechanisms.

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Data protection
measures addressconfidentiality,

Data protection
measures focus on
restricting data

Data in-motion, inuse, and at-rest, isprotected against

Data encryption
implementation is
implemented with

Employ commonpurpose measures
such as encryption ofdata in motion bycommon-purpose
mechanisms such as
TLS.

2019-02-25- 59 -

Introduce detection
mechanisms
supporting the work ofdata protection policies
and controls.

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Implementation of Data Protection Practices (cont. from page 59)
integrity andavailability
requirements.

access, constraining
data flow, andmonitoring data
access and use.

disclosure andalgorithm agility inuncontrolled changes mind and includes key
by applying functions management measures
such as confidentiality such as PKI and other
Data protection
controls, integrity
trust schemes.
Specific measures aremeasures meet
controls, accessTechnical protectionsprivacy and residency implemented only if it
control, isolation and(such as DLP or service
is prescribed by therequirements from
replication.
restrictions) prevent
policy.
applicable laws andSoftware andthe accidental spilling
regulations.
firmware packages
or unauthorized
and versions aresharing of data.
verified throughappropriate integrity
checking mechanisms.
Data owners have a
choice of mechanisms
to protect data and
opt to implement themost appropriate
controls to address
securityrequirements,
operational
requirements andbusiness need.
Data protection
mechanisms can beeasily replaced asthey become
outdated (forexample, noalgorithms are hardcoded into theimplementation).
These mechanisms
protect the data
against disclosure andintentional or
accidental corruption
according to theconfidentiality,
integrity, privacy anddata retention
policies, and enforce
the control of theinformation flow
within the system andbetween

2019-02-25- 60 -

Version 1.0

IoT SMM Practitioner’s Guide

8: Enablement Domain

Implementation of Data Protection Practices (cont. from page 59)
interconnected
systems based on thedefined information
flow control policies.
The level ofprotection, andassurance on its
enforcement iscommensurate with
the impact of data
loss or falsification.

Table 8-6:

Implementation of Data Protection Practices

A manufacturer of an automotive over-the-air patching gateway must ensure thatcode and information is protected at all times. Data must be protected in transit, at
Examplerest and while in use. Their maturity target for implementation of data protection
practices is comprehensiveness level 4, formalized. The assessment indicates goodpractices for integrity checking, key management and cryptographic agility; in
addition, there are mechanisms in place to prevent data leakage. Their current stateis determined to match their target: level 4, formalized.

2019-02-25- 61 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

9 HARDENING DOMAIN
The security hardening domain comprises organizational and technical countermeasures used toassess, recognize and remediate risks to improve the trustworthiness of the system.

9.1

VULNERABILITY AND PATCH MANAGEMENT SUBDOMAIN

Vulnerability and the patch management subdomain policies and procedures are used to keep
component systems up to date and less prone to attacks due to vulnerabilities in thosecomponent systems.
9.1.1 VULNERABILITY ASSESSMENT PRACTICE
Vulnerability Assessment (cont. from page 62)
This practice helps identify vulnerabilities, determine the risk that each vulnerability places on the organizationand develop a prioritized remediation plan.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Consider whether
widely known
vulnerabilities arepresent inorganizational assets.

Verify whether
Perform holistic
Perform regular deep
business critical assets vulnerability analysis customized
are adequatelyof the system as avulnerability
protected fromwhole using
assessments
known vulnerabilities. automation and third- throughout lifecycle.
party evaluations.

Generalconsiderations

This level meets theneed for overall
protection against
widely deployedattacks and attacks
requiring low skills.

This level meets theThis level meets theThis level meets theneed for improved
need for theneed for theprotection of critical improved protection continuous monitoring
components against of critical components of system
attackers with aagainst attackers with vulnerabilities andmedium skill-level and medium skills andexposures throughout
involves deeper
against insider
the system lifecycle toreview of
attacks.
withstand targeted
vulnerabilities.
attacks.

Assessment isperformed on a
departmental basis
without an overall
organizational plan.
What needs to bedone to achieve thislevel2019-02-25

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Appoint a person for Identify criticalassessing well-known components.
vulnerabilities in any
Appoint personnel,
given component.
detail and prioritize
their responsibilities
for the vulnerability
assessment, andEstablish anassessment scheme
involving regularvulnerability scanningof all assets using
automated tools andthird-party
evaluations.

Implement periodic
activities involving
third parties todiscover thevulnerabilities.

- 62 -

Negotiate themethods, tools, andprioritize the activities

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Vulnerability Assessment (cont. from page 62)
establish reporting
Informally describe
procedures.
the types andexamples information
Describe thesources for the
obligatory andassessment.
optional information
sources for theassessment.

Incorporate threat
intelligence received
from information
sharing forums andsources into
vulnerability
assessment program.

according to the
exposure ofcomponents to attacks
and the associatedrisks.

Review the results ofthird-party
Ensure theassessments and thevulnerability program vulnerability
accounts for changes management programin the organization’s to identify strategic
inventory in near real- process improvements.
time.
Describe thesupposed types ofvulnerabilities, levelof details in theirdescription, format of
the report.
Establish program to
improve quality ofcomponents during
entire lifecycle,
including design anddevelopment.
Establish process forcontinuous
improvement ofvulnerability
assessment process.

2019-02-25

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

The job description
for the responsible
person contains theduty to monitor thedesignated systems
for well-known
vulnerabilities.

The vulnerability
assessment process is
implemented by theefforts of a speciallyformed team, internalor external to theorganization.

Information about
vulnerabilities is
directly requested
from the responsible
personnel whenrequired.

An oversight processensures that
identified
vulnerabilities are
remediated within atime period
appropriate to the

A routine vulnerability Comprehensive
discovery andvulnerability
remediation process assessment process istakes place.
implemented
periodically according
The results of theto the establishedvulnerability
method.
management
program are actively Results of third-party
assessments and thetracked by senior
management and the vulnerability
management program
board.
are reviewed to
The results of theidentify strategic
vulnerability
process improvements.

- 63 -

Indicators ofaccomplishment

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Vulnerability Assessment (cont. from page 62)
severity ofvulnerability.

assessment areavailable by request
and contain enough
List of components
details and score
most critical or known
evaluation for every
for being targets of
discovered
attacks and theirvulnerability.
vulnerabilities arerequested from themaintenancepersonnel whenrequired, including
operating systems,
and general softwareand services.

Table 9-1:

Vulnerability Assessment

A smart manufacturing company would like to ensure they manage theirvulnerabilities holistically using tools and third part evaluators. They set their
Examplecomprehensiveness level for the vulnerability assessment practice to level 3,
consistent. Upon performing an internal assessment, they discover that they haveteam that does not use tools and only looks for known vulnerabilities. They set theircurrent state comprehensiveness level for the practice to level 2, ad hoc.

2019-02-25- 64 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

9.1.2 PATCH MANAGEMENT PRACTICE
Patch Management (cont. from page 65)
This practice clarifies when and how frequently to apply the software patches, sets up procedures for emergency
patches and proposes additional mitigations in the instance of constrained access to the system or other issues
involved with patching.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Follow security
advisories issued by
vendors and install
the provided patches.

Prioritize patchingbased on risks andconfirm that specificcomponents areprotected against themost probableattacks. Periodicallyreview patch status.

Automate patchingwith centralized
support for patch
management.

Protect components
with a long lifecycle
and those that are noteasily patched due tocertification oroperational
requirements.

Generalconsiderations

This level implements
a manual process for
installing software
security patches asprovided by vendors.

This level defines a
process for updating
not only the softwarethat is most exposed
to attacks, but also
the components
whose compromise
may lead to the direst
consequences andimplements a process
for periodic updatesof software based on
the results of risk
analysis andvulnerability
assessment.

This level implements
a centralized andautomated process
for patch updates for
all resources,
including cloud andedge.

This level provides for
managing components
and devices with longlife cycles and thosethat are not easily
patched by managing
patching over the life
cycle as well as using
other techniques toaddress vulnerabilities
addressed by patches.

A standard process
for delivering OS andapplication updates
ensures seamless andtimely response to
emerging security
issues.

2019-02-25

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Establish the rules for
installing software
patches provided by
vendors.

Prioritize the software Establish the rules for
update process
patching uniformly
according to the risk and consistently using
analysis andautomation andvulnerability
centralized
assessment results.
management.

Establish and manage
patch management
process continuously
over time withconsiderations for the- 65 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Patch Management (cont. from page 65)
Adjust the automatedInclude theupdates where
preliminary testing of
possible.
the security patches
and updates whererequired.

Indicators ofaccomplishment

Indicators ofaccomplishment

Policy for applying the The information
vendor patches.
about available
patches is obtained
The components
either automaticallyconnected to theor from the specificInternet obtain the
security advisories
security updates more
provided by vendors,or less periodically,
security companies,
while other softwareand CERTs.
and devices are
updated in case of
There are responsible
security incident, or
personnel that may
upon obtaining theprovide thenotification about
information about
serious or mass attack status of softwarethat may affect them. updates by request.

Initiate the process of
replacing theappropriate softwarewith another version
or other similarsoftware when it is
not possible to installa security update thatis necessary to
decrease the risks toacceptable values.

lifecycle of both IT and
OT components.
Examine the softwareof critical systems tounderstand it deeply,
including thevulnerabilities leading
to patches.

Indicators ofaccomplishment

Indicators ofaccomplishment

A scalable andsystematic risk-based
approach to software
patching or
replacement is inplace.

Continuous patch
management is linked
to a continuous risk
management activity.

Consideration andprotection of longDecision-making
lifespan systemstrategy for the cases components where
where immediatecontinuous patching ispatching is not
not feasible.
applicable.

IT and OT are handled
separately. Patching isreviewed periodically.
Consequences ofvulnerabilities
associated with
software components
being exploited areunderstood anddocumented.
Patch management isprioritized and theorganization
maintains awarenessof available patches.

Table 9-2:

2019-02-25

Patch Management- 66 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

A supply chain company has sensors and devices installed in their depots as well as
in vehicles and shipping containers and packages. They would like to be able to
Examplemanage the security, firmware updates, and patches for their devices centrally andsecurely patch over the air. They set the target comprehensiveness to level 4,
formalized. Upon internal inspection, they discover that they receive pathinformation automatically for their IT systems, but their IoT device management isperformed separately and manually. They set their current level ofcomprehensiveness to level 2, ad hoc.

9.2

SITUATIONAL AWARENESS SUBDOMAIN

The situational awareness subdomain comprises techniques and organizational and community
activities used to achieve an understanding of the current security state enabling an organization
to prioritize and manage threats more effectively.
9.2.1 MONITORING PRACTICE
Monitoring Practice (cont. from page 67)
This practice is used to monitor the state of the system, identify anomalies and aid in dispute resolution.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

From time to timecheck individual
diagnostic logs ofcomponents, devices,sensors and systems.

Obtain status eventsfrom devices andcheck for correct
expected operation.
Malware is detected.

Collect, consolidate,
and analyze monitoring information
holistically from avariety of sources
with human expertisefor analysis.

Use automation andcontinuous monitoringwith analytics toidentify concerns.

Generalconsiderations

This level implements
the basic monitoringof security eventsusing the built-in
mechanisms ofcomponents, devices,sensors, operating
systems, services, andsoftware.

This level employs
events generated byindividualcomponents, devices,sensors and systems
to detect security
issues. Malware is
detected.

At this level,
information fromvarious monitoringsources areconsolidated andmanaged holistically.

This level implements
the continuous realtime monitoring of all
relevant types of
security events using
the most appropriate
means and automation
for analysis.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Follow existing
general security
guidance on basic
security monitoring
using existing

Consider events
Consider different
caused by both
sources and various
human actions (e.g., additional advanced
access to the sensitive monitoring systems
resources, credentials

Automate most of theanalysis of security
events and conduct
required manual

2019-02-25- 67 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Monitoring Practice (cont. from page 67)
mechanisms without
any specific concerns
for the particulars of
the specific system.

management) and(intrusion detection
existing processes
systems, SIEMs, etc.).
(e.g., software
Involve skilled
updates, periodic onsecurity personnel ordemand malware
Assign thethird-partyscans). Failure
responsibility for thecontractors that track
reporting provides
analysis of security
security events andinsight into device
related events is toprovide information
and application
the system
about the current
failures and visibility
administrator or othersecurity state to theinto emerging security
person responsible
responsible
threats.
for the software,stakeholders.
system and network Focus on the events
that may have mostin daily use.
Protect thesignificant impact on monitoring
the normal system
information, forfunctioning, so theexample with securerecommendations for logging.
analysis refer the
results of risk
assessment.

Indicators ofaccomplishment

Indicators ofaccomplishment

Responsible
personnel who areaware of the current
security state.

Use of general
Monitoring
monitoring
information ismechanisms is related combined to create ato potential
consolidated view
consequences of high relevant to the main
The analysis of
impact andrisks.
security state is based
documented.
Additional tools andon basic indicators
techniques beyond
such as the absence
Malware detection
generic tools areof anomalies inprocedures andsystem logs.
techniques have been deployed andappropriate expertiseestablished.
is engaged.

Table 9-3:

Perform themonitoring at various
system levels – hosts,
network, specificequipment and may
involve the skilled
security personnel or
third-party contractors(e.g., in a form ofSecurity Operation
Center).
Implement the wholecycle of monitoringfrom establishingincident indicators tied
to risks to theprotection and backup
of monitoring data.
Test and continuously
improve detection
processes.

Communicate theinformation about
events within theorganization.
Indicators ofaccomplishment

review whereappropriate.

Indicators ofaccomplishment
Continuous monitoring,use of automation foranalysis, protection ofmonitoring data andappropriate expertise isengaged.
The description of
revealed incident isgiven in terms ofbusiness security
objectives.

Monitoring

An oil and gas company conducts a current state assessment of their operations andidentifies that they are manually viewing device logs to identify any potential
Exampleproblems and alerts. They set their maturity to comprehensiveness level 1, basic.
They would like to transition to an automated system that will monitor all their
2019-02-25- 68 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

machines and devices and allow operators to view the results and act on them. They
set their target Comprehensiveness Level to 3, consistent and begin planning toaddress the gap.
9.2.2 SITUATIONAL AWARENESS AND INFORMATION SHARING PRACTICE
Situational Awareness and Information Sharing (cont. from page 69)
This practice helps organizations be better prepared to respond to threats. Sharing threat information keeps
systems up to date.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Obtain information on Have a general
Learn information
external incidents as awareness of external about external
needed. Provide some incidents andincidents in
information to
implement a policy
systematic manner.
external parties need- sharing information to Information sharing
to-know and asexternal parties on a policy supports
needed.
need-to-know basis. responsible
disclosure.

Generalconsiderations

This level defines
This level defines arecommendations for policy on incident
sharing information
information sharing,
about serious general including when, how
incidents to external and to whom
parties but decisions information is to be
are made on an adshared.
It also includes
hoc basis.
Awareness of external general awareness ofincidents is based on external information.
the most publicized
incidents.

This level makes
This level supports
awareness of external sharing of zero-day
incidents systematic. vulnerabilities and isapplicable if the
security assessment
and testing activities
are implemented
within theorganization.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Specify the incident
and vulnerability
disclosure policy
according to thelegislative andregulatory
background andnecessary expertiseexchange
considerations.

Analyze which typesof security incidents
may particularly
affect the system ororganization.

Share incident
information about
general security
incidents withexternal parties.

2019-02-25

Maintainsubscriptions tosecurity advisories,
mailing lists ofvendors, sector
communities to keep
Provide appropriate
the situational
instructions on whenawareness about
to share information
security issues arisingon incidents, toin the particularwhom, and how.
sector or relevant tothe used
Devices automaticallytechnologies.
produce failure
Obtain information
reports that can beshared withfrom software and- 69 -

Set up a two-way
sharing of zero-day
threats and incidents
across the industry.

What needs to bedone to achieve thislevel
Share the zero-day
vulnerabilities with thevendor of the software
or equipment andinform the relevant
authorities, agencies
and security companies
to enable joint work to
mitigate the effect ofpossible future
exploitation of thesevulnerabilities in thewild.

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Situational Awareness and Information Sharing (cont. from page 69)
General security
incidents include
malware infection,
unauthorized accessto the service orsoftware,compromised
credentials, use ofunauthorized
equipment or media,
etc.

manufacturers andcentral management
systems.

Include into theappropriate
instructions therecommendations on
the means andprocess of thecommunication
regarding security
issues (the intended
recipients, way ofcommunication, etc.).

Define the policy
describing theappropriate use of data
about security
incidents, discovered
vulnerabilities, andapplied practices fromother participants of
IoT community andspecifying how andwhen to collaborate
with regulatory
authorities,
standardization
Devices automaticallycommittees, andproduce failure
voluntary organizations
reports that can befor providing theshared withfeedback on the
manufacturers andregulatory acts,
central management
guidelines, standards,
systems.
and recommendations.
Include into the
instructions for the
personnel andguidance for theconfiguration ofmonitoring software
the recommendations
on the means andprocess of thecommunication (theintended recipients,
way ofcommunication, etc.)
and the general
strategy in disclosureof vulnerabilities tothe external agents(e.g., responsible
disclosure).

Awareness andcommunication of the
security incidents isneed-to-know.
Keep abreast of
product recalls andnews.

2019-02-25

services, including
anti-malware
solutions and othersecurity software that
perform monitoringof the security state
automatically sending
reports about
detected security
events andvulnerabilities upon
appearance thisinformation.

Indicators ofaccomplishment

Indicators ofaccomplishment

Recommendations on
sharing information
about security
incidents clarify
sharing practices
while limiting sharing
as much as possible,

Clarity on the when, Systematicwith whom, and how approaches toto communicate
situational awarenesssecurity incidents is
are in place.
provided in the policy.
Information sharing
policies support- 70 -

Indicators ofaccomplishment

Indicators ofaccomplishment
Information sharing
about zero-day
vulnerabilities is
codified in policy andpractice.

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Situational Awareness and Information Sharing (cont. from page 69)
but decisions are
made ad hoc.

Table 9-4:

responsible
Personnel are aware
disclosure.
of general news about
incidents.

Situational Awareness and Information Sharing

A retailer determines that its comprehensiveness target for situational awarenessand information sharing for its stores should be at level 2, ad hoc, based on the need
Exampleto generally protect consumer information at the point of sale. As it introduces newtechnology involving facial recognition that is connected to the cloud, the retailer
recognizes the need to consider policies for consumer privacy data for storage andtransmission and sets its comprehensiveness target at level 3, consistent.

9.3

EVENT AND INCIDENT RESPONSE, CONTINUITY OF OPERATIONS SUBDOMAIN

Event and incident response subdomain comprises a combination of policy and technicalactivities designed to allow an organization to respond to incidents swiftly and to minimize
disruption to the organization enabling the organization to continue its core business.
9.3.1 EVENT DETECTION AND RESPONSE PLAN PRACTICE
Event Detection and Response Plan (cont. from page 71)
This practice defines what a security event is and how to detect and assign events for investigation, escalate themas needed and respond appropriately. It should also include a communications plan for sharing information
appropriately and in a timely manner with stakeholders.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Define incidents andbasic response
actions.

Provide guidance on
how to detect andrespond to incidents
that can impact
critical components.

Set up the basis forthe automatic
execution of response
procedures within theorganization.

Generalconsiderations

This level supports
sharing of zero-day
vulnerabilities and isapplicable if the
security assessment
and testing activities
are implemented
within theorganization.

At this level,
individual
departments
implement their own
incident responseplans to establish anddocument theprocedures andactions to respond to
defined types of

The organization has The organization has
a unified andan integrated incidentautomated (or semi- response program that
automated) cycle ofincludes partners andincident detection,other organizations.
response, and support This level enables themonitoring andof operations
analysis of additional
continuity.
data that can be used
to detect an attack at

2019-02-25- 71 -

Include partners andother organizations in
an incident response
approach that also hasa view beyond isolated
incidents, enabling theorganization to detect
early stages of an
attack as well prevent
incidents.

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Event Detection and Response Plan (cont. from page 71)
significant incidents
that can impact
critical components.

early stages or toprovide responses toprevent the
exploitation ofvulnerabilities.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

The policy addresses
well-known incidents
by type andresponsible
personnel.

Use advanced
Determine which
security incidents may monitoring
techniques andrequire immediate
reaction, enumerate automated solutions
the types, and outline such as network andthe steps that should device logging,
IDS/IPS, NGFW, forbe taken to respondincident detection
to the incident andand analysis.
mitigate damage.

These incidents may
include denial-ofservice attacks,
unauthorized accessto networks,
accessing protected
and private
information, defacing
web pages, misuse ofservices, etc.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel
Consider the secondary
symptoms of the
security violation orsystem misuse such as
unusually heavy traffic
or high CPU usage,
locked-up accounts,
cleared log file,
unexpected changes in
configuration, andcorrelate these
symptoms.

Implement
automated
notification about the
security incident
Optionally implement
including all relevant an approach based on
information delivered the correlation of
Employ basic analysis,
to those responsible symptoms to prevent
Base the detection
including manual
for system recovery, the incident.
actions for every type deep examination ofremediation andof security incident on the incident-related
Precisely define themaintaining
clear indicators ofdata for certain use
notion of a securitycontinuous systemsecurity violation.
cases.
relevant event that is
operation.
typically wider than aConsider the
Perform analysis as asecurity violation.
information aboutpart of forensics
Integrate the incident
information flows and activities.
response with
Implement thegeneral use of IT
Situational Awareness
Align the notification
response to prevent
components foras well as theactions withsuch events.
incident examination.
Remediation,
situational awareness
Recovery, andDefine the basic
policy.
Continuity of
response plan that
Operations SMM
does not consider any Prescribe thepractices.
response thatdeviations from theincludes the actionsprescribed actions.
for the system
recovery,
remediation, andsupport of operations
continuity alsoaligned withappropriate policy.

2019-02-25

Describe thepersonnel roles andorder of operations
when a response isneeded.

- 72 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Event Detection and Response Plan (cont. from page 71)
Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Individuals are awareof the need torespond to security
events based on clear
indicators of security
violations.

Departments have asystematic anddocumented
approach to incidents
with varying degrees
of manual analysis ofindicators.

Unified approach toincident detection
and response.

Shared approach toincidents with partners
and other third parties.

Incident response
plan is accepted.

Analysis approach goesbeyond individual
incidents, creating
broader understanding
and supporting theability to detect andrespond to secondary
Incident response andindicators of an attack
recovery plans arethat may be precursors
tested.
to a security violation.
Incident response andrecovery plansincorporate lessons
learned fromincidents andresponse strategies
are updated
appropriately.
Advanced tools andsome degree ofautomation ofincident detection
and analysis has been
implemented.

Public relations aremanaged forincidents.

Table 9-5:

Event Detection and Response Plan

A healthcare provider determines that their target comprehensiveness level is 2, ad
hoc, as they would like to have an internal organization with clear roles that can
Exampleaddress incidents, perform analysis and generate a response. Upon review of theircurrent state they determine that they have some individuals across the organizationthat respond to incidents in their respective areas when an incident is detected. They
determine that they are at a comprehensiveness level 1, basic, and that they need toestablish a more formal organization and document procedures.

2019-02-25- 73 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

9.3.2 REMEDIATION, RECOVERY AND CONTINUITY OF OPERATIONS PRACTICE
Remediation, Recovery and Continuity of Operations (cont. from page 74)
This practice is a combination of technical redundancies whereby trained staff and business continuity policy help
an organization recover quickly from an event to expedite returning to business as usual.
Comprehensiveness Comprehensiveness ComprehensivenessComprehensivenessLevel 1
Level 2
Level 3
Level 4
Objective

Provide basic
instructions for thesystem recovery.

Define a policy andEnable automatedplans to handle
remediation andpossible known
recovery procedures.
incidents and to
confirm the complete
recovery of thesystem.

Support technical andorganizational
measures to facilitatequick system recovery
and establish policies
and technologies toenable forensic
investigations.

Generalconsiderations

This level defines theconcrete actions forthe remediation andrecovery of the mostcritical components.

This level supports
continuity ofoperations by simple
redundancy measures
such as data backups
and has a
documented plan for
remediation andrecovery.

This level uses
automation to enable
remediation andrecovery.

This level includes
regular periodic testingof remediation andrecovery procedures toverify the ability tomaintain continuity ofoperations. It also
includes technical andpolicy approaches toenable forensic
examination of systems
following an incident.

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

What needs to bedone to achieve thislevel

Identify criticalcomponents andprovide basic
instructions forrecovery based on
general mechanisms.

Define a remediation
and recovery policy,
establish contingency
plans for particularuse case scenarios.

Automated removal
of malware, restoring
backup data to
databases,
systematicallyremoving temporary
containment actions,and restarting all
operational systems
and applications.

2019-02-25

Establish the policy for
regular and planned
testing of continuous
operation at ascheduled time toverify that the backup
Maintain all backup
and fail-over systems
systems to the same
will work properlylevel as the primary
when called upon andsystems.
that the system can be
Establish measures torestored to a preDefine procedures forconfirm complete
incident state.
operational
recovery.
Support automatedcontinuity.
Consider additional
operations continuity,
Upon detection of aapproaches toenabling the use of
security incident
recovery such as using
redundant mechanisms
these mechanisms
redundant
and data upon
immediately enable
components or onreceiving information- 74 -

Version 1.0

IoT SMM Practitioner’s Guide

9: Hardening Domain

Remediation, Recovery and Continuity of Operations (cont. from page 74)
demand data
recovery.

the secondary
mechanisms.

about the possible
interrupt or damage ofprimary ones.

Support operations
Devices can be
Ensure that recovery
continuity based on
automaticallyboth restores theuser observation
restored to a securesystem and makes it(after-the-factstate following aapproach). Note, that more secure bycompromise.
keeping the same
this approach canCompartmentalization
operational capabilities
carry number ofthrough hardwareand protecting against
adverse risks. In
enforced barriers
particular it does not the exploit that caused
between software
the incident.
prevent damage tocomponents preventthe primary equipa breach in one from
Establish the policies
ment or otherpropagating to others.
consequences of the and technologies toincident while preven- enable forensic
ting the interruption. examinations.
Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Indicators ofaccomplishment

Documented
instructions forrecovery of individualcomponents.

A documented
remediation andrecovery policy
supported byfunctioning backup
systems and redundant components
used to enable
recovery of IT and OT
components.

Use of automatedmechanisms tomaintain continuity,
including fail-over.

Planned and periodic
testing of recovery
procedures, use of
automation andtechniques to improvesystem resilience.

Incidents are contained and mitigated.
Newly identified
vulnerabilities are
mitigated or documented as acceptedrisk.

Table 9-6:

Business system
availability metrics
are established andsupported withprocesses andtechnologies.

Policies andtechnologies in place toenable forensic
investigations toenable learning andsystem improvement.
Reputation is managed
for incidents.

Remediation, Recovery and Continuity of Operations

A city traffic department determines that they need to be able to recover quickly
from any possible disruption to the system and to be able to have processes that
Exampleenable them to maintain continuity of operations, learn and improve over time. They
identify their target comprehensiveness as level 4, formalized. The current state
assessment identifies automated recovery systems, but they are disconnected andlocalized damage can occur. They rate their current comprehensiveness level as 3,
consistent.
2019-02-25- 75 -

Version 1.0

IoT SMM Practitioner’s Guide

10: Comprehensiveness Level Definition Guide

Part III: Comprehensiveness Level Definition Guide
10 COMPREHENSIVENESS LEVEL DEFINITION GUIDEThis guide recommends for consideration the following domain goals corresponding to thecomprehensiveness levels for these domains.
DomainTypical Goal

ComprehensivenessLevel

The goal of Security Governance is to
set up a general base for security considerations

1 / Minimum

establish baseline security measures

2 / Ad-hoc

facilitate implementation of security capabilities

3 / Consistent

set a clear governance structure and processes

4 / Formalized

The goal of Security Enablement is toenable the use of available security controls

1 / Minimum

implement security controls according to the known usage
scenarios

2 / Ad-hoc

employ both built-in and additional mechanisms to cover the
known risks

3 / Consistentestablish the process to address the risks by the best available
means

4 / Formalized

The goal of Security Hardening is to
apply the recognized practices of cyber hygiene

1 / Minimum

improve system protection according to its needs and priorities

2 / Ad-hoc

employ the well-recognized methods and tools enabling
trustworthiness3 / Consistentestablish the continuous process of supporting thetrustworthiness objectives

4 / Formalized

Table 10-1:

Comprehensiveness Level Definition Guide

This guide recommends for consideration the following typical needs corresponding thecomprehensiveness levels for subdomains.

2019-02-25- 76 -

Version 1.0

IoT SMM Practitioner’s Guide
Subdomain

10: Comprehensiveness Level Definition Guide

Typical Needs

Comprehensiveness
Level

Strategy and Governance refers to the need forvision, scope and security objectives

1 / Minimum

the most appropriate best practices

2 / Ad-hoc

well-recognized approaches and standards

3 / Consistent

support of business processes, legal, operational, and otherissues

4 / Formalized

Threat Modeling and Risk Assessment refers to the need forreview of current threat landscape

1 / Minimum

understanding the system and technology vulnerabilities

2 / Ad-hoc

comprehensive description of relevant risks

3 / Consistenta holistic and systematic approach to risk management

4 / Formalized

Supply Chain and External Dependencies Management refers to the need fora reputation check for suppliers and contractors

1 / Minimum

security assurance artifacts for the supply chain

2 / Ad-hoc

certificates and other guarantees by trusted authorities

3 / Consistentcontrol of exposure to possible harm from suppliers andcontractors

4 / Formalized

Identity and Access Management refers to the need forsupporting elementary entities for the basic usage scenario

1 / Minimum

differentiating the actors for the general access scenarios

2 / Ad-hoc

employing best practices for supporting sophisticated accessscenarios

3 / Consistentcomprehensive protection against the risks connected tounauthorized access

4 / Formalized

Asset Protection refers to the need foraccounting for the use of both digital and physical assets

1 / Minimum

monitoring of the assets on a use case basis

2 / Ad-hoc

managing and protecting the assets of various types

3 / Consistentassurance of the enforcement of asset management policies

4 / Formalized

Data Protection refers to the need forthe general maintenance of data confidentiality and integrity

2019-02-25- 77 -

1 / Minimum

Version 1.0

IoT SMM Practitioner’s Guide

10: Comprehensiveness Level Definition Guide

an increased level of assurance for some data

2 / Ad-hoc

the implementation of recognized data protection policies andmethods

3 / Consistentassurance of protection of critical business information both intransit and at rest

4 / Formalized

Vulnerability and Patch Management refers to the need forkeeping the systems up to date and less prone to attacks

1 / Minimum

enforcing a regular update policy for critical components

2 / Ad-hoc

supporting automated updates configured specifically for thecase

3 / Consistentplanning both a regular update process and emergency scenarios
for critical zero-days

4 / Formalized

Situational Awareness refers to the need forkeeping minimal awareness of the security-related events

1 / Minimum

specific attention to some kinds of security events

2 / Ad-hoc

comprehensive monitoring and regular sharing of security
related information

3 / Consistent

providing and managing all information relevant totrustworthiness aspects

4 / Formalized

Event and Incident response, Continuity of Operations refers to the need forchecking for system recovery after incidents

1 / Minimum

ensuring the recovery of separate system components orprocesses

2 / Ad-hoc

supporting an automatic recovery procedure where possible andhaving appropriate reporting3 / Consistent

having swift incident response and reducing harm to thebusiness both by technical and organizational means

4 / Formalized

Table 10-2:

Comprehensiveness Level Definition Guide

This guide recommends for consideration the following practice purpose definitions
corresponding the comprehensiveness levels for these practices.

2019-02-25- 78 -

Version 1.0

IoT SMM Practitioner’s Guide
Practice

10: Comprehensiveness Level Definition Guide

Typical purpose definition

ComprehensivenessLevel

The purpose of Security Program Management is todescribe the general security provisions

1 / Minimum

reference the relevant security objectives and how they are
addressed

2 / Ad-hoc

cover the general topics of recognized security management
standards

3 / Consistent

implement the clear planning, timely provision and control of
security activities

4 / Formalized

The purpose of Compliance Management is tobe aware of compliance drivers

1 / Minimum

consider some optional compliance requirements for
implementation

2 / Ad-hoc

implement obligatory compliance requirements

3 / Consistentmonitor evolving standard requirements for compliance

4 / Formalized

The purpose of Threat Modeling is torefer to general IT security issues as threats

1 / Minimum

identify and describe threats in an ad-hoc manner

2 / Ad-hoc

describe and classify threats in an accurate (optionally formal)way

3 / Consistentreveal and clearly describe IT factors both known and specificthat may put the system at risk

4 / Formalized

The purpose of Risk Attitude is toinformally define the notion of risk

1 / Minimum

differentiate the importance of risks

2 / Ad-hoc

measure and appropriately manage the risks

3 / Consistent

use a risk management framework and processes

4 / Formalized

The purpose of Product Supply Chain Risk Management is tomonitor the vulnerabilities and patches for the suppliedcomponents

1 / Minimum

implement some security testing for the supplied components

2 / Ad-hoc

obtain certificates or other security assurance artifacts for the
essential components

3 / Consistent

apply a supply chain risk management policy

4 / Formalized

The purpose of Services Third-Party Dependencies Management is to2019-02-25

monitor the reputation of contractors

1 / Minimum

provide for quality of services through contractual agreements

2 / Ad-hoc- 79 -

Version 1.0

IoT SMM Practitioner’s Guide

10: Comprehensiveness Level Definition Guide

obtain third-party evidence of the service quality

3 / Consistent

apply as uniform trustworthiness management policy tocontractors

4 / Formalized

The purpose of Establishing and Maintaining Identities is tomaintain one or several accounts in the same or a very similarway

1 / Minimum

manage the identities for several groups of people, systems orthings

2 / Ad-hoc

support a diverse range of identities leveraging automatedmechanisms

3 / Consistentmaintain and control the use of identities of people, systems andthings throughout their lifecycle

4 / Formalized

The purpose of Access Control is to
only constrain the ability of external agents to access the system

1 / Minimum

consider the role of the subject and control the appropriate
access rights

2 / Ad-hoc

Use available access control policies with a proper level ofassurance

3 / Consistentmaintain an authorization scheme strictly aligned with businessneeds and constraints

4 / Formalized

The purpose of Asset, Change and Configuration Management is to
track the infrequent changes in assets and configurations

1 / Minimum

follow some specific rules to manage possible changes to thesystem

2 / Ad-hoc

support change management procedures for the number ofassets and/or configurations

3 / Consistent

regulate the process for the lifecycle of assets from provisioning
to replacement, including emergency changes

4 / Formalized

The purpose of Physical Protection is togenerally constrain the access to physical assets

1 / Minimum

customize the access constraints to consider time and manner ofphysical access

2 / Ad-hoc

automate adjustable physical access control using specificidentity tokens

3 / Consistentaddress all aspects of physical security and safety, prevent theft,and ensure ongoing safe operation

4 / Formalized

The purpose of Security Model and Policy for Data is to2019-02-25

declare that data should be protected from unauthorized access

1 / Minimum

set simple data categorization and appropriate constraints

2 / Ad-hoc- 80 -

Version 1.0

IoT SMM Practitioner’s Guide

10: Comprehensiveness Level Definition Guide

define the particular approach and roles/attributes forcontrolling the access to data

3 / Consistentcategorize and consistently protect the data according to therequirements of stakeholders

4 / Formalized

The purpose of Implementation of Data Protection Controls is totake advantage of built-in protection controls (OS, network,
services)

1 / Minimum

configure built-in controls and ensure that their usage fits thedata protection goals

2 / Ad-hoc

support the proper application of data controls according torecognized standards

3 / Consistentensure the required protection of each data item both in transit
and at rest

4 / Formalized

The purpose of Vulnerability Assessment is toconsider whether widely known vulnerabilities are relevant tothe system

1 / Minimum

check whether the specified components are prone to attacks

2 / Ad-hoc

get an objective third-party evaluation of vulnerabilities andexposures

3 / Consistent

perform regular deep customized security inspections

4 / Formalized

The purpose of Patch Management is toconsider the security advisories issued by vendors and install theappropriate patches

1 / Minimum

check that specified components are protected against the mostprobable attacks

2 / Ad-hoc

establish automatic update procedures where possible

3 / Consistentenforce a system policy to guarantee the continuous protection
against known attacks

4 / Formalized

The purpose of Monitoring Practice is tofrom time to time check the system logs for diagnostic purposes

1 / Minimum

periodically check events indicating how properly the criticalprocesses execute

2 / Ad-hoc

collect and analyze security relevant information both with builtin and specifically designed tools

3 / Consistent

act as catalyst and capacity-builder for the continuous system
protection

4 / Formalized

The purpose of Situation Awareness and Information Sharing is toobtain some relevant external information on an ad-hoc basis

2019-02-25- 81 -

1 / Minimum

Version 1.0

IoT SMM Practitioner’s Guide

10: Comprehensiveness Level Definition Guide

enable personnel to consistently use relevant external
information feeds

2 / Ad-hoc

consider on a case basis sharing internal data with authorities
and community

3 / Consistentestablish a two-way sharing of zero-days and incidents across theindustry

4 / Formalized

The purpose of Event Detection and Response Plan is todefine specific incidents and basic actions to react

1 / Minimum

provide guidance for critical components on how to detect andrespond to incidents

2 / Ad-hoc

set up the basis for automatic execution of response procedures

3 / Consistentcreate controls to detect incidents, assign them for investigationand escalate as needed

4 / Formalized

The purpose of Remediation, Recovery, and Continuity of Operations is to
give basic instructions for system recovery

1 / Minimum

handle known incidents and check whether the system iscompletely recovered

2 / Ad-hoc

Enable automatic execution of remediation and recovery
procedures

3 / Consistent

support a combination of both technical and organizational
measures facilitating quick system recovery

4 / Formalized

Table 10-3:

2019-02-25

Comprehensiveness Level Definition Guide- 82 -

Version 1.0

IoT SMM Practitioner’s Guide

11: Case Study Approach

Part IV: Case Studies
To increase the usefulness of the SMM, we include several case studies for:•••a smarter data-driven bottling line,
an automotive gateway supporting OTA updates andconsumer (residential) security cameras.

The organization of the case study material is consistent, as described below.

11 CASE STUDY APPROACH
Each case study presents the relevant use case descriptions, SMM profiles and explanation of theidentification of comprehensiveness levels and scope for each domain, subdomain and practice.
The explanation of the purpose and form of the content is not repeated in the case studies.
Each case study is organized as follows:
•
•
•
•
•

Case study background and problem description.
Factors to consider in the case study system analysis.
The prioritization of the security domains.
The security needs for subdomains.
How to validate the purpose of security practices.

11.1 CASE STUDY BACKGROUND AND PROBLEM DESCRIPTION
Each case study starts with the description of its background, the problem the SMM aims to solve
and the approach taken. This is followed by a section on establishing the security maturity target.

11.2 FACTORS TO CONSIDER IN THE CASE STUDY SYSTEM ANALYSIS
To apply the security maturity model, analyze use cases to determine the relevant concerns, risks,and constraints and identify and describe all security assumptions, goals, and requirements. Thenprioritize activities and perform a security maturity evaluation and enhancement.
The analysis of a new or an existing deployed system should consider the following factors:
Size and coverage: Estimate how big the organization or system is, or how many consumers will
have access to the device, solution or system under examination.
Exposure: Estimate how many kinds of external connections exist and how they might becompromised. Enumerate the external connections. Find out whether there are security
vulnerabilities or natural exposures for similar systems or organizations.
Threat landscape: Evaluate the threat environment, the types of threat actors, and how
aggressive the threat actors in the environment for the given system are.
Best practices: Find out whether there are known best practices for improving security for similarsystems or organizations.
2019-02-25- 83 -

Version 1.0

IoT SMM Practitioner’s Guide

11: Case Study Approach

Experience. Find out whether there are known security incidents for similar systems ororganizations.
Urgency: Evaluate the urgency of threats and risks and prioritize according to urgency.
Threat impact: Consider the extent of consequences related to the threats. Do they affect safety,
the environment, community or “only” production? Trustworthiness aspects such as safety andprivacy should be considered.
Constraints: Identify the constraints that functional and non-functional requirements may poseon the implementation of security practices. Evaluate the trade-offs.
Trust: How many people require extended privileges to enable the system to function and how
does this vary during the lifecycle of the project (during installation, maintenance, everyday work,etc.)? How many people have physical and other privileged access to sensitive physicalcomponents or sensitive information? What are the identity management requirements? How istrust in people established and managed?
Timeline: Establish times and expected results for every milestone and plan for a repeated
improvement lifecycle.
Expected results: Articulate the goals of the security maturity evaluation and enhancement.
Dependencies: Outline project dependencies, including the specifics of the interdependencies ofthe security functions to be implemented.

11.3 PRIORITIZING THE SECURITY DOMAINS
Once a clearly written description of all the assumptions, goals, and requirements of the system
has been created, the next step is to evaluate the priority and goals for the security maturity
domains. The idea is to set up a basic comprehensiveness level for each domain (governance,
enablement and hardening) according to the general goal connected to the appropriate type ofactivities. This comprehensiveness level may then be increased for certain subdomains andpractices but should not be decreased to maintain the domain level at the target.
Similarly, the scope should be defined with clarity on whether the general scope is acceptable oran industry- or system-specific scope is necessary. The scope may then be tailored for
subdomains and practices as appropriate. The rationale should be documented.
The comprehensiveness levels for each domain correspond to the general goals as follows:
For the security governance domain:••••

Follow general basic security considerations (minimum level).
Implement security measures based on requirements (ad hoc level).
Facilitate implementation of consistent security capabilities (consistent level).
Establish a clear governance structure and associated processes (formalized level).

For the security enablement domain
2019-02-25- 84 -

Version 1.0

IoT SMM Practitioner’s Guide••••

11: Case Study Approach

Enable the use of some security controls (minimum level).
Implement security controls according to known security scenarios (ad hoc level).
Employ both built-in and additional mechanisms to cover the known risks (consistentlevel).
Establish a process to address risks by the best available means (formalized level).

For the security hardening domain:••••

Apply recognized practices of cyberphysical hygiene (minimum level).
Improve system protection according to its particular needs and priorities (ad hoc level).
Employ well-recognized methods and tools for enabling trustworthiness (consistentlevel).
Establish a continuous process of supporting the trustworthiness objectives (formalized
level).

These domain comprehensiveness-level definitions also apply to subdomains and practices andare relevant when considering the security needs for subdomains and the purpose of every
security practice.

11.4 VALIDATING THE SECURITY NEEDS FOR SUBDOMAINS AND PRACTICES
Once the goals and corresponding comprehensiveness levels have been established for thedomains, the target comprehensiveness for the subdomains should be reviewed and enhanced
as appropriate. The scope of the subdomains should also be reviewed. This validation is based on
the Comprehensiveness Level Definition Guide using the following questions:
For security needs for governance:•••

How can the needs for security strategy and governance be described?
How can the needs for threat modeling and risk assessment be described?
How can the needs for supply chain and external dependencies management be
described?

For security needs for enablement:•••

How can the needs for identity and access management be described?
How can the needs for asset protection be described?
How can the needs for data protection be described?

For security needs for hardening:•••

How can the needs for vulnerability and patch management be described?
How can the needs for situational awareness be described?
How can the needs for event and incident response, continuity management be
described?

Validating the purpose of security practices: After validating the security needs corresponding to
the subdomains, the purpose of every security practice should be reviewed to validate the target
2019-02-25- 85 -

Version 1.0

IoT SMM Practitioner’s Guide

11: Case Study Approachcomprehensiveness and scope for practices implementation or change them. This validation isbased on the Comprehensiveness Level Definition Guide using the following questions:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

What is the purpose of security program management?
What is the purpose of compliance management?
What is the purpose of threat modeling?
What is the purpose of setting out the risk attitude?
What is the purpose of product supply-chain risk management?
What is the purpose of services third-party dependencies management?
What is the purpose of establishing and maintaining identities?
What is the purpose of access control?
What is the purpose of asset, change and configuration management?
What is the purpose of physical protection?
What is the purpose of establishing the protection model and policy for data?
What is the purpose of implementation of data protection practices?
What is the purpose of vulnerability assessment?
What is the purpose of patch management?
What is the purpose of security audit?
What is the purpose of information sharing and communication?
What is the purpose of an event detection and response plan?
What is the purpose of supporting remediation, recovery, and continuity of operations?

2019-02-25- 86 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

12 CASE STUDY 1: SMARTER DATA-DRIVEN BOTTLING LINEThe goal for the project is to reduce operating costs and increase efficiency of a legacy bottlingline through adaptive management of production output.

12.1 BACKGROUND, PROBLEM DESCRIPTION AND APPROACH USING SMM
A mid-tier system integrator implements solutions for beverage production lines. The integrator
is proud of their packaging expertise and technical know-how in this area. Their solutions are
efficient, robust, reliable and easy to operate. They currently provide maintenance and support
to their customers.
Now the time has come to propose something completely new: a single platform for monitoring
all phases of the operating cycle (including sale, delivery and return of final product), businessperformance tracking, reporting and analytics. The declared objective is to implement andmaintain an adjustable production cycle depending on the past and ongoing requests frompurchasers, return percentage, seasonal changes and new marketing opportunities.
They use barcode and RFID scanners to track the incoming raw materials, production batches,
packaged product and particular shipments. Scanners are used with legacy equipment to provide
live tracking, operational support, reporting and analytics for ongoing business decisions.
As the system integrator does not have much IT experience, they engage an outsourcing company
for development of the portal. A key function is to provide an easy-to-use platform for monitoringbusiness operations that includes the technological process. It is customizable to some extent
and may be supplemented with additional applications, such as performance tracking, quality
monitoring, order and returns management, maintenance, fleet management and extensions formarketing research.
The various applications use data from sensors at the production line and may also control theparameters of the process. The portal is available remotely via the internet so security is aconcern regarding possible impact on the production line.
The business-level stakeholders at the integrating company have to establish the appropriate
security requirements for the platform and the applications that will run on it. They use the SMM
for describing their concerns. With the help of an outside security architect developing theplatform and various applications, these concerns are formulated as security objectives.

12.2 FACTORS TO CONSIDER IN THE CASE STUDY SYSTEM ANALYSIS•The system integrator considers the solution that would be used by its major clients andwould attract new customers who want to enhance the efficiency and operational agilityof their manufacturing processes. The planned number of installations would grow froma few dozen in the first year up to perhaps two hundred in three years. The preferred
relationship with customers is to supply a solution with a long-term contractual
commitment for its support and maintenance. The implementation of practices may be

2019-02-25- 87 -

Version 1.0

IoT SMM Practitioner’s Guide

•

•

•

•
•

•

•

•

12: Case Study 1: Smarter Data-Driven Bottling Lineprovided by third parties while the integrator establishes appropriate requirements andmakes the appropriate security tradeoffs against costs and other concerns.
The most likely security vulnerabilities and attacks are expected to be on the softwareand external services, such as the commercial off-the-shelf operating system that may
have vulnerabilities exploited by malware. As the production line becomes connected,
these vulnerabilities are exposed to the external world.
The threat environment is typical for connected manufacturing. For computers that arepart of the manufacturing infrastructure, the internet remains the main source of attacks
and risks of malware infections.
Best practices for the target environment include network segmentation, using firewalls,
keeping the passwords for the operators’ machines and servers secure, and installing
software patches as they are issued or at least once a month.
While targeted attacks for the food and beverage manufacturing are not be relevant,typical attacks (e.g., WannaCry malware) have already hurt similar environments.
The urgency of risks must be determined according to their effect on the execution andavailability of main services. From this perspective, prevention and prompt incident
response play major roles in security processes.
While safety remains a concern for any manufacturing plant, an important focus of
security is on service availability and the integrity of the process. Personnel safety is
supported by traditional approaches such as safety instructions, but should be consideredas the solution is developed. Safety of the product is supported by maintaining processintegrity. Privacy is not an issue for this application as it does not work with personal data.
The typical constraint on security practices is the necessity of integration with (usually)brownfield environment that may not support some necessary practices. The system
integrator considers the risks and trade-offs and will provide procedures for risk
acceptance when appropriate.
As the production line gets smarter, planning and design of the system should include theactive involvement of service providers to ensure the security and overall trustworthinessof the system. This requires a clear understanding of the typical process, the adjustableparameters and the maximum level of trust that would be assigned to each service.

12.3 PRIORITIZING THE SECURITY DOMAINS
Security governance: The goal for governance is to establish governance practices based on theneeds of the typical use cases for the beverage production line. The governance scenarios requirealignment with specific needs of smart manufacturing. Therefore, the basic comprehensivenesslevel is 2, ad hoc and the scope is industry.
Security enablement: The goal for security enablement is to implement security controls toknown use cases. There are no industry- or system-specific requirements; general techniques like
password-based authentication and separation of privilege fit the needs. The basic
comprehensiveness level is 2, ad hoc and the scope is general.
Security hardening: The goal is to address the risks arising from connecting to the internet. Thisrequires particular attention to hardening practices such as timely software patching, periodic
2019-02-25- 88 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Linesecurity audits, maintenance and prompt incident response. There are some Industry-level
requirements but not across the board. We have the comprehensiveness level 2, basic andgeneral scope (which would grow to general+ as industry-specific scope is assigned to theparticular practices).
The initial diagram for the priorities across the domains is shown below.

Figure 12-1: Initial target values for security domains

12.4 CONSIDERING THE SECURITY NEEDS FOR SUBDOMAINS
12.4.1 SECURITY NEEDS FOR GOVERNANCE
Strategy and governance are guided by the most appropriate best practices. The
comprehensiveness level remains 2 and the scope remains industry as for the corresponding
domain.
Threat modeling and risk assessment for smart manufacturing needs to take into consideration
the risks for manufacturing process. To make the threat model and the appropriate risk
definitions consistent the analyst uses the tools and methods for investigating the exposures andflaws of the typical solution deployment. Thus, the comprehensiveness level for this subdomain
is 3 and the scope remains industry. The corresponding domain will be adjusted to thecomprehensiveness level 2+ to reflect that some subdomains are greater than 2.
Supply chain and external dependencies management: Using externally provided services and thethird-party-supplier networking infrastructure is a source of security risk, but a requirement of
security-certification guarantees issued by trusted authorities for all third parties would
2019-02-25- 89 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Linesignificantly increase the cost, so the comprehensiveness level remains at 2, with strengthened
requirements to some selected providers (depending on risks) leading to a 2+. This is acceptablesince remaining risks are covered by hardening practices implemented within the solution andduring its support and maintenance. The scope is industry.
12.4.2 SECURITY NEEDS FOR ENABLEMENT
Access management suggests using the typical roles for the definition of responsibilities andallowed access. The set of roles and access control scheme for the installation may slightly change
from case to case. This enables using a use case-based approach to access management without
the need of enhanced procedures for introducing new roles. Thus, the comprehensiveness levelis 2, the scope is general.
Asset protection management is a key practice for supporting the reliable and secure functioningof a production line with similar types of assets for different installations. Properly implemented
procedures for use, maintenance and support of assets minimize the risks from the majority of
threats. Some devices and software are specific to the solution. The comprehensiveness level is2, the scope is system specific. The corresponding domain thus has general+ scope.
Data protection: Some data for the smart production line affects how the process executes, so
integrity and availability of this data is important. These aspects are implemented according to
the use case and using general approaches. The comprehensiveness level is 2, the scope isgeneral.
12.4.3 SECURITY NEEDS FOR HARDENING
Vulnerability and patch management is of highest priority given the use of commercial platforms
supplemented with custom applications for smart manufacturing. Support of the consistentvulnerability and patch management and specific attention to industry and system vulnerabilities
give us the comprehensiveness level 3 and system scope. The scope value for the corresponding
domain is set to industry+. 1
Situational awareness: Practices for maintaining situational awareness are planned according to
the current threat landscape for industrial sector and smart manufacturing in particular. Reportson the current security state for that domain are periodically issued by authoritative agencies,
CERTs and security companies. The initial guide for obtaining the information from these sources
and its further analysis should underlie the situational awareness approach. The solution should
provide the ability to audit security-related events with optional delivery of such reports to thesolution support center. The comprehensiveness level is 3, the scope is industry.
Event and incident response: Any security incident at the smart production line must be handled
immediately as the possible compromise of the process bears significant financial risks andProviding software patching as a part of the whole maintenance and support service can bepresented as one of the advantages of the “full package” purchase from the system integrator as
opposed to just initial installation.
1

2019-02-25- 90 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

reputation losses. The response process should address the needs of typical manufacturing
process. The comprehensiveness level is 3, the scope is industry. The comprehensiveness level
for the corresponding domain is consistent and the scope is industry+.
The refined security maturity target for subdomains is illustrated by the diagram below.

Figure 12-2: Refined target values for security subdomains

12.5 VALIDATING THE PURPOSE OF SECURITY PRACTICES
Security program management: The system integrator defines the policies and procedures
addressing the security objectives, such as preventing unauthorized control of the line andmaintaining the confidentiality of the recipes and know-how. As the implementation of thepractice is performed ad hoc, the comprehensiveness level remains 2. Since security objectives
are not expected to go beyond the needs of similar facilities, the scope remains industry.
Compliance management: The system integrator performs the ad hoc assessment for theexternal compliance with outsourcing of the appropriate assurance activities. The preferred way
2019-02-25- 91 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Lineof providing compliance is through demonstrating evidence of the existing practices
correspondence to the compliance requirements. The comprehensiveness level remains 2 andthe scope is industry.
Threat modeling: The purpose is to describe systematically the threats that may violate thesecurity objectives. The analyst considers the generic landscape and recommendations fromsecurity and industry-regulating authorities. Additional sources include consideration of threats
for separate assets and boundaries and technology-specific classifications like OWASP Top 10.
The comprehensiveness level for this threat modeling is 3 and the scope is industry.
Risk attitude: An approach to characterizing risks focuses on the process continuity and integrity.
Where possible, a quantitative estimation of risk is performed. The estimation of risk usuallydepends on the size of facility, production output, internal dependencies and other factors. The
other part is elaboration on the strategy for risk mitigation, avoidance or acceptance, andpreparing the appropriate procedures. The comprehensiveness level for the practice is 3 and thescope is industry.
Product supply chain risk management: The purpose of supply chain risk management is toelaborate the measures taken for every piece of software used as a part of the provided solution.
For some components evidence provided by third parties may be required (e.g., certification
results). These cases must be documented and controlled contractually. The comprehensivenesslevel for the practice is 2+, and the scope is industry.
Third-party dependencies management: The purpose of the practice is to establish and manage
the quality and security commitments for the service-level agreements storing and exchanging
the information in cloud, and hosting the web services by external providers. Some guarantees
may require confirmation of third parties (issued by third parties licenses or certificates), some
may be provided by service supplier. The comprehensiveness level for the practice is 2+, and thescope is industry.
Establishing and maintaining identities: The purpose of establishing and maintaining identities
for the portal is to identify the typical roles for the system managing and controlling the
manufacturing process. These procedures are implemented in a way similar to any IT system. The
comprehensiveness level for the practice is 2, the scope is general.
Access control: The purpose of access control practice is to restrict the access of unauthorizedpeople or systems. Documenting and assessing variously implemented access controls arenecessary for timely identification of the weakest links in the solution perimeter. Finally, allcontrols should be managed consistently. The comprehensiveness level for the practice is 3, thescope is general.
Asset, change and configuration management: The purpose of this practice is to tailor thesolution for every given installation to maximize efficiency. While the solution remains the same,the asset, change and configuration management implementation will be different from case tocase. The assets and some software are specific to the solution. The comprehensiveness level is2, the scope is system specific.
2019-02-25- 92 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

Physical protection is intended to withstand direct attacks on the system by physical means. This
includes physical damage and more complicated attacks such as forging RFID labels. The practice
should be implemented by traditional means and the protection scenarios are case-based so thecomprehensiveness level is 3 and the scope is general.
Security model and policy for data classifies the data valuable to the manufacturing process andconsiders how important its confidentiality and integrity are at different stages of the process.
The classification is case-based. The comprehensiveness level remains 2 and the scope is general.
The purpose of implementation of data protection controls is to apply widely acceptedmechanisms such as data encryption or controlling the access to data storage. Most built-in
controls in COTS software are sufficient to support the required level of assurance. The
comprehensiveness level remains 2 and the scope is general.
The purpose of vulnerability assessment is to perform holistic vulnerability analysis of the systemusing automation and third-party evaluations. The important role for the system plays theabsence of specific flaws, which may allow fraud. The systematic approach and specific security
test cases lead to the consistent comprehensiveness and system scope for this practice.
The purpose of patch management is to implement a centralized and automated process forpatch updates for COTS components, manufacturing firmware and software and specificallydesigned components that make the solution “smart”. The comprehensiveness level is 3 and thescope is industry.
The purpose of auditing is to record security related events with optional delivery of reports tothe solution support center. For this purpose, information from various monitoring sources areconsolidated and managed holistically, including the process-related events. The
comprehensiveness level is 3 and the scope is system. The scope for the upper subdomain anddomain is industry+.
The purpose of information sharing and communication is to learn about vulnerabilities, threat
landscape and external incidents. This includes maintaining subscriptions to security advisories,
mailing lists of vendors and sector communities to keep the situational awareness about security
issues. The comprehensiveness level is 3 and the scope is industry.
The purpose of an event detection and response plan is a unified cycle of incident detection,
response, and support of operations continuity across all installations. This requires automatednotification about the security incident including all relevant information delivered to those whoare responsible for system recovery, remediation and maintaining continuous system operation.
The comprehensiveness level is 3, the scope is industry.
The measures for the remediation and recovery and continuity of operations after the incident at
the manufacturing line must be regulated by the instructions and guidelines and inspired by theindustry practices. The comprehensiveness level is 3 and the scope is industry.
The detailed security maturity target at the level of required practices implementation maturity
is shown at the diagram below.
2019-02-25- 93 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

Figure 12-3: Target values for the Security Practice

After validation, the security maturity target at the level of domains has changed. The final
diagram illustrating the target values for comprehensiveness and scope is shown below.

2019-02-25- 94 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

Figure 12-4: Validated security maturity target at the level of security domains

2019-02-25- 95 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

Figure 12-5: Validated security maturity target at the level of security subdomains

The summary of the created security maturity target is given in the table below.

2019-02-25- 96 -

Version 1.0

IoT SMM Practitioner’s Guide

12: Case Study 1: Smarter Data-Driven Bottling Line

TargetSecurity Governance
Security Strategy and Governance
Security Program Management
Compliance Management
Threat Modeling and Risk Assessment
Threat Modeling
Risk Attitude
Supply Chain and External Dependencies
Management
Supply Chain Risk Management
Third-Party Dependencies Management
Security Enablement
Identity and Access Management
Establishing and Maintaining Identities
Access control
Asset protection
Asset, Change and Configuration Management
Physical Protection
Data Protection
Security Model and Policy for Data
Implementation of Data Protection Controls
Security Hardening
Vulnerability and Patch Management
Vulnerability Assessment
Patch Management
Situational Awareness
Audit
Information Sharing and Communication
Event and Incident Response, Continuity ofOperations
Event Detection and Response Plan
Remediation, Recovery, and Continuity of Operation

Table 12-1:

2019-02-25

Comprehensiveness
2 (Ad hoc)+
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
3 (Consistent)
3 (Consistent)
3 (Consistent)
2 (Ad hoc)+

Scope
Industry
Industry
Industry
Industry
Industry
Industry
Industry
Industry

2 (Ad hoc)+
2 (Ad hoc)+
2 (Ad hoc)+
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)+
2 (Ad hoc)
3 (Consistent)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
3 (Consistent)
3 (Consistent)
3 (Consistent)
3 (Consistent)
3 (Consistent)
3 (Consistent)
3 (Consistent)
3 (Consistent)

Industry
Industry
General+GeneralGeneralGeneralSystemSystemSystemGeneralGeneralGeneralIndustry+
Industry+
SystemIndustry
Industry
Industry+
Industry
Industry

3 (Consistent)
3 (Consistent)

Industry
Industry+

Created security maturity target summary- 97 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates

13 CASE STUDY 2: AUTOMOTIVE GATEWAY SUPPORTING OTA UPDATESThe goal for this automotive project is to assess and improve the security for over-the-air (OTA)
updates to the in-vehicle firmware and transmission of diagnostic and operational data from onboard systems according to the business concerns of the tier-1 supplier. This should include
ongoing support for this security through situational awareness and other dimensions.

13.1 BACKGROUND, PROBLEM DESCRIPTION AND APPROACH USING SMM
The tier-1 automotive supplier implemented the solution for enabling OTA update for ECU
firmware and transmitting diagnostic and operational data from on-board systems andcomponents. Motivation for the solution is to enable vehicle connectivity to reduce recall
expense for OEMs, shorten response time for clients’ calls, continuously improve product quality
and operational efficiency, and deliver post-sale vehicle performance and feature enhancements.
As similar solutions were already in the market, the development timeframe was tight and notmuch attention was paid to security requirements. Now the supplier wants to reconsider the
security concerns and check whether it is necessary to add security mechanisms. 1 It is possible
to use the OTA update capabilities to improve the security features of already supplied devices.
The tier-1 and interested OEM-level stakeholders discuss the relevant security concerns for thesolution. Then the tier-1 supplier developing the solution needs to elaborate the security
maturity target covering both technical security measures and organizational support of theproper level of its security and relevant trustworthiness aspects (primarily safety and privacy).
Based on this SMM target the developer then conducts a gap analysis for the already supplied
samples and provides a roadmap for security enhancement and continuous support of solution
trustworthiness. After implementing the appropriate features, the supplier maintains thesolution over its usage lifecycle according to established agreements with the OEM. 2

13.2 FACTORS TO CONSIDER IN THE CASE STUDY SYSTEM ANALYSIS
The main factors affecting the security maturity target for the device begin with objective factors:
Coverage. The device is expected to be installed in vehicles of at least one manufacturer and usedaround the world.
Exposure. Several vectors for device compromise may be easily identified: through the internet(the channels for images supply), via short-range wireless communication interfaces, via physicalaccess through on-board diagnostics (OBD) interface.

1“Adding security” is never ideal since it should be by default and by design.

This prevents the OEM from requiring disproportionate security requirements and enables
dialogue about reasonable risk and cost for security.
2

2019-02-25- 98 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
Threat landscape. Currently the interest to the security of connected vehicles is particularly high,and we can expect the attempts of attacks on the device in the wild.
Relevance. A new type of device intended for connected vehicles. The appropriate area is still
under research. Best practices do not exist, and there are no applicable regulatory or standards
requirements for security.
Pertinence. The security incidents for this kind of devices were not disclosed. A few security
incidents connected to exploiting the flaws in electronic car equipment, or to the failures of thisequipment are publicly discussed.
Urgency. Security vulnerabilities of devices of this type are not known. At the same time, thetechnologies that may be used for its implementation such as securing communications requireparticular attention.
Threat impact. A successful attack may cause the failure of car equipment or even affect car
safety. As we consider the vehicles, individual privacy is also in focus (for example, car tracking).
Constraints. Safety poses constraints on functionality and security. Safety requirements may
substantially influence the design and implementation of security practices.
Trust. The trust is distributed. Car service technicians require privileged access to the device forits maintenance. Car owners may also access the device or allow access to unauthorized
maintainers. This may require regulation.
Timeline. The time and resources for development, and the resulting cost of the device areconstrained due to the increased competition in the market. The timeline is divided into the big
stages: prototype, pilot and production, for which the security maturity prioritizing may change.
Expected results. For the prototype it is important to pay attention to designing the security
mechanisms according to the expected threats independently of the currently known incidents
or technology vulnerabilities. Threat modeling and security enablement practices are prioritized.
As the prototyping stage is successfully completed, we adjust the maturity of hardening practices
by implementing infrastructure services. Then, for the mass production it is important to regulate
the trust by establishing the security program according to the final risk assessment results.
Dependencies. As this is the device of a new kind, hardening practices implementation will rely
on enablement practices, and the governance may be used to compensate for flaws associatedwith excessive trust.

13.3 PRIORITIZING THE SECURITY DOMAINS
Security governance: The goal for governance is to establish the baseline security measures basedon use cases for the device. Some governance scenarios may require alignment with industry
practices. Therefore, the basic comprehensiveness level is 2, ad hoc and the scope is industry.
Security enablement: The goal for security enablement is to implement security controls
according to the known security scenarios. There are no specific industry-specific requirements
2019-02-25- 99 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
for IT security, thus, general techniques may fit the needs of the solution security. The basic
comprehensiveness level is 2, ad hoc and the scope is general.
Security hardening: The goal is to improve the system protection according to its particular needs
and priorities. The industry poses constraints on applying additional hardening activities. We
have the comprehensiveness level 2 and industry scope.

Figure 13-1: Initial target values for security domains for the Automotive Gateway Supporting OTA
Updates case study

13.4 CONSIDERING THE SECURITY NEEDS FOR SUBDOMAINS
13.4.1 SECURITY NEEDS FOR GOVERNANCE
Strategy and governance are guided by the most appropriate best practices as there no wellrecognized approaches and security standards for this type of devices. The comprehensivenesslevel is 2, and the scope is industry as for the upper domain.
Consistent threat modeling and risk assessment are important as they help to understandpossible system and technology vulnerabilities. The comprehensiveness level is 3. The scoperemains industry. The comprehensiveness level for the upper domain grows up to 2+.
Supply chain and external dependencies management: As the development of IT-related featuresof the device is rarely a core activity for a Tier-1 automotive supplier, it will reuse the existing
software solutions and involve contractors. Focus on security for these third parties is particularly
needed. A use case-based approach works better than IT based certificates or typical policies for
supply chain management. The comprehensiveness level is 2, and the scope is industry.
2019-02-25- 100 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
13.4.2 SECURITY NEEDS FOR ENABLEMENT
Identity and access management: The typical use of the device prescribes the strict regulation ofwho, how and under what circumstances its functions may be accessed. The set of roles andaccess control scheme based on this role distribution will not change over time. The use casebased approach for access management is sufficient and does not need enhanced procedures tointroduce new identities or change the access control rules. The comprehensiveness level is 2,
and the scope is industry.
Asset protection management plays a particular role for device security. Properly implemented
procedures for the everyday use, maintenance and repair of the vehicle and control of theirenforcement minimizes the risk of the majority of threats. These procedures must be consistent
with the car maintenance lifecycle. The comprehensiveness level is 3, and the scope is industry.
Data protection: As the purpose of the device is to implement over-the-air updates for the ECU
firmware it works with at least one kind of sensitive data (firmware update images). The device
may also have a unique identifier transferred over the open channels and linked to the owner
data, potentially causing privacy issues such as tracking the car. Therefore, the data protection
requires a comprehensiveness level increase from 2, ad hoc to 3, consistent. We set
comprehensiveness to 2+ and the scope to industry. We also change the comprehensivenesslevel for the upper domain to 2+.
13.4.3 SECURITY NEEDS FOR HARDENING
Vulnerability and patch management: As vulnerable gateways create risks for all the devices forwhich they provide update services, vulnerability and patch management should be a matter ofthe utmost priority. The comprehensiveness level is 4, and the scope is industry.
Situational awareness: Practices keeping the situational awareness are planned according to thecurrent threat landscape and trends in security research of connected vehicles. The main roleplays the information sharing and communication across the industry while the security audit forthe separate vehicles supports the ongoing security maintenance. The comprehensiveness levelis 2, and the scope is industry.
Event and incident response: A security incident is a demonstration of the violation of one ormore security objectives. The information of any security incident must be handled immediately
as the possible compromise of the devices bears significant reputation risks. The
comprehensiveness level is 4, and the scope is industry. The comprehensiveness for the upperdomain grows up to 2+.
The refined security maturity target for subdomains is illustrated by the diagram below.

2019-02-25- 101 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates

Figure 13-2: Refined target values for security subdomains for the Automotive Gateway Supporting OTA
Updates case study

13.5 VALIDATING THE PURPOSE OF SECURITY PRACTICES
Security program management: The purpose of security program management is to provide thevision of what the security should be for this kind of device. As the opportunities provided by themarket for the automotive gateway and the appropriate challenges are still under investigation,
the stakeholders should focus on the use cases for the device to make the process of establishing
the security objectives agile. Premature actions to establish guidelines and processes for security
management may hinder prompt changing of the security strategy for the device according to
the market response.
The scope is system since the risks (such as an unauthorized person taking over control of the caror someone tracking it) are specific to this kind of automotive system. The comprehensivenesslevel remains 2, but the scope grows up to system level.
Compliance management determines which general and sector-specific standards are applicable,
and which level of conformance to these standards is required. At the moment, security
standards and regulatory requirements for embedded vehicle devices do not exist. Hence, we
2019-02-25- 102 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
consider some requirements from the security standards for embedded devices for optional
implementation, tailoring them to the industry demands at comprehensiveness level 2.
Threat modeling must describe and classify threats in an accurate, optionally formal way. Use therecognized tools and methods to identify and describe all threats reveal the IT factors that may
put the system at risk. The threat model must be reconsidered every time the requirementschange. This brings us to comprehensiveness level 4. The scope is system because of the
combination of traditional demands of automotive industry and challenges posed by the newly
introduced functions. The upper subdomain target levels become 3+ and industry+. (The ‘+’indicates that a subdomain could have one practice at industry scope and another at systemscope.)
Risk attitude: The business-level stakeholders need clear understanding of the risk level for all
identified threats associated with a device. The risk attitude covers evaluation and measurement,
both quantitative and qualitative. The generally accepted approach may be applied to manage
them. The approach to evaluating and measuring the risks does not change with the threat model
to keep backward compatibility with previous assessments. Thus, the comprehensiveness targets
level 3. The scope should be aligned with industry-accepted practices to compare different risks
by their severity, so industry scope is appropriate.
Product supply chain risk management: Before contracting a supplier, it makes sense to apply
well-known approaches such as a search of published vulnerabilities and consider them in viewof identified threats. Identify the particular cases to be controlled at the contractual level such as
issuing patches for newly discovered vulnerabilities if they pose a particular risk. This is a level 2
comprehensiveness approach. Product supply chain risk management should follow the industryaccepted practices to simplify the operations, resulting in industry scope.
Third-party dependencies management: Third-party-inspired threats should be included in thethreat model and security policies, and should detail timeframes, commitment for updates,
patches, and maintenance of supplied components. This is a comprehensiveness of level 2.
Dependencies management should follow the industry-accepted practices to simplify theoperations, an industry scope.
Establishing and maintaining identities: Managing the identities for the device is performed
according to the key scenarios defined in the supporting guidelines. The maintenance procedures
are implemented in car service only. The unauthorized implementation of such procedures isrestricted by the terms of warranty maintenance and repair. The set of identities corresponds to
the roles for the industry including car owner, drivers, and authorized personnel of maintenanceservice and so on, so this is industry scope. Since role-based and attribute-based access control
models fall under ad hoc, comprehensiveness level is 2, and the scope is industry.
Access control: Access to the system functions is performed according to the use case scenarios.
Access to the device functions through IT interfaces and through direct connection to on-board
diagnostics (OBD) interface is managed separately. This is level 2 since it may not be consistent.
There is no guarantee that the car owner will not violate the access control. Some access control

2019-02-25- 103 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
scenarios require consideration of specific ways to access the device, so this practice
implementation is industry specific. The upper subdomain grows up to industry as well.
Asset, change, and configuration management: During the design and implementation of thedevice, it is desirable to configure systems to provide only essential capabilities. The developed
guidelines for the use, maintenance and repair of the vehicle and its components provide clear
instructions and set the warranty and other constraints if these instructions are not followed.
The need for a consistent approach gives a target of level 3. As the device goes into mass
production, the comprehensiveness level may be increased to level 4. The operations prescribedby the practice should be aligned with typical operations for maintenance in the industry, anindustry scope.
Physical protection: The device and its interfaces must be physically protected from access fromthe car interior. The device must be tamper-resistant. The personnel of the car service accessing
the device to perform the maintenance and repair procedures must have the authorization by
the vendor or OEM (depending on the policy of car maintenance). A consistent level 3 approachis important. Physical protection and restriction on physical access to the device are to beprovided using the regulating principles typical for the automotive industry, so this is industry
scope. The comprehensiveness level for the upper subdomains grows up to 3+, and for thedomain grows up to 2+.
Security model and policy for data: The possibility of tracking the car is a relevant threat, so thedata protection policy comprehensiveness level is to be set to level 3, consistent to provide
privacy. The objectives are specific to the system, so we set the scope level to system. Considering
the scope of the other subdomain practices, the scope for the upper subdomain and domain are
therefore industry+.
Implementation of data protection controls follows both general and industry-specificconsiderations and therefore the scope level is set to industry.
As the policy does not change significantly over time and is driven by the use cases, the dataprotection measures focus on restricting data access, constraining data flow and monitoring data
access and use. Regulations do not prescribe specific requirements for such devices but weconsider proper implementation of data protection measures as critical for the device promotion
at the market; therefore, we set the comprehensiveness level to 2+.
A vulnerability assessment before entering the market prevents mitigates the risk thatcompetitors and researchers find previously unknown flaws. Implementation of this assessmentby third parties reveals hidden threats and prevents conflicts of interest among developers. This
brings us to level 3 of comprehensiveness. The device is planned to evolve; thus, the vulnerability
assessment should be planned regularly. For continuing development after entering the market
the comprehensiveness level of vulnerability assessment should be improved to level 4,
consistent. Vulnerabilities are evaluated and rated according to the system-specific security
objectives. Therefore, the scope level for this practice is system. The scope level for the upper
subdomain and domain grows up to industry+.

2019-02-25- 104 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
Patch management, similar to vulnerability assessment, should be established regularly andsynchronized with the development lifecycle during the mass production stage. Before entering
the market, patches may be managed in an ad hoc way to save time and resources. Patch
management addresses issues discovered during testing, security testing and vulnerability
assessment phases. This formalized approach is level 4. According to the specific requirementsof the industry, regular patch management is to be aligned with the automotive industry
production V-cycle, resulting in industry level for the scope. The upper subdomain gains level 4
comprehensiveness too.
Auditing describes security objectives and identifies threats to provide a base for theidentification of events types to be monitored. Deep analysis of monitoring information at a
central database from a variety of sources is good during the testing phase; for everyday
functioning the amount of data coming from many cars is hard to analyze and store. They may
also cause additional issues with privacy. Therefore, we focus on the events that may have mostsignificant impact on normal device functioning. This corresponds to the comprehensivenesslevel 2, ad hoc. As the monitored events are specific to automotive the scope level for thispractice is system.
Information sharing and communication on the vulnerabilities and threats for the emerging
technologies prevent significant risks connected to their use. The proper organization of thisprocess is particularly important for the automotive area where even the unapproved
information on possible threat to human safety may cause huge reputational loss. Process-based
monitoring and sharing the information among industry peers helps all parties to be better
prepared to respond to all kinds of risks. Therefore, the level 4, formalized comprehensivenesslevel is applied here. For information sharing and communication it makes sense to track thenews about the trends in automotive industry, incidents, vulnerabilities in design andimplementation of protocols for the communication of in-vehicle equipment, newly appeared
threats and other security research results for the industry. Thus, the scope is industry specific.
Event detection and response plan: The implementation of this practice identifies and classifies
security events, and describes the requirements to the personnel involved in an incident, theappropriate procedures to be followed, and interaction algorithms and time constraints. Security
event response and handling safety incidents are interconnected in an appropriate way. All
countermeasures up to the recall of cars are accurately regulated by the established procedures.
The comprehensiveness level is 4, formalized.
All event response operations should be tailored to the specific risks for the system, therefore,
the scope level is system. The resulting scope level for the upper domain is industry+.
The measures for the remediation, recovery and continuity of operations after the incident or
device failure are usually taken at the car service. The provided instructions and guidelines must
include all procedures including feedback that may help to improve the device. All interactions
are made according to the formally defined procedure that may change over time to enhancethe experience of all parties and elaborate on the best practices. The operations for remediation,
recovery and continuous support are inspired by the industry practices similar to the cases ofelectronic equipment failure. The comprehensiveness level is 4 and the scope is industry.
2019-02-25- 105 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates

Figure 13-3: Target values for the Security Practices for the Automotive Gateway Supporting OTA
Updates case study

After the validation, the security maturity target at the level of domains has changed. The final
diagram illustrating the target values for comprehensiveness and scope is shown below.

2019-02-25- 106 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates

Figure 13-4: Validated security maturity target at the level of security domains for the Automotive
Gateway Supporting OTA Updates case study

2019-02-25- 107 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates

Figure 13-5: Validated security maturity target at the level of security subdomains for the Automotive
Gateway Supporting OTA Updates case study

The summary of the created security maturity target is given in the table below.

2019-02-25- 108 -

Version 1.0

IoT SMM Practitioner’s Guide 13: Case Study 2: Automotive Gateway Supporting OTA Updates
TargetSecurity Governance
Security Strategy and Governance
Security Program Management
Compliance Management
Threat Modeling and Risk Assessment
Threat Modeling
Risk Attitude
Supply Chain and External Dependencies
Management
Supply Chain Risk Management
Third-Party Dependencies Management
Security Enablement
Identity and Access Management
Establishing and Maintaining Identities
Access control
Asset protection
Asset, Change and Configuration Management
Physical Protection
Data Protection
Security Model and Policy for Data
Implementation of Data Protection Controls
Security Hardening
Vulnerability and Patch Management
Vulnerability Assessment
Patch Management
Situational Awareness
Audit
Information Sharing and Communication
Event and Incident Response, Continuity ofOperations
Event Detection and Response Plan
Remediation, Recovery, and Continuity of Operation

Table 13-1:

2019-02-25

Comprehensiveness
2 (Ad hoc)+
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
3 (Consistent)+
4 (Formalized)
3 (Consistent)
2 (Ad hoc)

Scope
Industry+
Industry+
SystemIndustry
Industry+
SystemIndustry
Industry

2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)+
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)+
3 (Consistent)
2 (Ad hoc)+
2 (Ad hoc)+
4 (Formalized)
4 (Formalized)
4 (Formalized)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)
2 (Ad hoc)+

Industry
Industry
Industry+
Industry
Industry
Industry
Industry
Industry
Industry
Industry+
SystemIndustry
Industry+
Industry+
SystemIndustry
Industry+
SystemIndustry
Industry+

4 (Formalized)
2 (Ad hoc)

SystemIndustry

Created security maturity target summary- 109 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

14 CASE STUDY 3: CONSUMER (RESIDENTIAL) SECURITY CAMERAS
A producer of IoT security cameras seeks to use the SMM to create an appropriate security
program.

14.1 BACKGROUND, PROBLEM DESCRIPTION AND APPROACH USING SMM
The organization performing this SMM benchmark offers a line of security (video) cameras
intended to be used in residential settings. The ecosystem includes mobile applications
customers can use to view video and control their cameras, and a cloud infrastructure that stores
video and relays communication from mobile apps to cameras. While the product line
development and marketing were all focused on residential use, the products have also become
popular with small businesses.
Having begun life as a startup, the organization is growing and maturing as its customer base
expands. As part of that process, the organization wants to build a more mature security
program, and that desire was cemented after recent media coverage of security weaknesses in acompetitor’s products. Previously the organization’s security-related efforts have been ad hoc
and driven by individuals within the company, rather than being a strategic, company-wide
program. The organization has decided it must protect customers from attacks through devices,
ensure customer privacy, and protect the company from brand and reputational damage.
Security best practices were explicitly considered during the design of the organization’s
products, so product security features are well documented in their specifications. In every otheraspect of security, though, the company has no documentation or formal policies.
The organization wants to understand the appropriate level of investment to meet these goals.
The company leadership are genuine in their desire to build an appropriate security program, but
the threat profile of their customers means that it is unlikely that deployment of its products
needs to be hardened sufficiently to protect against advanced, persistent threats. The
organization wants to adopt an appropriate level of security, without over investing in ways thatwould reduce margins or increase product costs without appreciable benefit. The company’s
leadership decides the SMM is an appropriate framework to help them make related decisions.
The organization starts the process by deciding what its target state should be.

14.2 FACTORS TO CONSIDER IN THE CASE STUDY SYSTEM ANALYSISThe following considerations drive the organization’s decisions as they determine their target
state in the various subdomains:••

Customers install the organization’s products in and around their homes, leading tosignificant privacy implications if a product were compromised. Consequently, theorganization wants to place emphasis on secure design and endpoint hardening tominimize the risk present in their released devices.
Related to this, the company believes that they would experience significant brand andreputational damage if their products suffered from a high-profile security incident. The

2019-02-25- 110 -

Version 1.0

IoT SMM Practitioner’s Guide••

14: Case Study 3: Consumer (Residential) Security Camerasorganization’s products compete in a crowded marketplace and they expect that
consumers will avoid products with publicized shortcomings.
The organization assesses that the most advanced threat actors to target their products
will likely be security researchers. There is no clear monetary benefit to be gained from
exploiting the product. Similarly, the product is unlikely to be installed in locations thatwould be of interest to sophisticated, nation-state actors.
Finally, the organization needs to build their security program from a starting point ofzero. Their target state needs to be pragmatic about what activities will yield the mostimprovement in terms of security and reduction of risk.

As the stakeholders develop their security maturity model benchmark, they opt not to include
the element of scope. They make this decision based on two factors. First, their industry has no
specific regulatory or compliance requirements that need to be considered. Second, they aredeveloping the benchmark for themselves. That being the case, the scope for all practices is level
4. Given the consistency of scope across the benchmark, the stakeholders decide not to focus on
it in their exercise.

14.3 PRIORITIZING THE SECURITY SUBDOMAINS
With the factors described above in mind, organization stakeholders work to determine theirtarget state. Again, while ideally all practices would operate at a level 4, the purpose of thisexercise is to assign relative priority to the various domains, subdomains, and practices. This
process recognizes that not all security practices are equal in all scenarios, and investment oftime and resources should be made based on what will lead to the greatest increase in security.
Initially security enablement and hardening target comprehensiveness level is 3, and they areprioritized over security governance which has the target comprehensiveness level 2. The target
scope for all domains is general.

2019-02-25- 111 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Figure 14-1: Initial target values for security domains for the Consumer Security Cameras case study

14.4 CONSIDERING THE SECURITY NEEDS FOR SUBDOMAINS
14.4.1 SECURITY NEEDS FOR GOVERNANCE
At this early stage, without an existing program, the organization seeks to establish baseline
measures of security, consistent with a level 2 target state.
Security strategy and governance: As the organization lacks the foundation for a security
program, their goal to provide a vision and then roll out basic security best practices, consistent
with a level 2 target state.
Threat modeling and risk assessment: The crowded market in which the organization competescauses it to put significant emphasis on the security of its production devices. Consequently, theorganization wants to prioritize threat modeling and risk assessment as tools its developers canuse to help prevent the inclusion of vulnerabilities in its products, consistent with a level 3 target.
Supply chain and external dependencies management: The company builds its products from
commodity components so needs to be sure they do not have vulnerabilities that can impact its
products. The stakeholders consequently decide that their risk profile does not require more thana level 0 target.

2019-02-25- 112 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

14.4.2 SECURITY NEEDS FOR ENABLEMENT
Decisions made in the enablement domain have implications for the security of stored data, andconsequently for user privacy. Given the company has a goal of protecting the privacy of theirusers (the confidentiality of video feeds) a level 3 target is appropriate.
Identity and access management: The company’s products only support a single user role. Given
the lack of complexity in their access model, the organization decides a level 2 target isappropriate as they only need to differentiate access based on individual users.
Asset protection management is fundamental to the security of hosts storing user information.
The company stores user videos on a cloud platform, which transfers much of the responsibility
to the cloud provider. Given the number of security incidents that have stemmed frommisconfigurations in a cloud backend the company still believes this should be an important area.
They consequently decide on a level 3 target for this subdomain.
Data protection: To protect user data, the company chooses a level 4 target for this subdomain.
The organization needs to classify all the information that can relate to an identified or an
identifiable person and to the video data it holds, and then specify adequate controls for eachlevel of classification. The organization also needs to ensure that its controls protect data intransit, at rest, and while being processed. This should include protection from malicious insiders.
14.4.3 SECURITY NEEDS FOR HARDENING
The hardening domain prevents attacks against endpoints and backend systems. They are willingto make the investment to have situational awareness and be able to respond to an attack against
its assets. It consequently chooses a level 3 target for the hardening domain.
Vulnerability and patch management: The company wants to ensure that known vulnerabilities
do not persist in their products or infrastructure. To prevent this possibility, they want to instituteautomated path management for their deployed products (i.e., OTA updates) and backend
infrastructure. They also want to pair patch management with a vulnerability management
program to provide feedback and verify the security of managed assets. These goals are
consistent with a level 3 target.
Situational awareness: The organization wants to have sufficient monitoring of security eventsso that signs of malicious activity can be detected and prevented in near real-time. For awarenessand information sharing, the company’s staff want to understand the state-of-the-art in terms of
threats but are unlikely to encounter situations in which they would seek to share their own
threat data with law enforcement. Although the specific goal for the monitoring practice isconsistent with a level 2, the organization sets an overall goal of level 3 for the subdomain.
Event and incident response: To preserve its professional reputation and revenue stream, thecompany needs to be able to restore services as fast as possible after an incident. If theorganization’s products can’t store customer video for a sustained period, the company
anticipates it would quickly lead to a consumer backlash. This goal of an automatic, swift, andcoordinated business response to an incident is consistent with a level 4 goal.
2019-02-25- 113 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Figure 14-2: Initial target values for security subdomains for the Consumer Security Cameras case study

14.5 VALIDATING THE PURPOSE OF SECURITY PRACTICES
After having established the target state for each subdomain, the organization takes stock of its
current state in an offsite two-day leadership workshop. The company brings in a third-party
security expert to facilitate the process and provide an impartial assessment of current state,based on information provided by the respective team leaders. There is some inherent bias inthis process, as allowing team leaders to self-report creates the potential for inflating existing
controls, but decided it was adequate for this first iteration through the security maturity model.
For future iterations, the company would like to have an independent third-party perform asecurity assessment to determine the target state objectively for each practice.
Security program management: After a long, uncomfortable conversation, the leadership teamacknowledges that they had no existing security program whatsoever. The stakeholders had allassumed that a security policy had been documented somewhere, but a review of the company’s
documentation and wiki found that none existed, although several other documents referenced
a security policy. The stakeholders set their current state as level 0.
2019-02-25- 114 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Compliance management: The stakeholders identified that they have no mature complianceprograms. After verifying that they do not process or store any PII data, they believe they do nothave any compliance requirements. They consequently rate their current compliancemanagement state as level 1.
Threat modeling: The stakeholders determine that one of their development teams, focused on
the cloud-side services, had been conducting routine threat models with formal methods. No
other development teams have used threat modeling during the development processes. The
stakeholders consequently rate their current state as 2 given its ad hoc nature.
Risk attitude: As a corollary of the lack of security policy, the organization also lacks a sense ofrisk. No organized effort exists to understand risks and differentiate their relative severities. The
stakeholders consequently categorize themselves as a level 1.
Product supply chain risk management: The company lacks a supply chain security program. No
one in their development or engineering teams has inventoried third-party provided softwareand hardware components, and there is no effort to stay informed of vulnerabilities in any thirdparty components. The organization consequently categorizes itself as a level 0.
Third-party dependencies management: The organization relies on a single third party for
ongoing operations, their cloud service provider. Their provider is a market leader and hasreceived multiple certifications for various compliance regimes. They provide these documents
to the organization annually, so the stakeholders find themselves at level 3 for this practice.
Establishing and maintaining identities: The company’s products currently support a single user
role. This allows the developer team to treat all users similarly and puts their current and target
states at level 1.
The organization’s access control requirements are more nuanced than their identity
management. The organization needs to ensure that access to PII and stored videos is securefrom other users and its own employees. Before performing a requested action, their system’s
authorization infrastructure currently verifies user authentication and that a request is for data
owned by the requester. The stakeholders consequently set their current state as level 2, but
acknowledge they need to do more to provide assurance, particularly as it relates to a potential
malicious insider.
Asset, change and configuration management: The stakeholders realize that there’s no process
in place to track changes in system configurations. Their ops team maintain documents in acollaboration system that details how different ecosystem components should be configured, butthere is no process to ensure the implementations match that or any alerting to note when achange occurs. They consequently benchmark themselves as a level 0 for current state.
Physical protection: The physical assets hosting sensitive information (PII and video) are all
operated by the cloud provider who has extensive physical security protections. Physical accessto the organization’s offices and workstations is controlled with ID cards, which are issued to
specific individuals and audited. The organization rates its current state as level 3 for this practice.

2019-02-25- 115 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Security model and policy for data: As an exception to the organization’s lack of official security
policies, they do have a well-documented security model and policy for access to data. As part oftheir first product’s design, the team worked out which assets in the ecosystem would process
and store which kinds of data and developed their architecture to ensure the security and privacyof stored video feeds and PII. Given the documentation and implementation that defines specificroles, assets, and services that can process or store different types of data, they assess theircurrent state as level 3.
Implementation of data-protection controls: Related to the above architecture plan, the company
has a mature solution for securing sensitive data. The architecture provides controls forunauthorized access from malicious insiders and ensures sensitive information is only stored in awell-secured location with the cloud provider. Further, encryption is implemented throughout
the architecture, for data in motion and at rest. The stakeholders assess this domain as level 3.
Vulnerability assessment: The company has not performed any sort of vulnerability assessmenton their products. They have conducted occasional, irregular vulnerability scans of pieces of theirinfrastructure. They consequently self-assess their current state as level 1.
Patch management: The organization has no process to push patches to its deployed products,
consistent with a level 0 current state, but servers and systems in their backend infrastructure
are automatically patched and managed by the cloud provider. The current state for backend
systems would be level 3. The organization gives itself a conservative current state assessmentof level 1 for this practice for this separate system.
Auditing: The development and ops teams occasionally review logs while troubleshooting, butthere is no routine or systematic log review. Moreover, logs are not proactively reviewed for
security-relevant events. The organization consequently identifies its current state as level 1.
Information sharing and communication: Members of the organization receive information on
security developments relevant to their industry through Twitter and media reports. The
stakeholders are unaware of anyone in the organization that routinely monitors threat
intelligence feeds; they are certain that no one is responsible for maintaining awareness of new,relevant threats. They assess their current state as level 1.
Event detection and response plan: A search of the organization’s document repositories fails toyield any documented incident-response plan. They assess level 0 for their current state.
Remediation, recovery and continuity of operations: The organization’s engineering team does
maintain documentation addressing how to restore operations in the event of a handful ofincident types. For those types of incidents, the team has created detailed instructions. In one
instance the team successfully used these procedures to restore services during a cloud provider
outage. The organization assesses as a level 2 because these plans only included members of theengineering team and did not include other stakeholders, such as public relations or legal.

2019-02-25- 116 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Figure 14-3: Target values for the Security Practices for the Consumer Security Cameras case study

As the target comprehensiveness levels have changed significantly after the detailed
consideration of security practices, the higher-level targets for subdomains and domains arealigned with their new values.

2019-02-25- 117 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Figure 14-4: Refined values for the Subdomains for the Consumer Security Cameras case study

2019-02-25- 118 -

Version 1.0

IoT SMM Practitioner’s Guide

14: Case Study 3: Consumer (Residential) Security Cameras

Figure 14-5: Refined values for the Domains for the Consumer Security Cameras case study

14.6 DEFINING NEXT STEPS AND ROADMAPWith the target and current states defined, the next phase of the process is for the organization
to identify those practices that fell below the target. For each of those practices the organization
determines the additional measures necessary to move that practice to target state. After thislist of additional controls is developed, the organization then prioritizes each change based on its
cost in terms of time, resources, and money relative to the improvement in security that change
would bring. The organization also keeps in mind the stakeholders responsible for each change
and the capacity of each stakeholder to implement change. With these considerations
enumerated, the organization develops its roadmap to improve its overall security maturity andmove towards target state.

2019-02-25- 119 -

Version 1.0

IoT SMM Practitioner’s Guide

Annex A: Revision History

Part V: Annexes
Annex A REVISION HISTORY
Revision
V1.00

Date
2019-02-25

2019-02-25

EditorCarielli, Hirsch, Rudina, Zahavi- 120 -

Changes Made
Initial Release

Version 1.0

IoT SMM Practitioner’s Guide

Annex B: Acronyms

Annex B ACRONYMS
BSIMM
C2M2
CAPEC
CERT
CIA
CISO
DLP
FDA
GDPR
IDS/IPS
IIC
IIRA
IISF
IIoT
IT
IoT
NGFW
OBD
OEM
OT
OWASP
PII
PKI
RFC
SIEM
TLS
US

2019-02-25

Building Security in Maturity Model
Cyber-Security Capability Maturity Model
Common Attack Pattern Enumeration and Classification
Computer Emergency Response Team
Confidentiality, Integrity and Availability
Chief Information Security Office
Data Loss Prevention
Food and Drug Administration
General Data Protection Regulation
Intrusion Detection System/Intrusion Prevention System
Industrial Internet Consortium
Industrial Internet Reference Architecture
Industrial Internet Security Framework
Industrial Internet of Things
Information Technology
Internet of Things
Next Generation Firewall
On Board Diagnostics
Original Equipment Manufacturer
Operational Technology
Open Web Application Security Project
Personally Identifiable Information
Public Key Infrastructure
Request for Comment
Security Information and Event Management
Transport Layer Security
United States- 121 -

Version 1.0

IoT SMM Practitioner’s Guide

Annex C: Glossary

Annex C GLOSSARY
The terms and their definitions in this section are specific to this document and may not beapplicable to other IIC documents including the Industrial Internet Vocabulary Technical Report.
Comprehensivenesscaptures the degree of depth, consistency and assurance of security
measures that support security maturity domains, subdomains or practices.
There are five comprehensiveness levels, from level 0 to level 4, with larger
numbers indicating a higher degree of comprehensiveness of security
controls.
Current state

DomainThe maturity current state represents the maturity as captured by anassessment of the organization.
The strategic priorities for security maturity. In the SMM, there are threedomains: governance, enablement, and hardening.

Industrial Internet Consortium (IIC)
an open membership, international not-for-profit consortium that is setting
the architectural framework and direction for the Industrial Internet.
Founded by AT&T, Cisco, GE, IBM and Intel in March 2014, the consortium’s
mission is to coordinate vast ecosystem initiatives to connect and integrate
objects with people, processes and data using common architectures,interoperability and open standards.
Industrial Internet of Things (IIoT)
describes systems that connects and integrates industrial control systems
with enterprise systems, business processes, and analytics.
Note 1: Industrial control systems contain sensors and actuators.
Note 2: Typically, these are large and complicated system.
Maturity

Practice

2019-02-25

Security maturity is a measure of an understanding of the current security
level, its necessity, benefits, and cost of its support. Maturity is captured by
two dimensions, comprehensiveness and scope.
The typical activities performed for a given subdomain; they provide thedeeper detail necessary for planning. Each sub domain has a set of practices.

- 122 -

Version 1.0

IoT SMM Practitioner’s Guide

Annex C: Glossary

Security maturity profile
The security maturity profile is a typical security maturity target for a specific
type of device, organization or system. Using security maturity target profiles
simplifies the process of establishing the target for common use cases.
Establishing a library of security maturity target profiles for common IoT
scenarios is a subject for further development.
Scope

Security level

Subdomain

Target state

2019-02-25

reflects the degree of fit to the industry or system needs. It captures thedegree of customization of the security measures that support security
maturity domains, subdomains or practices. Such customizations are typicallyrequired to address industry-specific or system-specific constraints of the IoT
system. There are three levels of scope for every security facet, from level 1
to level 3, with higher numbers indicating a narrower and more specificscope.
is a measure of confidence that the system is free of vulnerabilities andfunctions in an intended manner.
is the basic means to address a domain at the planning level. Each domain
currently defines three subdomains.
The security maturity target is the desired “end state” security maturity for
an organization or system. The security maturity target can apply to a new
system under development or an existing brownfield system. The security
maturity target is determined based upon the business objectives of theorganization or group.

- 123 -

Version 1.0

IoT SMM Practitioner’s Guide

Annex D: References

Annex D REFERENCES[BSIMM]

Building Security in Maturity Model (BSIMM), retrieved 2019-01-24
https://www.bsimm.com/download.html
fromhttps://www.bsimm.com[CVSS]

Common Vulnerability Scoring System (CVSS), V3, 2015, retrieved 2019-01-24
https://www.first.org/cvss/[ENER-C2M2]

Office of Electricity Delivery & Energy Reliability: Cybersecurity Capability
Maturity Model (C2M2), retrieved 2016-09-26
https://www.energy.gov/sites/prod/files/2014/03/f13/C2M2-v1-1_cor.pdf
fromhttps://www.energy.gov/ceser/activities/cybersecurity-critical-energyinfrastructure/energy-sector-cybersecurity-0-0[IIC-IIRA2017]

Industrial Internet Consortium: The Industrial Internet, Volume G1:
Reference Architecture Technical Report, version 1.8, 2017-01-31, retrieved
2019-01-24
https://www.iiconsortium.org/IIRA.htm[IIC-IIV2018]

Industrial Internet Consortium: The Industrial Internet, Volume G8:
Vocabulary Technical Report, version 2.1, 2018-05-22, retrieved 2019-01-24
https://www.iiconsortium.org/vocab/index.htm[IIC-SMMD2019] Industrial Internet Consortium: IoT Security Maturity Model: Description andIntended Use, 2019-02-25, retrieved 2019-02-25
https://www.iiconsortium.org/pdf/SMM_Description_and_Intended_Use_FI
NAL_Updated_V1.1.pdf[IIC-IISF2016]

Industrial Internet Consortium: Industrial Internet of Things Volume G4:
Security Framework, 2016-09-26, retrieved 2019-01-24
https://www.iiconsortium.org/IISF.htm[IIC-SBPEP2018] Industrial Internet Consortium: IIC Endpoint Security Best Practices,
IIC:WHT:IN17:V1.0:PB:20180312
Steve Hanna, Srinivas Kumar, Dean Weber, 2018-03-12, retrieved 2019-01-24
https://www.iiconsortium.org/pdf/Endpoint_Security_Best_Practices_Final_
Mar_2018.pdf

2019-02-25- 124 -

Version 1.0

IoT SMM Practitioner’s Guide

Index

INDEX
A

G

Access control .......................................................... 49
practice considerations ....................................... 49
practice purpose ................................................. 80
Assessmentof security maturity ............ See: Security maturity
assessment
Asset management .................................................. 51
subdomain .................................................... 51, 77
Asset, change and configuration management
practice considerations ....................................... 51
practice purpose ................................................. 80

Governance ......................... See: Security governance

H

Hardening .............................. See: Security hardening

I

Identity and access management ............................47
subdomain .................................................... 47, 77
IIC ......................... See: Industrial Internet Consortium
IIRA .... See:Industrial Internet Reference Architecture
IISF ......... See: Industrial Internet Security Framework
Implementation of data protection
practice considerations ....................................... 59
practice purpose ................................................. 81
Incident response .................................................... 71
Industrial Internet Consortium .............................. 127
Industrial Internet Reference Architecture ...............8
Industrial Internet Security Framework..................... 8C

Change management............................................... 51
Compliance management........................................ 37
practice considerations ....................................... 37
practice purpose ................................................. 79
Comprehensiveness................................................. 13
level................................................... 14, 22, 28, 76
Configuration management..................................... 51
Continuity of operations .......................................... 74

L

Level
of comprehensiveness ..... See Comprehensivenesslevelof scope......................................... See: Scope levelvisualization ........................................................ 15D

Data protection
implementation .................................................. 59
Data protection........................................................ 56
policy ................................................................... 56
subdomain .......................................................... 56
Data protection
subdomain .......................................................... 77
Domain ......................See: Security Maturity domains

M

Monitoring ............................................................... 67
practice considerations ....................................... 67
practice purpose ................................................. 81

O

Object Management Group ................................... 127
OMG ......................... See Object Management GroupE

Enablement ........................ See: Security enablement
Establishing and maintaining identities ...................47
practice considerations ....................................... 47
practice purpose ................................................. 80
Event and incident response
subdomain .................................................... 71, 78
Event detection ....................................................... 71
Event detection and response plan
practice considerations ....................................... 71
practice purpose ................................................. 82
Event response ........................................................ 71

2019-02-25

P

Patch management.................................................. 65
practice considerations ....................................... 65
practice purpose ................................................. 81
Physical protection .................................................. 54
practice considerations ....................................... 54
practice purpose ................................................. 80
Practice ..................... See: Security maturity practices
Product supply chain risk management ..................43
practice considerations ....................................... 43
practice purpose ................................................. 79
Protection model and policy for data

- 125 -

Version 1.0

IoT SMM Practitioner’s Guide

Index

practice considerations ....................................... 56
practice purpose ................................................. 80

practice considerations ....................................... 34
practice purpose ................................................. 79
Security strategy and governance ...........................34
subdomain .................................................... 34, 77
Services third-party dependencies management ....45
practice considerations ....................................... 45
practice purpose ................................................. 79
Situational awareness........................................ 67, 78
subdomain .......................................................... 67
Situational awareness and information sharing
practice purpose ................................................. 81
Situational awarenessand information sharing
practice considerations ....................................... 69
SMM ..............................See: Security maturity model
extensibility ................................................... 10, 16
practice template ................................................ 15
profile....................... See: Security maturity profile
target ......................... See Security maturity target
Subdomain ........... See: Security maturity subdomains
Supply chain and the external dependencies
management......................................................... 43
subdomain .................................................... 43, 77

R

Recovery .................................................................. 74
Remediation ............................................................ 74
Remediation recovery and continuity of operations
practice considerations ....................................... 74
practice purpose ................................................. 82
Response plan.......................................................... 71
Risk Attitude ............................................................ 41
practice considerations ....................................... 41
practice purpose ................................................. 79

S

Scope ....................................................................... 13
level............................................................... 14, 24
Securityenablement ............................................. 12, 47, 76
governance ............................................. 12, 34, 76
hardening ................................................ 12, 62, 76
Security level.............................................................. 9
Security maturity ....................................................... 9
applying the model ....................................... 21, 83
assessment.................................................... 21, 27
current state ....................................................... 27
domains ........................................................ 12, 76
enhancement ................................................ 21, 31
gap analysis ......................................................... 29
hierarchy ............................................................. 12
model .............................................................. 9, 11
practices ........................................................ 12, 78
profile............................................................ 16, 22
roadmap.............................................................. 31
subdomains................................................... 12, 76
target ............................................................ 22, 23
Security program management ............................... 34

2019-02-25

T

Threat modeling ...................................................... 39
practice considerations ....................................... 39
practice purpose ................................................. 79
Threat modeling and risk assessment .....................39
subdomain .................................................... 39, 77

VVulnerability and patch management .....................62
subdomain .................................................... 62, 78
Vulnerability assessment ......................................... 62
practice considerations ....................................... 62
practice purpose ................................................. 81- 126 -

Version 1.0

IoT SMM Practitioner’s Guide

Authors and Legal Notice

AUTHORS AND LEGAL NOTICE
Copyright © 2019, Industrial Internet Consortium, now incorporating OpenFog, a program of
Object Management Group, Inc. (“OMG”).

ACKNOWLEDGEMENTS
Security Applicability Task Group, co-chaired by Ron Zahavi (Microsoft) and James Clardy (NetFoundry), which is a subgroup of the Security Working Group co-chaired by Sven Schrecker (LHP
Engineering Solutions) and Jesus Molina (Waterfall Security Solutions).
EDITORS
Sandy Carielli (Entrust Datacard), Frederick Hirsch (Fujitsu), Ekaterina Rudina (Kaspersky), Ron
Zahavi (Microsoft).
AUTHORSThe following persons contributed substantial written content to this document:
Sandy Carielli (Entrust Datacard), Matt Eble (Praetorian), Frederick Hirsch (Fujitsu), Ekaterina
Rudina (Kaspersky), Ron Zahavi (Microsoft).
CONTRIBUTORSThe following persons contributed valuable ideas and feedback that significantly improved thecontent and quality of this document:
Marcellus Buchheit (Wibu-Systems).
TECHNICAL EDITOR
Stephen Mellor (IIC staff) oversaw the process of organizing the contributions of the above
Editors, Authors and Contributors into an integrated document.

USE OF INFORMATION—TERMS, CONDITIONS AND NOTICESThis is an Industrial Internet Consortium document (the “Document”) and is to be used inaccordance with the terms, conditions and notices set forth below. This Document does not
represent a commitment by any person to implement any portion or recommendation containedin it in any products or services. The information contained in this Document is subject to change
without notice.

LICENSES
The companies who contributed content to this Document (“Contributing Companies”) have
granted to the Industrial Internet Consortium (the “IIC”), a program of Object Management
Group, Inc. (“OMG”) a nonexclusive, irrevocable, sublicensable, royalty-free, paid up, worldwide
license to copy and distribute this Document and to modify this Document and distribute copies
2019-02-25- 127 -

Version 1.0

IoT SMM Practitioner’s Guide

Authors and Legal Noticeof the modified version. Each of the Contributing Companies has agreed that no person shall bedeemed to have infringed the copyright in the included material provided by any such copyrightholder by reason of having copied, distributed or used such material as set forth herein.
Subject to the terms and conditions below, OMG (including its IIC program) and the Contributing
Companies hereby grant you a fully-paid up, non-exclusive, nontransferable, royalty-free,worldwide license (without the right to sublicense) to use, copy and distribute this Document(the “Permission”), provided that: (1) both the copyright notice above, and a copy of thisPermission paragraph, appear on any copies of this Document made by you or by those acting
on your behalf; (2) the use of the Document is only for informational purposes in connection with
the IIC’s mission, purposes and activities; (3) the Document is not copied or posted on any
network computer, publicly performed or displayed, or broadcast in any media and will not beotherwise resold or transferred for commercial purposes; and (4) no modifications are made tothis Document.
This limited Permission is effective until terminated. You may terminate it at any time by ceasing
all use of the Document and destroying all copies. The IIC may terminate it at any time by notice
to you. This Permission automatically terminates without notice if you breach any of these terms
or conditions. Upon termination, or at any time upon the IIC’s express written request, you will
destroy immediately any copies of this Document in your possession or control.
The Licenses and Permission relate only to copyrights and do not convey rights in any patents(see below).

PATENTS
Compliance with or adoption of any advice, guidance or recommendations contained in any IIC
reports or other IIC documents may require use of an invention covered by patent rights. OMG
and its IIC program are not responsible for identifying patents for which a license may be required
to comply with any IIC document or advice, or for conducting legal inquiries into the legal validity
or scope of those patents that are brought to its attention. IIC documents are informational andadvisory only. Readers of this Document are responsible for protecting themselves against
liability for infringement of patents and other intellectual property that may arise from following
any IIC recommendations or advice. OMG and its IIC program disclaim all responsibility for such
infringement.

GENERAL USE RESTRICTIONSThis Document contains content that is protected by copyright. Any unauthorized use of thisDocument may violate copyright laws, trademark laws and communications regulations andstatutes. Except as provided by the above Permission, no part of this work covered by copyrightmay be reproduced or used in any form or by any means—graphic, electronic, or mechanical,
including photocopying, recording, taping or information storage and retrieval systems—without
permission of the copyright owner(s).

2019-02-25- 128 -

Version 1.0

IoT SMM Practitioner’s Guide

Authors and Legal Notice

DISCLAIMER OF WARRANTY
WHILE THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PROVIDED “AS IS” AND MAY
CONTAIN ERRORS OR MISPRINTS. OMG (INCLUDING ITS IIC PROGRAM) AND THE CONTRIBUTINGCOMPANIES MAKE NO WARRANTIES, REPRESENTATIONS OR CONDITIONS OF ANY KIND, EXPRESSOR IMPLIED, WITH REGARD TO THIS DOCUMENT, INCLUDING BUT NOT LIMITED TO ANYWARRANTY OF TITLE OR OWNERSHIP, OF MERCHANTABILITY, OF FITNESS FOR A PARTICULARPURPOSE OR USE, OR AGAINST INFRINGEMENT. OMG (INCLUDING ITS IIC PROGRAM) MAKES NO
REPRESENTATIONS, WARRANTIES, GUARANTIES, OR CONDITIONS AS TO THE QUALITY,
SUITABILITY, TRUTH, ACCURACY, OR COMPLETENESS OF THIS DOCUMENT.
IN NO EVENT SHALL OMG (INCLUDING ITS IIC PROGRAM) OR ANY OF THE CONTRIBUTINGCOMPANIES BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGE, OR DAMAGE FOR LOSS OF PROFITS,
REVENUE, DATA OR USE, HOWEVER IT ARISES, WHETHER IN AN ACTION OF CONTRACT,NEGLIGENCE OR OTHER TORTIOUS ACTION, INCURRED BY ANY USER OR ANY THIRD PARTY IN
CONNECTION WITH THE FURNISHING, PERFORMANCE, REPRODUCTION, DISTRIBUTION OR USE
OF THIS MATERIAL, EVEN IF PREVIOUSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
The entire risk as to the quality and performance of any software or technology developed using
this Document is borne by you. This disclaimer of warranty constitutes an essential part of thePermission granted to you to use this Document.

LIMITED RIGHTS NOTICEThis Document contains technical data that was developed at private expense and (i) embodies
trade secrets, or (ii) is confidential and either commercial or financial. This document was notproduced in the performance of a government contract and is not in the public domain. The use,
duplication or disclosure of this Document by the U.S. Government is subject to the restrictions
set forth in 48 C.F.R. 52.227-14–Rights in Data “Limited Rights Notice (Dec. 2007) (a) and (b),” oras specified in 48 C.F.R. 12.211 of the Federal Acquisition Regulations and its successors, asapplicable. This data may only be reproduced and used by the U.S. Government with the express
limitation that it will not, without written permission of the copyright owners, be used for
purposes of manufacture nor disclosed outside the Government. The copyright owners are as
indicated above and may be contacted through Object Management Group, Inc., 109 Highland
Avenue, Needham, MA 02494, U.S.A.

TRADEMARKSThe trademarks, service marks, trade names and other special designations that appear on andwithin the Document are the marks of OMG, the Contributing Companies and possibly othermanufacturers and suppliers identified in the Document and may not be used or reproduced
without the express written permission of the owner, except as necessary to reproduce,
distribute and refer to this Document as authorized herein.

2019-02-25- 129 -

Version 1.0