Nowadays, security mechanisms are essential to every IT system to protect the users, and the information handled. Usually, security is defined by the famous CIA-triad, namely the concept of Confidentiality, Integrity, and Availability. These are the key requirements when we are addressing security-related aspects. Confidentiality is the prevention of unauthorized or improper disclosure of data. Integrity concerns the assurance that data is not modified in unwanted way. Availability aims at keeping data access and resources available whenever required, frequently accomplished by fault tolerance mechanisms, utility or usability, and controlled concurrency. Security focuses on Information Systems. Privacy is the right of the data owner to make data available only to whomever he/she wants. While sharing some confidentiality aspects, the objective is different, and so are the required policies. To meet these security and privacy key requirements in the FISHY project, it was necessary to develop a module (SPI – Security and Privacy data space Infrastructure) aiming to deploy the necessary mechanisms to ensure those properties.
SPI is a fundamental architectural component of the FISHY Project, being responsible for the access control related to all devices, processes and ICT components of systems deployed in supply chain organisations. This architectural block is composed by three main components, namely Identity Management, Access Policy, and Data Management. These modules are designed with the intent to provide an interface between low-level components, higher-level modules, and users, demanding constant and all-around communication with every component of the FISHY Project. According to the FISHY architecture, it should provide both local and federated services since FISHY is spread along different domains.
The Identity Manager component manages users’ IDs and roles associated to the FISHY platform. Using well-known protocols (OpenID Connect and OAuth2), it also provides authentication, authorization, and auditing features. It was implemented using Keycloak, an open-source solution that fulfils all the previously described access control requirements.
The Access Policy module manages security and privacy policies in the FISHY Platform. The Extensible Access Control Markup Language (XACML) was chosen as the underlying technology for designing, verifying, and maintaining authorization policies, as it intervenes in transforming policies written in natural language into a format that can be automatically interpreted by the platform. This module establishes a link and cooperates with the Identity Manager and the Data Management through its core policy engine. For most components, authorization policies will be resource-oriented, establishing which operations and under which conditions a particular FISHY component can perform over resources’ data. Role-based or user-oriented policies will also be in place to control which resources and under which conditions users can access. Both flavours are fundamental in a secure implementation of a distributed system like the FISHY platform and are fully supported by XACML and Keycloak. Privacy policies can be implemented through a specialized version of resource-oriented authorization policies with additional conditions pertaining to required anonymization. In the FISHY project, specifically the SADE Use Case, it is easily acknowledged that privacy is one of the requirements to manage at all times. Most data provided by vehicles can be linked to their owners, falling into the private domain and demanding explicit authorization to be accessed in clear. Otherwise, that data can be accessed in an anonymized way. Provisioning for the deanonymization function is also required for forensics and statistical analysis purposes. Such access should demand owner authorization too. Again, specific resource-oriented policies will be created for that purpose. FISHY aims to provide security services for supply chains in general. Like the SADE use case, many others supply chains can handle private data, requiring compliance with GDPR. One of the resulting impositions is adopting the privacy by design and default approach. SPI provides the formal mechanisms to specify and verify the authorization policies, which are a core function in such an approach.
The Data Management module is especially concerned with the enforcement of privacy policies implementing anonymization techniques on data matching specific privacy policies (the Anonymization component), as described above. Besides, this module also provides data format uniformization and normalization for data collected by the FISHY agents (the Adaptation component) placed in the organization premises. The data normalization feature is necessary since the data collected from different tools are provided in different formats. A standard data format promotes data correlation mechanisms and empowers the FISHY analysis capacity. The Data Management module uses the Common Event Format (CEF) for that purpose. CEF is a generic data format inspired by the well-known Syslog mechanism and is already used by several security event management and visualization systems. Besides its generality, using CEF also promotes the possibility of interchanging data with other related systems. Concerning the implementation, the Data Management module provides an entry point for each low-level data source requiring such transformation and outputs the correspondent data in CEF into the Central Repository, where it can be accessed by any high-level FISHY component – or even exported to an eventual external tool.
André da Silva Oliveira
Henrique Santos
University of Minho