This deliverable of the CS-AWARE project is the second in an iterative series of three deliverables (D2.1 System and dependency analysis (first iteration) – Cybersecurity requirements for local public administrations, D2.2 System and dependency analysis (second iteration) – Pilot scenario definition and D2.3 System and dependency analysis (third iteration) – Pilot scenario specification and self-healing strategies) that will be delivered throughout the project run time. The second iteration picks up on the first iteration to refine our understanding in the three main thematic focus points covered in the original deliverable: an initial threat assessment in the LPA context, an analysis of external information sources and a pilot specific analysis in the partner municipalities of Larissa and Rome. In addition this deliverable adds a fourth focus point, the definition of CS-AWARE use cases, based on our understanding and results of the first three topics.
For the initial threat analysis, the updated versions of the reports covered in last year’s deliverable were investigated for changes that would shift our understanding of risks in LPAs. It has shown that during the last year only minor shifts in the cybersecurity landscape could be observed, none of which were specifically relevant to our understanding of LPA risks. Based on those findings it was concluded that our initial risk analysis of D2.1 is still valid and does not need to be updated.
In the context of analysis of external information sources, D2.1 focused on classifying available information sources and identifying relevant sources in those classes. In D2.2 our focus shifted to those information sources that can be utilized for dynamic collection of cybersecurity relevant information specific to the CS-AWARE context. Based on the classification of D2.1, those sources are mainly related to threat intelligence, vulnerability data as well as social media sources. A challenge we saw specifically with threat intelligence sources was that there are a multitude of free and commercial data providers, yet little work has been done in assessing the quality of those providers. It was therefore decided to create a CS-AWARE specific scoring system to identify the most relevant information sources and shortlist those that should be collected with priority. This was done by defining a set of indicators, assigning an importance value to each indicator and assess all relevant sources based on those criteria. A shortlist of sources that will be considered with priority in CS-AWARE was created. Our results indicate that a methodical approach towards assessing the quality and relevance of information sources does offer some additional value to a purely intuitive selection. With respect to social media, it was already concluded in D2.1 that Twitter and Reddit will most likely provide the most relevant information for CS-AWARE, based on expected quality and accessibility of data. For D2.2 the challenge was to narrow the focus of data collection by identifying relevant users and communities in those two social media platforms that are considered relevant for cybersecurity and CS-AWARE. It was decided to use user/community based shortlisting since this usually yields in better results and less false positives as compared to keyword based shortlisting. Taking into account the dynamic nature of social networks, we see the list as a solid basis for the CS-AWARE data collection efforts that will dynamically evolve based on how the relevant users and communities evolve.
The analysis of LPA specific information was refined by the second round of system and dependency analysis workshops. After gaining a comprehensive overview of the core system setups by identifying the critical assets as well as dependencies among those assets during the first round of workshops (reported in D2.1), the challenge for deliverable 2.2 was to refine this understanding by identifying the critical processes of the services that are relevant for CS-AWARE piloting, and the associated information flows through the system and dependency graph that those processes create in day-to-day operations of both system users and administrators. To achieve this understanding, the workshops were organized in two parts: the system and dependency focused workshop to refine the understanding of systems and processes already started in the first round of workshops, as well as a more end-user focused story telling workshop to determine the cybersecurity related problems users and administrators alike face on a daily basis, and the procedures and processes used to solve those problems. Based on the results of those workshops, as well as the initial risk analysis, the CS-AWARE team was able to define an approach to pilot scenario definition. It was concluded that the best approach will be to model the pilot scenarios after the information flows each relevant process creates in the systems. Monitoring and analysis will be mainly based on behavioural analysis of relevant information flows to detect unusual and suspicious behaviour. It was concluded that the monitoring points identified in D2.1 are able to capture the information required to perform this analysis.
In addition to the pilot scenarios, specific use case scenarios have been defined, based on the experience gained during the initial risk analysis, the analysis of data that is available from external information sources, as well as the requirements that end users and administrators have – derived from the results of the system and dependency analysis as well as storytelling workshops. Four specific use cases could be identified: Vulnerability awareness (map classified vulnerabilities to specific LPA systems/components), Behaviour analysis (identify suspicious behaviour and if possible classify according to data received from threat intelligence), General security warnings (inform about general and/or currently ongoing security events that may become relevant to the specific context of each LPA). The final use case, if the CS-AWARE project decides to allow analysis of some data considered personal identifiable data under GDPR rules (specifically IP and DNS entries), an analysis of connections originating from or going to specific IP/DNS entries that are classified as malicious by relevant communities can be conducted. While we assume that the list of use case scenarios covers all aspects relating to cybersecurity awareness that can be covered considering the data that is provided by the various communities, additional use cases may be added in case new information arrives.