Figure 1: View of the default CEAA UI
In previous blogposts we have seen how ASCLEPIOS implements advanced data access control mechanisms and leverages powerful cryptographic schemes and trusted hardware capabilities to enhance the security level of healthcare services and enable healthcare providers to take advantage of cloud computing.
The ASCLEPIOS framework can thus be used to instantiate secure workflows for sharing data and insights. At the same time, this brings a need to monitor the execution of these workflows and the usage of the underlying services, to help healthcare providers understand how data access operations take place and allow them to timely detect and handle any abnormal behaviours.
The ASCLEPIOS component that undertakes this task is the Cybersecurity, Encryption and Access Analytics for Healthcare Providers (CEAA) module.
By delivering insights into encryption and decryption activities, data access patterns, normal and abnormal behaviours, CEAA helps healthcare providers build more robust threat preventive mechanisms around their infrastructure and data. Of-course not all identified “abnormal” behaviours are malicious and CEAA also aims to help detect cases where benign users are having difficulties in using the services in an appropriate way or are, knowingly or not, interacting with a system in an unconventional way which could make it (or the underlying data) vulnerable to attacks.
To achieve its goal, CEAA monitors interactions both between and within the different architecture layers and components of the ASCLEPIOS framework.
See for example the following scenario: A user may execute a search using the ASCLEPIOS symmetric searchable encryption services, to either retrieve patient files or as a first step to identify the inputs that need to be fed to the functional-encryption enabled analytics. For these workflows to be executed smoothly, encryption and decryption operations also run in the background.
To effectively identify abnormal activity, CEAA needs to be active during this whole workflow and to examine each request independently but also to provide insights into the sequence of the performed requests across the various services. Hence, it needs to receive and process all logs generated by the ASCLEPIOS services and all foreseen interacting entities.
Simply put, for CEAA the more information it has, the more trustworthy its analysis results will be. Yet, this is not a straightforward process. Why?
The reason is that the decision to obtain and analyse such detailed information cannot be made independently of the privacy and security considerations that guide the framework as a whole. In other words, there are inherent technical limitations regarding the information that can be logged and provided by the underlying tools and services: Apart from security and privacy concerns around revealing information regarding the inner workings of some services, there are also technical limitations that may hinder the extraction of such information altogether and these limitations are of paramount importance for the security of the underlying services, as they guarantee that information leakage is not possible.
Designing a secure logging process, including determining the information that should be logged and the way the logs are stored and accessed, is therefore a challenge! Since the ASCLEPIOS services are designed primarily to ensure privacy and security in data access and exchange, it may be inherently not possible to provide all information to the security analyst in a granular manner – a worthy compromise considering the benefits!
Where we are now…
An important step towards tangible results has been to define metrics of interest to the healthcare provider’s security analyst to help identify incidents that require further investigation. Some metrics are generic, e.g. number of successful/failed requests within a given timeframe, whereas others are ASCLEPIOS-specific, e.g. percentage of functional encryption computations that came as a follow-up to a search request (through searchable encryption).
Apart from ingesting the logs of these requests, CEAA provides a contextualisation mechanism to further improve the analysis. Contextualisation may again be generic, e.g. enriching an IP with geoIP information, but also organisation-specific: Detection of abnormal behaviour entails having a common ground of what constitutes normal behaviour, and this depends on contextual and operational information of the underlying organisation. Indicatively, assessing whether receiving requests over patients data during non-working hours of the organisation is normal requires at least the following to be known: (a) which are the working hours and (b) whether for the specific organisation such behaviour is expected (e.g. due to research work conducted by interns which is not restricted to specific time intervals) and whether this is something permanent or temporary. This contextualisation of information, which is organisation-specific, is also helpful in terms of presentation and visualisation, as it helps create a more intuitive interface for the security analyst working for the specific healthcare provider.
To truly assist security administrators of healthcare organisations in the identification of “interesting” events that require further investigation, CEAA needs to limit the amount of data they need to review only to the actually meaningful. To achieve that, CEAA comes with a rich default dashboard that offers insights into all identified metrics and even allows for more to be defined, computed and visualized. This default dashboard offers alternatives for each security analyst to choose from and allows configuration across the complete pipeline: input data, contextualisation and analysis process, rule definition and visualisation adaptation.
That was a first sneak-peek into the ASCLEPIOS CEAA module- stay tuned for more! In the meantime, if you want to dive deeper into the CEAA implementation details, as well as to see how it can also be of added value from the cloud service providers’ perspective – offering targeted performance insights – you can visit our deliverables section.