Conventions Used in This Book

This book follows a few typographical and stylistic conventions:

New terms are set in italic the first time they are introduced.
Each chapter concludes with key terms that have been introduced within the chapter.
Whenever possible, we reference the Common Vulnerabilities and Exposures (CVE) database to enable you to obtain additional information about the vulnerabilities; for example, http://cve.mitre.org/cgi-bin/cvename.cgi? name =CAN-2004-0965 .
This book also contains the following elements for additional information, such as notes, tips, cautions , and sidebars.

Note

Notes provide additional information about a topic.

Tip

Tips provide information that can make a task easier or ease an administrative burden .

Caution

Cautions are items you need to be aware of that may pose a problem or need to be carefully considered .

A Sidebar Looks Like This

We often use sidebars to present illustrative examples or add greater depth to the material.

1. Introduction to Assessing Network Vulnerabilities

This chapter introduces some basic security concepts, such as what security really is. It also starts the discussion of risk assessment as a process. Risk is all around us, and good Information Technology (IT) governance requires us to assess its potential dangers. Finally, this chapter will provide an overview of the network vulnerability assessment. Understanding how the network vulnerability assessment fits into the overall security program will help as we go through the entire process in subsequent chapters.

What Security Is and Isn't

Computer security is unlike other forms of security. Products such as locks, safes, and steel doors give clear ratings on what types of attacks they can withstand and how long they can withstand them. Most IT security products do not come configured in such a manner. These devices state only that they will prevent, block, drop, or protect from specific risks. Technology has failed to offer one complete perfect solution. Sure, you will find vast quantities of security technologies advertised in all the latest glossy security magazines and at security trade shows, but simply throwing money at products isn't the real solution. Security is not technology.

Misconfiguration, improper installation, and poor management are other causes of poor security. I have seen IT workers and managers involved in poor practices. I'll never forget the time a government agency showed me a firewall that was supposed to be protecting the internal network. The problem was that it wasn't even hooked to the network. It was configured in loop back mode. Security is not the administration.

Policies are another item pointed to when someone speaks of security. Many organizations don't have a well-defined security policy. Others have policies but they are poorly written or no one follows them because there are no consequences built in to the policy. After all, it's just a paper document. Policies are not security.

By now, you may be wondering what I think security is. Security is a process. Yes, security requires technology, people, and policies; however, that is not enough. Security is a process that requires input from the entire organization to be effective. It involves work on a proactive basis, such as patching vulnerable systems and monitoring audit files and IDS systems' activity logs. Security also requires support from senior management; it includes risk analysis, good implementation, employee training, patch management, and periodic vulnerability assessments. Figure 1.1 outlines the flow of this process.