colin dellow's bln

Chapter 1 motivates the need for secure systems, and provides tips on how to convince your organization of the need.

Howard:

As the Internet grows in importance, applications are becoming highly interconnected. In the "good old days," computers were usually islands of functionality, with little, if any, interconnectivity. In those days, it didn't matter if your application was insecure -- the worst you could do was attack yourself -- and so long as an application performed its task successfully, most people didn't care about security.

Cohen:

The misinformation on the book starts in the 2nd sentence of the first paragraph of chapter 1 when we are told that security wasn't important before the Internet grew in importance and that the worst result would be that people could attack themselves. The first network-based global computer virus reached mainframes around the world in the late 1980s - and it did not involve the Internet. [emphasis mine]

Cohen has a point: The introduction of networks is what caused the shift in focus in computer security, and, as the Internet is just one such network, Howard's point is technically incorrect. Is it misinformation? Hardly. That implies some malice or motive.

Howard:

[...] So where do you begin instilling security in your organization? The best place is at the top, which can be hard work. It's difficult because you'll need to show a bottom-line impact to your company, and security is generally considered something that "gets in the way" and costs money while offering little or no financial return. Selling the idea of building secure products to management requires tact and sometimes requires subversion. Let's look at each approach.

Cohen:

Indeed, chapter 1 demonstrates just how poor the internal culture at Microsoft is. Such awareness activities as getting the boss to send an email and nominating an evangelist are really not about writing secure code as much as internally about convincing Microsoft to do what you want. It is valuable for salespeople no doubt.

It is unclear what Cohen draws on to support his statement about the poor internal culture at Microsoft -- indeed, the foreword to the book talks about the 2002 trustworthy computing directive from Bill Gates motivating the change in culture.

Howard:

Principle #1: The defender must defend all points; the attacker can choose the weakest point.
Principle #2: The defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities.
Principle #3: The defender must be constantly vigilant; the attacker can strike at will.
Principle #4: The defender must play by the rules; the attacker can play dirty.

Cohen:

The lack of a basis for design shows up in Chapter 1 and it permeates the book. The four principles selected in the book are hardly what I would choose, but then I was not choosing. "Principle 2 - the defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities" - an excellent example of why you need a design basis and how the lack of one leads you down the wrong path. "Principle 4 - The defender must play by the rules; that attacker can play dirty!" - what rules are those? My view is that this lack of a design basis, the lack of deep understanding of issues and a way to approach dealing with them, and the lack of a theory and a practice underlies the problem that Microsoft and much of the current programming community has with writing secure code. This book does nothing to solve these problems.

Cohen introduces the phrase 'design basis', but doesn't define it -- though he does lament the lack of them in most software. He complains that the principles presented are not those he would present -- but doesn't offer his own principles.