In academia, government, and industry, DevOps has become a standard, straightforward option for streamlining efforts and increasing comprehensive participation by all stakeholders in the software development lifecycle (SDLC). In highly regulated environments (HREs) within these three sectors, however, applying DevOps can prove challenging. HREs are mandated by policies for various reasons, the most often being general security and protection of intellectual property thus making the sharing and open access principles of DevOps that much harder to apply. In this blog post series DevOps and HREs, which is based on a published paper, we will discuss the process, challenges, approaches, and lessons learned in implementing DevOps in the software development lifecycle in HREs. In this first post, we will explore challenges (and goals) to implementing DevOps in HREs. The majority of what you will read in the series stems from our experiences in performing these tasks. In addition to presenting challenges, this post gives an overview of what an HRE is, what you should expect to find in these environments, and what DevOps implementation obstacles may be present.

To begin, we will use the following definition of an HRE:

a physical or digital environment characterized by: air-gapped physical spaces, air-gapped computer systems, heighten access control, segregation of duties, inability to discuss certain topics outside of specific physical spaces, and an inability to transport certain artifacts off premise.

As you can see from our definition, an HRE is focused on control of data, personnel, access, and physical spaces. General security practices are heightened, and many areas and systems are siloed from each other and from everything external to the HRE. We want to clarify that the word regulated focuses on heightened security, and an organization set up as an HRE functions under imposed security policies.

The goal of this series is to demystify the process of implementing DevOps in HREs. There are several factors and challenges unique to an HRE that can make full implementation of traditional DevOps harder than other entities that function in an open environment. To achieve this goal, we will guide the reader in a step-by-step process of understanding, engaging, analyzing and improving an HRE's software development process. Along the way we will describe how to overcome HRE obstacles to DevOps implementation, determine an HRE's DevOps posture and perform ­a full DevOps assessment. We welcome suggestions, comments, feedback, and requests, so please feel free to reach out to us!

In the United States, some examples of regulators are: Federal Trade Commission, Consumer Product Safety Commission, Food and Drug Administration, and the Federal Aviation Administration amongst others­. HREs are most prominent in government, military, and industry. Within government and military, the primary purpose for establishing an HRE is to protect classified information and personally identifiable information (PII). In industry, the HRE is used to protect primarily proprietary information and PII.

An HRE is usually set up as a standalone structure or a subsection of a larger structure, a set of offices in one floor of a building, for example, with entry and exit access highly controlled and vetted. All access to physical and digital objects is carefully vetted with the goal of being able to know which individuals are accessing the system and their location at all times. When multiple groups require an HRE, these structures can be further siloed into subsections of entire floors or multiple HREs on a single floor.

In an HRE, fundamental DevOps principles such as open communication, cross-collaboration, and continuous end user-feedback are hard to achieve. To implement DevOps, you must be able to identify what aspects of a specific HRE will make these principles more difficult and become obstacles to implementation. Below is a list of the obstacles you are most likely to find in an HRE:

1. Air-gapped environments
2. Slow project approval
3. Slow hardware and software acquisition
4. Lack of software version control
5. Absence of centralized document repository
6. Lack of communication with stakeholders
7. Loss of project work time
8. Partial or absent production environment access
9. New requirements late in the software development life cycle (SDLC)
10. Lack of centralized software installation
11. High attrition of contract personnel
12. Slow IT request fulfillments

In addition to those listed above, each HRE can present its own specific set of obstacles. Within one organization there can be several software development groups, and each group may function within its own HRE and under its own security policies. The obstacles listed above may therefore appear multiple times for the same organization. As a result, the same handling approach may not apply across the organization and will instead be determined by the manner in which the obstacle is present within each group's own HRE.

The following are overall goals to keep in mind when implementing DevOps in an HRE:

1. Assess the DevOps posture before and after implementation.
2. Tell the organization, when needed, they need critical improvements in order to consider DevOps.
3. Identify as many obstacles to DevOps as possible.
4. Make the organization aware that DevOps is not the solution to all the problems.
5. The ultimate goal is to improve the SDLC of a software development group within in an HRE.
6. The improvement will likely use both DevOps and non-DevOps approaches.

Changes in culture will be the hardest to modify. Moreover, DevOps will not be the answer to all the obstacles found in an SDLC. Especially within an HRE, recommendations to remove obstacles will often be achieved through a combination of DevOps and non-DevOps approaches. This combination will result in a process that we call HRE-DevOps, an improved SDLC that is customized and tailored for each development group.

Arriving at a full DevOps implementation in an HRE may require multiple rounds of assessments and recommendations, where each round advances a few steps to the desired state of an SDLC. It is also critical to assess the DevOps current posture of a development group's SDLC and discuss with the organization what needs to be done to achieve their desired SDLC. Changing the culture of an HRE is the biggest obstacle one will likely encounter when implementing new processes, such as those in DevOps. All the tools and processes can be in place, if personnel struggle or delay altering the way they perform tasks, it will be a long and hard road to finalizing change. In an HRE, culture shifts can be much more harder due to daily activities being carried out by following imposed policies, and thus personnel must be told of policy changes they need to adhere to.

Looking Ahead

In this post, we set the groundwork for carrying out a DevOps assessment in an HRE. Several obstacles common to HREs should be expected and overcoming them may be different for each organization. In the next post in this series, we will examine the task of setting expectation, an important first step in implementing DevOps in an HRE.

Additional Resources:

Read the paper from which this this series of blog posts is excerpted, Implementing DevOps Practices in Highly Regulated Environments, which was presented at the 2018 International Workshop on Secure Software Engineering in DevOps and Agile Development.

Read other posts in the DevOps blog.

Listen to the SEI Podcast Roundtable, How Risk Management Fits into Agile and DevOps in Government.