ITS 421 - Tactical Perimeter Defense

Chapter 2, Assessing Risk and Its Impact on Access Control

Objectives:

This lesson concerns risk assessment, which includes some special vocabulary. Objectives important to this lesson:

1. Terms and concepts about risk assessment and related controls
   
2. Threats and vulnerabilities
3. Asset values, situations, and liabilities
4. Case studies and examples
   

Concepts:

Chapter 2

The chapter opens with a discussion of risk, which is familiar to anyone who has lost money gambling, but the word means more than that when we are talking about protecting networks. Let's consider some of the vocabulary on page 19:

• Asset - information, property, people or anything else that we care about
• Threat - a potential form of loss or damage; many threats are only potential threats, but we plan for them because they might happen
• Threat agent - a vector for the threat, a way for the threat to occur; could be a person, an event, or a program running an attack
• Vulnerability - a weak spot where an attack is more likely to succeed
• Exploit - a method of attack
• Probability of occurrence - the odds that a particular threat will exploit a particular vulnerability successfully
• Impact - the kind (e.g. money, productivity, customer confidence) and scale (usually expressed in dollars) of loss that an occurrence would have on an organization; a high score here means we should concentrate some of our limited budget on a particular asset
• Risk - The text defines this twice, the first time using words it defines later in its list. It is easier to understand the long definition after you look at the items above this one. It says risk is the probability that a particular threat will exploit a vulnerability causing harm to an organization.
  
  The second version says that we can quantify risk by saying it is the probability of an occurrence multiplied by the impact of that occurrence. Isn't it nice to be able to do math?
  
• Control - A process that we put in place to reduce the impact and/or probability of a risk.

The effects and the causes of risk are concern for everyone in an organization. The systems, the users, the policies, and the threat agents all affect whether there will be a successful attack on our organization.

On page 22, the text discusses a few important access control threats:

Password Cracking

Most people would rather not use passwords at all, so it is the system administrator's job to force them to use something. The text describes a typical scenario in which a minimum password length is set, along with a complexity rule that the password must contain upper case, lower case, and numeric characters. Often a password policy would give users the choice of using symbols along with or instead of one of those character types. I believe the authors chose to simplify the math for their tables on pages 22 and 23 by limiting the number of possible characters. By the way, the authors use the words combination and permutation as though they were synonyms. They are not. This takes us to math again. Sorry, but this is necessary.

The area of math we need for a few minutes is called probability, which was created by Blaise Pascal and Pierre de Fermat, two mathematicians who created this area of mathematics after Pascal was consulted by Antoine Gombaud, a French writer who kind of pretended to be a nobleman, and who couldn't understand why he was losing money gambling on games he had made up himself. The story is worth reading, and so is this part of math. The point is that combinations and permutations are two different things.

The table on page 22 is correctly labeled as a table of permutations. If the order of the characters did not matter, that would be a combination. Let's consider an example with only numbers, and only three characters. 123, 132, 213, 231, 312, and 321 would all be equally acceptable: those are the possible combinations of those three digits, and they all count as the same. In gambling, this would be the equivalent of betting on those three numbers and boxing them.

This is not how passwords work. Since the order of characters in a password does matter, that makes a password problem a permutation, which means that each of the variant combinations must be considered separately. When you calculate the number of possibilities in a permutation, you do as the authors have done, You multiply the number of possible characters (n) times itself for each position in the password (r). If we have ten digits, know the length is three, and know that repeats are allowed, the number of permutations would be 10 * 10 * 10 = 1000. The equation for that is just n^r.

When the order does not matter, the equation changes considerably, resulting in a much smaller answer. Follow the link in the last sentence to a very good math lesson on the two concepts. Read the lesson behind that link if you don't understand factorials. If you do, the equation for the answer is (n + r -1)! / (r! * (n - 1)!). The answer is (10 + 3 -1)! / (3! * (10 - 1)!) = 220. There are only 220 combinations of three characters in a ten character universe, if order does not matter. If that looks terrible, don't worry. We will talk about it in class.

Back to our text, the reason we care about all that math is that it give us a way to understand the math on page 22. The more possible characters in each position, the greater the base number that must be raised to a power equal to the number of characters actually used in the password. This is why the table on page 22 looks like it does. Each row in the table holds numbers that are exponentially larger than the row before it. The table on page 23 explains that we care because it would take a hacker an exponentially longer time to crack a password by the brute force method: trying every possible password until the right one is discovered. The times in the chart, by the way, are theoretical. The actual time it would take would be determined by the time it takes to try a login, the number of failed logins you can before a your account is locked out, the duration of the automatic lockout, and whether the hacker know how long your password is to begin with.

The attacker our text is describing is in fact trying variations on user IDs as well as variations on passwords. This is much more complicated than trying to hack into a system when user IDs are known, or can be guessed. Let's join our authors on page 24. If the attacker is trying to break into our system by using passwords. Having broken in as a random user is not very valuable for a hacker. That only results in the access that has been granted to the hacked account. As the authors point out, the next step may be to learn about other users on the system, and to hack those accounts that we guess have heightened access, rights that can lead to full access to the system. Is there a better way to start an attack? The authors take a detour into another approach that works well, social engineering.

Social Engineering

Social engineering is working the users of a system like a con artist. Think of Leonardo DiCaprio in Catch Me If You Can, interviewing an airline official to get the information he needed to impersonate a pilot. In the same way, a hacker can ask people for account information and get it because the people being asked often put no effort in keeping the information secret. It is probably true that people are the weakest link in any security chain. A social engineer would love to learn that the password policy shown on the right was actually in force for a target organization. What changes would you make to this terrible example of a policy?

Shoulder surfing, is another useful technique: watching a user type to learn ID, password, and other useful information. This is also social engineering, and so is paying attention to what people do. Of course, to do that you have to be inside the possibly secure facility. That's not a big problem in most cases. The text mentions a classic example of tailgating, following an authorized user through a door that requires you to scan an ID to pass through it. The hacker in the text had his hands full of briefcase, coffee cup, keys, and a box of doughnuts. He smiled and asked for help getting through the door. People usually oblige that request. Around holidays, presents are also a good ruse, as well as anything else allowed in the office, like a potted plant, or a bouquet of flowers. Anything to make you look like a nice person whose hands are too full to use your own ID to open the door.

Access Control Vulnerabilities

The text explains that passwords should never be stored on a system in an unencrypted form. A file full of such information is too valuable to hackers to allow it to exist. Most network operating systems provide a method that encrypts a password before a user submits it for authentication using a hash function. A hash function takes a plaintext block of any size and converts it to an encrypted block of a specific size. This is often done with passwords and PINs. The idea is to use the same hash function each time a user enters a password, and to compare the hash to a stored version of the hashed password, which is the only version of the password that is saved on the system. This method makes sure that anyone reading the file that holds the hash versions cannot know what the actual passwords are. Hash algorithms work only in one direction: you can't use the hash algorithm to decrypt the hash output. You can only compare to see if the hash of the user's input matches the saved hash.

An experienced hacker could use rainbow tables, in an attempt to work around the hash. A rainbow table holds the hash values of known words and numbers. The idea is to capture a user's hashed submission, then compare it to the data in a rainbow table. If the hacker finds a match, the password is no longer secret. How do you capture the hash? That's what is actually stored in the system. If the attacker can access the Security Account Manager data file on a workstation or server (Windows), that's helpful because it contains the encrypted passwords for known users. No user on the system should be granted more rights than are needed to do the work they should be doing, but every system has some user IDs that must be granted the highest level of rights. The text warns us that there are also instances in which an application must have specific high level rights (to a folder or a file), but it should never be necessary to grant administrator level rights to the whole system.

Risk Assessment

The text returns to the concept of risk assessment on page 26. It poses a good question that has more than one answer. How shall we count the value of an asset? This is easier to answer once we choose between two points of view:

• Quantitative Risk Assessment - Every asset must be given a currency value of some sort that can be used in the measure of its impact on the organization. Several methods of assigning this value are discussed.
  • Replacement cost - What would it cost us to replace this asset if it were compromised or destroyed in an attack? If a partial loss is possible, what would be the value of each part of it?
  • Purchase cost - What did the asset cost to acquire it or develop it?
  • Depreciated cost - If the asset loses value over time, at what rate is it lost, and what is it worth now?
• Qualitative Risk Assessment - In this method, every asset is given a relative value, not a currency value, which means that each must be measured against the others in terms of its worth to the organization

The text continues with a discussion that leads to a complicated calculation. You need to pay attention to each step. The text presents the concepts in a different order than I have seen before. I think this one is clearer:

• Asset Value (AV): the value that an asset has for the next several calculations; this value may be different depending on the context of its use
• Exposure Factor (EF): the percentage of the value that would be lost in a single successful attack/exploit/loss; this accommodates the idea that an entire asset is not always lost to an attack
  
• Single Loss Expectancy (SLE): this is a number that can be obtained by multiplying AV times EF.
  SLE = AV * EF
  
• Frequency of Occurrence: this number tells you how many attacks to expect in some time period; this is ambiguous if we are not told whether this is the rate for all such attacks, or the rate for all such successful attacks
  We generally assume that the number given is the rate at which successful attacks occur.
• Annualized Rate of Occurrence (ARO): often, known frequency of occurrence may be expressed in days or hours, but the executive you report to may want the numbers expressed in years. This is understandable if, for example, we are talking about establishing a yearly budget for IT Security. Reporting is often done based on calendar or fiscal years, which is another argument for making this conversion.
• Annualized Loss Expectancy (ALE): the final number stands for the currency value of our expected loss for a given asset in one year; provided you have calculated the numbers so far, ALE equals SLE times ARO.
  ALE = SLE * ARO

Risk Management Strategies

The text lists four major strategies for managing risk in your environment. Here are five:

• defense (avoidance) - make every effort to avoid your vulnerabilities being exploited; make the attack less possible, make the threat less likely to occur; avoid risk by avoiding the activity associated with the risk, and by providing an active defense against it
  
• transferal (transference) - in general, letting someone else worry about it
  In the ITIL model, this is included in the definition of a service:
  "A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks."
  A reader might misunderstand this statement, thinking that the customer does not pay anything. That is not the case. An IT service provider would assume the costs and risks of an operation in return for the customer's payment for the service. This can be done in-house or by outsourcing.
  
• mitigation (mitigation) - this method seeks to reduce the effects of an attack, to minimize and contain the damage that an attack can do; Incident Response plans, Business Continuity plans, and Disaster Recovery plans are all part of a mitigation plan
  
• acceptance (acceptance) - this counterintuitive idea makes sense if the cost of an incident is minimal, and the cost of each of the other methods is too high to accept; the basic idea here is that it costs less just to let it happen in some cases, and to clean up afterward
• termination (not listed in the text) - instead of accepting the risk of leaving the asset open to attack, the owner may choose to remove the asset from the environment that holds the risk of attack; it is arguable that any environment can be totally safe, but it may be possible to move the asset to an environment that presents different, lesser risks; if this is not possible, the owner may choose to stop offering a service, stop presenting data to the public, or otherwise stop exposing such an asset to risks

The text continues with a multipoint discussion about making risk assessment an ongoing strategy. It boils down to the idea that things change, that you need to make sure of what you own, what it is worth to you (now and in the future), and how much effort you should spend to protect it. So, we have spent some effort finding out what we have, ranking the assets by some scale, and determining that we should do it again this time next year. Now what?

Now, we think about the means to protect some of those assets. The text points out that firewalls and managed switches can protect multiple devices on the segments of our network that flow data through them. In a managed environment, we can set policies that manage the rights to every device, but it makes sense to use the economies afforded to us by traffic choke points in our networks.

The text also suggests that we take a multilayered approach to security. This means that a security solution will have multiple layers, requiring an attacker to get through several kinds of protection before accessing data. Diversity should be part of the layering concept. Diversity means that each layer of security is different in some way from the other layers, so an attacker will not be able to use the same exploit to get through all the layers. A layered approach is also called a defense in depth.

Security for Staff

The text tells us that we should spend some time on training our users in security. A better way to think about this is to think about having a Security Education, Training, and Awareness (SETA) program. There are three parts to a SETA program, two of which apply to all of our employees, one applies to our technical/professional staff:

• Education - ongoing education for the professionals who perform the customer service and compliance functions noted earlier in the chapter; professional staff in this area will need periodic enhancement of their skills and knowledge, regardless of whether the organization requires staff to pursue formal certification
  
• Training - training generally means teaching someone how to do something without necessarily teaching them the formal knowledge that a professional employee may need; training in this sense is the practical information that people need to do a job that is not an IT security job, such as knowing how to update the virus signatures on a workstation, or knowing how to scan a file or a hard drive for viruses; training will need to be refreshed or updated as your environment changes; different training may be offered to staff who perform different jobs or who have different skill levels
  
• Awareness - this part of the program is a reminder to staff to be aware and act on their awareness, to promote new information as needed, to remind users to use the training related to their jobs

Security for Workstations

The text discusses three protection methods that apply to workstations:

• Virus scanning - update your anti-virus signatures regularly, and use live protection
• Operating system patches - have a regular patch program, keep workstations updated when new vulnerabilities are discovered
• Host firewalls - most enterprise anti-virus products also include host level firewalls; make a good choice and keep it updated

Security for LANs

The text recommends that we concentrate on three items to protect each LAN:

• Implement a network intrusion detection and prevention system (NIDPS)
• Scan all email
• Implement server-level virus scanning

Security for LAN to WAN links

Our security measures can only extend over what we control, so we should take particular measures to protect at the boundary, the perimeter, between our assets and the rest of the world.

• firewall - a filter that denies or allows particular kinds of network traffic; a firewall for a web server might allow traffic on port 80, which is used for HTTP traffic, but deny it on most other ports; a firewall might also allow or deny traffic based on IP address, domain name, or the state of the connection; stateful firewalls are preferred over stateless firewalls
• DMZ - I have never understood why this term is used. 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 connection with the other parts, and holds no assets that the rest of the world may not see. Another text 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.
• proxy server - a server that receives requests, then forwards them to the actual server that will meet the request; the proxy server acts like a firewall filter, refusing requests that it has been told are invalid, and it acts like a DMZ device, protecting the "real" network from the outside world
• application gateway - typically a server that acts like a proxy server, but it does so to protect an application, not another server
• Intrusion Detection and Prevention Systems (IDPSs) - this time the name is accurate: an IDPS watches what happens on a network, notices unusual behavior (detection), and acts to stop attacks in real time (prevention). The text points out that this kind of system may run on a network for general protection, or may run as a service on a particular host for more local protection. (In case you have not run into that word, any device that is connected to an IP network, and has a network address, is called a host.)

Security for Remote Access

Staff who must connect to our network remotely should be enabled to use Virtual Private Network connections. They should also be trained to never make a connection through any unencrypted wireless channel.

Security for Systems and Applications

This is like the security for operating systems mentioned above. The best approach relies on security patches from the publishers of the software involved, as well as protecting the devices that use this software with the methods listed above.

Case Studies

The text ends the chapter with some observations about what should be done in particular situations. The first is a private sector company described as having a border firewall and a DMZ for its web servers. They had installed anti-virus and spam protection for their email system. They were also using some access controls, but we are not told what they were.

The text proposes a series of steps toward improving this system:

1. Do a risk assessment
2. Move high risk systems to their own LAN, and protect that LAN better
3. Increase protection at the border firewall
4. Install a network based intrusion detection and protection system
5. Install automatic patching on the web servers
6. Install host based firewalls and host based antivirus systems on the web servers (they were not benefiting from the network solutions)
7. Allow maintenance on the web servers only from privileged logins directly on those devices
8. Identify systems in the DMZ that are being attacked. Move them to a separate protected LAN. Install proxy servers and application firewalls for those systems.
9. Automate monitoring of the web systems, including log shipping (automatic copying of log files)
10. Audit all user rights, reducing those rights where they are not needed
11. Implement rights assignment to job related group objects
12. Establish a process to request elevated rights for individuals, including an assessment and approval/denial of those requests

The second case study is for a public sector agency whose security needs are meant to be strong. As an exercise, I will ask you to analyze the situation and proposed changes in this section.