Stacey Higginbotham adds a “dose of reality” to the cloud computing craze in her post on “10 Reasons Enterprises Aren’t Ready to Trust the Cloud”. Check the link for the full list which include security, portability and reliability. Cloud Computing – the next big thing, emphasis on “next”.

This just tickled my funny bone. And made me feel sorry for a certain technical marketing manager… But really, if it’s that hard to explain where the name came from, you’re not paying your marketing people enough. ;-p

As IT spending growth slows, virtualization (and the ROI it promises) rises to the top. According to a Goldman Sachs report, “server virtualization” and “consolidation” are the top priorities for technology executives. Goldman predicts the overall growth in spending to slip from “7 percent to 5 percent this year.”

Butler Group analyst Roy Illsley shares his advice for implementing holistic systems management or “simplification, so that the IT department can manage the technology stack at a higher level, and therefore enable it to manage a wider range of technologies more efficiently. Hmm… simplifying IT, breaking down silos, automation, visibility across heterogeneous infrastructure…sounds very very familiar.

ShareThis

In this series I am going to talk about “Walking” with the SDL. Walking is the point where your security development practices become a lifecycle – a repeatable, mostly reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll talk about walking – or adding the “L” in SDL.

I will be covering quite a bit on this topic, so I intend to split it up in to a multi-part series over a few days. I’ll condense it all into one big doc at the end. In Part One, I will review “crawling” and the foundation you need to have in place as well as discuss getting management approval. In Part Two we’ll cover the topic of expanding your security training. In the additional posts, we’ll discuss formalizing requirements, reusing threat modeling and attack surface review data, the importance of final security reviews, and managing post-release documentation. All of these are components to “walking” with the SDL.

Before I jump into detailing what you can do to “walk” with the SDL, let’s look back at a snapshot of what you should already have in place from learning to “crawl.” At a high level, crawling involved three components. Each of these components requires specific activities or tools that your team must implement to begin developing secure code:

1.       Detailed awareness of your architecture and its attack surface.

a.       Threat Modeling

2.       Tools that will perform security analysis on your application.

a.       Strengthen compiler defenses

b.      Use code analysis or static analysis tools such as PREfast, FxCop, AppVerif

c.       Build a strong fuzz testing capability

3.       Results that show how the analysis resulted in improved security

a.       Response planning and response process in place

b.      Use bugs to gather evidence and show that your work improved security

Think of these pieces as the “gross motor skills” you need to start walking. You should already be using these components and have reached a conscious decision to start building a lifecycle around your secure development practices. As you start figuring out how to “walk”, I want to point out that each of the concepts I discuss in this post is a critical component of the Microsoft Security Development Lifecycle. Adopting the SDL in your company involves a combination of integrating the existing SDL principles and the creating of unique requirements and components specific to your environment to build your own Security Development Lifecycle.

With that in place, let’s start talking about what it means to “Walk with SDL.”

Obtain Management Approval/Endorsement

Creating a Security Development Lifecycle will cost time and money. In addition, it will likely require some process changes. In most organizations, this change will not happen unless you obtain the management approval and endorsement necessary to compel the organization to act.

The key to successfully pitching SDL to your management can be found in the data you have been accumulating during the “crawl” phase. As you may recall from my crawling post, the simplest way to create evidence that clearly illustrates improved application security is to “mine” the data from your bug database. Connecting those bugs to known security vulnerabilities or to what would have been bad security issues that were avoided by fixing them in development is a powerful story. Of course your pitch should include other necessary components like anticipated costs, new software acquisition, possible vendor and consulting contracts and anticipated return on investment.

However, the heart of your argument will be the story you tell. The story is quite simply “If we hadn’t done this basic work in security, here is what we would have missed and how much it would have hurt…” followed by “if we continue to expand our security practices and make them a part of our process, we can better predict measurable security improvements that reduce the likelihood of future risks.”

The new SDL website [http://www.microsoft.com/sdl] provides some valuable reference material on the Business Case for SDL. I would recommend that looking through that information for some good supporting material. In Part Two, I will discuss expanding your security training as another component of “walking” with SDL.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        What unique challenges are you facing as you try to push for SDL adoption?

?        What have you used to successfully communicate the importance of security to your management?