Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

Just got a more permanant link (http://www.virtualteched.com/Videos/EU_DanGriffinMichaelHoward_WB.asx) to my shorter interview with Mike Howard at TechEd/Developers/Barcelona a week or so ago.  I say "shorter" because there was a longer version, as well as one that I taped solo earlier in the week, that should be posted to the above site in the next few months.

Wanted to leave a few follow-up points to what was discussed in that interview:

I actually had a few interesting discussions in Barcelona about addressing various application lifecycle pain points via integration with Visual Studio (specifically the Team System SKU, for the most part).  These discussions took place with folks in- and outside of Microsoft.  Because of my background, my bias is toward solving the security needs faced by application developers. 

The Fuzz Testing sample I did for MSDN Magazine is indeed representative of the opportunities available for security-aware integrators and service providers right now.  In other words, if your business is in working with developers in the Windows environment, and it centers around some external tool and/or process, consider integrating it into Visual Studio.  Security testing and all that entails (static code analysis, pentesting, fuzzing, run-time analysis) is ripe for this kind of integration.  The point is - your customers already know a given interface, and its one into which Microsoft continues to make big investments, so why not ride that wave?

Here’s the thing I didn’t mention in the interview, though.  From the perspective of the industry overall, and specifically all of the lines-of-business (LOB) and ISV devs out there, security testing isn’t the real problem.  The real problem - the Big Gap - is in integrating any sort of end-to-end security development best-practices into whatever methodology is currently in use. 

Microsoft’s Security Develpment Lifecycle is a notable example is something which has tremendous value, and yet has gained very little traction among the groups I mentioned above.

The problem is twofold:  one, everybody’s process is slightly different.  And two, accomplishing that sort of process integration requires the tender loving care of someone who not only really understands security, but is willing to invest the time and energy into understanding and adapting to a team’s existing process. Okay, there’s a third reason as well, but it’s more minor:  Microsoft has neglected thus far to integrate SDL into their own commercial lifecycle tools.  Why doesn’t Team Foundation Server force me to be aware of security best practices?

So, right now, the burden for addressing this SDL Gap should be borne by the methodology and application lifecycle management consultants.  I use the term consultant in an all-encompassing way - that applies to internal as well as external methodology experts.  My point is this - if you’re training devs, project managers, or testers on Agile, have you incorporated security best practices into all phases?  If so, please let me know, because you’re a hero and I want everyone to know your name. 

At this point, marrying the S(ecurity)DL (any of them; Microsoft’s is just one example) with the S(oftware)DL (again, any of the methodologies) seems like mainly a business opportunity for service providers:  there’s a good body of reusable knowledge, but it’s tough to learn initially, constantly evolving, and its application varies each time.  Still, there’s a productization opportunity here as well - integrate S(ecurity)DL into the workflow, whatever toolset is in use.
Permalink |

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment