ITS 305 - Security Policies and Auditing

Chapter 8, IT Security Policy Framework Approaches

Objectives:

This lesson covers chapter 8. It discusses areas of IT security policy frameworks, factors to consider when creating them, implementing them, and maintaining them. Objectives important to this lesson:

1. Choosing an IT security policy framework
2. Setting roles, responsibilities, and accountabilities
3. Separation of duties
4. Using a structured approach
5. Best practices
   

Concepts:

Chapter 8

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:

• Government agencies are required to follow the requirements of the Federal Information Security Management Act (FISMA, 2002). This usually means that the agency will follow the guidelines of the NIST, but it does not prevent them from selecting one of the choices lower on the page to do so.
• Many auditing firms have chosen the Committee of Sponsoring Organizations (COSO) model, and the Control Objectives for Information and related Technology (COBIT) model.
• Select a framework that others in your industry have been successful using. This means you ask your friends what they do.

Skipping to the bottom of page 207, the author describes some of the strengths of several framework models that might cause a enterprise to choose them

• COSO - a financial view of risk, useful for accounting firms or departments
• COBIT - connects business requirement to technology controls, but is not specific about implementing those controls
• ITIL - created by the British government to manage their IT needs, it is focused on the way an IT organization delivers services; it has grown in recent years to cover more types of organizations
• PCI DSS - created by the payment card industry, this one is focused on that aspect of business
• ISO - contains rules and procedures for multiple industries; it is a good choice for most enterprises, being specific about IT controls, but it is less detailed about management of them
• NIST (National Institute of Standards and Technology) - Guidelines from the federal government for government agencies and others

 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):

• Risk Governance - this domain relates risks to the interests of the business, sets objectives for the business and for risk management, and relates risk management to the strategic objectives of the enterprise
  
• Risk Evaluation - this domain discovers and reports risks, it analyzes risks and determines their impact, and it keeps a database of known risks
  
• Risk Response - this domain identifies or creates risk responses, chooses appropriate responses, and manages risk response actions
  

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 the 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.

• Head of information management -  The author calls this role the oone responsible for data quality in the enterprise, and observes it is typically held by a business person instead of a technologist. Perhaps we should pause to wonder if that is a good idea or a poor one.
• Data stewards - Owners of data, people who approve or deny requests for access rights based on business requirements. We can hope they know something about technology.
• Data custodians - If the stewards are people from the business side, these are their counterparts on the IT side who do the actual work of deploying data on systems in structures that match the steward's needs. Think of them as analysts, and the stewards as business experts.
  
• Data administrators - In some texts, these are the same people as the custodians. They run the servers, install patches, and are responsible for executing policies that apply to their systems.
• Data security administrators - Again, these people may be the same people as in other groups. This role includes adding and removing rights in user accounts, and assessing threats to the system.
  

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.