After nearly 7 years in Product Support Services helping our customers on issues ranging from debugging IIS failures, to identifying performance issues to helping customers with security investigations I have taken on a new challenge and accepted a job in the Security Business and Technology Unit working for the SWI team (Secure Windows Initiative).
My career at Microsoft initially had me working reactively with customers at a 1:1 level and while it was immensely satisfying and a great learning experience – near the end I had an intense desire to reach more people and to scale out so to speak. This is largely what made me turn to blogging.
As a member of the SWI team, I feel I will be getting that opportunity (although indirectly) as I will be working closely with the MSRC during the security bulletin development process. Specifically, I’ll be helping them identify possible workarounds to security vulnerabilities so that they can be tested, verified and documented in the bulletins by the time they go live so that our customers can use them (if necessary) until the security updates can be applied.
This is definitely a change in focus for me, but I’m incredibly excited about it. However, as you can see I can, unfortunately, no longer really blog about Windows incident response topics with any sort of authoritative first-hand knowledge since I will no longer be helping to develop new incident response techniques or be doing incident response as my primary job. I’ve asked the PSS Security team not to give up on blogging and my hope is that they will create a team blog that all members can use to pick up where I am leaving off – if this happens – I will post the details and a referral URL here.
Going forward I am going to repurpose my blog and use it to talk about one of the most fascinating teams in Microsoft – the Secure Windows Initiative team. This team is responsible for one of the most important policies we have ever enforced – the Security Development Lifecycle – the development process by which all new products must go through. But what’s really interesting is that this is the team within Microsoft that just about no one (externally) has heard about – yet they have some pretty unbelievably important tasks.
We have recently published a very lengthy and a surprisingly in-depth look into how we have been developing software over the last few years (although it is a process designed to be continually improved and thus this process has evolved since its conception).
Maintaining and enforcing the SDL is one of the core tasks of the SWI team, so without further adieu I give to you the SDL: