At Threat Stack, we’ve been a SecOps-oriented team from day one. This means our developers, operations, and security practitioners all work together to make sure that every line of code we release is secure. It’s how we eat our own dogfood.
But we know that getting started with SecOps isn’t always easy, especially since little has been said so far about the practicalities of how security and operations can come together to enable SecOps.
Pete Cheslock, our Senior Director of Operations and Support, has been on the frontlines of SecOps for much of his career, so we decided to spend some time quizzing him about the practical aspects of getting a SecOps program started. In this Q&A, Pete explains:
- How he’s seen the SecOps movement evolve
- How companies can overcome the main challenges to SecOps implementation
- Where to begin with SecOps
Q: How are you seeing companies implement (or not implement) SecOps today?
A: These days, SecOps is being handled in two ways.
First, there are companies that embrace DevOps wholeheartedly and now utilize a shared set of tools to improve the velocity of their code deployment. But because they have been so focused on DevOps, security teams have to play catch up — trying to test, audit, and assess code as fast as they can (and after it’s already been released).
Other companies are working to integrate security and DevOps much earlier on in the development cycle. One way to do this is to leverage open source tools to perform security-related tasks, such as testing for systems vulnerabilities before code is shipped to production. Configuration Management (CM) tools like Chef, Puppet, and Ansible have made the integration of operations and security possible.
I don’t think we’re at a point yet where there is widespread and effective implementation of SecOps, but we’re getting close. What we’re seeing more and more of is a “rugged DevOps” approach, whereby companies throw security tools into the same pipeline that developers and operations folks are using. It’s not a formalized process, but it’s a great start, and we love to see scrappy teams getting it done however they can.
Q: What are the key issues SecOps can solve? What can’t it solve?
A: The main benefit SecOps provides is helping companies deliver software more efficiently and securely. With a solid SecOps process in place, code can be delivered bug-free, well-tested, and hardened. In this way, security becomes an inherent outcome of DevOps.
SecOps also helps to solve for human error in the development and testing process. Human error could easily be the biggest culprit of cloud security attacks, whether it’s a bug in the code that attackers can exploit, or a lack of integrity in the testing process. With SecOps, companies can automate security into the development process, significantly cutting down on errors, breaches, and, of course, clean-up costs.
SecOps isn’t a silver bullet though. To be effective, it requires company-wide buy in, the right tools and processes, and a commitment to the organizational goals you set out to achieve.
Q: What are the biggest challenges of adding a DevOps security process?
A: Quite frankly, there just isn’t a lot of information out there about to actually implement SecOps, so companies don’t even know where to begin. At Threat Stack, we noticed this huge gap in SecOps education, which is why we just released The SecOps Playbook: What I’ve Learned About Integrating Security Into DevOps.
At the most basic level, though, SecOps requires an organizational change. It’s not a technical challenge; it’s a people challenge. And, as you can imagine, organizational change can be difficult.
In my experience, security and operations teams don’t even speak the same language, which can cause the entire initiative to fail before it gets started. To make sure this doesn’t happen, it’s important to find someone who can lead the charge by educating teams about the tools they can use together and open up the channels of communication between both parties. When you can speak the same language, you can take part in the same dialogue — and this is what enables SecOps.
Q: Who is the appropriate person to lead the SecOps charge?
A: I’ve seen release engineers take on this responsibility effectively, since they’re often adept at pairing people with complementary skillsets to learn from each other. Having a security practitioner work one-on-one with this member of the DevOps team member is a great way to build rapport while each teaches the other their processes, practices, and tools of the trade.
Q: What advice do you have for companies that are starting to make the transition to SecOps?
A: Start small. While that sounds like obvious advice, it’s helpful for teams who either don’t have internal security expertise or who need to take small steps in order to bring about cultural change. In two recent posts (Cloud Security: Where to Get Started, Part 1 and Part 2), I explain how companies can implement security early on in the development lifecycle by tackling low-hanging security tasks and building from there.
In practice, I say start by identifying something small that you want to improve, such as knowing the most common security threats to your industry. Then, day by day, aim to learn a little more so that over time, you’re always making progress. More often than not, SecOps fails when teams try to boil the ocean by attempting too much at once. This leads to analysis paralysis, spreading yourself too thin, and not getting much of anything done.
Q: Do specific types of companies need SecOps more than others?
A: SecOps can really benefit every type of company. Pretty much all types of companies (plus private citizens) are targets for security breaches today, even if they don’t have highly valuable data. Attackers often look to compromise unassuming company systems from which they can launch a greater attack while remaining disguised. As defenders, we need to be prepared with hardened systems and quick response processes — and that’s exactly what SecOps enables.
SecOps can also be leveraged as a way to accelerate the meeting of compliance requirements. For companies that must follow a number of set rules in highly regulated industries, SecOps can automate many of their requirements, enabling them to check off a lot of boxes pretty easily.
Q: Can you measure the success of a SecOps implementation?
A: This is a tricky one. People have been trying to quantify the success of security and DevOps for years. Is it the number of breaches or hacks prevented that demonstrates success? Or is it the number of secure deploys per day? It depends a lot on your circumstances and goals as an organization. Often, results-driven companies focus on what amount to little more than vanity metrics.
Rather than getting bogged down by numbers, start by identifying what’s most important to your business (e.g., the ability to deploy patches fast), and begin tracking those metrics before you start making changes. Then, as you begin to implement security into DevOps, your metrics should tell the story. For example, you may notice a shortened time-to-response as SecOps enables patches to be deployed in half the amount of time. The metrics you choose will vary from those used by the next company, so look inward at what matters most to your organization and build from there.
Moving Into a SecOps World
The SecOps conversation doesn’t end here. Our new eBook, The SecOps Playbook: What I’ve Learned About Integrating Security Into DevOps, provides the practical guidance companies have been looking for when it comes to actually implementing SecOps. Check it out, and let us know what you think.