DevSecOps

We won’t labour the point that DevOps meant development and operations working together. So we’d naturally assume that DevSecOps means the three concerns, Development Security and Operations working together. The problem for most DevOps teams that get DevSecOps is that the security part is a mystery to them.

So, our mission at Midnyte City is to make our customers successful in their own right. When we see this we understand our customers are not being setup for success. This is our three step guide to trying to bring success in a DevSecOps world.

One: Create and understand your security posture.

Security posture sounds intimidating, it’s actually a quite mundane set of questions. Quite literally what have you got to defend and how is it going to be a problem if its compromised? This is a details job. What do we have? By that we mean what services do you have? Let me tell you we spend a lot of time helping customers track down that one naughty service someone is paying for on their credit card. What data do you store? Which clients are high risk? What software do you make and ship? Those questions generally are answered with lists of services, data, software artefacts and so on. This is your map. It allows you to see what’s heavily protected and what’s poorly defended.

Two: pick a framework.

This depends on the organisational maturity, but certainly when there’s no Security team, there’s often no security framework. Frameworks allow you to take the security posture you generated in step one and apply a standard set of controls around it. We have a soft spot for CIS or NIST CSF.  Because they give a solid checklist of actions to take and they don’t require formal validation. They do however set you well for formal validation through ISO 27001 or SOC2. Once you’re mature enough for a formal certification (and note that it requires executive and probably board level support), there are tools that help you with that.  We’ve seen both Drata and Vanta play well for customers, but we’re also keen on using the simplest thing that will work. So for at least one client we just used Excel to get them to audit.

Three: start reporting.

In the sense that sunshine is the best disinfectant, you need to start explaining what’s wrong and how it needs to get fixed. Try and work board-level down. Have a risk register, then some kind of scorecard for how you perceive the security journey. Follow that up with a project plan and you’ve hit every step from the board to the team. Don’t forget to celebrate the wins on the way too. :)

We wish you all the best on your DevSecOps journey. And if you want a chat about how to do it well or merely learn from our mistakes, feel free to give us a call.