[WEB SECURITY] Great article outlining a core issue with many in the security community

Vance, Michael Michael.Vance at salliemae.com
Mon Feb 14 13:19:41 EST 2011


Where do you draw the line at what developers should know and do automatically and what they should only do if there is a specific, written requirement? Where do things get too technical for product owners and stakeholders to define them? We don't expect there to be a written requirement to use a specific data type or array structure; why should there have to be a specific requirement to sanitize input using a whitelist? Shouldn't that be automatic, part of "good coding practices?"

The problem is getting owners and stakeholders to think in terms of abuse and misuse cases.  Their requirements are always based on the "happy path." "If the user provides the input we are expecting, this is how the application should behave." They define edits and exception paths in terms of business logic, but never in terms of technical capabilities. They are concerned that a customer may try to withdraw more money from their account than the available balance, not that they may try to withdraw more money than the input buffer is designed to hold. That last type of requirement is up to the developer in many shops.

Even when developers put the question to non-technical stakeholders, it often perplexes them: "If the program receives input that it is not designed to handle, how should I have the program handle it?"  Seems a little circular or oxymoronic, doesn't it? You're asking for a design specification for something that is not in the design.

I've sat in requirements sessions and brought up abuse cases where the response from the business is, "What are the chances that someone will do that?" The answer, as we on this list know, is that the chance is low, but when that one determined, skilled individual turns his attention to your application, you still need to be ready for him. The chances that a burglar is going to try to walk in your front door on any given day is pretty low, too, but we all still lock our front doors.

We need to get rid of the antagonistic Us vs. Them attitude between Security and AppDev, and we need to start by a) stopping accusing the other of not knowing s**t about the other's discipline and b) admitting that we don't know s**t about the other's discipline. Only then will we actually start to listen to and learn from each other.

-Michael

From: websecurity-bounces at lists.webappsec.org [mailto:websecurity-bounces at lists.webappsec.org] On Behalf Of Ory Segal
Sent: Monday, February 14, 2011 2:22 AM
To: robert at webappsec.org
Cc: websecurity at lists.webappsec.org; websecurity-bounces at lists.webappsec.org
Subject: Re: [WEB SECURITY] Great article outlining a core issue with many in the security community

Hi,

Developers shouldn't be blamed for not writing secure applications - it's usually the fault of product owners and stakeholders that don't define (and prioritize) security as a critical requirement for a software project.

You don't expect developers to build a pretty and usable user interface, you also don't expect them to define the flow and logic of your application. That's why product owners and stakeholders have to define product requirements, use cases, users, scenarios, etc.

Developers develop code, which should adhere to the requirements of the project.

As long as security won't be a 1st class citizen in the world of software requirements, I suspect we won't see software that is secure by design.

Having security requirements also means that product owners, developers and QA teams can verify that the requirements are met. They can measure their success, and understand how to get better. Anything less than this is simply a waste of time, i.e. bolting security on the project in hindsight.

What we do need to ask ourselves is - if nobody is prioritizing security as a critical software requirement - what are we doing wrong here???

-Ory
-------------------------------------------------------------
Ory Segal
Security Products Architect
AppScan Product Manager
Rational, Application Security
IBM Corporation
Tel: +972-9-962-9836
Mobile: +972-54-773-9359
e-mail: segalory at il.ibm.com<mailto:segalory at il.ibm.com>
[cid:image001.gif at 01CBCC1F.ED165F70]



From:        robert at webappsec.org
To:        websecurity at lists.webappsec.org
Date:        14/02/2011 12:36 AM
Subject:        [WEB SECURITY] Great article outlining a core issue with many in        the security community
Sent by:        websecurity-bounces at lists.webappsec.org
________________________________



I saw this posted via twitter and thought it was worth mentioning here. While the example specifies owasp, I am not posting this link to slam
them in particular. I think that the point applies to MANY folks in the security industry.

Security Vs Developers
http://appsandsecurity.blogspot.com/2011/02/security-people-vs-developers.html

Regards,
- Robert Auger
WASC Co Founder/Moderator of The Web Security Mailing List
http://www.qasec.com/
http://www.webappsec.org/


_______________________________________________
The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity at lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org


This E-Mail has been scanned for viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110214/4093ffd3/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2359 bytes
Desc: image001.gif
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110214/4093ffd3/attachment.gif>


More information about the websecurity mailing list