Search

This document is one of the deliverables of the ACCEPT project, under WP2 – Foundations, and in particular, task T2.4-Security Access Control (SEAC) framework design & guidelines for technical solution developers. The purpose of this deliverable is to give a detailed description of the final cybersecurity framework as it has been designed in agreement with the system architecture. A lot of attention has been given to the protection of the personal data of the users throughout the whole platform. All mechanisms and principles followed are designed with respect to General Data Protection Regulation. All data that are being processed inside the ACCEPT platform have been anonymized, while security mechanisms have been implemented in all components of the platform, to protect the end user’s privacy. A risk assessment has been completed by relevant partners to achieve a clear view of the potential risks and threats, and to plan the proper countermeasures to eliminate them. Finally, this deliverable describes the specific security mechanisms that were finally chosen and incorporated in the ACCEPT platform, following the previous version the Deliverable D2.5-Report on cybersecurity framework design & specifications for data protection & privacy v1.

This deliverable discusses the security mechanisms that are going to be implemented to the ACCEPT solution, in order to mitigate threats that may be present in the data communication procedures. As the whole ACCEPT architecture should respect the General Data Protection Regulation, a lot of attention has been given to the definition of the needs for such purposes, and the presentation of a Homomorphic encryption solution serving as an anonymization technique. Additionally, there is a thorough presentation of a RISK assessment that is going to be conducted for all pilot sites, in a form of a questionnaire. Task T2.4-Security Access Control (SEAC) framework design & guidelines for technical solution developers is part of WP2 – Foundations. The aim of the WP2 is to thoroughly analyse the end-user requirements of both energy consumers/ prosumers as well as energy communities and other market actors that will operate as retailers, aggregators or Energy Service Companies in line with Task T3.1- ACCEPT Living Labs design & establishment activities, part of WP3-Energy Governance, communities and demonstration site analysis. All analysis and mechanism presented in this deliverable are in a form of Security Guidelines as the development of the ACCEPT infrastructure is still under development. More technical details on the implementations will be given in the Deliverable D2.6-Report on cybersecurity framework design & specifications for data protection & privacy v2.

This report presents the work carried out in Task 2.3 of ACCEPT regarding the system architecture design process and results up to Month 10 of the project. In particular, the deliverable includes the high-level architecture model of the complete system, with the initial point being the design as presented in the Description of Work, and further refined and updated based on the work carried out in this period. This high-level architecture has also been mapped to the various SGAM layers to assist the future integration and development activities. The main bulk of the document concentrates on detailing the specifications and characteristics of the various system's software components. A dedicated template was created and circulated to all relevant partners in order to provide the components' functional and non-functional specifications, highlight interdependencies with other components, and declare the input/output data requirements (Annex I – Component’s Specifications and Requirements Template). Additionally, detailed component diagrams were created, and finally, the connection with Deliverable 2.1 (D2.1) was performed via a mapping of components to Use Cases that required relevant functionalities. Sequence diagrams were already created for D2.1 and are not presented here. This is the first version of ACCEPT's system architecture. It will drive the development of the first iteration of the system and its constituent components, up to Month 16 of the project. Following that, a pre-validation stage will evaluate the system prototype, resulting to refinements, changes and updates that will be reflected on the Deliverable 2.4, which will present the final version of the architecture.