Application Security
9/19/2014
10:30 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

An AppSec Report Card: Developers Barely Passing

A new study reveals that application developers are getting failing grades when it comes to their knowledge of critical security such as how to protect sensitive data, Web services, and threat modeling.

Let me start by recounting an Aesop’s Fable "The Stag at the Pool."

A stag saw his shadow reflected in the water. Although he greatly admired the size of his antlers, he was angry with himself for having such weak feet. While he was contemplating himself, a lion appeared. The stag took flight and kept at a safe distance from the lion, until he entered a wood and became entangled by his horns. The lion quickly came up and caught him. The stag reproached himself: "Woe is me! How have I deceived myself! These feet which would have saved me I despised, and I gloried in these antlers which have proved my destruction."

A decade ago a chief information security officer (CISO) wasn’t in the lexicon. Fast forward ten years and you can find thousands of CISOs serving companies large and small. Some positions are created in response to having sustained a massive breach, like Neiman Marcus. Others are created to try and get a handle on organizational security because hacks and breaches harm profits. Just ask Target. Or Home Depot.

Modern technology is stunningly effective. We can do so many things quickly and efficiently. Open-source libraries are an excellent example of how people across the world can collaborate and produce good products. Despite rapid technological advances and changes, the way in which developers write code has not changed. And if secure coding practices aren’t taught, developers can’t be expected to produce secure code and deploy safe applications.

What developers don’t know about AppSec
In the recent 2014 State of Application Developer Security Knowledge Report, a year-long study by Aspect Security on what 1,425 developers from 695 organizations worldwide know and don’t know about security, we discovered some areas developers understand well, and some critical areas with which they struggle. Our study details the results of a fully randomized test of basic application security knowledge across 65 different areas. Here are a few key findings:

Protecting Sensitive Data: 80% of developers answered incorrectly.
Data breaches are the most common security exploits. Hundreds of millions of account details have been stolen this year alone. Developers must know what your different types of data are and be taught how to properly protect each.

Introduction to Web Services Security: 64% of developers answered incorrectly.
If your organization is moving to service oriented architecture, publishes APIs, has REST interfaces, is using JQuery or Angular, or is building rich clients, then the low scores here should be of particular concern. There are lots of ways to build these APIs insecurely, and your developers need to understand the right way to do things.

Threat Modeling and Security Architecture Review: 74% of developers answered incorrectly.
Developers didn’t do very well when asked about security architecture and security models. Without a plan, framework, and guardrails in place, it’s not surprising that code gets built with architecture-level vulnerabilities in place. Training your team how to communicate and collaborate on security is a smart investment.

What’s in it for me?
While industry reports provide general information, they can’t tell you what your developers know about application security. Are your developers in the camp that scored just 36% on Web Services Authentication and Authorization? Or did they score 81% on Cross Site Request Forgery? Are you able to answer questions like:

• Do you have vulnerabilities you haven’t fixed? (The answer is yes.)
• Do you have vulnerabilities you don’t know about? (The answer is yes.)
• Do your employees have sufficient time to learn about the latest vulnerabilities, the skills to understand secure coding, and the support to put those things into practice? (The answer is: … that’s up to you.)

If you don’t know, that’s OK. You can find out where you fall short by taking a free Secure Coder Analytics quiz (also created by Aspect Security). The results for your organization will be specific and actionable, not industry guidance, antlers of beauty though they are. They’ll point to what you need and get you down to the details that matter. They’ll be the feet that carry you swiftly away from attackers.

Some organizations do quite well in many application security measures. They understand what SQL Injection is and have taught their developers so they don’t create vulnerable code. But what about protecting sensitive data so a data breach doesn’t happen to you? Or using cryptography securely so credential handling and algorithm choice don’t become your undoing? Or authenticating users to manage identity properly so cross site request forgery doesn’t cough up organizational data?

Application security doesn’t happen by chance, it happens by choice; it happens by design. And with the average score for developers sitting at a barely passing 60.77%, clearly there needs to be more application security training by design. We need to value practical application of knowledge.

After all, that’s the moral of "The Stag at the Pool." What is most truly valuable is often underrated, and application security knowledge is certainly underrated. So get down to brass tacks and figure out what your developers know.

 

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
Page 1 / 2   >   >>
planetlevel
100%
0%
planetlevel,
User Rank: Author
9/23/2014 | 5:10:53 PM
Re: Blame the developers?
I would never blame developers for our problems in application security.  This study is intended to shine a light on what we know and don't know so that we can make some rational decisions.  There's no blame or animus here.

I have quoted Ice T in many presentations saying "Don't hate the playa, hate the game."  The problem is that the entire software development ecosystem is not set up to encourage secure code.  These things can shift, though.  The automobile industry shifted from the Ralph Nader "Unsafe at Any Speed" days to now, where cars have extensive safety protections, regulation, crash tests, etc...

So how do we get out of the "Unsafe at Any CPU Speed" days?  I think there's a lot of promise in the DevOps movement.  Not that DevOps by itself will lead to more secure code, but all the tools and processes in DevOps establishes the infrastructure that will make automated security verification possible.

 
aws0513
50%
50%
aws0513,
User Rank: Ninja
9/22/2014 | 8:46:07 AM
Re: This is surprising for me
I perceive the AppSec miasma as a complex problem of the following.
  • Coders that do not know or are not attentive to application security practices.  This of itself is because of several factors to include coders who are self taught, coders that attended developer training at schools that do not teach application security practices, and coders that are simply focused on the solution without consideration for security being integral to that solution.  Some of this weakness can also be attributed to managers.
  • IT development managers focused on delivering service without consideration for security practices.  Many IT managers are measured on completion of projects, without any measure for completion based upon security audit.  Some managers would have contention with that statement, but after being part of many audits in the past, more often than not, the IT managers were at fault for not implementing AppSec practices within their team and holding strictly to those practices as part of office policy.  In the end, the management CAN influence the way their development teams address AppSec practices.  But there still seems to be a broad lack of attention in this area, especially in smaller organizations.
  • Lack of aggresive attention to security practices by C-Level management.  Even if there is a CISO role within an organization, it is not uncommon for the upper management to demand delivery of a solution or product before it has been vetted properly for security practices and controls.  The ever present "operations before security" concern starts at the top.  Although this is still considered a acceptable view, IMHO it is the wrong mindset to have in this day and age.

The analogy I have for the entire AppSec attitude out there is the seatbelt law.  As laws for seatbelt use started to be established, it took many years of effort by lawmakers, judges, law enforcement, and even the insurance and auto industries to change the public mindset.  Even today we still have people out there that still insist on driving without their seatbelt.  We all know it is better for us, but so many still see the practice as fruitless and not necessary because "we are good drivers" and "accidents happen to bad or inattentive drivers".

As a IT security professional, I constantly discuss  AppSec with management.  But I also constantly see "exceptions" or "deferred requirements" on projects because the upper management wants a project to be implemented now instead of waiting on the extra efforts necessary to make sure AppSec practices are completed properly. 
This tendancey toward exception process (at all levels of management) needs to be curtailed...  dramatically.  How to convince management of this and make them follow through is the hard part.
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
9/22/2014 | 7:58:19 AM
Re: This is surprising for me
Stephen Covey's famous quote to "begin with the end in mind' from his series on Habits of Highly Effective People are certainly apt here. However I'd say that the beginning in this case starts with the people and companies who pay developers to write code for software. The survey results quoted here definitely underscore the fact that securtity is an afterthought in app developmeent and that's not going to cut it today.

I'd also like to point out that we'll be talking about application security on Dark Reading Radio this week will guest speakers Michael Coates, OWASP Chairman and Product Security Director at Shape Security, and former OWASP Chairman Jeff Williams, who is founder and CTO of Aspect Security & Contrast Security, and the creator of many open-source standards, tools, libraries, and guidelines – including the OWASP Top Ten.

We'll be taking a close look at some of the latest research and practices in application security on the heels of OWASP's AppSec USA conference in Denver last week. Date & Time, Wednesday 9/24 at 1 pm. ET, 10 am PT. Here's the link to the show

 
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
9/19/2014 | 6:30:40 PM
Re: Colleges are the problem
I would agree with this statement too. Programming classes are more focused on fundamentals of logic implementation and/or computer languages and standards, most is certainly not focused on secure application development practices.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
9/19/2014 | 6:28:57 PM
Re: Blame the developers?
I agree. Some security problems come from the fact of not following secure coding guidelines, some others are actually from simple bugs, not from implementation strategy.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
9/19/2014 | 6:26:02 PM
This is surprising for me
We certainly expect more out of developers. There can not be expectation of a secure application without an expectation of security-aware developers. Developers have to increase their knowledge of security and start development security in mind. As Stephen Covey wold put it "start end in mind"
davidneville
50%
50%
davidneville,
User Rank: Apprentice
9/19/2014 | 4:28:36 PM
Re: Blame the developers?
You are absolutely correct when you say a simple phishing exercise can make it a moot point. I completely agree that people need to be smart about security, and that no amount of security can protect you from people who make made choices. On the other hand, secure coding could have stopped things like TJ Maxx, Nieman Marcus, Target, and Home Depot. None of those were phishing scams, and it looks like insecure code contributed to the problems that led to data breaches. I'll go back to your question because, let's be honest, the bottom line is you can't protect people from themselves. Or, as a friend used to say, "You can lead a horse to water, but you can't make it do the backstroke."
TerryB
50%
50%
TerryB,
User Rank: Ninja
9/19/2014 | 3:19:08 PM
Re: Blame the developers?
@David, I'm sure you are right, he wasn't trying to diss developers. But talk about gross over simplification. I've been developing 10 years longer than the Author and I sure don't have the answers. Much of his 20 years was like much of my 30, using technology which has nothing to do with what is in use today.

So maybe he took timeout from paying work to go back to school and get trained on all the pitfalls in this new paradigm we are in now. If I have a point, and I probably don't, it's how many of these security experts can you even trust to train developers? Where did these experts come from on technology in it's infancy?

I maintain the two most contributing factors are unprecedented access to the servers (from internet) and use of scripting languages. I know the Author is saying that this is new world now and this is one step you can do to help, train developers to close more holes. But a simple phishing exercise can make all that a moot point.

Am I wrong?
davidneville
50%
50%
davidneville,
User Rank: Apprentice
9/19/2014 | 2:55:12 PM
Re: Blame the developers?
Blame the developers? Well, I'm sure there's blame enough to share. Product managers care about a product on the shelf. Security is an afterthought, if it's thought of at all. At the end of the day, no developer wants to create insecure code. Help them get the training and education they need to avoid simple mistakes. I think that's all the author was saying.
TerryB
50%
50%
TerryB,
User Rank: Ninja
9/19/2014 | 1:27:25 PM
Blame the developers?
Back in the day before internet and when programs were compiled, I sure don't remember the problems we have today, Maybe it wasn't the best idea to put my freaking bank's server ON THE INTERNET in the first place!!

Combine that with all these source code scripting languages which don't need to be compiled and we wonder why everybody is getting hacked.

I laughingly compare this to the movie War Games where the computer controlling nuclear weapons was hooked to remote access from the public. Doesn't appear to me moving bank/big store servers worked much better.

I like swiping debit cards and online banking access as much as next guy but I'd give it all up in second to prevent someone from stealling my credit or identity. At least back then it had to be an inside job, now you have a million different attack vectors and million different pieces of technology in the mix. If you want to train developers on all that in college, they'll be going to school longer than doctors.

The author suggests if we just hire someone like him this all goes away. Somehow I doubt he takes on that liability in his contract when he engages a client.
Page 1 / 2   >   >>
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This is a secure windows pc.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.