Chapter 9.

Security

Quandoque bonus dormitat Homerus. Even good Homer nods

sometimes. (Even the cleverest can make mistakes.)

--Horace

In this chapter, we describe the vulnerabilities and threats to a mobilized

enterprise web architecture. We also describe mobile device security, secure
communications between the client and servers, and security on the
enterprise web servers and back-end systems.

Mobilized Enterprise Web Architectures

At the enterprise level, a secure architecture is usually required to protect the
service provider’s assets from being attacked. Security architectures generally
use some form of role-based access control and database-enabled or system-
enabled authentication and authorization mechanisms that integrate user
identity, user roles, and application entitlements. The security architecture
may also provide additional services, such as encryption, certificate
management, and smart card technology. In the following sections, we
describe several of the most common vulnerabilities and threats.

Vulnerabilities

Mobilized enterprise web architectures are vulnerable to attack from many

perspectives (see Figure 9-1). Some of these vulnerabilities are common and
relatively easy to remedy. Others are more subtle and may not be initially
intuitive or obvious. Some of the most common vulnerabilities are described
in the following sections.
Figure 9-1. Mobilized enterprise web architecture vulnerabilities

1. User activity. Users themselves can make the enterprise vulnerable.

For example, they can inadvertently trigger an attack simply by
opening an email attachment, downloading unsafe content from the
Web, or running a script that contains a virus. The more privileged a
user, the more dangerous this possibility is. For example, an
administrator who inadvertently introduces a virus into a system
can potentially propagate it throughout the enterprise.
2. Weak usernames and passwords. Weak usernames and passwords
can also make an enterprise vulnerable. Typical weak usernames
include “administrator” or “admin,” while weak passwords are
blank, “password,” or “1234.” Weak usernames and passwords can
 be remedied by instigating a security policy that enforces strong
usernames and passwords. For example, you can require that a
password must be at least ten characters in length, contain
uppercase and lowercase alphabetic and numeric characters, and
include at least one punctuation mark.
3. Excessive permissions. Users are often granted more permissions
and privileges than are strictly necessary. This may allow malicious
users to gain greater access to the system’s resources than should be
possible. It also allows users to accidentally commit security
breaches.
4. Deception. Users can be deceived into revealing private information
about themselves. For example, an attacker posing as an online help
desk operator might persuade a user to reveal his/her password
under the pretext of performing some administrative task. A well-
written application should never expose a password or require a
user to expose his/her password.
5. Excessive services and ports. Certain web servers (e.g., Microsoft
IIS) enable more services and port connections by default than are
strictly necessary to run a specific application. These unused services
and ports can provide an opening for attackers.
6. Unencrypted data transfer. Data is typically sent between a client
and server in unencrypted form. If this data is intercepted on the
wire or wirelessly, an attacker can read and/or alter the data.
7. Buffer overrun. Buffer overrun attacks occur when malicious users
exploit an unchecked buffer in a program and overwrite the contents
with their own code or data. If program code is overwritten with new
code, this changes the program’s operation to that prescribed by the
attacker. If data is overwritten with other data, this corrupts the
data’s integrity.
8. SQL injection attacks. SQL injection attacks can occur when SQL
statements are dynamically built through user input. Attackers with
good SQL knowledge can modify the SQL statements and make the
application execute tasks that may expose passwords or other
information.
9. Code-embedded usernames and passwords. Attackers can gain
access to a system if they are able to read application code that
contains embedded usernames or passwords. Web pages that contain
database connection strings are vulnerable in this scenario.
Threats

Many threats can be made against an enterprise’s systems and applications.

Microsoft classifies these threats into several major categories that are
commonly known and easily remembered by the acronym “STRIDE.” Each
letter of STRIDE represents a type of threat: Spoofing, Tampering, Repudiation,
Information disclosure, Denial of service, and Elevation of privilege.

1. Spoofing. Spoofing occurs when an attacker pretends to be a user

who is trusted by the system. In doing so, the attacker is able to
assume the identity of the user and may gain access to unauthorized
areas. Spoofing can also occur when a system is fooled into trusting
another system that is under the control of an attacker.
2. Tampering. Tampering occurs when an attacker gains access to a
system and tampers with its operation or function.
3. Repudiation. Repudiation occurs when a system is unable to prove
that an event occurred. This is normally a result of insufficient
auditing or logging abilities. For example, even if an attacker is
caught, he/she may be able to repudiate having attacked the system
because there is no proof.
4. Information disclosure. Information disclosure occurs when an
attacker is able to view an individual’s private data. Some of this data
obviously needs to be secure, such as a user’s date of birth, mother’s
maiden name, or social security number. However, other
information may also require the same level of security, but for more
subtle reasons. For example, a user’s selection of favorite stocks does
not seem at first glance to require strong security. However, if the
stock portfolio belongs to a prominent investor, it could be leveraged
by an attacker.
5. Denial of service. A denial of service attack disrupts or prevents
access to a system or its resources by flooding the system with
messages. These attacks cause applications to become starved of CPU
or memory resources and ultimately prevent users from accessing
the applications.
6. Elevation of privilege. Elevation of privilege attacks are launched
when an attacker is able to elevate or gain additional privileges to
those normally granted (e.g., a normal registered user is able to gain
administrative privileges).
Mitigation

Vulnerabilities and threats can be mitigated by a variety of mechanisms. Some

of the most common mitigation methods are described below.

• Authentication and access control. Authentication can be used to

verify that a user is who he/she claims to be, while access control
 through the use of entitlements determines what the user is allowed
to do and see.
• Secure communications. Communications between the various
tiers can be secured using encryption so that even if a message is
intercepted, it cannot be deciphered.
• Quality of service. A software service that profiles messages sent to
the system can be used to mitigate denial of service attacks.
• Throttling. Throttling limits the number of messages that can be
sent to a system. If throttles are set, it is possible to mitigate denial of
service attacks because the system cannot be flooded with messages.
• Auditing. Logging important events (auditing) is an important part
of mitigation; it creates a record of system and user activity that can
be reviewed by system owners to determine security threats and
their sources.
• Filtering. Authentication filters can be set on protected resources to
evaluate and block all messages coming into the enterprise that pose
a threat.
• Least privilege. Users should be granted the least number or level of
privileges that will allow them to carry out their normal tasks.
The rest of this chapter describes various threats against the mobilized
enterprise web architecture in detail and the mitigation techniques used to
defend the enterprise against them.

User-To-Mobile Client Security Issues

The simple interaction between a user and a mobile device can lead to security
breaches. For example, some of the vulnerabilities in this area include user
activity, weak usernames and passwords, excessive permissions, and users
being deceived into revealing too much information.

There are several mechanisms available to alleviate these vulnerabilities,

including the use of authentication, smart cards, and biometric authentication
(see Figure 9-2). In addition, granting the minimum level of privileges each
user needs will help alleviate these vulnerabilities. In the following sections,
we will discuss these mechanisms in more detail.
Figure 9-2. User-to-mobile client security issues

Authentication

Authentication helps mitigate the threat of spoofing. If the application

mandates the use of strong usernames and passwords and sets minimal
required privileges, the enterprise application’s vulnerability to attack will be
reduced. Authentication can be carried out at several levels, as described
below:

1. Mobile device. The mobile device itself may have or require the
entry of a username or password after a period of time has elapsed.
 For example, many cellular telephones require the entry of a
password before they will call a number.
2. Application authentication (local). If the mobile client is a fat
client, the application may have a login page that authenticates
against a local database when the mobile application is disconnected
from the back-end servers. A user must log in to use a particular
application regardless of whether he/she is connected to the
enterprise servers. This means that additional security, such as an
encrypted local database, may be required on the mobile device.
3. Application authentication (remote). If the mobile client is a thin
client, no custom application pages reside on it. A user can still log in
to the application on the server, but the user must then be always
connected. Authentication is therefore remote and is handled by
security on the server. However, you should ensure that persistent
state cookies, automatic password fill-in capabilities, and other such
mechanisms are not a threat to the enterprise as a whole. Any
application that requires the storage of this type of information on
the client can be vulnerable to attack since the person who next uses
the device may not be the authorized user.
Smart Cards

The practice of implementing smart cards to validate a user’s identity is now

also in use, but it is not yet as widespread as simple logging in and logging out.

Biometric Authentication

Emerging technologies that involve biometric authentication such as

fingerprinting, voice recognition, and retinal scans are also becoming viable
options for establishing user identity. Biometric authentication helps mitigate
the threat of spoofing and drastically reduces the enterprise application’s
vulnerability to attack, since the identity of a user is known very precisely,
reducing the chance of misidentification to virtually zero.

Mobile Client Security Issues

Users are understandably concerned about the security and privacy of data on
mobile devices, especially since mobile devices tend to be easily misplaced,
lost, or stolen.
However, while the loss of a mobile device may be annoying and expensive for
the user, the loss of the information stored on the mobile device may far
outweigh the value of the mobile device itself. For example, the loss of a
mobile device containing records of orders taken but not yet uploaded to the
server may be very costly. In addition, the possible exposure of private
information stored on the mobile device to unauthorized persons (i.e., the
person who stole the device or some other intruder) may have serious
consequences.

As a result of these concerns, several mechanisms can be implemented to

better protect mobile devices including automatic logout, credentials re-entry,
data destruction, database encryption, and encryption of code-embedded
usernames and passwords (see Figure 9-3). The following sections discuss
these mechanisms in more detail. Note, however, that these mechanisms are
not necessarily foolproof. In practice, it is very difficult to completely
guarantee the safeguarding of mobile devices. Implementing these safeguards,
however, makes it very difficult for intruders to access secure data even if
they physically have the mobile device.
Figure 9-3. Mobile client security issues

Automatic Logout and Credentials Re-Entry

Many mobile devices have automatic logout features triggered by user

inactivity. These features serve to protect the data on the mobile device if a
user loses or has the device stolen.

For example, cellular telephones, Pocket PCs, and Tablet PCs can be set to
require re-entry of user credentials after some period of time has elapsed. The
necessary software is provided by the vendor and it is typically a built-in
feature of the product.

Data Destruction
It is possible to implement a custom data destruction mechanism that erases
sensitive programs and data from the mobile device if it is out of contact from
the server for a prolonged period of time.

The mechanism can be a simple program that deletes designated files or data
from the mobile device after a predefined period of time has elapsed. It can
also be triggered to run when a user enters an incorrect password a certain
number of times.

It is also possible to create a server-initiated program that deletes designated

files from the mobile device. This may be harder to implement, however, since
you may not be able to contact the mobile device to initiate such an action.

Database Encryption

It is possible to encrypt the data in certain mobile device databases. For

example, Microsoft SQL Server CE databases can be encrypted. Thus, even if a
Pocket PC is lost, it becomes extremely difficult for intruders to read the data
held within the database.

Code-Embedded Usernames and Passwords

Encrypting the mobile device’s database, however, will not help if an attacker
can gain access to application code that contains embedded usernames or
passwords. As a result, all usernames and passwords contained in the mobile
client code or in configuration files should also be encrypted.

Client-Server Communications Security

Issues
Internet communications are not inherently secure, and it is possible to
intercept transmissions between a client and server. As a result, several types
of communication encryption have been developed to help prevent tapping
into the message stream and intercepting messages (see Figure 9-4).
Figure 9-4. Client-server communications security issues

Communication Encryption

The use of encryption is perhaps the most common method used to prevent
the reading of clear text messages between a client and server.

For example, the use of Secure Sockets Layer (SSL) is one of the most common
mechanisms used to prevent clear text message interception over the Internet.
SSL is typically used to encrypt data between a client and a web presentation
server.
In addition, wireless connections are often encrypted using Wired Equivalent
Privacy (WEP). The use of such an encrypted wireless connection requires the
entry of an encryption key on the mobile device. Without the encryption, it is
possible for unauthorized intruders to utilize or intercept information from
the wireless network.

While the use of encryption is generally recommended, it is also pertinent to

note that encryption comes at a price. Encryption (and decryption) can be
quite resource-intensive for both client and server. As a result, it is often better
to selectively encrypt data than to encrypt everything.

Existing Web Architectures and Back-End

Systems Security Issues
The existing web architecture and back-end systems may also have certain
vulnerabilities (see Figure 9-5). In the following sections, we discuss some of
the standard mechanisms that are used to secure enterprise web architectures
and back-end systems, such as firewalls, port lockdown, communication
encryption, and database authentication and encryption.
Figure 9-5. Existing web architecture and back-end systems security issues

Firewalls and Tier Separation

The judicious placement of firewalls and the separation of code and logic into
tiers are just two of several powerful mechanisms used to secure enterprise
web architectures.

Firewalls can be set up to filter all network traffic moving in and out of the
enterprise. Highly secure architectures may utilize multiple layers of firewall
protection to create several regions of trust. The frontmost firewall guards the
enterprise domain from the Internet, while the innermost firewall defends the
corporate intranet. Again, the semitrusted region between these two firewalls
is typically called the DMZ . This area may be hosted outside of the enterprise
by an Internet service provider.

The use of two firewalls creates three zones: the public, untrusted Internet
zone; the semitrusted DMZ ; and the trusted intranet zone. One benefit to using
a three-tier application architecture, from a security perspective, is the ability
to distribute application components securely within each zone. For example,
many enterprises place the Presentation Tier in the DMZ and the Application
and Database Tiers within the corporate intranet. This design provides
multiple layers of security protecting the crucial data stored within the
database.

Application Services and Port Lockdown

As mentioned earlier in this chapter, more application services and ports may
be available than are actually required to operate the application. Generally,
prior to deployment, a review of all services and open ports should be
undertaken, and unnecessary services stopped or disabled and unused ports
closed or disabled.

Communication Encryption

Although the application, database, and back-end servers typically lie within
an enterprise’s intranet, certain highly secured intranets (e.g., within banks or
brokerages) may require additional encryption on the network between them.
This is to prevent unauthorized access by internal users.

There are several commonly used encryption mechanisms to prevent the

reading of clear text messages between servers, as described below.

• SSL. SSL is one of the most common mechanisms used to prevent

clear text message interception within an enterprise. SSL may be
used to encrypt data between the application and database servers.
• IPSec. Internet Protocol Security (IPSec) is also used to encrypt data
passing between back-end systems, such as the web server,
application server, and database server.
• RPC encryption. The use of Remote Procedure Call (RPC) encryption
is also very common. It is typically used to encrypt messages between
serviced components on remote servers.
Database Authentication

In enterprise applications, database authentication can be performed using

individual user accounts or service accounts. Each method has its advantages
and disadvantages. Individual user authentication requires maintenance of
multiple accounts within the database and minimizes the ability for
applications to pool database connections. The use of a service account,
however, creates a different problem. If an attacker is able to retrieve the
service account username and password, he/she may gain access to the entire
database. In order to prevent this, applications that use service accounts
should keep the database connection string in an encrypted file for
safekeeping.

Database Encryption

Data held within the enterprise databases and back-end systems may be stored
encrypted. While the database can generally be expected to lie within an
enterprise’s intranet, certain highly secured intranets (e.g., within banks or
brokerages) may require that the database be encrypted to prevent
unauthorized access by internal users.

Summary
Security in a mobilized enterprise web architecture is an umbrella concern
that encompasses users, mobile devices, mobile clients, networks, web
applications, and back-end applications.

Every system and interface can be subjected to some form of attack and needs
to be secured. However, a secure architecture is only as strong as its weakest
link; once one system has been breached, the entire enterprise can be
compromised.

It is also important to note that no single security feature is completely

foolproof. Generally, several security features should be used in combination
to reduce the threat to the minimum level acceptable to the enterprise.

Security is a very broad topic and a detailed treatment of the subject is well
beyond the scope of this book. We recommend that interested readers