CSS 211 - Introduction to Network Security

Lesson 9: Chapter 14, Security Policies and Training

Objectives:

This lesson covers chapter 14 in the text. It discusses security policies and end user training in them. Objectives important to this lesson:

1. Organizational security policies
2. Developing a security policy
3. Types of security policies
4. Training end users in security issues

Concepts:

Organizational Security Policies

Chapter 14 begins with some observations about the migration away from using social security numbers as identification numbers by various entities. In passing, the author warns that identity theft can also begin with numbers from bank accounts, passports, credit cards, and birth dates. This relates in a general way to the topic of the chapter, creating a security policy that might have guarding against this kind of theft among its goals.

Definitions

A bit later in the chapter the text attempts to put a security policy into context by describing security statements/documents. The discussion fits better at the beginning of our discussion.

• guideline - suggestions for using something in a safe or effective way; often published, but not necessarily mandated that employees comply
• standard - requirements about how a specific application or device may by used; typically published and compliance is mandatory
• policy - a longer formal document that may reference standards and guidelines, published to users at all levels, that defines what may and may not be done, what penalties are incurred by noncompliance with the rules contained in it; generally broader in scope than a standard, and it requires compliance, unlike a guideline

A security policy meets the definition above, but it is focused on one or more network/computer security concepts.

Trust and Control

On page 480 the author describes a balance that must be achieved between trust and control when writing a security policy. He points out that if you could always trust everyone, you would not need to control what they do. If you never trusted anyone, you would want to control everything they all do. His third alternative is not really apt. (I think he is trying to paraphrase Abraham Lincoln.) He says that you can trust some people some of the time. It may be more appropriate to say we can trust some things that people do, but not everything. This can be expressed in a couple of areas.

• How much authority shall a user have over a workstation? Can users install and remove software, or can only approved software be installed by IT staff?
• What web sites shall a user be allowed to visit, or be prevented from visiting?

The answers to these questions are decisions that might be included in a security policy. As I write this, I am reminded of another quote from Mr. Lincoln. He once said, "I have never had a policy. I have simply tried to do what seemed right, each day, as each day came." Maybe he would not have been comfortable in computer security, but it is worth remembering. Sometimes, the day brings something a policy did not anticipate.

Designing a Policy

A set of characteristics of a good policy appear on page 482. Consider them like a set of ingredients: more of one and less of another might be right for a particular policy.

• Contain a consensus of judgment from the people who created it
• Define appropriate/acceptable behavior
• Define what tools (software, hardware, connectivity devices, etc.) should be used, and how they should be used
• State the actions that authorities will take on discovery of noncompliance
• State penalties for noncompliance

Security Policy Cycle

The text provides three steps in the design cycle for security policies. The steps are reminiscent of the four steps in Continuous Quality Improvement: Plan, Do, Check, Act.

• Risk management study - as discussed in chapter 9, they must identify assets, threats, vulnerabilities, risk values, and risk mitigation
• Policy design/creation - a policy or policies are designed to enable the risk mitigation plans
• Compliance monitoring and policy evaluation - user compliance is monitored, and the success of the policy is evaluated, which leads to the study of risk management as the cycle begins again

Types of Security Policies

The text proposes that security policies should not be long documents. To meet this goal, an organization might have to create several policy documents that address specific areas of operation or concern. Page 485 presents a table of sixteen kinds of security policies. The text discusses nine different policies in more detail.

• acceptable use policy - what a user should use company equipment for, and what is specifically prohibited or limited
• security-related human resource policy - states what IT related actions must be taken when an employee joins or leaves the organization, especially what actions are taken when an employee is terminated
• password policy - this should include the requirements for creating an acceptable password (complexity rules), requirements for age limit, guidelines for creating a strong password, and requirements to keep passwords secret
• personally identifiable information policy - this policy typically relates to information given to an organization by clients and customers, and how that information may be used by the organization
• disposal and destruction policy - this relates to equipment owned by the organization, how data will be removed, how devices may be recycled, sold, or destroyed
• service level agreement policy - this can be an agreement on terms of service between the organization and its clients, or between the organization and its vendors and contractors; it should cover who is expected to do what, in what time frame, and what remedies exist for disagreements
• classification of information policy - the author does not explain this one well, but it may be a way to rank information by its perceived level of importance or sensitivity
• change management policy - this one is also described very generally, because it is meant to be a policy that describes how any major change to the organization should be applied, documented, and examined
• ethics policy - may be called a code of ethics or code or conduct; the text differentiates between values (beliefs held by individuals), morals (values from a belief system), and ethics (beliefs about right and wrong behavior held by a group); an ethics policy would contain a list of behaviors that are encouraged and others that are forbidden, which would provide a standard for all people in the group it applies to

Education and Training

The last section of the text concerns training end users so they will be able to handle some problems on their own.

Organizational Training

The text points out that organizations traditionally provide training to staff at particular events in a employee's career, such as hiring, promotion, and yearly inservices or retreats. It also points out that there are times it should be done such as when there is a hardware or software change, or when an IT related attack has happened that brings a new issue to light.

On page 493 the author presents a list of 20 year time spans and the traits that are supposedly linked to people born in those double decades. In general, he may have a point, but it does not seem relevant to the material in the chapter.

After a few more sentences he uses jargon (pedagogical, androgogical) to point out that you train/teach adults differently than you do children. At least most people would relate to the group a bit differently if you want to keep their attention. His list of information for the androgogical approach presumes that the adult learner is self motivated and wants to be in the training session. This is often untrue when you are trying to train busy staff in software that they will use infrequently.

The author continues to discuss the concept of learning styles. The year after the book was published, a study showed that the learning styles concept may not actually exist in any significant way. Students who have been convinced that they are only one kind of learner have been done a disservice. Let insects be specialized, we are adaptable beings. Read, listen, watch, and do: all methods are probably valuable.

Personally, I have doubts about the talk-to-each-other method. I particularly hate going to training sessions where they ask me to work out the wisdom of the universe by discussing issues with the other attendees while the people running the session have a coffee break. If they have some wisdom to impart, I don't need to waste my time trying to discover it. Let's hear it first, then discuss it.

Reducing Social Engineering

The last topic in the text is social engineering and teaching people to resist it. Some examples are given of ways to talk people into giving you information. The text then moves on to the problem of phishing, solicitation of personal or company information through an official looking email. Some variations on phishing are listed:

• spear phishing - sending the email to specific people, customizing it to look like a message sent to them by an entity with some of their personal information already
• pharming - sending an email that takes the person directly to a web site (the phisher's site) instead of asking the reader to follow a link
• Google phishing - the phisher sets up a fake search engine that will send people to the phishing web site on specific searches (presumably it returns real search results on searches that would not lead to a page the phisher has prepared)

Some suggestions are made about teaching people to avoid falling for phishing scams. Some are better than others:

• When an email has a web link in it, hover over the link and read the URL. It should go to a real web site, and should not contain web scripting commands or @ signs. This presumes that the user will recognize script commands and knows the real address of the entity being spoofed.
• Generic greetings can be an indicator of phishing, but real vendors might use them in a mass email.
• A message that asks for personal information and contains a link that goes to a web site that does not use https as its protocol is suspect, but that is not actually definitive. A user might be given a web address that will redirect them to a site using the proper protocol. Click if you must, but read the screen when you get there. That's when to check for https and the padlock icon.
• The author does not mention it, but lots of bogus emails have terrible spelling and grammar, which should never appear in an official email from a reputable organization. I wonder if this is done on purpose in the Bank Manager emails, so the reader thinks he/she might take advantage of the writer. If you can get the mark (meaning 13) to think he is the grifter, the swindle would probably be easier.

The text moves on to list a few more techniques which I believe are not really social engineering.

• dumpster diving - stealing or raiding someone's trash in hopes of finding personal information; not social engineering because there is no interaction with another person
• shoulder surfing - watching someone key in an ID, password, or both to steal their identity; not social engineering because the person did not reveal is, they simply did not hide it

The very last topic concerns computer hoaxes, which usually take the form of chain letters. There is often no request for money or information in these, but they do have the potential to waste time and IT resources. The author suggests that users can look for signs the email is a hoax, such as impossible claims (which they may not recognize) or attributing news to an unlikely source (which they also may not recognize). A more practical method would be to run the concept by snopes.com, a fine source for information about hoaxes and urban legends. Take a look regularly to see what people have been asked to believe lately.