Threats in Networks

Up to now, we have reviewed network concepts with very little discussion of their security
implications. But our earlier discussion of threats and vulnerabilities, as well as outside articles
and your own experiences, probably have you thinking about the many possible attacks against
networks. This section describes some of the threats you have already hypothesized and
perhaps presents you with some new ones. But the general thrust is the same: threats aimed to
compromise confidentiality, integrity, or availability, applied against data, software, and
hardware by nature, accidents, nonmalicious humans, and malicious attackers.

What Makes a Network Vulnerable?

An isolated home user or a stand-alone office with a few employees is an unlikely target for
many attacks. But add a network to the mix and the risk rises sharply. Consider how a network
differs from a stand-alone environment:

Anonymity. An attacker can mount an attack from thousands of miles away and never come into
direct contact with the system, its administrators, or users. The potential attacker is thus safe
behind an electronic shield. The attack can be passed through many other hosts in an effort to
disguise the attack's origin. And computer-to-computer authentication is not the same for
computers as it is for humans; as illustrated by Sidebar 7-2, secure distributed authentication
requires thought and attention to detail.

Many points of attack both targets and origins. A simple computing system is a self-contained unit.
Access controls on one machine preserve the confidentiality of data on that processor.
However, when a file is stored in a network host remote from the user, the data or the file itself
may pass through many hosts to get to the user. One host's administrator may enforce rigorous
security policies, but that administrator has no control over other hosts in the network. Thus,
the user must depend on the access control mechanisms in each of these systems. An attack
can come from any host to any host, so that a large network offers many points of vulnerability.
Sharing. Because networks enable resource and workload sharing, more users have the potential
to access networked systems than on single computers. Perhaps worse, access is afforded to
more systems, so that access controls for single systems may be inadequate in networks.

Complexity of system. In Chapter 4 we saw that an operating system is a complicated piece of

software. Reliable security is difficult, if not impossible, on a large operating system, especially
one not designed specifically for security. A network combines two or more possibly dissimilar
operating systems. Therefore, a network operating/control system is likely to be more complex
than an operating system for a single computing system. Furthermore, the ordinary desktop
computer today has greater computing power than did many office computers in the last two
decades. The attacker can use this power to advantage by causing the victim's computer to
perform part of the attack's computation. And because an average computer is so powerful,
most users do not know what their computers are really doing at any moment: What processes
are active in the background while you are playing Invaders from Mars? This complexity
diminishes confidence in the network's security.

A network's expandability also implies uncertainty about the network boundary. One host may
be a node on two different networks, so resources on one network are accessible to the users
of the other network as well. Although wide accessibility is an advantage, this unknown or
uncontrolled group of possibly malicious users is a security disadvantage. A similar problem
occurs when new hosts can be added to the network. Every network node must be able to react
to the possible presence of new, untrustable hosts. Figure 7-11 points out the problems in
defining the boundaries of a network. Notice, for example, that a user on a host in network D
may be unaware of the potential connections from users of networks A and B. And the host in
the middle of networks A and B in fact belongs to A, B, C, and E. If there are different security
rules for these networks, to what rules is that host subject?
Unknown path. Figure 7-12 illustrates that there may be many paths from one host to another.
Suppose that a user on host A1 wants to send a message to a user on host B3. That message
might be routed through hosts C or D before arriving at host B3. Host C may provide acceptable
security, but not D. Network users seldom have control over the routing of their messages.
Thus, a network differs significantly from a stand-alone, local environment. Network
characteristics significantly increase the security risk.

Who Attacks Networks?

Who are the attackers? We cannot list their names, just as we cannot know who are all the
criminals in our city, country, or the world. Even if we knew who they were, we do not know
if we could stop their behavior. To have some idea of who the attackers might be, we return to
concepts introduced in Chapter 1, where we described the three necessary components of an
attack: method, opportunity, and [Link] the next sections we explore method: tools and
techniques the attackers use. Here we consider first the motives of attackers. Focusing on
motive may give us some idea of who might attack a networked host or user. Four important
motives are challenge or power, fame, money, and ideology.

Challenge

Why do people do dangerous or daunting things, like climb mountains or swim the English
Channel or engage in extreme sports? Because of the challenge. The situation is no different
for someone skilled in writing or using programs. The single most significant motivation for a
network attacker is the intellectual challenge. He or she is intrigued with knowing the answers
to Can I defeat this network? What would happen if I tried this approach or that technique?
Some attackers enjoy the intellectual stimulation of defeating the supposedly undefeatable. For
example, Robert Morris, who perpetrated the Internet worm in 1988 (described in Chapter 3),
attacked supposedly as an experiment to see if he could exploit a particular vulnerability. Other
attackers, such as the Cult of the Dead Cow, seek to demonstrate weaknesses in security
defenses so that others will pay attention to strengthening security. Still other attackers are
unnamed, unknown individuals working persistently just to see how far they can go in
performing unwelcome activities.

However, as you will soon see, only a few attackers find previously unknown flaws. The vast
majority of attackers repeat well-known and even well-documented attacks, sometimes only to
see if they work against different hosts. In these cases, intellectual stimulation is certainly not
the driving force, when the attacker is merely pressing [run] to activate an attack discovered,
designed, and implemented by someone else.

Fame

The challenge of accomplishment is enough for some attackers. But other attackers seek
recognition for their activities. That is, part of the challenge is doing the deed; another part is
taking credit for it. In many cases, we do not know who the attackers really are, but they leave
behind a "calling card" with a name or moniker: Mafiaboy, Kevin Mitnick, Fluffy Bunny, and
members of the Chaos Computer Club, for example. The actors often retain some anonymity
by using pseudonyms, but they achieve fame nevertheless. They may not be able to brag too
openly, but they enjoy the personal thrill of seeing their attacks written up in the news media.

Money and Espionage

As in other settings, financial reward motivates attackers, too. Some attackers perform
industrial espionage, seeking information on a company's products, clients, or long-range
plans. We know industrial espionage has a role when we read about laptops and sensitive papers
having been lifted from hotel rooms when other more valuable items were left behind. Some
countries are notorious for using espionage to aid their state-run industries. Sometimes
industrial espionage is responsible for seemingly strange corporate behavior. For example, in
July 2002, newspapers reported that a Yale University security audit had revealed that
admissions officers from rival Princeton University broke into Yale's online admissions
notification system. The Princeton snoops admitted looking at the confidential decisions about
eleven students who had applied to both schools but who had not yet been told of their decisions
by Yale. In another case, a startup company was about to activate its first application on the
web. Two days before the application's unveiling, the head offices were burglarized. The only
item stolen was the one computer containing the application's network design. Corporate
officials had to make a difficult choice: Go online knowing that a competitor might then take
advantage of knowing the internal architecture or delay the product's rollout until the network
design was changed. They chose the latter. Similarly, the chief of security for a major
manufacturing company has reported privately to us of evidence that one of the company's
competitors had stolen information. But he could take no action because he could not determine
which of three competitors was the actual culprit.

Industrial espionage is illegal, but it occurs, in part because of the high potential gain. Its
existence and consequences can be embarrassing for the target companies. Thus, many
incidents go unreported, and there are few reliable statistics on how much industrial espionage
and "dirty tricks" go on. Yearly since 1997, the Computer Security Institute and the U.S.
Federal Bureau of Investigation have surveyed security professionals from companies,
government agencies, universities, and organizations, asking them to report perceptions of
computer incidents. About 500 responses are received for each survey. Theft of intellectual
property amounted to a total loss of $31 million, with an average loss per incident of $350
thousand, making this the category of third-highest loss. That amount was more than double
the amount reported in the 2004 survey. (These survey results are anecdotal, so it is hard to
draw many conclusions. For full details on the survey see [CSI05].) Industrial espionage,
leading to loss of intellectual property, is clearly a problem.

Organized Crime

With the growth in commercial value of the Internet, participation by organized crime has also
increased. In October 2004, police arrested members of a 28-person gang of Internet criminals,
called the Shadowcrew, who operated out of six foreign countries and eight states in the United
States. Six leaders of that group pled guilty to charges, closing an illicit business that trafficked
in at least 1.5 million stolen credit and bank card numbers and resulted in losses in excess of
$4 million. In July 2003, Alexey Ivanov was convicted as the supervisor of a wide-ranging,
organized criminal enterprise that engaged in sophisticated manipulation of computer data,
financial information, and credit card numbers. Ivanov and group were responsible for an
aggregate loss of approximately $25 million. And in January 2006, Jeanson James Ancheta
pled guilty to having infected 400,000 computers with malicious code and renting their use to
others to use to launch attacks on others. In June 2005, the FBI and law enforcement from 10
other countries conducted over 90 searches worldwide as part of "Operation Site Down,"
designed to disrupt and dismantle many of the leading criminal organizations that illegally
distribute and trade in copyrighted software, movies, music, and games on the
Internet [DOJ06]. Brazilian police arrested 85 people in 2005 for Internet fraud. Although
money is common to these crimes, the more interesting fact is that they often involve
collaborators from several countries. These more sophisticated attacks require more than one
person working out of a bedroom, and so organization and individual responsibilities follow.
With potential revenue in the millions of dollars and operations involving hundreds of
thousands of credit card numbers and other pieces of identity, existing organized crime units
are sure to take notice. As Williams [WIL01] says, "[T]here is growing evidence that organized
crime groups are exploiting the new opportunities offered by the Internet."

Ideology

In the last few years, we are starting to find cases in which attacks are perpetrated to advance
ideological ends. For example, many security analysts believe that the Code Red worm of 2001
was launched by a group motivated by the tension in [Link] relations.
Denning [DEN99a] has distinguished between two types of related behaviors, hactivism and
cyberterrorism. Hactivism involves "operations that use hacking techniques against a target's
[network] with the intent of disrupting normal operations but not causing serious damage." In
some cases, the hacking is seen as giving voice to a constituency that might otherwise not be
heard by the company or government organization. For example, Denning describes activities
such as virtual sit-ins, in which an interest group floods an organization's web site with traffic
to demonstrate support of a particular position. Cyberterrorism is more dangerous than
hactivism: "politically motivated hacking operations intended to cause grave harm such as loss
of life or severe economic damage." Security and terrorism experts are seeing increasing use
of the Internet as an attack vector, as a communications medium among attackers, and as a
point of attack. Cullison [CUL04] presents a very interesting insight (which we overview
in Sidebar 1-6, p. 24) into of the use of technology by al Qaeda.
Reconnaissance

Now that we have listed many motives for attacking, we turn to how attackers perpetrate their
attacks. Attackers do not ordinarily sit down at a terminal and launch an attack. A clever
attacker investigates and plans before acting. Just as you might invest time in learning about a
jewelry store before entering to steal from it, a network attacker learns a lot about a potential
target before beginning the attack. We study the precursors to an attack so that if we can
recognize characteristic behavior, we may be able to block the attack before it is launched.
Because most vulnerable networks are connected to the Internet, the attacker begins preparation
by finding out as much as possible about the target. An example of information gathering is
given in [HOB97]. (Not all information gathered is accurate, however; see Sidebar 7-4 for a
look at reconnaissance combined with deception.)

Port Scan
An easy way to gather network information is to use a port scan, a program that, for a
particular IP address, reports which ports respond to messages and which of several known
vulnerabilities seem to be present. Farmer and Venema [FAR93] are among the first to describe
the technique. A port scan is much like a routine physical examination from a doctor,
particularly the initial questions used to determine a medical history. The questions and
answers by themselves may not seem significant, but they point to areas that suggest further
investigation.

Port scanning tells an attacker three things: which standard ports or services are running and
responding on the target system, what operating system is installed on the target system, and
what applications and versions of applications are present. This information is readily available
for the asking from a networked system; it can be obtained quietly, anonymously, without
identification or authentication, drawing little or no attention to the scan. Port scanning tools
are readily available, and not just to the underground community. The nmap scanner by Fyodor
at [Link]/nmap is a useful tool that anyone can download. Given an address, nmap
will report all open ports, the service they support, and the owner (user ID) of the daemon
providing the service. (The owner is significant because it implies what privileges would
descend upon someone who compromised that service.) Another readily available scanner is
netcat, written by Hobbit, at [Link]/users/l0pht. (That URL is "letter ell," "digit zero,"
p-h-t.) Commercial products are a little more costly, but not prohibitive. Well-known
commercial scanners are Nessus (Nessus Corp. [AND03]), CyberCop Scanner (Network
Associates), Secure Scanner (Cisco), and Internet Scanner (Internet Security Systems).

Social Engineering

The port scan gives an external picture of a networkwhere are the doors and windows, of what
are they constructed, to what kinds of rooms do they open? The attacker also wants to know
what is inside the building. What better way to find out than to ask? Suppose, while sitting at
your workstation, you receive a phone call. "Hello, this is John Davis from IT support. We
need to test some connections on the internal network. Could you please run the command
ipconfig/all on your workstation and read to me the addresses it displays?" The request sounds
innocuous. But unless you know John Davis and his job responsibilities well, the caller could
be an attacker gathering information on the inside architecture.

Social engineering involves using social skills and personal interaction to get someone to
reveal security-relevant information and perhaps even to do something that permits an attack.
The point of social engineering is to persuade the victim to be helpful. The attacker often
impersonates someone inside the organization who is in a bind: "My laptop has just been stolen
and I need to change the password I had stored on it," or "I have to get out a very important
report quickly and I can't get access to the following thing." This attack works especially well
if the attacker impersonates someone in a high position, such as the division vice president or
the head of IT security. (Their names can sometimes be found on a public web site, in a network
registration with the Internet registry, or in publicity and articles.) The attack is often directed
at someone low enough to be intimidated or impressed by the high-level person. A direct phone
call and expressions of great urgency can override any natural instinct to check out the story.
Because the victim has helped the attacker (and the attacker has profusely thanked the victim),
the victim will think nothing is wrong and not report the incident. Thus, the damage may not
be known for some time. An attacker has little to lose in trying a social engineering attack. At
worst it will raise awareness of a possible target. But if the social engineering is directed against
someone who is not skeptical, especially someone not involved in security management, it may
well succeed. We as humans like to help others when asked politely.
Intelligence

From a port scan the attacker knows what is open. From social engineering, the attacker knows
certain internal details. But a more detailed floor plan would be nice. Intelligence is the general
term for collecting information. In security it often refers to gathering discrete bits of
information from various sources and then putting them together like the pieces of a puzzle.
One commonly used intelligence technique is called "dumpster diving." It involves looking
through items that have been discarded in rubbish bins or recycling boxes. It is amazing what
we throw away without thinking about it. Mixed with the remains from lunch might be network
diagrams, printouts of security device configurations, system designs and source code,
telephone and employee lists, and more. Even outdated printouts may be useful. Seldom will
the configuration of a security device change completely. More often only one rule is added or
deleted or modified, so an attacker has a high probability of a successful attack based on the
old information.

Gathering intelligence may also involve eavesdropping. Trained spies may follow employees
to lunch and listen in from nearby tables as coworkers discuss security matters. Or spies may
befriend key personnel in order to co-opt, coerce, or trick them into passing on useful
information. Most intelligence techniques require little training and minimal investment of
time. If an attacker has targeted a particular organization, spending a little time to collect
background information yields a big payoff.

Operating System and Application Fingerprinting

The port scan supplies the attacker with very specific information. For instance, an attacker
can use a port scan to find out that port 80 is open and supports HTTP, the protocol for
transmitting web pages. But the attacker is likely to have many related questions, such as which
commercial server application is running, what version, and what the underlying operating
system and version are. Once armed with this additional information, the attacker can consult
a list of specific software's known vulnerabilities to determine which particular weaknesses to
try to exploit.

How can the attacker answer these questions? The network protocols are standard and vendor
independent. Still, each vendor's code is implemented independently, so there may be minor
variations in interpretation and behavior. The variations do not make the software
noncompliant with the standard, but they are different enough to make each version distinctive.
For example, each version may have different sequence numbers, TCP flags, and new options.
To see why, consider that sender and receiver must coordinate with sequence numbers to
implement the connection of a TCP session. Some implementations respond with a given
sequence number, others respond with the number one greater, and others respond with an
unrelated number. Likewise, certain flags in one version are undefined or incompatible with
others. How a system responds to a prompt (for instance, by acknowledging it, requesting
retransmission, or ignoring it) can also reveal the system and version. Finally, new features
offer a strong clue: A new version will implement a new feature but an old version will reject
the request. All these peculiarities, sometimes called the operating system or application
fingerprint, can mark the manufacturer and version.

For example, in addition to performing its port scan, a scanner such as nmap will respond with
a guess at the target operating system. For more information about how this is done, see the
paper at [Link]/nmap/[Link].

Sometimes the application identifies itself. Usually a client-server interaction is handled

completely within the application according to protocol rules: "Please send me this page; OK
but run this support code; thanks, I just did." But the application cannot respond to a message
that does not follow the expected form. For instance, the attacker might use a Telnet application
to send meaningless messages to another application. Ports such as 80 (HTTP), 25 (SMTP),
110 (POP), and 21 (FTP) may respond with something like

Impersonation

In many instances, there is an easier way than wiretapping for obtaining information on a
network: Impersonate another person or process. Why risk tapping a line, or why bother
extracting one communication out of many, if you can obtain the same data directly?
Impersonation is a more significant threat in a wide area network than in a local one. Local
individuals often have better ways to obtain access as another user; they can, for example,
simply sit at an unattended workstation. Still, impersonation attacks should not be ignored even
on local area networks, because local area networks are sometimes attached to wider area
networks without anyone's first thinking through the security implications.

In an impersonation, an attacker has several choices:

Guess the identity and authentication details of the target.

Pick up the identity and authentication details of the target from a previous communication or
from wiretapping.
Circumvent or disable the authentication mechanism at the target computer.
Use a target that will not be authenticated.
Use a target whose authentication data are known. Let us look at each choice.

Authentication Foiled by Guessing

Chapter 4 reported the results of several studies showing that many users choose easy-to-guess
passwords. In Chapter 3, we saw that the Internet worm of 1988 capitalized on exactly that
flaw. Morris's worm tried to impersonate each user on a target machine by trying, in order, a
handful of variations of the user name, a list of about 250 common passwords and, finally, the
words in a dictionary. Sadly, many users' accounts are still open to these easy attacks.

A second source of password guesses is default passwords. Many systems are initially
configured with default accounts having GUEST or ADMIN as login IDs; accompanying these
IDs are well-known passwords such as "guest" or "null" or "password" to enable the
administrator to set up the system. Administrators often forget to delete or disable these
accounts, or at least to change the passwords.

In a trustworthy environment, such as an office LAN, a password may simply be a signal that
the user does not want others to use the workstation or account. Sometimes the password-
protected workstation contains sensitive data, such as employee salaries or information about
new products. Users may think that the password is enough to keep out a curious colleague;
they see no reason to protect against concerted attacks. However, if that trustworthy
environment is connected to an untrustworthy wider-area network, all users with simple
passwords become easy targets. Indeed, some systems are not originally connected to a wider
network, so their users begin in a less exposed situation that clearly changes when the
connection occurs.

Dead accounts offer a final source of guessable passwords. To see how, suppose Professor
Romine, a faculty member, takes leave for a year to teach at another university. The existing
account may reasonably be kept on hold, awaiting the professor's return. But an attacker,
reading a university newspaper online, finds out that the user is away. Now the attacker uses
social engineering on the system administration ("Hello, this is Professor Romine calling from
my temporary office at State University. I haven't used my account for quite a while, but now
I need something from it urgently. I have forgotten the password. Can you please reset it to
ICECREAM? No? Well, send me a new password by email to my account r1@[Link].")
Alternatively, the attacker can try several passwords until the password guessing limit is
exceeded. The system then locks the account administratively, and the attacker uses a social
engineering attack. In all these ways the attacker may succeed in resetting or discovering a
password.

Authentication Thwarted by Eavesdropping or Wiretapping

Because of the rise in distributed and client-server computing, some users have access
privileges on several connected machines. To protect against arbitrary outsiders using these
accesses, authentication is required between hosts. This access can involve the user directly, or
it can be done automatically on behalf of the user through a host-to-host authentication
protocol. In either case, the account and authentication details of the subject are passed to the
destination host. When these details are passed on the network, they are exposed to anyone
observing the communication on the network. These same authentication details can be reused
by an impersonator until they are changed. Because transmitting a password in the clear is a
significant vulnerability, protocols have been developed so that the password itself never leaves
a user's workstation. But, as we have seen in several other places, the details are important.

Microsoft LAN Manager was an early method for implementing networks. It had a
password exchange mechanism in which the password itself was never transmitted in the clear;
instead only a cryptographic hash of it was transmitted. A password could consist of up to 14
characters. It could include upper- and lowercase letters, digits, and special characters, for 67
possibilities in any one position, and 6714 possibilities for a whole 14 -character password quite
a respectable work factor. However, those 14 characters were not diffused across the entire
hash; they were sent in separate substrings, representing characters 17 and 814. A 7-character
or shorter password had all nulls in the second substring and was instantly recognizable. An 8-
character password had 1 character and 6 nulls in the second substring, so 67 guesses would
find the one character. Even in the best case, a 14- character password, the work factor fell
from 6714 to 677 + 67 7 = 2 * 677. These work factors differ by a factor of approximately 10
billion. (See [MUD97] for details.) LAN Manager authentication was preserved in many later
systems (including Windows NT) as an option to support backward compatibility with systems
such as Windows 95/98. This lesson is a good example of why security and cryptography are
very precise and must be monitored by experts from concept through design and
implementation.
Authentication Foiled by Avoidance

Obviously, authentication is effective only when it works. A weak or flawed authentication

allows access to any system or person who can circumvent the authentication. In a classic
operating system flaw, the buffer for typed characters in a password was of fixed size, counting
all characters typed, including backspaces for correction. If a user typed more characters than
the buffer would hold, the overflow caused the operating system to bypass password
comparison and act as if a correct authentication had been supplied. These flaws or weaknesses
can be exploited by anyone seeking access.

Many network hosts, especially those that connect to wide area networks, run variants of Unix
System V or BSD Unix. In a local environment, many users are not aware of which networked
operating system is in use; still fewer would know of, be capable of, or be interested in
exploiting flaws. However, some hackers regularly scan wide area networks for hosts running
weak or flawed operating systems. Thus, connection to a wide area network, especially the
Internet, exposes these flaws to a wide audience intent on exploiting them.

Non-existent Authentication

If two computers are used by the same users to store data and run processes and if each has
authenticated its users on first access, you might assume that computer-to-computer or local
user-to-remote process authentication is unnecessary. These two computers and their users are
a trustworthy environment in which the added complexity of repeated authentication seems
excessive.

However, this assumption is not valid. To see why, consider the Unix operating system. In
Unix, the file .rhosts lists trusted hosts and .rlogin lists trusted users who are allowed access
without authentication. The files are intended to support computer-to-computer connection by
users who have already been authenticated at their primary hosts. These "trusted hosts" can
also be exploited by outsiders who obtain access to one system through an authentication
weakness (such as a guessed password) and then transfer to another system that accepts the
authenticity of a user who comes from a system on its trusted list.

An attacker may also realize that a system has some identities requiring no authentication.
Some systems have "guest" or "anonymous" accounts to allow outsiders to access things the
systems want to release to anyone. For example, a bank might post a current listing of foreign
currency rates, a library with an online catalog might make that catalog available for anyone to
search, or a company might allow access to some of its reports. A user can log in as "guest"
and retrieve publicly available items. Typically, no password is required, or the user is shown
a message requesting that the user type "GUEST" (or your name, which really means any string
that looks like a name) when asked for a password. Each of these accounts allows access to
unauthenticated users.

Well-Known Authentication

Authentication data should be unique and difficult to guess. But unfortunately, the
convenience of one well-known authentication scheme sometimes usurps the protection. For
example, one computer manufacturer planned to use the same password to allow its remote
maintenance personnel to access any of its computers belonging to any of its customers
throughout the world. Fortunately, security experts pointed out the potential danger before that
idea was put in place.

The system network management protocol (SNMP) is widely used for remote management of
network devices, such as routers and switches, that support no ordinary users. SNMP uses a
"community string," essentially a password for the community of devices that can interact with
one another. But network devices are designed especially for quick installation with minimal
configuration, and many network administrators do not change the default community string
installed on a router or switch. This laxity makes these devices on the network perimeter open
to many SNMP attacks.

Some vendors still ship computers with one system administration account installed, having a
default password. Or the systems come with a demonstration or test account, with no required
password. Some administrators fail to change the passwords or delete these accounts.

Trusted Authentication

Finally, authentication can become a problem when identification is delegated to other trusted
sources. For instance, a file may indicate who can be trusted on a particular host. Or the
authentication mechanism for one system can "vouch for" a user. We noted earlier how the
Unix .rhosts, .rlogin, and /etc/hosts/equiv files indicate hosts or users that are trusted on other
hosts. While these features are useful to users who have accounts on multiple machines or for
network management, maintenance, and operation, they must be used very carefully. Each of
them represents a potential hole through which a remote useror a remote attackercan achieve
access.
Spoofing

Guessing or otherwise obtaining the network authentication credentials of an entity (a user, an

account, a process, a node, a device) permits an attacker to create a full communication under
the entity's identity. Impersonation falsely represents a valid entity in a communication. Closely
related is spoofing, when an attacker falsely carries on one end of a networked interchange.
Examples of spoofing are masquerading, session hijacking, and man-in-the-middle attacks.

Masquerade

In a masquerade one host pretends to be another. A common example is URL confusion.

Domain names can easily be confused, or someone can easily mistype certain names. Thus
[Link], [Link], and [Link] might be three different organizations, or one bona fide
organization (for example, [Link]) and two masquerade attempts from someone who
registered the similar domain names. Names with or without hyphens ([Link] versus
[Link]) and easily mistyped names ([Link] versus [Link], or [Link] versus
[Link]) are candidates for masquerading.

From the attacker's point of view, the fun in masquerading comes before the mask is removed.
For example, suppose you want to attack a real bank, First Blue Bank of Chicago. The actual
bank has the domain name [Link], so you register the domain name [Link].
Next, you put up a web page at [Link], perhaps using the real Blue Bank logo that
you downloaded to make your site look as much as possible like that of the Chicago bank.
Finally, you ask people to log in with their name, account number, and password or PIN. (This
redirection can occur in many ways. For example, you can pay for a banner ad that links to
your site instead of the real bank's, or you can send e-mail to Chicago residents and invite them
to visit your site.) After collecting personal data from several bank users, you can drop the
connection, pass the connection on to the real Blue Bank, or continue to collect more
information. You may even be able to transfer this connection smoothly to an authenticated
access to the real Blue Bank so that the user never realizes the deviation. (First Blue Bank
would probably win a suit to take ownership of the [Link] domain.)
A variation of this attack is called phishing. You send an e-mail message, perhaps with the real
logo of Blue Bank, and an enticement to click on a link, supposedly to take the victim to the
Blue Bank web site. The enticement might be that your victim's account has been suspended
or that you offer your victim some money for answering a survey (and need the account number
and PIN to be able to credit the money), or some other legitimate-sounding explanation. The
link might be to your domain [Link], the link might say click here to access your
account (where the click here link connects to your fraudulent site), or you might use some
other trick with the URL to fool your victim, like [Link]/[Link].

In another version of a masquerade, the attacker exploits a flaw in the victim's web server and
is able to overwrite the victim's web pages. Although there is some public humiliation at having
one's site replaced, perhaps with obscenities or strong messages opposing the nature of the site
(for example, a plea for vegetarianism on a slaughterhouse web site), most people would not
be fooled by a site displaying a message absolutely contrary to its aims. However, a clever
attacker can be more subtle. Instead of differentiating from the real site, the attacker can try to
build a false site that resembles the real one, perhaps to obtain sensitive information (names,
authentication numbers, credit card numbers) or to induce the user to enter into a real
transaction. For example, if one bookseller's site, call it Books-R-Us, were overtaken subtly by
another, called Books Depot, the orders may actually be processed, filled, and billed to the
naïve users by Books Depot. Test your ability to distinguish phishing sites from real ones
at [Link]

Phishing is becoming a serious problem, according to a trends report from the Anti-Phishing
Working Group [APW05]. This group received over 12,000 complaints each month from
March 2005 to March 2006, with the number peaking above 18,000 for March 2006.

Session Hijacking

Session hijacking is intercepting and carrying on a session begun by another entity. Suppose
two entities have entered into a session but then a third entity intercepts the traffic and carries
on the session in the name of the other. Our example of Books-R-Us could be an instance of
this technique. If Books Depot used a wiretap to intercept packets between you and Books-R-
Us, Books Depot could simply monitor the information flow, letting Books-R-Us do the hard
part of displaying titles for sale and convincing the user to buy. Then, when the user has
completed the order, Books Depot intercepts the "I'm ready to check out" packet, and finishes
the order with the user, obtaining shipping address, credit card details, and so forth. To Books-
R-Us, the transaction would look like any other incomplete transaction: The user was browsing
but for some reason decided to go elsewhere before purchasing. We would say that Books
Depot had hijacked the session.

A different type of example involves an interactive session, for example, using Telnet. If a
system administrator logs in remotely to a privileged account, a session hijack utility could
intrude in the communication and pass commands as if they came from the administrator.

Man-in-the-Middle Attack

Our hijacking example requires a third party involved in a session between two entities.
A man-in-the -middle attack is a similar form of attack, in which one entity intrudes between
two others. We studied one form of this attack in Chapter 3. The difference between man-in-
the-middle and hijacking is that a man-in-the-middle usually participates from the start of the
session, whereas a session hijacking occurs after a session has been established. The difference
is largely semantic and not too significant.

Man-in-the-middle attacks are frequently described in protocols. To see how an attack works,
suppose you want to exchange encrypted information with your friend. You contact the key
server and ask for a secret key with which to communicate with your friend. The key server
responds by sending a key to you and your friend. One man-in-the-middle attack assumes
someone can see and enter into all parts of this protocol. A malicious middleman intercepts the
response key and can then eavesdrop on, or even decrypt, modify, and reencrypt any
subsequent communications between you and your friend. This attack is depicted in Figure 7-
15.
This attack would be changed with public keys, because the man-in-the-middle would not have
the private key to be able to decrypt messages encrypted under your friend's public key. The
man-in-the-middle attack now becomes more of the three-way interchange its name implies.
The man-in-the-middle intercepts your request to the key server and instead asks for your
friend's public key. The man-in-the-middle passes to you his own public key, not your friend's.
You encrypt using the public key you received (from the man-in-the-middle); the man-in-the-
middle intercepts and decrypts, reads, and reencrypts, using your friend's public key; and your
friend receives. In this way, the man-in-the-middle reads the messages and neither you nor your
friend is aware of the interception. A slight variation of this attack works for secret key
distribution under a public key.

Message Confidentiality Threats

An attacker can easily violate message confidentiality (and perhaps integrity) because of the
public nature of networks. Eavesdropping and impersonation attacks can lead to a
confidentiality or integrity failure. Here we consider several other vulnerabilities that can affect
confidentiality.
Misdelivery

Sometimes messages are misdelivered because of some flaw in the network hardware or
software. Most frequently, messages are lost entirely, which is an integrity or availability issue.
Occasionally, however, a destination address is modified or some handler malfunctions,
causing a message to be delivered to someone other than the intended recipient. All of these
"random" events are quite uncommon.

More frequent than network flaws are human errors. It is far too easy to mistype an address
such as 100064,30652 as 10064,30652 or 100065,30642, or to type "idw" or "iw" instead of
"diw" for David Ian Walker, who is called Ian by his friends. There is simply no justification
for a computer network administrator to identify people by meaningless long numbers or
cryptic initials when "iwalker" would be far less prone to human error.

Exposure

To protect the confidentiality of a message, we must track it all the way from its creation to its
disposal. Along the way, the content of a message may be exposed in temporary buffers; at
switches, routers, gateways, and intermediate hosts throughout the network; and in the
workspaces of processes that build, format, and present the message. In earlier chapters, we
considered confidentiality exposures in programs and operating systems. All of these exposures
apply to networked environments as well. Furthermore, a malicious attacker can use any of
these exposures as part of a general or focused attack on message confidentiality.

Passive wiretapping is one source of message exposure. So also is subversion of the structure
by which a communication is routed to its destination. Finally, intercepting the message at its
source, destination, or at any intermediate node can lead to its exposure.
Traffic Flow Analysis

Sometimes not only is the message itself sensitive but the fact that a message exists is also
sensitive. For example, if the enemy during wartime sees a large amount of network traffic
between headquarters and a particular unit, the enemy may be able to infer that significant
action is being planned involving that unit. In a commercial setting, messages sent from the
president of one company to the president of a competitor could lead to speculation about a
takeover or conspiracy to fix prices. Or communications from the prime minister of one country
to another with whom diplomatic relations were suspended could lead to inferences about a
rapprochement between the countries. In these cases, we need to protect both the content of
messages and the header information that identifies sender and receiver.

Message Integrity Threats

In many cases, the integrity or correctness of a communication is at least as important as its

confidentiality. In fact for some situations, such as passing authentication data, the integrity of
the communication is paramount. In other cases, the need for integrity is less obvious. Next we
consider threats based on failures of integrity in communication.

Falsification of Messages

Increasingly, people depend on electronic messages to justify and direct actions. For example,
if you receive a message from a good friend asking you to meet at the pub for a drink next
Tuesday evening, you will probably be there at the appointed time. Likewise, you will comply
with a message from your supervisor telling you to stop work on project A and devote your
energy instead to project B. As long as it is reasonable, we tend to act on an electronic message
just as we would on a signed letter, a telephone call, or a face-to-face communication. However,
an attacker can take advantage of our trust in messages to mislead us. In particular, an attacker
may

a) change some or all of the content of a message

b) replace a message entirely, including the date, time, and sender/receiver identification
c) reuse (replay) an old message
d) combine pieces of different messages into one
e) change the apparent source of a message
f) redirect a message
g) destroy or delete a message

These attacks can be perpetrated in the ways we have already examined, including

a) active wiretap
b) Trojan horse
c) impersonation
d) preempted host
e) preempted workstation
Noise

Format Failures

Network communications work because of well-designed protocols that define how two
computers communicate with a minimum of human intervention. The format of a message, size
of a data unit, sequence of interactions, even the meaning of a single bit is precisely described
in a standard. The whole network works only because everyone obeys these rules.

Almost everyone, that is. Attackers purposely break the rules to see what will happen. Or the
attacker may seek to exploit an undefined condition in the standard. Software may detect the
violation of structure and raise an error indicator. Sometimes, however, the malformation
causes a software failure, which can lead to a security compromise, just what the attacker wants.
In this section we look at several kinds of malformation.

Malformed Packets

Packets and other data items have specific formats, depending on their use. Field sizes, bits to
signal continuations, and other flags have defined meanings and will be processed
appropriately by network service applications called protocol handlers. These services do not
necessarily check for errors, however. What happens if a packet indicates a data field is 40
characters long and the actual field length is 30 or 50? Or what if a packet reports its content is
continued in the next packet and there is no next packet? Or suppose for a 2-bit flag only values
00, 01, and 10 are defined; what does the handler do if it receives the value 11? For example,
in 2003 Microsoft distributed a patch for its RPC (Remote Procedure Call) service. If a
malicious user initiated an RPC session and then sent an incorrectly formatted packet, the entire
RPC service failed, as well as some other Microsoft services.

Attackers try all sorts of malformations of packets. Of course, many times the protocol handler
detects the malformation and raises an error condition, and other times the failure affects only
the user (the attacker). But when the error causes the protocol handler to fail, the result can be
denial of service, complete failure of the system, or some other serious result.

Protocol Failures and Implementation Flaws

Each protocol is a specification of a service to be provided; the service is then implemented in

software, which, as discussed in Chapter 3, may be flawed. Network protocol software is basic
to the operating system, so flaws in that software can cause widespread harm because of the
privileges with which the software runs and the impact of the software on many users at once.
Certain network protocol implementations have been the source of many security flaws;
especially troublesome have been SNMP (network management), DNS (addressing service),
and e-mail services such as SMTP and S/MIME. Although different vendors have implemented
the code for these services themselves, they often are based on a common (flawed) prototype.
For example, the CERT advisory for SNMP flaws (Vulnerability Note 107186) lists
approximately 200 different implementations to which the advisory applies. Or the protocol
itself may be incomplete. If the protocol does not specify what action to take in a particular
situation, vendors may produce different results. So an interaction on Windows, for example,
might succeed while the same interaction on a Unix system would fail.

The protocol may have an unknown security flaw. In a classic example,

Bellovin [BEL89] points out a weakness in the way packet sequence numbers are assignedan
attacker could intrude into a communication in such a way that the intrusion is accepted as the
real communication and the real sender is rejected.

Attackers can exploit all of these kinds of errors.

Web Site Vulnerabilities

A web site is especially vulnerable because it is almost completely exposed to the user. If you
use an application program, you do not usually get to view the program's code. With a web
site, the attacker can download the site's code for offline study over time. With a program, you
have little ability to control in what order you access parts of the program, but a web attacker
gets to control in what order pages are accessed, perhaps even accessing page 5 without first
having run pages 1 through 4. The attacker can also choose what data to supply and can run
experiments with different data values to see how the site will react. In short, the attacker has
some advantages that can be challenging to control.

The list of web site vulnerabilities is too long to explore completely here. Hoglund and
McGraw [HOG04], Andrews and Whitaker [AND06], and Howard et al. [HOW05] offer
excellent analyses of how to find and fix flaws in web software. Be sure to review the
code development issues in Chapter 3, because many code techniques there (such as buffer
overflows and insufficient parameter checking) are applicable here.

Web Site Defacement

One of the most widely known attacks is the web site defacement attack. Because of the large
number of sites that have been defaced and the visibility of the result, the attacks are often
reported in the popular press. A defacement is common not only because of its visibility but
also because of the ease with which one can be done. Web sites are designed so that their code
is downloaded, enabling an attacker to obtain the full hypertext document and all programs
directed to the client in the loading process. An attacker can even view programmers' comments
left in as they built or maintained the code. The download process essentially gives the attacker
the blueprints to the web site.

The ease and appeal of a defacement are enhanced by the seeming plethora of vulnerabilities
that web sites offer an attacker. For example, between December 1999 and June 2001 (the first
18 months after its release), Microsoft provided 17 security patches for its web server software,
Internet Information Server (IIS) version 4.0. And version 4.0 was an upgrade for three
previous versions, so theoretically Microsoft had a great deal of time earlier to work out its
security flaws.

Buffer Overflows

Buffer overflow is alive and well on web pages, too. It works exactly the same as described
in Chapter 3: The attacker simply feeds a program far more data than it expects to receive. A
buffer size is exceeded, and the excess data spill over into adjoining code and data locations.
Perhaps the best-known web server buffer overflow is the file name problem known as iishack.
This attack is so well known that is has been written into a procedure
(see [Link] To execute the procedure, an attacker supplies as
parameters the site to be attacked and the URL of a program the attacker wants that server to
execute. Other web servers are vulnerable to extremely long parameter fields, such as
passwords of length 10,000 or a long URL padded with space or null characters.

Dot-Dot-Slash

Web server code should always run in a constrained environment. Ideally, the web server
should never have editors, xterm and Telnet programs, or even most system utilities loaded.
By constraining the environment in this way, even if an attacker escapes from the web server
application, no other executable programs will help the attacker use the web server's computer
and operating system to extend the attack. The code and data for web applications can be
transferred manually to a web server or pushed as a raw image.
But many web applications programmers are naïve. They expect to need to edit a web
application in place, so they install editors and system utilities on the server to give them a
complete environment in which to program. A second, less desirable, condition for preventing
an attack is to create a fence confining the web server application. With such a fence, the server
application cannot escape from its area and access other potentially dangerous system areas
(such as editors and utilities). The server begins in a particular directory subtree, and everything
the server needs is in that same subtree.

Enter the dot-dot. In both Unix and Windows, '..' is the directory indicator for "predecessor."
And '../..' is the grandparent of the current location. So someone who can enter file names can
travel back up the directory tree one .. at a time. Cerberus Information Security analysts found
just that vulnerability in the [Link] extension for the Microsoft Index Server. For example,
passing the following URL causes the server to return the requested file, [Link], enabling
an attacker to modify or delete it.

[Link]

../../../../../winnt/system32/[Link]

Application Code Errors

A user's browser carries on an intricate, undocumented protocol interchange with applications

on the web server. To make its job easier, the web server passes context strings to the user,
making the user's browser reply with full context. A problem arises when the user can modify
that context.

To see why, consider our fictitious shopping site called CDs-R-Us, selling compact discs. At
any given time, a server at that site may have a thousand or more transactions in various states
of completion. The site displays a page of goods to order, the user selects one, the site displays
more items, the user selects another, the site displays more items, the user selects two more,
and so on until the user is finished selecting. Many people go on to complete the order by
specifying payment and shipping information. But other people use web sites like this one as
an online catalog or guide, with no real intention of ordering. For instance, they can use this
site to find out the price of the latest CD from Cherish the Ladies; they can use an online book
service to determine how many books by Iris Murdoch are in print. And even if the user is a
bona fide customer, sometimes web connections fail, leaving the transaction incomplete. For
these reasons, the web server often keeps track of the status of an incomplete order in parameter
fields appended to the URL. These fields travel from the server to the browser and back to the
server with each user selection or page request.

Assume you have selected one CD and are looking at a second web page. The web server has
passed you a URL similar to

[Link]

This URL means you have chosen CD number 459012, and its price is $15.99. You now select
a second and the URL becomes

[Link] [Link]?i1=459012&p1=1599&i2=365217&p2=1499

But if you are a clever attacker, you realize that you can edit the URL in the address window
of your browser. Consequently, you change each of 1599 and 1499 to 199. And when the server
totals up your order, lo and behold, your two CDs cost only $1.99 [Link] failure is an
example of the time -of- check to time-of-use flaw that we discussed in Chapter 3. The server
sets (checks) the price of the item when you first display the price, but then it loses control of
the checked data item and never checks it again. This situation arises frequently in server
application code because application programmers are generally not aware of security (they
haven't read Chapter 3!) and typically do not anticipate malicious behavior.

Server-Side Include

A potentially more serious problem is called a server-side include. The problem takes
advantage of the fact that web pages can be organized to invoke a particular function
automatically. For example, many pages use web commands to send an e-mail message in the
"contact us" part of the displayed page. The commands, such as e-mail, if, goto, and include,
are placed in a field that is interpreted in HTML.

One of the server-side include commands is exec, to execute an arbitrary file on the server.
For instance, the server-side include command

<!#exec cmd="/usr/bin/telnet &">

opens a Telnet session from the server running in the name of (that is, with the privileges of)
the server. An attacker may find it interesting to execute commands such as chmod (change
access rights to an object), sh (establish a command shell), or cat (copy to a file).

Denial of Service

So far, we have discussed attacks that lead to failures of confidentiality or integrityproblems

we have also seen in the contexts of operating systems, databases, and applications.
Availability attacks, sometimes called denial-of-service or DOS attacks, are much more
significant in networks than in other contexts. There are many accidental and malicious threats
to availability or continued service.

Transmission Failure

Communications fail for many reasons. For instance, a line is cut. Or network noise makes a
packet unrecognizable or undeliverable. A machine along the transmission path fails for
hardware or software reasons. A device is removed from service for repair or testing. A device
is saturated and rejects incoming data until it can clear its overload. Many of these problems
are temporary or automatically fixed (circumvented) in major networks, including the Internet.

However, some failures cannot be easily repaired. A break in the single communications line
to your computer (for example, from the network to your network interface card or the
telephone line to your modem) can be fixed only by establishment of an alternative link or
repair of the damaged one. The network administrator will say "service to the rest of the
network was unaffected," but that is of little consolation to you.

From a malicious standpoint, you can see that anyone who can sever, interrupt, or overload
capacity to you can deny you service. The physical threats are pretty obvious. We consider
instead several electronic attacks that can cause a denial of service.
Connection Flooding

The most primitive denial-of-service attack is flooding a connection. If an attacker sends you
as much data as your communications system can handle, you are prevented from receiving
any other data. Even if an occasional packet reaches you from someone else, communication
to you will be seriously degraded.
More sophisticated attacks use elements of Internet protocols. In addition to TCP and UDP,
there is a third class of protocols, called ICMP or Internet Control Message Protocols.
Normally used for system diagnostics, these protocols do not have associated user applications.
ICMP protocols include

a) ping, which requests a destination to return a reply, intended to show that the
destination system is reachable and functioning
b) echo, which requests a destination to return the data sent to it, intended to show that
the connection link is reliable (ping is actually a version of echo)
c) destination unreachable, which indicates that a destination address cannot be
accessed
d) source quench, which means that the destination is becoming saturated and the
source should suspend sending packets for a while

These protocols have important uses for network management. But they can also be used to
attack a system. The protocols are handled within the network stack, so the attacks may be
difficult to detect or block on the receiving host. We examine how these protocols can be used
to attack a victim.

Echo-Chargen

This attack works between two hosts. Chargen is a protocol that generates a stream of packets;
it is used to test the network's capacity. The attacker sets up a chargen process on host A that
generates its packets as echo packets with a destination of host B. Then, host A produces a
stream of packets to which host B replies by echoing them back to host A. This series puts the
network infrastructures of A and B into an endless loop. If the attacker makes B both the source
and destination address of the first packet, B hangs in a loop, constantly creating and replying
to its own messages.

Ping of Death

A ping of death is a simple attack. Since ping requires the recipient to respond to the ping
request, all the attacker needs to do is send a flood of pings to the intended victim. The attack
is limited by the smallest bandwidth on the attack route. If the attacker is on a 10-megabyte
(MB) connection and the path to the victim is 100 MB or more, the attacker cannot
mathematically flood the victim alone. But the attack succeeds if the numbers are reversed:
The attacker on a 100-MB connection can easily flood a 10-MB victim. The ping packets will
saturate the victim's bandwidth.

Smurf

The smurf attack is a variation of a ping attack. It uses the same vehicle, a ping packet, with
two extra twists. First, the attacker chooses a network of unwitting victims. The attacker spoofs
the source address in the ping packet so that it appears to come from the victim. Then, the
attacker sends this request to the network in broadcast mode by setting the last byte of the
address to all 1s; broadcast mode packets are distributed to all hosts on the network. The attack
is shown in Figure 7-16.

Syn Flood

Another popular denial-of-service attack is the syn flood. This attack uses the TCP protocol
suite, making the session-oriented nature of these protocols work against the victim.

For a protocol such as Telnet, the protocol peers establish a virtual connection, called a session,
to synchronize the back-and -forth, command-response nature of the Telnet terminal emulation.
A session is established with a three-way TCP handshake. Each TCP packet has flag bits, two
of which are denoted SYN and ACK. To initiate a TCP connection, the originator sends a
packet with the SYN bit on. If the recipient is ready to establish a connection, it replies with a
packet with both the SYN and ACK bits on. The first party then completes the exchange to
demonstrate a clear and complete communication channel by sending a packet with the ACK
bit on, as shown in Figure 7-17.
Occasionally packets get lost or damaged in transmission. The destination maintains a queue
called the SYN_RECV connections, tracking those items for which a SYNACK has been sent
but no corresponding ACK has yet been received. Normally, these connections are completed
in a short time. If the SYNACK (2) or the ACK (3) packet is lost, eventually the destination
host will time out the incomplete connection and discard it from its waiting queue.

The attacker can deny service to the target by sending many SYN requests and never
responding with ACKs, thereby filling the victim's SYN_RECV queue. Typically, the
SYN_RECV queue is quite small, such as 10 or 20 entries. Because of potential routing delays
in the Internet, typical holding times for the SYN_RECV queue can be minutes. So the attacker
need only send a new SYN request every few seconds and it will fill the queue.

Attackers using this approach usually do one more thing: They spoof the nonexistent return
address in the initial SYN packet. Why? For two reasons. First, the attacker does not want to
disclose the real source address in case someone should inspect the packets in the SYN_RECV
queue to try to identify the attacker. Second, the attacker wants to make the SYN packets
indistinguishable from legitimate SYN packets to establish real connections. Choosing a
different (spoofed) source address for each one makes them unique. A SYNACK packet to a
nonexistent address results in an ICMP Destination Unreachable response, but this is not the
ACK for which the TCP connection is waiting. (Remember that TCP and ICMP are different
protocol suites, so an ICMP reply does not necessarily get back to the sender's TCP handler.)

Teardrop

The teardrop attack misuses a feature designed to improve network communication. A network
IP datagram is a variable-length object. To support different applications and conditions, the
datagram protocol permits a single data unit to be fragmented, that is, broken into pieces and
transmitted separately. Each fragment indicates its length and relative position within the data
unit. The receiving end is responsible for reassembling the fragments into a single data unit.

In the teardrop attack, the attacker sends a series of datagrams that cannot fit together properly.
One datagram might say it is position 0 for length 60 bytes, another position 30 for 90 bytes,
and another position 41 for 173 bytes. These three pieces overlap, so they cannot be
reassembled properly. In an extreme case, the operating system locks up with these partial data
units it cannot reassemble, thus leading to denial of service.

For more on these and other denial of service threats, see [CER99 and MAR05].

Traffic Redirection

As we saw earlier, at the network layer, a router is a device that forwards traffic on its way
through intermediate networks between a source host's network and a destination's network.
So if an attacker can corrupt the routing, traffic can disappear. Routers use complex algorithms
to decide how to route traffic. No matter the algorithm, they essentially seek the best path
(where "best" is measured in some combination of distance, time, cost, quality, and the like).
Routers are aware only of the routers with which they share a direct network connection, and
they use gateway protocols to share information about their capabilities. Each router advises
its neighbors about how well it can reach other network addresses. This characteristic allows
an attacker to disrupt the network.

To see how, keep in mind that, in spite of its sophistication, a router is simply a computer with
two or more network interfaces. Suppose a router advertises to its neighbors that it has the best
path to every other address in the whole network. Soon all routers will direct all traffic to that
one router. The one router may become flooded, or it may simply drop much of its traffic. In
either case, a lot of traffic never makes it to the intended destination.
DNS Attacks

Our final denial-of-service attack is actually a class of attacks based on the concept of domain
name server. A domain name server (DNS) is a table that converts domain names like
[Link] into network addresses like [Link]; this process is called resolving the
domain name. A domain name server queries other name servers to resolve domain names it
does not know. For efficiency, it caches the answers it receives so it can resolve that name more
rapidly in the future. A pointer to a DNS server can be retained for weeks or months. In the
most common implementations of Unix, name servers run software called Berkeley Internet
Name Domain or BIND or named (a shorthand for "name daemon"). There have been
numerous flaws in BIND, including the now-familiar buffer overflow.

By overtaking a name server or causing it to cache spurious entries (called DNS cache
poisoning), an attacker can redirect the routing of any traffic, with an obvious implication for
denial of service. In October 2002, a massive flood of traffic inundated the top -level domain
DNS servers, the servers that form the foundation of the Internet addressing structure. Roughly
half the traffic came from just 200 addresses. Although some people think the problem was a
set of misconfigured firewalls, nobody knows for sure what caused the attack. An attack in
March 2005 used a flaw in a Symantec firewall to allow a change in the DNS records used on
Windows machines. The objective of this attack was not denial of service, however. In this
attack, the poisoned DNS cache redirected users to advertising sites that received money from
clients each time a user visited the site. Nevertheless, the attack also prevented users from
accessing the legitimate sites.

Signals sent over communications media are subject to interference from other traffic on the
same media, as well as from natural sources, such as lightning, electric motors, and animals.
Such unintentional interference is called noise. These forms of noise are inevitable, and they
can threaten the integrity of data in a message.

Fortunately, communications protocols have been intentionally designed to overcome the

negative effects of noise. For example, the TCP/IP protocol suite ensures detection of almost
all transmission errors. Processes in the communications stack detect errors and arrange for
retransmission, all invisible to the higher-level applications. Thus, noise is scarcely a
consideration for users in security-critical applications.
Distributed Denial of Service

The denial-of -service attacks we have listed are powerful by themselves, and Sidebar 7-
7 shows us that many are launched. But an attacker can construct a two-stage attack that
multiplies the effect many times. This multiplicative effect gives power to distributed denial of
service.

To perpetrate a distributed denial-of-service (or DDoS) attack, an attacker does two things,
as illustrated in Figure 7 -18. In the first stage, the attacker uses any convenient attack (such as
exploiting a buffer overflow or tricking the victim to open and install unknown code from an
e-mail attachment) to plant a Trojan horse on a target machine. That Trojan horse does not
necessarily cause any harm to the target machine, so it may not be noticed. The Trojan horse
file may be named for a popular editor or utility, bound to a standard operating system service,
or entered into the list of processes (daemons) activated at startup. No matter how it is situated
within the system, it will probably not attract any attention.
The attacker repeats this process with many targets. Each of these target systems then becomes
what is known as a zombie. The target systems carry out their normal work, unaware of the
resident zombie.

WHAT IS THE PURPOSE OF CYBERSECURITY ARCHITECTURE?

Every successful organization relies on the strength of its organizational structure. A detailed
business plan, efficient employees, and the business experience of key personnel are all critical.
A formidable team is built from the consistency and commitment of all of the above, and
implementing a strong cybersecurity architecture is no exception.

This is how important it is to have your organization’s cybersecurity architecture airtight in

order to protect your organization against external threats. Cyber-threats and cybersecurity
breaches come in various forms and continually evolve. Hence, it is pertinent that an
organization like yours is highly security alert and familiar with measures and strategies to
militate against possible threats.
Without strong security, your organization is vulnerable to a number of threats. Read on to
learn about the purpose of cybersecurity architecture.

What is Cybersecurity Architecture?

Cybersecurity architecture, also known as “network security architecture”, is a framework that

specifies the organizational structure, standards, policies and functional behavior of a computer
network, including both security and network features. Cybersecurity architecture is also the
manner in which various components of your cyber or computer system are organized, synced
and integrated.A cybersecurity architecture framework is one component of a system’s overall
architecture. It’s designed and built to provide guidance during the design of an entire
product/system. Security architecture helps to position security controls and breach
countermeasures and how they relate to the overall systems framework of your company. The
main purpose of these controls is to maintain your critical system’s quality attributes such as
confidentiality, integrity and availability. It’s also the synergy between hardware and software
knowledge with programming proficiency, research skills and policy development.

A security architect is an individual who anticipates potential cyber-threats and is quick to

design structures and systems to preempt them. Most organizations are exposed
to cybersecurity threats but a cybersecurity architecture plan helps you to implement and
monitor your company’s network security systems. A cybersecurity architecture framework
positions all your security controls against any form of malicious actors and how they relate to
your overall systems architecture.
Various elements of cybersecurity strategies like firewalls, antivirus programs and intrusion
detection systems play a huge role in protecting your organization against external threats. To
maintain and maximize these security tools as well as already existing and functional policies
and procedures, your company should implement a detailed security architecture that integrates
these different elements for your networks.
This framework unifies various methods, processes and tools in order to protect an
organization’s resources, data and other vital information. The success of a cybersecurity
architecture relies heavily on the continuous flow of information throughout the entire
organization. Everyone must work according to the framework and processes of your
company’s security architecture.

Security Architecture Components

According to Internal Auditors, effective and efficient cybersecurity architecture consists of

three major components. Those are people, processes and tools that work together to protect
your company’s assets. To align these components effectively, your security architecture needs
to be driven by your security policy. stating your security architecture expectation,
implementation plan, and enforcement process.
A security policy is a statement that outlines how each entity accesses each other, what
operations various entities can carry out, the level of protection that is required for a system as
well as actions that should be taken when these security requirements are not met. The
components listed below are part of an effective and carefully planned security architecture:
Direction in the area of incident response to threats, disaster recovery, systems configuration,
account creation and management, and cybersecurity monitoring.

1) Identity management.
2) Decided inclusion and exclusion of those subject to the domain of the security
architecture.
3) Access and border control.
4) Validation and adjustment of the architecture.
5) Training.
 Features of Cybersecurity Architecture
The following are some of the features of cybersecurity architecture:

▪ Network Elements
1) Network nodes like computers, NICs, repeaters, hubs, bridges, switches, routers,
modems, gateways.

2) Network communication protocols (TCP/IP, DHCP, DNS, FTP, HTTP, HTTPS,

IMAP)

3) Network connections between nodes using specific protocols

4) Network topologies among nodes such as point-to-point, circular, chain, and hybrid

▪ Security Elements
1) Cybersecurity devices like firewalls, Intrusion Detection/Protection Systems
[IDS/IPS], encryption/decryption devices.
2) Cybersecurity software (anti-virus software, spyware software, anti-malware software)

3) Secure network communication protocols (TCP/IP, DHCP, DNS, FTP, HTTP, HTTPS,
IMAP).

4) Strong encryption techniques like end-to-end encryption, zero-knowledge privacy,

blockchain.

▪ Security Frameworks & Standards

1) Cybersecurity framework architecture standards like NIST Risk Management
Framework (RMF) SP 800-37 and ISO IEC 27000-Series.

2) Technology standards for cybersecurity software choices.

Security Procedures & Policies

These are security procedures and policies directed towards your organization and enforced.
According to Cybersecurity Forum, a cybersecurity architecture should ideally be definable
and simulatable using an industry-standard architecture modeling language (e.g., SysML,
UML2).
Key Phases in Security Architecture
These are the key phases in the security architecture framework and process:

1) Architecture Risk Assessment: Here, you evaluate the influence of vital business
assets, the risks, and the effects of vulnerabilities and security threats to your
[Link] Architecture and Design: At this phase, the design and
architecture of security services are structured to aid the protection of your
organization’s assets in order to facilitate business risk exposure objectives and goals.
2) Implementation: Cybersecurity services and processes are operated, implemented,
monitored and controlled. The architecture is designed to ensure that the security policy
and standards, security architecture decisions, and risk management are fully
implemented and effective for a long period.
3) Operations and Monitoring: Here, measures like threat and vulnerability
management and threat management are taken to monitor, supervise and handle the
operational state in addition to examining the impact of the system’s security.

Purpose of Cybersecurity Architecture

The purpose of cybersecurity architecture is simply to ensure that the main network
architecture of your company including sensitive data and critical applications are fully
protected against any present or future threats and breaches. It’s important you fully understand
the various weak points in your system in order to effectively and quickly proffer a solution.
The best way to identify your system’s weak point is to employ the services of a cybersecurity
architect. A cybersecurity architect will thoroughly evaluate surface vulnerabilities for
different network topologies and cyber-attacks to effectively defend your sensitive data and
critical applications.
The primary goals of effective cybersecurity architecture are:

1) To ensure that all cyber-attacks are minimized, mitigated against, hidden or dynamic.
2) To ensure that cyber-attack surfaces should be relatively small in size, covertly stored,
so that they are stealth in moving towards threat targets and difficult for cyber threats to
detect and penetrate.
3) To make sure all your confidential and sensitive data is strongly encrypted, and be
subject to end-to-end encryption techniques during transfer.
 4) All cyber-attacks are aggressively detected, mitigated, and countered using
countermeasures like Moving-Target Defenses (MTD).
Closing Thoughts

Cybersecurity architects are particularly skilled in identifying potential threats. They

understand computer and network systems enough to design security architecture plans,
implement these plans, and supervise the proper implementation.

RSI Security can help your organization by providing your IT department with qualified
security experts to handle your next cloud architecture implementation. Our cybersecurity
team can set up a secure network with the most up-to-date best practices. as well as support
your organization in any technology it uses.
No matter how complex your IT environment is, we provide support for your organization in
any technology that it uses and to professionally handle your cloud architecture
implementation. Send a message now to reach our team of experienced cybersecurity
architects.
Content Integrity - Security in Networks

Content Integrity

Content integrity comes as a bonus with cryptography. No one can change encrypted data in a
meaningful way without breaking the encryption. This does not say, however, that encrypted
data cannot be modified. Changing even one bit of an encrypted data stream affects the result
after decryption, often in a way that seriously alters the resulting plaintext. We need to consider
three potential threats:

1) malicious modification that changes content in a meaningful way

2) malicious or nonmalicious modification that changes content in a way that is not
necessarily meaningful
3) nonmalicious modification that changes content in a way that will not be detected

Encryption addresses the first of these threats very effectively. To address the others, we can
use other controls.

Error Correcting Codes

We can use error detection and error correction codes to guard against modification in a
transmission. The codes work as their names imply: Error detection codes detect when an error
has occurred, and error correction codes can actually correct errors without requiring
retransmission of the original message. The error code is transmitted along with the original
data, so the recipient can recompute the error code and check whether the received result
matches the expected value.

The simplest error detection code is a parity check. An extra bit is added to an existing group
of data bits depending on their sum or an exclusive OR. The two kinds of parity are called even
and odd. With even parity the extra bit is 0 if the sum of the data bits is even and 1 if the sum
is odd; that is, the parity bit is set so that the sum of all data bits plus the parity bit is even. Odd
parity is the same except the sum is odd. For example, the data stream 01101101 would have
an even parity bit of 1 (and an odd parity bit of 0) because 0+1+1+0+1+1+0+1 = 5 + 1 = 6 (or
5 + 0 = 5 for odd parity). A parity bit can reveal the modification of a single bit. However,
parity does not detect two -bit errorscases in which two bits in a group are changed. That is,
the use of a parity bit relies on the assumption that single-bit errors will occur infrequently, so
it is very unlikely that two bits would be changed. Parity signals only that a bit has been
changed; it does not identify which bit has been changed.

There are other kinds of error detection codes, such as hash codes and Huffman codes. Some
of the more complex codes can detect multiple-bit errors (two or more bits changed in a data
group) and may be able to pinpoint which bits have been [Link] and simple error
detection and correction codes are used to detect nonmalicious changes in situations in which
there may be faulty transmission equipment, communications noise and interference, or other
sources of spurious changes to data.

Cryptographic Checksum

Malicious modification must be handled in a way that prevents the attacker from modifying
the error detection mechanism as well as the data bits themselves. One way to do this is to use
a technique that shrinks and transforms the data, according to the value of the data bits.
To see how such an approach might work, consider an error detection code as a many-to-one
transformation. That is, any error detection code reduces a block of data to a smaller digest
whose value depends on each bit in the block. The proportion of reduction (that is, the ratio of
original size of the block to transformed size) relates to the code's effectiveness in detecting
errors. If a code reduces an 8-bit data block

to a 1-bit result, then half of the 28 input values map to 0 and half to 1, assuming a uniform
distribution of outputs. In other words, there are 28/2 = 27 = 128 different bit patterns that all
produce the same 1-bit result. The fewer inputs that map to a particular output, the fewer ways
the attacker can change an input value without affecting its output. Thus, a 1-bit result is too
weak for many applications. If the output is three bits instead of one, then each output result
comes from 28/23 or 25 = 32 inputs. The smaller number of inputs to a given output is important
for blocking malicious modification.

A cryptographic checksum (sometimes called a message digest) is a cryptographic function

that produces a checksum. The cryptography prevents the attacker from changing the data
block (the plaintext) and also changing the checksum value (the ciphertext) to match. Two
major uses of cryptographic checksums are code tamper protection and message integrity
protection in transit. For code protection, a system administrator computes the checksum of
each program file on a system and then later computes new checksums and compares the
values. Because executable code usually does not change, the administrator can detect
unanticipated changes from, for example, malicious code attacks. Similarly, a checksum on
data in communication identifies data that have been changed in transmission, maliciously or
accidentally.

Strong Authentication and Kerberos - Security in Networks

Strong Authentication

As we have seen in earlier chapters, operating systems and database management systems
enforce a security policy that specifies whowhich individuals, groups, subjectscan access which
resources and objects. Central to that policy is authentication: knowing and being assured of
the accuracy of identities.

Networked environments need authentication, too. In the network case, however,

authentication may be more difficult to achieve securely because of the possibility of
eavesdropping and wiretapping, which are less common in nonnetworked environments. Also,
both ends of a communication may need to be authenticated to each other: Before you send
your password across a network, you want to know that you are really communicating with the
remote host you expect. Lampson [LAM00] presents the problem of authentication in
autonomous, distributed systems; the real problem, he points out, is how to develop trust of
network entities with which you have no basis for a relationship. Let us look more closely at
authentication methods appropriate for use in networks.

One-Time Password

The wiretap threat implies that a password could be intercepted from a user who enters a
password across an unsecured network. A one-time password can guard against wiretapping
and spoofing of a remote host.

As the name implies, a one-time password is good for one use only. To see how it works,
consider the easiest case, in which the user and host both have access to identical lists of
passwords, like the one-time pad for cryptography from Chapter 2. The user would enter the
first password for the first login, the next one for the next login, and so forth. As long as the
password lists remained secret and as long as no one could guess one password from another,
a password obtained through wiretapping would be useless. However, as with the one-time
cryptographic pads, humans have trouble maintaining these password lists.

To address this problem, we can use a password token, a device that generates a password
that is unpredictable but that can be validated on the receiving end. The simplest form of
password token is a synchronous one, such as the SecurID device from RSA Security, Inc. This
device displays a random number, generating a new number every minute. Each user is issued
a different device (that generates a different random number sequence). The user reads the
number from the device's display and types it in as a one-time password. The computer on the
receiving end executes the algorithm to generate the password appropriate for the current
minute; if the user's password matches the one computed remotely, the user is authenticated.
Because the devices may get out of alignment if one clock runs slightly faster than the other,
these devices use fairly natural rules to account for minor drift.

What are the advantages and disadvantages of this approach? First, it is easy to use. It largely
counters the possibility of a wiretapper reusing a password. With a strong password-generating
algorithm, it is immune to spoofing. However, the system fails if the user loses the generating
device or, worse, if the device falls into an attacker's hands. Because a new password is
generated only once a minute, there is a small (one-minute) window of vulnerability during
which an eavesdropper can reuse an intercepted password.

ChallengeResponse Systems

To counter the loss and reuse problems, a more sophisticated one-time password scheme uses
challenge and response, as we first studied in Chapter 4. A challenge and response device looks
like a simple pocket calculator. The user first authenticates to the device, usually by means of
a PIN. The remote system sends a random number, called the "challenge," which the user enters
into the device. The device responds to that number with another number, which the user then
transmits to the system.

The system prompts the user with a new challenge for each use. Thus, this device eliminates
the small window of vulnerability in which a user could reuse a time-sensitive authenticator.
A generator that falls into the wrong hands is useless without the PIN. However, the user must
always have the response generator to log in, and a broken device denies service to the user.
Finally, these devices do not address the possibility of a rogue remote host.

Digital Distributed Authentication

In the 1980s, Digital Equipment Corporation recognized the problem of needing to

authenticate nonhuman entities in a computing system. For example, a process might retrieve
a user query, which it then reformats, perhaps limits, and submits to a database manager. Both
the database manager and the query processor want to be sure that a particular communication
channel is authentic between the two. Neither of these servers is running under the direct
control or supervision of a human (although each process was, of course, somehow initiated
by a human). Human forms of access control are thus inappropriate.

Digital [GAS89, GAS90] created a simple architecture for this requirement, effective against
the following threats:

1) impersonation of a server by a rogue process, for either of the two servers involved in
the authentication
2) interception or modification of data exchanged between servers
3) replay of a previous authentication
The architecture assumes that each server has its own private key and that the corresponding
public key is available to or held by every other process that might need to establish an
authenticated channel. To begin an authenticated communication between server A and server
B, A sends a request to B, encrypted under B's public key. B decrypts the request and replies
with a message encrypted under A's public key. To avoid replay, A and B can append a random
number to the message to be encrypted.

A and B can establish a private channel by one of them choosing an encryption key (for a
secret key algorithm) and sending it to the other in the authenticating message. Once the
authentication is complete, all communication under that secret key can be assumed to be as
secure as was the original dual public key exchange. To protect the privacy of the channel,
Gasser recommends a separate cryptographic processor, such as a smart card, so that private
keys are never exposed outside the processor.

Two implementation difficulties remain to be solved: (a) How can a potentially large number
of public keys be distributed and (b) how can the public keys be distributed in a way that
ensures the secure binding of a process with the key? Digital recognized that a key server
(perhaps with multiple replications) was necessary to distribute keys. The second difficulty is
addressed with certificates and a certification hierarchy, as described in Chapter 2.

Both of these design decisions are to a certain degree implied by the nature of the rest of the
protocol. A different approach was taken by Kerberos, as we see in the following sections.

Kerberos

As we introduced in Chapter 4, Kerberos is a system that supports authentication in distributed

systems. Originally designed to work with secret key encryption, Kerberos, in its latest version,
uses public key technology to support key exchange. The Kerberos system was designed at
Massachusetts Institute of Technology [STE88, KOH93].

Kerberos is used for authentication between intelligent processes, such as client-to-server

tasks, or a user's workstation to other hosts. Kerberos is based on the idea that a central server
provides authenticated tokens, called tickets, to requesting applications. A ticket is an
unforgeable, nonreplayable, authenticated object. That is, it is an encrypted data structure
naming a user and a service that user is allowed to obtain. It also contains a time value and
some control information.
The first step in using Kerberos is to establish a session with the Kerberos server, as shown
in Figure 7-29. A user's workstation sends the user's identity to the Kerberos server when a user
logs in. The Kerberos server verifies that the user is authorized. The Kerberos server sends two
messages:

1) to the user's workstation, a session key S G for use in communication with the ticket-
granting server (G) and a ticket TG for the ticket-granting server; SG is encrypted under
the user's password: E(SG + TG, pw)
2) to the ticket-granting server, a copy of the session key S G and the identity of the user
(encrypted under a key shared between the Kerberos server and the ticket-granting
server)

If the workstation can decrypt E(SG + TG, pw) by using pw, the password typed by the user,
then the user has succeeded in an authentication with the workstation. Notice that passwords
are stored at the Kerberos server, not at the workstation, and that the user's password did not
have to be passed across the network, even in encrypted form. Holding passwords centrally but
not passing them across the network is a security advantage.

Next, the user will want to exercise some other services of the distributed system, such as
accessing a file. Using the key SG provided by the Kerberos server, the user U requests a ticket
to access file F from the ticket-granting server. As shown in Figure 7-30, after the ticket-
granting server verifies U's access permission, it returns a ticket and a session key. The ticket
contains U's authenticated identity (in the ticket U obtained from the Kerberos server), an
identification of F (the file to be accessed), the access rights (for example, to read), a session
key SF for the file server to use while communicating this file to U, and an expiration date for
the ticket.

The ticket is encrypted under a key shared exclusively between the ticket-granting server and
the file server. This ticket cannot be read, modified, or forged by the user U (or anyone else).
The ticket-granting server must, therefore, also provide U with a copy of S F, the session key
for the file server.

Requests for access to other services and servers are handled similarly.

Kerberos was carefully designed to withstand attacks in distributed environments:

1) No passwords communicated on the network. As already described, a user's password

is stored only at the Kerberos server. The user's password is not sent from the user's
workstation when the user initiates a session. (Obviously, a user's initial password must
be sent outside the network, such as in a letter.)
2) Cryptographic protection against spoofing. Each access request is mediated by the
ticket-granting server, which knows the identity of the requester, based on the
authentication performed initially by the Kerberos server and on the fact that the user
was able to present a request encrypted under a key that had been encrypted under the
user's password.
 3) Limited period of validity. Each ticket is issued for a limited time period; the ticket
contains a timestamp with which a receiving server will determine the ticket's validity.
In this way, certain long-term attacks, such as brute force cryptanalysis, will usually be
neutralized because the attacker will not have time to complete the attack.
4) Timestamps to prevent replay attacks. Kerberos requires reliable access to a universal
clock. Each user's request to a server is stamped with the time of the request. A server
receiving a request compares this time to the current time and fulfills the request only
if the time is reasonably close to the current time. This time-checking prevents most
replay attacks, since the attacker's presentation of the ticket will be delayed too long.
5) Mutual authentication. The user of a service can be assured of any server's authenticity
by requesting an authenticating response from the server. The user sends a ticket to a
server and then sends the server a request encrypted under the session key for that
server's service; the ticket and the session key were provided by the ticket-granting
server. The server can decrypt the ticket only if it has the unique key it shares with the
ticket-granting server. Inside the ticket is the session key, which is the only means the
server has of decrypting the user's request. If the server can return to the user a message
encrypted under this same session key but containing 1 + the user's timestamp, the
server must be authentic. Because of this mutual authentication, a server can provide a
unique channel to a user and the user may not need to encrypt communications on that
channel to ensure continuous authenticity. Avoiding encryption saves time in the
communication.

Kerberos is not a perfect answer to security problems in distributed systems.

1) Kerberos requires continuous availability of a trusted ticket-granting server. Because

the ticket-granting server is the basis of access control and authentication, constant
access to that server is crucial. Both reliability (hardware or software failure) and
performance (capacity and speed) problems must be addressed.
2) Authenticity of servers requires a trusted relationship between the ticket-granting server
and every server. The ticket-granting server must share a unique encryption key with
each "trustworthy" server. The ticket-granting server (or that server's human
administrator) must be convinced of the authenticity of that server. In a local
environment, this degree of trust is warranted. In a widely distributed environment, an
 administrator at one site can seldom justify trust in the authenticity of servers at other
sites.
3) Kerberos requires timely transactions. To prevent replay attacks, Kerberos limits the
validity of a ticket. A replay attack could succeed during the period of validity,
however. And setting the period fairly is hard: Too long increases the exposure to replay
attacks, while too short requires prompt user actions and risks providing the user with
a ticket that will not be honored when presented to a server. Similarly, subverting a
server's clock allows reuse of an expired ticket.
4) A subverted workstation can save and later replay user passwords. This vulnerability
exists in any system in which passwords, encryption keys, or other constant, sensitive
information is entered in the clear on a workstation that might be subverted.
5) Password guessing works. A user's initial ticket is returned under the user's password.
An attacker can submit an initial authentication request to the Kerberos server and then
try to decrypt the response by guessing at the password.
6) Kerberos does not scale well. The architectural model of Kerberos, shown in Figure 7-
31, assumes one Kerberos server and one ticket-granting server, plus a collection of
other servers, each of which shares a unique key with the ticket-granting server. Adding
a second ticket-granting server, for example, to enhance performance or reliability,
would require duplicate keys or a second set for all servers. Duplication increases the
risk of exposure and complicates key updates, and second keys more than double the
work for each server to act on a ticket.

Kerberos is a complete solution. All applications must use Kerberos authentication and access
control. Currently, few applications use Kerberos authentication, and so integration of
Kerberos into an existing environment requires modification of existing applications, which is
not feasible.
Access Controls - Security in Networks

Access Controls

Authentication deals with the who of security policy enforcement; access controls enforce the
what and how.

ACLs on Routers

Routers perform the major task of directing network traffic either to subnetworks they control
or to other routers for subsequent delivery to other subnetworks. Routers convert external IP
addresses into internal MAC addresses of hosts on a local [Link] a host is being
spammed (flooded) with packets from a malicious rogue host. Routers can be configured with
access control lists to deny access to particular hosts from particular hosts. So, a router could
delete all packets with a source address of the rogue host and a destination address of the target
host.

This approach has three problems, however. First, routers in large networks perform a lot of
work: They have to handle every packet coming into and going out of the network. Adding
ACLs to the router requires the router to compare every packet against the ACLs. One ACL
adds work, degrading the router's performance;
as more ACLs are added, the router's performance may become unacceptable. The second
problem is also an efficiency issue: Because of the volume of work they perform, routers are
designed to perform only essential services. Logging of activity is usually not done on a router
because of the volume of traffic and the performance penalty logging would entail. With ACLs,
it would be useful to know how many packets were being deleted, to know if a particular ACL
could be removed (thereby improving performance). But without logging it is impossible to
know whether an ACL is being used. These two problems together imply that ACLs on routers
are most effective against specific known threats but that they should not be used
indiscriminately.

The final limitation on placing ACLs on routers concerns the nature of the threat. A router
inspects only source and destination addresses. An attacker usually does not reveal an actual
source address. To reveal the real source address would be equivalent to a bank robber's leaving
his home address and a description of where he plans to store the stolen money.

Because someone can easily forge any source address on a UDP datagram, many attacks use
UDP protocols with false source addresses so that the attack cannot be blocked easily by a
router with an ACL. Router ACLs are useful only if the attacker sends many datagrams with
the same forged source address.

In principle, a router is an excellent point of access control because it handles every packet
coming into and going out of a subnetwork. In specific situations, primarily for internal
subnetworks, ACLs can be used effectively to restrict certain traffic flows, for example, to
ensure that only certain hosts (addresses) have access to an internal network management
subnetwork. But for large-scale, general traffic screening, routers are less useful than firewalls.

Firewalls

A firewall does the screening that is less appropriate for a router to do. A router's primary
function is addressing, whereas a firewall's primary function is filtering. Firewalls can also do
auditing. Even more important, firewalls can examine an entire packet's contents, including the
data portion, whereas a router is concerned only with source and destination MAC and IP
addresses. Because they are an extremely important network security control, we study
firewalls in an entire section later in this chapter.

Wireless Networks Security

Wireless Security
Because wireless computing is so exposed, it requires measures to protect communications
between a computer (called the client) and a wireless base station or access point.
Remembering that all these communications are on predefined radio frequencies, you can
expect an eavesdropping attacker to try to intercept and impersonate. Pieces to protect are
finding the access point, authenticating the remote computer to the access point, and vice versa,
and protecting the communication stream.

SSID

As described earlier in this chapter, the Service Set Identifier or SSID is the identification of
an access point; it is a string of up to 32 characters. Obviously the SSIDs need to be unique in
a given area to distinguish one wireless network from another. The factory-installed default for
early versions of wireless access points was not unique, such as "wireless," "tsunami" or
"Linksys" (a brand name); now most factory defaults are a serial number unique to the device.

A client and an access point engage in a handshake to locate each other: Essentially the client
says, "I am looking to connect to access point S" and the access point says, "I am access point
S; connect to me." The order of these two steps is important. In what is called "open mode," an
access point can continually broadcast its appeal, indicating that it is open for the next step in
establishing a connection. Open mode is a poor security practice because it advertises the name
of an access point to which an attacker might attach. "Closed" or "stealth mode" reverses the
order of the protocol: The client must send a signal seeking an access point with a particular
SSID before the access point responds to that one query with an invitation to connect.

But closed mode does not prevent knowledge of the SSID. The initial exchange "looking for
S," "I am S" occurs in the clear and is available to anyone who uses a sniffer to intercept
wireless communications in range. Thus, anyone who sniffs the SSID can save the SSID (which
is seldom changed in practice) to use later.

WEP

The second step in securing a wireless communication involves use of encryption. The original
802.11 wireless standard relied upon a cryptographic protocol called wired equivalent
privacy or WEP. WEP was meant to provide users privacy equivalent to that of a dedicated
wire, that is, immunity to most eavesdropping and impersonation attacks. WEP uses an
encryption key shared between the client and the access point. To authenticate a user, the access
point sends a random number to the client, which the client encrypts using the shared key and
returns to the access point. From that point on, the client and access point are authenticated and
can communicate using their shared encryption key. Several problems exist with this seemingly
simple approach.

First, the WEP standard uses either a 64- or 128-bit encryption key. The user enters the key in
any convenient form, usually in hexadecimal or as an alphanumeric string that is converted to
a number. Entering 64 or 128 bits in hex requires choosing and then typing 16 or 32 symbols
correctly for the client and access point. Not surprisingly, hex strings like C0DE C0DE… (that
is a zero between C and D) are common. Passphrases are vulnerable to a dictionary attack.

Even if the key is strong, it really has an effective length of only 40 or 104 bits because of the
way it is used in the algorithm. A brute force attack against a 40-bit key succeeds quickly. Even
for the 104-bit version, flaws in the RC4 algorithm and its use (see [BOR01, FLU01 ,
and ARB02 ]) defeat WEP security. Several tools, starting with WEPCrack and AirSnort, allow
an attacker to crack a WEP encryption, usually in a few minutes. At a 2005 conference, the
FBI demonstrated the ease with which a WEP-secured wireless session can be broken.

For these reasons, in 2001 the IEEE began design of a new authentication and encryption
scheme for wireless. Unfortunately, some wireless devices still on the market allow only the
false security of WEP.

WPA and WPA2

The alternative to WEP is WiFi Protected Access or WPA, approved in 2003. The IEEE
standard 802.11i is now known as WPA2, approved in 2004, and is an extension of WPA. How
does WPA improve upon WEP? First, WEP uses an encryption key that is unchanged until the
user enters a new key at the client and access point. Cryptologists hate unchanging encryption
keys because a fixed key gives the attacker a large amount of ciphertext to try to analyze and
plenty of time in which to analyze it. WPA has a key change approach, called Temporal Key
Integrity Program (TKIP), by which the encryption key is changed automatically on each
packet.

Second, WEP uses the encryption key as an authenticator, albeit insecurely. WPA employs
the extensible authentication protocol (EAP) by which authentication can be done by password,
token, certificate, or other mechanism. For small network (home) users, this probably still
means a shared secret, which is not ideal. Users are prone to selecting weak keys, such as short
numbers or pass phrases subject to a dictionary attack.
The encryption algorithm for WEP is RC4, which has cryptographic flaws both in key length
and design [ARB02]. In WEP the initialization vector for RC4 is only 24 bits, a size so small
that collisions commonly occur; furthermore, there is no check against initialization vector
reuse. WPA2 adds AES as a possible encryption algorithm (although RC4 is also still supported
for compatibility reasons).

WEP includes a 32-bit integrity check separate from the data portion. But because the WEP
encryption is subject to cryptanalytic attack [FLU01], the integrity check was also subject, so
an attacker could modify content and the corresponding check without having to know the
associated encryption key [BOR01]. WPA includes a 64-bit integrity check that is encrypted.

The setup protocol for WPA and WPA2 is much more robust than that for WEP. Setup for
WPA involves three protocol steps: authentication, a four-way handshake (to ensure that the
client can generate cryptographic keys and to generate and install keys for both encryption and
integrity on both ends), and an optional group key handshake (for multicast communication.)
A good overview of the WPA protocols is in [LEH05].

WPA and WPA2 address the security deficiencies known in WEP. Arazi et al. [ARA05] make
a strong case for public key cryptography in wireless sensor networks, and a similar argument
can be made for other wireless applications (although the heavier computation demands of
public key encryption is a limiting factor on wireless devices with limited processor
capabilities.)

Honeypots, Alarms and Alerts - Security in Networks

Alarms and Alerts

The logical view of network protection looks like Figure 7-32, in which both a router and a
firewall provide layers of protection for the internal network. Now let us add one more layer to
this defense.

An intrusion detection system is a device that is placed inside a protected network to monitor
what occurs within the network. If an attacker passes through the router and passes through the
firewall, an intrusion detection system offers the opportunity to detect the attack at the
beginning, in progress, or after it has occurred. Intrusion detection systems activate an alarm,
which can take defensive action. We study intrusion detection systems in more detail later in
this chapter.

Honeypots

How do you catch a mouse? You set a trap with bait (food the mouse finds attractive) and
catch the mouse after it is lured into the trap. You can catch a computer attacker the same way.
In a very interesting book, Cliff Stoll [STO89] details the story of attracting and monitoring
the actions of an attacker. Cheswick [CHE90, CHE02] and Bellovin [BEL92c] tell a similar
story. These two cases describe the use of a honeypot: a computer system open to attackers.

You put up a honeypot for several reasons:

a) to watch what attackers do, in order to learn about new attacks (so that you can strengthen
your defenses against these new attacks)
b) to lure an attacker to a place in which you may be able to learn enough to identify and stop
the attacker
c) to provide an attractive but diversionary playground, hoping that the attacker will leave
your real system alone

A honeypot has no special features. It is just a computer system or a network segment, loaded
with servers and devices and data. It may be protected with a firewall, although you want the
attackers to have some access. There may be some monitoring capability, done carefully so
that the monitoring is not evident to the attacker.

The two difficult features of a honeypot are putting up a believable, attractive false environment
and confining and monitoring the attacker surreptitiously. Spitzner [SPI02, SPI03a] has done
extensive work developing and analyzing honeypots. He thinks like the attacker, figuring what
the attacker will want to see in an invaded computer, but as McCarty [MCC03] points out, it is
always a race between attacker and defender. Spitzner also tries to move much of his data off
the target platform so that the attacker will not be aware of the analysis and certainly not be
able to modify or erase the data gathered. Raynal [RAY04a. RAY04b] discusses how to
analyze the data collected.

Traffic Flow Security

So far, we have looked at controls that cover the most common network threats: cryptography
for eavesdropping, authentication methods for impersonation, intrusion detection systems for
attacks in progress, architecture for structural flaws. Earlier in this chapter, we listed threats,
including a threat of traffic flow inference. If the attacker can detect an exceptional volume of
traffic between two points, the attacker may infer the location of an event about to occur.

The countermeasure to traffic flow threats is to disguise the traffic flow. One way to disguise
traffic flow, albeit costly and perhaps crude, is to ensure a steady volume of traffic between
two points. If traffic between A and B is encrypted so that the attacker can detect only the
number of packets flowing, A and B can agree to pass recognizable (to them) but meaningless
encrypted traffic. When A has much to communicate to B, there will be few meaningless
packets; when communication is light, A will pad the traffic stream with many spurious
packets.

A more sophisticated approach to traffic flow security is called onion routing [SYV97].
Consider a message that is covered in multiple layers, like the layers of an onion. A wants to
send a message to B but doesn't want anyone in or intercepting traffic on the network to know
A is communicating with B. So A takes the message to B, wraps it in a package for D to send
to B. Then, A wraps that package in another package for C to send to D. Finally, A sends this
package to C. This process is shown in Figure 7-33. The internal wrappings are all encrypted
under a key appropriate for the intermediate recipient.
 Receiving the package, C knows it came from A, although C does not know if A is the
originator or an intermediate point. C then unwraps the outer layer and sees it should be sent
to D. At this point, C cannot know if D is the final recipient or merely an intermediary. C sends
the message to D, who unwraps the next layer. D knows neither where the package originally
came from nor where its final destination is. D forwards the package to B, its ultimate recipient.
With this scheme, any intermediate recipientsthose other than the original sender and ultimate
receiverknow neither where the package originated nor where it will end up. This scheme
provides confidentiality of content, source, destination, and routing.

Controls Review

At the end of our earlier discussion on threats in networks, we listed in Table 7-4 many of the
vulnerabilities present in networks. Now that we have surveyed the controls available for
networks, we repeat that table as Table 7-7, adding a column to show the controls that can
protect against each vulnerability. (Note: This table is not exhaustive; other controls can be
used against some of the vulnerabilities.)
Firewalls

Firewalls were officially invented in the early 1990s, but the concept really reflects the
reference monitor (described in Chapter 5) from two decades earlier. The first reference to a
firewall by that name may be [RAN92]; other early references to firewalls are the Trusted
Information Systems firewall toolkit [RAN94] and the book by Cheswick and Bellovin
[updated as CHE02].

What Is a Firewall?

A firewall is a device that filters all traffic between a protected or "inside" network and a less
trustworthy or "outside" network. Usually a firewall runs on a dedicated device; because it is a
single point through which traffic is channeled, performance is important, which means
nonfirewall functions should not be done on the same machine. Because a firewall is executable
code, an attacker could compromise that code and execute from the firewall's device. Thus, the
fewer pieces of code on the device, the fewer tools the attacker would have by compromising
the firewall. Firewall code usually runs on a proprietary or carefully minimized operating
system.

The purpose of a firewall is to keep "bad" things outside a protected environment. To

accomplish that, firewalls implement a security policy that is specifically designed to address
what bad things might happen. For example, the policy might be to prevent any access from
outside (while still allowing traffic to pass from the inside to the outside). Alternatively, the
policy might permit accesses only from certain places, from certain users, or for certain
activities. Part of the challenge of protecting a network with a firewall is determining which
security policy meets the needs of the installation.

People in the firewall community (users, developers, and security experts) disagree about how
a firewall should work. In particular, the community is divided about a firewall's default
behavior. We can describe the two schools of thought as "that which is not expressly forbidden
is permitted" (default permit) and "that which is not expressly permitted is forbidden" (default
deny). Users, always interested in new features, prefer the former. Security experts, relying on
several decades of experience, strongly counsel the latter. An administrator implementing or
configuring a firewall must choose one of the two approaches, although the administrator can
often broaden the policy by setting the firewall's parameters.

Design of Firewalls

Remember from Chapter 5 that a reference monitor must be

a) always invoked
b) tamperproof
c) small and simple enough for rigorous analysis

A firewall is a special form of reference monitor. By carefully positioning a firewall within a

network, we can ensure that all network accesses that we want to control must pass through it.
This restriction meets the "always invoked" condition. A firewall is typically well isolated,
making it highly immune to modification. Usually a firewall is implemented on a separate
computer, with direct connections only to the outside and inside networks. This isolation is
expected to meet the "tamperproof" requirement. And firewall designers strongly recommend
keeping the functionality of the firewall simple.

Types of Firewalls

Types of Firewalls

Firewalls have a wide range of capabilities. Types of firewalls include

packet filtering gateways or screening routers

1) stateful inspection firewalls

2) application proxies
3) guards
4) personal firewalls

Each type does different things; no one is necessarily "right" and the others "wrong." In this
section, we examine each type to see what it is, how it works, and what its strengths and
weaknesses are. In general, screening routers tend to implement rather simplistic security
policies, whereas guards and proxy gateways have a richer set of choices for security policy.
Simplicity in a security policy is not a bad thing; the important question to ask when choosing
a type of firewall is what threats an installation needs to counter.
Because a firewall is a type of host, it often is as programmable as a good-quality workstation.
While a screening router can be fairly primitive, the tendency is to host even routers on
complete computers with operating systems because editors and other programming tools assist
in configuring and maintaining the router. However, firewall developers are minimalists: They
try to eliminate from the firewall all that is not strictly necessary for the firewall's functionality.
There is a good reason for this minimal constraint: to give as little assistance as possible to a
successful attacker. Thus, firewalls tend not to have user accounts so that, for example, they
have no password file to conceal. Indeed, the most desirable firewall is one that runs
contentedly in a back room; except for periodic scanning of its audit logs, there is seldom
reason to touch it.

Packet Filtering Gateway

A packet filtering gateway or screening router is the simplest, and in some situations, the most
effective type of firewall. A packet filtering gateway controls access to packets on the basis of
packet address (source or destination) or specific transport protocol type (such as HTTP web
traffic). As described earlier in this chapter, putting ACLs on routers may severely impede their
performance. But a separate firewall behind (on the local side) of the router can screen traffic
before it gets to the protected network. Figure 7-34 shows a packet filter that blocks access
from (or to) addresses in one network; the filter allows HTTP traffic but blocks traffic using
the Telnet protocol.
For example, suppose an international company has three LANs at three locations throughout
the world, as shown in Figure 7-35. In this example, the router has two sides: inside and outside.
We say that the local LAN is on the inside of the router, and the two connections to distant
LANs through wide area networks are on the outside. The company might want communication
only among the three LANs of the corporate network. It could use a screening router on the
LAN at [Link] to allow in only communications destined to the host at [Link] and to
allow out only communications addressed either to address [Link] or [Link].

Packet filters do not "see inside" a packet; they block or accept packets solely on the basis of
the IP addresses and ports. Thus, any details in the packet's data field (for example, allowing
certain Telnet commands while blocking other services) is beyond the capability of a packet
filter.

Packet filters can perform the very important service of ensuring the validity of inside
addresses. Inside hosts typically trust other inside hosts for all the reasons described as
characteristics of LANs. But the only way an inside host can distinguish another inside host is
by the address shown in the source field of a message. Source addresses in packets can be
forged, so an inside application might think it was communicating with another host on the
inside instead of an outside forger. A packet filter sits between the inside network and the
outside net, so it can know if a packet from the outside is forging an inside address, as shown
in Figure 7-36. A screening packet filter might be configured to block all packets from the
outside that claimed their source address was an inside address. In this example, the packet
filter blocks all packets claiming to come from any address of the form 100.50.25.x (but, of
course, it permits in any packets with destination 100.50.25.x).

The primary disadvantage of packet filtering routers is a combination of simplicity and

complexity. The router's inspection is simplistic; to perform sophisticated filtering, the filtering
rules set needs to be very detailed. A detailed rules set will be complex and therefore prone to
error. For example, blocking all port 23 traffic (Telnet) is simple and straightforward. But if
some Telnet traffic is to be allowed, each IP address from which it is allowed must be specified
in the rules; in this way, the rule set can become very long.

Stateful Inspection Firewall

Filtering firewalls work on packets one at a time, accepting or rejecting each packet and
moving on to the next. They have no concept of "state" or "context" from one packet to the
next. A stateful inspection firewall maintains state information from one packet to another in
the input stream.

One classic approach used by attackers is to break an attack into multiple packets by forcing
some packets to have very short lengths so that a firewall cannot detect the signature of an
attack split across two or more packets. (Remember that with the TCP protocols, packets can
arrive in any order, and the protocol suite is responsible for reassembling the packet stream in
proper order before passing it along to the application.) A stateful inspection firewall would
track the sequence of packets and conditions from one packet to another to thwart such an
attack.

Application Proxy

Packet filters look only at the headers of packets, not at the data inside the packets. Therefore,
a packet filter would pass anything to port 25, assuming its screening rules allow inbound
connections to that port. But applications are complex and sometimes contain errors. Worse,
applications (such as the e-mail delivery agent) often act on behalf of all users, so they require
privileges of all users (for example, to store incoming mail messages so that inside users can
read them). A flawed application, running with all users' privileges, can cause much damage.

An application proxy gateway, also called a bastion host , is a firewall that simulates the
(proper) effects of an application so that the application receives only requests to act properly.
A proxy gateway is a two-headed device: It looks to the inside as if it is the outside (destination)
connection, while to the outside it responds just as the insider would.

An application proxy runs pseudoapplications. For instance, when electronic mail is

transferred to a location, a sending process at one site and a receiving process at the destination
communicate by a protocol that establishes the legitimacy of a mail transfer and then actually
transfers the mail message. The protocol between sender and destination is carefully defined.
A proxy gateway essentially intrudes in the middle of this protocol exchange, seeming like a
destination in communication with the sender that is outside the firewall, and seeming like the
sender in communication with the real destination on the inside. The proxy in the middle has
the opportunity to screen the mail transfer, ensuring that only acceptable e-mail protocol
commands are sent to the destination.

As an example of application proxying, consider the FTP (file transfer) protocol. Specific
protocol commands fetch (get) files from a remote location, store (put) files onto a remote host,
list files (ls) in a directory on a remote host, and position the process (cd) at a particular point
in a directory tree on a remote host. Some administrators might want to permit gets but block
puts, and to list only certain files or prohibit changing out of a particular directory (so that an
outsider could retrieve only files from a prespecified directory). The proxy would simulate both
sides of this protocol exchange. For example, the proxy might accept get commands, reject put
commands, and filter the local response to a request to list files.
To understand the real purpose of a proxy gateway, let us consider several examples.

1) A company wants to set up an online price list so that outsiders can see the products
and prices offered. It wants to be sure that (a) no outsider can change the prices or
product list and (b) outsiders can access only the price list, not any of the more sensitive
files stored inside.
2) A school wants to allow its students to retrieve any information from World Wide Web
resources on the Internet. To help provide efficient service, the school wants to know
what sites have been visited and what files from those sites have been fetched;
particularly popular files will be cached locally.
3) A government agency wants to respond to queries through a database management
system. However, because of inference attacks against databases, the agency wants to
restrict queries that return the mean of a set of fewer than five values.
4) A company with multiple offices wants to encrypt the data portion of all e-mail to
addresses at its other offices. (A corresponding proxy at the remote end will remove the
encryption.)
5) A company wants to allow dial-in access by its employees, without exposing its
company resources to login attacks from remote nonemployees.

Each of these requirements can be met with a proxy. In the first case, the proxy would monitor
the file transfer protocol data to ensure that only the price list file was accessed, and that file
could only be read, not modified. The school's requirement could be met by a logging procedure
as part of the web browser. The agency's need could be satisfied by a special-purpose proxy
that interacted with the database management system, performing queries but also obtaining
the number of values from which the response was computed and adding a random minor error
term to results from small sample sizes. The requirement for limited login could be handled by
a specially written proxy that required strong user authentication (such as a challengeresponse
system), which many operating systems do not require. These functions are shown in Figure
7-37.
The proxies on the firewall can be tailored to specific requirements, such as logging details
about accesses. They can even present a common user interface to what may be dissimilar
internal functions. Suppose the internal network has a mixture of operating system types, none
of which support strong authentication through a challengeresponse token. The proxy can
demand strong authentication (name, password, and challengeresponse), validate the
challengeresponse itself, and then pass on only simple name and password authentication
details in the form required by a specific internal host's operating system.

The distinction between a proxy and a screening router is that the proxy interprets the protocol
stream to an application, to control actions through the firewall on the basis of things visible
within the protocol, not just on external header data.

Guard

A guard is a sophisticated firewall. Like a proxy firewall, it receives protocol data units,
interprets them, and passes through the same or different protocol data units that achieve either
the same result or a modified result. The guard decides what services to perform on the user's
behalf in accordance with its available knowledge, such as whatever it can reliably know of the
(outside) user's identity, previous interactions, and so forth. The degree of control a guard can
provide is limited only by what is computable. But guards and proxy firewalls are similar
enough that the distinction between them is sometimes fuzzy. That is, we can add functionality
to a proxy firewall until it starts to look a lot like a guard.

Guard activities can be quite sophisticated, as illustrated in the following examples:

1) A university wants to allow its students to use e-mail up to a limit of so many messages
or so many characters of e-mail in the last so many days. Although this result could be
achieved by modifying e-mail handlers, it is more easily done by monitoring the
common point through which all e-mail flows, the mail transfer protocol.
2) A school wants its students to be able to access the World Wide Web but, because of
the slow speed of its connection to the web, it will allow only so many characters per
downloaded image (that is, allowing text mode and simple graphics, but disallowing
complex graphics, animation, music, or the like).
3) A library wants to make available certain documents but, to support fair use of
copyrighted matter, it will allow a user to retrieve only the first so many characters of
a document. After that amount, the library will require the user to pay a fee that will be
forwarded to the author.

A company wants to allow its employees to fetch files via ftp. However, to prevent introduction
of viruses, it will first pass all incoming files through a virus scanner. Even though many of
these files will be nonexecutable text or graphics, the company administrator thinks that the
expense of scanning them (which should pass) will be negligible.

Each of these scenarios can be implemented as a modified proxy. Because the proxy decision
is based on some quality of the communication data, we call the proxy a guard. Since the
security policy implemented by the guard is somewhat more complex than the action of a
proxy, the guard's code is also more complex and therefore more exposed to error. Simpler
firewalls have fewer possible ways to fail or be subverted.

Personal Firewalls

Firewalls typically protect a (sub)network of multiple hosts. University students and

employees in offices are behind a real firewall. Increasingly, home users, individual workers,
and small businesses use cable modems or DSL connections with unlimited, always-on access.
These people need a firewall, but a separate firewall computer to protect a single workstation
can seem too complex and expensive. These people need a firewall's capabilities at a lower
price.
A personal firewall is an application program that runs on a workstation to block unwanted
traffic, usually from the network. A personal firewall can complement the work of a
conventional firewall by screening the kind of data a single host will accept, or it can
compensate for the lack of a regular firewall, as in a private DSL or cable modem connection.

Just as a network firewall screens incoming and outgoing traffic for that network, a personal
firewall screens traffic on a single workstation. A workstation could be vulnerable to malicious
code or malicious active agents (ActiveX controls or Java applets), leakage of personal data
stored on the workstation, and vulnerability scans to identify potential weaknesses.
Commercial implementations of personal firewalls include Norton Personal Firewall from
Symantec, McAfee Personal Firewall, and Zone Alarm from Zone Labs (now owned by
CheckPoint).

The personal firewall is configured to enforce some policy. For example, the user may decide
that certain sites, such as computers on the company network, are highly trustworthy, but most
other sites are not. The user defines a policy permitting download of code, unrestricted data
sharing, and management access from the corporate segment, but not from other sites. Personal
firewalls can also generate logs of accesses, which can be useful to examine in case something
harmful does slip through the firewall.

Combining a virus scanner with a personal firewall is both effective and efficient. Typically,
users forget to run virus scanners daily, but they do remember to run them occasionally, such
as sometime during the week. However, leaving the virus scanner execution to the user's
memory means that the scanner detects a problem only after the factsuch as when a virus has
been downloaded in an e-mail attachment. With the combination of a virus scanner and a
personal firewall, the firewall directs all incoming e-mail to the virus scanner, which examines
every attachment the moment it reaches the target host and before it is opened.

A personal firewall runs on the very computer it is trying to protect. Thus, a clever attacker is
likely to attempt an undetected attack that would disable or reconfigure the firewall for the
future. Still, especially for cable modem, DSL, and other "always on" connections, the static
workstation is a visible and vulnerable target for an ever-present attack community. A personal
firewall can provide reasonable protection to clients that are not behind a network firewall.

Comparison of Firewall Types

We can summarize the differences among the several types of firewalls we have studied in
depth. The comparisons are shown in Table 7-8.

Example Firewall Configurations

Let us look at several examples to understand how to use firewalls. We present situations
designed to show how a firewall complements a sensible security policy and architecture. The
simplest use of a firewall is shown in Figure 7-38. This environment has a screening router
positioned between the internal LAN and the outside network connection. In many cases, this
installation is adequate when we need only screen the address of a router.
However, to use a proxy machine, this organization is not ideal. Similarly, configuring a router
for a complex set of approved or rejected addresses is difficult. If the firewall router is
successfully attacked, then all traffic on the LAN to which the firewall is connected is visible.
To reduce this exposure, a proxy firewall is often installed on its own LAN, as shown in Figure
7-39. In this way the only traffic visible on that LAN is the traffic going into and out of the
firewall.

For even more protection, we can add a screening router to this configuration, as shown
in Figure 7-40. Here, the screening router ensures address correctness to the proxy firewall (so
that the proxy firewall cannot be fooled by an outside attacker forging an address from an inside
host); the proxy firewall filters traffic according to its proxy rules. Also, if the screening router
is subverted, only the traffic to the proxy firewall is visiblenot any of the sensitive information
on the internal protected LAN.
Although these examples are simplifications, they show the kinds of configurations firewalls
protect. Next, we review the kinds of attacks against which firewalls can and cannot protect.

What Firewalls Can and Cannot Block

As we have seen, firewalls are not complete solutions to all computer security problems. A
firewall protects only the perimeter of its environment against attacks from outsiders who want
to execute code or access data on the machines in the protected environment. Keep in mind
these points about firewalls.

1) Firewalls can protect an environment only if the firewalls control the entire perimeter.
That is, firewalls are effective only if no unmediated connections breach the perimeter.
If even one inside host connects to an outside address, by a modem for example, the
entire inside net is vulnerable through the modem and its host.
2) Firewalls do not protect data outside the perimeter; data that have properly passed
(outbound) through the firewall are just as exposed as if there were no firewall.
3) Firewalls are the most visible part of an installation to the outside, so they are the most
attractive target for attack. For this reason, several different layers of protection,
called defence in depth, are better than relying on the strength of just a single firewall.
4) Firewalls must be correctly configured, that configuration must be updated as the
internal and external environment changes, and firewall activity reports must be
reviewed periodically for evidence of attempted or successful intrusion.
5) Firewalls are targets for penetrators. While a firewall is designed to withstand attack, it
is not impenetrable. Designers intentionally keep a firewall small and simple so that
even if a penetrator breaks it, the firewall does not have further tools, such as compilers,
linkers, loaders, and the like, to continue an attack.
6) Firewalls exercise only minor control over the content admitted to the inside, meaning
that inaccurate data or malicious code must be controlled by other means inside the
perimeter.

Firewalls are important tools in protecting an environment connected to a network. However,

the environment must be viewed as a whole, all possible exposures must be considered, and
the firewall must fit into a larger, comprehensive security strategy. Firewalls alone cannot
secure an environment.
Intrusion Detection Systems

After the perimeter controls, firewall, and authentication and access controls block certain
actions, some users are admitted to use a computing system. Most of these controls are
preventive: They block known bad things from happening. Many studies (for example,
see [DUR99]) have shown that most computer security incidents are caused by insiders, people
who would not be blocked by a firewall. And insiders require access with significant privileges
to do their daily jobs. The vast majority of harm from insiders is not malicious; it is honest
people making honest mistakes. Then, too, there are the potential malicious outsiders who have
somehow passed the screens of firewalls and access controls. Prevention, although necessary,
is not a complete computer security control; detection during an incident copes with harm that
cannot be prevented in advance. Halme and Bauer [HAL95] survey the range of controls to
address intrusions.

Intrusion detection systems complement these preventive controls as the next line of defense.
An intrusion detection system (IDS) is a device, typically another separate computer, that
monitors activity to identify malicious or suspicious events. Kemmerer and
Vigna [KEM02] survey the history of IDSs. An IDS is a sensor, like a smoke detector, that
raises an alarm if specific things occur. A model of an IDS is shown in Figure 7-41. The
components in the figure are the four basic elements of an intrusion detection system, based on
the Common Intrusion Detection Framework of [STA96]. An IDS receives raw inputs from
sensors. It saves those inputs, analyzes them, and takes some controlling action.
IDSs perform a variety of functions:

1) monitoring users and system activity

2) auditing system configuration for vulnerabilities and misconfigurations
3) assessing the integrity of critical system and data files
4) recognizing known attack patterns in system activity
5) identifying abnormal activity through statistical analysis
6) managing audit trails and highlighting user violation of policy or normal activity
7) correcting system configuration errors
8) installing and operating traps to record information about intruders

No one IDS performs all of these functions. Let us look more closely at the kinds of IDSs and
their use in providing security.

Types of IDSs (Intrusion Detection Systems)

Types of IDSs
The two general types of intrusion detection systems are signature based and
heuristic. Signature-based intrusion detection systems perform simple pattern-matching and
report situations that match a pattern corresponding to a known attack type. Heuristic intrusion
detection systems, also known as anomaly based, build a model of acceptable behavior and
flag exceptions to that model; for the future, the administrator can mark a flagged behavior as
acceptable so that the heuristic IDS will now treat that previously unclassified behavior as
acceptable.

Intrusion detection devices can be network based or host based. A etwork -based IDS is a stand-
alone device attached to the network monitor traffic throughout that network; a host-based IDS
runs on to a single workstation or client or host, to protect that one host.

Early intrusion detection systems (for example, [DEN87b, LUN90a, FOX90 , LIE89]) worked
after the fact, by reviewing logs of system activity to spot potential misuses that had occurred.
The administrator could review the results of the IDS to find and fix weaknesses in the system.
Now, however, intrusion detection systems operate in real time (or near real time), watching
activity and raising alarms in time for the administrator to take protective action.

Signature-Based Intrusion Detection

A simple signature for a known attack type might describe a series of TCP SYN packets sent
to many different ports in succession and at times close to one another, as would be the case
for a port scan. An intrusion detection system would probably find nothing unusual in the first
SYN, say, to port 80, and then another (from the same source address) to port 25. But as more
and more ports receive SYN packets, especially ports that are not open, this pattern reflects a
possible port scan. Similarly, some implementations of the protocol stack fail if they receive
an ICMP packet with a data length of 65535 bytes, so such a packet would be a pattern for
which to watch.

The problem with signature-based detection is the signatures themselves. An attacker will try
to modify a basic attack in such a way that it will not match the known signature of that attack.
For example, the attacker may convert lowercase to uppercase letters or convert a symbol such
as "blank space" to its character code equivalent %20. The IDS must necessarily work from a
canonical form of the data stream in order to recognize that %20 matches a pattern with a blank
space. The attacker may insert malformed packets that the IDS will see, to intentionally cause
a pattern mismatch; the protocol handler stack will discard the packets because of the
malformation. Each of these variations could be detected by an IDS, but more signatures
require additional work for the IDS, which reduces performance.

Of course, signature-based IDSs cannot detect a new attack for which a signature is not yet
installed in the database. Every attack type starts as a new pattern at some time, and the IDS is
helpless to warn of its existence.

Signature-based intrusion detection systems tend to use statistical analysis. This approach
uses statistical tools both to obtain sample measurements of key indicators (such as amount of
external activity, number of active processes, number of transactions) and to determine whether
the collected measurements fit the predetermined attack signatures.

Ideally, signatures should match every instance of an attack, match subtle variations of the
attack, but not match traffic that is not part of an attack. However, this goal is grand but
unreachable.

Heuristic Intrusion Detection

Because signatures are limited to specific, known attack patterns, another form of intrusion
detection becomes useful. Instead of looking for matches, heuristic intrusion detection looks
for behavior that is out of the ordinary. The original work in this area (for example, [TEN90])
focused on the individual, trying to find characteristics of that person that might be helpful in
understanding normal and abnormal behavior. For example, one user might always start the
day by reading e-mail, write many documents using a word processor, and occasionally back
up files. These actions would be normal. This user does not seem to use many administrator
utilities. If that person tried to access sensitive system management utilities, this new behavior
might be a clue that someone else was acting under the user's identity.

If we think of a compromised system in use, it starts clean, with no intrusion, and it ends dirty,
fully compromised. There may be no point in the trace of use in which the system changed
from clean to dirty; it was more likely that little dirty events occurred, occasionally at first and
then increasing as the system became more deeply compromised. Any one of those events
might be acceptable by itself, but the accumulation of them and the order and speed at which
they occurred could have been signals that something unacceptable was happening. The
inference engine of an intrusion detection system performs continuous analysis of the system,
raising an alert when the system's dirtiness exceeds a threshold.
Inference engines work in two ways. Some, called state-based intrusion detection systems, see
the system going through changes of overall state or configuration. They try to detect when the
system has veered into unsafe modes. Others try to map current activity onto a model of
unacceptable activity and raise an alarm when the activity resembles the model. These are
called model-based intrusion detection systems. This approach has been extended to networks
in [MUK94]. Later work (for example, [ FOR96, LIN99]) sought to build a dynamic model of
behavior, to accommodate variation and evolution in a person's actions over time. The
technique compares real activity with a known representation of normality.

Alternatively, intrusion detection can work from a model of known bad activity. For example,
except for a few utilities (login, change password, create user), any other attempt to access a
password file is suspect. This form of intrusion detection is known as misuse intrusion
detection. In this work, the real activity is compared against a known suspicious area.

All heuristic intrusion detection activity is classified in one of three categories: good/benign,
suspicious, or unknown. Over time, specific kinds of actions can move from one of these
categories to another, corresponding to the IDS's learning whether certain actions are
acceptable or not.

As with pattern-matching, heuristic intrusion detection is limited by the amount of information

the system has seen (to classify actions into the right category) and how well the current actions
fit into one of these categories.

Stealth Mode

An IDS is a network device (or, in the case of a host-based IDS, a program running on a
network device). Any network device is potentially vulnerable to network attacks. How useful
would an IDS be if it itself were deluged with a denial-of-service attack? If an attacker
succeeded in logging in to a system within the protected network, wouldn't trying to disable
the IDS be the next step?

To counter those problems, most IDSs run in stealth mode, whereby an IDS has two network
interfaces: one for the network (or network segment) being monitored and the other to generate
alerts and perhaps other administrative needs. The IDS uses the monitored interface as input
only; it never sends packets out through that interface. Often, the interface is configured so that
the device has no published address through the monitored interface; that is, a router cannot
route anything to that address directly, because the router does not know such a device exists.
It is the perfect passive wiretap. If the IDS needs to generate an alert, it uses only the alarm
interface on a completely separate control network. Such an architecture is shown in Figure 7-
42.

Other IDS Types

Some security engineers consider other devices to be IDSs as well. For instance, to detect
unacceptable code modification, programs can compare the active version of a software code
with a saved version of a digest of that code. The tripwire program [KIM98] is the most well
known software (or static data) comparison program. You run tripwire on a new system, and it
generates a hash value for each file; then you save these hash values in a secure place (offline,
so that no intruder can modify them while modifying a system file). If you later suspect your
system may have been compromised, you rerun tripwire, providing it the saved hash values. It
recomputes the hash values and reports any mismatches, which would indicate files that were
changed.

System vulnerability scanners, such as ISS Scanner or Nessus, can be run against a network.
They check for known vulnerabilities and report flaws found.
As we have seen, a honeypot is a faux environment intended to lure an attacker. It can be
considered an IDS, in the sense that the honeypot may record an intruder's actions and even
attempt to trace who the attacker is from actions, packet data, or connections.

Goals for Intrusion Detection Systems

Goals for Intrusion Detection Systems

The two styles of intrusion detectionpattern matching and heuristicrepresent different

approaches, each of which has advantages and disadvantages. Actual IDS products often blend
the two approaches.

Ideally, an IDS should be fast, simple, and accurate, while at the same time being complete. It
should detect all attacks with little performance penalty. An IDS could use someor allof the
following design approaches:

1) Filter on packet headers

2) Filter on packet content
3) Maintain connection state
4) Use complex, multipacket signatures
5) Use minimal number of signatures with maximum effect
6) Filter in real time, online
7) Hide its presence
8) Use optimal sliding time window size to match signatures

Responding to Alarms

Whatever the type, an intrusion detection system raises an alarm when it finds a match. The
alarm can range from something modest, such as writing a note in an audit log, to something
significant, such as paging the system security administrator. Particular implementations allow
the user to determine what action the system should take on what events.

What are possible responses? The range is unlimited and can be anything the administrator
can imagine (and program). In general, responses fall into three major categories (any or all of
which can be used in a single response):

1) Monitor, collect data, perhaps increase amount of data collected

2) Protect, act to reduce exposure
 3) Call a human

Monitoring is appropriate for an attack of modest (initial) impact. Perhaps the real goal is to
watch the intruder, to see what resources are being accessed or what attempted attacks are tried.
Another monitoring possibility is to record all traffic from a given source for future analysis.
This approach should be invisible to the attacker. Protecting can mean increasing access
controls and even making a resource unavailable (for example, shutting off a network
connection or making a file unavailable) . The system can even sever the network connection
the attacker is using. In contrast to monitoring, protecting may be very visible to the attacker.
Finally, calling a human allows individual discrimination. The IDS can take an initial defensive
action immediately while also generating an alert to a human who may take seconds, minutes,
or longer to respond.

False Results

Intrusion detection systems are not perfect, and mistakes are their biggest problem. Although
an IDS might detect an intruder correctly most of the time, it may stumble in two different
ways: by raising an alarm for something that is not really an attack (called a false positive, or
type I error in the statistical community) or not raising an alarm for a real attack (a false
negative, or type II error). Too many false positives means the administrator will be less
confident of the IDS's warnings, perhaps leading to a real alarm's being ignored. But false
negatives mean that real attacks are passing the IDS without action. We say that the degree of
false positives and false negatives represents the sensitivity of the system. Most IDS
implementations allow the administrator to tune the system's sensitivity, to strike an acceptable
balance between false positives and negatives.

Secure E-Mail

The final control we consider in depth is secure e-mail. Think about how much you use e-mail
and how much you rely on the accuracy of its contents. How would you react if you received
a message from your instructor saying that because you had done so well in your course so far,
you were excused from doing any further work in it? What if that message were a joke from a
classmate? We rely on e-mail's confidentiality and integrity for sensitive and important
communications, even though ordinary e-mail has almost no confidentiality or integrity. In this
section we investigate how to add confidentiality and integrity protection to ordinary e-mail.
Security for E-mail

E-mail is vital for today's commerce, as well a convenient medium for communications among
ordinary users. But, as we noted earlier, e-mail is very public, exposed at every point from the
sender's workstation to the recipient's screen. Just as you would not put sensitive or private
thoughts on a postcard, you must also acknowledge that e-mail messages are exposed and
available for others to [Link] we would like e-mail to be more secure. To define and
implement a more secure form, we begin by examining the exposures of ordinary e-mail.

Threats to E-mail

Consider threats to electronic mail:

1) message interception (confidentiality)

2) message interception (blocked delivery)
3) message interception and subsequent replay
4) message content modification
5) message origin modification
6) message content forgery by outsider
7) message origin forgery by outsider
8) message content forgery by recipient
9) message origin forgery by recipient
10) denial of message transmission

Confidentiality and content forgery are often handled by encryption. Encryption can also help
in a defense against replay, although we would also have to use a protocol in which each
message contains something unique that is encrypted. Symmetric encryption cannot protect
against forgery by a recipient, since both sender and recipient share a common key; however,
public key schemes can let a recipient decrypt but not encrypt. Because of lack of control over
the middle points of a network, senders or receivers generally cannot protect against blocked
delivery.

Requirements and Solutions

If we were to make a list of the requirements for secure e-mail, our wish list would include the
following protections.

1) message confidentiality (the message is not exposed en route to the receiver)

2) message integrity (what the receiver sees is what was sent)
3) sender authenticity (the receiver is confident who the sender was)
4) nonrepudiation (the sender cannot deny having sent the message)

Not all these qualities are needed for every message, but an ideal secure e-mail package would
allow these capabilities to be invoked selectively.

Designs

The standard for encrypted e-mail was developed by the Internet Society, through its
architecture board (IAB) and research (IRTF) and engineering (IETF) task forces. The
encrypted e-mail protocols are documented as an Internet standard in documents 1421, 1422,
1423, and 1424 [LIN93, KEN93, BAL93, KAL93a]. This standard is actually the third
refinement of the original specification.

One of the design goals for encrypted e-mail was allowing security-enhanced messages to
travel as ordinary messages through the existing Internet e-mail system. This requirement
ensures that the large existing e-mail network would not require change to accommodate
security. Thus, all protection occurs within the body of a message.

Confidentiality

Because the protection has several aspects, we begin our description of them by looking first
at how to provide confidentiality enhancements. The sender chooses a (random) symmetric
algorithm encryption key. Then, the sender encrypts a copy of the entire message to be
transmitted, including FROM:, TO:, SUBJECT:, and DATE: headers. Next, the sender
prepends plaintext headers. For key management, the sender encrypts the message key under
the recipient's public key, and attaches that to the message as well. The process of creating an
encrypted e-mail message is shown in Figure 7-43.
Encryption can potentially yield any string as output. Many e-mail handlers expect that
message traffic will not contain characters other than the normal printable characters. Network
e-mail handlers use unprintable characters as control signals in the traffic stream. To avoid
problems in transmission, encrypted e- mail converts the entire ciphertext message to printable
characters. An example of an encrypted e-mail message is shown in Figure 7-44. Notice the
three portions: an external (plaintext) header, a section by which the message encryption key
can be transferred, and the encrypted message itself. (The encryption is shown with shading.)
The encrypted e-mail standard works most easily as just described, using both symmetric and
asymmetric encryption. The standard is also defined for symmetric encryption only: To use
symmetric encryption, the sender and receiver must have previously established a shared secret
encryption key. The processing type ("Proc-Type") field tells what privacy enhancement
services have been applied. In the data exchange key field ("DEK-Info"), the kind of key
exchange (symmetric or asymmetric) is shown. The key exchange ("Key-Info") field contains
the message encryption key, encrypted under this shared encryption key. The field also
identifies the originator (sender) so that the receiver can determine which shared symmetric
key was used. If the key exchange technique were to use asymmetric encryption, the
key exchange field would contain the message encryption field, encrypted under the recipient's
public key. Also included could be the sender's certificate (used for determining authenticity
and for generating replies).

The encrypted e-mail standard supports multiple encryption algorithms, using popular
algorithms such as DES, triple DES, and AES for message confidentiality, and RSA and
DiffieHellman for key exchange.

Other Security Features

In addition to confidentiality, we may want various forms of integrity for secure e-mail.
Encrypted e-mail messages always carry a digital signature, so the authenticity and
nonrepudiability of the sender is assured. The integrity is also assured because of a hash
function (called a message integrity check, or MIC) in the digital signature. Optionally,
encrypted e-mail messages can be encrypted for confidentiality.

Notice in Figure 7 -44 that the header inside the message (in the encrypted portion) differs
from that outside. A sender's identity or the actual subject of a message can be concealed within
the encrypted portion.

The encrypted e-mail processing can integrate with ordinary e-mail packages, so a person can
send both enhanced and nonenhanced messages, as shown in Figure 7-45. If the sender decides
to add enhancements, an extra bit of encrypted e-mail processing is invoked on the sender's
end; the receiver must also remove the enhancements. But without enhancements, messages
flow through the mail handlers as usual.
S/MIME (discussed later in this section) can accommodate the exchange of other than just text
messages: support for voice, graphics, video, and other kinds of complex message parts.

Encryption for Secure E-mail

The major problem with encrypted e-mail is key management. The certificate scheme
described in Chapter 2 is excellent for exchanging keys and for associating an identity with a
public encryption key. The difficulty with certificates is building the hierarchy. Many
organizations have hierarchical structures. The encrypted e-mail dilemma is moving beyond
the single organization to an interorganizational hierarchy. Precisely because of the problem of
imposing a hierarchy on a nonhierarchical world, PGP was developed as a simpler form of
encrypted e-mail.

Encrypted e-mail provides strong end -to-end security for electronic mail. Triple DES, AES,
and RSA cryptography are quite strong, especially if RSA is used with a long bit key (1024
bits or more). The vulnerabilities remaining with encrypted e-mail come from the points not
covered: the endpoints. An attacker with access could subvert a sender's or receiver's machine,
modifying the code that does the privacy enhancements or arranging to leak a cryptographic
key.
Example Secure E-mail Systems

Encrypted e-mail programs are available from many sources. Several universities (including
Cambridge University in England and The University of Michigan in the United States) and
companies (BBN, RSA-DSI, and Trusted Information Systems) have developed either
prototype or commercial versions of encrypted e-mail.

PGP

PGP stands for Pretty Good Privacy. It was invented by Phil Zimmerman in 1991. Originally
a free package, it became a commercial product after being bought by Network Associates in
1996. A freeware version is still available. PGP is widely available, both in commercial
versions and freeware, and it is heavily used by individuals exchanging private e-mail.

PGP addresses the key distribution problem with what is called a "ring of trust" or a user's
"keyring." One user directly gives a public key to another, or the second user fetches the first's
public key from a server. Some people include their PGP public keys at the bottom of e-mail
messages. And one person can give a second person's key to a third (and a fourth, and so on).
Thus, the key association problem becomes one of caveat emptor: "Let the buyer beware." If I
am reasonably confident that an e-mail message really comes from you and has not been
tampered with, I will use your attached public key. If I trust you, I may also trust the keys you
give me for other people. The model breaks down intellectually when you give me all the keys
you received from people, who in turn gave you all the keys they got from still other people,
who gave them all their keys, and so [Link] sign each key you give me. The keys you give
me may also have been signed by other people. I decide to trust the veracity of a key-and-
identity combination, based on who signed the key.

PGP does not mandate a policy for establishing trust. Rather, each user is free to decide how
much to trust each key [Link] PGP processing performs some or all of the following
actions, depending on whether confidentiality, integrity, authenticity, or some combination of
these is selected:

Create a random session key for a symmetric algorithm.

1) Encrypt the message, using the session key (for message confidentiality).
2) Encrypt the session key under the recipient's public key.
3) Generate a message digest or hash of the message; sign the hash by encrypting it
with the sender's private key (for message integrity and authenticity).
 4) Attach the encrypted session key to the encrypted message and digest.
5) Transmit the message to the recipient.

The recipient reverses these steps to retrieve and validate the message content.

S/MIME

An Internet standard governs how e-mail is sent and received. The general MIME specification
defines the format and handling of e-mail attachments. S/MIME (Secure Multipurpose
Internet Mail Extensions) is the Internet standard for secure e-mail attachments.S/MIME is
very much like PGP and its predecessors, PEM (Privacy-Enhanced Mail) and RIPEM. The
Internet standards documents defining S/MIME (version 3) are described
in [HOU99] and [RAM99]. S/MIME has been adopted in commercial e-mail packages, such
as Eudora and Microsoft Outlook.

The principal difference between S/MIME and PGP is the method of key exchange. Basic PGP
depends on each user's exchanging keys with all potential recipients and establishing a ring of
trusted recipients; it also requires establishing a degree of trust in the authenticity of the keys
for those recipients. S/MIME uses hierarchically validated certificates, usually represented in
X.509 format, for key exchange. Thus, with S/MIME, the sender and recipient do not need to
have exchanged keys in advance as long as they have a common certifier they both trust.

S/MIME works with a variety of cryptographic algorithms, such as DES, AES, and RC2 for
symmetric encryption.

S/MIME performs security transformations very similar to those for PGP. PGP was originally
designed for plaintext messages, but S/MIME handles (secures) all sorts of attachments, such
as data files (for example, spreadsheets, graphics, presentations, movies, and sound). Because
it is integrated into many commercial e-mail packages, S/MIME is likely to dominate the secure
e-mail market.