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
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
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
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
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
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
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
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
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
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
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   >   >>


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The 10 Most Impactful Types of Vulnerabilities for Enterprises Today
Managing system vulnerabilities is one of the old est - and most frustrating - security challenges that enterprise defenders face. Every software application and hardware device ships with intrinsic flaws - flaws that, if critical enough, attackers can exploit from anywhere in the world. It's crucial that defenders take stock of what areas of the tech stack have the most emerging, and critical, vulnerabilities they must manage. It's not just zero day vulnerabilities. Consider that CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilitlies in widely used applications that are "actively exploited," and most of them are flaws that were discovered several years ago and have been fixed. There are also emerging vulnerabilities in 5G networks, cloud infrastructure, Edge applications, and firmwares to consider.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-1172
PUBLISHED: 2023-03-17
The Bookly plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the full name value in versions up to, and including, 21.5 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that w...
CVE-2023-1469
PUBLISHED: 2023-03-17
The WP Express Checkout plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘pec_coupon[code]’ parameter in versions up to, and including, 2.2.8 due to insufficient input sanitization and output escaping. This makes it possible for authenti...
CVE-2023-1466
PUBLISHED: 2023-03-17
A vulnerability was found in SourceCodester Student Study Center Desk Management System 1.0. It has been rated as critical. This issue affects the function view_student of the file admin/?page=students/view_student. The manipulation of the argument id with the input 3' AND (SELECT 2100 FROM (SELECT(...
CVE-2023-1467
PUBLISHED: 2023-03-17
A vulnerability classified as critical has been found in SourceCodester Student Study Center Desk Management System 1.0. Affected is an unknown function of the file Master.php?f=delete_img of the component POST Parameter Handler. The manipulation of the argument path with the input C%3A%2Ffoo.txt le...
CVE-2023-1468
PUBLISHED: 2023-03-17
A vulnerability classified as critical was found in SourceCodester Student Study Center Desk Management System 1.0. Affected by this vulnerability is an unknown functionality of the file admin/?page=reports&date_from=2023-02-17&date_to=2023-03-17 of the component Report Handler. The manipula...