key: cord-0037292-vdddhcuq
authors: Kizza, Joseph Migga
title: Computer Network Vulnerabilities
date: 2012-07-31
journal: Guide to Computer Network Security
DOI: 10.1007/978-1-4471-4543-1_4
sha: 0c1452b2a9f038bf1c1816c7e9cd4f31d1befcd4
doc_id: 37292
cord_uid: vdddhcuq

System vulnerabilities are weaknesses in the software or hardware on a server or a client that can be exploited by a determined intruder to gain access to or shut down a network. Donald Pipkin defines system vulnerability as a condition, a weakness of or an absence of security procedure or technical, physical, or other controls that could be exploited by a threat [1].

System vulnerabilities are weaknesses in the software or hardware on a server or a client that can be exploited by a determined intruder to gain access to or shut down a network. Donald Pipkin de fi nes system vulnerability as a condition, a weakness or an absence of security procedure or technical, physical, or other controls that could prevent a threat [ 1 ] .

Vulnerabilities do not only exist in hardware and software that constitute a computer system but also in policies and procedures, especially security policies and procedures, that are used in a computer network system and in users and employees of the computer network systems. Since vulnerabilities can be found in so many areas in a network system, one can say that a security vulnerability is indeed anything in a computer network that has the potential to cause or be exploited for an advantage. Now that we know what vulnerabilities are, let us look at their possible sources.

The frequency of attacks in the last several years and the speed and spread of these attacks indicate serious security vulnerability problems in our network systems. There is no de fi nitive list of all possible sources of these system vulnerabilities. Many scholars and indeed many security incident reporting agencies, such as Bugtraq, the mailing list for vulnerabilities; CERT/CC, the USA Computer Emergency Response Team; NTBugtraq, the mailing list for Windows security; RUS-CERT, the Germany Computer Emergency Response Team; and US DOE-CIAC, the US Department of Energy Computer Incident Adversary Capability, have called attention to not only one but multiple factors that contribute to these security problems and pose obstacles to the security solutions. Among the most frequently mentioned sources of security vulnerability problems in computer

The two major components of a computer system, hardware and software, quite often have design fl aws. Hardware systems are less susceptible to design fl aws than their software counterparts owing to less complexity, which makes them easier to test; limited number of possible inputs and expected outcomes, again making it easy to test and verify; and the long history of hardware engineering. But even with all these factors backing up hardware engineering, because of complexity in the new computer systems, design fl aws are still common.

But the biggest problems in system security vulnerability are due to software design fl aws. A number of factors cause software design fl aws, including overlooking security issues all together. However, three major factors contribute a great deal to software design fl aws: human factors, software complexity, and trustworthy software sources [ 3 ] .

In the human factor category, poor software performance can be a result of the following: 1. Memory lapses and attentional failures: For example, someone was supposed to have removed or added a line of code, tested, or veri fi ed, but did not because of simple forgetfulness. 2. Rush to fi nish: The result of pressure, most often from management, to get the product on the market either to cut development costs or to meet a client deadline can cause problems. 3. Overcon fi dence and use of nonstandard or untested algorithms: Before algorithms are fully tested by peers, they are put into the product line because they seem to have worked on a few test runs. 4. Malice: Software developers, like any other professionals, have malicious people in their ranks. Bugs, viruses, and worms have been known to be embedded and downloaded in software, as is the case with Trojan horse software, which boots itself at a timed location. As we will see in Sect. 7.5 , malice has traditionally been used for vendetta, personal gain (especially monetary), and just irresponsible amusement. Although it is possible to safeguard against other types of human errors, it is very dif fi cult to prevent malice. 5. Complacency: When either an individual or a software producer has signi fi cant experience in software development, it is easy to overlook certain testing and other error control measures in those parts of software that were tested previously in a similar or related product, forgetting that no one software product can conform to all requirements in all environments.

Both software professionals and nonprofessionals who use software know the differences between software and hardware programming. In these differences underlie many of the causes of software failure and poor performance. Consider the following: 1. Complexity: Unlike hardwired programming and design in which it is easy to exhaust the possible outcomes on a given set of input sequences, in software programming, a similar program may present billions of possible outcomes on the same input sequence. Therefore, in software programming, one can never be sure of all the possibilities on any given input sequence. 2. Dif fi cult testing: There will never be a complete set of test data set to check software exhaustively for all bugs for a given input sequence. 3. Ease of programming: The fact that software programming is easy to learn encourages many people with little formal training and education in the fi eld to start developing programs, but many are not knowledgeable enough about good programming practices or able to check for errors. 4. Misunderstanding of basic design speci fi cations: This affects the subsequent design phases including coding, documenting, and testing. It also results in improper and ambiguous speci fi cations of major components of the software and in ill-chosen and poorly de fi ned internal program structures.

There are thousands of software sources for the millions of software products on the market today. However, if we were required to name well-known software producers, very few of us would succeed in naming more than a handful. Yet we buy software products every day without even ever minding their sources. Most importantly, we do not care about the quality of that software, the honesty of the anonymous programmer, and of course its reliability as long as it does what we want it to do. Even if we want to trace the authorship of the software product, it is impossible because software companies are closed within months of their opening. Chances are when a software product is 2 years old, its producer is likely to be out of business. In addition to the dif fi culties in tracing the producers of software who go out of business as fast as they come in, there is also fear that such software may not even have been tested at all.

The growth of the Internet and the escalating costs of software production have led many small in-house software developers to use the marketplace as a giant testing laboratory through the use of beta testing, shareware, and freeware. Shareware and freeware have a high potential of bringing hostile code into trusted systems.

For some strange reason, the more popular the software product gets, the less it is tested. As software products make market inroads, their producers start thinking of producing new versions and releases with little to no testing of current versions. This leads to the growth of what is called a common genesis software product, where all its versions and releases are based on a common code. If such a code has not been fully tested, which is normally the case, then errors are carried through from version to version and from release to release.

In the last several years, we have witnessed the growth of the open-source movement. It has been praised as a novel idea to break the monopoly and price gauging by big software producers and most important as a timely solution to poor software testing. Those opposed to the movement have criticized it for being a source of untrusted and many times untested software. Despite the wails of the critics, major open-source products such as Linux operating system have turned out with few security fl aws; still there are fears that hackers can look at the code and perhaps fi nd a way to cause mischief or steal information.

There has been a rise recently in Trojan horses inserted into open-source code. In fact security experts are recommending running readily available programs such as MD5 hashes to ensure that code hasn't been altered. Using MD5 hashes and similar programs such as MD4, SHA and SHA-1 continually compare codes generated by "healthy" software to hashes of programs in the fi eld, thus exposing the Trojans. According to the recent CERT advisory, crackers are increasingly inserting Trojans into the source code for tcpdump, a utility that monitors network traf fi c, and libpcap, a packet capture library tool [ 4 ] .

However, according to the recent study by the Aberdeen Group, open-source software now accounts for more than half of all security advisories published in the past year by the Computer Emergency Response Team (CERT). Also according to industry study reports, open-source software commonly used in Linux, Unix, and network routing equipment accounted for 16 of the 29 security advisories during the fi rst 10 months of 2002, and there is an upswing in new virus and Trojan horse warnings for Unix, Linux, Mac OSX, and open-source software [ 4 ] .

New developments in software engineering are spearheading new developments such as software reuse and software reengineering. Software reuse is the integration and use of software assets from a previously developed system. It is the process in which old or updated software such as library, component, requirements and design documents, and design patterns is used along with new software.

Both software reengineering and reuse are hailed for cutting down on the escalating development and testing costs. They have brought ef fi ciency by reducing time spent designing or coding popularized standardization and led to common "look and feel" between applications. They have made debugging easier through use of thoroughly tested designs and code.

However, both software techniques have the potential to introduce security fl aws in systems. Among some of the security fl aws that have been introduced into programming is fi rst the mismatch where reused requirements speci fi cations and designs may not completely match the real situation at hand and nonfunctional characteristics of code may not match those of the intended recipient. Second, when using object programming, it is important to remember that objects are de fi ned with certain attributes, and any new application using objects de fi ned in terms of the old ones will inherit all their attributes.

In Chap. 4 , we discussed many security problems associated with script programming. Yet there is now momentum in script programming to bring more dynamism into Web programming. Scripting suffers from a list of problems including inadequate searching and/or browsing mechanisms before any interaction between the script code and the server or client software, side effects from software assets that are too large or too small for the projected interface, and undocumented interfaces.

Security management is both a technical and an administrative security process that involves security policies and controls that the organization decides to put in place to provide the required level of protection. In addition, it also involves security monitoring and evaluation of the effectiveness of those policies. The most effective way to meet these goals is to implement security risk assessment through a security policy and secure access to network resources through the use of fi rewalls and strong cryptography. These and others offer the security required for the different information systems in the organization in terms of integrity, con fi dentiality, and availability of that information. Security management by itself is a complex process; however, if it is not well organized, it can result in a security nightmare for the organization.

Poor security management is a result of little control over security implementation, administration, and monitoring. It is a failure in having solid control of the security situation of the organization when the security administrator does not know who is setting the organization's security policy, who is administering security compliance, and who manages system security con fi gurations and who is in charge of security event and incident handling.

In addition to the disarray in the security administration, implementation, and monitoring, a poor security administration team may even lack a plan for the wireless component of the network. As we will see in Chap. 17 , the rapid growth of wireless communication has brought with it serious security problems. There are so many things that can go wrong with security if security administration is poor. Unless the organization has a solid security administration team with a sound security policy and secure security implementation, the organization's security may be compromised. An organization's system security is as good as its security policy and its access control policies and procedures and their implementation.

Good security management is made up of a number of implementable security components that include risk management, information security policies and procedures, standards, guidelines, information classi fi cation, security monitoring, and security education. The following core components serve to protect the organization's resources:

A risk analysis to identify assets, discover the threats that put these assets at risk, • and estimate the possible damage and potential loss a company could endure if any threats become real. The results of the risk analysis help management construct a budget with the necessary funds to protect the recognized assets from their identi fi ed threats and develop applicable security policies that provide direction for security activities. Security education takes this information to each and every employee.

Security policies and procedures to create, implement, and enforce security • issues that may include people and technology. Standards and guidelines to fi nd ways, including automated solution for creating, • updating, and tracking compliance of security policies across the organization. Information classi fi cation to manage the search, identi fi cation, and reduction of • system vulnerabilities by establishing security con fi gurations. Security monitoring to prevent and detect intrusions, consolidate event logs for • future log and trend analysis, manage security events in real time, manage parameter security including multiple fi rewall reporting systems, and analyze security events enterprise-wide. Security education to bring security awareness to every employee of the organi-• zation and teach them their individual security responsibility.

Incorrect implantation very often is a result of incompatible interfaces. Two product modules can be deployed and work together only if they are compatible. That means that the module must be additive ; that is, the environment of the interface needs to remain intact. An incompatible interface, on the other hand, means that the introduction of the module has changed the existing interface in such a way that existing references to the interface can fail or behave incorrectly. This de fi nition means that the things we do on the many system interfaces can result in incompatibility that further results in bad or incomplete implementation. For example, ordinary addition of a software or even an addition or removal of an argument to an existing software module may cause an imbalanced interface. This interface sensitivity tells us that it is possible because of interposition that the addition of a simple thing like a symbol or an additional condition can result in an incompatible interface, leading the new symbol or condition to con fl ict with all applications that have been working without problems.

To put the interface concept into a wide system framework, consider a systemwide integration of both hardware and software components with differing technologies with no standards. No single information system product, whether hardware or software, is based on a standard that the industry has to follow. Because of this, manufacturers and consumers must contend with the constant problems of system compatibility. Because of the vast number of variables in information systems, especially network systems, involving both hardware and software, it is not possible to test or verify all combinations of hardware and software. Consider, for example, that there are no standards in the software industry. Software systems involve different models based on platforms and manufacturer. Products are heterogeneous both semantically and syntactically.

When two or more software modules are to interface one another in the sense that one may feed into the other or one may use the outputs of the other, incompatibility conditions may result from such an interaction. Unless there are methodologies and algorithms for checking for interface compatibility, errors are transmitted from one module into another. For example, consider a typical interface created by a method call between software modules. Such an interface always makes assumptions about the environment having the necessary availability constraints that the accessibility of local methods to certain states of the module. If such availability constraints are not checked before the modules are allowed to pass parameters via method calls, errors may result.

Incompatibility in system interfaces may be cause by a variety of conditions usually created by things such as:

Too much detail • Not enough understanding of the underlying parameters • Poor communication during design • Selecting the software or hardware modules before understanding the receiving • software Ignoring integration issues • Error in manual entry • Many security problems result from the incorrect implementation of both hardware and software systems. In fact, system reliability in both software and hardware is based on correct implementation, as is the security of the system.

In Sect. 4.2.1 , we discussed design fl aws in technology systems as one of the leading causes of system vulnerabilities. In fact we pointed out that systems are composed of software, hardware, and humanware. There are problems in each one of these components. Since the humanware component is in fl uenced by the technology in the software and hardware, we will not discuss this any further.

The fact that computer and telecommunication technologies have developed at such an amazing and frightening speed and people have overwhelmingly embraced both of them has caused security experts to worry about the side effects of these booming technologies. There were reasons to worry. Internet technology has been and continues to be vulnerable. There have been reports of all sorts of loopholes, weaknesses, and gaping holes in both software and hardware technologies.

According to Table 4 .1 , the number of reported system vulnerabilities has been on the rise from 3 in 1989 to 1,113 in 2011, a 26.81% growth, and this is only what is reported to the National Vulnerability Database (NVD), a division of the National Institute of Standards and Technology (NIST) within the US Department of Commerce. There is agreement among security experts that what is reported is the tip of the iceberg. Many vulnerabilities are discovered and, for various reasons, are not reported.

Because these technologies are used by many who are not security experts (in fact the majority of users are not security literate), one can say that many vulnerabilities are observed and probably not reported because those who observe them do not have the knowledge to classify what has been observed as a vulnerability. Even if they do, they may not know how and where to report.

No one knows how many of these vulnerabilities are there in both software and hardware. The assumption is that there are thousands. As history has shown us, a few are always discovered every day by hackers. Although the list spans both hardware and software, the problem is more prevalent with software. In fact, software vulnerabilities can be put into four categories:

Operating system vulnerabilities: Operating systems are the main sources of all • reported system vulnerabilities. SANS (SysAdmin, Audit, Network, Security) Institute, a cooperative research and education organization serving security professionals, auditors, system administrators, and network administrators, together with the Common Weakness Enumeration (CWE), a communitydeveloped dictionary of weaknesses of software types, have been issuing lists ; popular operating systems cause many of the vulnerabilities . This is always so because hackers tend to take the easiest route by exploiting the best-known fl aws with the most effective and widely known and available attack tools. Port-based vulnerabilities: Besides operating systems, network service ports take • second place as sourcing system vulnerabilities. For system administrators, knowing the list of most vulnerable ports can go a long way to help enhance system security by blocking those known ports at the fi rewall. Such an operation, though not comprehensive, adds an extra layer of security to the network. In fact it is advisable that in addition to blocking and deny-everything fi ltering, security administrators should also monitor all ports including the blocked ones for intruders who entered the system by some other means. For the most common vulnerable port numbers, the reader is referred to the latest SANS at http://www.sans.org/ . Application software-based errors. • System protocol software such as client and server browser. •

To help in the hunt for and fi ght against system vulnerabilities, SANS, in cooperation with the Common Weakness Enumeration (CWE), a community-developed dictionary of weaknesses of software types, has been issuing lists annually: "CWE/ SANS Top 25 Most Dangerous Software Errors."

In addition to highlighting the need for system administrators to patch the most common vulnerabilities, we hope this will also help many organizations that lack the resources to train security personnel to have a choice of either focusing on the most current or the most persistent vulnerability. One would wonder why a vulnerability would remain among the most common year after year, while there are advisories on it and patches for it. The answer is not very farfetched, but simple: system administrators do not correct many of these fl aws because they simply do not know which vulnerabilities are most dangerous; they are too busy to correct them all or they do not know how to correct them safely.

Although these vulnerabilities are cited, many of them year after year, as the most common vulnerabilities, there are traditionally thousands of vulnerabilities that hackers often use to attack systems. Because they are so numerous and new ones being discovered every day, many system administrators may be overwhelmed, which may lead to loss of focus on the need to ensure that all systems are protected against the most common attacks.

Let us take stock of what we have said so far. Lots and lots of system vulnerabilities have been observed and documented by SANS and CWE in their series, "CWE/ SANS Top 25 Most Dangerous Software Errors." However, there is a stubborn persistence of a number of vulnerabilities making the list year after year. This observation, together with the nature of software, as we have explored in Sect. 4.2.1 , means it is possible that what has been observed so far is a very small fraction of a potential sea of vulnerabilities; many of them probably will never be discovered because software will ever be subjected to either unexpected input sequences or operated in unexpected environments.

Besides the inherently embedded vulnerabilities resulting from fl awed designs, there are also vulnerabilities introduced in the operating environments as a result of incorrect implementations by operators. The products may not have weaknesses initially, but such weaknesses may be introduced as a result of bad or careless installations. For example, quite often products are shipped to customers with security features disabled, forcing the technology users to go through the dif fi cult and error-prone process of properly enabling the security features by oneself.

It is ironic that as "useful" technology develops so does the "bad" technology. What we call useful technology is the development in all computer and telecommunication technologies that are driving the Internet, telecommunication, and the Web. "Bad" technology is the technology that system intruders are using to attack systems. Unfortunately these technologies are all developing in tandem. In fact, there are times when it looks like hacker technologies are developing faster than the rest of the technologies. One thing is clear, though: hacker technology is fl ourishing.

Although it used to take intelligence, determination, enthusiasm, and perseverance to become a hacker, it now requires a good search engine, time, a little bit of knowledge of what to do, and owning a computer or an internet ready mobile device. There are thousands of hacker Web sites with the latest in script technologies and hundreds of recipe books and sources on how to put together an impact virus or a worm and how to upload it.

The ease of availability of these hacker tools; the ability of hackers to disguise their identities and locations; the automation of attack technology which further distances the attacker from the attack; the fact that attackers can go unidenti fi ed, limiting the fear of prosecution; and the ease of hacker knowledge acquisition have put a new twist in the art of hacking, making it seem easy and hence attracting more and younger disciples.

Besides the ease of becoming a hacker and acquiring hacker tools, because of the Internet sprawl, hacker impact has become overwhelming, impressive, and more destructive in shorter times than ever before. Take, for example, recent virus incidents such as the "I Love You," "Code Red," "Slammer," and the "Blaster" worms' spread. These worms and viruses probably spread around the world much faster than the human cold virus and the dreaded severe acute respiratory syndrome (SARS).

What these incidents have demonstrated is that the turnaround time, the time a virus is fi rst launched in the wild and the time it is fi rst cited as affecting the system, is becoming incredibly shorter. Both the turnaround time and the speed at which the virus or a worm spreads reduce the response time, the time a security incident fi rst affects the victim system and the time an effective response to the incident should have been initiated. When the response time is very short, security experts do not have enough time to respond to a security incident effectively. In a broader framework, when the turnaround time is very short, system security experts who develop patches do not have enough time to reverse engineer and analyze the attack in order to produce counter immunization codes. It has been and it is still the case in many security incidents for antivirus companies to take hours and sometimes days, such as in the case of the Code Red virus, to come up with an effective cure. However, even after a patch is developed, it takes time before it is fi ltered down to the system managers. Meantime, the damage has already been done, and it is multiplying. Likewise, system administrators and users have little time to protect their systems.

In his testimony to the Subcommittee on Government Ef fi ciency, Financial Management and Intergovernmental Relations of the US House Committee on Government Reform, Richard D. Pethia, director, CERT centers, pointed out the dif fi culty in fi xing known system vulnerabilities as one of the sources of system vulnerabilities. His concern was based on a number of factors, including the everrising number of system vulnerabilities and the ability of system administrators to cope with the number of patches issued for these vulnerabilities. As the number of vulnerabilities rises, system and network administrators face a dif fi cult situation. They are challenged with keeping up with all the systems they have and all the patches released for those systems. Patches can be dif fi cult to apply and might even have unexpected side effects as a result of compatibility issues [ 2 ] .

Besides the problem of keeping abreast of the number of vulnerabilities and the corresponding patches, there are also logistic problems between the time at which a vendor releases a security patch and the time at which a system administrator fi xes the vulnerable computer system. There are several factors affecting the quick fi xing of patches. Sometimes, it is the logistics of the distribution of patches. Many vendors disseminate the patches on their Web sites; others send e-mail alerts. However, sometimes busy systems administrators do not get around to these e-mails and security alerts until sometime after. Sometimes, it can be months or years before the patches are implemented on a majority of the vulnerable computers.

Many system administrators are facing the same chronic problems: the neverending system maintenance, limited resources, and highly demanding management. Under these conditions, the ever-increasing security system complexity, increasing system vulnerabilities, and the fact that many administrators do not fully understand the security risks, system administrators neither give security a high enough priority nor assign adequate resources. Exacerbating the problem is the fact that the demand for skilled system administrators far exceeds the supply [ 2 ] .

Data from Table 4 .1 shows a growing number of system attacks reported. However, given that just a small percentage of all attacks is reported, this table indicates a serious growing system security problem. As we have pointed out earlier, hacker technology is becoming more readily available, easier to get and assemble, more complex, and their effects more far reaching. All these indicate that urgent action is needed to fi nd an effective solution to this monstrous problem.

The security community, including scrupulous vendors, has come up with various solutions, some good and others not. In fact, in an unexpected reversal of fortunes, one of the new security problems is to fi nd a "good" solution from among thousands of solutions and to fi nd an "expert" security option from the many different views.

Are we reaching the limits of our efforts, as a community, to come up with a few good and effective solutions to this security problem? There are many signs to support an af fi rmative answer to this question. It is clear that we are reaching the limits of effectiveness of our reactive solutions. Richard D. Pethia gives the following reasons [ 2 ] :

The number of vulnerabilities in commercial off-the-shelf software is now at the • level that it is virtually impossible for any but the best resourced organizations to keep up with the vulnerability fi xes.

The Internet now connects more than 2.2 billion users and continues to grow at a • rapid pace. At any point in time, there are millions of connected computers and other devices that are vulnerable to one form of attack or another. Attack technology has now advanced to the point where it is easy for attackers to • take advantage of these vulnerable machines and harness them together to launch high-powered attacks. Many attacks are now fully automated, thus reducing the turnaround time even • further as they spread around cyberspace.

The attack technology has become increasingly complex and in some cases • intentionally stealthy, thus reducing the turnaround time and increasing the time it takes to discover and analyze the attack mechanisms in order to produce antidotes.

Internet users have become increasingly dependent on the Internet and now use • it for many critical applications so that a relatively minor attack has the potential to cause huge damages. Without being overly pessimistic, these factors, taken together, indicate that there is a high probability that more attacks are likely, and since they are getting more complex and attacking more computers, they are likely to cause signi fi cant devastating economic losses and service disruptions.

According to John Palumbo, social engineering is an outside hacker's use of psychological tricks on legitimate users of a computer system in order to gain the information (usernames and passwords) one needs to gain access to the system [ 5 ] .

Many have classi fi ed social engineering as a diversion, in the process of system attack, on people's intelligence to utilize two human weaknesses: fi rst, no one wants to be considered ignorant, and second is human trust. Ironically, these are two weaknesses that have made social engineering dif fi cult to fi ght because no one wants to admit falling for it. This has made social engineering a critical system security hole.

Many hackers have and continue to use it to get into protected systems. Kevin Mitnick, the notorious hacker, used it successfully and was arguably one of the most ingenious hackers of our time; he was de fi nitely very gifted with his ability to socially engineer just about anybody [ 5 ] .

Hackers use many approaches to social engineering, including the following [ 6 ] : • Telephone . This is the most classic approach, in which hackers call up a targeted individual in a position of authority or relevance and initiate a conversation with the goal of gradually pulling information out of the target. This is done mostly to help desks and main telephone switch boards. Caller ID cannot help because hackers can bypass it through tricks, and the target truly believes that the hacker is actually calling from inside the corporation. • Online . Hackers are harvesting a boom of vital information online from careless users. The reliance on and excessive use of the Internet have resulted in people having several online accounts. Currently an average user has about four to fi ve accounts including one for home use, one for work, and an additional one or two for social or professional organizations. With many accounts, as probably any reader may concur, one is bound to forget some passwords, especially the least used ones. To overcome this problem, users mistakenly use one password on several accounts. Hackers know this and they regularly target these individuals with clever baits such as telling them they won lotteries or were fi nalists in sweepstakes where computers select winners, or they have won a speci fi c number of prizes in a lotto, where they were computer selected. However, in order to get the award, the user must fi ll in an online form, usually Web-based, and this transmits the password to the hacker. Hackers have used hundreds of tricks on unsuspecting users in order for them to surrender their passwords. • Dumpster diving is now a growing technique of information theft not only in social engineering but more so in identity theft. The technique, also known as trashing, involves an information thief scavenging through individual and company dumpsters for information. Large and critical information can be dug out of dumpsters and trash cans. Dumpster diving can recover from dumpsters and trash cans individual social security numbers, bank accounts, individual vital records, and a whole list of personal and work-related information that gives the hackers the exact keys they need to unlock the network. • In person is the oldest of the information stealing techniques that predates computers. It involves a person physically walking into an organization's of fi ces and casually checking out note boards, trash diving into bathroom trash cans and company hallway dumpsters, and eating lunches together and initiating conversations with employees. In big companies, this can be done only on a few occasions before trusted friendships develop. From such friendships, information can be passed unconsciously. • Snail mail is done in several ways and is not limited only to social engineering but has also been used in identity theft and a number of other crimes. It has been in the news recently because of identity theft. It is done in two ways: the hacker picks a victim and goes to the post of fi ce and puts in a change of address form to a new box number. This gives the hacker a way to intercept all snail mail of the victim. From the intercepted mail, the hacker can gather a great deal of information that may include the victim's bank and credit card account numbers and access control codes and pins by claiming to have forgotten his or her password or pin and requesting a reissue in the mail. In another form, the hacker drops a bogus survey in the victim's mailbox offering baits of cash award for completing a "few simple" questions and mailing them in. The questions, in fact, request far more than simple information from an unsuspecting victim. • Impersonation is also an old trick played on unsuspecting victims by criminals for a number of goodies. These days the goodies are information. Impersonation is generally acting out a victim's character role. It involves the hacker playing a role and passing himself or herself as the victim. In the role, the thief or hacker can then get into legitimate contacts that lead to the needed information. In large organizations with hundreds or thousands of employees scattered around the globe, it is very easy to impersonate a vice president or a chief operations of fi cer. Since most employees always want to look good to their bosses, they will end up supplying the requested information to the imposter. Overall, social engineering is a cheap but rather threatening security problem that is very dif fi cult to deal with.

Vulnerability assessment is a process that works on a system to identify, track, and manage the repair of vulnerabilities on the system. The assortment of items that are checked by this process in a system under review varies depending on the organization. It may include all desktops, servers, routers, and fi rewalls. Most vulnerability assessment services will provide system administrators with: Network mapping and system fi ngerprinting of all known vulnerabilities • A complete vulnerability analysis and ranking of all exploitable weaknesses based • on potential impact and likelihood of occurrence for all services on each host Prioritized list of miscon fi gurations •

In addition, at the end of the process, a fi nal report is always produced detailing the fi ndings and the best way to go about overcoming such vulnerabilities. This report consists of prioritized recommendations for mitigating or eliminating weaknesses, and based on an organization's operational schedule, it also contains recommendations of further reassessments of the system within given time intervals or on a regular basis. More details in Chap. 9 .

Due to the massive growth of the number of companies and organizations owning their own networks, the growth of vulnerability monitoring technologies, the increase in network intrusions and attacks with viruses, and worldwide publicity of such attacks, there is a growing number of companies offering system vulnerability services. These services, target the internals and perimeter of the system, Web-based applications, and provide a baseline to measuring subsequent attacks against the system including scanning, assessment and penetration testing, and application assessment.

Vulnerability scanning services provide a comprehensive security review of the system, including both the perimeter and system internals. The aim of this kind of scanning is to spot critical vulnerabilities and gaps in the system's security practices. Comprehensive system scanning usually results in a number of both false positives and negatives. It is the job of the system administrator to fi nd ways of dealing with these false positives and negatives. The fi nal report produced after each scan consists of strategic advice and prioritized recommendations to ensure that critical holes are addressed fi rst. System scanning can be scheduled, depending on the level of the requested scan, by the system user or the service provider, to run automatically and report by either automated or periodic e-mail to a designated user. The scans can also be stored on a secure server for future review.

This phase of vulnerability assessment is a hands-on testing of a system for identi fi ed and unidenti fi ed vulnerabilities. All known hacking techniques and tools are tested during this phase to reproduce real-world attack scenarios. One of the outcomes of these real-life testings is that new and sometimes obscure vulnerabilities are found, processes and procedures of attack are identi fi ed, and sources and severity of vulnerabilities are categorized and prioritized based on the user-provided risks.

As Web applications become more widespread and more entrenched into e-commerce and all other commercial and business areas, applications are slowly becoming the main interface between the user and the network. The increased demands on applications have resulted into new directions in automation and dynamism of these applications. As we will see in Chap. 6 , scripting in Web applications, for example, has opened a new security paradigm in system administration. Many organizations have gotten sense of these dangers and are making substantial progress in protecting their systems from attacks via Web-based applications. Assessing the security of system applications is, therefore, becoming a special skills requirement needed to secure critical systems.

Vulnerability online services have many advantages for system administrators. They can, and actually always do, provide and develop signatures and updates for new vulnerabilities and automatically include them in the next scan. This eliminates the need for the system administrator to schedule periodic updates.

Reports from these services are very detailed not only on the vulnerabilities, sources of vulnerabilities, and existence of false positives, but they also focus on vulnerability identi fi cation and provide more information on system con fi guration that may not be readily available to system administrators. This information alone goes a long way in providing additional security awareness to security experts about additional avenues whereby systems may be attacked. The reports are then encrypted and stored in secure databases accessible only with the proper user credentials. This is because these reports contain critically vital data on the security of the system and they could, therefore, be a pot of gold for hackers if found. This additional care and awareness adds security to the system.

Probably, the best advantage to an overworked and many times resource-strapped system administrator is the automated and regularly scheduled scan of all network resources. They provide, in addition, a badly needed third-party "security eye," thus helping the administrator to provide an objective yet independent security evaluation of the system.

What is a vulnerability? What do you understand by a system vulnerability? 2. Discuss four sources of system vulnerabilities

What are the best ways to identify system vulnerabilities?

What is innovative misuse? What role does it play in the search for solutions to system vulnerability?

What is incomplete implementation? Is it possible to deal with incomplete implementation as a way of dealing with system vulnerabilities?

What is social engineering? Why is it such a big issue yet so cheap to perform? Is it possible to completely deal with it? Why or why not?

Some have described social engineering as being perpetuated by our internal fears. Discuss those fears

What is the role of software security testing in the process of fi nding solutions to system vulnerabilities?

Some have sounded an apocalyptic voice as far as fi nding solutions to system vulnerabilities. Should we take them seriously?

What is innovative misuse? What role does it play in the search for solutions to system vulnerabilities?

Is it possible to locate all vulnerabilities in a network? In other words, can one make an authoritative list of those vulnerabilities? Defend your response

Why are design fl aws such a big issue in the study of vulnerability? 5. Part of the problem in design fl aws involves issues associated with software veri fi cation and validation (V&V). What is the role of V&V in system vulnerability?

Information Security: Protecting the Global Enterprise

Information Technology-Essential But Vulnerable: How Prepared Are We for Attacks?

Ethical and Social Issues in the Information Age

Open Source and Linux

Social Engineering: What is it, why is so little said about it and what can be done? SANS

Social Engineering Fundamentals