Secure Coding: Principles and Practices

Chapter 2. Architecture

Architecture is easy: you just stare at the paper until droplets of blood appear on your forehead.

—Unknown^[1]

^[1] Source: www.ergoarchitecture.com/quotations/default.html

Imagine with us that you are the engineering director of a large company and you are interviewing candidates for a position as your software security architect. You ask the three main candidates, "Just how secure will you be able to make my software?"

If one of the candidates answers, "I can make your software secure against any attack," we hope you'll show him the door. If another candidate answers, "I will make your software as secure as it can possibly be," we hope you'll give her a failing grade as well.

In our opinion, the winning response is, "How secure do you want it to be?" That's because designing in too much security drains away resources, frustrates people, and can complicate matters so much that intelligent software maintenance is impeded.^[2] Superfluous security controls can actually diminish the overall safety of an enterprise.

^[2] By the way, we'd give extra credit to any candidate who asked his own question: "What do you mean by `secure'?"

The process of selecting design elements and principles to match a defined security need is what we mean by security architecture. In this chapter, we'll examine the role of architecture and how it applies throughout the development process, and we'll introduce the security engineering principles we believe are key to the development ...