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" <shad...@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 _______________________________________________
