RSnake and I were talking about this the other day as one of the problems in the webappsec industry. Over the years I’ve spoken at well over 100 events including ISSA, ISACA, Black Hat, AppSec, InfoSec, SANS, CSI, and probably more OWASP chapters than anyone. Saying 10% of infosec conference audiences are developers would be a generous estimate. The vast majority is part of IT Security in one form or another. For some reason though IT Security people expect developers to come to us and be shown the light, perhaps it should be the other way around. In fact, I’m sure of it.
Back in May Joe Walker and I co-presented at JavaOne (as we did the year before at the Ajax Experience). He’s plays the part of the well-known developer bringing in the well-known infosec guy. Over 1,000 people maxed out the ballroom, so clearly “security” is a draw at developer conferences. We covered XSS, CSRF, SQL Injection, and offered some live demos. We showed what an attacker could do to their beloved code should some basic precautions not be taken and discussed the value of security inside the SDLC. Judging from the feedback - they loved it. Demos rule, no question. I think I reached more developers and made a more positive impact on that group that day than in all the shows since the Ajax Experience.
Here’s what I’ve learned: Tailor your subject matter and talking points to your audience. OK, you already knew that. From my experience IT Security is most interested in learning about the latest and greatest threats, statistical trends, and what they’re peers did to solve a particular problem. So that's what I focus on during those events. Preaching security in the SDLC is just “OK”, but not terribly sexy to this audience. This is why you hardly see any code security talks at the infosec conferences, much the dismay of Andrew van der Stock. Developers and developer conferences are much interested in “application security”, but it has to be presented in the proper context to keep it interesting. Getting a handle on the right flow, format, and level of sophistication is the hard part. Seems they want to cover more browser extension and Google Gears related stuff now.
18 comments:
As a developer who has worked for years with Security professionals, I have to say that you've hit the nail on the head. We're very interested in HOW to make our applications more secure, but not at all interested in Security tech trends, statistics and the like.
Thanks for sharing. Clearly we're going to have to bring the two worlds in some way. I think I'd like to see security tracks show up at more developer conferences, rather than trying to get developers to show up to security conferences where they have they'd have to weed through 98% of the stuff their not interested in.
I have recently attended the OWASP top 10 talk at Houston OWASP, along your lines, with all examples from .NET. 40% developers in the audience, which was greeted with relief by the presenter. Do companies like to train their developers in security?
Sure, they like to train they're developers in security, but can't send them to security conferences to do that. They'd rather send them to developer conferences or bring the training in house.
I completely agree! I work for a large corporation and we have to constantly go out to our developers and educate them. If we don't, we end up with more vulnerable code to evaluate when it comes time. That is why we are developing a Secure SDLC to integrate into the current SDLC being used by the company. We also do mandatory security training for all developers AND their management.
We really have seen an improvement over time. I just hope it continues.
Agreeing with the previous few posts. I think the best thing a development shop or enterprise can to is bring the security talks on the home campus. It makes the topic much more available to the developers where they may have a hard time getting away from the office to do a week long conference where the majority of the topics will not even apply to them. Lead developers and architects may not even have the option to get away because they are so integrated into their projects and timelines.
Just as import is training management that security is important and giving them some shock and awe examples to drive the points home. If management does not see the importance then the developers will never be able too.
I too work for a fortune 500 company and this approach has worked very well for us. Its fun to see management's reaction when the lights finally come on! We are currently targeting marketing for the next round of security training =).
Also, when the conferences are in Dubai or New Zealand or New Delhi or Paris, most of us don't even bother asking corporate for permission to fund our overseas trip.
I couldn't agree more Jeremiah. I spoke this year about application security at a Dev conference here in Ireland.
The talk went down very well, getting one of the best turnouts of the conference.
Hopefully we can bring the two communities a bit closer together!
This is a really interesting post as I had a really similar conversation with some people at the OWASP AppSec conference in Australia earlier this year. I think the theme of the conversation was along that lines that "most of the people at this event *get* it... the problem is that the people who should be here aren't".
Dan/David/Christian, and then we're left to answer the next logical question. How best to reach and get to those that don't "get it" in a mass way? Perhaps we should start offering to coordinate entire application security tracks at developer conferences? The conference organizers might welcome the assistance with topics their not familiar with or the expert speakers in the space.
Jeremiah, Yep. I think that getting these sorts of topics/streams into traditional developer-land conferences is a really good idea. I'm also not entirely sure what the state of play is for software security units/courses getting included in standard curriculum for software engineering/computer science degrees, but I think this is also a really good idea. I can't think of a good excuse for anyone graduating with a degree in computer/software development to develop insecurely, especially as they focus so much on software development lifecycles.
I think thats not a bad idea, having a security track at dev conferences may go along way towards reaching the masses!
I also agree with Christian, until security is embedded into Computer Science (and similar) degrees it will be hard to achieve that "buy in".
I know at least Stanford has an "Advanced Computer Security" certification program now run by Neil Daswani, PhD.
http://scpd.stanford.edu/advancedsecurity/
If the model/format proves successful, perhaps it can be shared and rolled out elswhere.
Of course developers have to know security, but my own experience is that developers and managers are too busy following the latest trends, like Extreme Programming, Design Patterns, the latest platforms, languages.
Now a counterpoint.
Microsoft famously ground to a halt and got all their developers and managers indoctrinated in security.
What did we get after that? Vista. WORST. OS. EVER.
Just adding more grist for the discussion mill.
Security is not that tough of a programming problem considering the difficult engineering tasks that web 2.0 programmers are faced with already.
Why should developers "focus" on security when the latest and greatest programming techniques are more appropo for their jobs?
Security is not functionality, it's very difficult to "prove" and the industry is flooded with half-truths and shills who will sell their soul in support of useless "appsec" products.
Let's give developers straight forward training (lets skip the cool new tricks when teaching developers and stick to the basics of defense and good security architecture ).
Let's give developers easy use API's ( Go ESAPI! ).
Let's continue to provide straight-forward pen-test guides and training to enhance assessment activities.
Let's stop focusing on cool new attacks tricks so we can get a little limelight to support our shilling for some useless, expensive, band-aid product.
In summary: developer education, easy to use enterprise class security API's, fine tuning of assessment activities. That's how you reach developers. Expecting them to attend our fud-filled vendor-gauntlet conferences is crazy.
The best way for developers to learn security is for the security folks to teach them anonymously. Embrace the notion of the security bandit...
http://www.owasp.org/index.php/Hartford
Hey Jim: As you basically said, the best practices, tools, processes, and teaching methods are out there (I would still submit that "webapp security is not that simple though). What I'm putting forth are my experiences in that the best way to reach developers about security is not through "security" conferences - yet we still whine about it.
Instead we should be offering and engaging security talks/tracks on whatever the topic at the developer conferences instead. They would then see security as a basic part of their job, essentially what we want to happen. Once we find the right vehicle we can perfect the strategy the makes the most impact content wise, and the developers themselves will tell us what that is.
I see I'm late to the party again, it figures...oh well, I'll share my .02.
I think one of the major problems with the security of software, is security is generally considered "outside" the development process. You have your requirements phase, which is where you'll define the functional, non-functional, business requirements, use cases, etc. But more often then not, security is never mentioned within the scope of those requirements. You won't find security mentioned in any books on requirements gathering, even Karl Weigers "Software Requirements", which every developer should read, doesn't mention anything about gathering security requirements. Software development process books, such as "Code Complete" by Steve McConnell, don't mention security as part of the development process. The requirements and development process has always been focused on ensuring the functionality of the application. Security has always been an afterthought; something that can be addressed in the next version. What needs to occur is for the software development purists and the appsec purists to come together and redefine the SDLC to ensure security is a core part of the development lifecycle. Sure certain companies are touting the benefits of their implementations of the SDC, but it obviously hasn't caught on yet.
Post a Comment