Ask three people what SecOps is and chances are you’ll get three different descriptions:
- It’s a team
- It’s a job title
- It’s a methodology
All of these definitions are, in fact, correct. Smaller companies may implement a SecOps methodology where everyone is a security ambassador, whereas larger companies with more personnel can assemble an entire team and designate specific SecOps job titles.
Our team defines SecOps as “automating runtime security in your infrastructure in a way that aligns security and operations tasks.” The goals are to reduce risk, stabilize infrastructure, and improve operational efficiency. With operations and security teams dealing with rapidly transforming infrastructure (which likely includes some combination of containers, microservices, or serverless architecture) and a severe resource shortage, it’s tough to know where to begin building a mutually beneficial security program that considers security and operations priorities and goals.
To help get you started, here are five ingredients that must be part of any successful SecOps implementation.
1. A Well-Thought-Out Strategy
Even the best intentions and ambitions for integrating security and operations can disintegrate if there isn’t an actionable strategy behind them. SecOps requires a cultural and organizational change, and change is difficult. That’s why you need an actionable plan to kickstart, run, and scale your SecOps program.
To begin, lay out the following components of your SecOps strategy:
- Goals (what you’re setting out to accomplish)
- Pro tip: Don’t overwhelm: Focus on two to four goals to start and make sure they are realistic, actionable, and attainable.
- Action items (what your team will execute on)
- Pro tip: Be very clear on the who, what, when, and how of your action items so they read like a playbook and can be implemented right away (or when the time is right).
- Budget and available resources (how you’ll make it happen)
- Pro tip: Often getting started with SecOps is just a matter of shifting around resources and integrating tools, so you may not even have to ask for additional budget, at least to start.
This plan will serve as a baseline for your entire SecOps program, so be sure to take the time to get it right. It should provide a clear definition of the desired outcomes, a straightforward path to get there, and a commitment from everyone involved to achieve it.
2. Designated Owners
Next, you have to get the right people involved. My recommendation is to take a top-down, bottom-up approach. In other words, you need to get C-levels and executive decision makers on board early. This means telling leadership exactly how SecOps will benefit the organization’s security posture — and its bottom line.
Then you need to get buy-in from your DevOps and security teams, since they will be the driving force behind this change. Both teams need to understand how SecOps will solve their pain points (much in the way Dev and Ops had to get on the same page back when the DevOps movement kicked off around 2009).
These conversations may not be easy to start, but in our experience, once someone opens up the discussion about SecOps and the opportunities it offers, the decision to go this route becomes much more straightforward.
According to our recent study, security and operations teams are still very siloed. In 38% of organizations, security is a completely separate team that’s only brought in on an “as-needed” basis. What’s more, 44% of developers aren’t trained to code securely, and 42% of operations teams admit they’re not trained in basic security practices. . In the past, I really didn’t know what my security counterparts did on a day-to-day basis, and they didn’t know what I did either. This in itself presented a significant learning curve as those teams began to integrate, but it was well worth the effort in the end.
To prepare your teams for SecOps, educate them about:
- The day in the life of a security pro (as told by someone in security)
- The day in the life of a DevOps pro (as told by someone in DevOps)
- Real SecOps use cases, such as testing for vulnerabilities in code
- A breakdown of the strategy and its action items so everyone understands the new process and, most importantly, how it will benefit them
4. A Process
In the early days of your SecOps implementation, chances are you’ll hit a few snags. That’s normal, but be sure you have a way of course-correcting and moving forward. The best way to do that is by implementing processes.
With people now working together who may not have worked together before, and with several tools required to get the job done, a process is needed to tie it all together.
For example, when Developer A ships code, you should know:
- What tool is scanning for vulnerabilities
- Who will review alerts from the vulnerability scan
- How that feedback will get back to Developer A to fix the code
Seems simple, but putting it on paper means fewer things slipping through the cracks. List out your most common workflows, document the end-to-end description of tasks, implement a process, iterate, rinse, and repeat. While it may sound like a lot of upfront work, the upsides are far greater, as these processes will:
- Save your team a lot of hassle later on by having to do this just once
- Reduce or eliminate errors and tasks falling through the cracks
- Keep everyone running on the same playbook at all times — even during a security event
5. Success Metrics and Ongoing Improvement
After putting a lot of work into your SecOps plan, you should be able to show that it’s actually working! Chances are your executive team will be asking, since they bought into it, and you’ll need to prove that the budget and resource allocation you requested is being well-spent.
Some of the most important questions you should be able to answer after implementing SecOps include:
- Could you deploy a patch today if you had to?
- How frequently are you able to identify a needed security patch?
- How quickly would you be alerted if there was a security-related incident such as an invalid login attempt?
You should also have some metrics or KPIs to show quantitative improvements from SecOps. What these numbers look like will depend on your organization’s industry, threats, data, and more. For example, a healthcare company will be more concerned about protecting patient data from a breach, whereas an ecommerce company will be focused on ensuring the security of credit card data both in transit and at rest. Whatever your goals, come up with a list of meaningful metrics and KPIs that will show how SecOps is moving the ball forward.
Most importantly, make these metrics realistic. Security will never be perfect, so strive for what’s achievable, understand there will be some bumps along the way, and always seek to improve, letting the numbers guide you as you progress.
A SecOps Roadmap
To help you address the challenges that go along with each of these five ingredients and to prepare you with even more guidance as you begin to implement SecOps, Threat Stack created the SecOps Playbook For Cloud Infrastructure: Defining SecOps and Goals for Your Security & Ops Team.
The playbook maps out several of the challenges and related goals associated with building a SecOps program, for organizations at any point on the spectrum of heterogeneous infrastructure (ranging from virtual server workloads, to containers, to container orchestration, to serverless infrastructure). Ideally, the advice will help your team establish a baseline of your security practices, so you can begin continuously improving toward more defined, repeatable processes — and ultimately automated processes.