New York City considers plan to bring fiber to public housing residents: Wireless networks are definitely out in the recommendations of a private consultant to the city's Broadband Advisory Committee, ComputerWorld reports. They may opt to use $4m in a fund from Verizon and a potential $8m from the two incumbent cable operators.

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.

With our most recent update to the SDL at Microsoft we’ve made one significant change to try and help in this scenario. That change is to take all of the SDL requirements and plug them into a filterable framework that allows a person or a team to match requirements with specific technologies. Now, instead of being presented with a large document that covers all SDL requirements, a team is presented with a dynamic Web site that allows them to selectively filter requirements based on their product type (Client, Server, Hardware, Online Service etc), code type (Native, Managed, JavaScript etc), platform type (Win32, Win64, WinCE, Mac etc), or applies to their specific role (Program Manager, Developer, Test Engineer, Operations, etc).

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.