DevOps, DevSecOps, and Security

Where are we heading?

Conclusion: For many organisations – particularly organisations working with safety critical systems – the traditional DevOps practices have always needed to be adapted to much higher standards of security. Risk appetite differs between organisations. Unfortunately, as has been demonstrated for decades with software configuration management and DevOps tooling and development methods, people often almost religiously advocate for the systems they are most familiar with, rather than for systems that match the context of the organisation.

Observations

As someone who has always had a holistic view of all things IT related, I decided to broaden my horizons this year and obtain a Certified Information Systems Security Professional (CISSP) certification. For those who do not know, the CISSP is a vendor neutral, highly valued qualification in the security field, provided by ISC2. The CISSP has been described by many as being “10 miles wide and two inches deep” across eight Information Systems Security domains. I would concur with this, however, it does do a deeper dive into a few areas.

Whilst this has given me the opportunity to formalise my experience and get a ticket, so to speak, it leaves me contemplating where DevOps and DevSecOps are heading. I have heard rumblings that DevOps or DevSecOps has the security field in its sights next. So let’s explore this further, and see if we can start getting our head around this.

To talk effectively to this topic, we must first get our head around the background.

The origin of DevOps practices

It may come as a surprise to some that many methods which are currently attributed to the Agile Manifesto and DevOps were known of and being successfully practiced last century. Continuous Integration is one of many that was being successfully practiced by experienced software configuration managers.

I was quite sceptical about the term DevOps as it started to take hold. I wasn’t sceptical of its success – that was obvious, I was sceptical of the important considerations which could be, and were left behind as many SCM teams rebranded as DevOps. Some examples were Automated Lifecycle Management, Requirements Management and Product Line Engineering.

Many SCM teams were not really doing SCM at the time – they were focussing on tooling, automated builds, deployment, and a bit of environment management. By the time DevOps started to take hold, I was already aware that enabling development teams successfully required close engagement with many more areas than just development and operations. Whilst for the newly initiated, DevOps was a great start, I was already working heavily on other areas with which development and operations groups interfaced and were dependent upon.

In a nutshell, DevOps is about ensuring that software change does not equate to system outage. Many of the technical problems tackled by the DevOps movement have a long history, and have been addressed successfully by Software Product Line Engineering methodologies, which are concerned with the economic creation, maintenance, and operation of families of hundreds and thousands of software intensive systems.

A major accelerant for DevOps was the availability of Cloud computing. Many organisations seized the opportunity to simplify their internal infrastructure and minimise the complexities that come from hosting your own infrastructure. From a security perspective, as some companies are able to move to being all cloud based, it also provides options not previously easily available, particularly around areas like multi-site redundancy, and disaster recovery. After all, the site risks associated with having a hot or cold site maintained by your organisation largely evaporate when it is just a matter of making changes in the cloud.

I must say, I was also not impressed by seeing the security stance of some of the early DevOps practitioners. One DevOps group at a large financial institution, for example, simply chose to ignore and undermine security efforts to support separation of duties, for example. Their approach was very much a case of thinking if they ignore it, it might simply go away. Of course, it never was going to go away as the need for resilience and risk reduction is extremely well founded.

Security

From the security perspective, there has been an intense evolution in the maturity of the practice. IT security has evolved for many organisations from just being a part of the systems administrators' job to encompass a wide variety of aspects – everything from facilities management, infrastructure and networking, security operations, systems and software testing, and of course, asset and risk management. The increased recognition of threats to organisational security is being clearly seen as more businesses seek executive level roles and support having security groups which are not buried down in the bottom of the organisational hierarchy, but have the lines right up to the CEO.

Security teams have had their share of difficulties. I am sure we all have stories of overly risk averse security engagements where the focus has been much more on confidentiality than availability for critical systems. An example that comes to mind here is where a security group prevented the synchronisation of two software development environments (Jira repositories) which were only ever internally hosted within the intranet.

It seems that, at least generally speaking, and depending on the groups themselves, many DevOps groups are focussed on availability first, integrity second and confidentiality third – and have taken a bottom up approach. Meanwhile, many Security groups are focussed on confidentiality first, integrity second, and availability third – they have taken a top down approach. Both the priorities and approaches differ in some significant ways.

DevSecOps

I see DevSecOps as being an intermediary bridge between the two groups. Software is taking over the world – Software Defined Networking is a good example. The DevSecOps manifesto introduces some methods which will be new to many professionals both from the DevOps and the Security communities. Conversely, there are still many facets of the security discipline about which software oriented people need to learn more. Designing and implementing a business continuity and disaster recovery plan, for example, involves much more than providing the software for the business to continue operating.

For many organisations – particularly organisations working with safety critical systems – the traditional DevOps practices have always needed to be adapted to much higher standards of security. Risk appetite differs significantly between organisations. If you make devices performing someone’s breathing for them, there is simply no room for failures in production at all.

With all that said, provided people work together collaboratively and with a non-tribal focus, the challenges which will arise will be overcome. Unfortunately, as has been demonstrated for decades with Software Configuration Management and DevOps tooling and development methods, people are often almost religiously advocating for the systems they are most familiar with, rather than for systems that match the context of the organisation.

Next Steps

1. For DevOps professionals, learning more about IT security and the CISSP is a good start. Likewise, for security professionals, this is a good time to learn more about software development.
2. The security domain of the CISSP is being adapted early next year, and I am looking forward to seeing the changes that get introduced. It is only when we have more people branching out between the different domains, that the understanding of each discipline’s strengths and opportunities for improvement will surface. From there, I think, the community of risk management and security professionals will start to develop a clearer picture.
3. S23M's new Human Factors service can assist organisations with the with transdisciplinary creative collaboration needed to bridge the gaps, and integrate the unique tacit knowledge within your organisation with practices emerging from the disciplines of DevOps, DevSecOps, and Security.

Jack Sussmilch, Senior Advisor
December 2020

References

1. A new service to address the implications of human limits and lack of psychological safety on collaboration, security and risk exposure: Human Factors
2. The DevSecOps manifesto
3. A methodology for product line engineering and life cycle management: Model-oriented domain analysis and engineering (MODA + MODE)
4. Introduction to product line engineering: From project to product mindset and onwards to product platform architectures
5. Carnegie Mellon Software Engineering Institute: Software product lines curriculum