Practical Vulnerability Management: A Strategic Approach to Managing Cyber Risk

INTRODUCTION

It’s human nature to pay attention to the problems that are big and flashy, attracting lots of interest, such as advanced persistent threat (APT) groups—state-­sponsored attackers. APT-linked attackers have compromised major retailers, financial institutions, and even government networks. But when we focus all of our attention on APTs and other headline-generating activity, we miss basic issues. Even though you have new firewalls protecting your system and powerful traffic-monitoring devices, if you don’t keep up with the bread and butter of your security responsibilities, you’re leaving many chinks in your system’s armor. Neglecting the basics, like keeping your systems updated, can lead to serious consequences.

Consider this example: suppose you’re an information security manager at a medium-sized e-commerce business. You’ve set up firewalls to block incoming traffic except for traffic to internet-facing services on systems in your demilitarized zone (DMZ). You’ve turned on egress filtering to block unauthorized exit traffic. An antivirus is on the endpoints, and you’ve hardened your servers. You believe your system is safe.

But an old web service is running on an outdated version of Tomcat on a Linux server in the DMZ. It’s a relic from an ill-advised foray into selling some of your company’s valuable proprietary data to selected business partners. The initiative failed, but because you made some sales, you had a contractual obligation to keep that server up for another year. At the end of the year, the project was quietly shuttered, but the server is still running. Everyone has forgotten about it. But someone on the outside notices it. An attack comes in from a compromised server in Moldova, and your unpatched Tomcat server is vulnerable to a five-year-old Java issue. Now the attacker has a foothold in your network, and all your protections couldn’t stop it. Where did you fail?

This guide demonstrates the value of strong information security fundamentals. These are the most important components of a successful information security program. Unfortunately, they’re regularly neglected in favor of sexier topics, such as traffic analysis and automated malware sandboxing. Don’t get me wrong; these are great advances in the state of the art of information security. But without a strong grasp of the fundamentals, investment in more advanced tools and techniques is futile.

Who This Book Is For

This book is for security practitioners tasked with defending their organization on a small budget and looking for ways to replicate functionality from commercially available vulnerability management tools. If you’re familiar with vulnerability management as a process, you’ll have a head start. To build your own vulnerability management system, you should be familiar with Linux and database concepts and have some experience in a programming language like Python. The scripts in this book are written in Python, but you can functionally re-create them in whichever modern scripting or programming language you prefer.

Back to Basics

You can consider a number of security topics as foundational, such as authentication management, network design, and asset management. Although these elements might not be exciting or interesting for an analyst to work on, they’re of critical importance.

Vulnerability management is one of the foundational concepts of information security. A perfectly written and configured software package doesn’t exist. Bugs are an inevitable part of software, and many bugs have security implications. Dealing with these software vulnerabilities is a perennial issue in information security; the practice of vulnerability management is required for a baseline level of security that can serve as a trusted foundation upon which to deploy more advanced and specialized tools.

Vulnerabilities affect an organization’s IT infrastructure at all levels, so vulnerability management affects all aspects of an IT security program. Endpoint security relies on workstations and servers being up-to-date with the latest software versions to minimize the attack surface. Zero-day vulnerabilities are always a concern. But removing the low-hanging fruit of known (and sometimes long-standing) vulnerabilities makes it more difficult for attackers to compromise an endpoint and gain a foothold in your environment. Network security does its best to ensure that only necessary traffic passes among internal network segments and to and from the internet. But if systems or network devices contain known vulnerabilities, even otherwise legitimate traffic might contain network-based attacks using known and trusted protocols. Identity and access management (IAM) restricts users to the specific systems and data to which they’re entitled. But if the identity systems are vulnerable, attackers can simply sidestep them.

If your environment has a baseline level of security, any countermeasures you put in place can’t be easily bypassed by exploiting known vulnerabilities. Let’s consider an analogy: after World War I, France tried to protect itself from Germany by building a long line of forts and entrenchments along its German border. It was named the Maginot Line after the French minister of war. But when World War II began, the Germans ignored the barrier by simply going around it, invading France across the Belgian border instead. All of that expensive defensive infrastructure was irrelevant. The same goes for your environment. If it doesn’t have a foundational level of security, any additional countermeasures are no more than a Maginot Line. Attackers can easily avoid them because there is an easier path elsewhere. But by establishing a vulnerability management baseline and maintaining it via an active vulnerability management program, you can trust that additional security measures will add real value to your security program.

Vulnerability Management Is Not Patch Management

Patch management, perhaps in conjunction with a full software configuration management (SCM) system, keeps track of the versions and patch levels of servers and endpoints across an enterprise. It can push patches remotely to keep systems up-to-date. But although traditional patch management and vulnerability management (as described in this guide) share many similarities, the underlying assumptions are very different.

Patch management assumes that patches are available, a patch management system can manage all the devices on the network that need patches, and there is enough time and manpower to apply all patches. But in real environments, it’s very rare for all of these conditions to hold. Devices exist that aren’t managed by the SCM: for example, network devices like routers and firewalls, test machines, abandoned servers, and devices running operating systems that aren’t compatible with SCM agents. All these components are invisible to a typical SCM deployment and could easily become out-of-date without anyone noticing. Even if automated patching is practicable for endpoints, often you must handle servers and network devices manually, because automatically patching a server might lead to downtime when the organization can least afford it. On the other hand, manually patching servers and network devices takes time that overworked IT staff often can’t spare.

Vulnerability management takes a more pragmatic approach. Instead of asking, How can we apply all of these patches? vulnerability management asks, Given our limited resources, how can we best improve our security posture by addressing the most important vulnerabilities? Vulnerability management looks at the problem through a risk management lens. We start with the full domain of vulnerabilities that exist on networked devices—managed and unmanaged—and determine which of these vulnerabilities present the highest risk to the organization’s security. Once we’ve gathered that data, we have enough information to prioritize patching and remediation activities. If after this process is complete we have the capacity to apply more updates and remediation, so much the better. But by looking at the highest-risk issues first and using our limited time and resources wisely, we can improve the system’s security posture significantly with comparatively little effort.

Main Topics Covered

This technical guide is divided into two main parts: conceptual and practical. In the first part, you’ll learn about the concepts and components of the vulnerability management process. In the second and larger part, you’ll look at a practical approach to building a free or low-cost vulnerability management system. Although you can follow the guide exactly, it’s most important for you to understand the concepts behind each script to adapt it to your own needs. Toward the end of the book, you’ll explore topics you might want to tackle once your vulnerability management system is up and running. One of those topics is purchasing a commercial tool to improve your vulnerability management program when you have the budget to do so.

How This Book Is Organized

Although there’s a natural flow from chapter to chapter and part to part, from theoretical to practical guidance, if you’re an experienced practitioner, you can jump to the specific topics of most interest. Similarly, the scripts naturally build from one to the next. But you can apply them on a piecemeal basis, depending on which tools and processes are already in place in your environment.

A summary of each chapter follows:

Chapter 1: Basic Concepts introduces the fundamental ideas of vulnerability management and its connection to risk management.

Chapter 2: Sources of Information discusses the various types of data you’ll need to collect to conduct the vulnerability management process.

Chapter 3: Vulnerability Scanners explores the process of scanning the systems in your network to find vulnerabilities.

Chapter 4: Automating Vulnerability Management explains how to build an automated system to collect and analyze the data you collect.

Chapter 5: Dealing with Vulnerabilities describes what to do about the vulnerability information you gather: patch, mitigate, or accept the risk.

Chapter 6: Organizational Support and Office Politics provides information on how to accomplish vulnerability management in your organization.

Chapter 7: Setting Up Your Environment explains how to put together the underlying OS, install required packages, and write a script to keep everything up-to-date.

Chapter 8: Using the Data Collection Tools discusses how to use Nmap, cve-search, OpenVAS, and Metasploit.

Chapter 9: Creating an Asset and Vulnerability Database shows you how to import scan results into the database.

Chapter 10: Maintaining the Database covers adding keys and culling old data.

Chapter 11: Generating Asset and Vulnerability Reports delves into creating basic CSV reports for assets and vulnerabilities.

Chapter 12: Automating Scans and Reporting describes writing a script to automate Nmap and OpenVAS scanning and periodically generate reports.

Chapter 13: Advanced Reporting discusses advanced reports using HTML.

Chapter 14: Advanced Topics explores creating an API, considering automatic exploitation, and entering the cloud.

Chapter 15: Conclusion wraps up the book by providing information on future security trends and how they might change your vulnerability management process.

Outcomes

This book’s goal is to take you from having no vulnerability management knowledge to having a functional vulnerability management program so you can generate accurate and usable vulnerability intelligence. This intelligence can help you increase your understanding of your organization’s vulnerability landscape and improve the organization’s overall security posture. By working through this guide, you’ll strengthen your organization’s vulnerability management capabilities, which is one of the fundamentals of a successful information security program.

Get the Code

As you are working through the steps to build yourself a vulnerability management system, you can always check the GitHub repository at https://github.com/magnua/practicalvm/. This repository contains all of the code in this book, as well as a few example configuration files that you can use in your own environment. Pull requests and suggestions are welcome!

Important Disclaimer

As is the case with most computer security tools or practices, you can use the tools and techniques in this guide offensively as well as defensively. Scanning can be an adversarial and malicious activity, and you should only perform it on systems (and networks) that you own or those you’ve been authorized to scan. I repeat: do not scan or otherwise probe systems that aren’t yours. Even when used properly, such tools can potentially cause negative outcomes including, in extreme cases, system crash and data loss. Be aware of the potential risks before engaging in any scanning or exploitation-related activity.

PART I

VULNERABILITY MANAGEMENT BASICS

1

BASIC CONCEPTS

Before you dive into vulnerability management, you should first understand some basic information about vulnerabilities. You might already be familiar with vulnerabilities and their varying risk levels. If so, consider this chapter a refresher to prepare you for the more advanced topics to come. This chapter isn’t an exhaustive primer of information security concepts, but it should be enough to ensure that the rest of the book is comprehensible.

The CIA Triad and Vulnerabilities

The three main pillars of information security are confidentiality of information (who can access data), integrity of information (who can modify data), and availability of information (whether data is available to authorized users). These three factors are known as the CIA triad. Although it isn’t a perfect model, the terms aid in discussing and ­categorizing security vulnerabilities.

Software, firmware, and hardware have bugs, and although not all bugs are serious, many have security implications. If you can enter improper input into a program and cause it to crash, not only is that a bug, it’s a vulnerability. But when you enter improper input and all it does is change the onscreen text color, presuming the text is still visible, that bug isn’t a vulnerability. Well, it isn’t until someone clever figures out how to leverage that bug to cause security-related issues. In short, a vulnerability is a weakness in an information system that an attacker can leverage in a way that has security implications. Typically vulnerabilities are due to bugs, but these weaknesses could stem from flaws in the code logic, poor software design, or implementation choices.

Because a bug must have implications for the confidentiality, integrity, or availability of data—or an entire information system—to be considered a vulnerability, the major vulnerability types map directly to the CIA triad. Denial-of-service (DoS) vulnerabilities impact the availability of data: if authorized users can’t access the system, they can’t access the data either. Information disclosure vulnerabilities impact data confidentiality: they permit unauthorized users to access data that they couldn’t otherwise access. Similarly, information modification vulnerabilities allow unauthorized users to modify data, so these vulnerabilities impact data integrity.

A fourth vulnerability category involves code execution and command execution. These vulnerabilities allow attackers to execute specific commands or arbitrary code on a system. The attacker has either limited or complete access to the system, depending on the user level at which this code executes, and can affect all three portions of the CIA triad. If an attacker can run commands, that person might be able to read or modify sensitive data or even shut down or reboot the system. Vulnerabilities in this category are the most severe.

Some vulnerabilities might fit into more than one category, and the categorization (and severity) could change as attackers begin to better understand the vulnerability and exploit it more thoroughly. Because the vulnerability landscape changes constantly, you need an effective vulnerability management program to keep abreast of developments.

What Is Vulnerability Management?

Vulnerability management is the practice of staying aware of known vulnerabilities in an environment and then resolving or mitigating these vulnerabilities to improve the environment’s overall security posture. Although this definition sounds simple, it entails a number of interdependent activities. I’ll discuss each of these activities in more detail in the following chapters. For now, let’s look at the vulnerability management life cycle’s major components (see Figure 1-1).

Figure 1-1: The vulnerability management life cycle

The first step is to understand the current vulnerability environment. To do so, you need to collect data about your systems to determine the vulnerabilities that exist on them. The next step is to analyze that collected data as well as security-related data from other sources.

Your data analysis results will help you make recommendations about the actions needed to improve your security posture. These recommendations might include installing patches or applying mitigations, such as firewall rules or system-hardening techniques. The next step is to implement recommendations. Once this is complete, the cycle begins again: you collect another round of systems data and the vulnerabilities that remain after analysis and mitigation, as well as new vulnerabilities that weren’t apparent in the previous cycle.

The management process is neither short nor simple. Finding vulnerabilities can be easy, but dealing with them and improving your security baseline will be ongoing. The process will also involve many different roles and business processes throughout the organization.

Let’s look at each step in more detail.

Collecting Data

You can split the collection component into two major categories: internal and external data collection. We’ll look at each in turn.

Internal data collection involves gathering information about your organizational environment. This data includes information about the hosts on your network—endpoints and network devices—and vulnerability information about each host. Host information can come from an exploratory scan using a network-mapping tool (like Nmap), an asset database tool, or a ­configuration management database (CMDB). If you have only a spreadsheet that contains data about