Security at EBRAINS

EBRAINS Security Risks

Security is not a state, it’s a process. It’s a process that will in fact never stop; technology will evolve and with it, risks will change as well. There are many facets and factors to consider and implement and it is therefore difficult to assess and manage by nature

Infrastructure Overview

EBRAINS on the technical level is basically a support IT and virtual infrastructure provider and offers access to resources such as virtual research environments, scientific workflows, collaborative applications, knowledge systems, data analysis and visualisation tools, and code repositories.

The infrastructure uses and offers a mix of general-purpose information technologies and domain- specific tools to fulfil the needs of the European neuroscience community to conduct brain research.

EBRAINS users may also request access to specialised computing infrastructure, such as high- performance computing clusters, or specialised computing environments for simulations and modelling. To facilitate seamless access to resources and services, EBRAINS employs an identity and access management system. EBRAINS own operational infrastructure consists of cloud-like environments at FENIX sites on which applications such as code repositories or collaborative tools are hosted. The code consists of a mix of open-source software and code provided by developers of EBRAINS, partners or third parties under varying licences.

The actual services are mostly provided via EBRAINS partners in a federated fashion. External commercial services are used for example to host the main EBRAINS website, and to handle core services like name resolution.

Office-related data is mostly handled via a Microsoft subscription for internal communication, or such as chats and meetings which are currently facilitated using a variety of self-hosted and external services and applications.

EBRAINS staff are largely responsible for the security of their work machines and can use them with few restrictions. Work from home with access the VPN is possible if they chose to.

Adversaries

One of the essential questions to answer for implementing effective security guidance is: Who is the adversary? The answer to this question shows the likely approach of relevant attackers and possible defence strategies. The differences stem from the attackers’ motivations, resources, sophistication, and persistence.

Typically, adversaries are categorised into opportunistic attackers, targeted attackers, insiders (which may expand in this case to project partners), APTs11 (Advanced Persistent Threats) and state-sponsored adversaries. It seems unlikely that EBRAINS is a target of nation-state level attackers. Opportunistic attackers and insiders (or insiders falling victim to opportunistic attackers) seem to embody the major groups of adversaries EBRAINS must deal with. But it is not totally unlikely that EBRAINS falls victim to APTs or targeted attackers either directly or as collateral damage of an attack against its partners.

It should be noted that provenance12 and reproducibility13 alone are not effective security measures to actively protect against certain attack vectors. Provenance is useful for tracking data history, but it’s not enough for effective security. Additional measures like access control, encryption, authentication, and intrusion detection are necessary for comprehensive protection.

Opportunistic attackers

Opportunistic attackers typically take advantage of easy targets without specifically targeting a particular entity. Common threats posed by opportunistic attackers include for example automated scanning and exploitation attempts to gain unauthorised access, compromise systems or cause data breaches, malware infections through various means, including email attachments, malicious websites, or compromised software, or credential theft and account compromise through techniques like phishing, social engineering, or brute-force attacks.

Insider threats

Insider threats refer to security risks which arise from individuals who have authorised access to an organisations systems, networks, or data, but misuse or abuse that access either intentionally or unintentionally. It’s very important to note that most insider-related issues are not purposefully malicious; however, they must be considered a risk to the security of an organisation and its infrastructure. Insider threats can be roughly classified into negligent insiders who pose risks due to carelessness, malicious insiders misusing privileged access, or infiltrators, who are external actors who obtain legitimate access credentials without authorization. These threats underline the need for robust security measures to address varying motivations and behaviours and protect organisational and operational security.

Advanced attackers

More sophisticated and targeted forms of security threats compared to opportunistic attacks are typically carried out by well-resourced and persistent adversaries, such as organised criminal groups, or individuals selling their access to various markets. These attacks are normally significantly more difficult to detect, often including zero-day exploits, custom malware, rootkits, and obfuscation. These techniques are designed to evade detection, bypass security controls, and maintain long-term persistence within the targeted infrastructure.

Summary

The biggest risks lie in attacks against internet-facing services, security vulnerabilities in custom and third-party software and a variety of insider threats. Development processes in scientific environments require constant improvement and change which carries the risk to employ technology that is not hardened enough to combat increasingly sophisticated attack automation, for example against soft targets, like humans. On the other hand, EBRAINS itself possesses a risk to its partners, like FENIX, to gain for example unauthorised access to computational resources or data.

Recommendations for security procedures and validation

Research projects rely heavily on knowledge acquisition, verification, and representation, not just in neuroscience. The recommendations summarize an understanding that there is a difference between general IT, scientific tools and services and more neuroscience-specific applications. EBRAINS operates currently in somewhat all categories, for once because technology is in real life often more complicated than it is on paper. But it also stems from a lack understanding by the author what the coherent vision of what EBRAINS may be at the time of writing. However, the recommendations assume a more generic scientific knowledge service as the goal.

Security Risk Mitigation

There are many ways to look at security risks and how to manage or mitigate them. The simplest way to understand it is as the question how much effort to spend on observation and protection of what. EBRAINS is facing considerable risk of security incidents that should be managed. There is not the one way to manage security, no two environments are the same, but there are well-established building blocks.

Incident Management

An incident in security context is an event that could lead to loss of, or complete or partial disruption to, an organisation’s operations, services, or functions. Incidents will most definitely happen, and the ability to understand and respond to such an incident can make all the difference.

Security teams are normally organised in the form of so-called CSIRTs (Cyber Security Incident Response Teams). Despite the “response” in the title, incident management consists of prevention, detection, resolution, quality control and feedback. CSIRTs often use iterative design and management methods to control and continual improve processes and products and have shown to be effective for security management. Well-established maturity models such as the Security Incident Management Maturity Model (SIM319) can be used to assess and improve the capabilities of a CSIRT long-term. Incident management needs to act as an interface internally and to other entities which may report, are affected by and or need to be informed about insecurities. How the incident management is organised in detail and what metrics it can deliver for what purpose depends on numerous factors, starting with the data and technology which needs to be secured and depends on the allocation of adequate resources to implement appropriate reviews, security controls, and deploy robust security policies and procedures.

Vulnerability Assessment and Management

Vulnerabilities appear in custom as well as in third-party software and services. Possible sources of vulnerabilities include weak authentication and authorization, inadequate input validation, insecure APIs and libraries, data storage and communication, poor configuration management, and code quality issues. Organizations respectively their security teams receive knowledge about vulnerabilities through various sources such as own security audits, security advisories, vulnerability databases, vendors, and participation in security communities and forums. In environments with a lot of custom code and data usage, vulnerability assessment relies primarily on automation and is closely related to software quality processes. Ideally, these processes inform and influence each other to improve automated security checks and yield most effective results from manual security audits and reviews. One major difference between custom open source software which is built in-house and third-party open source software maybe the need for different security communication: Handling of custom software vulnerabilities involves providing bug reports, offering patches and informing users, while third-party software use boils either down to risk assessment and patch management (the vast majority of cases, see Figure 8), or security assessment and reporting to the vendor, including for example providing PoCs (Proof of Concepts) or patches if security bugs have been found in their components.

Auditing custom code needs a different approach. Automated security tests exist and already used in current CI/CD processes, but manual audit assistance requires the understanding where the blind spots are: Automated code audits may miss complex issues that involve subtle logic errors, context- specific vulnerabilities, or non-standard coding patterns that are not covered by predefined rules or patterns recognized by tools. The code needs to be identified typically containing subtle bugs with potential high impact, dealing for example with authentication and authorization, multi-threading and concurrency, cryptography, parsing and input validation. A knowledge graph could assist the manual review with a representation of the code based on curated keywords and patterns. This rather pragmatic and simple approach has been shown to be surprisingly effective.

Code and Service Security

The major goal of all subjects in this report is to improve maturity. Technical maturity refers to how developed and reliable a technology or product is after undergoing manual and automated testing and improvements following a meaningful methodology. A high level of technical maturity means it’s stable and ready for practical use with minimal risks.

Living documentation

Living documents for each code quality and security process is an important component, which means it requires a constant review and possible update to remain useful. Reviews can happen for several reasons and for different aspects as needed. An example may be availability of new CI tools and pipelines, use of new languages, libraries, or computer-assisted coding. Reviews should always happen as post-mortems of incidents. In this context, an incident may refer to an accident with impact (like a breach), but it may also refer to knowledge about insecurity in custom code or unsafe procedures. In a scenario with an EBRAINS CSKG, the living documents could also act as a form of curation for what code quality and security processes are recommended or required for what tool chains.

Code Reviews

For code quality and security, there is no single better measure than code reviews on all levels where code is used and produced. The idea is that the code has been seen and understood by more entities than the author and some automated checks. How that applies in detail is, again, far beyond this document, but the main areas are the review of use of security-related functions in third-party code, own custom functions (and here front and foremost the security critical ones), and for configuration in service context – and it may apply internally and externally, depending on the nature of software project involved. Code reviews may also happen as part of an internal or external security audit, or in the aftermath of an incident.

Secure Development and Service Lifecycles

Every piece of software and every service undergoes phases, from the first concept to end of life, and often the original idea gets changed due to limitations, restrictions, or unforeseen technical challenges, or expanded to cover more use cases until it is replaced or retired. Depending on the nature of the software or service, such changes may have a significant security impact. Changing security requirements boil down the questions what critical functions exist (for example handling authentication and authorization, reading, and writing files, communicating with the network, accessing databases), how changes affect the security of the system, and if there is the need or potential to improve technical and organisational processes to cover new attack vectors. Agile development and services principles are prone to underestimate new risks introduced with expanding capabilities of a software or service. The essential question in this context is if security assumptions hold under different conditions or configurations. Services may be actively and continuously evaluated on application level, for example with internal and external penetration tests or other static and dynamic security tests to gradually increase robustness and maturity.

Awareness building, training, and education

Awareness is a necessity to increase the overall security posture of the staff and constituency and help to detect, prevent, and recover from incidents. Security training and education programs should aim at understanding the changing landscape and threats, facilitate information exchange, and train on tools, processes and procedures related to security and incident management. Basic trainings should be developed internally so that they can be used and expanded, for example for new developers and staff. For subjects of new technologies or specialised topics, using external resources it advised. The trainings should not only cover topics for developers and IT staff, but also management and other employees. As mentioned above, code reviews are an effective way to secure software. Reading code is harder than writing code, effectively learning how to read code requires developing strong comprehension skills, understanding coding contexts, gaining familiarity with different languages and frameworks, and employing thorough documentation practices.

A common way to educate developers and administrators for this type of ability are trainings on how to spot and exploit vulnerabilities. Besides being practical and fun, such trainings raise awareness what to look for and what matters for security when assessing code and configuration.

Looking Forward

The recommendations in this report focus on the ability for continuous documentation, technical assessment, improved awareness, and preparedness. It expresses the need for a sustainable CSIRT, clear lines of communication, meaningful reporting mechanisms, and continuous decision-making processes. It also proposes the use of an ISMS based on a knowledge graph, maybe using the EBRAINS KG, and to develop the ontologies needed. Security and training programmes need development, based on priorities and available resources.