Chapter 2: The Proactive Security Development Process

Chapter 2

The Proactive Security Development Process

Many books that cover building secure applications outline only one part of the solution: the code. This book aims to be different by covering design, coding, testing, and documentation. All of these aspects are important for delivering secure systems, and it's imperative that you adopt a disciplined process that incorporates these aspects. Simply adding some good ideas or a handful of best practices and checklists to a poor development process will result in only marginally more secure products. In this chapter, I'll describe in a general way some methods for improving the security focus of the development process. I'll then spend a good amount of time on educational issues because education is both crucial to creating secure products and a pet subject of mine. Then I'll move on to more specific discussion of the techniques you should use to instill security awareness and discipline at each step in the development process.

However, let's first look at some of the reasons why people choose not to build secure systems and why many perfectly intelligent people make security mistakes. Some of the reasons include the following:

  • Security is boring.

  • Security is often seen as a functionality disabler, as something that gets in the way.

  • Security is difficult to measure.

  • Security is usually not the primary skill or interest of the designers and developers creating the product.

  • Security means not doing something exciting and new.

Personally, I don't agree with the first reason security professionals thrive on building secure systems. Usually, it's people with little security experience and perhaps little understanding of security who think it's boring, and designs and code considered boring rarely make for good quality. As I hope you already know or will discover by reading this book, the more you know about security, the more interesting it is.

The second reason is an oft-noted view, and it is somewhat misguided. Security disables functionality that should not be available to the user. For example, if for usability reasons you build an application allowing anyone to read personal credit card information without first being authenticated and authorized, anyone can read the data, including people with less-than-noble intentions! Also, consider this statement from your own point of view. Is security a disabler when your data is illegally accessed by attackers? Is security something that gets in the way when someone masquerades as you? Remember that if you make it easy for users to access sensitive data, you make it easy for attackers, too.

The third reason is true, but it's not a reason for creating insecure products. Unlike performance, which has tangible analysis mechanisms you know when the application is slow or fast you cannot say a program has no security flaws and you cannot easily say that one application is more secure than another unless you can enumerate all the security flaws in both. You can certainly get into heated debates about the security of A vs. B, but it's extremely difficult to say that A is 15 percent more secure than B.

That said, you can show evidence of security-related process improvements for example, the number of people trained on security-related topics, the number of security defects removed from the system, and so on. A product designed and written by a security-aware organization is likely to exhibit fewer security defects than one developed by a more undisciplined organization. Also, you can potentially measure the effective attack surface of a product. I'll discuss this in Chapter 3, Security Principles to Live By, and in Chapter 19, Security Testing.

Note also that the more features included in the product, the more potential security holes in it. Attackers use features too, and a richer feature set gives them more to work with. This ties in with the last reason cited in the previous bulleted list. New functions are inherently more risky than proven, widely used, more mature functionality, but the creativity (and productivity) of many developers is sparked by new challenges and new functions or new ways to do old functions. Bill Gates, in his Trustworthy Computing memo, was pointed about this when he said, When we face a choice between adding features and resolving security issues, we need to choose security.

Ok, let's look at how we can resolve these issues.



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