Concepts:Chapter 9This chapter begins with the popular concept that the biggest problems we have in IT security are associated with people. The text tells us that people are subject to problems that automated defenses do not share:
The text continues with a discussion of three areas in which humans cause IT security breaches. These are not the only areas to be concerned about, but they are a good start. Social engineering is a label that is applied to any attempt to convince someone to do something that is to your benefit. In the context of IT security, a social engineer is often a con artist who is asking, fooling, convincing, or otherwise manipulating people into revealing secrets or granting access to systems. The author lists some classic social engineering methods:
The author remarks that social engineering is often preferred to more difficult hacking, because it is usually easy, fast, and effective. That is true for someone with the right skill set. Many hackers are not accomplished actors, but social engineers need to be. Think about it the next time someone calls your home "from Microsoft" and tells you they have noticed problems on your computer. Then hang up the phone, there is no point in talking to them. Human mistakes come from many causes. The text lists several,
but only discusses mistakes that it collects under the heading of carelessness. In fact, the examples
of carelessness the author gives to us might easily be called by
different names.
Insiders is the title of the third item about users. The text refers to a study that said 31% of data breaches in 2013 were due to employees, consultants, contractors, or vendors. The text points out that most of these people are in a position to know the information in the security framework, so they might each know about some of the weak spots in the defenses of an organization. They are more informed, and more likely to avoid detection should they decide to attack the organization. Every disgruntled employee has their own motivation. The text offers an example, stating that the average experienced help desk agent in the Philippines may make as little as $4000 per year. Selling company data may be very tempting. Stolen credit card information may be worth a very large sum to a reseller. The text proceeds with a discussion of seven types of users. The author presents some thoughts about each group, and adds two more in the list on page 240.
The text makes the point that if we cannot determine which user takes an action on a system, we should at least be able to narrow the search down to the user IDs that had the rights to take the action in question. This makes us more aware that we need to control the number of people who have access and control over sensitive information. The text returns to the idea of an Acceptable Use Policy (AUP), which it has presented before. Such a policy might best be viewed as a statement of a principle, and a starting point for ongoing discussion. No such policy can be exhaustive, it cannot cover all possible abuses of company equipment, because someone is always finding a new way to use company equipment for a purpose that it is not meant for. When new circumstances come up, the text recommends that they be discussed in awareness training, which could be video moment, a newsletter, or a topic to bring up at staff meetings. These methods are examples, and the nature of the business should lead to an appropriate choice that will allow discussion without threat or boredom. The text provides a list of topics you may want to cover in an AUP on page 252.
Your organization may require that users who are to be
assigned
elevated rights must sign or agree to a Privileged-Level Access Agreement (PAA). This agreement should lay out
the duties to be carried out when using elevated access, the company
policy on handling sensitive information, and other rules as deemed
necessary. The text presents a list of statements and promises that the
employee may be expected to agree to on page 253. These are some
highlights from that list:
Another policy related area covered in this chapter is a Security Awareness Program (SAP). Page 254 lists several laws we have covered already, and some new ones, that require that companies must have an SAP to instruct their employees in security issues. Following one or more of the schedules required by these laws will give a company the defense that they tried to follow the rules, should there be a breach of their data. Page 255 returns to several recommendations the text has
already made, and some standard recommendations that may or may not
help. For example, the idea that you should never open an email
attachment unless you know the person who sent it. That is not really
useful, since email accounts can be spoofed, and business email often
comes from someone we have not met or do not know. The advice about
encrypting all sensitive data is more useful, regardless of the medium
used to store or send it. The last topic in the chapter seems like a small point. The author draws a distinction between two methods of managing access that are almost identical:
In the second case, as in the example in the text, more privileges are assigned to users who do not always need them so that they can all be assigned to the same group. The benefit to the administrator is obvious. The benefit to the manager of these employees is that they can all use the same resources on the network if the need arises for them to do so. This results in employees having the rights and privileges to do the work of other employees who are missing, assuming the employees who are present have been taught how to do that work. This method should not be used when there is high security on the data that might be accessed by the users, or when trust in the employees is not certain. Chapter 10Chapter 10 takes us to some hardware related material. First
the author discusses three ways
to organize policies. He seems
to like organizing by functional area,
but warns us that this is disrupted with every reorganization a company
goes through. He considers the second method, organizing by layers of security, a
difficult one to use. Companies are free to classify various kinds of
security as falling in various layers of their own choosing. There is
no standard to naming the layers or placing products in them. That leaves the third method, organizing policies by the seven domains the author introduced us to earlier. The author acknowledges that this method has a problem as well: some security issues cross over several domains. This requires policies that address the differences between those domains, and the similarities between them. The author recommends that a compliance oriented approach may be adopted by choosing an industry standard model, such as the ISO or COBIT models. For those with no interest at all in the seven domains, here is some background information about the Seven Kingdoms:
Perhaps it would be useful to link the seven domains to the seven kingdoms? This can be an exercise for the student. The author presents a topic outline of a standards document on pages 266 and 267. This outline is similar, but not identical to the template he gave us in chapter 7. This material does not seem to fit the topic of this chapter, so we should move on. The author begins a discussion of Workstation Domain policies on page
267. He reminds us that encryption
is typically required for company information on portable devices, and
that this is an example of a workstation policy. Other policies for portable devices might include remote wiping if lost or stolen, and
lockout or data wipe on too many failed login
attempts. The methods to attain each of these results should be
documented in control standards
that relate to such policies. Standards define how something will be
done that a policy requires. As you should recall, that also leads to procedures and guidelines where they are needed. Control standards for workstations (examples):
The text reminds us that baseline standards are the basic requirements for device types, such as workstations, which may be modified by specific standards for users who require more advanced features. Some features to expect in baseline standards:
The text continues with a section on LAN Domain policies, which deal with
connectivity and traffic flow. This includes
policies, standards, and procedures about firewalls, switches, DoS protection, and WiFi Security. The text presents a
list of control standards for this domain on page 274. Note that it
includes security controls for routers
and configuration change
controls. A list of baseline standards for this domain appears on page
276. The LAN-to-WAN Domain
section includes policies, standards, and procedures about DMZ controls, Internet Proxy controls (do we use
them? which devices are they?), content
blocking and filtering
controls, and intrusion detection and
prevention controls. In the section on the WAN Domain, a bit of a flaw emerges in the plan for this chapter. There is a bit of crossover between this domain and the last one. We find switches and routers in both, so we are told that policies relating to those components may be handled in the LAN-to-WAN Domain, or in another domain, instead of this one. The text suggests that this domain may contain policies on DNS, on WAN management, on router security, and on web services. DNS policies may include creation of domain names in our registered domain. Moving ahead to the Remote
Access Domain, which concerns remote
connections, security
and encryption of devices and data , and remote authentication. Standards
should include VPN software
and gateways, VPN IDs, and RADIUS server issues. The last domain in the list of seven is the System/Application Domain. This
domain has some unique issues, among them determining who is the owner of programs and data, who will
grant access to them, and
who is responsible for their functioning.
Oddly, the text includes both cryptography
standards and physical security
standards in this domain. Maybe we need another domain or two? The text adds one more domain, this one on Telecommunications policies. This
can include telephone and data traffic, the wiring that supports both of those
technologies, the end user devices
and infrastructure devices
that interact with those technologies, and crossover technologies like Voice over IP (VoIP). |