Risk and Risk Management
Chapter 9 begins, as usual, with some stories. This time they are about property and data loss. The first topic in the chapter is risk. A risk is the probability of a loss. The text calls it the "likelihood that a threat agent will exploit a vulnerability". This is correct but misleading. It implies malicious intent, which may lead you away from considering the risk of fire, flood, or other natural disaster. These are threats as well, and they present risk as well. Later in the chapter, the text makes this clearer.
Management of risk is a process that takes several steps from recognition to action. To manage risk, the text presents five steps:
Components of risk management
You can't protect what you don't know about. A list of the assets must be made to determine what could be at risk. Having given us a list of five steps, the author gives us a list of five types of assets to inventory:
The text provides a template of information to collect about each asset, which will obviously increase the size of our collected data. After collecting all the data about what and where an asset is, the text tells us to assign a relative value to each asset. This is another concept related to accounting, but the text takes a general approach to it. Consider the bulleted questions on page 305 that might be asked when determining how important, valuable, or productive an asset is. The relative value could be based on any scale that is meaningful to your organization. The text proposes assigning values from 1 to 5, 5 meaning the asset is of the highest value.
Once the assets are identified, you need to identify the possible threats to each asset. It might be more practical to say that you identify the potential threats that are likely to occur. Consider the table on page 306. The list seems a bit haphazard, and some of the examples suggest threat agents, while others do not.
A more reasoned approach may be to use the attack tree tool illustrated on page 307. In this method, you start by postulating a particular threat. This is the root of the tree. The first level of branches are potential exploits that would lead to this threat being a reality. The next level of branches, if needed, explains how the exploits might be carried out. The author tells us that a fully developed attack tree would show every possible attack. Yes, except for the ones he hasn't thought of. Being sure you are prepared for everything and being wrong is also a threat. More threats to consider, and comments on them, are in this short article on TechRepublic.
This step identifies the state of our organization and the vulnerabilities that a threat agent might exploit. Only a few examples are given, but the author spends a major portion of the chapter on vulnerabilities outside this section. A different discussion of the subject is in this document, which points out that other industries and authorities may use different terms for similar concepts.
The wisdom in this heading seems to be that experienced appraisers will be able to identify things they have seen before and may notice related vulnerabilities. We should have people with different experience work together to conduct an appraisal. It is also recommended that we use software vulnerability scanners that are discussed in a few pages.
The purpose of this step is to determine the impact of each possible loss, attack, or exploit. The scale shown on page 309 can be used as a guide in assigning a category to each loss. Note that the language used is not precise, and could be reinterpreted by different people in the same organization.
Note that the impact scale in the Building Sciences article has fewer grades, which may make it harder or easier to use. I like their approach of placing each loss on two axes: impact of loss and vulnerability to threat. In the text, the author discusses some equations in a less than logical progression. Let's consider it this way:
At the end of this section, the author mentions that we need to determine the probability that the vulnerability will occur, but this would have to be done prior to calculating a value for the ARO mentioned above.
The text discusses three methods of addressing the identified risks:
The text returns to this topic and stays with variations on it for the remainder of the chapter. The first section is about vulnerability scanning tools, which obviously focus on IT vulnerabilities.
The text introduces the concept of using port addresses to identify processes, services, and applications that are running on a device. A server may have only one IP address, but it may be using several port addresses to keep track of sessions with multiple clients. The text presents the three classic divisions of port addresses:
The text mentions that you can go to the IANA web site to see the assignments for well known and registered ports. If you follow the link in the previous sentence, give it a minute to load. It is over 49000 lines of information.
Just because a port is assigned does not mean that it is in use, or needed in a given environment. Ports that are not needed can be blocked by administrators, which brings up the three port states listed on page 313. An attacker might use a port scanner to determine the state of a port on a given machine.
Back to the topic, the text tells us that an attacker will scan for any open ports on a system to try an attack on them. Likewise, organizations may scan for open ports to identify those that need to be closed to enhance security.
The text discusses software that can be used to map what devices are connected to a network at any given time. Page 314 shows an example of a text output which is really more of a list, and an example of a graphic output that shows logical connections through infrastructure devices. Note that this information is typically gathered through ICMP packets, the same mechanism that is used to perform a ping.
This sort of information is useful to network staff as well as to attackers, since both benefit from knowing the layout of a network.
A protocol analyzer, as noted in the text, can be a program or a standalone device. It may also be called a packet sniffer, or just a sniffer. Its purpose is to examine packets on the network, even those not meant for the device being used. Normally, NICs ignore packets that are not sent to their MAC address (or to a broadcast address), but a protocol analyzer puts a NIC in promiscuous mode, which means that it accepts all packets passing by, allowing the operator to gather them in a capture file for examination.
Note the list of uses in the book for which an attacker might run a protocol analyzer:
Note also that the use of a protocol analyzer on a network without authorization is generally forbidden in most environments. Doing this at your place of employment without authorization could place your employment in jeopardy, and may have more serious consequences.
This short discussion describes devices that would be of use to staff looking for the vulnerabilities that have not yet been identified on a network. Page 317 lists several capabilities of this class of device, but it does not mention how such a device performs its job, other than to say that it might include a port scanner and a network mapper. An example of this kind of software that is recommended for this course is Nessus, which is free for individual use outside enterprise environments.
Open Vulnerability and Assessment Language (OVAL)
OVAL is a reporting standard sponsored by the Department of Homeland Security to enable users to mine the data from vulnerability scans. Data written out in OVAL compliant files can be queried in SQL, can be displayed as XML, and can be understood across products.
We have already discussed passwords at length. One use of the programs described in this section is to test the strength of passwords in hashed files. This may seem like a good idea, but we should realize that it only tests the password against the sort of attack the cracking program knows how to perform.
The chapter ends with a short discussion of penetration testing, in which an authorized person attempts to attack a system as a real attacker would. Although real techniques are used, this is still meant to be a simulation of an attack, and no harm is expected to by done by the action.
Chapter 10 continues the discussion of vulnerabilities, extending into the area of audits. An audit is defined as you might imagine, as a close examination that results in a detailed report. The chapter is concerned with IT audits of security elements.
The first topic on page 333 is privilege auditing. In the context of this text, right, privilege, and permission are synonymous. They do not appear to have the separate connotations that they have in a Microsoft class where a privilege can be a set of rights that overrides permissions set at the object level.
The text reviews the terminology used earlier: the owner is responsible for determining rights, the custodian sets and maintains the rights, and the user exercises what rights are granted.
The text reviews the four Access Control models discussed in chapter 7 as methods to assign privileges:
Auditing System Security Settings
The text turns to some remarks about auditing the rights of users with regard to network objects. The concepts discussed here are good ideas, but they become very impractical in large networks. There is little chance that the intended, proper rights of a given user will be known to a network administrator when that administrator oversees thousands of users. Consider the list of steps in a review that are provided in page 335. Each step is more unlikely than the last. It reminds me of the way you would run access to an application if it were not popular, not used by many, or not out of development. A live application that is used by fifty thousand users cannot be managed this way.
It is worthwhile to review the list of file and folder permissions for Windows on page 335, and the much shorter list of permissions for Unix on page 336.
The text returns to the subject of Group Policies on page 336, which provide a much more dynamic way to control user permissions to network objects.
The topic of Log Management begins on page 340. You should review the types of logs discussed and the types of information typically found in them: