DevSecOps — what does that even mean these days? The truth is, it means a lot of different things to a lot of different people. Like its counterpart DevOps, which means to bridge the gap between development and operations, I believe DevSecOps means to bridge the gap between development, security, and operations.
The focus of this post will be to bridge the human gap between security, development, and the users. We will start this process by talking about a few of the common interactions developers usually have with security teams and how they can be made easier and more productive. In a future post, we will lay out some tools that will also greatly aid in this process.
For perspective, my background is in Operations, Support and Infrastructure Engineering. I have since transitioned over to Infrastructure Security, with the primary responsibility of helping teams build security from the outset rather than a tacked on measure.
In today’s Infrastructure Engineering circles, we have a concept of Infrastructure As Code (IAC). The basic idea of this is that you codify not only the products, but also the pipelines used to build them, and the server architecture used to run and manage them. This has brought much needed discipline to infrastructure and leads to the first item on our list.
Infrastructure Engineering == Software Engineering
It may not be Java or .Net, but working with Chef, Puppet, and Terraform is most certainly worthy of being called software development and even Software Engineering. The code certainly needs tests, and it should be stored in a revision control system and documentation consummate with its complexity needs to be written.
The testing and documentation will go a long way towards showing your security team that your infrastructure is solid, has the proper posture and takes threats seriously. Storing the code in a repository will provide the audit capabilities that keeps everyone honest. It also provides the benefit of increasing productivity by providing new workflows for development teams.
The First Day of School
Many times when beginning the software development process, the first step(s) include requirements gathering. There are several points that could be made here that will be incredibly helpful and will make the security and developer interactions flow better. The most important thing to do is to build a rapport with the users and with security. It is much easier to work together if you can share a common goal.
The users have to get something done, the developers need to build something useful for them, and security needs to ensure the company and users are safe. The common thread here is getting the task accomplished in a safe and efficient manner. From a security perspective I would rather not say no to a project that a team is working on, and I am sure most security people would agree. I can’t say yes to what I don’t understand though. Try to develop some shared experiences, find some common ground that a relationship can be built from, and have some empathy.
Most security professionals are aware that security may not be the first priority for a development team and want to help. The user just wants their widget and most likely has no clue how to build it and what the development process entails. I have found the best way to improve the relationship between users and developers is to involve the users as much as possible. Explain to the users why the security controls are necessary, and you empower them to be invested in the security process.
What is …
Just talking with the users is not enough, you need to ask questions. I can’t tell you what questions to ask as that is very subjective. I can say that in my experience asking the right questions was the difference between a successful design that would not draw red flags and a project that would end up with serious refactoring at a late stage.
The classic example is asking what ports need to be opened on a firewall. This is a fairly simple question, but don’t forget the user may not understand networking or security. For example, you may open port 456 on the firewall for tcp connections, but the user is actually using udp.
Driven by Design
The collaboration doesn’t end with asking questions. Once you have finished with the questions and created a design, you should engage security and have them help with a design review at this point before any code has been written. Engaging early will give security and the development teams plenty of time to work through any sticky points and save the project from costly late-stage redesigns.
After this is complete, it is time to take the design back to the users and review it with them as well. This will avoid any other late-stage issues where users were under a different assumption than the development team. The key here goes back to building a rapport. These meetings, while time-consuming and certainly not what everyone wants to be doing, are critical to a successful project.
Web Scale…Not so much
Most of developers don’t need to roll their own major tools. Many companies, especially those operating at an exceptionally large scale, have written and open sourced their toolkits. More importantly they have built a community around those tools and continue to support them. Whenever possible these or other open source solutions that have wide exposure should be used. If the use case or tool is common enough, security may have already vetted it and you can just go on your merry way.
Trying to roll your own homegrown monitoring solution, which seems to be a common thing these days, is generally not necessary and will only lead to long meetings with security and users when your glorified command and control server is rooted due to a bug in some functionality. The message is simple, please don’t roll your own tools unless you really need to. Your users will thank you, future maintainers will thank you, and security will certainly thank you.
These are but a few thoughts to get you pointed in the right direction. Later I can talk about several software tools that can be used to make everyone’s life a lot easier and help hold the momentum through the various design iterations.
Originally published at www.devseccon.com on November 7, 2018.
