This is a weekly post where we address questions of interest to the Application Information Security Community. To that end, we’d love to hear your questions! Please Tweet us with the hashtag #ThinkAppSec or leave us a comment below and we’ll pick one or two questions from that list.

#ThinkAppSec Questions Answered (Week 8)

This week’s question was inspired by a concern I’ve heard from many different companies over the years. The big picture problem can be paraphrased as: Help! Our Dev Team hates the Software Security Testing Team.

Rather than two questions this week – we’ve got a two part answer to one big question:

How can we foster cooperation to help our Development and Security Teams work together?

1. Motivation

Though it can be easy to striate ourselves into opposing factions (ex: red states v. blue states, dog lovers v. cat lovers, vegans v. omnivores), there’s strong evidence that human beings are naturally social and cooperative creatures that want to work together. A great way to get that cooperation fired up is to provide a common motivation. When humans are faced with a shared goal, it’s more likely they’ll work together to achieve it. These same principals can be applied to application security testing.

To illustrate this point, let’s take an example company that is about to launch a major offering. This is the one, it’s going to lead-frog the competition and bring in a slew of customers with all of its innovate features and functions. The Board and Sales are jazzed up because the new application is projected to increase the customer base and revenues significantly. The business owner of the app has completed extensive focus group testing and the new application got high marks for user experience and value. The dev team has been working round-the-clock to ensure that the offering launches on the target date. And marketing has lined up an advertising/social media blitz for it.

Everything’s great right? Not so fast, the security team just finished the pre-launch security assessment and the app is riddled with high severity vulnerabilities. Now they’re going to the business owner and the CEO saying that the new app can’t launch with these exposures and the launch target date is in jeopardy.

Now consider these two scenarios, in the first the dev team and security team are motivated by different goals, in the second their goal is the same.

Scenario One: Dev – Get the App Out on Time Security – No Vulnerable Apps can Launch

Since the project’s inception, the dev team has had one core remit – make a usable app, that customers will love and have it ready for the target launch date. There may have been some mention of it being “secure” but what that means was never clearly defined. Dev is responsible for making an app customers love, and the focus groups have already proven this out, the app is great and in the dev team’s mind it is ready for launch.

The company has been clear – security testing’s purpose is to make sure no vulnerable apps go into production. And their testing proves this new app is vulnerable. Security knows that delaying the launch of the app could have negative financial consequences for the company, but their objective has been set: preventing the company from attack and sensitive data loss.

Scenario Two: Dev and Security – Get a Secured App Out on Time

The CEO and Board understand the business risks of launching applications intro production with high severity vulnerabilities. Protecting customer and sensitive data is a core tenant of the company’s mission and is one of the critical goal’s for this new app. Dev knows that part of their success for this project is dependent on the application launching with no high severity vulnerabilities so they are highly motivated to get those vulns removed before launch day.

Which scenario looks more like the situation at your organization? Which one do you think will be more effective in the long run?

2. Communication

In the previous example, you may have been screaming – “but wait! there’s another big problem, all the testing was done at the end of the cycle!” or “our executive management doesn’t understand the risks of a vulnerable app so security is never part of the real success factors for the dev team!”

Excellent points that lead to the other key factor for cooperative harmony between dev and security: communication. The sooner the common goal can be articulated and worked into the process and the more clearly the process is communicated between all parties, the better chance there is for smooth, operationally efficient, execution. No development team wants to hear at the end of the cycle that their code is “bad.” That sets up a combative and contentious environment. If the development team works collaboratively with security and the business owners at the beginning of the process, security and risk management can be worked into the cycle at the beginning and the teams can work toward a common goal throughout the process, with secure requirements, secure design, threat modeling and security testing at many checkpoints rather than having a nasty security surprise two days before a major launch.

Don’t forget that communication needs to expand beyond the dev and security teams up to the executive decision makers. If the business supports security testing and a risk program that can balance speed to market with app vulnerabilities and exposures that can set the tone for a shared goal between dev and security. If the top level of decision makers has the right goal – the delivery teams have a much better chance of being team-mates rather than warring factions with disparate goals.

Security Intelligence

{{title}}

{{title}}

{{title}}

Topics

#ThinkAppSec Questions Answered (Week 8)

1. Motivation

Scenario One: Dev – Get the App Out on Time Security – No Vulnerable Apps can Launch

Scenario Two: Dev and Security – Get a Secured App Out on Time

2. Communication

Other Application Security Questions Answered

More from Software Vulnerabilities

X-Force releases detection & response framework for managed file transfer software

MSMQ QueueJumper (RCE Vulnerability): An in-depth technical analysis

X-Force prevents zero day from going anywhere

Topic updates