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.

Database Security
Authentication
Mobile
Privacy
Compliance
Careers and People
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
An AppSec Report Card: Developers Barely Passing
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   >   >>


News
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
News
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
News
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-21070
PUBLISHED: 2021-04-19
Adobe Robohelp version 2020.0.3 (and earlier) is affected by an uncontrolled search path element vulnerability that could lead to privilege escalation. An attacker with permissions to write to the file system could leverage this vulnerability to escalate privileges.
CVE-2020-7851
PUBLISHED: 2021-04-19
Innorix Web-Based File Transfer Solution versuibs prior to and including 9.2.18.385 contains a vulnerability that could allow remote files to be downloaded and executed by setting the arguments to the internal method. A remote attacker could induce a user to access a crafted web page, causing damage...
CVE-2021-29399
PUBLISHED: 2021-04-19
XMB is vulnerable to cross-site scripting (XSS) due to inadequate filtering of BBCode input. This bug affects all versions of XMB. All XMB installations must be updated to versions 1.9.12.03 or 1.9.11.16.
CVE-2021-23381
PUBLISHED: 2021-04-18
This affects all versions of package killing. If attacker-controlled user input is given, it is possible for an attacker to execute arbitrary commands. This is due to use of the child_process exec function without input sanitization.
CVE-2021-23374
PUBLISHED: 2021-04-18
This affects all versions of package ps-visitor. If attacker-controlled user input is given to the kill function, it is possible for an attacker to execute arbitrary commands. This is due to use of the child_process exec function without input sanitization.