CSS 211 - Introduction to Network Security

Lesson 6 - Vulnerability Assessments, Security Audits

Objectives:

This lesson covers chapters 9 and 10 in the text. It discusses determining network vulnerabilities and conducting security audits. Objectives important to this lesson:

  1. Risk and risk management
  2. Components of risk management
  3. Vulnerability scanning tools
  4. Penetration testing
  5. Privilege audits
  6. Usage audits
  7. Monitoring for security anomalies
  8. Monitoring tools
Concepts:
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:

  • asset identification - what do we care about?
  • threat identification - what are the dangers?
  • vulnerability appraisal - how much could be lost?
  • risk assessment - how likely is a loss?
  • risk mitigation - how do we reduce the risk?
Components of risk management

Asset Identification

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:

  • data - all the information the company has, in all the forms it is kept
  • hardware - this is mainly about IT hardware; other hardware assets go under physical assets
  • personnel - this category is broadly defined to include employees, customers, partners, vendors, and any other people who come in contact with our company
  • physical assets - including what an accountant might call capital assets: buildings, cars, trucks, furniture, etc.
  • software - any software the company owns or uses

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.

Threat Identification

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.

Vulnerability Appraisal

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.

Risk Assessment

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:

  • Asset Value (AV) = the monetary value of the asset
  • Exposure Factor (EF) = the percentage of the asset's value that would be lost to a particular attack (This will vary from one threat to another.)
  • Single Loss Expectancy (SLE) = AV * EF
  • Annualized Rate of Occurrence (ARO) = probability of a loss in a particular year (This probability will include the possibility of multiple losses of the same type in a year.)
  • Annualized Loss Expectancy (ALE) = SLE * ARO

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.

Risk Mitigation

The text discusses three methods of addressing the identified risks:

  • diminish the risk - patch, make and enforce policies, enlighten staff about safer procedures
  • transfer the risk - obtain insurance against loss; possibly subcontract the service that incurs the risk
  • accept the risk - write off losses as the "cost of doing business"
Identifying Vulnerabilities

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.

Port Scanners

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:

  • well known - addresses 0 through 1023 are typically assigned to commonly used protocols that might be used by system or root processes
  • registered - addresses 1024 through 49151 are used by any application or service, and typically can be reallocated by users and programmers
  • private - addresses 49152 through 65535 are also called dynamic addresses which are allowed to be used by any application

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.

  • open - a service is available and listening on this port for requests; attempts to connect can be made
  • closed - no service is listening on this port; attempts to connect will be rejected with a reply
  • blocked - no replies are sent, no connections are made, no information is given

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.

Network Mappers

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.

Protocol Analyzers

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:

  • capture copies of files from reconstructed streams
  • read email
  • view web pages
  • read unencrypted passwords

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.

Vulnerability Scanners

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.

Password Crackers

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.

Penetration Testing

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.

Privilege Auditing

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:

  • Mandatory Access Control - users cannot reassign controls they are assigned
  • Role based Access Control - control is based on job function (group membership)
  • Rule based Access Control - users can be assigned to groups on the fly, based on rules
  • Discretionary Access Control - a user with full control can grant control to any other user

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:

  • security application logs
  • security hardware logs
  • operating system logs