Do you love SecOps in theory, but just can’t seem to make it work in practice? Or, maybe you’ve already implemented a security operations strategy to some degree within your organization, but struggle to make IT operations and security jive as seamlessly as you would like?

Either way, there’s a good chance that your troubles stem from one or more of the common barriers to SecOps strategies. This article explains why businesses often fail at implementing SecOps successfully and how they can work around the roadblocks.

What Is SecOps?

SecOps refers to collaboration between security teams and IT operations teams. The goal of SecOps is to ensure that security is a priority for IT teams as they manage environments.

In a world where every year sets new records for cybersecurity attacks, SecOps has become a pillar of many businesses’ efforts to stay a step ahead of threat actors. By integrating security into core IT operations processes rather than treating security as a separate discipline, SecOps enables organizations to manage threats more effectively and with fewer resources.

SecOps Strategy Challenges

At least, that’s what happens when you do SecOps well. That can be easier said than done due to the following strategic challenges.

1. Organizational Structure

It’s easy to talk about integrating security into IT operations. But figuring out what that means from an organizational perspective is much harder.

Should you try to embed security engineers on your IT operations team, or vice versa? Do you somehow try to combine the two teams into a single team? Do you just tell each team to collaborate with the other, and then hope they do? These are all difficult questions to answer given that SecOps doesn’t prescribe a specific approach to team management.

Perhaps the best solution is to focus on ensuring that security and IT operations teams have the tools they need to communicate and work with each other regardless of how the teams are structured or who answers to whom. In other words, don’t let yourself get hung up on the organizational structure. There’s no right or wrong way to organize your teams, as long as they have the tools they need to communicate.

2. Forgetting the Developers

SecOps focuses on collaboration between security teams and IT operations teams. It leaves developers out of the picture, at least officially.

That’s a problem, of course, because in many cases developers will ideally play a role in identifying and addressing security risks. It’s hard to make sure your environments are as secure as possible when the people writing the application code aren’t aware of the threats the business faces or the security resources it has at its disposal.

You could respond to this conundrum by spewing more buzzwords (namely, DevSecOps). But here again, the real solution is to make sure that the security tooling you give all of your stakeholders — whether they are developers, IT engineers, security engineers, or anyone else — is accessible to and usable by them. It doesn’t really matter how you officially define developers’ role in SecOps, as long as the developers are able to play a role, practically speaking.

3. Lack of Automation

Everyone likes to talk about automation in SecOps. But when you look at how many organizations attempt to implement SecOps automation, you realize that it’s typically limited to things like automated security monitoring and alerting.

That stuff is great, but it doesn’t lead to full-scale automation across your entire SecOps workflow. It doesn’t ensure that security teams and IT operations teams can automate the entire process of finding, understanding, and remediating security risks.

To do that, you need automation tooling that goes further than monitoring and alerting. You need to make it possible for all SecOps stakeholders to define security rules within the systems they manage, then enforce those rules automatically. Instead of merely receiving alerts when a SIEM or SOAR detects a threat, the teams should be able to automate risk management in all respects.

4. Too Much Identifiability, Too Little Actionability

It’s one thing to identify security issues within IT operations. It’s another to solve them in an actionable way.

Many SecOps initiatives get hung up on the former process — finding risks — and fail to make the leap toward solving them. As a result, the business ends up being great at figuring out all the things that the IT team is doing wrong from a security perspective. But that merely leads to finger-pointing rather than actionable improvement.

One way to address this issue is to make sure that IT operations teams can collaborate on security remediation rather than just security risk identification. Rather than sharing SIEM and SOAR alerts with IT, for instance, have the IT team participate in security incident response.

Likewise, the IT team should not just tell the security team what it’s doing, but should ask security engineers to play a hand in IT processes. Security engineers could help write IaC files, for instance, or help design a new application deployment.

When you approach SecOps from an action-focused perspective, it becomes much easier for security specialists to improve IT operations in ways that lead to fundamental reductions in risks, as opposed to merely detecting security problems as they arise.

5. Lack of SecOps Skills

A final key challenge to SecOps is a shortage of engineers who have deep expertise in both IT and cybersecurity. This has been a longstanding issue, and it’s only growing worse as businesses face ever-greater pressure to secure their IT assets.

In the long run, the solution is to work at the societal level to train more engineers in SecOps. But that will take years — and even when more of those specialists exist, they will be expensive.

A more practical approach for the here and now is to deploy security tooling that anyone can use without requiring specialized cybersecurity expertise. No-code security automation platforms like Torq go a long way toward enabling your existing team to do SecOps instead of waiting years for the cybersecurity skills shortage to fix itself.

Conclusion

You can talk about SecOps all day. But until you overcome the key barriers and challenges in implementing SecOps — like a lack of complete automation and a focus on risk identification at the expense of risk remediation — all you’ll get is talk. To make SecOps work in practice, you need real-world, actionable security automation tools that let everyone on your various teams support SecOps initiatives.