Hi Chris, Thanks for answering my email. There's one thing that I actually believe you people are not following here. Blackhat is a conference to present cutting-edge NEW offensive technologies, methodologies, techniques, etc. It is *not* about talking things there were already presented and talk about, for that there are other conferences with that specific purpose, maybe you are not aware of those. You should google a little bit. Search for: "security conferences google calendar" and you'll have a good panorama of conferences, check the schedules and you'll see there are conferences that cover pretty much all the topics.
I understand that a lot of developers and project managers are willing to have technically *good* conferences focused on defense at all levels, but from there to propose Blackhat to become such a thing is 100% plain wrong. Probably a new conference should be created to satisfied the niche you are mentioning. Then if people who is technically capable are willing to present the material they usually use to give trainings to their customers, then that's another story. >> 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. If you read the following six book you'll have probably more than you might actually need (actually with the first 5): The Security Development Lifecycle: http://www.amazon.com/Security-Development-Lifecycle-Michael-Howard/dp/0735622140/ref=sr_1_1?s=books&ie=UTF8&qid=1314826912&sr=1-1 Threat Modeling: http://www.amazon.com/Threat-Modeling-Microsoft-Professional-Swiderski/dp/0735619913/ref=sr_1_1?s=books&ie=UTF8&qid=1314826965&sr=1-1 Writing Secure Code, Second Edition: http://www.amazon.com/Writing-Secure-Second-Michael-Howard/dp/0735617228/ref=sr_1_3?s=books&ie=UTF8&qid=1314826965&sr=1-3 Code Complete: A Practical Handbook of Software Construction: http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670 The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities: http://www.amazon.com/Art-Software-Security-Assessment-Vulnerabilities/dp/0321444426/ref=sr_1_1?s=books&ie=UTF8&qid=1314826625&sr=1-1 Hunting Security Bugs: http://www.amazon.com/Hunting-Security-Bugs-Tom-Gallagher/dp/073562187X/ref=sr_1_2?s=books&ie=UTF8&qid=1314826641&sr=1-2 > 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. I've read your blog and I understand your frustration. I know a buch of people who are great in both areas, and they work actively in the SDL process for big companies. I believe if a conference to present this kind of presentations is created they would be interested in doing some presentations there. Actually I would do a couple as well. But once the life time of such a conference technically is short, because once you've presented what has to be done, then the rest is up to the people who develop the software. New tool, yes there will always be new tool, as well there will always be people willing to talk. But for professionals once the message is transmitted there are two options or the developers understood or they need to get a training to understand. Also there it is the responsibility of the companies to train their people to make better products, big companies do that all the time and also even create internal conferences so that their developers get aware of what can go wrong. > 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. That's because there are crappy books all over the place. And professors who shouldn't be 'teaching' anymore unless they actualize their education material to the time they are living at. Are they teaching. GWBasic? NO, they are just teaching wrong. Thanks not my problem. It is an education problem, and we could discuss ages about this, because the even all the education models that I know of are fundamentally broken. > 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. Check the books I've mention you at the beginning of this email. About Tomcat, specific .Net libraries, etc you have to read not developer books, but security books that cover those specific topics. Also there are many online material that cover those topics. Developers instead of searching for pieces of sample code to use (read: steal from others), should also care about what they are doing. The people who would go to the kind of conference you are trying to promote here are people who care about security, and these individuals usually do their homework. >> 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. I've seen the same thing, and I've also seen developers who where trained really well and do a great job. Auditing their code is great, and finding flaws is very difficult. Most of the time Legacy code is a major problem. Anyways, now a days if a software architect doesn't have a GOOD threat model of their products components and doesn't follow an SDL process, then that's not good engineering anymore. >> 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. This is simple, there are people specialized in one thing or another, few people has the 'desire' and/or 'passion' for both. That's life, and that's the reason why exist security people and developers. If a guy doesn't know what SQL injection or XSS is, he/she shouldn't be developing software at all, period. If you don't know how to drive a car, you are dangerous on the street, and that's why you are not allow to drive. > Only by bringing the builders and the breakers together and getting them > involved in > the other side will we begin to see changes. That's what Microsoft and other companies are doing, and the reason why they are improving. > Blackhat is a *perfect* opportunity to do this. To have the opportunity to present stuff that is already known???, no it is not the right place. Create a new conference, but please don't destroy with crappy presentation one which is good. Or ask blackhat to make 'trainning' for that, that is the right place, but not the briefings. > Where else are there thousands of security > professionals who are great at breaking sorry to be to let you know this, but there are *no* thousands of security *professionals* who are *great* at breaking stuff at blackhat. Yes there are Thousands, but most of them have no idea, they *think* they do, they want to *pretend* they do, but they don't. > 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. the few who are actually good, already know this because their job is working together with the product teams of the biggest software companies on the planet. > 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. Unfortunately that's not gonna happen, you need good developers for that. Now a days it seems and anyone how did his first 'hello world' or graduated from university consider themselves good developers. Good developers are not that easy to find, that's why software development companies are always hiring. Also good developers are not cheap either. Shitty developers == shitty products. > Products don't fix software problems we agree on that one :) > - and we can all agree that the application is the attack surface that > everyone should be focusing on right now I think. The application _exposes_ an attack surface. Good designs decrease the attack surface a lot, good software engineering prevent developers from using insecure API, and good defense in-depth make that attack surface extremely difficult to exploit. >> 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! Sure, each conference has a different focus and people go to conferences depending on their interest. > We want developers to come to blackhat no, YOU want developers to come to blackhat. You and others who share the same wish as you do, should request at development conferences to invite the best professionals to go and do presentations about secure development sessions for developers. Blackhat is conference for security people. They should add more training focus on Secure Development and Design, SDL, etc, but not bring known topics to the briefings. Although I still believe that a new conference to cover exactly that topic should be created, and I'm sorry if that is outside of US. > There is a very negative stigma between security pros and developers. that happens on companies which don't care about security and crappy developers who don't want to be pointed when they did a mistake. That's why I love working with good customers, because they have great and professional development teams. > 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. that's *exactly* what happens with companies which care about doing quality products and not just focus on developing and selling crap. I'm so glad I work only with good companies. > 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… As I said before, XSS and SQLi are so basic, things which require -10 of technical skills, if someone don't know about both should be developing software. As well as security "professionals" who don't know anything beyond XSS and SQLi, should stop calling themselves 'professionals'. > 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. I do agree that there should be more security awareness on Development Conferences, as well as good trainings. That's where it would fit best. Or create a new Con that covers Secure Development topics only. regards, Sergio > > </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 _______________________________________________
