Re: informIT: Building versus Breaking

[Chris Schmidt <chrisisbeef () gmail com>]

I agree on the terminology of whitehat vs. blackhat here Sergio, but in
almost every other regard I disagree completely.

> To design and build proper software and hardware there are a lot of
> conferences out there, as well as trainings and a huge amount of literature.
> There are very good books when it comes to secure software development.

This is 100% false and misleading. Yes, there are great security tools out
there, and yes there are great development conferences - however, the two
*rarely* if *ever* intermingle. See my blog "Cross Pollination; It's not
just for Bees" ( 
http://yet-another-dev.blogspot.com/2010/11/cross-pollination-its-not-just-f
or-bees.html) for my thoughts on this subject in particular.

Additionally, students are taught how to write insecure code from the time
they write their first "Hello World" application. This topic has been
discussed a great many times and hasn't changed much. Go to your local
bookstore and pick up a java book, flip to the section on JDBC and tell me
that the first thing you learn to do is something other than build a dynamic
SQL statement with untrusted user input. Show me an MVC book that covers
proper contextual output encoding or building a Data Access Control policy.
Pick up a Tomcat Book and tell me where it says you should disable the
InvokerServlet. Pick up a .Net book and tell me where the chapter on using
AntiXSS is. I could go on and on, but I really don't think it is necessary.

> Every year what is presented, in the best security conferences, are new
> techniques that developers need to be aware of in order to build secure
> products. Most of the presentations talk about things that were wrongly
> designed and/or corner-cases which were not considered.

I think we can agree that the majority of flaws that get exploited are due
to improper or missing security controls. This is a fundamental flaw in
engineering software. I have sat with some of the best software architects
and looked at their architecture diagrams and specifications. I have seen
the missing controls, I have seen the specifications lacking or using
controls improperly. I have seen damn smart developers make really stupid
mistakes when trying to make security decisions in code simply because they
don't really understand what it means to write secure code.

> There are also a lot of tools and libraries which help development teams to do
> things right, specially libraries and templates like Microsoft Safeint as well
> as the safe APIs, which prevent developers from shooting themselves.
> They just need to use them. There are also managed languages, APIs to handle
> SQL securely, etc. It is just that a lot of developers don't use what is
> available to them.

See above statements.

> Blackhat is great as it is now, there are talks about new defense technologies
> from time to time too. Having more talks about defense would be use, in my
> opinion, to sale products than anything else. I don't believe it would do any
> good to Blackhat.

Again, I completely disagree. As a general rule, people that break software
know enough about engineering to be able to spot flaws in code - they don't
really *understand* terms like 'Agile' or 'Inversion of Control' and
conversely most developers may have heard of SQL Injection or Cross Site
Scripting but have *no* concept of the depth of the problems. Only by
bringing the builders and the breakers together and getting them involved in
the other side will we begin to see changes. Blackhat is a *perfect*
opportunity to do this. Where else are there thousands of security
professionals who are great at breaking stuff but not so good on
understanding what it really takes to build something - how to architect
software and systems - or the nuances of specific languages, libraries, and
development methodologies. Also the argument that this is what the vendor
area is for - complete and utter BS. You show me the magic box that takes
poorly written code in one side and spits out well architected and secure
code on the other and then we can talk. Products don't fix software problems
- and we can all agree that the application is the attack surface that
everyone should be focusing on right now I think.

> Blackhat IS about breaking stuff, the vendors area offers defense products and
> services to improve your security. For building stuff (as in development)
> there are other conferences out there. People go to Blackhat to be aware of
> what things might go wrong in order to protect better themselves. And even
> then many good talks overlap unfortunately.

Yes, Blackhat is absolutely about breaking stuff, this is a major part of
the problem. Developers generally don't go to Blackhat - they go to JavaOne.
How many talks are there at JavaOne on the latest 0-day in Spring or Struts.
How many speakers go to ApacheCon to talk about the vulnerabilities in
Cocoon or HTTPD? None! We want developers to come to blackhat and learn
about doing this - but there are very few, if any development managers that
will approve a budget to send his dev team to a conference that has
*nothing* to do with development. We want them to stick around at Defcon so
they can learn how to really break stuff and meet people in the community.
There is a very negative stigma between security pros and developers. We get
rid of that by bringing communities together and providing a venue for the
two groups to *really* work and learn together. We get devs interested in
writing secure code by showing them how to break it. I remember when I gave
a class to the QA and Dev staff at my old job on how to XSS and SQLi. You
should have seen their eyes light up when they got that alert to pop for the
first time or pulled back the entire contents of a db table. This is what
makes security "sexy" to developers; otherwise it is just more work...

In closing, let me say that while I don't agree with gem 100% - I think that
this is a step in the right direction. I think having a defensive track or
even just an engineering track at Blackhat would be huge. Not only would it
make the conference 10x as attractive to development managers, it gives the
security guys a chance to understand the other side of it. This is how we
effect change, by changing things - by not changing things, the only thing
we are doing is giving ourselves and the forensics guys just a little more
job security. I promise you, I would flip burgers for the rest of my life if
I felt confident that my credit card information was safe on the internet.

</rant>

~chris

On 8/31/11 12:01 PM, "Sergio 'shadown' Alvarez" <shadown () gmail com> wrote:

> Hi gem,
>
> I've read your article to see what direction you were willing to take, before
> jumping into the conversation. Your post was exactly what I thought you were
> heading to.
>
> I disagree with your thought for many reasons.
>
> But first I would like to use proper terms so that we don't misuse some
> vocabulary:
>
> You said: """Software security should be a balanced approach of offense and
> defense (white hat and black hat, if you will)"""
>
> Whitehat: reports what he/she has found. Network vulenerabilities, software
> security flaws, flawed crypto, design flaws, or whatever it is that the
> individual found it was broken or wrong.
>
> Blackhat: doesn't report what he/she found, because she/he want to keep it
> that way.
>
> Of course there are a lot of grays out there too.
>
> Defense isŠwell... defense.
>
> To design and build proper software and hardware there are a lot of
> conferences out there, as well as trainings and a huge amount of literature.
> There are very good books when it comes to secure software development.
>
> Every year what is presented, in the best security conferences, are new
> techniques that developers need to be aware of in order to build secure
> products. Most of the presentations talk about things that were wrongly
> designed and/or corner-cases which were not considered.
>
> There are also a lot of tools and libraries which help development teams to do
> things right, specially libraries and templates like Microsoft Safeint as well
> as the safe APIs, which prevent developers from shooting themselves.
> They just need to use them. There are also managed languages, APIs to handle
> SQL securely, etc. It is just that a lot of developers don't use what is
> available to them.
>
> Blackhat is great as it is now, there are talks about new defense technologies
> from time to time too. Having more talks about defense would be use, in my
> opinion, to sale products than anything else. I don't believe it would do any
> good to Blackhat.
>
> """I am not opposed to breaking stuff (see "Exploiting Software" from 2004),
> but I am worried about an overemphasis on breaking stuff."""
>
> Blackhat IS about breaking stuff, the vendors area offers defense products and
> services to improve your security. For building stuff (as in development)
> there are other conferences out there. People go to Blackhat to be aware of
> what things might go wrong in order to protect better themselves. And even
> then many good talks overlap unfortunately.
>
> Regards,
>   Sergio
>
> On Aug 31, 2011, at 4:16 PM, Gary McGraw wrote:
>
> > hi sc-l,
> >
> > I went to Blackhat for the first time ever this year (even though I am
> > basically allergic to Las Vegas), and it got me started thinking about
> > building things properly versus breaking things in our field.  Blackhat was
> > mostly about breaking stuff of course.  I am not opposed to breaking stuff
> > (see "Exploiting Software" from 2004), but I am worried about an overemphasis
> > on breaking stuff.
> >
> > After a quick and dirty blog entry on the subject
> > <http://www.cigital.com/justiceleague/2011/08/09/building-versus-breaking-a-w
> > hite-hat-goes-to-blackhat/>, I sat down and wrote a better article about it:
> >
> > Software [In]security: Balancing All the Breaking with some Building
> > http://www.informit.com/articles/article.aspx?p=1750195
> >
> > I've also had a chat with Adam Shostack (a member of the newly formed
> > Blackhat Advisors) about the possibility of adding some building content to
> > Blackhat.  Go Adam!
> >
> > Do you agree that Blackhat could do with some building content??
> >
> > gem
> >
> > company www.cigital.com
> > podcast www.cigital.com/silverbullet
> > blog www.cigital.com/justoceleague
> > book www.swsec.com
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L) SC-L () securecoding org
> > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
> > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> > as a free, non-commercial service to the software security community.
> > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> > _______________________________________________
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L () securecoding org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> _______________________________________________



_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________