Users, developers, managers, and administrators (yes, it is true!) are all very common sources of network security failure. Certainly the most common way that people introduce vulnerabilities to network security is by creating weak passwords. Human beings are incredibly bad at generating, remembering, and using random characters. Furthermore, the word password itself might lead users to create very weak passwords. The first password most people think of is a word that appears in the dictionary, or worse yet, the name of a family member. There are approximately 350,000 words in the American Heritage Dictionary of the English Language, 3rd Edition. It might not be feasible to attack a password through the console (although it’s almost shocking how often well-known bad passwords, like password, admin, or root, are used), but a computer that made 10,000 attempts per second would find the password within 17.5 seconds on average or within 35 seconds in a worst-case scenario.

The human factor also comes into play as a major failure mode outside of the scope of technology. One of these areas is physical security; the other is social engineering. In terms of physical security, people often leave doors open or unlocked, leave their workstations unattended and unlocked, and leave their laptop computers in the back seat of their cars while they stop at the grocery store. For example, in 2000, the laptop belonging to the CEO of Qualcomm was stolen after he delivered a presentation at an industry conference. According to the media, the CEO was fewer than 30 feet away from the podium where he had been speaking when his laptop was stolen.

Social engineering is another attack vector. What is the easiest way to get a password? Ask for it, of course. Exploiting the basic trust, fears, and ego of humans is an incredibly powerful way to break into a network. In 2002, a student at the University of Delaware who was going to fail her math and science courses decided to take corrective action through exploiting the university’s computer system. She simply called the university’s human resources department, posed as the professor for each course, and asked to have the password reset. It worked—she not-so-magically received A grades. The human resources employee changed the password even though password changes over the phone were prohibited. According to police records, "The human resources worker complied, even though she later told police the voice on the phone sounded ’young, high-pitched, and desperate.’"

The heart and soul of network security is the security policy of the organization. The quality and completeness of an organization’s security policy strongly correlates to the overall effectiveness of its network security. Security policy, however, is not the least bit sexy for most IT administrators. It is pretty rare to see any IT admin jump out of his chair and say "Why yes, I would like to work with Human Resources, Management, and the Legal Department to make policy!" Policy breakdowns can cause network security to fail in several ways, most prominently when developers and administrators take the path of least resistance to meet a poorly conceived or nonexistent policy. Security policies frequently fail because they are:

The breakdown of security policy often leads to the greater breakdown of network security; consequently, assessing the effectiveness of security policies in your organization is essential.

Computers do exactly what human beings (administrators included) tell them to do, no matter how little sense the instructions have. Administrators and developers are bound to make configuration and other types of mistakes that can easily lead to security vulnerabilities and ultimately to the compromise of an organization’s information.

Most operating systems and applications come out of the box configured to use the most popular features or to provide a generic state of operation that might or might not meet your organization’s security requirements. Unfortunately, the trouble with default configurations is that everyone, including the bad guys, knows what the default configuration is, weaknesses and all. But just as easily, an administrator or developer might introduce new weaknesses by misconfiguring an operating system or application, or by writing code that does not follow security best practices. For example, developers often introduce vulnerabilities by not carefully tracking how data is copied into memory buffers, resulting in buffer overrun conditions that can lead to remote compromise of the system.

With proper training, documentation, and systematic controls, organizations can minimize these types of errors; however, it is unlikely that preventative measures will stop all incidents. Proactive security assessment can not only help locate these vulnerabilities before attackers exploit them, but can also demonstrate how vulnerabilities in unrelated systems and applications can, in aggregate, lead to a major security compromise. This most often occurs when systems of different trust levels are connected, as shown in Figure 1-1.

Figure 1-1. How attackers exploit vulnerabilities in unrelated systems to carry out attacks.

For example, an attacker might want to get access to the customer database in Figure 1-1; however, the attacker has no means to access the server. To gain access to the customer database:

Making poor, misguided, or unjustified assumptions is the root cause of many security vulnerabilities. Administrators can make poor assumptions about user behavior, about how technology works, or about whether tasks have been completed. It takes only one small oversight resulting from an unjustified assumption for an attacker to compromise a network or application. Preventing administrators and developers from making unjustified assumptions is one of the single biggest ways you can improve security. Conversely, when assessing the security of a network, your job is all about discovering where administrators and developers have made unjustified assumptions.

Closely associated with making poor assumptions is ignorance. Often administrators and developers simply are not aware of the consequences of their actions or the threats that attackers pose to their network or application. Network management might also be the source of ignorance regarding how to properly secure information assets or what the threats to information assets are. The adage that nobody believes it happens until it happens to him has been very applicable to computer crime; however, with ever-increasing media and popular culture attention paid to computer crime, this type of ignorance might come to an end soon. It is unlikely, though. The bottom line is that there are bad guys out there and, given the opportunity, they will break into your organization’s network, even without any overwhelming motivation.

The security of a network is only as good as its last update. Remember, security is dynamic—it is not a fixed state. Consequently, you must be vigilant about both securing information assets and maintaining the security of those assets. Certainly this is no more evident than with security patching for operating systems and applications. There is in effect a race between administrators and attackers each time a security patch is released. The administrators race to test and deploy the patch before attackers can develop an exploit and attack networks. For example, on July 16, 2003, Microsoft published the security bulletin MS 03-026 and corresponding patch. The subject of the bulletin was product vulnerability in various versions of Windows operating systems that could lead to the remote compromise of the operating system through a remote procedure call (RPC). Within 11 days, exploit tools were published on the Internet, including source code and executable files. The Blaster virus, which took advantage of the RPC/DCOM product vulnerability, was not live until early August, approximately three weeks after the patch was released. About half a million computers were infected by Blaster nonetheless. Although vendors, Microsoft included, must develop better technologies to reduce vulnerabilities and to patch operating systems and applications, administrators must stay up-to-date on security to protect the organization’s network.

Vulnerability scanning is the most basic type of security assessment. Vulnerability scanning assesses a network for potential security weaknesses that are well known and well understood. Vulnerability scanning is generally carried out by a software package but can also be accomplished through custom scripts. Vulnerability scanning software frequently requires administrative rights on a network because of technical reasons or controls built into the scanning software, but some scanning does not require this level of access. In general, vulnerability scanning assessments assume that the person carrying out the scan is an administrator. Most commercial vulnerability scanning software packages do the following:

Penetration testing, often called pen testing, is a much more sophisticated type of security assessment than vulnerability scanning. Unlike vulnerability scanning, which generally examines the security of only individual computers, network devices, or applications, penetration testing assesses the security of the network as a whole. Also, penetration testing, by definition, assumes that the pen tester does not yet have administrator rights. (In fact, the goal of every pen test is to ultimately obtain administrator credentials.) Penetration testing can help educate network administrators, IT managers, and executives about the potential consequences of a real attacker breaking into the network. Penetration testing also reveals security weaknesses missed by vulnerability scanning: how vulnerabilities are exploited, and weaknesses in people and processes.

IT security auditing differs greatly from vulnerability scanning and penetration testing. IT security auditing generally focuses on the people and processes used to design, implement, and manage security on a network. In an IT security audit, the auditor and your organization’s security policies and procedures use a baseline. A proper IT security audit will help determine whether your organization has the necessary components to build and operate a risk-appropriate, secure computing environment.

Unlike vulnerability scanning and penetration testing, IT security audits can be conducted by people without significant technical skills; conversely, the skills needed to perform a good audit are not necessarily those possessed by technical employees. IT security audits are essential elements of regulatory compliance. For example, if you work in the health care industry in the United States, your organization might be subject to the HIPAA (Health Insurance Portability and Accountability Act) security and privacy regulation. There is a reasonable chance that your organization’s insurance company will ask for some type of proof of compliance, and this is where the IT security audit comes in.