Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi, Ralph Hood here. I should probably take a minute to introduce myself since this is my first official SDL blog post. I’ve been a program manager at Microsoft for almost nine years. In past roles at Microsoft I was the lead program manager for security response in the Windows Sustained Engineering group, and in my last role I was a project manager in the Microsoft Auto group that partnered with Ford Motor Company to create the SYNC device. I joined the Security Engineering and Communications group in early November of last year as a program manager on the SDL team. My primary responsibility on the SDL team is coordinating the internal update and change process for the SDL inside of Microsoft to ensure we are always looking at new processes and technologies to further enhance the benefits of the SDL.
In the Microsoft Auto group we spent a lot of time trying to figure out what the SDL meant to our product. We knew we needed to do threat modeling, primarily because threat modeling is probably the most commonly known requirement of the SDL. Beyond threat modeling though, members of the various disciplines in our product team didn’t know what parts of the SDL applied to our product and what parts applied to technologies, platforms, or programming languages we didn’t use and thus could safely ignore. One of our program managers set out to sift through the SDL requirements and associated tools to try and determine what was applicable to our environment. While we eventually made the right decisions on what SDL requirements we needed to focus upon, we spent more time than we would have liked trying to figure it all out.
This means if I’m a program manager for a Win64 Client product, I can view just the SDL requirements that apply to that criteria and the result is a clearer starting point for what you need to do to begin adopting the SDL for your project. This applicability filtering also allows product groups to more easily divide up the responsibility for ramping up on the SDL instead of overloading a single person in their group with figuring out what needs to be done. For instance, a product group could assign a person from each discipline in their team to identify which SDL requirements need to be met and at what point in the product cycle. A program manager can now more easily identify the SDL requirements that need to be thought about and met during the Requirements phase of a product, and likewise a test engineer can identify and begin working on the test collateral for SDL requirements that will be needed later in the schedule during the verification phase.
As the SDL continues to grow to address evolving security concerns and new technologies, it’s necessary for the SDL to be able to scale and have this type of filtering in place. Enhancing the functionality and depth of our tools that we use in the SDL is an ongoing process. These tools don’t always apply to every code type or product type. We have test tools that only run on native code while other tools run only against managed code, and that’s just one example. It’s important that we leverage a filterable framework like we have to address these differences and help teams understand where they need to focus their resources and what just doesn’t apply to their product or technology.
Hello everyone, Shawn Hernan here. I used to work on the SDL team, and I might have been a regular contributor