There is an ongoing tension between corporate cybersecurity and application security. That tension is rooted in both the technical and organizational challenges of keeping both of these environments secure, compliant, and reliable. While many people may view ‘security’ with a broad brush, the actual day-to-day job of securing an application stack, and the tools required to do so, are quite different from that of securing a corporate network. While these two efforts may share the ultimate goal of security and compliance, there are enough differences to warrant separating them in an organization.
Corporate security must address a broad and dynamic attack surface. This includes endpoints in the field, widespread file sharing through email and collaboration platforms, data leakage, insider threats, phishing, and more. Their charter is protecting the company and its assets as a whole. As such, corporate security must contend with trusted, internal users making mistakes or taking actions that trigger an attack or a breach. They also must protect sprawling domains that could stretch across multiple clouds and remote sites.
On the other hand, in a DevOps environment, the danger is focused. Application security must defend against more aggressive, nuanced attacks while still fulfilling their mission – a mission that is likely directly tied to revenue or internal productivity. The stakes are higher in application security because application attacks tend to play out quicker and have more catastrophic impact. Most of the big breaches we hear about are ultimately application attacks.
Aside from the fundamental differences in mission, there are cultural differences between corporate and application security that are rooted in training, standard practices. and even philosophy. The traditional corporate security model of layered defense does not translate well to the tooling, structures, and architectures of the cloud. On-premise corporate security is not dynamic or built for the speed and scale of cloud environments. Given that, organizational tension arises when companies try inserting corporate security staff onto the application security team. The former will tend to treat application security like just another corporate system. Conversely, the latter would likely also not be ready to shift mindsets and behaviors to a corporate security operating paradigm.
Ultimately, to be successful, corporate security and application security must be run separately. However, it is important to note that while these two groups are different in execution, they do share the same goals. And while they need to have separate missions, they also must collaborate effectively.
One way to accelerate collaboration is with DevOps. Due to its nature and mission, it makes the most sense to prioritize adopting DevOps (or DevSecOps) practices in application security first. Attempting to apply DevSecOps in both environments right from the start can cause break downs. Because DevOps methods and frameworks are common to developers, application security teams are already working within a familiar structure. DevOps, however, does not translate as easily into corporate security’s on-premise model.
Furthermore, in cloud-based DevSecOps environments, the deployment, configuration, and monitoring of security controls can be fully automated. But with on-premise corporate security, this is much more difficult, given the hundreds (or even thousand)s of deployed endpoint machines, network perimeters, and office locations. Trying to apply months-long on-premise cadences to the cloud will significantly elongate implementing even the smallest changes. That’s not what DevOps, or DevSecOps, is about. Even just this single metric represents why corporate security and application security will have difficulty integrating.
To gain the advantages a DevSecOps model can offer, integration has to start on the application security side. Collaboration benefits will come later when these good practices trickle down to corporate security, but do not expect it to happen immediately. And do not unnecessarily force integration of these groups with each other; their diverse approaches will likely not mix well.
There are those who may argue that the separation approach is wasteful or that it breeds greater tension, particularly for smaller organizations. First, it is far more expensive and cumbersome to force two teams with radically different missions into a common structure merely for the promise of efficiency. Second, pushing DevOps on corporate security will cause greater tension at the start. It is preferable to allow corporate security to adopt these methods more slowly after there are clear structures in place with application security. Lastly, as the Puppet State of DevOps report showed, the challenge with DevOps adoption comes when automation ramps up. In the corporate security space, automation is still quite nascent, while it is mature in the application security space.
Ultimately, corporate and application security must unite under a common operational “language”, and DevOps is the best structure for that. However, there is a strong case to be made to keep these teams separated so they can focus on their missions, but then allow them to adopt DevOps concepts in a more natural and staggered manner.
