No.
Ask most developers what the Security team's favorite word is, and that's the answer you get! Security teams have historically been a punching bag for folks who "just want to get work done" because the nature of securing your systems and applications means locking things down... and that often means slowing progress.
The tune changes rapidly, however, once you've been through a breach... or a ransomware attack... or something equally insidious. According to this IBM report, the average cost of a security breach to a company is... $4.45 MILLION dollars.
That's more than a lot of startups' seed funding, y'all. We can't ignore Security and expect to stay in business. We absolutely must address these needs.
You put the Lime Security in the Coconut DevOps...
You might have guessed this from the title of the post, but the challenge before us is to ensure that all of our work to improve delivery happens "in bounds"... within the realm of our Security team's comfort. To achieve this, we absolutely need to bring Security along in our DevOps transformation! But it doesn't take long for the problems to start...
Constraints, man... they're... like, constraining
One of the first things we might try is inviting Security team personnel to join our project teams. Oh, they've always been involved before, but it was at a distance, wasn't it? They were some amorphous body "out there" someplace who gave us an approval (or, more likely, a list of things to fix before we could have approval, amirite???).
This rapidly becomes a problem because we typically expect to have 1 security specialist on staff for every 10 developers, and 1 developer on staff for every 10 ops personnel. The number of projects that a team of 110 Dev & Ops people can do is MUCH greater than the availability of that 1 security engineer!
So just get more... š
Have you seen salaries for Security Engineers? The reason the ratios look like they do is very likely constrained by the budget already. You're not going to be able to staff up a huge security team.
Processes can be hard to change
This is especially true if your processes are long-standing. DevOps introduces a lot of new thinking with completely different approaches to problems of scale and priority. Your security procedures are going to have to adapt to this new mode of thinking, and... that's hard. Just like it's hard to get people used to test-driven development or Scrum or continuous deployments, your security team is going to have to stop and think about what it means to keep things secure as you build software in this different mindset.
People are even harder to change than processes
You might have read all the best DevOps books.
You might have attended the conferences and TED talks.
You might have even written a book or two yourself on how to deliver software faster.
You might have all the certifications in the world that make you an official DevOp.
BUT
If you don't help your Security team get excited about these changes, YOU. WILL. FAIL.
Security teams don't like big, sweeping changes. Those are just accidents waiting to happen, there are too many moving parts and something gets overlooked and pretty soon you're staring at one of those huge breach expenses we talked about earlier. Security teams avoid big sweeping changes in favor of smaller, targeted change. Those leave more of the surrounding systems in a stable state, and they can focus on only what's changing to ensure that nothing slips through the cracks.
And here you come, with your Story Points and your Continuous Everythings and your GitHubs and Jenkinses, and you're expecting everything to just update.
You're triggering your Security team with every sentence.
So what's to be done about it all?
You might feel like you're backed into a corner now - how are we supposed implement these DevOps principles if Security's just getting triggered all the time?
Take a breath. These problems aren't insurmountable. They're not permanent. This just requires some empathy and understanding!
Start with Security in mind, EARLY. They can and absolutely will shut you down, so you need to have them join your coalition sooner rather than later!
Introduce your sweeping changes incrementally. Building a CI/CD pipeline? Add the tools in one at a time and let them help you understand how to secure them. Asking for process changes? One at a time. Let them feel some ownership of the DevOps transformation, rather than just being a transaction you carry out.
Earn their trust. This happens when you start to think like a "Junior Security Engineer" and handle some of the obvious things up front. Do they require multifactor auth for tools? Ensure that you've addressed that need before you bring it to them. Do they have a SIEM that collects log files from applications? Prepare for that integration by making sure you know how to send the logs from your tools. What are the project artifacts that they care about for audit purposes? How can you ensure they receive these in a fashion that makes it easy to manage (particularly if you're going to be increasing how often they receive them)? Showing them that you're thinking of them and how to make their lives better while you build your DevOps tooling and Delivery processes will earn their respect.
Wrapping up
Security gets a bad reputation for interfering with DevOps efforts... but generally their reputation is founded in our own inability to communicate effectively with them.
Being a DevOp is about learning to build coalitions; you don't know everything there is to know about software delivery, but you are surrounded by people who each have a piece of the puzzle to share. Making a good friend in the Security Team will make your life much easier as you try to promote change within your organization!
Next week we're going to take a quick break from DevOps to build something fun based on an audience suggestion. Tune in to learn how you can create a Quote of the Day phone app... without code!
Top comments (0)