ITS 305 - Security Policies and Auditing

Chapter 4, Business Challenges Within the Seven Domains of IT Responsibility
Chapter 5, Information Security Policy Implementation Issues

Objectives:

This lesson covers chapters 4 and 5. It discusses areas of IT responsibility and implementing security policies. Objectives important to this lesson:

1. Seven domains of IT infrastructure
2. Mitigating risk with policies
3. Building access controls
   
   
4. Human nature
5. Organizational structures
   
6. User apathy
   
7. Management support
   
8. Policies and roles, responsibilities, and accountability
   
9. Balancing employee performance and accountability
   

Concepts:

Chapter 4

This chapter begins with the idea that we can help our efforts to train employees if we view the enterprise as having seven parts, each of which may address the needs of different parts of the organization, or the needs of different kinds of users. The text refers to these seven parts as seven domains.

• User domain - any user of our systems falls in this domain, whether inside or outside our organization
  
• Workstation domain - not just computers, but any device our users use
  
• LAN domain - each LAN and the devices that make a LAN work
  
• WAN domain - the system that links devices across long distances; typically this is the Internet which is used by most businesses
  
• LAN-to-WAN domain - the infrastructure and devices that connect our organization's LANs to the WAN system
• Remote Access domain - the technologies used by our mobile and remote users to connect to their customary resources; can include VPN solutions and encryption technology
• System/Application domain - technologies used to actually conduct business functions, as opposed to making connections of various types

So, how does looking at our systems according to these labels help? The text discusses this for the rest of the chapter. Keep in mind that policies should always be posted on a company's intranet, and employees should be able to access them any time they are at work.

User Domain

The text tells us to begin protecting this domain by making users aware of the policies that affect them, and by training them to observe security precautions. It tells us that on-the-job training in these areas is more effective than classroom training, and it recommends assigning a job buddy or a mentor to show a new employee the right way to do a job. This is a good idea, but it depends on someone in each work unit to do the training. It relies upon that person being a good trainer, and on their knowing and caring about security. This will not always happen, so it is very important to design security policies that will protect the organization even when employees are not thinking about safe procedures. The automatic policies will reside in another domain. This one is about what users may and may not do.

• Acceptable use policy - This policy must contain specific examples of general principles, such as only using company assets for company business, not breaking any laws or company rules, and not exposing company data to corruption or theft.
• E-mail policy - This one must tell users what is acceptable and unacceptable regarding e-mail, such as no spam, no chain e-mail, and limits to allowed personal use of e-mail.
• Privacy policy - Protecting the private data of the company and its customers is very important. This policy should summarize applicable laws and regulations. It should also specify rules about data transport and encryption.
• System access policy - This policy is about how and when users may access the organization's systems. User ID and password rules belong here, as well as authentication procedures for particular networks.
• Physical security and clean desk policy - Many organizations handle data they consider to be sensitive, so there will be rules about access to doors, rooms, and data processing locations. This is physical security. A clean desk policy states that company data should never be exposed by being left open on a desk. This includes hard copy files and computer access, which leads to a policy about locking a computer before you walk away from your desk.
• Corporate mobility policy - Mobile device policies include wireless access methods and rules about use inside and outside the corporate buildings. It may also include rules about the acceptable and unacceptable use of personal devices accessing corporate data or e-mail. As the text mentions, there is a trend toward allowing this through a policy.
• Social networking policy - Social networks were not meant for the display of company data when they were created. People have done enough of that kind of posting that some organizations prefer to have their own pages on social network sites, managed by an office of information, and to have policies that forbid employees to post any data about company operations or staff. This is reasonable, given that such sites are commonly used by hackers when they are looking for background information before an attack.

Managing the user domain can be challenging. Consider the graphic on page 83, that shows two approaches. Assigning permissions to each user is fine in a small organization, but it is very complicated in large one. The problem is that as a person moves from one job to another in the organization, their permissions should change, but it becomes unclear what to grant and what to take away. Users tend to collect permissions from job to job, and it can become impossible to determine which ones they still need, newly need, or no longer need. The second method shown in the graphic is a role based access control (RBAC) which assigns permissions to groups, and users are taken into and out of those groups when their jobs change. This method requires less management, and is less prone to error. However, it requires coordination among the people assigning permissions. For example, having a group for the managers of a particular system means the staff maintaining group membership need to know about it, lest someone create another group for that purpose. Not a problem? What happens if some managers are put in one group, and some in another, and they don't have the same rights? How about if they are put in both groups? Should they be taken out of both when they leave that job? What if someone doesn't know about one? Even with these concerns, this method is better than assigning rights to every user.

Turning to page 92, the text discusses some recommendations that may help in dealing with users themselves:

• Awareness - Users need some kind of security training, as noted above. In addition, they should be reminded about security problems from time to time.
• Enforcement - This is an odd point, simply that security policies should require that no one be able to execute a high risk action without the approval of another party. A better point would be that there should be clearly stated consequences for the violation of any security policy the organization has put into effect.
• Reward - The text misplaces the concept of consequences for noncompliance, putting it here with the idea of rewarding/recognizing staff who are compliant with security policies. It suggests that employees might be given a score for compliance at an annual review. This is not likely to occur, since it is unlikely that we will be able to measure every work action on this scale.
• Monitoring - The text recommends quality assurance processes (making sure the right actions are taken the first time) and quality control processes (evaluating work after it has been done, perhaps by samples from every employee).
  

Workstation Domain

The text reminds (twice!) that the operational definition of workstation is any device used to access our systems. Typically, there will be policies that prevent most users from installing software, unless it is approved for general use. There may be administrative IDs that allow configuration changes, but these IDs and their matching passwords may be shared among staff who are assigned to install software. An RBAC solution is also possible, and more flexible. Shared IDs tend to require a change in shared passwords whenever staff changes take place. The text presents a list of functions that fall in this domain, which may require appropriate policies.

• Inventory management - logs devices that attach to our networks, builds lists of when they log in and from what locations
• Discovery management - logs the configuration of devices, including software, which provides data for other functions
• Patch management - pushes patches to operating systems and software, based on data stored about each device or on device membership in software management groups; should also include management of installed anti-virus and firewall software
• Help desk management - this one establishes a help desk, typically a call center, but often including remote and local hands-on support for users
• Log management - collects logs (such as event logs) from devices into a central location for analysis; may be used to find vulnerabilities or pattern of attack
• Security management - applies security measures, such as limiting or removing administrator level accounts on local devices

The recommendations in the text on pages 93 and 94 say essentially the same things.

LAN Domain

The text tells us this domain is about the devices and services that make a LAN. It also appears to be about devices that link LANs to each other.

• Switch - The text actually describes hubs as well as switches, so here is a short lesson. A hub is a device that has several RJ-45 ports. You can plug in as many devices as you have ports, then every signal that is transmitted by any device that is connected to that hub will be passed on to the rest of the devices connected to that hub. Some hubs can retransmit (amplify) the signals, but none of them decide where to send a signal. Any incoming signal goes back out all ports except for the one on which the hub received the signal. This means only one of those devices can transmit at any given time.
  
  A switch learns which devices are reachable on which ports by noticing the sender's MAC address on each incoming packet and making a list, called a Source Address Table (SAT). If a switch knows that a message is meant for a device connected to port 7, that's the only port that signal will be sent through. All other ports are available for other traffic. This is much more efficient than using a hub. It should be clear that switches increase the bandwidth inside a network by connecting only the devices that need to be connected at any given moment.
  
  For the purposes of our text, a switch may be configured to treat some ports as part of one LAN, and other ports as part of another LAN. Traffic may be restricted this way, or it may be allowed to flow.
  
  
• Router - Routers are typically used to connect two networks together, whether they are two LANs in the same building, or two LANs that are separated by a WAN link. The text says that routers connect a LAN to a LAN or a LAN to a WAN. This is also correct.
  
  
• Firewall - A firewall can be a device protecting a network (network based), or software protecting a single device (host based). Their purposes are similar, but a hardware firewall must handle much more traffic. Since they are meant to protect a large number of devices, a network firewall is typically placed at a traffic choke point. A good place is between the main switch for a network and the router that provides access to the Internet. It should be monitoring traffic flowing into and out of our network. Firewalls don't just monitor traffic. They deny traffic that they decide is dangerous to a network or a device, based on firewall rules put in place by a system administrator. Firewall rules are like policy restrictions that apply to packets flowing across, into, or out of a network.
  
  
• Flat network - A flat network gives every device on it the same potential access to every other device, without restrictions from firewalls, routers, or switches. This puts the burden of protection on the part of every device in the network.
  
  
• Segmented network - A segmented network is more like a collection of separate LANs. Each of them can allow or deny traffic through the connecting devices noted above.

The text recommends on page 95 that policies be created to restrict or forbid the use of live video, music feeds, and social media sites due to the time employees have been known to spend on them and the bandwidth that some of them take to use them.

LAN-to-WAN Domain

The most obvious device that belongs in this domain is a router. The text mentions another member of this domain, a DMZ. The letters stand for Demilitarized Zone, which is a military term for a geographic area in which contending forces do not place troops or other military assets. Its purpose in that context is to prevent conflict by establishing a buffer between two armed forces.

In the context of information system security, a DMZ is a part of your network that has no traffic flowing from it to the other parts. It holds no assets that the rest of the world may not see. Some texts calls it a "no man's land" but that is not accurate. We still protect this area with security measures, but we use it as an area where public business is conducted. The metaphor is flawed, as you should see, but it is commonly used so you need to know about it. The purpose of this part of the network is to provide information and services to the public, while keeping public access away from the secure parts of our network. As such, it is often the part of our network that connects directly to the WAN link leading to the Internet.

Monitor, Evaluate, and Assess (Fourth Domain)

Controls are tested and monitored in this phase. Testing takes place on the entire environment. We determine whether the controls are serving the big picture goals (business requirements, strategic goals) of the organization. The system is assessed and audited several ways:

• Self-assessment - usually performed by internal quality assurance and quality control staff
• Internal Audit - people inside the organization perform the audit and report to a controlling body or committee
• External Audit - an outside entity performs the audit, concentrating on organizational aspects that require an independent agent's view
• Regulator Audit - done when aspects of the organization fall under government regulation or legal requirements

On page 96, the text recommends that we pay close attention to the policies and equipment associated with the DMZ. It also recommends that we test this part of the network (and the rest, for that matter) with penetration testing, actual exploits staged by ourselves or by a contractor, to determine the success or failure of our security measures.

WAN Domain

As noted above, the most common WAN domain may be the Internet. In previous decades, there was no meaningful access to a usable Internet. That changed in the 1990s. Before that, leased data circuits from data service providers (typically telephone companies) served the purpose of providing wide area connections between data points for companies. The situation is different now, less secure, and more open to both commerce and attack.

On page 97, the text recommends using VPN solutions over the Internet as the most cost effective solution for WAN service. The text also suggests that if your security needs are very high, you may need to pursue leased lines from data service providers in some cases. The text does not discuss the fact that access to the Internet is not universal, and sometimes an older technology may be the only practical solution.

Remote Access Domain

The text explains that we can think of this as an extension of the User Domain, but the methods of connection are different, and authentication methods are typically stricter. Most security is based on one or more of three types of things: something you have (like a key or an ID card), something you know (like a PIN or a password), or something you are (like a fingerprint or the shape of your face).

When a person logs in from a standard workstation in a normal environment, one level of protection, like an ID and password pair, may be secure enough.

For a situation that is more vulnerable, like logging in from a remote location through a public data network, two levels (or two factors, as the text calls them) may be required, such as a user name-password pair along with a one-time password from a security device (that may require a Personal ID Number as well). You see the layers? My password (something I know) is no good unless I use the one-time key from the device (something I have), which is no good unless I know the PIN that proves I am allowed to use the device (something else I have to know). The one-time password shown in the image on the right, by the way, is only good for one minute. After that minute, a new six numeral code will be generated. Sorry guys, the minute for that key passed by long ago. Any complaints should be addressed to the Paladin of the Lost Hour. The device in the photo is an example of a hard token. The functions of such a device can also be implemented in software as a soft token, but I consider that to be a less secure idea. Using a soft token lets the hacker strike another object off his "have to steal all of these" list.

System/Application Domain

System software is usually the operating system of any computer or network. This includes the utility software that you find on most operating systems. Applications may be any programs used by the organization. The text merely discusses this on page 91, but does not present any connection to security.

The actual security discussion related to this class begins on page 99. The text recommends on page 100 that we use a Data Loss Prevention system for very sensitive data. A DLP system may be able to monitor where and when copies of such files are written, and by whom or what process. A virus or worm that is harvesting data will often have a recognizable signature that a DLP system should recognize.

Chapter 5

Chapter 5 returns to the author's concern that users are a key to security. He expands the concept to include stakeholders in the success of our organization, such as our vendors and customers. He then takes a strange turn into psychology, proposing that there are three elements that motivate employees to do a good job. His premise is that motivated employees will show better performance, and that when all three are present we can expect satisfied customers and increased profits.

I doubt his list is exhaustive, especially since he adds another factor (good leadership) in the next paragraph, but we should consider it:

• Pride - The author's observations are valid. People are more likely to put more effort into their jobs when they feel appreciated, and when they understand that their work contributes to a goal. The text warns us not to cause competition that leads to only one winner in a group. That could lead to motivation for one, and demotivation for the rest. Team successes are more valuable to an organization than individual successes because of this.
• Self interest - The text seems to propose evaluating staff on strengths and weaknesses, in order to show employees what they need to do to gain advancement, or to avoid reduction in status or pay. Praising accomplishment is good, but pointing out shortcomings can be a motivator as well, if it is done with a plan for improvement.
• Success - The text finally turns to an angle that supports security policies in this discussion. The premise seems to be that an IT security professional should make it clear that a successful security program will give the company a point of pride, will be in its self interest, and will contribute to the success of the company by fending off attacks that would lower our score on each of these measures.

The text goes into a discussion of personality types that takes just two pages. You may want to look it over, and think about the personality aspects that are discussed. Note, I said aspects, not types. I think that putting people in categories is dangerous. When you think of a person as having one set of characteristics, you begin to ignore the fact that they have other characteristics, interests, and motivators as well. In a way, it is like Shakespeare's line that "All the world's a stage, and all the men and women merely players. They have their exits and their entrances,
and one man in his time plays many parts..." (As You Like It, Act II, Scene VII).

I think it is a fine goal to determine what your people find motivating, and to supply that to them, but you may want to remember that no one is only one thing, only one aspect of a person. People find different things motivating at different times, and you won't do them justice unless you put in a bit of effort to know them and who they are presently. People are affected by the pressures on them, by their joy, by their sorrow, and by things we can only guess about until we know them. Don't rely on the evaluation from a personality test that only reflects, imperfectly, the image they projected at a single moment in time.

The text moves on to consider some qualities of a good leader that will lead to motivated staff. The advice is good.

• Have good values, and show them to your people.
• Set clear goals, communicate them to staff, and tell them why the goals matter.
• Make sure your people are trained in the things they need to know for their jobs, or the jobs they want.
• Support your staff by acknowledging their efforts even when they fail. Efforts fail, not people. Don't make failure personal when it isn't personal.
• Reward good effort, good behavior, and good results, not your favorite staff people. This is easy to mess up, so make sure you don't.

On page 113, the text turns to issues connected to organizational structure. This goes on for several pages, but the principle involved here does not take that much effort to explain. Security policies tell people what they should do. The text points out that it is unhelpful to tell someone to do something if they do not have the authority to do it, or if you do not have the authority to tell them.

• Rules about employee conduct that are outside the scope of a person's job are unimportant to that person. Don't waste your time telling everyone to maintain the firewalls if only five people in your organization do it. You are bothering everyone else and wasting their time.
• Rules about employee conduct may need to be handed down through a chain of authority over each person, which means the rules have to be endorsed by the leaders in the organization and passed down as many chains as your organization has.
• When cooperative actions need to be taken, your organization should coordinate the creation of rules about that kind of action. All groups who will participate in the actions should participate in the creation and endorsement of such rules.

The text spends one page on user apathy, which is a common response to communications that user feel do not affect them. Some advice is offered.

• Assume that some people will not comply with a policy. Build in redundant protections to catch the problems your policy is meant to cover.
• Explain why every policy, new or changed, is important to the organization and its employees.
• Use an employee awareness program, to regularly remind people about threats and what we do to minimize them.
• Make sure that the appropriate staff are made aware of policies, that they know that compliance is required, and that there will be monitoring and accountability.
• Reward compliance where possible, but avoid rewards that always go to the same people.

As we have already seen, the support of executive management is required for any change in an organization, such as adding a new policy about conduct or procedures. In fact, there is a need for management support at all levels. The failure to support a change by management at any level can affect the people below that level in the organization chart. The text offers some suggestions about selling ideas to executives. Some are worth remembering.

• Make sure that you have facts and measures to show that a policy is needed, and that it will be effective.
• Make sure you are selling the idea to the right person or people, in alignment with the structure of the organization.
• Make sure that everyone understands what the policy can and cannot do, will and will not do. Misunderstanding leads to disappointment.
• Make sure that the changes you propose to make are attainable. If a policy or change is too complex, people will not be successful with it.

The text also makes the point that there is a crossover between security policies and human resource policies. There must be an understanding in the Human Resources department about any policy for which there will be discipline for noncompliance. This is true of any work rule, and it is true for behaviors that jeopardize the security of an organization. For this reason, many security policies require a signature from each employee, or a button click when signing on a network, to signify knowledge of the policy and agreement to comply.

The text offers a list of roles associated with development, implementation, managing, and monitoring policies and the systems and data associated with them. The problem with this section is that these duties do not always go with the roles that are listed. If there is a separate IT security division in the IT department, then there may be people in those positions who carry out some of these duties. This is common in large organizations. In small ones, several these duties may be carried out by fewer people.

The chapter ends with a discussion of performance and accountability. It repeats some of the advice given earlier, that there must be a clear understanding of who is to carry out the technical duties that are associated with a security policy, or any IT policy for that matter.