A risk exposure is the impact to the organization when an event occurs. There are several ways to calculate risk exposure. Ideally, you want to quantify it within business terms, such as putting a dollar value on the losses. A generally accepted formula can be used to calculate exposure, as follows:

Risk exposure = Likelihood the event will occur × Impact if the event occurs

For example, if there’s a 50-percent chance that a $2 million loss may occur, the risk exposure would be $1 million (0.5 × $2 million = $1 million). This calculation, plus other assessments, can lead to understanding the total risk exposure of a business unit.

You can use different analytical methods to determine likelihood and impact. These methods fall into two types: quantitative and qualitative. Quantitative methods involve using numerical measurements to determine risks. Measurements may include a range of measurements, such as asset value and frequency of the threat. A shortcoming of quantitative methods is a lack of reliable data. This can be overcome by reaching a consensus on the use of industry benchmarks.

Qualitative analysis involves professional judgment. This means making a well-educated guess, so to speak. Qualitative techniques may include questionnaires, interviews, and working groups. Qualitative analysis can be used to adjust measurement created through quantitative methods.

These are very powerful tools that allow you to have an engaged conversation on risk with the business. When presented with the risk exposure, the business can accept the risk or fund its mitigation. It’s important that you discuss with the business any assumptions made in determining the likelihood or impact. This serves two purposes: It validates your assumption, and it also builds credibility for the analysis. This avoids the situation where the analysis is discarded as unrealistic.

When you combine the risk exposure and business impact analysis (BIA), you can see the direct impact on the business. This view of risk allows you to prioritize the risks. A risk management program creates a balance between reducing the most likely events and mitigating risks with the greatest impact. Controls addressing one risk can impact other risks.

Security policies and controls can reduce reputational, operational, legal, and strategic risk. This is accomplished by limiting vulnerabilities and reducing breaches, which builds consumer confidence.

Once you identify a risk, you choose a strategy for managing it. There are four generally accepted risk management strategies, as follows:

• Risk avoidance—Not engaging in certain activities that can incur risk. This is difficult in most situations.
• Risk acceptance—Accepting the risk involved in certain activities and addressing any consequences that result.
• Risk transference—Sharing the risk with an outside party.
• Risk mitigation—Reducing or eliminating the risk by applying controls.

Risk avoidance is primarily a business decision. You need to look at the risks and benefits to determine how important they are to the viability of the business. This is quite difficult to implement. For example, there is risk of malware if you use email; however, simply not using email is not a viable option.

Risk acceptance is either a business or technology decision. The business needs to know about risks that impact its operations. If the business does not think it is feasible or cost-effective to manage the risk in other ways, it must choose to accept the risk. There are a host of daily technology risks that are accepted by the IT department. Hopefully, these risks have a low probability of impacting the business. From a practical standpoint, not all risks can be formally accepted by the business. The key is to have a process by which risks are assessed and rated. This rating can be used to determine who has the authority to accept each risk.

Risk transference is taking the consequences of a risk and moving the responsibility to someone else. The most common type of risk transference is the purchase of insurance. For example, you might purchase data breach insurance that would pay your expenses in the event of a data breach. Transferring a risk does not reduce the likelihood that a risk will occur. It removes the financial consequences of that risk.

There is no one list of mitigation strategies. The mitigation strategy depends on the risks, threats, and vulnerabilities facing the organization. A grocery market protecting customer credit cards has a different set of threats than a nuclear power plant. Their mitigation strategies will also differ.

However, all mitigation strategies have a common objective: prevention. The prevention of risks is less costly than dealing with their aftermath. To be effective, you must have a process in place to identify risks before they threaten the business. Risk management policies promote a series of efforts that allow an organization to be always self-aware of risks. The following is a sampling of those efforts:

• Threat and vulnerability assessments
• Penetration testing
• Monitoring of systems, applications, and networks
• Monitoring of vendor alerts on vulnerabilities
• Active patch management
• Effective vendor management and oversight
• Aggressive risk and security awareness

These methods reduce risk. They also provide a source of new information about the environment. This information can be used to design better solutions and understand limits of the existing environment. You can measure the impact of these effects in reduced risk to data integrity, confidentiality, and availability.

Vulnerability assessments are a set of tools used to identify and understand risks to a system, application, or network device. Vulnerabilities is a term that identifies weaknesses in the IT infrastructure, or control gaps. If these weaknesses or control gaps are exploited, it could result in an unauthorized access to data.

There are a number of tools and techniques to perform vulnerability assessments. Here are a few examples:

• A vulnerability scan of a network
• A scan of the source code of an application
• A scan of an operating system’s open ports

It’s important to understand that these are tools, not assessments. They are valuable tools identifying potential weaknesses; however, the assessment comes from the analysis of the results. The assessment must address the vulnerability. It must also address the impact to the business and cost of remediation.

Security policies define when and how to perform a vulnerability assessment. The following are typical steps to be followed:

1. Scope the assessment.
2. Identify dependencies.
3. Perform automated testing.
4. Analyze and generate reports.
5. Assign a rating.

You need to scope the assessment and understand the environment prior to any assessment work. This work involves both technical and business aspects. You need to understand what business processes are being used on the internal networks plus what processes are being used externally through the firewall. Based on this information, you can assess the security policies, standards, and procedures. This should provide a comprehensive baseline to compare the assessment results against.

A comprehensive vulnerability assessment looks at the processes end-to-end. This is more effective than just looking at processes on an isolated component. For example, assume your organization has a network of car dealerships across the state. Also assume there is a VPN available to cross-check inventory and delivery of new cars. You conduct a vulnerability assessment. The assessment finds a control weakness that could prevent a car dealership from receiving new cars. That is a much more meaningful conclusion than, “XYZ server has open ports.”

Next, you identify dependent processes and technology that support each primary process. For example, remote access from home may be dependent on the security token. A security token is either a hardware device or software code that generates a “token” at logon. A token is usually represented as a series of numbers. A security token is extremely difficult (and some say impossible) to replicate. When assigned to an individual as part a required logon, the token provides assurance as to who is accessing the network. The home environment and the security token each creates a potential vulnerability. The home and token both need to be discussed beyond the firewall.

It is important to understand how information is used. For example, the assessment should address employee access, use, and dissemination of information. Network and application diagrams are good sources of information.

The use of automated testing tools is best practice. They can scan a large volume of vulnerabilities within seconds. The key takeaway is that the results must be examined and put into the context of the process and risk.

Automated testing tools call for you to rank threats in order of greatest risk. Classifying risks allows the organization to apply consistent protection across its asset base.

During analysis and reporting, you bring the data together and determine the business impact. Using the BIA results helps align risks to the business. For example, if the assessment includes a process that the business has already declared mission-critical, then the assessment can reflect that fact. This approach helps you assess vulnerabilities that deserve priority attention.

With the vulnerability analysis completed, it’s time to assign a rating. A vulnerability assessment rating describes the vulnerability in relation to its potential impact on the organization. The rating typically follows the same path as any risk rating adopted with other risk teams. You typically calculate the exposure, as discussed earlier in the section entitled “Risk Exposure.” Based on the risk exposure, you assign a value. Then, using a scale, you can assign a rating such as low, moderate, or high, as discussed in Table 11-4.

You do not have to apply a report rating. You could rate the report based on risk exposure. More organizations tend to use the low, moderate, and high ratings. The feeling is that these ratings can more accurately reflect the risk by applying professional judgment.

Vulnerabilities are weaknesses in a system that could result in unauthorized access to data. All software have some vulnerability. The goal is to produce code with the lowest number of vulnerabilities possible. That means designing code well and reducing defect rates. Equally important is closing vulnerabilities quickly once they are discovered. For commercial software, closing vulnerabilities often comes in the form of the vendor issuing a patch or an update release.

At some point vulnerabilities become known. This is called zero day. From that point to the point where a security fix can be distributed is the vulnerability window. For example, assume a new virus is found on a desktop. Your virus scanner and other preventative measures did not detect and prevent the virus. You discovered this vulnerability on March 1. You notified the vendor of the vulnerability on March 2. The vendor issued a new signature file to detect and prevent the virus on March 15. On the same day, you upgraded all the virus scanners with the new signature file. In this example you have a vulnerability window from March 1 to March 15. The zero day is March 1, which is the day the vulnerability became known.

Vulnerability can last for years when the distributed fix does not fix the root cause. When a vulnerability is exposed through a specific type of attack, you create a security fix. Later, however, you may discover that a different type of attack exploited the same vulnerability. It turns out that the original fix did not address the root cause of the vulnerability. The security fix of the first attack only cut off the original avenue of attack. This avenue of attack is also known as an attack vector. The fix did not resolve the root cause of the vulnerability.

Reducing the vulnerability window is important for an organization. It reduces the possibility of unauthorized data access and disclosure of information. That means working quickly with vendors and in-house development teams to identify fixes.

There are a number of common tools one can utilize to conduct vulnerability scans. A few are discussed here:

• Nmap—This is a common port scanner. It scans for open ports, running services, and so forth. It is a free download.
• Nessus—This is the most widely used vulnerability scanner. It is not a free tool; there are various licensing models. However, it is a powerful tool.
• OWASP ZAP—The Open Web Application Security Project Zed Attack Proxy is a free download that will scan websites for the common vulnerabilities. Specifically, it searches for the OWASP top 10 vulnerabilities.

The objective of a patch management program is to quickly secure against known vulnerabilities. Patches are produced by the vendors of systems, applications, and network devices. The objective to patch quickly seems straightforward; however, implementing patches can be challenging. For a large organization with a diverse set of technologies, there may be a continual flood of vendor patches. The dilemma is that failing to apply the patch leaves a security vulnerability that a hacker can exploit. Applying every patch that comes your way may lead to incompatibilities and outages.

Security policies outline the requirements for patch management. These include defining how patches should be implemented. The security policies also define how the patches should be tracked.

The key to success in patch management is to have a consistent approach to applying patches. This approach includes:

• Vetting
• Prioritization
• Implementation
• Postimplementation assessment

Vetting the patch is important to understanding the impact to your environment. Not all patches will apply to your environment. You must determine what security issues and software updates are relevant. An organization needs a point person or team responsible for tracking a patch from receipt to implementation. An asset management system helps inventory all systems, applications, and network devices. This is used to track what assets have been patched.

Each patch needs to be tested to ensure its authenticity. It also needs to be checked as to whether it is compatible with the organization’s applications. Regardless of how well you tested the patch, systems may encounter an incompatibility. When that occurs, you will need to work with the vendor to resolve the issue. You could also find an alternative way to mitigate the vulnerability.

You need to determine the priority of the patch before you implement it. Security policies should provide guidance on how long any security vulnerability can go without being mitigated. The patch team should have clear guidance about how quickly critical patches must be applied. Critical patches are those that mitigate a risk that is actively spreading within the company. Generally, critical patches are applied within hours or days.

Once you assess the priority, you can schedule the patch. You typically schedule patches monthly or quarterly. You make all patches viewable, such as on a Microsoft SharePoint site, by key stakeholders. These stakeholders could be systems, application, and network administrators. This gives them the ability to review and comment on patch deployment. Security policies should identify the notification period before patches are applied.

At this stage the patch process is most visible to the organization. You need to assess the security of the patch management application itself periodically. By its nature, the patch management application needs elevated rights. The patch may need to be applied to every system, application, and network device. A breach of the patch management application can be devastating to an organization.

These patch management tools also provide a vital task of discovery. These tools can examine any device on the network and determine its patch level. Some of these tools are used for dual purposes, such as patch and asset management.

Perform a postimplementation assessment to ensure that the patch is working as designed. Patches can have unintended consequences. Problems with patches need to be tracked and the patch backed out, if necessary.