When it comes to security, don’t shoot the developer

Application and software vulnerabilities are increasingly popular routes for cybercrime. This has led to pressure on development teams to contribute to security, but most security managers don’t have a strong understanding of modern development teams, tools and practices.

Share

Application and software vulnerabilities are increasingly popular routes for cybercrime. This has led to pressure on development teams to contribute to security, but most security managers don’t have a strong understanding of modern development teams, tools and practices. Furthermore, the way security and development teams interact often increases the divide, which was illustrated while answering questions at a Security BSides conference in Austin a couple of years ago:

Security curmudgeon: “If developers would stop writing such crappy code, all our lives would be a lot easier.” Me: “?!”

How does one respond to that? The problem is the curmudgeon’s premise was flawed – he assumed developers wrote code with security vulnerabilities because they were some combination of stupid, lazy or even malicious. For most developers, that couldn’t be further from the truth. Developers do care about security, but they often don’t have a background in secure design and coding fundamentals, much less platform-specific advice on how to build things the correct way.

Just providing training and instruction doesn’t solve the problem either. Security professionals must understand that developers do care about security. They must care about security while caring about application performance and fixing non-security-related bugs, all while delivering new features on an impossible timeline. Too many security teams live in a security-centric world. Development teams live in a world where security is a factor, but competes with more prominent concerns. Agreed, development teams need to better educate their members about security, but equally, name-calling and a holier-than-thou attitude from security teams will not help.

Here’s how development and security teams can interact better:

- Learn how your development teams work. Are they using a waterfall or an Agile methodology? How often do they do internal and external releases? When you ask developers to fix vulnerabilities or participate in proactive activities like threat modelling, you’re asking them to work on your behalf. It helps to know how they work so you can time and characterise requests in a way that is going to be as easy as possible for them.

- Learn about the coding and management tools your development teams use. Giving developers a new system to manage their security tasks is harder than packaging security tasks in the systems they’re already using. Developers will avoid anything that’s too hard.

- Show up bearing gifts once in a while. Development teams won’t want to see you if you’re delivering always bad news, Instead try to show up with some good news or gratitude or something they can use to do their jobs better.

- “Skate to where the puck is going to be,” hockey great Wayne Gretzky once famously said. After you understand what development teams are doing now, spend a little time looking at what teams are just starting to try out. Between DevOps, cloud servers, everything-as-a-service and other innovations coming available, the way applications get developed and deployed is evolving quicker than ever. These technologies are going to be adopted, and security folks need to figure out how they’re going to best deal with it.

Development teams have a critical role in keeping organisations secure because the software they develop is a prime target and potential entry point for attackers. Unfortunately, security is only one concern among many for development teams, and security managers often fail to consider this. Taking a couple of lessons from Dale Carnegie’s ‘How to Win Friends and Influence People’ and the writings of Emily Post on social etiquette can go a long way toward crafting much better interactions between development and security groups.

Dan Cornell, CTO Denim Group, (ISC)2 member.

"Recommended For You"

Agile doesn't (necessarily) mean fragile 11 Project Management Tips for Setting and Managing Expectations