Security Symposium @ the PDC

I’ve been meaning to write about this, but I’ve been a little busy of late.

On day 4 of the PDC (this Friday) we’re holding a Security Symposium.

The morning is 100% focused on the Security Development Lifecycle (SDL), including threat modeling (I’ll be presenting this material), risk assessement, fuzz testing and much MUCH more. Following the SDL material is a panel discussion MC’d by yours truly (!) the panel will include:

  • Steve Lipner, Director Security Eng Strategy, Microsoft
  • David Litchfield, Managing Director and Founder, Next Generation Security Software Ltd (NGSSoftware)
  • David Palmer, Head of Information Security Risk Management, WestPac
  • Greg Elkins, Consulting Systems Engineer, LexisNexis

Oh, we’re giving away copies of “19 Deadly Sins of Software Security” to all symposium attendees.

So see you there – please stop by and say ‘hi!’ and learn a thing or three about improving your software development processes to accomodate better security.

And if you really want, I’ll sign your book (it adds $0.34 to the book value, but hey! 😉

Comments (1)

  1. Back in July I posted that I couldn’t wait to get my hands on a copy of "The 19 Deadly Sins of Software Security". The authors (Michael Howard, David LeBlanc and John Viega) have contributed to some of my favorite writings, and I just knew it had to be a good book. It might be because I have read so many of their other books, that I didn’t find this book as appealing to me. That’s right, I didn’t really enjoy this one. I am guessing its because I was spoiled by already reading Writing Secure Code, Secure Programming Cookbook, Building Secure Software etc. that I just didn’t feel I got as much out of the book as I wanted. More importantly, I think the guys missed a great opportunity. The format was excellent: Overview of each Sin Show which languages are effected Explain the Sin Show the Sin in various langauges Show how to spot the Sin pattern during code review Show testing techniques to find the Sin (when possible) Show real world examples of the Sin Show redemption steps But while the format was great and to the point (which made for a more streamlined read) it was the last step that I was expecting more out of. Especially since "…and How to Fix Them" was in the title. This was the best place to REALLY show how to fix sinful code. As an example, in the Integer Overflow Sin they go into detail to show how a senior developer with lots of experience had a function checking for an overflow that was flawed. Near the end of the page they even show how to fix it. What they could have done was bring it full circle and rewrite the function showing the right way to do it, and then providing the "correct code" in the various languages. I was expecting that throughout the book, to no avail. This is what I think is missing in all these books. I want a SHORT book I can give to a new developer joining the team so they can see how to write safe code correctly, even to the point they can almost cut-and-paste some of these techniques into their own code. For a new developer coming in to secure software programming, I am not sure that this is the right book for them. It misses the background to explain WHY its such a problem. Writing Secure Code and Building Secure Systems were two books I rather enjoyed because of all the back story about it. And that made for a more enjoyable technical read of those books. However,I just felt this book was too dry as they tried to balance depth with bredth in 270 pages. With that said, I think this would be a PERFECT book for a developer who wants a quick and dirty understanding of the Sins and how to fix them without really understanding WHY, and how deep the risks can go. More importantly, I think this is a good intro for code auditors and whitebox testers who don’t have to have as much coding experience to know what to look for (at least in a first pass) I am assuming that if I hadn’t read the other books that I might have more enjoyed this one. It is jammed full of good technical information, but just didn’t "turn my crank" so to speak compared to their other works. If you have read the other books, I am not sure how much more you would gain from this one. What WOULD be interesting is if someone new to this read this book first and THEN read the other ones. I would bet it would be an eye opening experience as you dug deeper into "Alice’s hole"… so to speak….