Threats and Vulnerabilities

Introduction

If you're an IT professional trying to improve your process for managing risks, or a business manager building an Information Security strategy, you may encounter the terms threats and vulnerabilities, but find the distinctions between them are not clear. Just like with the difference between Disaster Recovery and Business Continuity, because they're related and there is some conceptual overlap, you'll often see the terms interchanged. Add to that countless glossaries or primers on the web about Information Security where the authors aren't precise with their terms, and the confusion builds.

Risk management must be done methodically and logically, especially for IT-related purposes like Information Security and Disaster Recovery. If not, you can't get concrete, actionable results that can be measured for effectiveness in terms of cost and impact. So any item of analysis has to be distinguishable from other items; if there is overlap, the nature and significance of the overlap has to be clear. Protected physical assets, information assets, software assets, people, suppliers, and critical processes are easily distinguishable, because what they are is self-evident. But when you have to identify threats, vulnerabilities, and potential impact, you must figure out a way to list, rank, and analyze them in a precise manner, which can present challenges we'll address below.

Let's start with the simplified J.D. Fox Exec definitions of threats and vulnerabilities.

Threats and vulnerabilities apply to Information Security risk management and related disciplines. For other areas of risk management, such as compliance risk, financial risk, or your company safety and emergency response programs, you generally won't see these terms.

Both have to be discovered and evaluated. For threats, the discovery and assessment process is called Threat Modeling. For vulnerabilities, as you'll see below, the process is generally more complex. When implemented in earnest, it is called the Vulnerability Management program.

Let's look at how threats and vulnerabilities apply to different areas of Information Security risk management, how they are distinguished, and how they interact.

Network Operations

For an Information Security program and Disaster Recovery planning related to your IT network operations, threat and vulnerability assessment activities are quite distinct.

Threats

For threats, the process is a linear part of the risk management process. The risk manager will identify and list all information assets and processes to protect, and then identify and rank the threats to those assets, in order to develop controls to protect against them. Threat Modeling for IT covers both technical threats (such as malware) and non-technical (such as fire or flood). Threats are discovered by studying threat intelligence reports, analyzing your systems and operations, brainstorming with departmental managers, and then putting it all together using old-time methods such as the Delphi Technique or FRAP, or with updated guidance from NIST. The process is centered on your asset value—that is, what management says is important and should be the focus of protection.

Vulnerabilities

Vulnerabilities are much more complicated to discover, because they arise from a wide range of technical aspects of your system. Some sort of vulnerability assessment should be performed to accurately rank the threats you've identified, because the condition of your system can greatly influence the likelihood and impact of each identified threat. For example, if you discover that a certain group of criminals have been employing a certain method to break into financial systems and steal banking data (a threat), the likelihood and impact to your organization would depend on whether your system were susceptible to the method used by these criminals, given the version and configuration of the software you use (vulnerability).

In this respect, Vulnerability Management is often described as the technical subcomponent of Information Security Threat Modeling.

Here are the three broad methods of Vulnerability Management, in escalating order of comprehensiveness and cost.

1. Configuration management involves your IT manager or department manually assessing and configuring your system to minimize vulnerabilities, based on best practices. These include deployment of endpoint security software, network segmentation, change management, implementing the principle of least privilege, using an automated software update process for commercial software to fix discovered security flaws promptly, enforcing user password policies, and use of free configuration scanning tools.
2. Vulnerability scanning software examines your application servers, storage, workstations, and network devices to identify the presence of vulnerabilities, such as configuration settings that don't match intent, poor user account management enabling easy access by unauthorized users, easily-breakable authentication or encryption methods in use, and the presence of known exploitable software. More sophisticated systems can create a network map and find vulnerabilities not identified by analyzing any individual device. This software can cost thousands of dollars per year and up, depending on the size of your system. In addition, it requires a greater level of security training for your IT staff to deploy the software and interpret the results of scans.
3. Penetration testing is a process performed by highly-trained professionals to seek out and identify not just the existence of vulnerabilities, but to determine how far into your system they can get exploiting multiple layers of vulnerabilities, what data can be accessed, and how easily an exploiter can avoid detection. You can't just buy penetration testing software; to have this done properly, you need a qualified tester, who will draw from a large library of software tools and techniques to perform the tasks necessary to assess your system properly. This can require an investment of tens to hundreds of thousands of dollars, plus continuing costs to maintain readiness.

The Problem

Where a problem becomes apparent is when you look at the options and costs for the different Vulnerability Management strategies. You can find yourself in a conundrum.

Here's why. When you embark on a new risk management program to shore up your Information Security, your company allocates a certain amount of time, resources, and money to do the analysis. The objective is to devise and select controls to protect against identified threats, where those controls cost less than the potential cost of the threats being realized. Since the most common and likely threats to your system are generally well-known, and discoverable with a little research, the cost to create a list of threats is going to be a negligible portion of your overall budget for risk management activities. Even unusual threats particular to your organization will be discovered, relatively easily, by collaborating with management and analyzing your operations and its history.

The number of vulnerabilities that may apply to your IT system are virtually endless, however. And the cost to find them can be significant. So, this is where you can encounter a problem, where it seems like you don't know how to proceed.

See, you thought you were going to do this:

1. Identify threats;
2. Scan for vulnerabilities to help evaluate your susceptibility to these threats; and
3. Use that information to prioritize the threats.

Then you'll know just what controls you need to invest in first. That's what the risk management doctrine says to do, right? But, when you get to the vulnerability scanning step, you find the cost of just the software is more than you ever expected to spend on risk controls to begin with!

So, what do you do? If you skip vulnerability scanning, then your evaluation of identified threats might be inaccurate. But, to do it, you have to budget for a significant expense, which might not be approved. Even if there is a budget, you still need a way to determine what capabilities you need, and how much you need to spend, because the range of offerings and pricing is quite broad. You feel like you need to know what kind of vulnerabilities you have before you can pick the right tools or methods to discover them!

The Solution

This is not actually the problem it seems to be. If you've encountered this while studying Information Security risk management doctrine, it's because what you're reading was not written for your kind of business. In other words, many authors write for the highest echelon; that is, they assume their readers are part of a large business with a vast and complex IT system, where thousands of dollars for vulnerability scanning systems, and even more for penetration testing, is a minor line-item in the IT operational and security budget. For the tens of millions of businesses in the United States that aren't like that, we need a way to apply the same doctrinal elements of the Vulnerability Management process, even if we use less sophisticated procedures and tools, but without compromising the value of our risk assessments.

So let's do it. First, based on their system configuration, some businesses simply do not need vulnerability scanning or penetration testing, meaning configuration management is perfectly suitable. Typically, this would be a company that only has workstations with off-the-shelf office productivity software, servers or network storage for file sharing, hosted e-mail, no public-facing custom applications or data, and a competent IT systems manager. If this describes your company, and your IT systems manager can validate that security best practices are consistently applied, then you can assign a relatively low likelihood to threats that would exploit common vulnerabilities in your risk analysis.

A small business that possesses certain qualities or crosses certain thresholds of complexity may need to invest in vulnerability scanning or penetration testing. These include:

• In-house developed software, for internal users or for Internet users;
• Very high value of information assets in relation to operational budget;
• Decentralized IT management, such as branch offices with autonomous IT departments, connected by leased lines or VPNs through the Internet;
• Lack of a continuous system development lifecycle program, leaving you with a complex mix of systems that vary in age that have been patched together over many years;
• An IT system that has not been well-managed (lacking documentation, change control, or security best practices);
• Recent history of a high number of targeted infiltration attempts;
• Recent history of successful infiltrations, where your IT managers are unable to determine what vulnerabilities were exploited or how.

If any of these apply, then you need to pause the risk management process after identifying threats, and determine what investment to make in vulnerability scanning or penetration testing to support evaluating these threats. You can do this by performing a separate simplified risk management process, but for this limited scope only. Just as risk management for Information Security or Disaster Recovery in general will tell you how much to invest for risk mitigation controls, this separate process will tell you how much to invest in tools and services to support your Vulnerability Management program.

This is where the experience of an Information Security professional is essential. To assess the required level of investment in Vulnerability Management, you need to understand the technical capabilities of various vulnerability scanning software and service offerings, and then determine which would best apply to your system based on IT security knowledge in general, knowledge of your IT systems in particular, and an assessment of the kinds of vulnerabilities you anticipate. With that information, the appropriate type of vulnerability assessment, and the optimal budget, can be determined, and the business case presented to management for approval.

Examples

Here are some examples, with numbers. Any mention of servers can refer to physical or virtual servers kept on premises, or virtual machines hosted by a cloud services provider, and the evaluation will generally be the same.

• Let's say you have a small operation, with good data backup systems in place. You determined early in the risk management process that the maximum possible loss from security breaches in your business is $25,000. You've read articles about vulnerability scanning and figure you need to do this, but find out it would cost about $10,000 for your network. Using the J.D. Fox Exec approach described above, you determine that configuration management by your IT systems manager is the optimal solution.
• Same small business, but with a more expansive IT system and more technology-driven operations, including some web-based applications for customers that you developed in-house. Because of this, possible losses due to a security breach could reach $200,000. Implementation of a vulnerability scanning system would cost $20,000. Your security manager, with detailed knowledge of your operations and IT system, advises that with the information provided by vulnerability scanning, his ability to prevent breaches will be significantly enhanced, especially since the developers who originally wrote your web applications are no longer with the company. Thus, investment in vulnerability scanning is indicated. Penetration testing would cost $50,000, but your security manager determines your data and systems are not complex enough to necessitate the in-depth nature of penetration testing, making the decision to forego this an easy one. All of this is recorded in your enterprise risk management documentation.
• Your business has only a few dozen employees and not much IT equipment, but you have developed a massive proprietary marketing database over many years that you intend to sell for a high profit. You have custom software you developed for managing and presenting this data, and web servers that allow subscribers and potential purchasers to access limited portions of the data. Foreign outsourced software developers you've hired can log in to your web servers as well, with the ability to update your web site's program code. They're not supposed to be able to access the data. The database is backed up to a cloud services provider. Disclosure or loss of the entire database could cost the business five million dollars or more. Because of the complexity and high cost, management easily approves a $75,000 budget for full penetration testing.

Software Development

Until this point, we've covered routine IT system operations, where identifying all possible threats to protected assets is the focus, and vulnerability analysis helps evaluate these threats. For custom software development, however, the risk management process focuses directly on vulnerabilities, for two reasons:

1. The types of threats to a software application or website are relatively limited. Applications need to defend against a human user attempting to gain access to functions or data beyond what they are intended to reach, and that's about it. Developers don't worry about power outages, natural disasters, equipment theft, or users not complying with policies.
2. Discovering and patching vulnerabilities in custom software after it's been rolled out, in most cases, is vastly more expensive than preventing them during development through sound development practices. Since the likelihood and impact of potential threats, and the value of the application's data, won't be known during development, ensuring you address all vulnerabilities during development is more cost-effective than waiting to see which ones matter and paying to fix those after the software has been deployed.

Security managers can use well-known software development security analysis methods ranging from the older STRIDE, DREAD, and Trike models, to the more complex OWASP model, to contemporary systems like PASTA and VAST for the agile shop. Some of these systems clearly focus on vulnerabilities as we'd expect; they diagram the process and data flow of program code and databases to identify entry points, coding practices, communications protocols, and encryption methods, to help the software development team identify problems with these that will create vulnerabilities.

Some of these models seem to focus on threats, by starting with an enumeration of what a malicious user might do to the application or data that shouldn't be allowed—for example, tampering with data, or uploading and running malware on the application server. But, the mitigation process will always involve ensuring the software is designed, from high-level structure to the most detailed program code checks, to eliminate all vulnerabilities that would allow these threats to be realized. Those that seem to focus on threats are merely attacking vulnerabilities from a different angle.

Epilogue

The intent of this article is to give business or IT systems managers the confidence that threat and vulnerability analysis does provide concrete, actionable information to guide sound, economical decisions to protect your information assets. As mentioned, other articles you might have read on this topic may give you the impression that it's all theory. But, as you can see, the theory and methods are well-developed, and can be applied successfully to any business if you have have an experienced, knowledgeable support provider, like J.D. Fox Exec.