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.
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.
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.
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:
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.
The recommendations in the text on pages 93 and 94 say essentially the same things.
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.
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.
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:
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.
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).
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 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 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:
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,
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.
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.
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.
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.
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.