Really like this idea Milton. <div><br></div><div>The "top x lists" seem to be pithy and get people's attention. I wonder if this is a new list that's needed. Not sure the right name. </div><div><br></div><div>Top x</div><div>...Organizational commitments for secure software</div><div>...business decisions to drive secure software</div><div><br></div><div>Etc</div><div><br>On Thursday, June 23, 2016, Milton Smith <<a href="mailto:milton.smith@owasp.org">milton.smith@owasp.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
+1 for Michael.  There is too much focus on the vulns and not enough focus on avoiding writing crappy software.  We need a OWASP 10 list for secure product (or similar).  Focus on the positive, building great software.  Manico comes the closes with top 10 proactive controls.  However, even this focuses on -the code-.  We need code approaches but we also need something outside of a pure code focus.  Maybe a top 10 secure product list like,<br>
<br>
1, Appoint a CISO w/board level visibility<br>
You wouldn't dare diagnose your own medical condition.  What makes you think you can make good decisions in security?  Hire an appsec expert with proven experience in the appsec space with hands on coding experience - a must.  It's hard enough to change the minds of developers as it is.  If you don't have the code chops you will never gain respect.  Equally important you need exec that can frame technical security problems in terms of business risk to boards, smart business leaders, or the public/press, in a way they can understand and appreciate.  The bar is high.<br>
<br>
2, Don't starve security<br>
The quickest way to kill any security program is starvation.  To be good at anything takes investment in resources.  Security budget should be 15%+ of the overall IT budget when starting a program and taper off as the program mature.  Compliance is a separate budget.  (or whatever OWASP thinks the best trend is among successful companies)<br>
<br>
3, Compliance is not security<br>
The first words out of the Target CEO's mouth was that they passed their audit.  Compliances is what you must do.  Security is the love you show your customers over and above compliance requirements.  In fact, your security leader should not have compliance responsibilities since this is a conflict of interest.  The chief of compliance should report to the board as well.  (well, we should soften the message slightly but you understand my point.  ;o)<br>
<br>
4, Security is a way of life not a band-aid<br>
Poor security is more than a code problem - it's a software quality problem.  You would be shocked if a doctor didn't wash his hands before your surgery.  Security is the same.  Every person and process that contributes to the code of your solution is a part of the problem and also a part of the solution.  Security must be applied throughout the entire software development lifecycle.<br>
<br>
5, You trained to be an engineer, don't forsake your training<br>
Software development is a like train careening out of control at many companies.  Yes, work quickly, Agile, and be competitive in business but not so quickly you forsake your training and common sense.  Put the skills you were taught to use.  Many business are constantly commenting on success of companies like Google.  If you want to enjoy the type of success Google has at your company you must do the things Google does.  Start building better software, security will follow, and you will take your company to amazing places.  Invest in yourself you would be amazed what you can do!  (Imagine being an early Blizzard employee trying to convince investors World of Warcraft is a good idea.  Someone was able to do this and look at the level of success)<br>
<br>
(you insert your ideas here 6-9)<br>
<br>
10, Educate, educate, educate<br>
Each role at an organization involved in project creation, development, and delivery requires ongoing security training.  Training should be role appropriate.  Managers need security training also.  Security is always changing and requires constant education.  (I have taken some managers with me to BH/DEFCON and their views on security are not the same as well we started)<br>
<br>
Anyway, I'm not strong on all these points but raising them as ideas for your consideration.  I do think there are some concerns larger than coding.  Elevating attention in these areas could be helpful to industry.<br>
<br>
Regards,<br>
Milton<br>
<br>
<br>
On 23 Jun 2016, at 9:41, Michael Coates wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Leaders,<br>
<br>
I just sent a related note to the top 10 list, but thought it was warranted<br>
for discussion here too.<br>
<br>
I feel like we have a major gap in our discussion of application risks.<br>
Specifically we think about implementation bugs and often forget design<br>
flaws.<br>
<br>
The main example here is password reuse attacks. From my vantage point in<br>
my day job (and just watching the news of my peers) this is a major concern.<br>
<br>
Here are 3 recent stories on this issue<br>
<a href="http://www.csoonline.com/article/3086942/security/linkedin-data-breach-blamed-for-multiple-secondary-compromises.html" target="_blank">http://www.csoonline.com/article/3086942/security/linkedin-data-breach-blamed-for-multiple-secondary-compromises.html</a><br>
<a href="http://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/" target="_blank">http://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/</a><br>
<a href="https://blog.twitter.com/2011/keeping-your-account-safe" target="_blank">https://blog.twitter.com/2011/keeping-your-account-safe</a><br>
<br>
What do others think? Is this getting the focus, discussion and attention<br>
it deserves? Are you talking about it at your companies or with your<br>
clients?<br>
<br>
<br>
Quick note on the technical side of the password reuse attack<br>
<br>
   - With password reuse attacks a breach anywhere on the web can mean a<br>
   breach of millions of users who reuse passwords<br>
   - These attacks are always done with automation 100million breached in<br>
   site A with a reusue rate on site B of 1% means 1million breached on site B<br>
   - There aren't "easy" answers here - The attacks always come from a<br>
   variety of IP addresses. Rate limiting isn't effective because it's 1<br>
   attempt per account from a new ip<br>
   - You have to rely on additional authentication information or<br>
   anti-automation (tradeoffs to both)<br>
   - Making this a "user problem" and walking away is not realistic<br>
<br>
<br>
<br>
--<br>
Michael Coates | @_mwc <<a href="https://twitter.com/intent/user?screen_name=_mwc" target="_blank">https://twitter.com/intent/user?screen_name=_mwc</a>><br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a>OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</blockquote>
</blockquote></div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br>--<br>Michael Coates | <a href="https://twitter.com/intent/user?screen_name=_mwc" target="_blank">@_mwc</a><br></div><div>OWASP Global Board<br></div><div dir="ltr"><div><br></div><div><br></div><div><br><br></div></div></div></div></div></div></div><br>