Active Security for Connected Device Lifecycle: the CERTIFY Architecture

Active Security for Connected Device Lifecycle: the CERTIFY Architecture Sara Matheu1,3[0000−0002−7997−5737], Stefano Sebastio2,3[0000−0001−8905−9874], Antonio Skarmeta1,3[0000−0002−5525−1259], Riccardo Orizio2,3, Stefanos Vasileiadis3, Vasilis Kalos3, Katharina M¨uller3, Thomas Gr¨ubl3, Rosella Omana Mancilla3, Simon Tuck3, Thomas Bocek3, Vincenzo Cuomo3, Roland Atoui3, Sreedevi Beena3, Luigi Coppolino3, Roberto Nardone3, Dinesh Sharma3, Rohit Bohara3, Javier Parra-Dom´ınguez3, and Javier Prieto3 1University of Murcia, Murcia, 30100, Spain {saranieves.matheu,skarmeta}@um.es 2Collins Aerospace, Cork, Ireland {stefano.sebastio, riccardo.orizio}@collins.com 3The CERTIFY Consortium Abstract. The technological evolution of embedded devices over the last decades has revolutionized our way of interacting with the world, and, at the same time, brought significant cybersecurity challenges in managing digital products. One of the paradigms that has had the most impact on our daily lives is the Internet of Things (IoT), whose number is estimated to reach 74.44 billion by 2025 according to Gartner. Regulations and standards have been approved at both European and global level emphasizing the importance of managing the security of devices throughout their lifecycle. The CERTIFY framework architecture emerges as a solution to implement security management during the lifecycle of an IoT device, including mechanisms for secure design and deployment, threat monitoring and mitigation, and secure upgrading. This article describes the CERTIFY architecture, highlights its key technologies and shows how it operates to protect each phase of the device lifecycle. Keywords: ·Systems security ·Security services ·Hardware security implementation ·Embedded systems security. 1 Motivation The development of IoT-enabled services requires a comprehensive management of security aspects throughout the lifecycle of IoT devices. Due to recent technological advancements, such devices are composed by an increasing number of software components to provide advanced functionality and create new datadriven services. At the same time, widespread adoption and ubiquitous network access of these devices makes them attractive targets for hackers. Therefore, such devices need be equipped with protection mechanisms able to adapt to security changes throughout their lifecycle. 2 S. Matheu, S. Sebastio et al. One of the main requirements of the Cybersecurity Act (CSA) [6] European regulation is the compliance monitoring in alignment with the requirements of the European cybersecurity certificates or the EU statements of conformity [3]. This includes mechanisms to demonstrate continued compliance with the specified cybersecurity requirements, from the design to the operation phase of the device. To this end, the Cybersecurity Act encourages security through design practices and collaboration among certification stakeholders to monitor the security of the device. This initiative is intended to build a more trustworthy digital ecosystem for the benefit of the Digital Single Market. The new European cyber resilience regulation (CRA) [5] published in 2022 also expressly stated the need and obligation not only to implement security measures during the development and manufacturing of devices, but also to manage security changes that may arise after manufacturing and updating. Additionally, transparency is required in the communication of relevant security information to users and other interested parties. This law, which is expected to come into force this year (2024), is in line with the NIS2 [4] directive approved in 2022, which also requires the sharing of cybersecurity information that may be relevant to other entities (for example, other manufacturers), so that they can respond in a coordinated manner to a possible attack. These three regulations (CSA, CRA, NIS) are currently constituting the pillars of the European cybersecurity laws. The CERTIFY architecture builds on this basis, providing a cybersecurity lifecycle management framework for IoT devices intended to support the device security management with (i) security by design support, (ii) continuous security assessment and monitoring (iii) timely detection, mitigation, and reconfiguration, (iv) secure IoT Over-The-Air (OTA) updating, and (v) continuous security information sharing. Moreover, this information sharing will enable a continuous risk assessment, gathering evidence that could agile future certifications. 2 Logical Architecture of the CERTIFY Framework The CERTIFY framework is logically constituted by three layers. In the project execution, these layers are implemented in three different Work Packages - WPs (i.e., WP3, WP4 and WP5), as shown in Figure 1. The bottommost layer (WP4) provides services built on top of hardware functionalities available in RISC-V and ARM MCUs (micro-controller units) to instantiate and maintain a secure environment. In the second tier (WP5), software-based solutions provide monitoring functionalities at both device and network layers. Transversely, a third layer (WP3) groups the services offered by a remote center, in charge of the inventorying, patching and securely deploying CERTIFY-powered IoT devices. 3 Architecture Framework Overview The previously described logical view is then realized through the definition of the CERTIFY architecture framework. Components part of the framework have been grouped in different “domains” or “planes” according to the their purpose. Active Security for Connected Device Lifecycle: the CERTIFY Architecture 3 Fig. 1. Logical view of the CERTIFY architecture. An abstract representation of the CERTIFY framework is depicted in Figure 2, where, for the sake of clarity, only the main interactions between domains (and not individual components) are reported. In the figure, components of the architecture are described with different colors according to the phase of the lifecycle they mainly contribute to (i.e., orange for design phase, blue for the bootstrapping, and green for operations). Moreover, dashed lines represent external events that may lead to additional communication flows (e.g., the discovery of a new threat). The embedded device plane (bottom left in the figure) provides the CERTIFY security services built on top of hardware functionalities to instantiate and maintain a secure environment. It defines the IoT platform, by means of the CERTIFY API and services and the embedded security API. The former cover services and elements needed to support operations such as configuration, bootstrapping, upgrading, and monitoring. Instead, low-level components part of the embedded security API, i.e., the Secure Element (SE) and the Trusted Execution Environment (TEE), provide the necessary enablers to guarantee the security of the processes inside the IoT Device. The domain enforcement plane (center left in Figure 2) includes services for the secure deployment of the device within the domain and the application of updates on the device. One core component of this plane is the Secure Enrollment module, responsible for the registration of the devices in the domain and the issuance of the required cryptographic material to enable the creation of Direct Anonymous Attestation (DAA) signatures. Instead, the Secure update and upgrade agent provides a graphical user interface where security administrators can visualize registered software and devices, upload the software to the repository, and trigger the software update process. It also provides features to check for available updates. This component has a close relationship with the Inventory and Registry, as it is used to record every event, firmware, and device metadata. This integration ensures security, transparency, and an unbroken chain of trust 4 S. Matheu, S. Sebastio et al. Fig. 2. Simplified representation of the CERTIFY architecture. in the OTA process, incorporating secure cryptographic algorithms for firmware integrity and signing. The domain orchestration plane (at the center in Figure 2) provides coordination functionalities within the domain, and its main component is the Device and Domain Manager. It focuses on the high-level management of groups or domains of IoT devices. These domains could be based on various criteria, such as location, functionality, or other attributes. In particular, the Device and Domain Manager coordinates enforcement and reconfiguration of IoT devices based on the information received from other components such as the MUD manager or the SIEM-SOAR. All the configurations (e.g., policies applied, version of updates) are stored in the second component part of this plane, i.e., the Inventorying and Registry, which is managed by the device and domain manager. The domain runtime sensors and monitoring plane (top left in Figure 2) offers software-based solutions for monitoring, detection, and decision functionalities based on the information received from the device and other domain components. The Network Bootstrapping Monitor and the Intrusion Detection System (IDS) receive data from the CERTIFY API in the IoT device regarding the network activity in different phase of the lifecycle. They generate an alert if the network bootstrapping behavior differs from the expected one or if a threat has been detected at runtime, respectively. Alerts are sent to the SIEM-SOAR component (Security Information and Event Management - Security Orchestration, Active Security for Connected Device Lifecycle: the CERTIFY Architecture 5 Automation and Response) for aggregation and correlation analysis with other raw data and alerts. Also, this plane interacts with the CTI plane, since discovered threats can be shared with the MISP, and possible mitigations can be received in the form of threat MUD files. The Cyber Threat Intelligence (CTI) plane (top right in Figure 2) provides services for ensuring privacy-preserving security information sharing like vulnerabilities, mitigations or recommended configurations. A central pillar of this plane is constituted by the Privacy-Preserving Cyber Threat Intelligence (PPCTI) system, which is responsible for anonymizing sensitive data and attributes in cyber threat reports. For responding to identified threats, PP-CTI combines the Manufacturer Usage Description (MUD) [7] with the Threat MUD server [10] as threat signaling mechanism. The MUD is a standardized software description defined by the Internet Engineering Task Force (IETF) Request for Comment (RFC) 8520, that allows IoT manufacturers to advertise device specifications and supported communication patterns. In particular, CERTIFY extends the MUD model to accommodate finer-grained security aspects and diverse security policies. These encompass extended network access control, channel protection, data protection, and authorization policies [8]. In this regard, while a standard MUD server offers guidelines for allowed or restricted network activities for each device, a Threat MUD server would allow to incorporate real-time or near realtime threat information as provided by the PP-CTI. Finally, the external plane (bottom right in Figure 2) integrates all the manufacturer services that, even if not strictly part of the framework, are exploited by CERTIFY. In particular, it includes services for security assessment and certification, CTI sharing, device authentication, and MUD generation and storage. 4 CERTIFY Architectural Components Only a holistic way of managing device security can strengthen cybersecurity resilience while providing an opportunity for cost reduction. CERTIFY architectural components have been designed taking this into account. This section links the CERTIFY lifecycle methodology [11] with the components involved, providing a brief overview of each of them. 4.1 Design Phase CERTIFY considers that, during the design phase, the manufacturer creates a MUD file providing guidelines on how to use the device to guarantee an esablished security level. This MUD is used during the certification process to check compliance and could be later extended with new mitigation policies, if needed. The secure evaluation methodology is supported by the Cyberpass tool4, a cloud platform taking as input security requirements and suggesting an evaluation methodology that starts with self-declaration/self-assessment, allowing the 4https://www.cyber-pass.eu 6 S. Matheu, S. Sebastio et al. manufacturer to answer the questionnaire based on these security requirements. Once the process is finished, the MUD is signed by the Certification Authority (CA), and the manufacturer can publish it on its MUD server to be accessible to any buyer of the product. The MUD URL together with the device identity is then stored inside the device for its secure deployment. To provide support for the following phases of the lifecycle, CERTIFY provides as part of the IoT device formally proven authentication and cryptographic protocols and robust isolation mechanisms enabled by open hardware architectures and trusted computing standards. The architecture of the IoT device includes three strategic enablers (in orange in Figure 2): the SE, the TEE, and the Embedded Security API acting as an interface for these low-level components. The SE is a dedicated secure and physical tamper-resistant microcontroller allowing protection against high-level software and hardware attacks. Such an element, when present, will constitute the HW engine, assuring support for the securitization at a high level of the IoT device. While the SE provides PKCS11 functions [9] to be used by the agents to interface and invoke crypto functionalities, the TEE provides a trusted world for those applications that need it, supporting cryptographic functions and secure operations. This is necessary to execute and protect CERTIFY processes such as IoT authentication, derivation of keys or data integrity protection. The embedded security API aims to abstract the access to the low level IoT security components such as the SE and the TEE. Thanks to these enablers, high-level components described in the following subsections can securely enforce certain configurations inside the IoT device, not only policies, but also SW images (enforcement and reconfiguration agent), perform the secure bootstrapping and authentication of the device (bootstrapping and authentication agent), and the monitoring of the IoT device behavior and configuration (attestation agent). 4.2 Bootstrapping Phase The bootstrapping phase characterizes the change of the device state to operational. At this stage, devices are authenticated, authorized, and securely configured to get onboarded by the CERTIFY framework. CERTIFY divides the bootstrapping into three subphases, each of them involving some of the blue components of Figure 2. The factory bootstrapping. In this phase, the cryptographic material (device keys) and the MUD URL are statically configured and securely stored in the IoT during manufacturing (if available, in the SE). The domain bootstrapping. In this phase, the device requests to start the bootstrapping in the domain (bootstrapping agent). CERTIFY leverages the Constrained Application Protocol (CoAP) - Extensible Authentication Protocol (EAP) [2, 1] to authenticate the device and generate the keys. In particular, the bootstrapping agent acts as the EAP peer, the secure enrollment module Active Security for Connected Device Lifecycle: the CERTIFY Architecture 7 acts as EAP authenticator, the Device and Domain Manager acts as AAA domain server and the AAA manufacturer server acts as EAP server. Moreover, CERTIFY relies on the extended MUD to securely configure the device. For this, CERTIFY adapts the IETF architecture to the MUD extension and the interactions with other components. In this sense, the Extended MUD Manager is the main entity of the CERTIFY MUD architecture. It aggregates the functionality of the MUD manager and threat MUD manager, in charge of the processes required for obtaining and parsing the MUD and threat MUD file. This component has been extended from the IETF standard and the NIST proposal. In this way, the MUD, which is stored by the manufacturer in the Extended MUD Server, is obtained and translated to MSPL policies by the Extended MUD Manager using the URL provided by the device. While the Device and Domain manager orchestrates at domain level the enforcement of the MSPL policies, the Enforcement and Reconfiguration Agent is the component responsible for the internal IoT orchestration of the activities that need to be performed. Additionally, CERTIFY also checks that the device type is authorized based on its fingerprint. While attempting to join an IoT network, each device type exhibits a characteristic fingerprint. Such a fingerprint changes by device type (hardware) and firmware version. The network bootstrapping monitor exploits such a behavioral feature of the device to build a monitor that can pose constraints on the devices that can join the network as well as request the enforcement of specific rules. As fingerprints are characterized by device type (and firmware version), we envision that the manufacturer builds such a behavioral fingerprint and includes it as part of the extended MUD file designed in CERTIFY. The domain enrollment. In this phase, high-end devices need to verify their correct state based on the policies defined in the MUD. CERTIFY leverages the DAA protocol to authenticate the high-end device and generate appropriate policies for attestation. In the CERTIFY architecture, the Authentication agent is responsible for the creation and management of the DAA key and the Secure Enrollment module is the DAA issuer, responsible for the issuance of the cryptographic material required to enable the creation of DAA signatures. While the extended MUD file is retrieved from the server and enforced, enhancing device security in alignment with the manufacturer’s certification, the DAA allows verifying the correct state of the device based on this verifiable evidence and helps to decide whether the network should allow or not the device to join. All in all, these processes allow CERTIFY to leverage the extended MUD file information during device bootstrapping to enable the configuration of security policies before granting network access, enhancing the security posture. All the information about authorized network devices, configurations, identity certificates and upgrades are stored in the Device Inventory and Registry. In essence, this repository serves as a pivotal tool in safeguarding the security, functionality, and integrity of network devices while maintaining a com- 8 S. Matheu, S. Sebastio et al. prehensive inventory of their attributes by enabling monitoring and securing device-related information. 4.3 Operations Phase Once deployed, the device can generate dynamic credentials (authentication agent) based on its identity for securely communicating with the entities inside the domain. However, in the operational phase, devices must be protected from threats and vulnerabilities that are not anticipated at design time. For this reason, the CERTIFY framework integrates runtime monitoring and IDS with mitigation enforcement, security assessment, and security information sharing. Monitors are in place to send information about the IoT device (Sniffer and Tracer). Therefore, whenever a vulnerability is detected, CERTIFY can select and apply a mitigation. This information is processed by runtime attestation (Attestation agent) and by the Integrity monitor to check the fulfillment of the security properties certified (i.e., the ones contained in the MUD) during the operational phase. Network traces are also processed by the IDS that analyses the traffic in real-time and alerts on potential threats. Detection rules are periodically updated with new known signatures and new rules can be added to customize the solution to customers’ and users’ needs. The detection is enriched with an anomaly detection procedure that analyses offline datasets of network traffic to identify potential misbehavior and anomalies in the usage of the network. These events can be further processed with more advanced, and computationally expensive, solutions by the SIEM-SOAR that could also correlate multiple events identified in the network and on the device under analysis. The SIEM-SOAR tool combines the typical functionalities of SIEM and SOAR systems. While the SIEM allows for the collection and analysis of security events and contextual data, the SOAR enables the centralized handling of threat intelligence and automates responses to security incidents, significantly reducing reaction times and limiting potential damage. Given alerts details, the SIEM-SOAR identifies and applies the most appropriate reaction (e.g., publish information, request an update, apply a mitigation by reconfiguring system, network or device, or even check for threat MUD file from the Extended MUD Server). Then the Device and Domain Manager coordinates the mechanisms to enforce mitigations and updates on the IoT Device. If a update is required, the secure update and upgrade agent orchestrates the software update based on the information contained in the local SW repository,Manufacturer SW repository, and Inventorying and Registry. In any case, the Enforcement and Reconfiguration agent is in charge of enforcing the configuration on the IoT device. The CERTIFY framework also integrates mechanisms to share security information with manufacturers and other interested parties in a privacy-preserving way through the PP-CTI component. In particular, the PP-CTI includes data mining techniques such as suppression, generalization, K-Anonymity, T-Closeness, L-Diversity and Differential Privacy. PP-CTI interfaces with the Malware Information Sharing Platform (MISP) where vital threat information is shared, Active Security for Connected Device Lifecycle: the CERTIFY Architecture 9 for example, details of attacks, newly discovered vulnerabilities, threat alerts, and other valuable cybersecurity insights. Furthermore, PP-CTI & MISP integrates an access control layer, featuring identity management software such as Fiware Keyrock5. This allows CERTIFY to decide which entities can send or receive specific data, further enhancing data security and privacy. The information could then be accessed by other CTI providers and the manufacturer (MISP manufacturer). In the same way, new threats and alerts can be received and exchanged among these sources. 5 Conclusions and Future Work While European regulations advance cybersecurity by imposing measures to manage it throughout the lifecycle of a device, it is still not clear how to implement such cybersecurity lifecycle management in an efficient and coordinated manner. In response to this problem, this paper provided an introduction and comprehensive overview of the general architecture of CERTIFY. CERTIFY addresses the security management of an IoT device during: i) the design, proposing technologies such as TEE and SE that facilitate its subsequent management; ii) the deployment and secure configuration based on DAA and MUD standard; and iii) the operations by monitoring, mitigating threats, and combining mechanisms such as IDS, SIEM, SOAR and threat MUD, and device secure update. Additionally, CERTIFY also aligns with the NIS directive, acting as a bridge for sharing security-relevant information with other stakeholders. While evidence of security miscompliance can be sent to the certification authority to request a recertification, new detected threats can be sent to the manufacturer to design mitigations or patches in an efficient fashion. Throughout the paper, we have linked each component to its function within the device lifecycle, as well as highlighted the main interactions with other components that make security management effective in each phase. The holistic methodology adopted by CERTIFY ensures that the CERTIFY architecture is suited to address the complexities of managing the security lifecycle of IoT devices, offering robust security, privacy, and adaptability in an ever-evolving digital landscape. The architecture presented here will be used as a basis to implement and integrate the CERTIFY framework, and it is intended to be updated using the feedback collected through the validation activities. Therefore, in the following stage CERTIFY will focus on the integration work to lay the groundwork for the comprehensive validation of CERTIFY in the three IoT use cases considered as part of the project (namely, connected aircraft cabin, smart micro-factories, artworks tracking). Acknowledgments. Research partially supported by the EU through the Horizon research and innovation program CERTIFY (grant agreement no. 11069471) 5https://fiware-idm.readthedocs.io/en/latest/