This chapter begins with the admission that things will go wrong no matter what we do. There will be security events (incidents, security problems) regardless of our best efforts. This is not an admission of defeat, it is the reason that we do our best to prevent and minimize these events. Another reason is the political and legal reason that the author suggests: we need to show that we did our best, so we can avoid the worst liability consequences afterward. It seems less noble to think about that aspect, but it is another reason to do the right thing, just in case you are the kind of person who is not already motivated to do it.
In this case, doing the right thing is picking the right security policy framework model. The author lists five of them on page 207. How do you pick the right one for your company? The author takes us through three rules at the top of page 207 that can lead to specific choices in some circumstances:
Skipping to the bottom of page 207, the author describes some of the strengths of several framework models that might cause an enterprise to choose them
On page 210, the author switches to another model, the ISACA Risk IT framework, to discuss some of its features that illustrate a comprehensive approach. (This framework is based on COBIT, but it extends to cover the problem noted above.) The short discussion in the text is about this model having three domains (areas of concern):
On page 212, the author makes a good point that changes to a process that people consider to be independent may affect dependencies they have not considered. In the example in the text, there is a change in the type of tapes used to make backups. This may have required a new tape reader/writer that could not read the older tape format. This seems unlikely to be a problem, when considering only recent backups and possible restores, but it could be a problem if our organization needs to restore archived data at some point. The observation in the text is that a framework view of related processes could find this kind of problem. I would expect the people who do restores to be aware of it as well, since they use the same devices as the people who do the backups, but we can accept the example for its intended benefit.
Okay, on page 213, I am officially sick of the author using the word domain to mean everything under the sun. He makes a reference to Infrastructure domains, then runs off on a tangent without explaining himself. Let's examine the tangent, since that seems to be his actual point.
The text lists five roles that mean different things to this author than they did to the last one. As with any discussion of roles, assume they might be called something else by the next place that hires you.
As we have discussed before, it is a good idea to have layers of approval for new or changed systems. Those layers should have increasingly wider scope as a request moves up the approval chain. There should also be people in those layers who know a lot about the layers under them in the organization. This kind of approval path might be based on organizational structure, or on organizational function. It is probably an unusual organization whose structure matches its functions, so there will be people in various jobs who also serve in overlapping roles.
Page 217 introduces another concept, separation of duties (SOD). The general concept is to protect the organization from loss due to one bad employee or one successful hacker. Thinking about it that way, it may be easier to sell the idea to employees that we want any high risk or high cost action to require the cooperation of two or more members of our organization, both/all of whom are empowered and required to contribute to the action, such as authorizing a large payment, or placing orders, or publishing sensitive material to a public facing web site. The text refers to this method as the layered security approach.
The text goes on to recommend a technique called three lines of defense. This method adds more complexity to the approval path where such complexity is needed. Compare the graphic on page 218 to the one below from a British site (hence the British spelling):
Note that in the example above, the first two lines of defense are separate, but they report to the same authority. The third line reports to a different authority, as well as the one the first two report to. This makes it certain that this decision will be evaluated at least five times, and perhaps six. The potential for evaluation by external entities is shown by the two entities on the right.
The chapter continues with more conceptual material, and finally ends with some case studies and best practice examples. The bottom line is that you should choose some model to follow, and no matter which one you choose, you will need to customize it for your organization. Your actual practices will need to reflect the needs of your business. Modify it to fit, and you will do better than if you follow the model exactly.