3.2 C ONTENT D ETAILS : R ESULT S ETS
3.2.7 G: Trust and Security
F.1 Embedded IoT Risk Management
Risk management as part of regular project reporting, e.g., risk list and status included as part of weekly project status update, e.g., using a simple risk breakdown structure (Hillson, 2003).
Lightweight approach, no dedicated resource required;
use content from section 3.2.6.2 to populate initial IoT risk breakdown structure;
applicable to project categories E.1–E.3 in Figure 43
F.2 Dedicated IoT Risk Management
Dedicated risk management function, using tools like risk sector plots to do detailed risk assessment on key risks, following PRAM, FMEA, ISO 3100, or similar.
Requires dedicated risk management resource;
applicable to project categories E.3–E.4.
F.3 Dedicated IoT Risk Management with Custom Methodology
Similar to B but building on a custom methodology like COBIT 5 risk response workflow, with custom IoT features (Latifi and Zarrabi, 2017).
Requires dedicated risk management team, including methodology specialist;
applicable to project categories E.5–E.6.
Table 15: Result Set F—risk management
Delegation: A trustor trusts a trustee to make decisions on its behalf.
Infrastructure: The trustor must trust him- or herself and his or her base infrastructure.
An important enabler of trust in this context is information security. There are a number of information security management system standards (ISMSs) out there, which attempt to provide more or less holistic frameworks for managing security in IT systems.
Figure 46: PDCA (“plan-do-check-act”) model for ISMS
Susanto et al. (2011) identifies the “big five” of information security management system standards as follows:
ISO 27001: This standard introduces a cyclic process model known as PDCA (“plan-do-check-act”), as shown in Figure 46, which is designed to establish, implement, monitor, and improve the effectiveness of an organization’s ISMS.
BS 7799: Defines a set of best practices for ISMS, which were partly adopted by ISO 27001.
PCIDSS: The Payment Card Industry Data Security Standard, established by the Payment Card Industry Security Standards Council.
ITIL: The Information Technology Infrastructure Library (ITIL) defines best practices for IT service management, including security management.
COBIT: The Control Objectives for Information and Related Technology (COBIT) is an IT governance framework, designed to create an integrated view on control requirements, technical issues, business risks, and security issues.
In the following, these more traditional views on trust and security must be translated to the IoT.
3.2.7.2 IoT Perspective
While security is seen by many as a key element of trust in the IoT, the concept of trust is much broader. For example, IIC and others (2016) identify security, privacy, safety, resilience, and reliability as the key aspects of trustworthiness in the IIoT.
Another good example is provided by the Online Trust Alliance (OTA). OTA has published an IoT trust framework, which consists of four areas (Online Trust Alliance, 2018): security principles; user access and credentials; privacy, disclosures, and
transparency; and notifications and related best practices. The IoT trust framework includes the following concrete policy definitions:
Privacy: Privacy-related policies such as collecting and sharing data from IoT devices must be clearly disclosed; data collection is limited to the data needed to support functionality.
Disclosures: The IoT solution must include thorough, easily discoverable disclosures covering privacy policies, data collection, and device functionality.
Updates: Purchasers are informed about device updatability; updates are delivered securely with minimal user intervention or impact.
Control: Consumers must be provided with choices and controls regarding the data collected by the IoT solution; the solution must support to transfer or wipe the data upon loss or sale.
The European Union Agency for Network and Information Security (ENISA) has proposed a scheme for certification and the development of an associated trust label for IoT devices. In ENISA (2017), a number of required policies are defined:
Security by design: The security of the whole IoT system must be considered from a consistent and holistic approach during its whole lifecycle.
Privacy by design: Privacy must be made an integral part of the system.
Asset management: Asset management procedures and configuration controls for key network and information systems must be ensured.
Risk and threat identification and assessment: Risks related to the IoT devices must by identified using a defense in-depth approach.
A number of technical measures are also proposed, including:
hardware security
trust and integrity management
strong default security and privacy
data protection and compliance
system safety and reliability
secure software/firmware updates
authentication
authorization
access control—physical and environmental security
cryptography
secure and trusted communications
secure interfaces and network services
secure input and output handling
logging
monitoring and auditing
The IIC security framework (IIC and others, 2016) aims to create a broad industry consensus on how to secure IIoT systems. In addition to security, it highlights safety, reliability, resilience, and privacy as key characteristics of a trustworthy IIoT system. The functional building blocks of the IIC security framework are shown in Figure 47, including the four core security functions: endpoint protection, communications and connectivity protection, security monitoring and analysis, and security configuration management. These are supported by a data protection layer and a systemwide security model and policy layer. The paper stresses the point that IIoT systems are often built with components from different suppliers and that security must be ensured for each of these.
Figure 47: IIC security framework functional building blocks
Of course, the IoT is built on already existing technologies, including standard hardware and software, embedded hardware and software, and communication technologies. A large amount of research on enabling security has been done in the past decades in each of these areas.
Gasser et al. (1989) defines an early digital distributed system security architecture. Meier et al. (2003) describes how to improve web application security. Vai et al. (2016) provides a discussion on how to secure embedded systems.
Detailed research on IoT security—done, for example, by Riahi et al. (2013)—provides a systemic approach for IoT security. Farooq et al. (2015) details a critical analysis of the security concerns of the IoT. Xu et al. (2014) discusses design challenges and opportunities for security in the IoT.
IIC (2018c) defines an IoT security maturity model based on the plan-do-check-act (PDCA) cycle (see Figure 46). IoT security maturity is described in three dimensions:
security governance, security enablement, and security hardening. The model defines five maturity levels for each dimension:
1. Level 0 (none): No common understanding of how the security practice is applied and no related requirements are implemented.
2. Level 1 (minimum): The minimum requirements of the security practice are implemented. There are no assurance activities for the security practice implementation.
3. Level 2 (ad hoc): The requirements cover main use cases and well-known security incidents in similar environments.
4. Level 3 (consistent): The requirements consider best practices, standards, regulations, classifications, software, and other tools.
5. Level 4 (formalized): : A well-established process forms the basis for practice implementation, providing continuous support and security enhancements.
3.2.7.3 Result Candidates and Matching Considerations
Table 16 proposes two main areas for the trust and security result set: trust policies and target security maturity.
Result Set G: Trust and Security
# Result Name Description and Matching Considerations Trust Policies
G.1.a Basic Clearly formulated and publicly available IoT trust policies, e.g., according to the IoT trust framework (Online Trust Alliance, 2018)
G.1.b Advanced Dedicated role in the IoT project organization to manage trust policy enforcement during system setup and operations
Target IoT Security Maturity
G.2.a L0: None Acceptable during proof of concept
G.2.b L1: Minimum Acceptable for minimum viable product (MVP) G.2.c L2: Ad Hoc Acceptable for non-mission-critical IoT solutions
G.2.d L3: Consistent Should be the goal for all IoT solutions with significant criticality
G.2.d L4: Formalized Goal for IoT solutions with high mission criticality Table 16: Result Set G—trust and security