The Information Security Tools (IST) team has released the InfoSec Assessment & Protection (A&P) Suite. It’s a suite made up of protection and assessment tools which include:
Read more about the A&P suite here and watch the podcast, “Assessment and Protection Suite,” as Anil Revuru (RV) and Mark Curphey from Microsoft IST team discuss the future of this suite of tools.
To download these tools for free, you will need to register on the Connect site. Once you’ve registered, you can download the tools below directly. Get the latest on the A&P Suite on the IST Blog.
Download, A&P Suite will include:
Hi everyone, Bryan here. There is a common misconception that because the SDL was originally created for Microsoft’s big showcase box products like Windows and SQL Server, that it only works for those kinds of products. This is of course patently false: virtually every Microsoft product and online service, large or small, follows the SDL. Many other organizations outside of Microsoft are also successfully implementing the SDL. However, while the content of the SDL – its requirements and recommendations – may be universal, the structure of the SDL as originally designed is more suited to long-running waterfall- or spiral-style development methodologies. Consider the classic “chevron” SDL graphic:
As you can see, the SDL prescribes certain activities to take place during certain phases of the development lifecycle – threat modeling for example happens during the Design phase, and static analysis is performed during the Implementation phase. But not every development methodology has well-defined lifecycle phases like this. Specifically, Agile development methodologies do not have distinct phases and instead follow an iterative, time-boxed approach. How can the SDL be applied successfully in these environments?
One solution might be to take all the SDL requirements and put them into the product backlog, then pull them into the active queue (aka the sprint backlog, if you’re using Scrum) just like any other user story. This might work adequately for box products with well-defined product lifecycles that use Agile; for example, the Visual Studio teams that follow Scrum would fall into this category. However, the majority of internal teams (and very likely the majority of all development teams outside Microsoft too) that follow Agile use it to build web applications. This is important because web applications often don’t have a defined “end”; they just keep building and growing indefinitely. If we put the SDL requirements into the product backlog, it might take a year or more for a team to complete them all, but all the features added to the product after that date would go unsecured.
An alternative solution might be to just apply the entire SDL to every iteration. This would solve the problem of unsecured functionality being added after the SDL requirements have been completed, but it would create a whole new problem just as big, namely: how to complete all that SDL work in such a short amount of time! Per the Agile Manifesto, Agile projects should have short iterations, lasting from one month to a few weeks or less. There are online services teams here at Microsoft with one week long sprints. There’s no way these teams could complete the entire SDL in a sprint that short. And even if they could, there would be no time left to actually develop new features.
Another alternative would be to pare back the SDL, to cut out the “unnecessary” SDL requirements and just complete a smaller, core subset of the SDL each iteration. Unfortunately, this approach is flawed too, because none of the SDL requirements are unnecessary. Every requirement has been proven to prevent vulnerabilities or to reduce the impact of a successful exploit. Leaving requirements out of Agile projects would jeopardize their security, and that’s simply not an acceptable solution.
However, although none of these approaches solves the problem of adapting the SDL to Agile, that doesn’t mean the task is impossible. Over the last year, a team of security professionals throughout the Trustworthy Computing Security and Online Services Security & Compliance teams (including myself and Michael Howard from SDL) have worked to find a solution to the problem. Our resulting process has been in internal beta since the spring, has just recently released internally, and now I’m happy to announce that we’re releasing the details of the SDL for Agile Development Methodologies process today.
In brief, SDL-Agile breaks the SDL into three categories of requirements: every-sprint requirements, the requirements so important that they must be completed every iteration; one-time requirements, the requirements that only have to be completed once per project no matter how long it runs; and bucket requirements, the requirements that still need to be completed regularly but are not so important that they need to be completed every sprint.
Over and above the reorganization of requirements into a more Agile-friendly structure, SDL-Agile also provides guidance for adapting many of the core SDL activities to Agile. Threat modeling is a perfect example: a team could easily spend an entire week-long sprint performing threat modeling, but this may not be the best use of their time. SDL-Agile describes how a team can spend an appropriate amount of time modeling new features as well as how to build up a baseline of threat models for existing functionality.
Instead of getting into an in-depth discussion of SDL-Agile in the limited space I have here, I ask that you download and read the complete SDL-Agile guidance here, included as part of the SDL 4.1a Process Guidance document. We believe we’ve developed a process that is faithful to both Agile and to SDL, in which teams can innovate and react quickly to changing customer needs but in which the products they create are still more resilient to attack. As always, we welcome your feedback.
Hi everyone, Bryan here. I’m going to be presenting two sessions on the SDL next week, one for TechEd Europe and one for the Microsoft Platforma event in Moscow. If you’re attending either of these conferences, stop by and introduce yourself, or better yet stay for the session!
TechEd Europe:
SIA-205: SDL-Agile: Microsoft’s Approach to Security for Agile Projects
Monday 11/9 9:00-10:15, Berlin 1 Hall 7-3a
Platforma:
FF-206: The Microsoft Security Development Lifecycle
Thursday 11/12 4:30-5:30, Red Congress-Hall
Hope to see you there!
Hi everyone, Bryan here. Earlier this week, Microsoft released the latest volume of the Security Intelligence Report (SIR), which covers the first half of 2009. There are many interesting statistics in this report, but there’s one that I’d like to draw particular attention to: the number of industry-wide reported vulnerabilities as broken down by OS vulns vs. browser vulns vs. application vulns.
It is gratifying to see a sharp decline in the number of application vulnerabilities reported in the first half of 2009, but it’s important to note that they still make up the vast majority of vulns. Attackers are still largely focusing on the long tail of third-party applications. It’s more important than ever for all development shops, no matter how small, to bake security practices into their development lifecycles and ensure that their products don’t end up contributing to next year’s blue Application Vulnerabilities bar.