Industrial Internet Security Framework v 1.0 | Page 29

Security Framework

5: Managing Risk

tradeoffs should be documented to support reexamination and independent verification.
Decisions should be made based on future requirements across the lifetime of the system, not
on the current threat landscape of today.
Deployment of security solutions needs to consider the legal ownership of the deployed IoT
components and support systems. For example, the sensors or actuators may be deployed and
owned by one legal entity, the IT components by another, while the data may be owned by yet
another. In addition, a distributed deployment may be under multiple jurisdictions. Therefore,
challenges posed by the ownership of equipment and data by multiple legal entities also need to
be considered in assessing risks to the security of the deployed systems.
Deployment of security solutions must also consider operations, since security implementation
that hinders them tend to be circumvented by operators, rendering the security measures
ineffective. Security controls that frequently generate false-positive security alerts, require
repeated user authentication or prevent the user from operating in the expected manner impede
business productivity and should be discarded lest the installer be asked to remove the offending
security controls. Security capabilities must be efficient, accurate and provide demonstrable
value in contributing to defensive postures.
Other security programs may organize specific capabilities into different groups or elements
based on traditional methodologies used in a specific sector or organization. For example, the
North American Electric Reliability Corporation’s Critical Infrastructure Protection standard
(NERC-CIP standard 1), which lays out the security program approach for electric providers in their
jurisdiction, has organized the activities into eleven elements, some of which are unique to
securing an electric system. Another example is European Union Agency for Network and
Information Security (ENISA)’s Security Framework for Governmental Clouds2 that offers four
high-level phases with fourteen elements spread across them.
Several methodologies exist to assess security programs, the security posture of organizations
and their process for secure development and maintenance of their products. Examples are
provided in Annex A.3. IIC plans to utilize the Cybersecurity Capability Maturity Model (C2M2)
model, discussed in Annex B, in IIC testbeds.

5.2

RISK ASSESSMENTS

Business risk is defined by IIC as “the effect of uncertainty on objectives” and information security
risk as the “potential that a given threat will exploit vulnerabilities of an asset or group of assets
and thereby cause harm to the organization.” 3 Information security uses the term threat instead
of the more general term uncertainty.
A risk assessment is the process by which risk, and specifically information security risk, is
characterized. Approaches to information systems risk assessment are documented in many
See [NERC-CIP]
See [ENISA-SFGC]
3
See [IIC-IIRA2016]
1
2

IIC:PUB:G4:V1.0:PB:20160926

- 29 -