Life used to be simpler for security teams. In the legacy world, they had a clear understanding of the environment they needed to protect—typically the standard LAMP stack (Linux, Apache, MySQL, PhP). Within this straightforward, relatively static infrastructure, they could carve out a network layer all for themselves to implement the security technologies of their choice. They also had a direct line to vendors to discuss the security controls that needed to be implemented. But in the age of DevOps and cloud, things just don’t work this way anymore. Four key changes have left security teams struggling to protect applications and organizations.
1. There’s no such thing as a standard architecture
Compared with the basic, standard stacks of the past, today’s application environments are a sprawling, ever-changing tangle. Many of the technologies used to enable DevOps teams are specifically designed to break the constraints of legacy architectures so that developers can move faster and launch software with greater agility.
In hopes of reclaiming the kind of control they once had, many companies talk about setting up a cloud environment for developers to use. By standardizing on a single platform, a single coding language, and so on, they can make it safe to develop in the cloud—or so the thinking goes. But with so many new architectures and technologies emerging to enable modern development practices, the very notion of a standard cloud computing platform sounds better in theory than in practice. You can have standardization, or you can have digital agility—but trying to have both is a fallacy.
2. Developers are in control
The network layer that security teams once relied on is now gone, and with it, their ability to dictate technologies. Developers are now driving more decisions and workflows—and they’re taking advantage of the freedom. In the 2019 DevOps Community Survey, 50 percent of respondents from large organizations cited that information security policies and teams are slowing software development teams down.
This shift in control makes sense in development terms; developers have the best understanding of the environments and tools that best meet their needs. But it also makes security something of an afterthought—another box to be checked on AWS, Azure, or GCP. They rarely have the time, expertise, or interest to research the best WAF available; according to the 2019 DevSecOps Community Survey, 48 percent of developers believe security is important but don’t have enough time to spend on it. In practice, that often means going with whatever’s easiest to order and move on to the coding at hand.
3. Business units are doing their own thing, too
It’s not just developers who are making their own technology decisions. Within an organization, there can be any number of teams using various clouds and content delivery networks (CDNs) for their own purposes. That’s one more set of environments for security to try to protect—and further proof that the traditional model of a single static, standardized architecture across the organization is gone for good.
4. Security teams are flying blind
As a result of these trends, security teams struggle to make decisions that fit the reality of the technology environment. The application layer is now a rat’s nest of services for long-term data, short-term data, analytics, communication, and so on, with new layers being added all the time. The security team doesn’t have a clear understanding of exactly what the architecture looks like, or why. And it’s not just security who has a hard time keeping up; the 2019 DevSecOps Community Survey found that 47 percent of mature DevOps organizations don’t have meaningful controls over what components are in their applications. It’s often unclear who’s making the decisions about what gets purchased and installed. Meanwhile, both development technologies and threats are proliferating and changing more rapidly every day.
How can the security team hope to maintain a vestige of control or protection? That’s not just a rhetorical question. Rather than clinging to outdated models that just aren’t coming back, security leaders need to develop new ways to collaborate with development to maintain protection without impeding DevOps agility. In part 2, we will discuss three ways to make that possible.
Read Part 2 here.
