Security Risk Management and Ethics PDF
Document Details
Uploaded by FruitfulDarmstadtium7355
King Faisal University
Mohammed Amin Almaiah
Tags
Summary
This document is a lecture on security risk management and ethics for computer networks and communications students at King Faisal University, Jordan. It discusses risk management, risk identification, and different perspectives on risk.
Full Transcript
Security Risk Management and Ethics Chapter Two: Security Risk Management Mohammed Amin Almaiah Computer Networks and Communications King Faisal University Chapter2: Topics This chapter covers the following topics and concepts: What risk management is and how it is impo...
Security Risk Management and Ethics Chapter Two: Security Risk Management Mohammed Amin Almaiah Computer Networks and Communications King Faisal University Chapter2: Topics This chapter covers the following topics and concepts: What risk management is and how it is important to the business. What some risk identification techniques are. What some risk management techniques are. Chapter2: Goals When you complete this chapter, you will be able to: Define risk management Describe risk management techniques Describe risk identification techniques Explain the relationship between the cost of loss and the cost of risk management Explain the risk management lifecycle Risk Management and Its Importance to the Organization Risk management is the practice of identifying, assessing, controlling, and mitigating risks. Threats and vulnerabilities are key drivers of risk. Identifying the threats and vulnerabilities that are relevant to the organization is an important step. You can then take action to reduce potential losses from these risks. It’s important to realize that risk management isn’t intended to be risk elimination. That isn’t a reasonable goal. Instead, risk management attempts to identify the risks that can be minimized and implement controls to do so. Risk Management and Its Importance to the Organization Cont., Risk management includes several elements: (1) Risk assessment—Risk management starts with a risk assessment or risk analysis. There are multiple steps to a risk assessment: Identify the IT assets of an organization and their value. This can include data, hardware, software, services, and the IT infrastructure. Identify threats and vulnerabilities to these assets. Prioritize the threats and vulnerabilities. Identify the likelihood a vulnerability will be exploited by a threat. These are your risks. Identify the impact of a risk. Risks with higher impacts should be addressed first. Risk Management and Its Importance to the Organization Cont., (2) identify risks to manage—You can choose to avoid, transfer, mitigate, or accept risks. The decision is often based on the likelihood of the risk occurring, and the impact it will have if it occurs. (3) Selection of controls—After you have identified what risks to address, you can identify and select control methods. Control methods are also referred to as countermeasures. Controls are primarily focused on reducing vulnerabilities and impact. Risk Management and Its Importance to the Organization Cont., (4) Implementation and testing of controls—Once the controls are implemented, you can test them to ensure they provide the expected protection. (5) Evaluation of controls—Risk management is an ongoing process. You should regularly evaluate implemented controls to determine if they still provide the expected protection. Evaluation is often done by performing regular vulnerability assessments. Role-Based Perceptions of Risk Ideally, all personnel within an organization will readily understand the threat to a company’s health if risk is not managed. Unfortunately, risks and risk management are often perceived quite differently. One of the challenges with effective risk management is achieving a proper balance between security and usability. Consider Figure 1.3. In the diagram on the left, the computers are completely locked down with a high level of security. Users are unable to use them to adequately perform their job. On the right, the computers are easy to use but security is neglected. In the middle, a balance between the two has been achieved. Role-Based Perceptions of Risk Role-Based Perceptions of Risk Cont., It is common for individuals in the followings roles to have different perceptions of risk: (1) Management— Management is concerned mostly with profitability and survivability. Since attacks can result in loss of confidentiality, integrity, or availability, management is willing to spend money to mitigate risks. However, their view of the risk is based on the costs of the risk and the costs of the controls. Management needs accurate facts to make decisions on which controls to implement to protect company assets. Role-Based Perceptions of Risk Cont., (2) System administrator—Administrators are responsible for protecting the IT systems. When they understand the risks, they often want to lock systems down as tight as possible. Administrators are often highly technical individuals. System administrators sometimes lose sight of the need to balance security costs with profitability. Role-Based Perceptions of Risk Cont., (3) Tier 1 administrator—Tier 1 administrators are the first line of defense for IT support (thus the “tier 1” part of the name). When a user needs assistance, a tier 1 administrator is often called. They may be more concerned with usability than security or profitability. These administrators are given limited administrative permissions. They often view the security controls as hindrances to perform their job and don’t always recognize the importance of the controls. For example, the need to use a change management process isn’t always understood. A well-meaning technician may bypass a change management process to solve one problem but unintentionally create another problem. These unapproved changes can result in business losses. Role-Based Perceptions of Risk Cont., (4) Developer—Some companies have in-house application developers. They write applications that can be used in-house or sold. Many developers have adopted a secure computing mindset. They realize that security needs to be included from the design stage all the way to the release stage. When developers haven’t adopted a security mindset, they often try to patch security holes at the end of the development cycle. This patching mindset rarely addresses all problems, resulting in the release of vulnerable software. Role-Based Perceptions of Risk Cont., (5) End user—End users simply want the computer to work for them. They are most concerned with usability. They often don’t understand the reason for the security controls and restrictions. Instead, security is viewed as an inconvenience. Well-meaning users often try to circumvent controls so they can accomplish their job. For example, USB thumb drives often transport viruses without the user’s knowledge. Companies frequently implement policies restricting the use of thumb drives. When a user needs to transfer a fi le from one computer to another, the USB thumb drive can be tempting. Risk Identification Techniques You learned about risk and losses earlier in chapter 1. Risk is the likelihood that a loss will occur. Losses occur when a threat exposes a vulnerability. In order to identify risks, you’ll need to take three steps: Step One: Identify threats Step Two: Identify vulnerabilities Step Three: Estimate the likelihood of a threat exploiting a vulnerability Step One: Identifying Threats “Threat identification” is the process of creating a list of threats. This list attempts to identify all the possible threats to an organization. This is no small task. The list can be extensive. A threat is any circumstance or event with the potential to cause a loss. Said another way, it is any activity that represents a possible danger. The loss or danger is directly related to one of the following: (1) Loss of confidentiality—Someone sees your password or a company’s “secret formula.” (2) Loss of integrity—An e-mail message is modified in transit, a virus infects a file, or someone makes unauthorized changes to a Web site. (3) Loss of availability—An e-mail server is down and no one has e- mail access, or a file server is down so data files aren’t available. Step One: Identifying Threats Cont.., Threats are often considered in the following categories: (1) External or internal—External threats are outside the boundary of the organization. They can also be thought of as risks that are outside the control of the organization. Internal threats are within the boundary of the organization. They could be related to employees or other personnel who have access to company resources. Internal threats can be related to any hardware or software controlled by the business. Step One: Identifying Threats Cont.., (2) Natural or man-made—Natural threats are often related to weather such as hurricanes, tornadoes, and ice storms. Earthquakes and tsunamis are also natural threats. A human or manmade threat is any threat from a person. Any attempt to sabotage resources is a man made threat. Fire could be manmade or natural depending on how the fire is started. Step One: Identifying Threats Cont.., (3) Intentional or accidental—Any deliberate attempt to compromise confidentiality, integrity, or availability is intentional. Employee mistakes or user error are accidental threats. A faulty application that corrupts data could be considered accidental. One method used to identify threats is through a brainstorming session. In a brainstorming session, participants throw out anything that pops into their heads. All ideas are written down without any evaluation. This creative process helps bring up ideas that may be missed when a problem is only analyzed logically. Step One: Identifying Threats Cont.., Some examples of threats to an organization include: An unauthorized employee trying to access data Any type of malware An attacker defacing a Web site Any DoS or DDoS attack An external attacker trying to access data Any loss of data Any loss of services A social engineer tricking an employee into revealing a secret Earthquakes, floods, or hurricanes A lightning strike Electrical, heating, or air conditioning outages Fires Step Two: Identifying Vulnerabilities You learned earlier that a vulnerability is a weakness. When a threat occurs, if there is a vulnerability the weakness is apparent. However, before threats occur, you’ll have to dig a little to identify the weaknesses. Luckily, most organizations have a lot of sources which can help you. Some of the sources you can use are: (1) System logs—Many types of logs can be used to identify threats. Audit logs can determine if users are accessing sensitive data. Firewall logs can identify traffic that is trying to breach the network. Firewall logs can also identify computers taken over by malware and acting as zombies. DNS logs can identify unauthorized transfer of data. Step Two: Identifying Vulnerabilities Cont.…, (2) Trouble reports—Most companies use databases to document trouble calls. These databases can contain a wealth of information. With a little bit of analysis, you can use them to identify trends and weaknesses. (3) Prior events—Previous security incidents are excellent sources of data. As evidence of risks which already occurred, they help justify controls. They show the problems that have occurred and can show trends. Ideally, weaknesses from a security incident will be resolved right after the incident. In practice, employees are sometimes eager to put the incident behind them and forget it as soon as possible. Even if documentation doesn’t exist on the incident, a few key questions can uncover the details. Step Two: Identifying Vulnerabilities Cont.…, (4) Incident response teams—Some companies have incident response teams. These teams will investigate all the security incidents within the company. You can interview team members and get a wealth of information. These teams are often eager to help reduce risks. (5) Audits—Many organizations are regularly audited. Systems and processes are checked to verify a company complies with existing rules and laws. At the completion of an audit, a report is created. These reports list findings which directly relate to weaknesses. (6) Certification and accreditation records—Several standards exist to examine and certify IT systems. If the system meets the standards, the IT system can be accredited. The entire process includes detailed documentation. This documentation can be reviewed to identify existing and potential weaknesses. Step Three: Estimate the likelihood of a threat exploiting a vulnerability Using the Seven Domains of a Typical IT Infrastructure Another way of identifying weaknesses is by examining the seven domains of a typical IT infrastructure. The following list gives you some examples in each of these domains: (1) User Domain—Social engineering represents a big vulnerability. Sally gets a call. “Hi. This is Bob from the help desk. We’ve identified a virus on your computer.” Bob then attempts to walk Sally though a long detailed process and then says “Why don’t I just fix this for you? You can get back to work. All I need is your password.” Step Three: Estimate the likelihood of a threat Cont., (2) Workstation Domain—Computers that aren’t patched can be exploited. If they don’t have antivirus software they can become infected. (3) LaN Domain—Any data on the network that is not secured with appropriate access controls is vulnerable. Weak passwords can be cracked. Permissions that aren’t assigned properly allow unauthorized access. (4) LaN-to-WaN Domain—If users are allowed to visit malicious Web sites, they can mistakenly download malicious software. Firewalls with unnecessary ports open allow access to the internal network from the Internet. Step Three: Estimate the likelihood of a threat Cont., (5) WaN Domain—Any public-facing server is susceptible to DoS and DDoS attacks. A File Transfer Protocol (FTP) server that allows anonymous uploads can host Warez from black-hat hackers. (6) Remote access Domain—Remote users may be infected with a virus but not know it. When they connect to the internal network via remote access, the virus can infect the network. (7) System/application Domain—Database servers can be subject to SQL injection attacks. In a SQL injection attack, the attacker can read the entire database. SQL injection attacks can also modify data in the database. Pairing Threats with Vulnerabilities One of the most important steps when identifying risks is to pair the threats with vulnerabilities. Threats are matched to existing vulnerabilities to determine the likelihood of a risk. The “Identifying Threats” section listed several threats. Table 1- 2 takes a few of those threats and matches them to vulnerabilities to identify possible losses. The following formula is often used when pairing threats with vulnerabilities. Example of Pairing Threats with Vulnerabilities Risk Management Techniques After risks have been identified, you need to decide what you want to do about them. Risk management can be thought of as handling risk. It’s important to realize that risk management is not risk elimination. A business that doesn’t take any risks doesn’t stay in business long. The ultimate goal of risk management is to protect the organization. It helps ensure a business can continue to operate and earn a profit. When deciding how to handle a risk you can choose to avoid, transfer, mitigate, or accept the risk. These techniques are explained in the following slides. Risk Management Techniques Cont.…, Risk management includes several techniques. They include: (1) Avoidance (2) Transfer (3) Mitigation (4) Acceptance (1) Avoidance One of the ways you manage risk is by simply avoiding it. The primary reason to avoid a risk is that the impact of the risk outweighs the benefit of the asset. An organization can avoid risk by: (1) Eliminating the source of the risk—The company can stop the risky activity. For example, a company may have a wireless network that is vulnerable to attacks. The risk could be avoided by removing the wireless network. This can be done if the wireless network isn’t an important asset in the company. (1) Avoidance Cont., (2) Eliminating the exposure of assets to the risk—The company can move the asset. For example, a data center could be at risk because it is located where earthquakes are common. It could be moved to an earthquake-free zone to eliminate this risk. The cost to move the data center will be high. However, if the risk is unacceptable and the value of the data center is higher it makes sense. (2) Transfer You can transfer risk by shifting responsibility to another party. This is most commonly done by purchasing insurance. It can also be done by outsourcing the activity. (1) Insurance—You purchase insurance to protect your company from a loss. If a loss occurs, the insurance covers it. Many types of insurance are available, including fire insurance. (2) Outsourcing the activity—For example, your company may want to host a Web site on the Internet. The company can host the Web site with a Web hosting provider. Your company and the provider can agree on who assumes responsibility for security, backups, and availability. (3) Mitigation You reduce risk by reducing vulnerabilities, and risk mitigation is the primary strategy in this process. Risk mitigation is also known as reduction or treatment. You reduce vulnerabilities by implementing controls or countermeasures. The cost of a control should not exceed the benefit. Determining costs and benefits often requires a cost benefit analysis. Some examples of mitigation steps are: (1) Alter the physical environment—Replace hubs with switches. Locate servers in locked server rooms. (2) Change procedures—Implement a backup plan. Store a copy of backups offsite, and test the backups. (3) Mitigation Cont., (3) Add fault tolerance—Use Redundant Array of Independent Disks (RAID) for important data stored on disks. Use failover clusters to protect servers. (4) Modify the technical environment—Increase security on the firewalls. Add intrusion detection systems. Keep antivirus software up to date. (5) Train employees—Train technical personnel on how to implement controls. Train end users on social engineering tactics. (3) Mitigation Cont., Often the goal is not to eliminate the risk but instead, to make it too expensive for the attacker. Consider the following two formulas. (1) Attacker’s cost < attacker’s gain—When this is true, it is appealing to the attacker. (2)Attacker’s cost > attacker’s gain—When this is true, the attacker is less likely to pursue the attack. Example: Cryptography is one of the ways to increase the attacker’s cost. If your company sends data across the network in clear text, it can be captured and analyzed. If the company encrypts the data, an attacker must decrypt it before analyzing it. The goal of the encryption isn’t to make it impossible to decrypt the data. Instead, the goal is to make it too expensive or too time consuming for the attacker to crack it. (4) Acceptance You can also choose to accept a risk. A company can evaluate a risk, understand the potential loss, and choose to accept it. This is commonly done when the cost of the control outweighs the potential loss. For example, consider the following scenario: A company hosts a Web server used for ecommerce. The Web server generates about $1,000 per month in revenue. The server could be protected using a failover cluster. However, estimates indicate that a failover cluster will cost approximately $10,000. If the server goes down, it may be down for only one or two hours, which equates to less than $3. (Revenue per hour = $1,000*12*365/24 = $1.37.) The decision to accept a loss becomes easier if you have evaluated the costs against the benefits, which is known as a “cost benefit analysis.” A cost benefit analysis is useful when choosing any of the techniques to manage risk. Cost-Benefit Analysis Any organization must perform a cost-benefit analysis (CBA) to help determine which controls or countermeasures to implement. If the benefits outweigh the costs, the control is often selected. A CBA compares the business impact with the cost to implement a control. For example, the loss of data on a file server may represent the loss of $1 million worth of research. Implementing a backup plan to ensure the availability of the data may cost $10,000. In other words, you would spend $10,000 to save $1 million. This makes sense. Cost-Benefit Analysis Cont., A CBA starts by gathering data to identify the costs of the controls and benefits gained if they are implemented. (1) Cost of the control—This includes the purchase costs plus the operational costs over the lifetime of the control. (2) Projected benefits—This includes the potential benefits gained from implementing the control. You identify these benefits by examining the costs of the loss and how much the loss will be reduced if the control is implemented. Cost-Benefit Analysis Cont., A control doesn’t always eliminate the loss. Instead, the control reduces it. For example, annual losses for a current risk may average $100,000. If a control is implemented, these losses may be reduced to $10,000. The benefit of the control is $90,000. You can use the following formula to determine if the control should be used: Loss before control - loss after control = cost of control Imagine the company lost $100,000 last year without any controls implemented. You estimate you’ll lose $10,000 a year if the control is implemented. The cost of the control is estimated at $10,000. Cost-Benefit Analysis Cont., The formula is: $100,000 - $10,000 (cost of control) - $10,000 (expected residual loss) = $80,000. One of the biggest challenges when performing a CBA is getting accurate data. While current losses are often easily available, future costs and benefits need to be estimated. Costs are often underestimated. Benefits are often overestimated. The immediate costs of a control are often available. However, the ongoing costs are sometimes hidden. Some of the hidden costs may be: - Costs to train employees - Costs for ongoing maintenance - Software and hardware renewal costs If the costs outweigh the benefits, the control may not be implemented. Instead, the risk could be accepted, transferred or avoided. (7) Risk on System/Application Domain The System/Application Domain refers to servers that host server level applications. Mail servers receive and send email for clients. Database servers host databases that are accessed by users, applications, or other servers. Domain Name System (DNS) servers provide names to IP addresses for clients. You should always protect servers using best practices: Remove unneeded services and protocols. Change default passwords. Regularly patch and update the server systems. Enable local firewalls. (7) Risk on System/Application Domain One of the challenges with servers in the System/Application Domain is that the knowledge becomes specialized. People tend to focus on areas of specialty. For example, common security issues with an email server would likely be known only by technicians who regularly work with the e- mail servers. NOTE: You should lock down a server using the specific security requirements needed by the hosted application. An e-mail server requires one set of protections while a database server requires a different set. Threats, Vulnerabilities, and Impact When a threat exploits a vulnerability it results in a loss. The impact identifies the severity of the loss. A threat is any circumstance or event with the potential to cause a loss. You can also think of a threat as any activity that represents a possible danger. Threats are always present and cannot be eliminated, but they may be controlled. Threats have independent probabilities of occurring that often are unaffected by an organizational action. As an example, an attacker may be an expert in attacking Web servers hosted on Apache. There is very little a company can do to stop this attacker from trying to attack. However, a company can reduce or eliminate vulnerabilities to reduce the attacker’s chance of success. Threats, Vulnerabilities, and Impact Threats are attempts to exploit vulnerabilities that result in the loss of confidentiality, integrity, or availability of a business asset. The protection of confidentiality, integrity, and availability are common security objectives for information systems. Figure 1.2 shows these three security objectives as a protective triangle. If any side of the triangle is breached or fails, security fails. In other words, risks to confidentiality, integrity, or availability represent potential loss to an organization. Because of this, a significant amount of risk management is focused on protecting these resources. Threats, Vulnerabilities, and Impact Cont., Threats, Vulnerabilities, and Impact Cont., Confidentiality—Preventing unauthorized disclosure of information. Data should be available only to authorized users. Loss of confidentiality occurs when data is accessed by someone who should not have access to it. Data is protected using access controls and encryption technologies. Integrity—Ensuring data or an IT system is not modified or destroyed. If data is modified or destroyed, it loses its value to the company. Hashing is often used to ensure integrity. Availability—Ensuring data and services are available when needed. IT systems are commonly protected using fault tolerance and redundancy techniques. Backups are used to ensure the data is retained even if an entire building is destroyed. Threats, Vulnerabilities, and Impact Cont., A vulnerability is a weakness. It could be a procedural, technical, or administrative weakness. It could be a weakness in physical security, technical security, or operational security. It’s only when an attacker is able to exploit the vulnerability that a loss to an asset occurs. Vulnerabilities may exist because they’ve never been corrected. They can also exist if security is weakened either intentionally or unintentionally. Example: Consider a locked door used to protect a server room. A technician could intentionally unlock it to make it easier to access. If the door doesn’t shut tight on its own, it could accidentally be left open. Either way, the server room becomes vulnerable. Threats, Vulnerabilities, and Impact Cont., The impact is the amount of the loss. The loss can be expressed in monetary terms, such as $5,000. The value of hardware and software is often easy to determine. If a laptop is stolen, you can use the purchase value or the replacement value. However, some losses aren’t easy to determine. If that same laptop held data, the value of the data is hard to estimate. Descriptive terms instead of monetary terms can be used to describe the impact. You can describe losses in relative terms such as high, medium, or low. As an example, NIST SP 80030 suggests the following impact terms: Threats, Vulnerabilities, and Impact Cont., (1) High impact—If a threat exploits the vulnerability it may: Result in the costly loss of major assets or resources. Significantly violate, harm, or impede an organization’s mission, reputation, or interest. Or, result in human death or serious injury. (2) Medium impact—If a threat exploits the vulnerability it may: Result in the costly loss of assets or resources. Violate, harm, or impede an organization’s mission, reputation, or interest. Or, result in human injury. (3) Low impact—If a threat exploits the vulnerability it may: Result in the loss of some assets or resources. Or, noticeably affect an organization’s mission, reputation, or interest. End