[Owasp-leaders] Password Reuse Attacks

Thu Jun 23 17:38:28 UTC 2016

All,

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

1, Appoint a CISO w/board level visibility
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.

2, Don't starve security
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)

3, Compliance is not security
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)

4, Security is a way of life not a band-aid
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.

5, You trained to be an engineer, don't forsake your training
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)

(you insert your ideas here 6-9)

10, Educate, educate, educate
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)

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.

Regards,
Milton

On 23 Jun 2016, at 9:41, Michael Coates wrote:

> Leaders,
>
> I just sent a related note to the top 10 list, but thought it was 
> warranted
> for discussion here too.
>
> I feel like we have a major gap in our discussion of application 
> risks.
> Specifically we think about implementation bugs and often forget 
> design
> flaws.
>
> The main example here is password reuse attacks. From my vantage point 
> in
> my day job (and just watching the news of my peers) this is a major 
> concern.
>
> Here are 3 recent stories on this issue
> http://www.csoonline.com/article/3086942/security/linkedin-data-breach-blamed-for-multiple-secondary-compromises.html
> http://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/
> https://blog.twitter.com/2011/keeping-your-account-safe
>
> What do others think? Is this getting the focus, discussion and 
> attention
> it deserves? Are you talking about it at your companies or with your
> clients?
>
>
> Quick note on the technical side of the password reuse attack
>
>    - With password reuse attacks a breach anywhere on the web can mean 
> a
>    breach of millions of users who reuse passwords
>    - These attacks are always done with automation 100million breached 
> in
>    site A with a reusue rate on site B of 1% means 1million breached 
> on site B
>    - There aren't "easy" answers here - The attacks always come from a
>    variety of IP addresses. Rate limiting isn't effective because it's 
> 1
>    attempt per account from a new ip
>    - You have to rely on additional authentication information or
>    anti-automation (tradeoffs to both)
>    - Making this a "user problem" and walking away is not realistic
>
>
>
> --
> Michael Coates | @_mwc 
> <https://twitter.com/intent/user?screen_name=_mwc>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders