In collaboration with Osterman Research, we recently embarked on a study into the human elements of cyber risk in the SDLC. Sean Wright, Lead Application Security SME at Immersive Labs, shares his thoughts on what we found.
“It’s the developers’ fault.” “Security is a hindrance and a roadblock.” “It’s not my problem.”
I’ve heard these more times than I care to count and, honestly, I’m fed up with it. Why? Because it shows that security and development teams are not collaborating – and often, they’re at loggerheads with one another.
In fact, this dynamic was one of the reasons we launched our new module aimed at Development and Engineering teams – to help bridge the gap with greater education and training. As the Executive Order published yesterday demonstrates, application security is more crucial than ever to the security of entire organizations. It’s no longer the concern of a few security types tucked away in the basement, but something that must be a priority for all. So while tension between the teams might seem like an intangible, irrelevant issue, it leads to very real problems.
The Executive Order on Improving the Nation’s Cybersecurity looks to both automation and human solutions to address the problem. We believe that if organizations can get the human elements right, it will have a foundational impact on the security of the SDLC as a whole.
Our new study with Osterman Research exists as a reflection of this. It clearly highlights that those human elements, including but not limited to the lack of collaboration between security and development teams, are having a serious impact on application security. In fact, it found that 81% of developers are knowingly releasing vulnerable applications, and only 31% of security practitioners believed their build environment was secure enough to withstand an attack like SUNBURST. If that’s not a worrying state of affairs, then I don’t know what is. But I’m not here to play the blame game – instead, I want to look at why this gap came about, and what we can do to close it.
Mind the gap
One of the most telling statistics picked up by this report is that only 27% of developers who responded felt that the security of applications is part of their responsibilities, with half of security practitioners feeling the same. It seems that one of the few commonalities between security and development teams is, sadly, that neither wants to take responsibility for application security.
This inter-team conflict has deep roots. In the past, development teams were quite right in some of the perceptions that they had about security teams: there’s a reason they earned the reputation for being the “no” team, after all. Luckily, we have come a long way since then, but there’s clearly still work to be done.
Why should we care?
Security and development teams have different responsibilities, so why should we care whether they collaborate not? To put it bluntly, because it could be the difference between your organization avoiding a major attack like SUNBURST and hitting the headlines for all the wrong reasons.
To be slightly less dramatic about it, there are a number of business-critical reasons behind closing the gap between security and development:
Addressing security issues earlier in the SDLC results in significantly lower costs.
The closer to production that any issues are identified, the longer and more costly it becomes to remedy. In some cases, it may even become an accepted risk which could take years to resolve, if ever.
Development has changed, but ‘old school’ testing is lagging behind and slowing deployment.
Gone are the days of large monolithic releases. We’ve now moved into the era of Continuous Delivery / Continuous Deployment (CI/CD). Changes are pushed out at a rapid rate and the old approach of testing before release just can’t scale.
Both teams are expected to do more with less – working together earlier in the SDLC will reduce friction later.
Security resources are often overburdened and under-resourced, and developers are expected to meet tighter release deadlines. Combine this with the move to CI/CD, and again the old approach is not going to work.
Collaboration is a two-way street.
The key to closing the gap between the two teams once and for all can be summed up in one word: understanding. And this understanding has to travel both ways. Security teams need to understand the pressures that the development team is under to get new features deployed faster and faster. Rather than being the team that blocks a release, they need to be the team that makes a release possible. They must provide solutions, not problems.
On the flip side, development teams need to understand the pressure that the security team is under to keep the organization safe and secure – and the vital role that their everyday work plays in that.
Something that fuels this lack of understanding is a lack of knowledge. Developers need to be aware of the vulnerabilities that they might introduce into their code and how to prevent them, but they also need to understand why this is important. They need to see what impact that vulnerability could have if it was exploited. Sadly, when only 44% of security practitioners felt they had the time to work with developers to secure applications, this is much easier said than done.
But there is a way.
150 labs on AppSec – and more every day
In one of my previous jobs, I found a Cross-Site Scripting (XSS) vulnerability in an application. I raised it with the devs but they didn’t think it was a big issue. It wasn’t until I demonstrated how an attacker could potentially use that vulnerability to gain ownership of a user’s browser did they understand the risk it posed and the importance of getting that specific vulnerability fixed.
That very scenario is the basis for Immersive Labs’ new Application Security product. It’s designed to offer developers real-life examples of vulnerabilities, stepping through how attackers can exploit them and what the potential outcome could be. It makes a hypothetical into a reality, so developers can get practical experience in preventing vulnerabilities from entering their code in the first place.
One of the greatest frustrations of an appsec engineer is seeing the potential that these two teams have if they just worked together: faster deployments, frictionless testing, alleviated pressures on time and resources, more space for creative solutions and – the reason we’re here – more secure applications. By using a tool like the Immersive Labs platform, we can equip both development and security teams with the appropriate knowledge and skills that’ll put them on the same page to fulfil that potential. Closer collaboration between teams means more powerful security and greater success for their organization.
If you would like to read the full report, click here to download a copy now. Alternatively, to see our new AppSec module in action, hit the button below to get a demo.
