<tt><font size=2>"Vance, Michael" <Michael.Vance@salliemae.com>
wrote on 14/02/2011 08:19:41 PM:<br>
<br>
> From: "Vance, Michael" <Michael.Vance@salliemae.com></font></tt>
<br><tt><font size=2>> To: "websecurity@lists.webappsec.org"
<websecurity@lists.webappsec.org></font></tt>
<br><tt><font size=2>> Cc: Ory Segal/Haifa/IBM@IBMIL</font></tt>
<br><tt><font size=2>> Date: 14/02/2011 08:20 PM</font></tt>
<br><tt><font size=2>> Subject: RE: [WEB SECURITY] Great article outlining
a core issue <br>
> with many in the security community</font></tt>
<br><tt><font size=2>> <br>
> Where do you draw the line at what developers should know and do <br>
> automatically and what they should only do if there is a specific,
<br>
> written requirement? Where do things get too technical for product
<br>
> owners and stakeholders to define them? We don’t expect there to
be <br>
> a written requirement to use a specific data type or array <br>
> structure; why should there have to be a specific requirement to <br>
> sanitize input using a whitelist? Shouldn’t that be automatic, part
<br>
> of “good coding practices?”</font></tt>
<br>
<br>
<br><tt><font size=2>*IMHO* - </font></tt>
<br><tt><font size=2>That's the wrong kind of requirement you listed there.
If you define the users of the system, and the use cases, you can derive
the rest (abuse cases). For example, user group A should access functions
f1,f2,f3, user group B, shouldn't have access to f1,f2 but access f3, etc.
>From these use-cases, you can define the abuse cases, in high level - for
example, user group A shouldn't be able to access information belonging
to user group B, etc.</font></tt>
<br>
<br><tt><font size=2>Your architect (or security champion) should translate
these use-cases & abuse cases into more technical requirements, such
as - "the system should protect from horizontal privilege escalation",
or "All attempts to read/write from the database should be validated
against SQL Injection to avoid data corruption or leakage", etc.</font></tt>
<br>
<br><tt><font size=2>These high level requirements, can then be fulfilled
by your developers, using the tools they have - secure coding best practices.</font></tt>
<br>
<br><tt><font size=2>You shouldn't have your stakeholders state: "Make
the system unbreakable", and then expect your developers to solve
the problem. That's a recipe for disaster. The more granular your requirements
and design are, the easier it will be to implement and produce metrics
for.</font></tt>
<br>
<br><tt><font size=2>(But, I'm stating the obvious now)</font></tt>
<br>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> The problem is getting owners and stakeholders
to think in terms of <br>
> abuse and misuse cases.  Their requirements are always based
on the <br>
> “happy path.” “If the user provides the input we are expecting,
this<br>
> is how the application should behave.” They define edits and <br>
> exception paths in terms of business logic, but never in terms of
<br>
> technical capabilities. They are concerned that a customer may try
<br>
> to withdraw more money from their account than the available <br>
> balance, not that they may try to withdraw more money than the input<br>
> buffer is designed to hold. That last type of requirement is up to
<br>
> the developer in many shops.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> Even when developers put the question to non-technical
stakeholders,<br>
> it often perplexes them: “If the program receives input that it is
<br>
> not designed to handle, how should I have the program handle it?”
 <br>
> Seems a little circular or oxymoronic, doesn’t it? You’re asking
for<br>
> a design specification for something that is not in the design.</font></tt>
<br>
<br><tt><font size=2>That's because it is exactly like asking the stakeholders
- should I use a While or a For loop. That's outside their domain. They
should define the security requirements, and the developer should fulfill
them. If the requirements are well defined, everyone will know what to
do.</font></tt>
<br>
<br>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> I’ve sat in requirements sessions and brought
up abuse cases where <br>
> the response from the business is, “What are the chances that <br>
> someone will do that?” The answer, as we on this list know, is that
<br>
> the chance is low, but when that one determined, skilled individual
<br>
> turns his attention to your application, you still need to be ready
<br>
> for him. The chances that a burglar is going to try to walk in your
<br>
> front door on any given day is pretty low, too, but we all still <br>
> lock our front doors.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br>
<br><tt><font size=2>That's why you do a risk assessment / threat model,
etc. You should come to the meeting prepared to answer technical questions
about the relevance of each threat or risk, so that the stakeholders will
be able to prioritize the solutions.</font></tt>
<br>
<br>
<br><tt><font size=2>> We need to get rid of the antagonistic Us vs.
Them attitude between <br>
> Security and AppDev, and we need to start by a) stopping accusing
<br>
> the other of not knowing s**t about the other’s discipline and b)
<br>
> admitting that we don’t know s**t about the other’s discipline.
Only<br>
> then will we actually start to listen to and learn from each other.</font></tt>
<br>
<br><tt><font size=2>I totally agree. </font></tt>
<br>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> -Michael</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> From: websecurity-bounces@lists.webappsec.org
[</font></tt><a href="mailto:websecurity-"><tt><font size=2>mailto:websecurity-</font></tt></a><tt><font size=2><br>
> bounces@lists.webappsec.org] On Behalf Of Ory Segal<br>
> Sent: Monday, February 14, 2011 2:22 AM<br>
> To: robert@webappsec.org<br>
> Cc: websecurity@lists.webappsec.org; websecurity-bounces@lists.webappsec.org<br>
> Subject: Re: [WEB SECURITY] Great article outlining a core issue <br>
> with many in the security community</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> Hi, <br>
> <br>
> Developers shouldn't be blamed for not writing secure applications
-<br>
> it's usually the fault of product owners and stakeholders that don't<br>
> define (and prioritize) security as a critical requirement for a <br>
> software project. <br>
> <br>
> You don't expect developers to build a pretty and usable user <br>
> interface, you also don't expect them to define the flow and logic
<br>
> of your application. That's why product owners and stakeholders have<br>
> to define product requirements, use cases, users, scenarios, etc.
<br>
> <br>
> Developers develop code, which should adhere to the requirements of
<br>
> the project. <br>
> <br>
> As long as security won't be a 1st class citizen in the world of <br>
> software requirements, I suspect we won't see software that is <br>
> secure by design. <br>
> <br>
> Having security requirements also means that product owners, <br>
> developers and QA teams can verify that the requirements are met.
<br>
> They can measure their success, and understand how to get better.
<br>
> Anything less than this is simply a waste of time, i.e. bolting <br>
> security on the project in hindsight. <br>
> <br>
> What we do need to ask ourselves is - if nobody is prioritizing <br>
> security as a critical software requirement - what are we doing wrong
here???<br>
> <br>
> -Ory <br>
> -------------------------------------------------------------<br>
> Ory Segal<br>
> Security Products Architect <br>
> AppScan Product Manager<br>
> Rational, Application Security<br>
> IBM Corporation<br>
> Tel: +972-9-962-9836<br>
> Mobile: +972-54-773-9359<br>
> e-mail: segalory@il.ibm.com <br>
> [image removed] <br>
> <br>
> <br>
> <br>
> From:        robert@webappsec.org <br>
> To:        websecurity@lists.webappsec.org <br>
> Date:        14/02/2011 12:36 AM <br>
> Subject:        [WEB SECURITY] Great article outlining
a core issue <br>
> with many in        the security community <br>
> Sent by:        websecurity-bounces@lists.webappsec.org
</font></tt>
<br><tt><font size=2>> <br>
> <br>
> <br>
> <br>
> I saw this posted via twitter and thought it was worth mentioning
<br>
> here. While the example specifies owasp, I am not posting this link
to slam<br>
> them in particular. I think that the point applies to MANY folks in
<br>
> the security industry.<br>
> <br>
> Security Vs Developers<br>
> </font></tt><a href="http://appsandsecurity.blogspot.com/2011/02/security-people-vs-developers.html"><tt><font size=2>http://appsandsecurity.blogspot.com/2011/02/security-people-vs-developers.html</font></tt></a><tt><font size=2><br>
> <br>
> Regards,<br>
> - Robert Auger<br>
> WASC Co Founder/Moderator of The Web Security Mailing List<br>
> </font></tt><a href=http://www.qasec.com/><tt><font size=2>http://www.qasec.com/</font></tt></a><tt><font size=2><br>
> </font></tt><a href=http://www.webappsec.org/><tt><font size=2>http://www.webappsec.org/</font></tt></a><tt><font size=2><br>
> <br>
> <br>
> _______________________________________________<br>
> The Web Security Mailing List<br>
> <br>
> WebSecurity RSS Feed<br>
> </font></tt><a href=http://www.webappsec.org/rss/websecurity.rss><tt><font size=2>http://www.webappsec.org/rss/websecurity.rss</font></tt></a><tt><font size=2><br>
> <br>
> Join WASC on LinkedIn </font></tt><a href=http://www.linkedin.com/e/gis/83336/4B20E4374DBA><tt><font size=2>http://www.linkedin.com/e/gis/83336/4B20E4374DBA</font></tt></a><tt><font size=2><br>
> <br>
> WASC on Twitter<br>
> </font></tt><a href=http://twitter.com/wascupdates><tt><font size=2>http://twitter.com/wascupdates</font></tt></a><tt><font size=2><br>
> <br>
> websecurity@lists.webappsec.org<br>
> </font></tt><a href=http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org><tt><font size=2>http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org</font></tt></a><tt><font size=2><br>
> <br>
> <br>
> This E-Mail has been scanned for viruses.</font></tt>