In Brief
Security of open-source solutions in the business interconnected market (especially in IoT where a single product may include components from various Tier 1 or OEM manufacturers) is hard to assure. OEM SW/HW developers that employ open-source solutions must assume that any component provided by 3rd parties needs to be reassessed for security as there is not holistic security auditing/testing process to cover the full production line.
The plethora of open-source HW/SW solutions on devices with constrained resources and no trusted environments leads to a considerably expanded threat landscape. The restricted execution environment reduces bootstrapping new devices in an IoT network and deploying/patching them securely; and the full DevSecOps of connected device open-source HW/SW must be reformulated offering security guarantees on the usage of open-source solutions.
SecOPERA will provide a one stop hub for complex OSS/OSH solutions offering to designers, implementers, operators and open-source HW/SW developers the means to analyse, assess, secure/harden and share open-source solutions as these are integrated in an overall complex product within a networked connected environment.
SecOPERA provides a framework supporting the open source DevSecOps lifecycle that comprises (i) a decomposition and security audit/testing engine that analyses open source solutions (OSS/OSH) (ii) an adaptation engine that debloats OSS/OSH code to remove unrelated open-source code and reduce the code attack surface; and a security enhancement process to harden the OSS/OSH solution (iii) an updating/patching mechanism so that the SecOPERA open-source
flows remain secure even if their open-source code starting points are vulnerable.
On top of that, SecOPERA hub provides (iv) an open-source repository for secure modules that is used in the security enhancement mechanism of open-source solutions; and (v) an open-source repository of security hardened OSS/OSH solutions and their security guarantees
Objectives
This project has received funding from the European Union’s Horizon 2020 Research and Innovation programme under grant agreement No. …..
Objective #1
Provide a complete Security Auditing-Testing toolbox in order to identify security issues in open-source software and hardware
Objective #2
Research and Develop Security Hardening and security enhancement of open-source solutions
Objective #3
Offer Adaptable security solutions for the open-source community (SW and HW) at cognitive, network, application and device layers that are securely updated/patched
Objective #4
Provide the SecOPERA hub that will offer the SecOPERA pool of open-source solutions (with security guarantees) as well as the SecOPERA framework with all the tools to support the SecOPERA concepts of Decompose, Audit/Assess, Secure, Adapt, Update
Objective #5
Validate the SecOPERA solution in two pilots using several use cases that are linked with all aspects of the SecOPERA hub
Objective #6
Provide a viable exploitation and business model of the SecOPERA solution that will comply with the open-source nature of the SecOPERA Framework, repository, and the associated open-source data, software and hardware components
Pillars
In SecOPERA, we view open-source solutions of a connected device as a series of interrelated components associated with Cognitive, Network, Application, and Device layers. A SecOPERA secure flow is a series of security credentials generated through security audit/testing of open-source components, each belonging to one of the four SecOPERA connected devices layers. The SecOPERA security flows constitute guarantees of an open-source solution but also an anchor of its current and future security. To provide and support through the full OSS-OSH development lifecycle its DevSecOps, for the security flows, in SecOPERA we introduce five pillars that complement each other:
Pillar #1 - Decompose
This pillar acts as the entry point of all other pillars. In SecOPERA, an open-source solution provided as input to the SecOPERA ecosystem is analysed and decomposed in OSS-OSH components that fit into the four SecOPERA layers. Apart from that, in the decompose pillar using open-source code scanning and component analysis techniques, we associate all components with their respected open-source repositories and create a dependency graph that describes the association of all open-source structures within an open-source component as well as the association between open- source components within the open-source solution.
Pillar #2 - Audit / Access
Provided open-source solutions are decomposed on the various layer components and that their dependencies are mapped, a vulnerability scan is performed on the dependent OSS-OSH structures that constitute the open-source component to discover known vulnerabilities as those are stored in CWE-CVE databases. The found CVEs are associated with the dependency graph of the open-source components, thus forming a vulnerability graph, and are integrated in the SecOPERA secure flow node. However, given the open-source sustainability problem that makes it hard to report and formalize CVEs associated with specific libraries, in SecOPERA we provide a security auditing/testing capability that extensively audit/assess open-source components for their security status using various different state-of-the-art and beyond the state-of-the-art techniques and tools for each SecOPERA layer. Common to all layers is that vulnerabilities are discovered using penetration testing. What is different, for each layer, is: (a) the mechanics of penetration testing, and (b) the type of vulnerabilities the auditing is searching for.
Pillar #3 - Secure / Harden
In SecOPERA, we aim to provide several open-source security modules that can be used to enhance the security of an open-source component or the overall OSS-OSH solution. These modules will be designed and developed for each one of the connected device layers i.e., the cognitive layer, the network layer, the application layer, and the device layer. Their goal will be to “harden” the security of open-source components of each layer as part of a SecOPERA secure flow achievement especially when auditing a particular layer may be incomplete. In these cases, secure pillar modules will be applied on the layer for containing likely existing, but not yet discovered, vulnerabilities. The secure pillar’s final goal is to provide to the SecOPERA ecosystem a secure module pool that can be accessed by the adapt pillar operations or by any third party that participates in the overall ecosystem.
Pillar #4 - Adapt
The Adapt pillar aims at combining the SecOPERA secure modules that can harden open-source solutions with the actual audited components of an open-source solution for a given series of defined services. The outcome would be an open-source flow corresponding to the initial open-source solution that is secured against a broad range of cybersecurity attacks (of all four SecOPERA layers) and that is adapted to the prescribed services of this solution as well as the capabilities of the device in which the solution will be deployed. In SecOPERA, we will provide the tools to securely combine open-source components and provide open-source hardware/software solutions tailored to services.
Pillar #5 - Update / Patch
In SecOPERA, we also provide a mechanism that through formal verification will be able to support the full lifecycle of open-source services by offering tailored patching. We will build upon work done in the Vessedia project, where some experiments were done to analyse the 6LoWPAN management platform, for distributing OtA update to low-power devices connected through a 6LoWPAN network. Higher-level models of the code under analysis will be built, and lower-level formal properties (the ones that generic Frama-C analysers can attempt to verify) will be automatically derived from this high-level view. The use of the SecOPERA secure flow guarantee for a given open-source solution (open flow) acts as the starting point of formally verifiable patches since such patches rely on the existing open flow which through the SecOPERA secure flow is fully characterized for its security. The dependency graph within the SecOPERA secure flow is revisited during update/patch and the code structures to be updated can be easily linked with all the other components that it interacts within an open flow. When introducing an update, the security audit is repeated but the assessment is performed in a more focused way since the secure flow information allows the speed up of the process.
Project Information
HORIZON-CL3-2021-CS-01
Call
HORIZON-CL3-2021-CS-01-02
Topic
HORIZON Research and Innovation Actions
Type of Action
1 January 20213
Start date
31 December 2025
End date
€ 4.581.135,00
Overall budget
