Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

• presse@ccc.de (preferred)
• 0700-CHAOSFON (0700 - 24267366)
  

First, a quick clarification. I noticed that some of the readers who commented on that first post wanted to talk about improving security through the use of various development methodologies or coding frameworks. Those are interesting tangents (and ones that I may write about in the future), but my intention with this post is to discuss a very specific problem related to how people integrate third-party code — that is, the stuff you import or link in but didn’t write yourself.

As I mentioned previously, developers have a tendency to “bolt on” third-party components to applications without understanding the security implications. Often, these components are glossed over or ignored completely during threat modeling discussions. I attempted to illustrate this with my fictitious WhizBang library example in Part 1.

When integrating a third-party component, developers familiarize themselves with the API but generally don’t care how it’s implemented. Granted, that’s how an API is supposed to work; you don’t have to futz around with code beyond the API boundary, and you can blissfully ignore parts of the library that you don’t need. In past consulting gigs, I’ve sat in threat modeling discussions where nobody knew whether a particular library generated network traffic. “We just use the API,” they say. The fact that it works is good enough; nobody seems to care how it works.

That mindset is ideal for rapid development but problematic for security. Failing to understand the complete application, as opposed to just the part you wrote, prevents you from accurately assessing its security posture.

It’s also no coincidence that web app pen testers love third-party components — we get excited when we see “bolted on” interfaces, because we know that developers tend to leave extraneous functionality exposed. The resulting findings usually generate reactions such as “I didn’t even know that servlet had an upload function.”

An Example

Here’s a close-to-home example related to my post about DWR 2.0.5 from the other day. DWR is an Ajax framework that has a variety of operating modes. In-house, we use a subset of DWR’s full functionality — specifically, we interact with it using the “plaincall” method only, so we made sure that the features we didn’t need were disabled via the configuration file. As it turned out, there were vulnerable code paths prior to the “do you have this thing disabled” check. In hindsight, if we had taken more time to understand the exposed interfaces, we could have reduced the attack surface by filtering out unneeded request patterns before they even touched the third-party code.

But wait, you say. What about maintainability? If I whitelist using a point-in-time application profile, doesn’t this create the same maintenance headache as the reviled WAF? It doesn’t have to. Certainly, one option would be to whitelist each and every unique URL that references the DWR framework, e.g.

/dwr/call/plaincall/myMethod1
/dwr/call/plaincall/myMethod2
/dwr/call/plaincall/myMethod3

But then you’d have to update the whitelist every time you added or removed functionality from your application. Also, don’t lose sight of the security goal, which is to minimize the amount of exposed third-party code. If I add or remove URLs that list, provided they are still using the “plaincall” method, I’m hitting the same DWR dispatcher every time. So I’ve increased maintenance cost without any security benefit.

A better option is to simply tighten the URL pattern a bit in the J2EE container. Here’s the default configuration:

<servlet-mapping>
  <servlet-name>dwr-invoker</servlet-name>
  <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

Now, instead of allowing every URL starting with /dwr/ to be processed by the DWR library, you could be a little more restrictive:

<servlet-mapping>
  <servlet-name>dwr-invoker</servlet-name>
  <url-pattern>/dwr/call/plaincall/*</url-pattern>
</servlet-mapping>

In this configuration, you don’t have to worry about /dwr/call/someothercodepath any more. There is less third-party code exposed, thereby reducing the overall attack surface of the application. (NB: DWR also serves up a couple of Javascript files, so those URL patterns will have to be whitelisted too)

A Logical Extension

Even if you’re not a developer, you should still be thinking about attack surfaces. People download and install blogging platforms such as WordPress, Movable Type, etc. all the time, but how many take additional steps to harden their installations? The concept is the same as the OS hardening analogy I brought up at the very beginning of this discussion.

Similarly, people install third-party WordPress plugins or Joomla components without considering that most of them are written by some random programmer who is a whiz with the plugin API but knows nothing about security?

At the risk of sounding trite, always remember that security is only as strong as the weakest link.

Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?

I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example.  The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.

But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.

You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season.  J

One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.”  He was not alone, I assure you.

Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.

Richard Derwent Cooke wrote,   “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”

At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.

To be effective, training needs to happen in an environment:

·         Where expectations are clearly set (the SDL sets specific minimum requirements).

·         People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).

·         Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).

·         Where management models the behavior (recall the original BillG TWC memo).

·         Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).

Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.

To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.

 By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even  decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects.  And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.

And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior.  Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .  

We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.

I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.

So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.

Hovering somewhere overhead, a tiny robot points its camera at the van and takes note of its color scheme and markings. An even bigger drone, thousands of feet above its hovering kin, maintains a God’s-eye vigil on the whole hunt.

Everything these robots see is radioed to monitors thousands of miles away -- and into the targeting systems of a B-52 bomber winging, silent and nearly invisible, several miles overhead.

This scenario, played out at a remote Nevada facility last week, was the first major test of the Army’s $160-billion, 20-year plan to build a high-tech family of networked robots and hybrid-electric armored vehicles. The “Future Combat Systems” program, co-managed by Boeing and consultants SAIC, aims to equip roughly a third of the Army with 14 new vehicle types that are connected constantly to a vast communications net.

The theory behind the FCS is that dispersed, intelligent robotic systems plugged into a universal communications network can help small numbers of U.S. troops riding in new vehicles to control huge swaths of terrain. Any ship, airplane or tank fitted with the FCS network devices will be able to see everything the others see.

The SkyNet-like network and dynamic coordination “is the most important thing,” Brigadier General James Terry says.

This is “a big deal for joint fires,” Army spokesman Paul Mehney told Wired.com.

“Joint fires” is mil-speak for getting all the military services to share info and coordinate their attacks. That kind of teamwork is a big factor in the U.S. military’s combat prowess. And if FCS works out as planned, the five U.S. military branches will team up better than ever.

Did the test work? Kinda.

The robots spotted the van; their targeting data bounced to a nearby unit of specially-equipped Humvees, then across the network to an Air Force intelligence cell in Langley, Virginia, then back to the B-52 -- all in just seconds. The bomber simulated dropping a guided bomb to “destroy” the van.

The Nevada test proved it was possible, according to Mehney.

But one critic says the test essentially was rigged -- that the conditions were too easy.

“There is ‘works’ and then there is ‘works,’” John Pike, an analyst with Globalsecurity,org, told Wired.com.

“A considerable fraction of the FCS network hardware does not currently exist,” Pike said. And the integration of that hardware that does exist has been touch-and-go.

In February, when testers “flipped the switch” for the first time on the network radios, there was a collective sigh of relief that the radios even worked -- this according to one FCS insider who spoke on background.

Last week’s desert test comes at a critical time for Future Combat Systems. Mounting criticism from the GAO plus the growing cost of fixing and upgrading the Army’s current war-weary vehicle fleet -- $120 billion over 10 years, according to the GAO -– has put the squeeze on the futuristic program. “It is not yet clear if or when the Army and [its contractors] can develop, build, and demonstrate the … network,” the Government Accountability Office reported in March.

One powerful congressman, nominally a supporter of FCS, has proposed injecting extra money into the program in order to rescue some of its technologies before canceling the rest.

Rep. John Murtha (D-PA), chair of the defense appropriations subcommittee, promised an extra $20 billion this year for FCS, provided the Army could use the money to wrap up the program quickly. “We need to accelerate FCS if we ever want to see anything accomplished,” Matt Mazonkey, a Murtha staffer, told Wired.com.

The Army is still preparing its response to Murtha’s query, Mehney said. Regardless, the service’s position on FCS has never wavered. The Army says that FCS is on-budget, on-schedule, and with continued funding will deliver on its promises to connect the ground service to itself and to all the other military branches.

And to ensure smooth progress despite a combined $900 million budget cut last year, the Army this month asked Congress to “re-appropriate” $250 million of other Army funds into FCS coffers.

“Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.”
- Bruce Schneier

For me, acquiring a “security” mindset wasn’t tough.  I was lucky enough to work with some great penetration testers.  The whole “social engineering” thing was easy to “get”, too.  By my second engagement, I acquired a love for figuring out how to manipulate the denigrated bureaucracy.

The problem with the security mindset is that, in risk analysis, it carries over as a bias.  When I’m out training organizations, there’s usually a really smart guy with ages of cybercop experience who will devolve the conversation about Vulnerability (Threat Capability vs. our Controls) into how he would use his knowledge of the systems and their weaknesses to possibly steal millions and millions of dollars/identities/trade secrets/whatever in a particularly clever way.  It happens every session.  It’s not a bad thing - but it has to be qualified within the context of the applicable threat community.  Are we really worried about an uber-brilliant admin with 20 years at the company and intimate knowledge of the systems architecture as a threat community?  Maybe we are, and if so this is a great and relevant discussion.

But if we’re not able to throw the resources at a problem needed to address someone whose skills and resources are in the top 1/10 of 1% of the threat community out there, what we’ve done is had a rabbit trail conversation that *if* an attacker had near perfect knowledge of the system and it’s defenses, it would be possible to evade prevention, detection, and most likely response until it was too late.  Great, but there’s a bias there that we’re carrying into the discussion because of the security mindset.

Thing is, once the security mindset matures with experience, we *know* that it is possible, for any system, regardless of physical location or vendors that supply software, to be compromised.  The question the risk analyst must answer, however, is really “What is *probable*?”.   And we should really belabor the point that “What is probable?” is not just a “Can it be done?” question. Yes, Level of Effort or Skills & Resources are relevant pieces of prior information, but what is similarly (if not more) important is the concept of frequency of events - or “*Is* it being done or more likely to be done in the future, and at what rate?”

EXAMPLE OF THE DIFFERENCE

There should probably be a Godwin-esque law about 9/11 examples and security by now, but you’ll forgive the indulgence.  Post 9/11, we had all sorts of questions about the risk of attackers and national infrastructure.  And the reason isn’t because we couldn’t imagine all sorts of creative attacks against nuclear power plants, metropolitan water supplies or large visibility entertainment venues.  Our uncertainty was due to a perceived possibility in an increase in frequency.  They did something spectacular once, (when) will they do it again?

This should be the mindset of the risk analyst.  Understand that it can be done, and how it may be accomplished, to be sure.  But it’s imperative that we frame that knowledge within the context of frequency and impact considerations.

For me, the good news is that mindests don’t seem to be fixed.  Training analysts in FAIR has shown me that they can be learned and unlearned.  In fact, I’m starting to think that a sign of IQ/EQ/Whatever might be said to be the speed with which one may adopt other mindsets.

Relevant References:

http://www.bloginfosec.com/2008/04/10/the-misleading-nature-of-schneiers-security-mindset/

http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html

One of the phrases I often hear during vision and strategy planning meetings at Microsoft is "What is the crawl, walk, run?" We use this phrase to differentiate the initial activities that will get us quickly moving toward our larger goals and then supplement them with other activities that may require longer preparation or planning. As I help non-Microsoft companies implement SDL into their development lifecycles, this "crawl" phase toward full adoption of SDL is very important. Usually some person in an organization picks up on the principles of SDL and is ready to roll them out immediately. However, that person usually is faced with competing interests that complicate full adoption: the team is mid-stream in development, short on budget, or management wants to see clear evidence before investing in the changes to support full SDL adoption.

Since we usually focus on how to roll out the full Lifecycle, I want to take a shot at defining what it means to start “crawling” toward SDL. One very important note before I start. What I describe below is not Microsoft’s SDL process. It matches some of the tools and principles, but does not encompass the holistic application security solution provided by SDL.

In my mind, to start crawling toward SDL, you need to execute on some of the core principles. They obviously need to be low-cost and effective. So, I want to summarize these into three components.

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

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

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

The good news is that you can attain these components with tools that are already available. The one consistent minimum requirement is that your code compiles/builds within Visual Studio 2005 SP1. The SP1 piece of this is important because some of the important defenses I discuss below were first made available in that version. Let’s look at some of the tools you can use to get “crawling” toward SDL today:

Detailed awareness of your architecture and its attack surface

Threat Modeling

Even if you are past the design phase, assign someone to do a retrospective model (perhaps as part of a pre-release review). This will likely give you a better understanding of your overall architecture and uncover holes in places you may have inadvertently overlooked.

Tools that will perform security analysis on your application

This is probably one of the most often discussed topics around SDL, so I’ll spend some time providing more detail. Let’s break this down into how it impacts differing parts of your team or organization: developers, testers, and operation.

Developers

You should start by strengthening your compiler defenses. Depending on whether you are writing native or managed code, these will differ.

For C and C++ code:

Strengthen your compiler defenses

·         Use the latest compiler and linker because important defenses are added by the tools

·         If using Visual C++,  use Visual Studio 2005 SP1 or later

·         Compile with appropriate compiler flags

·         Compile clean at the highest possible warning level

·         Compile with –GS to detect stack-based buffer overruns

·         Link with appropriate linker flags: /NXCompat to get NX defenses, /DynamicBase to get ASLR,  and /SafeSEH to get exception handler protections

Do not use banned APIs in new code

·         Use #include “banned.h” header file to find banned C/C++ functions in your code quickly. This header file is included in the companion disk in the Security Development Lifecycle book.

·         Compile regularly with /W4 and fix all C4996 (banned C Runtime function) warnings

For all Languages:

Strengthen your compiler defenses

·         Use the latest compiler, linker and libraries because defenses are added by the tools and code

o   If using C#, use  C# v2.0 or later and if using VB.Net use 8.0 or later

·         Use .NET Framework 2.0 or later

·         Do not use weak crypto in new code

o   Use only AES, RSA and SHA-256 (or better)

·         Prevent XSS vulnerabilities by using filtering and escaping libraries around all Web output

·         Secure your SQL script by only using prepared SQL statements - no string concatenation or string replacement

Run these tools habitually

·         PREfast (in Visual Studio 2005, use the /analyze compiler option) – a static analysis tool that identifies defects in C/C++ programs and enables you to perform quick desktop error detection on small code bases

·         FxCop – an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies

·         Application Verifier (AppVerif) – detect and help debug memory corruptions, critical security vulnerabilities, and limited user account privilege issues.

Testers

James Whittaker has covered testing in the SDL on this blog in the past. In a “crawl” scenario, you need to keep it simple while maximizing the value of output. I would recommend focusing on fuzz testing. This is likely something you will need to invest some time creating.  Scott Lambert’s article on Fuzz Testing at Microsoft and the Triage Process provides some good guidance on how to think through what type(s) of fuzzing to exercise against your application.

If you choose to expand beyond fuzz testing, I would point you back to James’ article on the broader topic of Testing in SDL. You may come to the conclusion that expanded security testing  may come later in your “walk” or “run” phases, but I would take some time to think through testing even while “crawling” to ensure you are getting broad enough coverage for your application. James’ article highlights the three-pronged approach to security testing we use at Microsoft. You should use these three approaches to ensure your own fuzz testing is comprehensive.

1.       Attacks against the application’s environment.

2.       Direct attacks against the application itself.

3.       Indirect attacks against the application’s functionality.

Results that show how the analysis resulted in improved security

Response planning

Protecting your customers is the entire reason for focusing energy on application security.  If there are holes in your code that you don’t uncover, someone else will. It is absolutely critical that you are prepared to respond rapidly and protect your customers. It is equally important that you construct your  response plan to serve as a front-line barometer for detecting the resilience of your security design  and what pieces of your applications security should be proactively bolstered to  address externally reported vulnerabilities.  The knowledge you harvest from these security incidents (typically through root cause analysis) is the primary way to improve your code and security tooling for the future.  Do everything you can to learn lessons from the vulnerabilities others find. If you don’t have a response plan in place, you need to get one in place as soon as possible. If you don’t know where to start, take a look at how our own Microsoft Security Response Center does it and fit to your scale or pick up the Security Development Lifecycle book and dig into the four-step process outlined.

The four steps of the emergency response process:

1.       Watch

2.       Alert and Mobilize

3.       Assess and Stabilize

4.       Resolve

Bugs, Bugs, Bugs

Gathering evidence that clearly shows your work has improved the security of your application is always a challenge. Trying to keep it lightweight adds to that challenge. The most effective way to create traceable and practical evidence without a lot of overhead is detailed management of security issues in your bug database.  The key here is that your bug database is configurable and able to be queried in a variety of ways to pull out this data. From the time you set out to implement this plan, be strict in tracking every discovery from threat modeling, the mitigations to those threats, and every bug you expose in tool analysis. This library of security bugs will give you an easy way to go back and gather evidence that shows the quantity of issues you discovered, the mitigations you used, and the impact the changes had on your application.

I have provided a fairly detailed view of these components. As I indicated, many of these defenses are available for you in Visual Studio 2005 SP1 or various linked resources above. If you are unsure whether you are taking advantage of all available defenses in your development tools, take the time to check.

It is my hope that some of you can use this scaled back entry into the principles of SDL to get moving toward improved security assurance. In the non-Microsoft SDL engagements I have been involved in, we have seen these steps effectively establish a baseline architectural understanding of your application security and identify critical weaknesses while providing solid evidence to support the decision to “run” forward into full SDL adoption.

[I want to thank Michael Howard for providing some of the key data for the Developer pieces in this article.]

It's useful if we take a moment and consider the definition of the auditing function. Here's mine:

Audits help us ensure that we are following our own policies. Audits measure the current state, compare the results against what the state should be, and show where we are out of compliance. Essentially, audits help us know that we are indeed doing what we say we're doing.

Audits are the natural outcomes of implementing good policies and following effective procedures. It makes no sense to spend time developing policies and without having some mechanism to measure compliance. That's the role of the auditing function -- to measure compliance. If we all agree that policies are good, then we should all agree that checking up on ourselves is also good.

So, then, who should conduct the audits? For comparison, let's examine a typical software development department. Here at Microsoft, such departments are composed of four over-arching roles:

• program management
• product management
• software development
• software test

Why this way? Consider the first two. We don't have "project managers" at Microsoft because project management incorporates two conflicting goals: managing people, schedules, and budgets (program management) versus incorporating customer requirements and creating new markets (product management). Program management optimizes resources while product management optimizes features. Rather than shoulder that inherent conflict onto a single person and expect them to deal with it without going completely bonkers, we have two roles, with different people. People skilled in each area negotiate with each other and come to an agreement about what's best both for Microsoft and for our customers.

Similar thinking exists for the second pair of roles. Developers strive to write high-quality code, and even do some testing along the way. But because no one's perfect, all code has some mistakes; it's valuable to have other people bang hard on the code, abuse it almost, to find and squash more bugs. Often, even the best developers are embedded so deeply in their own code that some bugs escape them. Developers rightly concern themselves with creating code that works and provides proper output. Testers figure out how to purposefully break software and discover code vulnerabilities. These are different skill sets, and using different people results in higher quality software.

We can apply the same logic to the information security department. How about these four roles:

• security standards
• security alignment
• security operations
• security auditing

The security standards group defines an organization's security architecture, creates policies and procedures, and ultimately takes responsibility for stewarding the integrity of the organization's information assets. The security alignment group spends time understanding the needs and drivers of the various business units, and advocates the business units' positions in meetings with the security standards group. Like in the software development model, having different folks negotiate together about standards and alignment helps ensure that business needs are met while also ensuring that the business is able to rely on information that's kept secure.

Remember: the primary purpose of information security is risk management. The standards folk know all about the bad guys and their techniques, and build up knowledge about which threats create risk for the organization. The alignment folk understand, through their constant interaction with people in the business units, all about business risk and get a feel for the business's risk tolerance -- that is, the level and kinds of risk that matter or don't matter. Together, the security standards and the security alignment folk can develop a security posture that allows the business to remain agile while also addressing the risks that make sense.

(Notice that I haven't indicated where, exactly, the alignment folk sit within the organization. They might be part of the security department, or they might be part of the individual business units. A case could be made for either choice; however, except for very large organizations, the alignment role probably isn't full-time. This leans the role toward sitting in the business units.)

Day-to-day work becomes the responsibility of those in security operations. They create standard configurations, perform installs and updates, monitor traffic, and respond to incidents. Ideally, policies and procedures guide all of these activities. But having policies and procedures isn't enough: we must also have a way to measure conformance. And that's the role of security auditing. Security auditors compare a system's current configuration to what it should be, based on the policy. Where systems are out of compliance, the auditor works with operations folk to understand the reasons, without engaging in blame-storming or launching personal attacks (this goes for operations folk, too). Most of the time, it's simply a mistake; here, auditors are like software testers, uncovering configuration vulnerabilities (bugs) that otherwise might be overlooked by operations and thus exploited by attackers.

Now you auditors out there, this doesn't mean that your role is simply that of checklist slave. Especially if your checklist is something you downloaded from the Internet. Remember: these checklists are only guidance, good ideas written by a person (or a committee) based on that person's risk tolerance. Effective auditors develop relationships with people in the other three groups: standards, alignment, and operations. Effective auditors take the time to learn the security landscape, how attackers operate, where vulnerabilities lie, and which threats matter. Really effective auditors learn how to do penetration testing, thus uncovering not only code and configuration vulnerabilities but also circumvention vulnerabilities through social engineering. By doing this, effective auditors remove the "us versus them" stigma often associated with auditing and truly become part of the security team, all working together to protect the organization's information assets.

(Notice that, as with the alignment group, I haven't indicated organizationally where the audit group should sit. I do, however, have a strong opinion on this: the management chains of the audit group and the operations group must be different. The people conducting audits shouldn't work for those who have a stake in an audit's outcome. To do so would create unavoidable and unrecoverable conflicts of interest.)

I'm sure there's more to the topic of organizing a security department. What do you think of this approach? Do you like the idea of dividing conflicting roles into different groups, then structuring them to work together to achieve realistic and useful outcomes? I don't suspect I've necessarily invented anything new here, but maybe just used a few new words -- such as "security alignment" -- and thought out loud about some of the tension that exists within the standards/alignment and operations/audit pairs. (Oh, and I got to write about my code/configuration/circumvention vulnerability triple again, heh.) Please tell me your thoughts. Maybe there's an entire white paper here, possibly even a TechEd presentation. Maybe someday we should offer a "TechManagementEd" conference!