Building Blocks of Change

Every cultural change program requires buy-in from both management and tactical technical people. Improvement programs will fail if either group is left out or even underemphasized. Every organization, every group within an organization, and every stakeholder will have a different sensitivity toward change. These differences must be understood and accounted for because variances in sensitivity deeply affect expectations. Disconnects in expectation may eventually end up forcing an organization into a least common denominator approach that lacks impact. Some common pitfalls are described in the box Overcoming Common Pitfalls.

Keeping things simple is good because this enables people to understand and support a programbut don't lose track of the big picture. Breaking a major change program down into logical segments of work, with specific deliverables tied to each segment (which we also call an initiative), is a proven tactical approach. In practice, we find that a reasonable time range for any given initiative is three to four months. A stepwise approach minimizes risk while enabling an organization to test the waters as it gauges receptivity to change.

Overcoming Common Pitfalls

Education, accountability, and clear objectives are critical components to any successful software security initiative. Over the years I have observed some initiatives succeed and others fail. A set of common pitfalls is something to familiarize yourself with and keep squarely in mind. Think carefully about avoiding these problems as you initiate a software security program.

Over-reliance on Late-Lifecycle Testing

In many cases, large organizations get a first taste of software security through penetration testing. This can quickly devolve into an inefficient penetrate-and-patch exercise that is too expensive to be workable. Addressing software security exclusively as a testing problem fails because vulnerabilities created during the development phase are uncovered too late. Identifying and eliminating security issues only during the final testing phase fits into the bad habit cycle of "Develop broken stuff and then fix it." Testing for quality is essential, but producing quality is the real goal. How about "Develop pretty good stuff and make sure it's good!"?

A test logically probes some activity (making it observable) and is used to make sure that the activity was successful. As such, a test can only confirm a desired result; it does not by itself produce that result. If a development team builds a complex piece of software and does absolutely nothing during the effort to mitigate software security vulnerabilities, what results do you suppose testing will unveil? Imagine giving a high-school calculus test to fourth graders working their way through fractionsof course they will fail. By analogy, the same thing happens when we apply security testing at the end of the lifecycle. There is a good reason that just about every single piece of enterprise software fails today when tested for security vulnerabilities. Frankly, the dev teams didn't know what they were doing.

Of course testing is importantbut value will be realized only once you have built something worth testing.

Related to this problem is the obvious fact that test results alone do nothing to fix problems. All too often, risk analysis and security testing results are filed away in the "do one day" drawer and forgotten. When that happens, security problems persist.

Management without Measurement

A basic premise of management theory is: You can't manage what you don't measure. This is certainly applicable to building secure software. Unfortunately, I commonly encounter organizations that exhibit a lack of objectives and measures to support their software security initiatives. Many companies insist they are creating secure softwareand slogans to that affect abound. But when asked how they measure their effectiveness, they are at a loss. Simply demanding that developers create secure code only states a truism without providing any urgency to follow through. No developer sets out in the morning to create insecure codebut they do it anyway. The desire to do it right is naturally present. The missing piece is identifying what is to be done and measuring to ensure that it is.

Training without Assessment

Training not only developers but everyone involved with creating secure software is an essential activity. Unfortunately, a number of companies I have worked with felt that once a training program had been put in place, nothing more needed to be done. Nothing was done to impose objectives, measures, and testing around software security. Training by itself is not very useful unless there is follow-through on the bigger picture.

Lack of High-Level Commitment

Make no mistake; implementing an SDL is a serious undertaking. Getting everyone on board requires a sustained effort. Microsoft is no exception. After the Gates memo in January 2002 (see Chapter 1), Microsoft made a staunch public commitment to improve the security of its operating system.

The company was serious about reaching its goal. Microsoft built metrics to track progress. It hired and empowered some of the world's leading software security authorities. There was a strong management edict to get it right. Any developer at Microsoft who created a security vulnerability after completing the corporate security training program faced "serious consequences." As a result, after an incredible investment of over $300 million, Microsoft has enjoyed considerable success rolling out its own SDL.

At Microsoft, the wealthiest and most powerful software company in the world with its nearly limitless resources and expertise, the effort to adopt an SDL required the involvement and support of the Chairman of the Board, not to mention an incredible amount of effort and diligence on the part of engineers and managers throughout the organization.

Without this commitment from the highest levels, even the most powerful grassroots efforts can hit the wall. I witnessed this myself at a huge Silicon Valley technology producer that is a household name. The managers in the executive suite had lost touch with the builders and did not understand why they needed to put their weight behind software security. The initiative lost steam and was not able to get the budget it needed to succeed.

Ask yourself: Who is the executive champion behind software security in your corporation, and how will they get the job done?

In terms of breaking a program down, my approach recommends a mixed method of planning for dependencies blended with a sequence of initiatives that builds on itself. Dependencies can be used to adjust the general sequence to account for those items likely to require some dependent task prior to being kicked off. For example, building a set of measurement tools will be directly dependent on the software development methodology that is used. If an early segment includes the selection and/or adoption of a given methodology, tool choice issues should be deferred to a later segment because they require an in-place methodology to be effective.

A clear sequence of initiatives allows an organization to achieve a specific level of adoption, test the waters, measure and validate accomplishments, and set the stage for the next level. Cigital follows a change program maturity path sequence with the following six phases:

1.	Stop the bleeding.
2.	Harvest the low-hanging fruit.
3.	Establish a foundation.
4.	Craft core competencies.
5.	Develop differentiators.
6.	Build out nice-to-haves.

Phase 1: Stop the bleeding is targeted at those areas of software development programs that are known to be problem areas. If particular security bugs like buffer overflows are causing the biggest problem, a good phase 1 approach might involve the adoption of a code scanning tool and an associated process for its use. If there are tens of thousands of security-critical applications with unknown risks, a good phase 1 approach might be to carry out a flyover risk analysis process and organize the applications in order of criticality/security exposure so that the plan addresses those applications most at risk first.

Phase 2: Harvest the low-hanging fruit is focused on finding quick wins that are instrumental in getting buy-in from the organization and in helping a change program build momentum. Note that this phase and its predecessor are good barometers for determining the organization's receptivity toward change.

Phase 3: Establish a foundation is about setting in place components that provide building blocks for future initiatives. Typical areas addressed in this phase include creating change control programs, building a root-cause analysis function, and setting up critical feedback loops. One such feedback loop identifies and cycles any security problems discovered through the application of best practices, such as code review, back into training (in order to teach developers how to avoid common security problems in the first place).

Phase 4: Craft core competencies is driven by both current strengths and desired strengths of the organization. If an organization has a strong reputation for creating solid architecture documentation, it will likely be more receptive to architectural risk analysis than it may be to abuse case development. This phase explicitly involves the adoption of software security best practices in a manner tailored to the strengths of the organization.

Phase 5: Develop differentiators in order to emphasize and highlight those capabilities that separate the organization from everyone else in the marketplace. Measurement and metrics systems put in place with a software security improvement program can be used to demonstrate how well things are going from a security perspective. This can serve as an important differentiator in the market.

Phase 6: Build out nice-to-haves involves adopting those capabilities that are not necessarily aligned to a given strategic business objective but bring value by achieving some improvement in productivity. These are left for last for obvious reasons.