What will the security team of the future look like?

I’m going to say something that I suspect a lot of people are already thinking: on its own, shifting security to the left isn’t solving the problems we want it to.

Building a secure software development lifecycle is a universal good. It leads to better products. But without other changes being made, it isn’t going to fix security problems in the development environment. For that, we need to examine how security operations are run.

I only came to this realization very recently. Like most people, I had assumed that shifting security to the left was a process that would take more time. Where it wasn’t working, I would have told you that more effort was required to allow a security culture to permeate software development. But then I started speaking to security professionals from across the industries in which F-Secure works, and something became quickly apparent. Even though developers are writing much more secure code, the security of development environments doesn’t seem to be getting better. And that’s despite concerted effort.

In fact, my own industry research showed that development environments are a top security worry for CISOs attempting to secure their cloud estates, irrespective of how long their organization has been shifting security to the left.

We’ve all been trying to shift left for close to half a decade. If, in that time, cyber mature financial institutions haven’t managed to do it, then I’d confidently say that nobody is going to get there soon.

Responders on the front lines have known this for a while. Joani Green—who leads F-Secure’s UK incident response team—says, "misconfigurations caused by decentralized DevOps teams have been the primary reason for the cloud breaches we've investigated in the past year or two. Primarily this is about DevOps pipelines containing secret keys, organizations not having control over secrets, and also logging and configuration tracking."

So what can explain this? And how can we make things better?

I’ve been thinking about these questions a lot recently. In so doing I’ve realized that there’s a larger story here. This is a story about how our attack surfaces changed but our approach to securing them lagged, and of how we all thought that cultural changes could fix organizational problems.

This is a story about how we all thought that cultural changes could fix organizational problems.

Ever further to the left

A 2001 blog by Larry Smith is often credited as the first statement about shifting security to the left. Smith was talking about testing in a narrow sense, and he was also writing over a decade before most organizations were even thinking about the cloud. Nonetheless, in the last decade, his basic insight has been developed into the dominant means for organizations to try and control the security problems that arise with decentralized development.

In this decade, a huge amount of progress has been made in securing development processes. Developers who think about security as a core feature of their products write code that is more stable, robust, and resilient. They have clearly demonstrated that there is a business cases to be made for adopting a DevSecOps process that goes beyond just ‘securing the product’. But then, there are also things that simply haven’t been addressed by most organizations going down this path.

Crucially, many organizations still don’t factor the cost of security into individual business functions. The result, says consulting director Jesper Gerved, “is that security doesn’t get implemented because it’s not on organizations’ priority lists.” If an organization wants to distribute security operations out into its business functions, it needs to turn security into a measurable deliverable for employees, equal to the other goals it pursues. Developers are under intense pressure. A recent study (with an admittedly tiny sample size of 260) found that 83% report feeling burned out. These are people who are already being pushed to breaking point. If security stops them meeting targets that their organizations value, they will find ways around security. Matthew puts this all in simple terms: “developers have a split goal of needing to do security stuff but having their backs up against the wall to cut code and deliver features.”

What often happens is that developers get asked to secure their projects, even though financial responsibility for that security lies with a separate operational team. Matthew (again) is very clear: “you need to be able to solve that divergence. To figure out what security is worth for your organization.” Ultimately, he explains, “the question is who’s going to pay for it.”

This is a problem that our consultants working in the field are increasingly coming up against. Antti Vähä-Sipilä is one of the pioneers of securing the systems development lifecycle (SDLC) in his native Finland, with big plans to revolutionize how organizations think about their security architecture. But Antti has found that simply focusing on improving processes is no longer always enough to achieve the changes needed to make his clients secure. “The root causes of these problems run much deeper than an SDLC gap analysis can expose,” he says, referring to the kind of assessment that he usually carries out when starting work with a new client. Gaps in SDLC processes get spotted, but fixing them doesn’t lead to the necessary improvements, and the reason for this is simple: many companies now have organizational structures that are “unhelpful for getting security right."

…many companies now have organizational structures that are “unhelpful for getting security right."

Antti thus sees organizational change as being crucial to overcoming these challenges. His actual recommendations—which have to do with restructuring entire product management concepts—fall outside the scope of the reports that he is usually asked to write. Often, what is needed are a series of tough but honest discussions with those at the very top.