Development Phase

Development Phase

Development involves writing and debugging code, and the focus is on making sure your developers write the best-quality code possible. Quality is a superset of security; quality code is secure code. Let's look at the some of the practices you can follow during this phase to achieve these goals.

Be Hardcore About Who Can Check In New Code (Check-Ins Checked)

I'll keep this short. Revoke everyone's ability to check in new and updated existing code. The ability to update code is a privilege, not a right. Developers get the privilege back once they have attended Security Bootcamp training.

Security Peer Review of New Code (Check-Ins Checked)

Peer review of new code is, by far, my favorite practice because that peer review is a choke point for detecting new flaws before they enter the product. In fact, I'll go out on a limb here: I believe that training plus peer review for security of all check-ins will substantially increase the security of your code. Not just because people are checking the quality of the code from a security viewpoint, but also because the developer knows his peers will evaluate the code for security flaws. This effect is called the Hawthorn effect, named for a factory just south of Chicago, Illinois. Researchers measured the length of time it took workers to perform tasks while under observation. They discovered that people worked faster and more effectively than they did when they weren't observed by the researchers.

Here's an easy way to make source code more accessible for review. Write a tool that uses your source control software to build an HTML or XML file of the source code changes made in the past 24 hours. The file should include code diffs, a link that shows all the updated files, and an easy way to view the updated files complete with diffs. For example, I've written a Perl tool that allows me to do this against the Windows source code. Using our source control software, I can get a list of all affected files, a short diff, and I then link to windiff.exe to show the affected files and the diffs in each file.

Because this method shows a tiny subset of source code, it makes it a reasonably easy task for a security expert to do a review. Note I say security expert. It's quite normal for all code to be peer-reviewed before it's checked into the code tree, but security geeks should review code again for security flaws, not generic code correctness.

Define Secure Coding Guidelines

You should define and evangelize a minimum set of coding guidelines for the team. Inform the developers of how they should handle buffers, how they should treat untrusted data, how they should encrypt data, and so on. Remember, these are minimum guidelines and code checked into the source control system should adhere to the guidelines, but the team should strive to exceed the guidelines. Appendixes C, D, and E offer starting guidelines for designers, developers, and testers and should prove to be a useful start for your product, too.

Review Old Defects

Reviewing old defects is outlined in greater detail in Chapter 3 in the Learning from Mistakes section. The premise is you must learn from past mistakes so that you do not continue making the same security errors. Have someone in your team own the process of determining why errors occur and what can be done to prevent them from occurring again.

External Security Review

It's worthwhile to have an external entity, such as a security consulting company, review your code and plans. We've found external reviews effective within Microsoft mainly because the consulting companies have an outside perspective. When you have an external review performed, make sure the company you choose to perform the review has experience with the technologies used by your application and that the firm provides knowledge transfer to your team. Also, make sure the external party is independent and isn't being hired to, well, rubber-stamp the product. Rubber stamps might be fine for marketing but are death for developing more secure code because they can give you a false sense of security.

Security Push

Microsoft initiated a number of security pushes starting in late 2001. The goals of these security pushes included the following:

  • Raise the security awareness of everyone on the team.

  • Find and fix issues in the code and, in some instances, the design of the product.

  • Get rid of some bad habits.

  • Build a critical mass of security people across the team.

The last two points are critical. If you spend enough time on a security push in the case of Windows, it was eight weeks the work on the push proper is like homework, and it reinforces the skills learned during the training. It gives all team members a rare opportunity to focus squarely on security and shed some of the old insecure coding habits. Moreover, once the initial push is completed, enough people understand what it takes to build secure systems that they continue to have an effect on others around them. I've heard from many people that over 50 percent of the time of code review or design review meetings after the security push was spent discussing the security implications of the code or design. (Of course, the meetings I attended after the security push were completely devoted to security, but that's just the Hawthorn effect at work!)

If you plan on performing a security push, take note of some of the best practices we learned:

  • Perform threat modeling first. We've found that teams that perform threat modeling first experience less churn and their process runs smoother than for those teams that perform threat modeling, code, test plan, and design reviews in parallel. The reason is the threat modeling process allows developers and program managers to determine which parts of the product are most at risk and should therefore be evaluated more deeply. Chapter 4 is dedicated to threat modeling.

  • Keep the information flowing. Inform the entire team about new security findings and insights on a daily basis with updated status e-mails, and keep everyone abreast as new classes of issues are discovered.

  • Set up a core security team that meets each day to go over bugs and issues and that looks for patterns of vulnerability. It is this team that steers the direction of the push.

  • The same team should have a mailing list or some sort of electronic discussion mechanism to allow all team members to ask security questions. Remember that the team is learning new stuff; be open to their ideas and comments. Don't tell someone his idea of a security bug is stupid! You want to nurture security talent, not squash it.

  • Present prizes for best bugs, most bugs found, and so on. Geeks love prizes!

Be Mindful of Your Bug Counts

You'll find security bugs if you focus on looking for them, but make sure your bug count doesn't become unmanageable. A rule used by some groups is to allow a developer to have no more than five active bugs at a time. Also, the total number of bugs for the product should be no more than three times the number of developers in the group. Once either of these rules is broken, the developers should switch over to fixing issues rather than finding more security bugs. Once bugs are fixed, the developers can then look for others. This has the positive effect of keeping the developers fresh and productive.

Keep Track of Bug Metrics

When a security flaw is found in the design or in the code, you should log an entry in your bug-tracking database, as you would normally do. However, you should add an extra field to the database so that you can define what kind of security threat the bug poses. You can use the STRIDE threat model explained in Chapter 4 to categorize the threats and at the end of the process analyze why you had, for example, so many denial of service flaws.

No Surprises and No Easter Eggs!

Don't add any ridiculous code to your application that gives a list of all the people who contributed to the application. If you don't have time to meet your schedule, how can you meet the schedule when you spend many hours working on an Easter egg? I have to admit that I wrote an Easter Egg in a former life, but it was not in the core product. It was in a sample application. I would not write an Easter Egg now, however, because I know that users don't need them and, frankly, I don't have the time to write one!



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2001
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net