Companies have had in place both IT operations teams and IT security teams, for decades. Yet when it comes to the way that each team performed its responsibilities, the tools it used and the cultural priorities it embraced, operations and security were traditionally quite isolated from each other.
This is, in part, why SecOps – meaning a strategy that achieves seamless collaboration between operations and security – is so difficult to achieve. It’s only by understanding the differences between operations and security that organizations can bridge the two effectively and implement SecOps.
Security People vs. Operations People
The differences between security and operations start with the teams that oversee each of these domains. Typically, the people who end up performing each type of work are quite different.
I don’t mean to say that they are different as individuals; demographically speaking, I’m unaware of any relevant trends separating security teams from operations teams. But when it comes to training and career trajectories, there are clear differences.
The typical security engineer received a degree in security (security jobs are not among those that you can easily obtain without a formal degree, unlike many other tech positions), and has spent his or her entire career in a security role. Likewise, someone who works in IT operations most likely received training in that specific field (whether it was through a college degree program in IT, or another form of training). And someone who works in IT operations is likely to spend his or her entire career in that field.
You do, of course, occasionally see developers or IT engineers who move into security positions. But that type of switch is rare, because security expertise and IT operations expertise were traditionally seen as distinct realms.
SecOps requires thinking beyond these disciplinary divides, and recognizing the many ways that IT and security skill sets overlap – which they indeed do. As a security engineer, you can’t secure an application very effectively if you don’t understand how applications are staged or deployed. And an IT engineer can’t keep applications up and running reliably without being aware of security issues that could impact uptime or performance.
So, operations and security people actually have a lot in common. The problem is simply that we haven’t conventionally thought of them in this way, or done a good job of structuring the IT industry in a manner that lets these two groups collaborate. SecOps is all about changing that.
Security Tools vs. Operations Tools
The tool sets that security teams rely on have also traditionally not had much in common or been well integrated with those of IT operations.
A security team’s tools typically consist of code scanning tools that can identify vulnerabilities within applications, as well as SIEMs or similar monitoring platforms that collect data from application environments or networks, and analyze it for signs of a breach.
IT operations teams rely on sets of tools that are broader and address more components of the application lifecycle. They use application testing and staging tools to help automate the processes required to ensure that new builds behave as required and are ready for deployment. They use release automation suites to push new applications into production quickly and automatically. They use Infrastructure-as-Code tools to manage the provisioning of the infrastructure that hosts applications. They use monitoring tools to help identify and respond to application performance or availability issues.
Doing SecOps effectively requires bridging the gaps between these two types of tool sets. One way to do this is to extend security tools into areas that they don’t traditionally cover, like auditing the Infrastructure-as-Code files that define how application environments and infrastructure are configured. Scanning for vulnerabilities in configurations wasn’t historically a major focus for security teams, but it is one example of how security engineers can extend their work into the realm of operations.
Along similar lines, the monitoring systems that are used by operations to manage application performance and reliability can be integrated with those used by security teams to manage security. These platforms rely on the same principles and methodologies – collecting data and analyzing it for anomalies that could signal problems – and there is no reason why security and operations teams need to have disparate tools for this process. Integrating security monitoring and performance monitoring under a unified platform streamlines manageability and promotes the collaboration that is at the heart of SecOps.
Security Culture vs. Operations Culture
In terms of culture, too, there are stark differences between the way that security and operations teams tend to think (at least in general).
Security engineers tend to be risk-averse and conservative in the way they approach new processes or changes. They know that the more applications or infrastructure you have running, the more rapidly you update it and the more variables you introduce, the greater the risk you face of a security problem.
In contrast, modern IT operations teams are all about scalability and rapid change. They prioritize processes that allow them to deploy and manage 1000 servers just as easily as they can manage 10. They are not worried about constant changes – like servers turning on and off or container instances being stopped and started – as long as they have the automation tools in place to handle them.
To do SecOps, both groups need to focus on finding a common cultural ground. Security teams should perhaps embrace automation more than they traditionally have, and understand that constant change and innovation are not bad things as long as you have automation in place to manage them.
At the same time, IT operations teams should think more carefully about the security implications of the work they do. From a security perspective, having 1000 servers running is different from 10; 1000 servers means a much greater attack surface that needs to be managed. Thus, scaling up should happen only if the proper security safeguards are in place.
Conclusion: Bridging Security and Operations with SecOps
Historically, security and operations teams have occupied decidedly disparate parts of the IT organization. But once you unpack what each team actually does, you realize that they are not so different after all. They share the same priorities, have overlapping types of expertise, and can use the same types of tools; if only they are given the opportunity.
SecOps is all about giving them that opportunity by breaking down the structural barriers that have traditionally separated security and operations teams from each other. By providing a common set of tools and methodologies for integrating security and operations processes, SecOps bridges the gap, allowing organizations to streamline their IT operations and security operations all at the same time.
