ITS 3050 - Security Policies and Auditing

Security Policies and Implementation Issues
Chapter 6, IT Security Policy Frameworks
Chapter 7, How to Design, Organize, Implement, and Maintain Security Policies

Objectives:

This lesson covers chapters 6 and 7. 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. IT security policy frameworks
2. IT program framework policies
3. Business factors relating to building a policy framework
4. Information assurance factors to consider
5. ISS factors to consider
6. Best practices
   
   
7. Designing policies
8. Contents of a policy framework
   
9. Implementing policies
10. Policy change control
11. Maintaining policies and standards
    
12. Best practices
    

Concepts:

Chapter 6

This chapter begins with a definition of an IT security policy framework. Unfortunately, it is only a list of components found in a framework, so it would tell you little if you do not understand the items listed there. Before continuing, review lesson 7 and compare it to this week's list of components.

• Policies - rules about the conduct of our organization with regard to particular actions (we will limit ourselves to particular models chosen by the IT department); how we will approach the expectation
• Standards - a method or process that may be procedural or technical (orders are to be placed by approved requesters within each work area); what steps are to be followed to assure general compliance with policy
• Baselines - standards from which other standards are developed; we might have a baseline standard that all PCs will come from one vendor contract with a minimum feature set, and specific standards for advanced models for IT system developers
• Procedure - a detailed set of steps to follow to be in compliance (requests are to be made to your manager, who will forward approved requests to your authorized requester); variations or limitations that apply to specific work areas, to be followed if they apply to your area
• Guidelines - a suggested addition to any of the items above that is recommended but optional (submit your requests two weeks before the end of a quarter to allow processing time); do this to make it work better
• Taxonomy - a set of definitions of how terms are used in our organization; this can also mean naming standards for objects in our organization, used in Active Directory or a management program; naming systems can be based on location, use, categorization, department or division ownership, or other concepts important to your organization

The author has thrown in some new ones. I made them bold in the list above. His comments on page 144 about growing a library of these documents being like growing a tree is a pretty good analogy. Like a tree, the parts of your business need to grow, to reach maturity, to produce fruit or nuts or seeds, and to be cut away to make room for new growth when they are no use any longer. The pieces of your policy framework should be expected to do the same. We need new rules about new products, new problems, and new changes to the environment.

The text talks about risk again for a bit. The author defines two phrases that may be misunderstood:

• Risk appetite - The upper limit of risk that is acceptable in pursuit of a goal
  
• Risk tolerance - The amount of variance in risk that is acceptable to an organization

Risk appetite is a measure of the greatest risk that is allowed to be undertaken. Most organizations are cautious about risk, if there is a significant impact. Risk tolerance is a measure of the difference between the highest risks, lowest risks, and average risks in an organization. No one minds low risk, but risks that are too high, too different from our standard operation, will cause too much variance in the performance of the company.

The next topic is called by two names: program framework policy and information security program charter. Both phrases are almost indecipherable, so let's see what the author means. The word program, which appears in both names, refers to a broad authority to make rules and procedures regarding information security that must be followed by all employees in the organization. The word charter in the second phrase also refers to the authority being granted to the people managing this program. Four common names for the officer who runs such a program appear at the top of page 147. Such authority must be granted by the legitimate owners or operators of the organization. We have already been sold on the idea of a framework containing all the concepts in the list above. The program framework policy, or program charter, is meant to be an even larger concept, one that establishes the legitimate rights of the office administering it.

The text lists four areas of concern within the program framework policy. Don't be confused, it still includes all the bulleted items above. It also includes these:

• Purpose and mission of the program - The text discusses this area with terms that sound unrealistic. Yes, the program should support the goals of the organization. How does protecting our customers' data conflict with the goals of any organization. The purpose is to perform the basic functions of an information security department, and to protect our assets. Alignment with the mission goals of the organization is more of a political statement than a useful one.
• Scope of the program - A discussion of the scope of the program depends on what our assets are, what our budget is, and how we decide which risks to protect ourselves from. There will never be enough money to do everything we want to do, so we have to live within our means.
• Responsible parties who will implement the program - This area makes it clear who has what responsibilities with respect to carrying out the procedures, notifying staff of policy, and making sure that these people do their jobs.
• Compliance management - The program requires that people follow the rules, and must also allow for monitoring performance for compliance and for violations. It must allow for policies to be created by the proper part of the organization (such as Human Resources) with regard to discipline for single, multiple, and repeated violations.

The text moves on to discuss well known framework models (security management models) that are often chosen by organizations as the basis for their own frameworks. To put this in perspective, imagine three phases of a project to develop your security management standards, as described by last year's text:

1. First, select a security management model that fits your organization's needs and goals.
2. Second, write your own security framework document, a plan that outlines the work needed to adapt the model to the realities of your organization.
3. Third, create the security blueprint, which is a working, operational document. It describes how your organization will meet each applicable requirement of your security model, through the goals that are established in your framework.

So, that means you need to create the framework and the blueprint, but your first goal is to select a model that makes sense. You see what I mean about different terms in different books? They really mean the same things. You just have to get an idea about the concepts first to see that it is the same message.

How do you select a model? Sometimes, a model has been selected for you by another part of the organization (upper management) and you simply have to use it. The good news is that whichever model was chosen, it will probably work after being customized into the blueprint for your organization.

• COBIT (Control Objectives for Information and Related Technology) - not discussed in detail in the text; follow the link to the left to see details
• ISO 27000 Series (International Organization for Standardization) - see the list of topics in document 27002 on pages 150-153
  
• NIST (National Institute of Standards and Technology) Models - see the brief discussion on page 153, and the table on pages 154-155, principles in NIST Special Publication 800-53
  
• ITIL (formerly Information Technology Infrastructure Library, now just ITIL) - not mentioned in this text; see the ITIL official site for more information; it was created by the British government and has become a world wide standard
• The image on the right links to another standard, from a hardware vendor. You may find that the model offered by Cisco explains the concepts more clearly that the web site above.

The text continues with a section on standards. Note that the definition at the top of of this web page only says a standard contains steps to follow to be compliant with a policy. The policies are meant to be general, and related standards are meant to be more specific. This often means that standards need to be:

• clearly written (so people will understand them)
• repeatable (so the same results can be expected)
• pursuing a known goal (part of the policy)
• applicable to the people following them (so those people can actually perform the steps)

Page 157 discusses two types of standards:

• Issue specific standard - This kind of standard can relate to new technology or a new situation.
  • Issue statement - This part of the standard would commonly define terms used to discuss it, define what the perceived risks might be, and what employees are expected to do.
  • Organization position - Why does the organization want us to follow this standard.
  • Applicability - What is the scope of the policy and this standard? Specific rules about how to apply the standard.
  • Roles and responsibilities - If the standard requires approvals, who approves and who makes requests.
  • Compliance - This is the part that tells us what people are not allowed to do, how they will be monitored, and what discipline is to be expected for noncompliance.
  • Points of contact - Who to ask if you have questions, where to find this standard in the library, who to ask for help if the standard does not work.
• System specific standard - A standard for a system (like a network, or an application with many users)
  • Who is allowed to use this system?
  • Are only specific users allowed to modify it? If so, who are they?
  • Are there firewall rules, domain rules, or port rules for this system? This is especially important for public facing systems.
  • Are users allowed to access the system remotely? Must they use a VPN to access it?

The text continues with a discussion about procedures and why we need them. Typically, a procedure is used when a standard has a large scope, and it must be followed differently by people in different jobs, or who are operating in different countries. The things a standard tells us to do usually are smaller in scope than the standard that it modifies, because of job duties or because of local regulations that differ from place to place.

Guidelines are mentioned briefly. The text observes that guidelines start out as suggestions, which often become standards if they work out well.

The text reminds us that policy frameworks, like anything else in business, may be affected by their cost and by the impact of their controls on employees, customers, and business processes. There is no way a program that is too costly can be adopted. Likewise, we cannot introduce security in a way that keeps our employees from working or keeps our customers from doing business with us.

The text reviews the five pillars of Information Assurance, reminding us that our policy framework must support all of them. They were discussed in lesson 1:

• Confidentiality - we do not allow access to any resource unless there is a reason for that access
• Integrity - making sure that no one changes data who has not been authorized to do so
• Availability - data must be available to authorized users when they need it
• Authentication - the security needs of the system must be matched by the level of confidence we have in a user's identity
• Nonrepudiation - tracking of events and files must prove that a particular user took action, authorized access or payment, or simply was on the system

The text amplifies on this theme a bit, listing some other risks that our framework should guard against:

• Unauthorized access
• Unauthorized use
• Unauthorized disclosure
• Disruption of services
• Destruction of assets

The text also offers some best practices regarding policy frameworks:

• Let the staff know about the framework - no one follows rules they do not know about
• Remind staff about the framework - make people aware that security is also up to them
• Select a framework model that fits your organization, then customize it as needed
• Learn from the mistakes of other companies - I recommend that you regularly read Brian Krebs' website, Krebs on Security for news and analysis

Chapter 7

The chapter begins with some advice about writing all of our security documents clearly. It implies that we should be using a middle of the road grade level for our documents, making them easy for most people to understand. I am not surprised that the author finally gets around to saying that we should answer the six basic questions I mentioned in the ITS 421 class this term. Let's use the same reference:

This is another way of looking at the rules you need to implement on your network. Explain them. A good idea is to memorize a line from Rudyard Kipling about six honest serving men:

I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.

(The rest of the poem is not important in this context. Yes, you should read poetry. And science fiction, and detective stories, and lots of other things.)

• Who does this policy affect?
• Why is the policy needed?
• What is the policy about? What are we allowed to do and not allowed to do?
• When is the policy going into effect? When are we subject to it, and when are we not?
• Where does this policy apply? Only at home? Only at remote locations? Everywhere?
• How will it be monitored? How will compliance be measured? How do we request exceptions or report problems?

The author takes a moment for another point before continuing on this topic. He quotes another text on page 176, to illustrate the idea that some security framework models use an Architecture approach. This is the approach taken by the Cisco model that is linked above. So what is architecture, with regard to frameworks? If you search the web for an answer, you will find other definitions than the one the author intended, so let's examine his concept.

Consider the diagram on page 177. It shows a classic four by four grid. The x axis shows increasing service standardization from left to right. The y axis shows increasing service integration from bottom to top.

In the chart above, I have shown the same data, but added some color. The progression from low to high service integration (purple scale), considering only that change, takes us from a diversified model to a coordinated model.

• Diversified - this model does not share data well from one entity to another, systems are independent and require knowledge of each one to support them
• Coordinated - this model can share data across the enterprise, making it a better solution; this model is achieved by more standardization

The progression from low to high service standardization (blue scale), considering only that change, takes us from a diversified model to a replicated model.

• Diversified - this model does not use the same services from one entity to another, services vary across locations and systems
• Replicated - this model has common services across the enterprise, providing a common, more familiar interface, making it a better solution; this solution is achieved by more central control of services

The last option includes both levels of integration, taking us to a unified model.

• Unified - this model has the benefits of both of the better models, it can share data across the enterprise and it has common services across the enterprise, making it the best choice

The text presents a long list of principles on pages 178 and 179 that should guide us in making policies. They are guides, not rules, so we should use our judgement when making policies which become rules. Some highlights from the list:

• Accountability - Make it clear whether a person is responsible only for his/her own actions, or for those of all people below him/her in the organization chart
• Awareness - Tell people what the rules are, remind them from time to time, and make the rules easy to find on the organization's internal web site
• Multidisciplinary - Tell people in every type of job what they need to know to do their job correctly in compliance with policies
• Integration - make sure your policies support each other and do not contradict each other
• Defense in depth - make sure that we have multiple layers of defense, and that controls are different from one layer to the next, so a particular exploit will not be able to penetrate all layers of defense

Several other principles are valuable as well, so you should read all of them. Let's have a discussion about them on Canvas this week.

A classic point of confusion is covered on page 180 and 180. The text presents two different methods of categorizing security controls. Remember that any control will fit in both categorizations, not just one of them. They were also mentioned in chapter 2.

Categorizations based on control type (and who would administer it):

• Physical controls - These include any physical barrier, like a locked door or a fence, as well as security cameras and guards
  
• Administrative controls - These include the procedures to create security policies and the security policies themselves. Security policies are  rules about "the actions that users may do, must do, and must not do". I have reworded it here, because "cannot" and "must not" do not mean the same thing.
  
• Technical controls - Actions that are performed by devices (technical solutions), such a firewalls denying packets.
  

Categorizations based on the function of a control:

• Deterrent controls - used to discourage attacks; applied before an attack; example: warning attackers that we are protected
  
• Preventive controls - used to prevent attacks; applied before an attack; example: using a firewall to block traffic for specific ports; these controls are typically automatic controls
  
• Detective controls - used to detect an attack or intrusion;; applied during an attack; example: using a Intrusion Detection System; these controls are typically manual controls
  
• Corrective controls - used to reduce damage and restore to service; applied after an attack; example: using an emergency cleaning program on a USB memory stick, so that a computer can be usable
• Compensating controls - alternative controls that are used when normal controls are not possible; applied during an attack; example: disabling switch ports to isolate devices or LAN segments
• Mitigating controls - any type of control may be a mitigating control if it finds or notices errors and presents a method to correct them
• Recovery controls - controls that restore service to its state before the attack

The highlighted categorizations above are the ones your text does not mention.

Moving ahead to page 185, the text begins several pages of sample templates. There is a template for a policy, a standard, a procedure, and a guideline. If your employer has been using such documents for a while, there is probably an enterprise standard you would follow. If this is not the case, the samples offered in the chapter give you an excellent place to start making a template for your organization. Let's do one or two of those as an assignment this week. The best way to provide a job aid like this is to provide both the template and an example of your enterprise documentation that uses it. As an assignment, follow the template for a policy that starts on page 185, and write a policy that would make sense to you.

The text begins a new section on page 190 about creating and implementing policies. It lists four steps, but it expands on each of them.

• Building consensus on intent - This means to consult the various authorities in your organization about the policy itself. What is the policy about, and why are we writing it? These questions must be answered before you can begin to write it. The authorities are approving the concept of the policy at this stage, not its final version.
• Reviews and approvals - In a sense, this is the same as the step above, except that it happens after each draft of the policy document. Note the list on page 191 of four types of staff who should review the policy for its accuracy and compliance with other policies and procedures in the organization:
  • Technical personnel
  • Legal authority
  • Human Resources
  • Audit and compliance staff
• Publication - There should be a library of some sort, whether a shared folder in the file system, an intranet web site, or another form of data sharing within your organization. The text mentions placing the original documents in the library with links to PDF copies. In practice, it is often best to keep the originals off line, and to store PDF versions as the ones the general staff may access. In a well run library, there will be follow up dates for reviews, revisions, and eventual retirement of policies.
• Awareness and training - As we have discussed before, the organization has an obligation to inform staff about new or changed policies, to keep them aware of continuing issues, and to train or educate staff as needed to perform their jobs properly under such policies. Training means to show someone how to do a job. Educating means to teach someone how a thing works, so they might think for themselves as needed, and continue to learn about the tools in question.