WP1 defined SecOPERA's general management procedures, including quality assurance, risk analysis, the Data Management Plan, Innovations, and Open-source Legal Management. The SecOPERA Advisory Board, with four external members, was established, and their initial feedback has been received.
WP2 conducted an initial market and SWOT analysis. Dissemination KPIs are progressing, with participation in 24 events and 17 scientific papers published. Individual exploitation plans were gathered. Current and emerging standards were reviewed, fostering two-way interaction between SecOPERA and standardisation bodies.
WP3 focused on deriving relevant threat models for the SecOPERA platform alongside technology and user requirements. It produced the first version of the SecOPERA reference architecture. The threat models required an initial threat model reduction to derive meaningful attacks for the project. Given SecOPERA's broad scope, which decomposes an application into four layers, each layer was analysed for potential vulnerabilities. To achieve this, we reviewed popular threat-modelling approaches and opted to extend STRIDE with enhanced matrices incorporating the SecOPERA layering perspective.
For technology requirements, a comprehensive analysis identified the components/engines associated with each SecOPERA framework pillar. Each partner owning technical components of the SecOPERA infrastructure completed a series of data collection documents. Technical requirements aligning with the framework's objectives were extracted for each component. For user requirements, we provided an overview of various end users who benefit from SecOPERA’s security features, grouped into categories. This categorisation ensures that the framework is applicable to a wide array of users.
WP4 focuses on the research and development of security-related primitive modules, providing core functionality for SecOPERA engines and populating the secure module pool. In RP1, various primitive modules were identified for each SecOPERA layer. The architecture of each primitive module and initial versions were evaluated and tested. Plans were sketched for how these modules should operate in their final versions, identifying their inputs and outputs for integration into the overall SecOPERA solution. Each module’s implementation maturity varies, with hardware-focused modules taking longer to develop.
WP5 started at the very end of RP1. WP5 will build upon WP4 components, coordinate with WP6, and ensure all engines can transmit results to the SecOPERA dashboard in an appropriate format.
WP6 focuses on the integration and validation of the SecOPERA framework. The work includes integrating SecOPERA components and services into a unified framework, defining use cases, adjusting the framework to pilot needs, and aligning SecOPERA outputs with project objectives. During RP1, the SecOPERA MVP was released.
