<div>The text outlined in SAFECode's latest release is very neat, simple and nicely puts forth the idea in a way understood easily by developers and security folks alike. Yeah, there might be some lack of prescriptive requirements but it is a good starting point for security folks while writing literature intended for non-security/developer/business typesee audience - that includes security requirements.</div>

<div><br clear="all">Thanks & Regards,<br>Prasad N. Shenoy<br><br><br></div>
<div class="gmail_quote">On Tue, Feb 15, 2011 at 2:53 AM, Ory Segal <span dir="ltr"><<a href="mailto:SEGALORY@il.ibm.com">SEGALORY@il.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><font face="sans-serif" size="2">Hi,</font> <br><br><font face="sans-serif" size="2">You are correct, although my requirements were from a business level perspective. I expect a more technical entity to granulate it a bit more before it reaches development.</font> <br>
<br><font face="sans-serif" size="2">But in general, yours are much better than mine ;-)</font> <br>
<div class="im"><br><font face="sans-serif" size="2">-Ory</font> <br><font face="sans-serif" size="2"> </font> <br><font face="Verdana" color="#82c0ff" size="1"><b>-------------------------------------------------------------</b></font><font face="Verdana" size="1"><b><br>
Ory Segal<br>Security Products Architect</b></font> <br><font face="Verdana" size="1"><b>AppScan Product Manager</b><br>Rational, Application Security<br>IBM Corporation<br>Tel: +972-9-962-9836<br>Mobile: +972-54-773-9359<br>
e-mail: </font><a href="mailto:segalory@il.ibm.com" target="_blank"><font face="Verdana" color="blue" size="1"><u>segalory@il.ibm.com</u></font></a><font face="Verdana" size="1"> </font><br><img src="cid:_1_0789F5300789F2F0002B5FBDC2257838"> <br>
<br><br><br></div><font face="sans-serif" color="#5f5f5f" size="1">From:        </font><font face="sans-serif" size="1">James Manico <<a href="mailto:jim@manico.net" target="_blank">jim@manico.net</a>></font> <br><font face="sans-serif" color="#5f5f5f" size="1">To:        </font><font face="sans-serif" size="1">Ory Segal/Haifa/IBM@IBMIL, "Vance, Michael" <<a href="mailto:Michael.Vance@salliemae.com" target="_blank">Michael.Vance@salliemae.com</a>></font> <br>

<div class="im"><font face="sans-serif" color="#5f5f5f" size="1">Cc:        </font><font face="sans-serif" size="1"><a href="mailto:websecurity@lists.webappsec.org" target="_blank">websecurity@lists.webappsec.org</a></font> <br>
</div><font face="sans-serif" color="#5f5f5f" size="1">Date:        </font><font face="sans-serif" size="1">15/02/2011 08:22 AM</font> <br><font face="sans-serif" color="#5f5f5f" size="1">Subject:        </font><font face="sans-serif" size="1">RE: [WEB SECURITY] Great article outlining a core issue with many in the security community</font> <br>

<hr noshade>

<div>
<div></div>
<div class="h5"><br><br><br><font face="Tahoma" color="#004080" size="2"><b>></b></font><font face="Times New Roman" color="#004080" size="3"> </font><font face="Courier New" size="2">our 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><font face="Times New Roman" size="3"> <br>
</font><br><font face="Calibri" color="#004080" size="2">This is not prescriptive enough, IMO.  The following requirement:</font> <br><font face="Calibri" color="#004080" size="2"> </font> <br><font face="Calibri" color="#004080" size="2">> </font><font face="Courier New" size="2">the system should protect from horizontal privilege escalation</font> <br>
<font face="Courier New" size="2"> </font> <br><font face="Calibri" color="#004080" size="2">..only leaves a developer scratching their heads. I would enhance this to require something along the lines of:</font> <br><font face="Calibri" color="#004080" size="2"> </font> <br>
<font face="Calibri" color="#004080" size="2">1)      Use a centralized data contextual access control methodology which restricts users from modifying or viewing data of users with the same role.</font> <br><font face="Calibri" color="#004080" size="2">2)      Use a centralized authority and a deny-by-default mechanism so that new features must be configured before being exposed</font> <br>
<font face="Calibri" color="#004080" size="2">3)      Hard-code ACTIVITIES in code instead of ROLES so that policy can be changed in real-time without requiring code changes and re-deployment</font> <br><font face="Calibri" color="#004080" size="2"> </font> <br>
<font face="Calibri" color="#004080" size="2">> </font><font face="Courier New" size="2">"All attempts to read/write from the database should be validated against SQL Injection to avoid data corruption or leakage", etc.</font> <br>
<font face="Courier New" size="2"> </font> <br><font face="Calibri" color="#004080" size="2">This is not an accurate requirement (and is quite dangerous, actually). I would require something along the lines of</font> <br>
<font face="Calibri" color="#004080" size="2"> </font> <br><font face="Calibri" color="#004080" size="2">1)      Use parameterized queries and data binding to prevent SQL injection (both in code and within stored procedures).</font> <br>
<font face="Calibri" color="#004080" size="2">2)      When parameterized queries hurt performance, use escaping of each individual untrusted variable</font> <br><font face="Calibri" color="#004080" size="2"> </font> <br><font face="Times New Roman" color="#004080" size="3">> </font><font face="Courier New" size="2">These high level requirements, can then be fulfilled by your developers, using the tools they have - secure coding best practices.</font><font face="Times New Roman" size="3"> <br>
</font><br><font face="Calibri" color="#004080" size="2">But this is part of the problem. Requirement from security folks are often inaccurate or “high level”. We need to get clear and prescriptive. I think the best bet is collaboration between a security architect and a developer-centric architect to build prescriptive requirements.</font> <br>
<font face="Times New Roman" color="#004080" size="3"><br>- Jim</font><font face="Times New Roman" size="3"><br></font><font face="Courier New" size="2"><br>>  </font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>
> 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><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>>  </font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>
> 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><font face="Times New Roman" size="3"> <br></font><font face="Courier New" size="2"><br>
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><font face="Times New Roman" size="3"> <br>
<br></font><font face="Courier New" size="2"><br>>  </font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>> 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><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>>  </font><font face="Times New Roman" size="3"> <br></font><font face="Courier New" size="2"><br>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><font face="Times New Roman" size="3"> <br>
<br></font><font face="Courier New" size="2"><br>> 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><font face="Times New Roman" size="3"> <br></font><font face="Courier New" size="2"><br>
I totally agree. </font><font face="Times New Roman" size="3"><br></font><font face="Courier New" size="2"><br>>  </font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>> -Michael</font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>
>  </font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>> From: </font><a href="mailto:websecurity-bounces@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>websecurity-bounces@lists.webappsec.org</u></font></a><font face="Courier New" size="2"> [</font><a href="mailto:websecurity-" target="_blank"><font face="Courier New" color="blue" size="2"><u>mailto:websecurity-</u></font></a><font face="Courier New" size="2"><br>
> </font><a href="mailto:bounces@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>bounces@lists.webappsec.org</u></font></a><font face="Courier New" size="2">] On Behalf Of Ory Segal<br>
> Sent: Monday, February 14, 2011 2:22 AM<br>> To: </font><a href="mailto:robert@webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>robert@webappsec.org</u></font></a><font face="Courier New" size="2"><br>
> Cc: </font><a href="mailto:websecurity@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>websecurity@lists.webappsec.org</u></font></a><font face="Courier New" size="2">; </font><a href="mailto:websecurity-bounces@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>websecurity-bounces@lists.webappsec.org</u></font></a><font face="Courier New" size="2"><br>
> Subject: Re: [WEB SECURITY] Great article outlining a core issue <br>> with many in the security community</font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>>  </font><font face="Times New Roman" size="3"> </font><font face="Courier New" size="2"><br>
> 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: </font><a href="mailto:segalory@il.ibm.com" target="_blank"><font face="Courier New" color="blue" size="2"><u>segalory@il.ibm.com</u></font></a><font face="Courier New" size="2"> <br>
> [image removed] <br>> <br>> <br>> <br>> From:        </font><a href="mailto:robert@webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>robert@webappsec.org</u></font></a><font face="Courier New" size="2"> <br>
> To:        </font><a href="mailto:websecurity@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>websecurity@lists.webappsec.org</u></font></a><font face="Courier New" size="2"> <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:        </font><a href="mailto:websecurity-bounces@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>websecurity-bounces@lists.webappsec.org</u></font></a><font face="Courier New" size="2"> <br>
> <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><a href="http://appsandsecurity.blogspot.com/2011/02/security-people-vs-developers.html" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://appsandsecurity.blogspot.com/2011/02/security-people-vs-developers.html</u></font></a><font face="Courier New" size="2"><br>
> <br>> Regards,<br>> - Robert Auger<br>> WASC Co Founder/Moderator of The Web Security Mailing List<br>> </font><a href="http://www.qasec.com/" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://www.qasec.com/</u></font></a><font face="Courier New" size="2"><br>
> </font><a href="http://www.webappsec.org/" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://www.webappsec.org/</u></font></a><font face="Courier New" size="2"><br>> <br>> <br>> _______________________________________________<br>
> The Web Security Mailing List<br>> <br>> WebSecurity RSS Feed<br>> </font><a href="http://www.webappsec.org/rss/websecurity.rss" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://www.webappsec.org/rss/websecurity.rss</u></font></a><font face="Courier New" size="2"><br>
> <br>> Join WASC on LinkedIn </font><a href="http://www.linkedin.com/e/gis/83336/4B20E4374DBA" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://www.linkedin.com/e/gis/83336/4B20E4374DBA</u></font></a><font face="Courier New" size="2"><br>
> <br>> WASC on Twitter<br>> </font><a href="http://twitter.com/wascupdates" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://twitter.com/wascupdates</u></font></a><font face="Courier New" size="2"><br>
> <br>> </font><a href="mailto:websecurity@lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>websecurity@lists.webappsec.org</u></font></a><font face="Courier New" size="2"><br>> </font><a href="http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org" target="_blank"><font face="Courier New" color="blue" size="2"><u>http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org</u></font></a><font face="Courier New" size="2"><br>
> <br>> <br>> This E-Mail has been scanned for viruses.</font> <br></div></div><br>_______________________________________________<br>The Web Security Mailing List<br><br>WebSecurity RSS Feed<br><a href="http://www.webappsec.org/rss/websecurity.rss" target="_blank">http://www.webappsec.org/rss/websecurity.rss</a><br>
<br>Join WASC on LinkedIn <a href="http://www.linkedin.com/e/gis/83336/4B20E4374DBA" target="_blank">http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br><br>WASC on Twitter<br><a href="http://twitter.com/wascupdates" target="_blank">http://twitter.com/wascupdates</a><br>
<br><a href="mailto:websecurity@lists.webappsec.org">websecurity@lists.webappsec.org</a><br><a href="http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org" target="_blank">http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org</a><br>
<br></blockquote></div><br>