Keywords

1 Introduction

Several approaches including tools and methods have been proposed for dealing with the gap between development and operations teams (DevOps) [1]. From a conceptual point of view, the current tools and methods provide solutions for solving or at least minimizing this gap. From real applications development point of view, there are too many artifacts, and automation is a must. The automation in DevOps environments is complex because it is hard to integrate and combine all artifacts, especially when deploying applications in the Cloud [2]. The real applications’ size and the market needs are requiring a fast and continuous delivery of products with new functions providing added value to customers. From a software engineering perspective, tools and methods must be aligned, and the best practices must be considered in order to provide an added value to customers. Time to market is a competitive advantage and DevOps helps developers and operations teams along the delivery process. Continuous Delivery (CD) is an added value, and CD and DevOps practices are intertwined IT practices [3].

Security is becoming a hot topic in several domains, and therefore security practices, methods and tools must enhance the security inside the final products. In this sense, SecDevOps and DevSecOps have appeared, and they incorporate security practices in DevOps environments [4]. There is no consensus on how security must be injected within a DevOps environment. For example, authors in [5] define DevSecOps as a way to incorporate cybersecurity practices within a system in a cloud environment by using a set of scripts such as: scripts for building the servers, scripts for configuring them, and so on. Other authors define DevSecOps [6] and they highlight that developers and managers are worried about the extra time it takes to produce code when adding security [6].

A real scenario where these aspects are especially crucial is the health sector. In fact, there is an initiative promoted by the eHealth Digital Service Infrastructure (DSI) Operations [7] from the European Commission promoting the exchange of health records among European countries. The eHealth DSI (eHDSI) is the initial deployment and operation of services for cross-border health data exchange under the Connecting Europe Facility (CEF). The aim of this platform is to connect different national health systems by using standards [8] to exchange eHealth record’s patient data, among other data. A change within the software platform called OpenNCP [9] implies a deployment of a wide set of different products, and its delivery and deployment cannot be postponed or delayed. As stated in the previous research work [10], there are some weaknesses that must be tackled appropriately from the security point of view. In addition, other research works [11, 12] and [13] have been carried out for improving this platform.

This paper deals with how to increase security in a complex DevOps environment. A DevOps approach is described, and security mechanisms based on source code analysis are used. This is a relevant aspect because some of the most relevant security breaches are those related to malicious code within files [14].

This paper is structured as follows. Firstly, a background on DevOps and security mechanisms are provided. Secondly, we describe the use case and our DevOps architecture. Thirdly, we summarize the main outcomes of this paper. Finally, we provide a conclusion and we outline future works.

2 Background

2.1 DevOps and Security

As stated previously, security in DevOps has coined two terms: SecDevOps and DevSecOps. But they share the same idea behind: to incorporate security practices in DevOps environments [4]. Literature reflects different definitions, and there is no common definition for DevOps [15]. For example, SecDevOps is a paradigm for integrating the software development and operation processes considering security and compliance requirements [16]. Other authors define DevSecOps as a DevOps methodology for security [17]. No matter how we define the approach the result is to include security related practices, and to fix the potential issues as soon as possible. This is what it is commonly defined as moving security practices to the left [18]. Some authors are focused on reinforcing and adding security and risk management [19] within the DevOps umbrella.

Time and how to speed up the process for delivery is a cornerstone in DevOps approach [1]. Therefore, approaches must continuously consider the integration of security [20]. Automating is an essential part of DevOps [21], and it is a key enabler for continuous integration (CI) and continuous deployment (CD), but sometimes it might expose secret information inside configuration files [22], and even we need to face the vendor lock-in problem [23].

DevOps approaches adopts software engineering practices to tackle complexity [24], and DevOps tools shift security “left” [25]. Despite some recent studies related to the delayed issue effect (DIE) [26], it is widely accepted that security issues are being handled very late in the development process. Security teams are seen as hurdles or bottlenecks within organizations. However, DevOps approaches help us to discover security vulnerabilities, debug applications, and bottlenecks identification [27]. In this sense, Continuous Deployment (CD) [28] improves the resulting architecture, and the features and functionalities inside the resulting product. In fact, continuous software delivery [15] is part of the key aspects in DevOps.

2.2 Cybersecurity Standard Practices

Cybersecurity practices are key elements to be considered along the deployment of any product, and they must be explicitly handled. Often, organisations do not manage security threats in a uniform and standard way. They use common security practices from an ad-hoc point of view. All these activities must be institutionalized, and standards help us in this process. This is especially relevant while developing critical systems [29] where we need to manage goals, risks and evidences [30, 31]. Standard based frameworks such as [32] are enablers for small settings and they should be considered while adopting security in complex scenarios.

Several cybersecurity related frameworks are dealing with the activities required for adding or enhancing security within applications, especially in critical contexts. In this sense, the National Institute of Standards and Technology (NIST) published a Framework for Improving Critical Infrastructure Cybersecurity [33] which activities are identify, protect, detect, respond and recover. DevOps tools and approaches must be adapted to include these activities.

3 Use Case Description and DevOps Architecture

3.1 Use Case Description

As stated previously, the eHealth Digital Service Infrastructure (DSI) Operations [7] promoted by the European Commission is developing and deploying services for cross-border health data exchange under the Connecting Europe Facility (CEF). This platform connects different national health systems by using a software platform called OpenNCP [9]. Figure 1 represents the situation where a citizen (Mike) from one country (UK) travels to another country (Spain) and at certain point in time, during his stay abroad, he requires to visit a medical doctor. The grey boxes in Fig. 1 are representing the current OpenNCP source code. Each country must install and deploy an instance of OpenNCP, and they need to connect their own National Health Systems with this platform. Each OpenNCP instance is composed by 23 Maven projects and around 146k lines of code [10].

Fig. 1.
figure 1

Use case description

Full size image

The European Security in Health Data Exchange project (SHiELD - https://project-shield.eu/) is enhancing the current OpenNCP platform with a set of functionalities improving the security of this platform by introducing or enhancing tools such as consent manager, data sensitivity, data hiding and secure design patterns among other. Therefore, an OpenNCP instance deployment requires a deployment of a wide set of different products, and its delivery and deployment cannot be postponed or delayed.

3.2 DevOps Architecture

In order to speed up the delivery and deployment processes of the resulting enhanced platform we have defined a DevOps architecture where security mechanisms are included/injected and considered along the deployment pipeline. The pipeline is managed by Jenkins (Fig. 2).

Fig. 2.
figure 2

DevOps approach stages and supporting tools

Full size image

  • The Development stage envisages the availability of a development environment that provides tools to write and test code, as well as to support collaborative development (e.g., source control management, work-item management, collaboration, unit testing, project planning). In our case we are using Eclipse and Gradle tools.

  • The Integration stage focuses on compiling the code and performing the unit test and integration test reports. This stage also includes the security check related to source code. In fact, we are integrating Jenkins and SonarQube for the analysis of the source code as it is explained in Sect. 4.

  • The Staging stage is where the QA, user acceptance, and development/testing teams do the actual testing. All tools, OpenNCP, consent manager, data hiding tools and so forth are dockerized and this stage checks whether the installation is ready including user acceptance.

  • The Production Environments envisage tools and features for application environment management and provisioning such as: Chef, Docker, Puppet.

The SHiELD software components are developed by different technology partners of the consortium. Each technology provider will set up its own development environment. Also, a shared software repository will be set up for the integration of the components so that they can interoperate, communicate and work together in an integrated manner.

In SHiELD, DevOps philosophy and the corresponding approach is used and applied at two levels:

  • Internally for the development and the operation (deployment and validation into the use cases’ environments) of the software components forming the different ICT enablers in the ecosystem.

  • Externally for the users of the SHiELD solution, as the different components will be integrated into the SHiELD DevOps framework for the development and operation of the SHiELD ecosystem.

The different ICT enablers which are part of the SHiELD ecosystem are composed of several software components that will be implemented by different partners following different technologies. SHiELD will use a DevOps based approach able to fully support the management of these implementations and the planed releases. DevOps integrates development and operations into a single-minded entity with common goals: high-quality software, faster releases and improved users’ satisfaction.

DevOps also incorporates a number of agile principles, methods, and practices such as continuous delivery, continuous integration, and collaboration. The DevOps approach requires the set-up of a development and delivery pipeline that consists of the stages an application goes from development to production. It represents the environments that are envisioned in SHiELD covering the different development stages:

4 Adding Security into a DevOps Pipeline

As stated previously, each country requires its own instance of OpenNCP and the rest of tools, and we need to enhance security of this platform by analyzing the source code of the resulting platform. Therefore, the DevOps process must include a “security check” which is based on the NIST cybersecurity framework and it is included within the integration stage (Fig. 3).

Fig. 3.
figure 3

Security within DevOps pipeline

Full size image

This approach is supported by the use of a tool suite (Fig. 4) which help us to identify, protect, detect and respond appropriately.

Fig. 4.
figure 4

Adding security into DevOps approach

Full size image

From a methodological point of view, the resulting DevOps process is aligned with the activities stemming from NIST cybersecurity framework:

  • Identify (ID): security requirements are considered and added. A risk assessment is carried out

  • Protect (PR): specific actions are considered and implemented during the integration phase

  • Detect (DE): potential threats are detected during the integration phase.

  • Respond (RS): measures are including during the integration to each potential threat.

  • Recover (RC): previous source code versions are considered in case there is a security issue.

This “security check” is based on the analysis of the resulting source code. This analysis is, in its turn, based on the identification of source code security patterns. This is represented in Fig. 5 where three layers are represented going from a high abstraction layer on top (upper layer) to the lower level represented by Java source code (lower layer). Each instance contains OpenNCP, consent manager, data sensitivity, data hiding and security design patterns. The “security check” is supported with a balanced scored card (BSC) summarizing the security status of the projects included within the development workspace (Fig. 6).

Fig. 5.
figure 5

Security patterns approach

Full size image
Fig. 6.
figure 6

A security balanced scored card included in the DevOps approach

Full size image

For running an OpenNCP installation we need a valid certificate which must be validated. Figure 5 provides an overview of the CertificateValidator class. From a programming point of view, programmers used to find the shortest path to generate their code, and here (Fig. 5) there is an example of a bad practice while programming: an IP address is hard-coded. This code provides the expected functionalities, but the analysis reveals a potential issue. Our approach gathers the result of this analysis.

The “security check” is supported with a balanced scored card (BSC) summarizing the security status of the projects included within the development workspace (Fig. 5).

This BSC includes a functionality to navigate source code in order to identify the security patterns (Fig. 7).

Fig. 7.
figure 7

DevOps approach stages and supporting tools

Full size image

5 Conclusion

Security is a hot topic in several domains especially in critical, infrastructures such as the national health systems. Security practices, methods and tools enhance the resulting final products and services offered to citizens. As stated before, there is no consensus on how security measures must be included within the DevOps pipeline. In fact, from a terminology point of view, SecDevOps and DevSecOps have emerged for incorporating security practices within DevOps environments [4].

This paper provides a DevOps approach and it includes security measures at the integration phase. In addition, we provide a tool suite for managing security measures along the DevOps pipeline. This approach is aligned to the NIST cybersecurity framework. In fact, our DevOps approach is described, and security mechanisms based on source code analysis are used. This is an initial step for injecting security along the DevOps process, but there are other functionalities to be included within the rest of stages such as at the production environment where more tools are required for identifying, detecting and responding a threat. Our approach is just focused on the integration phase because some of the most relevant security breaches are those related to malicious code within files.

This approach has been developed for a real scenario related to the health sector. This scenario is framed under the umbrella of the eHealth Digital Service Infrastructure (DSI) Operations [7] from the European Commission. This initiative allows the use and the exchange of health records among European countries. Each country has a node and it is connected to each national health system. This network of nodes is enhanced with security tools such as data hiding tools, consent managers and so forth. and there are several tools to be deployed on each country node. Our approach contributes to the deployment of these nodes and security measures are added at the integration phase.

As future work, we are working on the identification of threats during the production phase. In addition, we recognize there are several cases where we need a dynamic analysis to check security issues. This aspect is postponed to a future research work.