ITS 3050 - Security Policies and Auditing

Managing Risk in Information Systems
Chapter 2, Managing Risk: Threats, Vulnerabilities, and Exploits
Chapter 4, Developing a Risk Management Plan

Objectives:

This lesson presents more terminology and planning ideas in chapter 2, and material about components of a risk management plan in chapter 4. Objectives important to this lesson:

1. Managing threats
   
2. Managing vulnerabilities
   
3. Managing exploits
   
4. Risk management strategies
   
   
5. Objectives of a risk management plan
6. Scope of a risk management plan
7. Assigning responsibilities
   
8. Procedures and schedules
9. Reporting requirements
10. Plans of action and milestones
11. Charting progress
    

Concepts:

Chapter 2

Let's examine the list of threat categories that begins on page 31.

Unintentional Threats

• Environmental - IT damage can be caused by weather related disasters. The text lists floods, tornadoes, hurricanes, earthquakes, and volcanoes. Buying insurance against possible threats is one way to handle them. Another is to move the company away from them, in whole or in part.
• Human - Employee errors and omissions lead to procedures not being done, or being done ineffectively. Systems can be automated to reduce human error, software can be error trapped to reduce data being entered incorrectly or not being entered where it is needed. Input validation for computer forms is a usual place to start.
• Accidental - The text describes a construction accident with a backhoe. I know of an instance in which a train derailed and cut a fiber optic line, cutting off data services for hours. Requiring our staff and our contractors to check for problems before they take actions is a place to start.
• Failure - All hard drives fail, eventually. Any piece of equipment can fail. The larger a system is, the more components it has, the greater the chance that something will go wrong before long. When failure happens, have we prepared for it?
  

Intentional Threats

The text begins with a short list of motivations that can cause people to want to harm our organization. We can probably add to this list.

• Greed - stealing information to use it or sell it; stealing personal information to access accounts
• Anger - seeking to hurt the victim through destruction, damage, or disruption
• Desire to damage - sometimes the victim is not the reason, if the attacker simply wants to damage something and is seeking a vulnerability to will provide access

The text changes the topic a bit to talk about kinds of attackers.

• hackers - one of the buzzwords of computer system geeks, this one can mean anything; it is generally accepted to mean someone with more skill than an average user, may be a white hat (good guy) or black hat (bad guy). A hacker may break in to a system for a thrill, to show off, or to cause some kind of damage.
• cracker - according to your text, a hacker whose intent is to damage a system or steal data.
  
• script kiddies - attackers who use hacking tools that they don't really understand
• spies - computer attackers who are looking for specific data from specific systems
• employees - Computer security includes the concept of protecting data from people who aren't authorized to access it. What about protecting it from authorized users who want to give or sell it to someone else? What about authorized users who give out their password because someone asks for it? What about users who are no good at protecting their secrets?
• computer criminal - someone who uses a computer in the commission of a crime
  
• cybercriminals - a computer criminal whose crime also involves a network. They are often after some financial gain, which could be from data they can sell, actual fund transfers, or theft of financial instruments.
• cyberextortionists - a cybercriminal who may attempt to hold a system or its data hostage (extorting money for its release), or may threaten a system with damage unless money is paid to prevent it
  
• cyberterrorists - a cyberterrorist is defined as a system attacker whose motivations are ideological.
• advanced persistent threats (APTs) - may be related to state sponsored cyberterrorism, an attack that goes on indefinitely; The text references, but gives no details on Operation Aurora. Click the link for a Wikipedia article on the incident.

Page 34 gives a list of best practices for dealing with general threats.

• create and enforce security policies - The text says "a policy" but you will need several. A separate policy may be needed to address each threat, or to address the procedures you want different staff in the organization to follow.
• purchase insurance - policies to insure against losses due to fire, flood, wind storm, theft, and business interruption are common
• use access controls - grant users access to network resources once they have properly authenticated to the system; the text reminds us to use two principles
• principle of least privilege -  grant only the privileges needed, and only to the resources actually needed, not to other resources
• principle of need to know - grant rights only to individuals who need access to data, not to entire groups when all members do not need access
  
• use automation - automate processes that should be done the same way each time, such as making backups, to avoid human error
• use input validation - as noted above, restrict data entry to only the correct kind of data; checking data entries for validity can avoid problems like SQL injections
• provide training - regular training for all employees keeps them mindful of mistakes to avoid and proper procedures to follow
• use antivirus software - install and configure an antivirus solution to be proactive, and make sure that it is updated regularly
• use boundary protection - strategic placement and configuration of firewalls and intrusion detection products should be used at the Internet interface and between divisions of the organization
  

Page 35 takes us to a discussion about vulnerabilities. They can appear in any part of our IT systems. The text reminds us that a vulnerability alone does not cause a loss. It must be exploited by threat for a loss to occur, so it tells us to look for threat/vulnerability pairs, threats that match an existing vulnerability and are likely to cause loss. Upon finding such a pair, we should create a mitigation plan to reduce the vulnerability, the probable loss, or both.

Consider the table of threat/vulnerability pairs on page 36, each of which has a stated expected loss. Compare it to the same table on page 37 in which a column has been added to each line proposing a mitigation plan, an action plan to reduce risk.

Starting on page 38, this text has a longer list of possible mitigation plans/actions than most books we have used in this program.

• policies and procedures - what is our goal and what do we do to reach it safely
  
• documentation - systems documentation, procedure documentation, documentation for any job that exists in our organization with attention to security in such documentation
  
• training - not only initial training, but reminders, updates, congratulations to people and areas that are doing a good job.
• separation of duties - critical and financial operations should require at least two responsible staff, to assure that important functions cannot be performed by one hacker or one rogue employee
  
• configuration management - using approved equipment, enterprise images for operating systems, controlled updates and software installations leads to a predictable environment that can be maintained or reset more easily than one in which every computer may be different from every other computer
  
• version control - the text is talking about preserving old versions and creating new versions of documents and software whenever someone makes a change in either by use of a version control system
  
• patch management - Software companies, especially the ones who produce operating systems, are always patching and updating their products, typically when new vulnerabilities and solutions to them are announced. Managed organizations will test, modify, package, and push such patches and updates to their users, often on a monthly cycle with emergency pushes as needed.
  
• intrusion detection - if a product only does detection, it will notice an attempted or actual intrusion, and will probably tell someone; a detection system does not take action against the intrusion (may serve a network or only one device on a network)
  
• intrusion prevention - if a product reacts to intrusions, it attempts to stop them, contain them, or minimize their effects (may serve a network or only one device on a network)
• incident response - there should be a multidisciplinary team in place to handle significant security issues; this is different from the team that handles day to day calls to the help desk
  
• continuous monitoring - someone needs data on the big picture, to better update and customize our vision and goals
  
• technical controls - This is a control that uses automated technology, such as intrusion detection and antivirus software
  
• physical controls - This is a control implemented by physical barriers, such as locked doors, guard desks, and cable locks.
  

Last week we mentioned exploits, and the text brings them up on page 41. As a quick definition, an exploit is an attack. It is often an attack that is based on a known or suspected vulnerability. The text tells us that many exploits begin in the public facing part of a network, its public Internet presence. The author of the text is focusing on exploits are implemented by using a computer program to attack a target, but I think many people use the word more generally, to include other means of attack.

Some exploit types are discussed.

• buffer overflow - This is a general category, in which the attacker sends more data or impossible data to a system that is not validating inputs from the user. The stream of data sent by the attacker may include commands to the system, which may be followed because the overflow has caused the system to stop running the program it was running. In addition to system commands, the attacker may succeed in loading a program into the target system, such as malware, a virus, or a worm. (What are those things? Notes on them are available.)
  
• SQL injection - Instead of sending a program file, the attacker may send an SQL command, hoping that the data the system was expecting was about to be handed to a Structured Query Language interface. This can also be avoided by properly validating the data supplied by the user.
  
• Denial of Service (DoS) - The text describes one way to start a denial of service attack. The attacker sends a request to connect to a network, fails to complete it, then sends another request. This pattern is repeated many times, in the hope that the attack will prevent legitimate users from connecting to the system, or that the server will eventually hang and reboot.
  
• Distributed Denial of Service (DDoS) - This is like the DoS attack, but it is carried out by a number of computers under the control of the attacker. The attacking computers are called clones or zombies. They are typically machines that the attacker has previously attacked, and infected with a program to put them in the attacker's control. The actual DDoS attack on the target system may be as simple as sending as many pings as possible to it, tying up its communication lines and its attention.
  

The author uses a hypothetical foreign government to describe steps that an attacker might follow to find a target and prepare for an attack:

• discover public servers
• establish a list of vulnerabilities for known server types, match discovered servers against this list
• try old and new techniques against found servers to develop more vulnerabilities to add our list
• develop new programs to attack newly discovered vulnerabilities, giving us new exploits
• use old and new exploits to attack discovered targets
  

The method above depends on information that is found or known about vulnerabilities. The text lists several sources of known or discovered vulnerability data:

• blogs and newsletters published by security professionals
• forums where professionals discuss new discoveries
• 2600 - a quarterly magazine about hacking many kinds of systems; content varies greatly from one issue to another
  
• Common Vulnerabilities and Exposures (CVE) list - A master list of discovered vulnerabilities, using a standardized naming scheme
• patch Tuesday and exploit Wednesday - Microsoft typically puts out patches on the second Tuesday of each month; patches are often reverse engineered to determine how to exploit the vulnerability the patch addresses; exploits for unpatched systems are then created
  

Pages 47 and 48 provide a list of standard techniques to harden (protect) servers against common exploits:

• remove or change defaults - many systems have well known default privileged IDs and passwords: these should be changed every time a computer is set up
• reduce the attack surface - attack surface means the things that can be attacked, so we should stop running any services that are not needed by the device or its users; we should also remove unnecessary protocols, so the computer does not respond to attempts to use them
• keep system patches up to date - patches must be tested in managed environments, but those that are approved should be applied without further delay, to avoid attacks from the exploit Wednesday folks
• enable firewalls - there is no point in disabling all protocols (how could you do anything?) but you can filter traffic based on where it came from and by other rules if you use firewalls, at strategic places in the network and on individual machines
• intrusion detection/prevention - if your budget supports it, intrusion detection make sense, and intrusion prevention is better; note that only intrusion prevention systems take steps to stop an intrusion
• antivirus software - it should be a given that you want an effective antivirus solution, and an antimalware solution as well
• use configuration management - don't allow users to install anything; use enterprise approved operating systems, hardware, and software
• regularly perform risk, vulnerability, and exploit assessments - things change, so you should look for changes, new risks, and appropriate solutions on a regular cycle and when there is a significant change in your environment

The remainder of the chapter covers US federal agencies and their initiative to assist in protection of assets. Go over this material to get an idea of who does what and where to look for information.

Chapter 4

Chapter 4 puts several concepts from the first three chapters into focus. In the previous chapters, we have talked about concepts, definitions, and a bit about their utility. Now we put some of the pieces together to make a plan for our organization. The text uses the example of a company that is concerned about its web site. The text also complicates the example with a concern that the company has not been compliant with HIPAA rules. At the moment, that is a distraction better handled by another division of the company, so we will consider the web site and its risks.

In general, making our plan starts with identification. We assume that identifying assets has already been done.:

1. Identify threats - What can go wrong? The text lists three threats: attack from the Internet, hardware and software failure, and loss of Internet connection.
2. Identify vulnerabilities - With those threats in mind, how are we vulnerable? The text lists several vulnerabilities.
   1. no firewall
   2. no intrusion detection
   3. no antivirus software (and no updates?)
   4. no updates for the server
3. The text assigns staff to collect data. It is not clear what data that is. If we assume that the vulnerabilities listed above are only suspected vulnerabilities, then we should verify that they do exist or they don't. If they do, we need to propose remediations for them.
4. Identify costs of an outage. - The text reminds us to think about tangible and intangible costs, as well as cost to return to our normal state.
5. Provide possible recommendations - What should be done to reduce our risks? Can we reduce the vulnerability, the impact of the threat, or both? The text does not state that the recommendations in this step are only potential recommendations until the next two steps are done.
6. Identify costs of recommendations - What is the cost of each recommendation, and the cost of sensible combinations of recommendations? For example, if we are considering three antivirus solutions, we should consider the cost of updates for them as well, and consider the update cost as a necessary part of the cost of each choice.
7. Perform a cost-benefit analysis (CBA) - For each recommendation, or combination of them, what is the cost of implementation compared to the probable impact of the risk it protects against?
8. Accept, defer, or modify recommendations - Document the choices of management regarding the recommendations.
9. Create a POAM - The text does not define this acronym. It is a Plan of Action and Milestones. It is a silly phrase. We need to make a plan to implement the approved changes, including a timeline for doing so.

The text goes through this process with the HIPAA concern as well. Note that the process is the same, but the focus is different, leading us to examine different items in each step.

On page 89, the text introduces the scope of a risk management plan. If this plan is to address the entire organization, it requires approval and endorsement at the highest level. If the the plan is for a smaller area, the approving authority is at a lower level, and the boundaries of the project are much closer. Any project can suffer from scope creep, which means that we suddenly find ourselves burdened with a larger project than we planned, causing inevitable increases in cost, time, staff commitment, and resources needed. When changes of this nature happen to a project, the costs and timeline must be reconsidered and adjusted, or the project should not be allowed to adopt new aspects,

The rest of the chapter considers each of the major steps in the plan in detail, adding considerations such as who should participate in making the plan, finding the facts, and reviewing the proposals. Look over each section to prepare for doing the assignments this week.