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.

Other Application Security Questions Answered

What is the importance of software security in supply chain management?

Who Should be Responsible for Application Security Testing?

Can “generated code” be tested?

How do we secure application vulnerabilities and code development, particularly for mobile and social applications that are built by business units or reside on the cloud?

As a CISO, how can I control my organization’s testing methodologies, change management and deployment processes, without compromising on quality and project timelines?
How Can I Secure Apps in the Cloud?

Will the legal landscape change if software vendors can be sued without damages or loss being proven?
The Legal Landscape: Can vendors be sued without damages? What the heck is PII?

What is PII – How much can the definition expand?
Mobile Apps: Which are More Secure Android or iOS?

Does IoT (Internet of Things) “change everything” for Application Security?

What is the difference between PCI DSS and PA DSS?

 

Submit your questions via Twitter using #ThinkAppSec

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

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

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today