The term “security operations” is often interpreted to be synonymous with a security operations center (SOC). In fact, a web search on security operations results mostly in links to SOC content. But that’s a narrow view. How you view security operations will make a difference in how fast your organization can deliver software and mitigate breach damage. A bigger-picture view that includes IT operations is necessary to address the agile threat environment that exists today.
The divide between security and operations
Let’s begin with a simple acknowledgement that conflict exists between most IT security and operations teams. Whether it simmers beneath the surface of thinly-veiled polite tolerance or involves the flipping of furniture, or something in-between, the difference in priorities for each team is bound to create tension. While IT security ultimately is concerned with the confidentiality, integrity and availability of IT services and information, IT operations focuses more on performance, efficiency and availability.
We might be tempted to find common ground over availability, but even this identical term is viewed through different lenses. The security perspective focuses on countering intentional sabotage, while operations seeks to mitigate accidental service disruption. The result of this divide is overlapping organizations and tools in many organizations, with conflict arising over the boundaries between them.
The three approaches to security operations
While the divide is almost universal, security must have an avenue to affect change in the infrastructure and applications of the organization in order to remediate vulnerabilities and respond to attacks. The challenge is a blurring of lines between the authority, responsibility and accountability for implementing change.
The approach taken by many organizations can be grossly organized into three categories.
1. Security administration – The everyday activities performed by IT security in support of its responsibilities. These can include the implementation and maintenance of policies and controls, threat analysis, compliance assessments, and security monitoring and incident investigation from a SOC or similar structure. These operational activities are clearly in the security domain, and while they will intersect with operations (for example, enabling log collection on a server) there is usually less grey area on who is the authority.
2. Secure ops frenemies – The necessary collaboration that must occur between IT security and operations. Every organization handles this a little differently, and ideally, there is documentation that clearly defines who provides management of credentials and access, who changes rules on the firewalls, and who patches servers to eliminate a vulnerability, as examples. Where things get contentious is when timeframe and priorities differ. If a security organization detects the exfiltration of data from a database, they often must rely on operations to shut it down. Operations may be reluctant to do so if that database supports a mission-critical service for the business.
3. DevSecOps – As more enterprises adopt DevOps practices, there is a greater integration of developers and operations teams in planning, building, testing, deploying and maintaining code in production to accelerate release velocity. As bottlenecks or “constraints” are removed, security is gaining the spotlight, and often not in a good way. Security testing, when performed at the end of a development cycle, can identify code that is insecure, but is also then costly to change. So there is a movement to “shift left” security testing by including it earlier in the cycle, which is helpful for developers, but operations/security integration continues to be unaddressed. It remains to be seen if DevOps, which is developer focused, shifts its center of gravity more towards operations, and in doing so, helps to bridge security and operations.
Which approach is correct?
The correct answer, of course, is the one that supports the business need for speed of software delivery, and the confidentiality, integrity and availability of services and data. That means that all three approaches must be covered, but they need improvement. The greatest potential for improvement comes from the interaction between security and operations teams.
One of the keys to the success of DevOps is the automation of handoffs between steps in the toolchain that allows for the continuous delivery of code. That kind of orchestration is sorely needed to bridge the divide between security and operations tools. The political and budgetary walls that exist between these organizations are unlikely to be dissolved, and there is no good reason to force full integration or cross-use of all tools. But connections and automation made for specific activities can address the most pressing concerns.
For example, your SIEM platform may be able to initiate tickets in a service desk tool. Automated processes in the service desk can then be triggered to perform a remediation action that IT operations has approved. This reduces the workload on both the security and operations teams and can enable a feedback loop for continuous improvement that will also support mutual trust.
That trust, leading to cooperation, is sorely needed in a time when security threats are innovating faster than the enterprise can keep pace. The greater the partnership between security and operations, the better the chance your organization can deliver software faster and minimize breach damage.