Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

2/6/2014
12:45 PM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

The 7 Deadly Sins of Application Security

How can two organizations with the exact same app security program have such wildly different outcomes over time? The reason is corporate culture.

The kneejerk approach to application security is to start finding and fixing vulnerabilities. The problem with these reactive programs is that they end up being expensive witch-hunts that don’t change the way code is built. Instead, we need to think of those vulnerabilities as symptoms of a deeper problem that lies somewhere in the software development organization.

Over the past 15 years, I’ve worked with a variety of organizations, both large and small, to improve their application security capabilities. One thing I’ve noticed is that two organizations with the exact same application security activities can have wildly different results over time. One organization will improve, steadily stamping out entire classes of vulnerabilities. The other will continue to find the same problems year after year.

The difference is culture. In some organizations, security is an important concern that is considered a part of every decision. In others, security is considered a productivity killer and a waste of time. These "culture killers" will, most certainly, undermine and destroy your application security program. Let’s take a look at the seven most deadly security sins...

Sin 1: Apathy. In 2002, Bill Gates famously drafted his "Trustworthy Computing" memo in which he makes clear that "Trustworthy Computing is the highest priority for all the work we are doing. We must lead the industry to a whole new level of Trustworthiness in computing." Executives have the power to make security a priority or a joke. What messages are you sending with your security decisions and actions?

Sin 2: Secrecy. Consider the mission of the Open Web Application Security Project (OWASP): "To make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks." Making security visible in your organization will ensure that development teams and business organizations are on the same page. Secrecy, on the other hand, leads to confusion, blind decision-making, and can even create disincentives for secure coding.  Do you use every vulnerability as an opportunity to improve or as a secret to cover up as quickly as possible?

Sin 3: Forgetfulness. Security is created through the evolutionary process. "Builders" create a security system, and "breakers" challenge that security. Each iteration advances security a little bit. However, many organizations don’t save the improvements made during each iteration. They don’t learn. Instead, their developers continue to make the same mistakes year after year. Organizations that learn from their mistakes capture the lessons they have learned in standards, technical defenses, training, and other forms.

Sin 4: Promiscuity. Some organizations allow development teams to adopt new technologies without any security analysis. This might be an open-source library, a new framework, or a new product. Eventually, vulnerabilities are identified in the new technology, but by then it is either technically or contractually too late to fix. The solution is to ask the hard questions before you get in bed with a new technology. What is the security story behind the technology? How can you verify security? How have the vendors handled security issues in the past?

Sin 5: Creativity. Done right, security is boring. Every time we see custom security controls, we find serious problems. Everyone knows not to build their own cryptography, or at least they should. But the same reasoning applies to authentication, access control, input validation, encoding, logging, intrusion detection, and other security defenses.

Sin 6: Blame. Some people like to blame developers for security flaws. Economic theory suggests that this is the efficient approach, since developers are in the best position to prevent security glitches from occurring. But blaming developers for application security problems is exactly the wrong thing to do. Blame creates a dangerous feedback loop where developers despise security, security teams exaggerate their findings to get attention, and everyone ends up blindly trusting applications. Remember the words of Ice-T, "Don’t hate the playa, hate the game."

Sin 7: Faith. Many organizations rely on a quick scan or static analysis to see if their applications are "good-to-go" without really understanding what they are getting. For example, access control is a critical security defense, but most tools can’t test it at all. Same for many encryption and authentication defenses as well. So you’ll need a different strategy to verify that those controls are in place and effective. Blind faith is not a defense.

Consider your software development culture and ask yourself if you’ve made secure coding simple and fun. Just remember: All the tools and processes in the world won’t lead to secure code unless you tackle the culture killers. Good luck!

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
planetlevel
50%
50%
planetlevel,
User Rank: Author
2/12/2014 | 10:13:44 AM
Re: Culture is #1 -- True, but what's the deadliest sin?
Some security professionals have commented to me that the best way to boostrap a security culture is to get hacked.  And I have seen companies pour effort into application security after a hack.  But I'm not convinced. I've worked with a number of clients that have managed to create a very strong security culture without a devastating hack.  And I've also seen those post-hack efforts fade over time -- meaning they didn't really change the culture.

To me the best signal of a great security culture is that security has been made "visible" -- there are artifacts available and people encourage informed and rational discussion of security issues.  Beware that "black-and-white" thinking! What other signals do you see of either great or terrible security culture?
J_Brandt
100%
0%
J_Brandt,
User Rank: Apprentice
2/11/2014 | 5:39:36 PM
Re: Culture is #1 -- True, but what's the deadliest sin?
Definitely Sin 1: Apathy.  With no incentive at the highest levels, nothing can be done.  No education, no awareness, no tools, no procedures, no nothing can happen.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
2/11/2014 | 1:33:19 PM
Re: Culture is #1 -- True, but what's the deadliest sin?
Glad you liked the column, J_Brandt. Curious to know which of the 7 deadly sins stands are the most deadly in your experience.
J_Brandt
100%
0%
J_Brandt,
User Rank: Apprentice
2/11/2014 | 1:14:43 PM
Culture is #1
Excellent piece.  It seems like almost weekly I am making the point to my clients that culture can override and make invalid any security hardware, software or procedure.  I'll be referencing your 7 deadly sins to help "tackle the culture killers!"
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
2/10/2014 | 8:59:38 AM
Importance of culture
Jeff, I couldn't agree more with your point about the importance of culture in setting the tone for attitudes about security. This is true on all levels -- from  software app development to enterprise-wide security architectures to end user awareness. And the message cleary has to come from the top. 
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
MITRE Releases 2019 List of Top 25 Software Weaknesses
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14994
PUBLISHED: 2019-09-19
The Customer Context Filter in Atlassian Jira Service Desk Server and Jira Service Desk Data Center before version 3.9.16, from version 3.10.0 before version 3.16.8, from version 4.0.0 before version 4.1.3, from version 4.2.0 before version 4.2.5, from version 4.3.0 before version 4.3.4, and version...
CVE-2019-15000
PUBLISHED: 2019-09-19
The commit diff rest endpoint in Bitbucket Server and Data Center before 5.16.10 (the fixed version for 5.16.x ), from 6.0.0 before 6.0.10 (the fixed version for 6.0.x), from 6.1.0 before 6.1.8 (the fixed version for 6.1.x), from 6.2.0 before 6.2.6 (the fixed version for 6.2.x), from 6.3.0 before 6....
CVE-2019-15001
PUBLISHED: 2019-09-19
The Jira Importers Plugin in Atlassian Jira Server and Data Cente from version with 7.0.10 before 7.6.16, from 7.7.0 before 7.13.8, from 8.1.0 before 8.1.3, from 8.2.0 before 8.2.5, from 8.3.0 before 8.3.4 and from 8.4.0 before 8.4.1 allows remote attackers with Administrator permissions to gain rem...
CVE-2019-16398
PUBLISHED: 2019-09-19
On Keeper K5 20.1.0.25 and 20.1.0.63 devices, remote code execution can occur by inserting an SD card containing a file named zskj_script_run.sh that executes a reverse shell.
CVE-2019-11779
PUBLISHED: 2019-09-19
In Eclipse Mosquitto 1.5.0 to 1.6.5 inclusive, if a malicious MQTT client sends a SUBSCRIBE packet containing a topic that consists of approximately 65400 or more '/' characters, i.e. the topic hierarchy separator, then a stack overflow will occur.