Risk Identification Techniques

Risk Identification Techniques

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 includes several elements:
Risk assessment—Risk management starts with a risk assessment or risk analysis.

There are multiple steps to a risk assessment:

  1. Identify the IT assets of an organization and their value. This can include data, hardware, software, services, and the IT infrastructure.
  2. Identify threats and vulnerabilities to these assets. Prioritize the threats and vulnerabilities.
  3. Identify the likelihood a vulnerability will be exploited by a threat.
  4. These are your risks.
  5. Identify the impact of a risk. Risks with higher impacts should be addressed first.
  6. 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.
  7. 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 counter¬ measures. Controls are primarily focused on reducing vulnerabilities and impact.
  8. Implementation and testing of controls—Once the controls are implemented, you can test them to ensure they provide the expected protection.
  9. 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.
  10. 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.


How Risk Affects an Organization’s Survivability

Profitability and survivability were presented earlier in the chapter. You should also consider them when identifying which risks to manage. Consider both the cost to implement the control and the cost of not implementing the control. As mentioned previously, spending money to manage a risk rarely adds profit. The important point is that spending money on risk management can help ensure a business’s survivability.
As an example, consider data and backups. Data is often one of the most valuable assets a business owns. It can include customer data. It can include accounting data such as accounts payable and accounts receivable. It can include employee data. The list goes on and on. This data is integral to success of a business, so it is often backed up regularly.
Imagine that a business spends $15,000 a year on data backups. This cost will not increase revenue or profits. Imagine that in a full year’s time, data is never lost and the backups are never needed. If profitability is the only consideration, management may decide to eliminate this cost. Backups are stopped. The next year, data could be lost, causing the company to fail.
The cost does need to be considered against profitability, though. For example, if a company earns only $10,000 in profit a year, it doesn’t make sense to spend $15,000 a year to protect the data.
On the other hand, imagine a company with $100,000 in annual profits. They choose not to spend the $15,000 on backups. Then a virus spreads through the enterprise, destroying all customer and accounting data. The company no longer has reliable records of accounts receivable. No one has access to the customer base. This can be a business-ending catastrophe.


Risk Management Fundamentals

Reasonableness
A company doesn’t need to manage every possible risk. Some risks are reasonable to manage while others are not.
Reasonableness is a test that can be applied to risk management to determine if the risk should be managed. It’s derived from the reasonable-person standard in law. In short, you should answer this question. “Would a reasonable person be expected to manage this risk?”
Risks that don’t meet the reasonableness test are accepted. For example, the threat of nuclear war exists. A company could spend resources on building bomb shelters for all employees and stocking them with food and water to last 30 years. However, this just isn’t reasonable.
As another example, consider a company located on the east coast of Florida. Hurricanes¬ are a very real threat and should be considered. However, the likelihood of a major earthquake hitting the east coast of Florida is relatively minor and doesn’t need to be addressed. A business in San Francisco, however, has different concerns. An earthquake there is a real threat, but a hurricane is not. So, for San Francisco, the risk of a hurricane is readily accepted while risk of an earthquake may not be accepted.

Balancing Risk and Cost

The cost to manage the risk must be balanced against the impact value. The costs can be measured in actual monetary values if they are available. You can also balance the costs using relative values such as low, medium, and high.
Table 1-1 shows an example of how the relative values can be assigned. This matrix was derived from NIST SP 800-30. Likelihood values are shown vertically, while impact values are shown horizontally. If a threat has a 10 percent likelihood of occurring it is assigned a value of Low. If the value is between 10 and 50 percent, the value is medium.
Balanced security rarely satisfi es everyone. Security personnel want to lock systems down tighter. End users fi nd the security controls inconvenient and want more usability.
It is common for individuals in the followings roles to have different perceptions of risk:

  • Management—Management is concerned mostly with profi tability and surviv¬ ability. Since attacks can result in loss of confi dentiality, 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.
  • 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 adminis¬ trators sometimes lose sight of the need to balance security costs with profi tability.
  • Tier 1 administrator—Tier 1 administrators are the fi rst line of defense for IT support (thus the “tier 1” part of the name). When a user needs assistance, a tier 1 admin¬ istrator is often called. They may be more concerned with usability than securityor profi tability. 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.
  • 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.
  • 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 incon¬ venience. 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.

You can address the perceptions of these different role holders through targeted training. Some training can include all employees; other training should be targeted to specific roles. Targeted training helps each role holder better understand the big picture. It can also help them understand the importance of security and its value to the success of the company.
People responsible for managing risks must take all perceptions into account. This is especially true if any of the controls can be bypassed.
For example, theft of laptops is a common problem for some companies. An employee can leave the laptop to take a break at a conference only to come back and find the laptop gone. This risk can almost be eliminated if the company purchases hardware locks. The lock can secure the laptop to a desk or other furniture. However, if users don’t perceive the risk as valid, they may simply not use the lock. In addition to purchasing the lock, steps need to be taken to train the users.

Risk Identification Techniques

You learned about risk and losses earlier in this chapter. 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:
  • Identify threats
  • Identify vulnerabilities
  • Estimate the likelihood of a threat exploiting a vulnerability


The following sections explore these concepts.

Identifying Threats

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:


  • Loss of confidentiality—Someone sees your password or a company’s “secret formula.”
  • 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.
  • 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.

“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.

Threats are often considered in the following categories:

  • 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.
  • Natural or man-made—Natural threats are often related to weather such as hurri¬ canes, tornadoes, and ice storms. Earthquakes and tsunamis are also natural threats. A human or man¬made threat is any threat from a person. Any attempt to sabotage resources is a man¬made threat. Fire could be man¬made or natural depending on how the fi re is started.
  • intentional or accidental—Any deliberate attempt to compromise confi dentiality, 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 brain¬ storming 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. 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, fl oods, or hurricanes
  • A lightning strike
  • Electrical, heating, or air conditioning outages
  • Fires
All these threats represent possible risks if they expose vulnerabilities.

Of course, you will identify different threats and vulnerabilities depending on the organization. Every organization has threats and vulnerabilities specifi c to them. In fact, a business with multiple locations may have some threats and vulnerabilities unique to one location.

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:

  • 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 fi ndings which directly relate to weaknesses.
  • 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.
  • 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 traffi c 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.
  • 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.
  • 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.
  • 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.

Using the Seven Domains of a Typical IT Infrastructure to Identify Weaknesses

Another way of identifying weaknesses is by examining the seven domains of a typical IT infrastructure. These domains were presented earlier in this chapter. Each domain can be examined individually. Further, each domain can be examined by experts in that domain. The following list gives you some examples in each of these domains:


  • user Domain—Social engineering represents a big vulnerability. Sally gets a call. “Hi. This is Bob from the help desk. We’ve identifi ed a virus on your computer.” Bob then attempts to walk Sally though a long detailed process and then says “Why don’t I just fi x this for you? You can get back to work. All I need is your password.”
  • Workstation Domain—Computers that aren’t patched can be exploited. If they don’t have antivirus software they can become infected.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Summarized from the book Risk List and Control - Darril Gibson
Darril Gibson is the CEO of Security Consulting and Training, LLC. He regularly teaches, writes, and consults on a wide variety of security and technical topics. He’s been a Microsoft Certified Trainer for more than 10 years and holds several certifications, including MCSE, MCDBA, MCSD, MCITP, ITIL v3, Security , and CISSP. He has authored, coauthored, or contributed to 10 books including the successful Security : Get Certified, Get Ahead.



No comments:

Post a Comment

Contact Us

Name

Email *

Message *

Back To Top