DevOps and security often appear to be at odds – making sure you have security controls in place without slowing down innovation can be difficult to manage. And while there is definitely no one right way to integrate the two, here are some of the successes (and learnings) our security team has had as we’ve navigated the world of DevOps.
Despite hearing about concepts like continuous deployment, automated pipeline testing and configuration as code, we initially focused on how to apply our traditional security gates and manual policies into this new way of developing. We realized quickly in our DevOps journey that our “old” way of thinking about security in relation to our Software Development Lifecycle (SDLC) was not going to work. So, we had to rethink how we do our jobs in security. Here’s what we learned:
1. Focus on the problem you are trying to solve.
Security’s focus is often on risk — what is the risk you are concerned about in a particular situation? Instead of saying, “Your compliance document says you must have security testing at this phase of the SDLC,” talk with your teams about the risks the testing addresses and how (and when) to integrate testing.
2. Go in with an open mind and be willing to learn.
It’s OK if you don’t know the intricacies of DevOps. DevOps is new for security as well as developers. If you want to learn more, there are a myriad of meetups, webinars, courses and articles available — then apply that knowledge. If you don’t know how to code, there’s no better time to learn than now. If you have manual processes that can be automated, start playing around with how to do that. Automation will not only simplify some of your work, but also give you a better understanding of what you are working to secure for your developers.
3. Remember you are a risk management expert.
At the end of the day, the most important value you provide is thinking about risk to the confidentiality, integrity and availability (CIA) of information for your organization. Be the expert at anticipating and identifying what can go wrong, and then what happens and how you prevent, detect and/or respond when those things go wrong. Stay focused on the CIA of information and use that lens to guide all your conversations.
4. Make it easy to choose good security.
In today’s world where technology is at our fingertips, developers do not need the help of Security, IT or Operations to stand up a cloud account, set up a cloud repo and start pushing code. So, find ways to make the desired (secure) choice the easiest one for them. Make sure your security tools are compatible with pipelines or allow developers to self-serve their deployment testing, work with teams to define paved paths that don’t require additional scrutiny (aka that don’t slow developers down!), and share as much security knowledge with the teams as possible. If we truly believe that “security is everyone’s job,” then let’s actually give development the tools and resources they need to be successful.
5. Consider new ways to “trust but verify.”
You’ll likely need to build in a way to detect security vulnerabilities throughout development without stopping development. At Code42, we found that one of the best new tools in our security tool chest is our ongoing bug bounty program. Sure, we still do our annual penetration test and have an amazing internal team of pen testers at our disposal to test new features and functionality. But, with our bug bounty program, we have a way to get real-time feedback from vetted security researchers on potential vulnerabilities. Innovate fast, fix fast.
Code42’s Approach to Securing DevOps
To set out on our DevSecOps path, we ended up creating a security consulting team and have a security analyst embedded within each scrum team. Some scrums work with their security analyst a lot, some only a little – every team is different and that is OK. They know we are there and don’t have to go in search of “someone from security” when they have questions. This is especially useful in our current WFH world where you can’t just walk over to the security department and ask questions to whomever is there. Also, it’s allowed us to see where situations might be unnecessarily cumbersome (secrets management, container scanning) and work on solutioning instead of sweeping problems under the rug.
At the end of the day, it’s all about finding the right balance. As Code42’s security team, we have two very important goals – continue to deliver an awesome product and do it securely – and for our organization, those are not competing forces.
Hear more from Michelle in the recent webinar, “Managing Security in a DevOps World,” in partnership with Sumo Logic.