summary

ISEC 610: Information Assurance
Module-2

Bilge Karabacak

Secure Design Principles

2

Security must be built-in, not bolted-on.

SDLC

Planning

Analysis

Design

Development

Testing

Operation &
Maintenance

Planning

Analysis

Design

Acquisition &
Installation

(Implementation)

Testing

Operation &
Maintenance

Software Development LifecycleSystem Development Lifecycle

4

Windows Null Sessions

• Assets: Windows NT 4.0 (1993) – Windows 2008
• Built-in feature:

• Browser service
• Novell’s NDS service
• RPC service
• …

• How to exploit?
• Open a CMD prompt and type this:
• net use \remote.serveripc$ “” /u:””

• Impact:
• The names of and permission on shares opened on the remote systems
• User account details on the remote system Account and password policies
• User login times

net use \192.168.2.2ipc$ “” /u:””

192.168.2.2192.168.2.1

Domain
controller?

TCP/IP Protocol Suite (Using IPv4)

• Missing security mechanisms:
• Integrity
• Confidentiality
• Authentication
• Non-repudiation

• Attacks:
• Spoofing
• Sniffing
• Denial of Service
• Man-in-the-Middle

IPv6 Development and Transition Timeline
Early
1990s 1998 2017 2018

Start Draft Standard Internet Standard

2004

Virginia Tech
deployment

Comcast: 66%
AT&T: 22.3 million

Log4Shell Vulnerability (CVE-2021-44228)

• Asset: log4j, a popular java logging
library

• Used by millions of devices, servers,
vendors

• AWS, iCloud, Cloudflare, Minecraft,
Fortinet, Siemens, IBM, Microsoft,
Red Hat, Salesforce, Atlassian,
Hadoop, Elastic Search,

• “The single biggest, most critical
vulnerability ever”, Tenable

• “A Design failure”, LunaSec

log4j

LDAP Service
JNDI Service

Hacker

Apache
Webserver

Secure Design Principles

• CISSP Text:
• Secure defaults
• Keep it simple
• Threat modeling (SDLC)
• The least privilege
• Separation of duties
• Shared responsibility (Cloud computing)
• Zero Trust

• Rhodes-Ousley’s Text:
• CIA model
• The lollipop model of defense

• CISSP & Rhodes-Ousley’s Text:
• Defense in depth (Layered defense)

8

Risk Management

98

Probability
Impact

Assets
Vulnerabilities
Threats
Existing countermeasures

Risk

Risk Analysis

Risk Mitigation
Risk Transfer
Risk Acceptance

Risk Management

Risk Responses

The amount of vulnerabilities

The value of assets

The effectiveness
of threats

Abstract View of Risk

(Asset, Vulnerability, Threat)

Impact & Likelihood

99

Risk What do blue lines represent?

a) Confidentiality, Integrity, and Availability
b) Security Controls (Countermeasures)
c) Assets, Threats, Vulnerabilities
d) Internal threats, external threats,

environmental factors

Residual Risk

Question

• A security control (countermeasure, safeguard) that decreases the
amount of a vulnerability directly and considerably:

a) Encryption
b) Monitoring
c) Patching
d) Training

100

Question

• A security control (countermeasure, safeguard) that decreases the
effectiveness of a threat directly and considerably:

a) Encryption
b) Training
c) Patching
d) Monitoring

101

Question

• A security control (countermeasure, safeguard) that decreases the
value of an asset directly and considerably:

a) Monitoring
b) Encryption
c) Training
d) Patching

102

Two Broad Class of Controls
Detective Controls Preventive Controls

Vulnerability scanning

Pen testing Bug bounty programs

EncryptionMFA

IPS

Access Control (FW, user access control,
NAC)

Patching

Zero Trust
IDS

SIEM

Digital Forensics

SOC

Antivirus

EDR
Hardening

Training & Awareness

Cyber threat intelligence

I. Total prevention means 100%
security. > It is not possible.

II. Prevention is ideal but
detection is must! > Prevention
and detection are equally
important!

III. Every successful detection is
preceded by a prevention
failure.

IV. Every failed detection means a
disaster. (potentially)

Information Security Standards
ISO Standards, NIST Guidelines

105

ISO 27000 Series Standards

ISO 27001: The Directions on how
to manage information security in

an organization

106

27001

9 p.

27002

78 p.

ISO 27002: The Inventory of
countermeasures

ISO/IEC 27001:2013

Information technology – Security techniques –
Information security management systems –

Requirements

ISO/IEC 27002:2013

Information technology — Security techniques —
Code of practice for information security

management

The Difference Between Two Standards

107

ISO 27002 ISO 27001

ISO 27001 Certification

108

ISMS: Information Security Management System

Risk analysis

Problems

Risk mitigation

Internal audit

Corrective actions

Monitor & measure

Continual improvements

109

Countermeasures
ISO 27002

Security processes
(Previous page)

ISO 27001

110

27001
27002

27001
27002

27001
27002

NIST Guidelines

• NIST Special Publication 800-37
Risk Management Framework for
Information Systems and Organizations:
A System Life Cycle Approach for Security
and Privacy 111

• NIST Special Publication 800-53
Security and Privacy Controls for
Information Systems and
Organizations

112

27001

27002

~

~

Risk Management Framework for Information Systems
and Organizations: A System Life Cycle Approach for
Security and Privacy

Security and Privacy Controls for Information Systems and
Organizations

Information security management systems –
Requirements

Code of practice for information security management

CHAPTER

8 Securing Unstructured Data

Chapter 11 discusses the subject of securing data storage—how security can be
applied to the specific locations where data resides. That chapter focuses on the
static state of data (information) on a hard disk or in a database, but in the high-
bandwidth, mobile, and networked environments in which we work and live,
information rarely stays in one place. In a matter of microseconds, information
can be distributed to many locations and people around the world. In order to
secure this data, we must look beyond the simple confines of where information
can be stored and think more about how it is stored or, more accurately for this
chapter, how it is formatted.

Information is typically categorized as being in either a structured format or
an unstructured format. The meaning of these terms is subject to different
interpretations by divergent groups, so first we’ll address their meaning in the
context of our discussion of securing unstructured data. It also makes sense to
think in terms of which of three different states data is currently residing: at rest,
in transit, or in use. We’ll discuss that second. Finally, we’ll get to the primary
focus of the chapter, the different approaches to securing unstructured data.

Structured Data vs. Unstructured Data
For purposes of this book, we are not going to get into a detailed discussion about
whether, for example, the unstructured Excel spreadsheet actually contains very
structured data. In classic terms, structured data is data that conforms to some
sort of strict data model and is confined by that model. The model might define a
business process that controls the flow of information across a range of service-
oriented architecture (SOA) systems, for example, or it might define how data is
stored in an array in memory. But for most IT and security professionals,
structured data is the information that lives in the database and is organized
based on the database schema and associated database rules. This means two
important things to you as a security professional:

• Databases reside within a data center that is surrounded by brick walls, metal
cages, network firewalls, and other security mechanisms that allow you to
control access to the data.

• The data itself is structured in a manner that typically allows for easy
classification of the data. For example, you can identify a specific person’s
medical record in a database and apply security controls accordingly.

So, because you know what structured data looks like and where it resides,
you have tight control over who can access it. Security controls are relatively easy
to define and apply to structured data using either the built-in features of the
structure or third-party tools designed for the specific structure.

By contrast, unstructured data is much more difficult to manage and secure.
Unstructured data can live anywhere, in any format, and on any device, and can
move across any network. Consider, for example, a patient record that is
extracted from the database, displayed in a web page, copied from the web page
into a spreadsheet, attached to an e-mail, and then e-mailed to another location.
Simply describing the variety of networks, servers, storage, applications, and
other methods that were used to move the information beyond the database
could take an entire chapter.

Unstructured data has no strict format. Of course, our Word documents, e-
mails, and so on conform to standards that define their internal structure;
however, the data contained within them has few constraints. Returning to the
example of the patient record, suppose a user copies it from the web page into the
spreadsheet after altering its contents, maybe removing certain fields and
headers. As this information flows from one format to another, its original
structure has been effectively changed.

Figure 8-1 depicts some examples of how data can move around between
different locations, applications, and formats.

Figure 8-1 Unstructured data doesn’t respect security boundaries.

Securing information when stored as structured data is relatively
straightforward. But as a piece of information from the structured world moves

into the unstructured world—in different file formats, across networks you didn’t
expect it to traverse, stored in places you can’t control—you have less control.
Doesn’t sound good? Consider the fact that many analysts say 80 percent or more
of digital information in an organization is unstructured, and that the amount of
unstructured data is growing at a rate 10 to 20 times the rate of structured data.
Also consider the constant stream of news articles highlighting theft of
intellectual property, accidental loss of information, and malicious use of data, all
with unstructured data at the core of the problem. In 2010, the worldwide total of
unstructured data was estimated at roughly 1 million petabytes
(1,048,576,000,000 GB) and is considered to be increasing at a rate of 25 percent a
year. We clearly need to understand how we can secure unstructured data.

At Rest, in Transit, and in Use
Unstructured data can be in one of three states at any given time. It can be at rest,
sitting quietly on a storage device. It can also be in transit (sometimes referred to
as “in flight”), which means it is being copied from one location to another. Or, it
can be in use, in which case the data is actively open in some application. Take
for example a PDF file. It may be stored on a USB drive, in a state of rest. The
same PDF file may be copied from the USB device, attached to an e-mail, and sent
across the Internet. The PDF then moves across many states of transit as it is
copied from the USB device, to the e-mail server, and travels along networks from
inbox to inbox. Finally, a recipient of the e-mail actually opens the PDF, at which
point the unstructured data is in use—residing in memory, under the control of
an application (such as Adobe Reader), and being rendered to the user who can
interact with the information.

The goal of this chapter is to focus on the challenges of securing unstructured
data in all three of these states and to look at common technologies used to
protect access to, and control over, information. We will look at specific types of
technology and examine newer technologies, such as data loss prevention (DLP)
systems, to see where the trends are going.
The Challenge of Securing Unstructured Data
To illustrate the challenge of securing unstructured data, assume your
organization has an HR application that has a database which maintains
information about each employee, including their annual wage, previous
disciplinary action, and personal data, such as home address and Social Security
number. Like most modern HR applications, it is web based, so when an
authenticated user runs a report, the report is returned from the world of the
structured database into the unstructured world as it is delivered to the web
browser in HTML format. The user of the application can then easily copy and

paste this information from the web browser into an e-mail message and forward
the data onto someone else. As soon as that information is added to the body of
the e-mail, it loses all structure and association with the original application. The
user may also choose to copy and paste only some of the information, change
some of the information, or add new content to the original information. The
person to whom the user sends the e-mail may then copy and paste the
information into a spreadsheet alongside other data. That spreadsheet
information may be used to create a graphical representation of the information,
with some of the original text used as labels on the graph. Very quickly,
information can be changed, restructured, and stored in smaller data formats
such as e-mails, documents, images, videos, and so on.

You might have a very well-defined security model controlling access to the
HR application and the database that contains the HR information. However, the
information needs to be delivered to people or applications for it to be
meaningful. If it gets delivered over a network, you can make sure that access to
the network is secure, yet when the information reaches the user, it can be
transformed into a thousand different formats and sent to dozens of other
applications and networks. Each of the locations where that information may
exist can be secured, and it may be possible to apply access controls to the file
share and control access to the data (content) repositories and the networks in
which they reside; however, your unstructured information may end up
anywhere and thus it is very hard to secure. In fact, it is hard to even locate,
identify, and classify information. Once that HR data ends up deep in an e-mail
thread which accidentally gets forwarded to the wrong audience, it no longer
resembles the well-defined structure of the original data residing in the database.
It has also been duplicated several times as it has traveled from the database to
the inbox of an unauthorized user.

Unstructured data changes are constantly occurring, and data ends up in
places you don’t expect, particularly as the Internet provides an unbelievably
large network of computers that excels in the transfer of unstructured data.
Enormous amounts of money and effort have been invested in building social
networking sites, file sharing and collaboration services, and peer-to-peer
applications that provide endless ways in which a piece of unstructured data can
be distributed within seconds to an audience of billions. It is little wonder that we
frequently read about examples of data loss—now that we’ve created so many
amazing ways to allow information to easily leave our protected borders, our
network controls to stop attackers from accessing our protected data are no
longer sufficient to keep it secure.

Approaches to Securing Unstructured Data

The problem of unstructured data has not gone unnoticed by the security
community; we have access to an array of technologies that are designed to
provide at least partial solutions to the problem of how to secure unstructured
data. While what follows is by no means a complete examination of all the
technologies available, we will examine the most commonly used technologies
and highlight the pros and cons of each. The key areas where unstructured data
can reside can be broken down into the following categories:

• Databases
• Applications
• Networks
• Computers
• Storage
• Physical world (printed documents)

The following sections describe techniques for security data in each of these
locations.
Databases
The database is the center of the data world. The majority of information you are
trying to secure was either created and inserted into, lives in, or has been
retrieved from a database. The most secure database in the world would be one
that nobody could access. It would have no keyboard attached, no network
connected, and no way to remove or add storage devices. Some would even argue
that the machine would also need to be powered off, located in a room without
doors, and be disconnected from any power source. Clearly it would also be the
world’s most useless database, as nobody would be able to actually use the data
stored on it. Therefore, for practical reasons, you have to secure the data within
the database while also allowing legitimate users and applications to access it.

The database was once considered the realm of structured data, but with new
developments in database technology, increasing amounts of unstructured data
are now stored in the database. For example, the database can be the storage
component of a content management system or an application that stores images,
videos, and other unstructured data.

Figure 8-2 shows the typical elements of a database system. In its most basic
form, the database is accessed over a network and a query is run against the
database service. This causes a database process to run and access the data store
to retrieve the queried data, which is then piped back over the network. The data
store can also export data into backups that are restored on development systems
or staging environments. Unstructured data can therefore reside in different
areas of the database—either at rest in the schema in the database data files, in
backups, or sometimes exported to other development or staging databases.

Database security is discussed in further detail in Chapter 12; however, in the
context of unstructured data protection, we are mainly concerned with
encryption, which is discussed next.

Figure 8-2 Information flows into and out of a database.
Encrypting Unstructured Data at Rest in the Database
The most common approach to securing the data in a database is encryption
(described in further detail as a general topic in Chapter 10). Encryption of data
that resides in a database can be approached in various ways:

• Encryption of the actual data itself such that it is stored in normal data files in an
encrypted state. The database doesn’t necessarily know (or care) whether or how
the data is encrypted, so it passes the encrypted data to the application to decrypt.

• Partial encryption of the database schema so that specific rows, columns, or
records are encrypted as a function of the storage of the data. In this case the
database handles the encryption of data and performs the decryption to the
application.

• Full encryption of the database data files such that any information that resides
in them is encrypted.

In the first scenario, the data itself is encrypted. As far as the database is
concerned, it is just storing another big chunk of data. When dealing with
unstructured data, this usually means that the files have been explicitly
encrypted using some type of external technology.

The second and third scenarios are handled completely within the database
platform itself—data is encrypted at rest (and also sometimes in use as it resides
in the memory of the database processes). Oracle and Microsoft use the term
“transparent data encryption” when referring to this sort of data security
because, as far as the application accessing the data is concerned, the information

is unencrypted—the encryption is transparent to the application because the data
is decrypted before the application sees it. These solutions offer a variety of levels
of confidentiality for the data they are protecting. Essentially the goal is to allow
only database or application processes to have access to the decrypted data.
Depending on the method of encryption applied, database exports and backups
can be protected without additional technology. Often, data that needs to be used
in development environments can be declassified by using data masking
technologies that use scrambling or randomization to convert real data into fake
information that still has similar characteristics to the original information.

The biggest problem with the latter two scenarios is that the unstructured data
is only secured while it resides in some part of the database files. When the data
needs to be accessed, it is delivered, usually in unencrypted form, to the querying
application. At that point it’s beyond the reach of any database encryption
solution.
Implementing Controls to Restrict Access to Unstructured Data
In scenarios where the database handles encryption of data and sends the
querying applications the data automatically decrypted, controlling who or what
can connect to the database and perform those queries becomes very important;
this is where database access controls play a key role in restricting access to data.
The approaches that are used by different databases vary, from authentication
with a simple username and password to gain access to a database schema, to a
complex set of rules that define for various levels of data classification who can
access what, from where, at what time, and using what application. Chapter
12 discusses this subject in further detail, along with other aspects of database
security. Often, as access rules become more complex, they provide opportunities
and requirements to determine increasingly complex structures of data
classification and control access to data at a granular level.

The credentials used to authenticate and provide authorization to access data
can either be stored within the database platform or reside within an external
identity directory. This enables the security of data to be associated with the
enterprise directory store, thus creating an easier method for managing the
access control model by using the existing access control infrastructure. For
example, you may have in your identity directory a range of groups with
memberships that reflect access to, say, sales, engineering, and research data. The
capability to associate database permissions with such groups and have logic in
the application return certain records based on those permissions provides a
very effective means of controlling access. By simply moving a user from one
group to another, you impact the access control mechanisms in the application
through to the database.

All the investment in configuring controls to restrict access to the database
still relies on trust that the process that is allowed to access the data is legitimate,
or that the data continues to be secured after it leaves the database.
Securing Data Exports
Many databases provide functionality for the mass export of data into other
databases. This presents security challenges. You may have encrypted the
database files and, using an encrypted backup platform, tied down user access
from the application through to the tables in the database, yet the owner of the
schema of data may still have a range of tools at their disposal to extract and
export data en mass. This activity is often the legitimate transfer of sets of data to
other systems for development purposes. For example, suppose an outsourcing
company is working on new features in your organization’s application and
requires data to work with to test its application changes. A quick e-mail or phone
call by the outsourcing team to the application owner to request an export of a
particular data set, and, bam, in a matter of seconds, a set of your organization’s
data now resides within another system that you have little to no control over.

From an unstructured data perspective, this can be a significant problem,
because the information that resides in database files can be easily shipped from
location to location. For example, the database may well have a set of access
controls that apply only to the production instance and not other instances such
as test and development. In that case, as the data is exported to test or
development, you may lose those controls. That would be equivalent (in the flat-
file world) to copying an entire file share containing hundreds of folders, with
each folder containing confidential files, to some other file share without proper
permissions. All that data suddenly becomes unprotected. Fortunately for people
concerned about the security of those files, that rarely happens. But in the real
world, database exports from one environment to another do occur frequently.

Encryption can be applied at the export phase. This usually is a different
mechanism from that used for the encryption of data in the schema or the
encryption applied to system-wide database backups. When exporting data, it is
usually possible to provide a passphrase to use as the key for the one-time
encryption of a specific data export. This allows sets of data to be protected in
transit because the encrypted export and passphrase are shared separately when
communicated to the user importing the data into their own system.
Challenges in Current Database Security Solutions
Although databases have been around since the late 1970s, they still top the list of
targets for attack. And, as noted earlier, the amount of unstructured data in the
database is constantly increasing. Why is this? Recently, developers have
incorporated into database platforms some clever features that make the storage

of unstructured data more efficient. Take for example de-duplication, a technique
where multiple copies of the same document are automatically detected and
stored only once, with a reference to the original for each copy. Consider a
database that is the back-end storage for a content management system. You may
have a sales presentation uploaded by many different users, and storing 20
copies of the same file would significantly increase storage requirements. By
using de-duplication, you could considerably reduce your storage requirements.
The database may also be able to perform data compression before the database
encrypts the data at rest. So, with more unstructured data residing in the
database, the database becomes a more attractive target for attack. Direct attacks
to the database, indirect attacks via the application, loss of backup tapes, and
poorly managed exports of sensitive data are all common threats today.

The database security methods previously mentioned are all necessary to
provide a reasonable level of security while the data is resident in the database.
However, at some point the data (both structured and unstructured) has to come
out of the database to be presented to trusted applications. That’s really the whole
point of a database—not to store data forever, but to allow that data to be queried
and given to other applications. Those other applications often contain their own
weaknesses and are configured and managed differently, resulting in the
potential for a lack of consistent data protection if those applications are not
properly secured. Thus, we must follow the flow of information as it continues its
journey.
Applications
Unstructured data is typically created in either of two ways: through user activity
on their workstations, or as applications access and manipulate structured data
and reformat it into a document, e-mail, or image. The number of applications is
growing at an amazing rate. With cloud development platforms, it is now a
relatively trivial task to create a collection of data from a wide variety of sources
and consolidate it into a new application. For the purpose of this chapter, our
focus is on web applications. There are many other types of applications, from a
suite of Microsoft Office products to client/server applications that do not
leverage any web-based technology. However, web applications are by far the
most common network-connected application, and their client is non-specific—
it’s a web browser. As such, securing web applications is the greatest challenge.
Secure application development is discussed in more detail in Chapters 26 and 27,
and controlling the behavior of already-written applications is covered
in Chapter 30.

Application security can be categorized into the following groups:

• Application access controls that ensure an identity is authenticated and
authorized to view the protected data, to which that identity is authorized, via the
application

• Network and session security to ensure the connection between the database,
application, and user is secure

• Auditing and logging of activity to provide reporting of valid and invalid
application activity

• Application code and configuration management that ensure code and changes to
the application configuration are secure

This list simplifies application security into some high-level concepts that
allow us to focus on the basic fundamentals of application security. Securing
applications is one of the most important ways to protect data, because
applications are the interface between the end user and the data. As a result a
great deal of the security investment is devoted to the development of the
application. Some companies, such as Microsoft, have a strict software
development lifecycle (SDLC) program to ensure applications are built in a secure
fashion. This approach is often called “secure by design” because security is a key
part of the software development process rather than a set of configurations
applied to the application as an afterthought. When you purchase an application
from a vendor, these aspects of security are typically out of your control;
therefore, you must choose your vendor wisely. If your organization is
developing its own applications, you must ensure that your developers have a
reasonable (and verifiable) level of knowledge about building secure
applications. Preparing for the Certified Information Systems Security
Professional (CISSP) certification exam is often a good starting point to give any
developer grounding in security and the implications to application
development. Chapter 27 of this book describes secure software development in
further detail.
Application Access Controls
Once an application is deployed and running, the first event in the chain of
events leading to access of your unstructured data is when a user attempts to
gain access to the application. Most enterprise-oriented applications have the
ability to integrate with existing identity management infrastructure, which is
considered a best practice. This allows users to authenticate by using credentials
that are already familiar to them. Single sign-on (SSO) mechanisms are typically
beneficial for applications because they provide usability and security and
simplify password management. Once a user has completed the authentication
phase, the application must determine what the user is authorized to do by using

the access control model within the application, which defines who can access
which information or resources.
Network and Session Security
After the application has authenticated the user and knows which data the user is
authorized to access, it must deliver that information when prompted. A wide
range of protocols can be used to secure the transmission of data from the
database to the application and from the application to the end user. A common
protocol for securing data transmissions is Secure Sockets Layer/Transport Layer
Security (SSL/TLS), which encrypts traffic delivered from the server to the client.
Some authentication solutions also extend the security features of authentication
to only allow certain trusted clients. This could, for instance, take the form of
allowing access to the application only by clients using a secure VPN channel or
using a computer that has a certain security patch level and antivirus/anti-
malware instance running. All these technologies are trying to assert a level of
trust for the communication between the application and the client.
Auditing and Logging
Similar to a database, applications can also provide a variety of options for
auditing and logging. This may take place in the code within the application itself,
or the application web server may provide prebuilt auditing functionality that is
available to the application. Again, as with a database, the audit data itself needs
to be secured, as the information being recorded may also be regarded as
sensitive. Security is not limited to protecting the confidentiality of audit data,
though; it extends to protection of audit data from unauthorized changes—that is,
ensuring data integrity. Someone who attacks a system will often attempt to hide
their tracks, and being able to manipulate the audit files is often a very effective
way to remove any evidence of an attack.
Application Code and Configuration Management
It is important to ensure that code and application configuration changes
preserve the security controls and settings and don’t introduce new
vulnerabilities, a configuration management system can be used. Configuration
management systems provide a repository for storing previous versions of
software, as well as controls for the workflow of reviews and approvals needed to
enforce compliance with an organization’s security policies.

Many large applications can also be configured to work with governance, risk
management, and compliance (GRC) software that has fine-grained knowledge of
the application assets as well as the policies the organization wishes to comply
with, providing reporting that verifies compliance with policy. A good example of
a GRC solution in action is ensuring that a doctor who is permitted to prescribe
drugs doesn’t also have the ability to dispense them (separation of duties). GRC

solutions are embedded tightly with applications and can also work alongside
identity management solutions.
Challenges in Current Application Security Solutions
Applications are among the biggest generators of unstructured content, and the
aforementioned security mechanisms highlight the need for a sufficient level of
security to ensure that only authorized users are able to access an application,
pursuant to the principle of least privilege. Securing this trusted connection
ensures that content is delivered to the end user confidentially.

Application security is the most mature and robust area of data security,
because it’s been around longer and has received more attention than other areas
such as networks and computers. The big application vendors who create the sort
of software that runs many large corporations have invested significant time and
effort to secure these applications. Large consulting firms have been built on
their expertise in deploying these applications in secure configurations, and the
applications are surrounded by technologies that secure the communication of
information into and out of the application. Yet in the same manner that a
database has to move information from its secured world and give it to a trusted
application, the application must secure access to, and the transmission of, data
to the end user. A user may well be using the correct authentication credentials
and accessing from a secure network, and may only be given data that is relevant
to their role, but ultimately they are getting access to information that, with
today’s browser-based web applications, they can very easily remove from the
secure confines of the application into the totally unknown and unprotected
world of unstructured content.

This is why organizations continue to experience data loss. Security may be
implemented at the application level, yet once the information goes beyond the
application, there is little or no control over it. As soon as the data is copied
beyond your controlled network, you lose the ability to protect the information.
Networks
Data moves from the protected realm of the database into the application and on
to the end user. Sometimes this communication occurs via a local process, but
often the application and database reside on different servers connected via a
network. The end users are rarely on the same computer that the application and
server reside on. Therefore, the security of the network itself is another area that
we must examine. However, because several other chapters of this book focus on
the subject of network security, the scope of this section is limited to mentioning
some of the technologies designed to secure unstructured data on the network.
These technologies are discussed in more depth in other chapters.

Network security technologies have developed into complex systems that are
able to analyze traffic and detect threats. Network intrusion prevention systems
(NIPSs; see Chapter 18) actively monitor the network for malicious activity and,
upon detection, prevent intrusion into the network. Malware protection
technologies prevent Trojans from deploying and planting back doors on your
trusted network clients. The newest polymorphic advanced persistent threats
(APTs), which steal data, provide back doors to attackers, and cause denial of
service (DoS) attempts, can be blocked using solutions that detect illegitimate
traffic and deny it.

All of the network security techniques described in Part IV of this book can be
used to secure network communications. However, network security solutions
are not able to protect information that has already left the network; they can
only detect the unauthorized transmission of data and deny it from going any
further.
Challenges in Current Network Security Solutions
Again, as with application security for unstructured data, the biggest challenge
with network security for unstructured data is that once a trusted user or client is
connected to the network, the network will freely pass to that user or client any
information they are authorized to access. You might be using advanced
techniques to monitor traffic flows, but to enable business, you still need to allow
information to flow. For example, suppose you need to secure information in
collaboration with a new business partner. Suppose further that you’ve created a
secure network between the two businesses and integrated it with the identity
management systems to only authenticate legitimate users at the partner
business to access your networked applications. Over this network will flow
many pieces of valuable information, securely. However, when that information
reaches the partner, it will no longer be bound within your nicely secured
network and may exist in the clear, meaning it can be easily lost or misused. If
something goes wrong, such as loss of data, you may have nothing but audit
records showing who from the partner business accessed that data. Those may be
useful in figuring out what went wrong, but any measures you take in response
will always be reactive, after the damage has already been done.

Two growing trends in the modern business environment are to move to
cloud-based services and to expand external collaboration in the form of
outsourcing, partner alliances, and increased customer access to company
information. This has resulted in the creation of various methods for connecting
your corporate network to several sources, further complicating the problem of
security. Data flows across networks to the application and from the application

over the network to the database. Network security solutions should be used to
provide the best possible protection to this data.
Computers
Once a legitimate user has securely connected across the network to the
application to access data residing in the database, the information is ultimately
presented in a web page that is rendered by a web browser. From there, the user
can move the data to an unstructured and unprotected location, such as a PDF file
or an Excel spreadsheet, and then download and store the data on the local drive
of a desktop workstation. Therefore, the security on the computer from which the
user interacts with the application and resulting unstructured content becomes
critical. Essentially, the computer is the front line in the battleground of
information security today.

Servers are usually limited in number and physically under your control, or at
least under the control of your cloud services provider. Networks and their
gateways are also limited in number and usually within your control. But end-
user computers may number in the hundreds or thousands and may often be
beyond your security control. Furthermore, those computers may be running a
large number of platforms, a wide variety of OS versions, and a wide variety of
software, and may be used by a wide variety of people. Everything we do with
information happens on the computer, which means the security of that
computer is critical to the ongoing security of your information. Within the
context of the security of unstructured content on computers, we will focus on
only a few areas:

• Ensuring that only legitimate users can access the computer (identity access
control)

• Controlling the flow of information over network interfaces and other
information connection points (USB, DVD, etc.)

• Securing data residing at rest on the computer
Identity Access Control
All operating systems have some form of user access control. The most basic (and
common) form is a username and password combination that is validated against
a local identity store. Successfully authenticated users are then granted a session
to the system, which then manages access to resources, typically by using an
access control list (ACL). In business environments, computers under the control
of the organization are configured to authenticate and grant sessions to users
whose identities are stored in a centralized identity management system. The
most prevalent identity management system is Microsoft Active Directory, which
natively manages access to Windows clients but is also often extended to the

management of Unix-based workstations. (Access control is covered in further
detail in Chapter 7.)

It is this identity that is associated with any unstructured data on the system.
Unfortunately, once a piece of unstructured data resides on a computer, any
security mechanism that controls access to it on the system is longer effective.
Thus, the identity that is used in the computer access may have little effect on the
actual access controls to local content. Some technologies are able to shrink the
access control layer to the content itself, and that is the subject of the following
chapter.
Controlling the Flow of Data over Networks and Connected Devices
Once a user is authenticated and provided with a session, they are able to
proceed to access the network, read data on the local hard disk, and connect USB
and other storage devices and transfer data to and from the computer. Privileges
to perform these actions are implemented by the local computer, which in turn,
with technologies like Active Directory, conforms to a central policy that defines
what users are able to do on their desktops.

From the unstructured data perspective, all these connections are simply
pipes through which information can travel, from one to the next. Each pipe may
have its own security model, but each model applies security to the unstructured
data only while it travels through the associated pipe.
Securing Data at Rest
Once they are logged in to a computer, most users in organizational
environments start working with data that is often stored locally on the host
device. It might, for example, take the form of a Word document saved from an e-
mail to the desktop; or it might be a PDF file cached by your browser as it
displays it from a web page. Even smartphones are computers that are able to
store massive amounts of data and run business software that allows the use of
unstructured data. Security for storage devices, as described in Chapter 11,
becomes important at this stage.
Challenges in Current Computer Security Solutions
Computers represent the interaction of humans and computers. Much effort goes
into creating a level of trust between the person and the computer. Usernames,
passwords, security token keys, smart cards, fingerprint scanners, various
biometric devices, and other mechanisms all attempt to ensure the computer
knows that the person is who they claim to be. Yet once this trust has been
established, information is allowed to flow freely. This trust in the human at the
keyboard often fails. Humans send e-mails by accident, lose USB keys, print
confidential information and leave it lying around, and sometimes even steal
data intentionally.

Consistently securing information in use on computers is one of the biggest
challenges facing the information security community today. Yet the computer is
the perfect place to start educating the end user on the importance of security.
There are mature solutions for different aspects of computer security. Anti-
malware technologies have been on the market for over a decade, and storage
encryption is in a fairly well-defined space. The challenge is to integrate the
various endpoint technologies to accurately support your security policies.
Storage (Local, Removable, or Networked)
Once on the computer, information either exists in a dynamic state, in the
memory of a running process (for example, with a web browser or software
application), or is stored in an unstructured form on the hard disk or a removable
drive (for example, in a file located in a local folder).

Storage is one of the most effective areas of unstructured data security and is
often the one which receives the most attention after a data loss incident. Storage
security solutions mainly deal with data at rest, but sometimes stored data exists
in another state, either in transit or in use. An example of this is the contents of a
PDF file that is stored in RAM and paged to the disk by the operating system. Is
this data at rest or in use? (An interesting court case that hinged on the
distinction between “at rest” and “in use” was mentioned in Chapter 3.) Typically,
storage security solutions focus on encryption or access control. These subjects
are covered in more detail in Chapter 7, but let’s consider the strengths and
weaknesses of encryption (detailed in Chapter 10) further before we move on.
Encryption of Storage
The most common “go to” security tactic for anyone who has suffered a data
breach, failed an audit, or just wants to be proactive is to “encrypt everything”
because that seems to be the easiest and most comprehensive approach. This is
mainly because databases, network storage, content management systems, and
computers ultimately end up storing data on storage devices like hard disk arrays
or USB flash memory, so encrypting these locations is an obvious solution.
Methods of encryption on storage devices fall into two categories:

• Disk encryption (either hardware based or software based)
• File-system encryption

Disk Encryption Hardware disk encryption is totally transparent to the
operating system and, therefore, to applications and users on the computer. This
means storing a piece of unstructured data on the disk is simple and requires no
change to the operating system, the application, or the content format.

Some form of authentication must take place before any data on the drive can
be decrypted and read. When full disk encryption is performed using software,
the operating system must have some form of unencrypted partition from which

to boot and in turn authenticate the system to gain access to the cryptographic
keys to decrypt the main encrypted disks.

Both hardware and software methods provide the encryption of data as it is
written to disk across the entire disk. The methods are totally transparent to the
processes (other than, of course, those in the operating system that may be
managing the encryption/ decryption), and as data is read from disk, it is seen by
applications in its decrypted state. One downside of hardware-based disk
encryption is that the management of the cryptographic keys can be difficult.
File-System Encryption Another method of encrypting data at rest is to
implement the functionality in the file system itself. This means that the methods
may vary depending on the operating system in use. Typically, the main
difference is that file and folder encryption only secures files and folders, not the
metadata. In other words, an unauthorized person is able to list the files, view the
filenames, and see the user and group ownerships, but they cannot actually
access the files themselves without the cryptographic keys. (An exception is the
ZFS file system, which does encrypt metadata.)

File-system encryption, like disk encryption, only applies when the content
resides in a location that is encrypted. If the data is moved from the encrypted
disk to a disk that’s unencrypted, it is no longer protected.
Challenges in Current Storage Security Solutions
Storage encryption and access controls are common in many organizations, yet
occurrences of data loss continue to increase, even from environments that have
these types of solutions. As mentioned, encryption only works at the source.

Storage access controls are clearly necessary. You need a level of control over
users’ access to information on local computers or networked file shares.
However, the limitations of these access controls are very quickly reached.
Imagine the simple scenario of two folders on a network file share, “All Company
– Public” and “Confidential – Engineering.” You may have defined a tight set of
engineering groups who have access to the latter, while allowing anyone in the
company, maybe even outsiders, to access the former. It only takes the single act
of a trusted engineer to accidentally store a few confidential documents in the
“All Company – Public” folder to render the access controls for that information
completely ineffective. Location-based access controls like this only provide
control for the location where the information resides; information moves
everywhere, but the security defined at the location does not travel with it.
Data Printed into the Physical World
A lot of time and effort is devoted to finding solutions for securing unstructured
data in the digital world; however, data loss incidents due to the loss or
inappropriate disposal of paper documents must also be considered—that is,

finding solutions for how to secure information in the hardcopy world.
Considering data in paper form as unstructured content is also another way to
visualize how structured data can easily pass into the unstructured world. You
print it out.

Encryption typically doesn’t help when printing information because the
information needs to be readable to humans. Instead, methods such as
watermarks and redaction are used. Watermarks leave identifying data (like a
background image or word) in the printed copies in an attempt to alert users to
the importance of the information and try to reduce the chances they are
negligent with the data. Redaction is the process of editing or blacking out certain
text in a document such that certain sensitive parts of a document are not visible.
Redaction often applies to the visibility of both the digital document and the
resulting printed version. Risks are introduced when information is not redacted
sufficiently, or the wrong data is redacted. For example, the U.S. Transportation
Security Administration (TSA) in 2009 posted a PDF online that had been redacted
in an ineffective way such that the blacked-out areas could be easily viewed
simply by copying the content and pasting it into another document.

The computer industry has been promising the paperless office for many
years, and although we collectively generate a great deal less paper than we used
to, paper has definitely not gone away. Many data breach incidents are the result
of poor disposal of physical paper records.

Physically printed copies of documents can pose risks just as great as those
posed by their digital counterparts. A user could print a spreadsheet and send it
via fax or mail to an unauthorized party. No information security technology that
exists in the digital domain is ever going to detect, secure, and control access to
the information when it is printed on paper. You can identify every single place
that digital information is going to live and encrypt those locations, but that
encryption has no effect on a paper-based copy. Thus, the best practices for
handling printed documents are limited to restriction of the contents printed,
along with reliance on human vigilance.

Before being printed, all confidential documents should have any non-
essential contents hidden or deleted, so unnecessary confidential information is
not included in the printout.

All printed confidential documents should have a front cover page, so their
contents are not visible from a casual glance. Also ensure that all pages have page
numbers (so any missing pages can be detected) and watermarks along with
headers and footers identifying the confidentiality level of the document.

Each copy of an entire document should be labeled, to aid in tracking each
copy. And confidential printouts should never be taken home, to a restaurant or

any public place, or anywhere outside of the controlled environment they’re
meant to be in.

Confidential documents should be printed to a private printer, whenever
possible, instead of to shared printers located in common areas. When this is not
possible, the person who prints the material should go directly to the printer,
watch it print, and collect the output immediately. Confidential documents should
never be left unattended, even for a short time.

All paper documents containing confidential information should be locked in
a secured container such as a desk drawer or file cabinet. They should never be
left sitting on top of a desk, even for a short time.

When no longer needed, documents should be immediately shredded or
placed in a secure container for a shredding service to destroy. The quality of
shredding is important—older “strip shredders” that simply cut pages into
individual strips are surprisingly easy to put back together. Crosscut shredders
cut in more than one direction, resulting in diamond-shaped pieces that are much
more difficult to reconstruct.

The Handbook for Safeguarding Sensitive Personally Identifiable
Information published by the U.S. Department of Homeland Security provides
some further guidelines for secure handling of hardcopy:

• When faxing data, make the recipient aware that a fax is about to be sent, so the
recipient will be aware that they need to go collect the fax right away.

• When sending mail, verify that the correct recipient received the delivery. Also
make sure the envelope is opaque so the contents inside are not visible. Use
tracking information to see where the delivery goes, via a delivery service that
provides Return Receipt, Certified or Registered mail, or a tracking service.

Finally, and as always, common sense should be used by the people who
handle paper copies of documents, because so much of document security is
dependent on human behaviors. People handing out confidential documents
need to make sure they know who they are giving copies to, and keep track of
those copies. They should also be responsible for collecting and destroying those
copies when done. A good example is a handout used in a meeting as a reference.
After the meeting is concluded, the meeting organizer should make sure to take
back the handouts, and remind everyone about their confidentiality. How do you
enforce good behaviors like this? The best way is to ingrain the desired behaviors
in the overall culture of the environment, through consistent messaging and
repetition via a security awareness program (as was discussed further in Chapter
5).

Newer Approaches to Securing Unstructured
Data
The previous sections of this chapter described various techniques for securing
unstructured data in individual environments, which may be thought of as “point
solutions.” These techniques emerged from security requirements of individual
use cases, and each is focused on the capabilities and limitations of the
environment to which it pertains. Newer approaches to unstructured data
security are broader in scope, more data-centric, and less platform-dependent.
The following sections describe these newer approaches, and how they can be
used to complement the security capabilities mentioned above.
Data Loss Prevention (DLP)
Data loss prevention (DLP) refers to a relatively new group of technologies
designed to monitor, discover, and protect data. You might also hear this
technology referred to as data leak prevention—and sometimes it’s also referred
to with the word protection instead of prevention. In any case, DLP is like a
“firewall for your data.” There is a wide variety of DLP solutions on the market,
which typically can be broken down into three types:

• Network DLP Usually a network appliance that acts as a gateway between major
network perimeters (most commonly between your corporate network and the
Internet). Network DLP monitors traffic that passes through the gateway in an
attempt to detect sensitive data and do something about it, typically block it from
leaving the network.

• Storage DLP Software running either on an appliance or directly on the file
server, performing the same functions as network DLP. Storage DLP scans
storage systems looking for sensitive data. When found, it can delete it, move it to
quarantine, or simply notify an administrator.

• Endpoint DLP Software running on endpoint systems that monitors operating
system activity and applications, watching memory and network traffic to detect
inappropriate use of sensitive information.

Network, storage, and endpoint DLP are often used together as part of a
comprehensive DLP solution to meet some or all of the following objectives:

• Monitoring Passive monitoring and reporting of network traffic and other
information communication channels such as file copies to attached storage

• Discovery Scanning local or remote data storage and classifying information in
data repositories or on endpoints

• Capture Storage of reconstructed network sessions for later analysis and
classification/policy refinement

• Prevention/blocking Prevention of data transfers based on information from the
monitoring and discovery components, either by interrupting a network session
or by interacting with a computer via local agents to stop the flow of information

DLP solutions may comprise a mixture of the above, and almost all DLP
solutions leverage some form of centralized server where policies are configured
to define what data should be protected and how.
Challenges in DLP Solutions
If the DLP solution isn’t monitoring a particular storage device or network
segment, or if a particular file doesn’t have the right policy associated with it,
then the DLP solution cannot enforce the right level of protection. This means
that every network segment, file server, content management system, and
backup system must be covered by a component of the DLP technology along
with proper classification of all documents critical to its success. Proper
configuration of the DLP environment and policies is a big task, and overlooking
one (or more) aspects can undermine the whole system.

DLP only makes point-in-time decisions. Consider, for example, a DLP policy
that allows users to send confidential data to a trusted partner. Six months later
the organization decides this partner is too expensive, and sets up an agreement
with another, cheaper partner. You then reconfigure the DLP policy to reflect this
change in the business relationship, but the DLP solution has no ability to affect
all the information that has flowed to the old partner. Data may now reside with
a partner who will soon be signing an agreement with your competitor.

The way in which a DLP solution deals with policy violations has limitations.
Prevention is part of its name, and for good reason—when a user is copying a file
or e-mail, the DLP solution prevents copying of information that it deems
illegitimate. This may initially seem like a good outcome, but what if your CEO is
giving an important presentation and wants to copy a file to an unencrypted USB
stick to share a marketing presentation with the board of directors? DLP might
block that. What if you want to e-mail an important document to your home e-
mail address to work on over the weekend? Nope, DLP blocks it and informs the
IT security group. While DLP has many advantages, it may impact business
processes and productivity if all possible scenarios are not considered.

DLP is also capable of generating a certain number of false positives (and false
negatives), which makes fully implementing all blocking/prevention components
a risky exercise. Even when the accuracy of policy enforcement is very high,
organizations often find the disruption to business so high that they prefer a
monitoring-only implementation.

Despite these problems, DLP is still an excellent tool for hunting down and
monitoring the movement of sensitive data. It can provide very valuable insight

into the information flows within the network and, at a minimum, can highlight
where illegitimate activity takes place or where sensitive information is stored in
open file shares. The reports from DLP network monitoring and discovery
components provide a useful feedback loop: identifying compliance “hot spots”
and poor working practices, mapping the proliferation of sensitive content
throughout (and beyond) your enterprise, and enabling organizations to tune
their existing access control systems. But keep in mind that you will need to add
additional trained staff to reap all of the benefits of the DLP solution. A significant
increase in workload is required to examine and act on all the alerts coming from
the DLP solution, including false alerts.
Information Rights Management (IRM)
Information rights management (IRM) is a relatively new technology that builds
protection directly into the data files, regardless of where they are stored and
where they are transmitted and used. IRM evolved from digital rights
management (DRM), which is used in the entertainment industry to protect music
and movies and apply protection to all kinds of data. IRM uses a combination of
encryption and access controls to allow authorized users to open files, and to
block unauthorized users. With IRM, files are encrypted using strong encryption
techniques. When a request is made to open the file and decrypt the data,
software is required to check with a central authentication server (usually
somewhere on the Internet) and, via a reliable handshake mechanism, determine
whether the requesting user is allowed to unlock the data.

IRM solutions go even further than providing access to the data; they control
the ability to copy, paste, modify, forward, print, or perform any other function
that a typical end user would want to perform. This provides a granular level of
control over files that can’t be provided by any other single security technology.
Thus, IRM can be a valuable tool in the security toolbox. Continue to the next
chapter to learn much more about this promising technology.

Summary
As defined in this chapter, unstructured data is any collection of electronic
information that does not follow a strict format (and therefore lacks any inherent
security controls). Unstructured data by itself is wide open and unprotected. This
data may reside in databases, applications, networks, computers, storage, and
even the physical world. And, it is growing at a pace faster than that of structured
data, which typically has inherent security controls.

Structured data is relatively easy to secure compared to unstructured data,
which exists in three states at various times: at rest, in transit, and in use.
Unstructured data is found in applications, networks, computers, storage systems,

and even inside structured databases. And once that data is printed into the
physical world, it can no longer be controlled by the software-based security
technologies applied to the original source data. This chapter provided an
overview of a range of security technologies for securing unstructured data in all
of these locations, including the limitations of those technologies.

With regard to applications, we discussed the use of access controls, network
and session security, auditing and logging, and configuration management to
protect unstructured data at rest. For the network, we identified that you can use
all of the network security technologies described in Part IV of this book to
protect data in transit. On computers, we covered ensuring that only authorized
users can access the data, controlling the flow of that data, and securing the data
at rest on the computer. On storage systems, we mentioned access controls and
discussed encryption in more detail. We looked at securing unstructured data
within databases through the use of encryption. In the physical world, we
reviewed the challenges and best practices for handling paper copies of
confidential information. And finally, we talked about two newer technology
solutions: data loss prevention (DLP), and information rights management (IRM)
as solutions to protecting unstructured data.

There is a common thread to these technologies and what they attempt to
achieve: ensuring that only authenticated and authorized users can access
secured data, and that bypassing the access control protecting that data isn’t easy.
These technologies also share a common challenge: they need to be implemented
in the proper places, and even when they are, if the information travels beyond
your perimeter of control, you lose control over that information and visibility of
where it goes thereafter. As with most security models, layering of various
security controls helps to close the gap by providing a defense-in-depth approach
to security.

References
Birru, Amha. Secure Web Based Voting System for the Case of Addis Ababa City:
Securing Vote Data at Poll Stations, In the Wire and Data at Rest. VDM Verlag,
2009.
ICON Group International. The 2011–2016 Outlook for Information Data Loss
Prevention (DLP) Appliances in the United States. ICON Group International, 2011.
Kenan, Kevin. Cryptography in the Database: The Last Line of Defense. Addison-
Wesley, 2005.
National Institute of Standards and Technology. NIST Special Publication 800-111:
Guide to Storage Encryption Technologies for End User Devices. NIST,
2007. http://csrc.nist.gov/publications/nistpubs/800-111/SP800-111.pdf

Photopoulos, Constantine. Managing Catastrophic Loss of Sensitive Data. Syngress,
2008.
U.S. Department of Homeland Security. Handbook for Safeguarding Sensitive
Personally Identifiable
Information. http://www.dhs.gov/xlibrary/assets/privacy/privacy_guide_spii_hand
book.pdf.
U.S. Government. Guide to Storage Encryption Technologies for End User Devices.
Books, LLC, 2011.

CHAPTER

7
Authentication and
Authorization

One of the most common ways to control access to computer systems is to
identify who is at the keyboard (and prove that identity), and then decide what
they are allowed to do. These twin controls, authentication and authorization,
respectively, ensure that authorized users get access to the appropriate
computing resources, while blocking access to unauthorized users.
Authentication is the means of verifying who a person (or process) is, while
authorization determines what they’re allowed to do. This should always be done
in accordance with the principle of least privilege—giving each person only the
amount of access they require to be effective in their job function, and no more.

Authentication
Authentication is the process by which people prove they are who they say they
are. It’s composed of two parts: a public statement of identity (usually in the form
of a username) combined with a private response to a challenge (such as
a password). The secret response to the authentication challenge can be based on
one or more factors—something you know (a secret word, number, or passphrase
for example), something you have (such as a smartcard, ID tag, or code
generator), or something you are (like a biometric factor like a fingerprint or
retinal print). A password by itself, which is a means of identifying yourself
through something only you should know (and today’s most common form of
challenge response), is an example of single-factor authentication. This is not
considered to be a strong authentication method, because a password can be
intercepted or stolen in a variety of ways—for example, passwords are frequently
written down or shared with others, they can be captured from the system or the
network, and they are often weak and easy to guess.

Imagine if you could only identify your friends by being handed a previously
agreed secret phrase on a piece of paper instead of by looking at them or hearing
their voice. How reliable would that be? This type of identification is often
portrayed in spy movies, where a secret agent uses a password to impersonate
someone the victim is supposed to meet but has never seen. This trick works
precisely because it is so fallible—the password is the only means of identifying
the individual. Passwords are just not a good way of authenticating someone.

Unfortunately, password-based authentication was the easiest type to implement
in the early days of computing, and the model has persisted to this day.

Other single-factor authentication methods are better than passwords. Tokens
and smart cards are better than passwords because they must be in the physical
possession of the user. Biometrics, which use a sensor or scanner to identify
unique features of individual body parts, are better than passwords because they
can’t be shared—the user must be present to log in. However, there are ways to
defeat these methods. Tokens and cards can be lost or stolen, and biometrics can
be spoofed. Yet, it’s much more difficult to do that than to steal or obtain a
password. Passwords are the worst possible method of proving an identity,
despite being the most common method.

Multifactor authentication refers to using two or more methods of checking
identity. These methods include (listed in increasing order of strength):

• Something you know (a password or PIN code)
• Something you have (such as a card or token)
• Something you are (a unique physical characteristic)

Two-factor authentication is the most common form of multifactor
authentication, such as a password-generating token device with an LCD screen
that displays a number (either time based or sequential) along with a password,
or a smart card along with a password. Again, passwords aren’t very good choices
for a second factor, but they are ingrained into our technology and collective
consciousness, they are built into all computer systems, and they are convenient
and cheap to implement. A token or smart card along with biometrics would be
much better—this combination is practically impossible to defeat. However, most
organizations aren’t equipped with biometric devices.

The following sections provide a more detailed introduction to these types of
authentication systems available today:

• Systems that use username and password combinations, including Kerberos
• Systems that use certificates or tokens
• Biometrics

Usernames and Passwords
In the familiar method of password authentication, a challenge is issued by a
computer, and the party wishing to be identified provides a response. If the
response can be validated, the user is said to be authenticated, and the user is
allowed to access the system. Otherwise, the user is prevented from accessing the
system.

Other password-based systems, including Kerberos, are more complex, but
they all rely on a simple fallacy: they trust that anyone who knows a particular

user’s password is that user. Many password authentication systems exist. The
following types of systems are commonly used today:

• Local storage and comparison
• Central storage and comparison
• Challenge and response
• Kerberos
• One-time password (OTP)

Each type of system is discussed in turn next.
Local Storage and Comparison
Early computer systems did not require passwords. Whoever physically
possessed the system could use it. As systems developed, a requirement to restrict
access to the privileged few was recognized, and a system of user identification
was developed. User passwords were entered in simple machine-resident
databases by administrators and were provided to users.

Often, passwords were stored in the database in plaintext format
(unencrypted), because protecting them wasn’t really a high priority. Anyone
who was able to open and read the file could determine what anyone else’s
password was. The security of the database relied on controlling access to the file,
and on the good intentions of all the administrators and users. Administrators
were in charge of changing passwords, communicating changes to the users, and
recovering passwords for users who couldn’t remember them. Later, the ability
for users to change their own passwords was added, as was the ability to force
users to do so periodically. Since the password database contained all
information in plaintext, the algorithm for authentication was simple—the
password was entered at the console and was simply compared to the one in the
file.

This simple authentication process was, and still is, used extensively for off-
the-shelf and custom applications that require their own internal authentication
processes. They create and manage their own stored-password file and do no
encryption. Security relies on the protection of the password file. Because
passwords can be intercepted by rogue software, these systems are not well
protected.
Securing Passwords with Encryption and Securing the Password File In time,
a growing recognition of the accessibility of the password file, along with some
high-profile abuses, resulted in attempts to hide the password file or strengthen
its defense. In early Unix systems, passwords were stored in a file called
/etc/passwd. This file was world-readable (meaning that it could be opened and
read by all users) and contained all the passwords in encrypted form.
Nevertheless, the encryption was weak and easy to defeat. Blanking the password

field (possible after booting from a CD) allowed a user to log in with no password
at all. Again, after several highly publicized compromises, the system was
redesigned to what it is today. In most modern Unix systems, the usernames are
stored in the /etc/passwd file but the passwords are stored in a separate file,
known as a shadow password file and located in /etc/shadow. It contains the
encrypted passwords and is not world-readable. Access is restricted to system
administrators, thus making an attack from a regular user account more difficult.

Much like early Unix systems, early versions of Windows used easily
crackable password (.pwd) files. Similarly, Windows NT passwords were saved in
the Security Account Manager (SAM), which could be modified to change the
passwords contained in it, or subjected to brute-force attacks to obtain the
passwords. Later versions of Windows added the syskey utility, which added a
layer of protection to the database in the form of additional encryption. However,
attack tools were created that could be used to extract the password hashes from
syskey-protected files.

Numerous freely available products can crack Windows and Unix passwords.
Two of the most famous are LC4 (formerly known as LOphtCrack) and John the
Ripper. These products typically work by using a combination of attacks: a
dictionary attack (using the same algorithm as the operating system to hash
words in a dictionary and then compare the result to the password hashes in the
password file), heuristics (looking at the things people commonly do, such as
create passwords with numbers at the end and capital letters at the beginning),
and brute force (checking every possible character combination).

Another blow to Windows systems that are protected by passwords is the
availability of a bootable Linux application that can replace the Administrator’s
password on a stand-alone server. If an attacker has physical access to the
computer, they can take it over—though this is also true of other operating
systems using different attacks.

Protection for account database files on many operating systems was
originally very weak, and may still be less than it could be. Administrators can
improve security by implementing stronger authorization controls (file
permissions) on the database files.

In any case, ample tools are available to eventually compromise passwords if
the machine is in the physical possession of the attacker, or if the attacker can
obtain physical possession of the password database. That’s why every system
should be physically protected. Centralized account databases and authentication
systems should be protected with extra precautions. In addition, user training
and account controls can strengthen passwords and make the attacker’s job
harder—perhaps hard enough that the attacker will move on to easier pickings.

Today, many off-the-shelf applications now use the central authentication
system already in use by the organization, such as Lightweight Directory Access
Protocol (LDAP) or Active Directory. They rely on the existing credentials of the
user, instead of maintaining their own password databases. This is much better
from a security standpoint, as well as easier for the end users. Single sign-on
(SSO) allows users to authenticate to applications using their current credentials,
without being challenged, which improves the user experience.
Central Storage and Comparison
When passwords are encrypted, authentication processes change. Instead of
doing a simple comparison, the system must first take the user-entered, plaintext
password and encrypt it using the same algorithm used for its storage in the
password file. Next, the newly encrypted password is compared to the stored
encrypted password. If they match, the user is authenticated. This is how many
operating systems and applications work today.

How does this change when applications are located on servers that client
workstations must interface with? What happens when centralized account
databases reside on remote hosts? Sometimes the password entered by the user is
encrypted, passed over the network in this state, and then compared by the
remote server to its stored encrypted password. This is the ideal situation.
Unfortunately, some network applications transmit passwords in cleartext—
telnet, FTP, rlogin, and many others do so by default. Even systems with secure
local, or even centralized, network logon systems may use these and other
applications which then transmit passwords in cleartext. If attackers can capture
this data in flight, they can use it to log in as that user. In addition to these
network applications, early remote authentication algorithms (used to log in via
dial-up connections), such as Password Authentication Protocol (PAP), also
transmit cleartext passwords from client to server.
What’s in a Hash?
A hash function is a mathematical formula that converts a string of characters
(text or numbers) to a numeric code (commonly called a hash). These functions
are very important to encryption methods, and thus to authentication systems
that require something (like a password) to be hidden. They’ve been around since
the 1970s.

In theory, a hash is one-way code, which means you can create it, but not
reverse it. It’s like being able to encrypt something without being able to decrypt
it. How is this useful? When one computer creates a hash, another computer can
use exactly the same inputs to create another hash, and compare the two. If they
match, the inputs are the same.

In practice, modern hashes can be cracked using advanced techniques. But
they are still some of the most useful tools we have for obfuscating data.

Secure Hash Algorithm version 1 (SHA-1) and Message Digest version 5 (MD5)
are the most widely known modern hash functions.
CHAP and MS-CHAP
One solution to the problem of securing authentication credentials across the
network so they are not easily intercepted and replayed is to use the challenge
and response authentication algorithms Challenge Handshake Authentication
Protocol (CHAP, described in RFC 1994) and the Microsoft version, MS-CHAP (RFC
2433). These protocols use the Message Digest version 5 (MD5). The server that
receives the request for access issues a challenge code, and the requestor
responds with an MD5 hash of the code and password. The server then compares
that hash to its own hash made from the same code and password. If they are the
same, the user is authenticated.

In addition to more secure storage of credentials, version 2 of MS-CHAP
(MSCHAPv2, described in RFC 2759) requires mutual authentication—the user
must authenticate to the server, and the server must also prove its identity. To do
so, the server encrypts a challenge sent by the client. Since the server uses the
client’s password to do so, and only a server that holds the account database in
which the client has a password could do so, the client is also assured that it is
talking to a valid remote access server. This is a stronger algorithm, although it is
not unbreakable. MSCHAPv2 has been found to be vulnerable to brute force
attacks that can be performed within a timeframe of minutes to hours on modern
hardware.
Kerberos
Kerberos is a network authentication system based on the use of tickets. In the
Kerberos standard (RFC 1510), passwords are key to the system, but in some
systems certificates may be used instead. Kerberos is a complex protocol
developed at the Massachusetts Institute of Technology to provide authentication
in a hostile network. Its developers, unlike those of some other network
authentication systems, assumed that malicious individuals as well as curious
users would have access to the network. For this reason, Kerberos has designed
into it various facilities that attempt to deal with common attacks on
authentication systems. The Kerberos authentication process follows these steps,
which are illustrated in Figure 7-1:

Figure 7-1 The Kerberos authentication system uses tickets and a multistep process.

1. A user enters their password.
2. Data about the client and possibly an authenticator is sent to the server. The

authenticator is the result of using the password (which may be hashed or
otherwise manipulated) to encrypt a timestamp (the clock time on the client
computer). This authenticator and a plaintext copy of the timestamp accompany
a login request, which is sent to the Kerberos authentication server (AS)—this is
the KRB_AS_REQ message. This is known as pre-authentication and may not be
part of all Kerberos implementations.

NOTE Typically, both the AS and the Ticket Granting Service (TGS) are part of the
same server, as is the Key Distribution Center (KDC). The KDC is a centralized
database of user account information, including passwords. Each Kerberos realm
maintains at least one KDC (a realm being a logical collection of servers and
clients, comparable to a Windows domain).

3. The KDC checks the timestamp from the workstation against its own time. The
difference must be no more than the authorized time skew (which is five
minutes, by default). If the time difference is greater, the request is rejected.

4. The KDC, since it maintains a copy of the user’s password, can use the password
to encrypt the plaintext copy of the timestamp and compare the result to the
authenticator. If the results match, the user is authenticated, and a ticket-granting
ticket (TGT) is returned to the client—this is the KRB_AS_REP message.

5. The client sends the TGT to the KDC with a request for the use of a specific
resource, and it includes a fresh authenticator. The request might be for
resources local to the client computer or for network resources. This is the
KRB_TGS_REQ message, and it is handled by the TGS.

6. The KDC validates the authenticator and examines the TGT. Since it originally
signed the TGT by encrypting a portion of the TGT using its own credentials, it
can verify that the TGT is one of its own. Since a valid authenticator is present,
the TGT is also less likely to be a replay. (A captured request would most likely

have an invalid timestamp by the time it is used—one that differs by more than
the skew time from the KDC’s clock.)

7. If all is well, the KDC issues a service ticket for the requested resource—this is the
KRB_TGS_REP message. Part of the ticket is encrypted using the credentials of the
service (perhaps using the password for the computer account on which the
service lies), and part of the ticket is encrypted with the credentials of the client.

8. The client can decrypt its part of the ticket and thus knows what resource it may
use. The client sends the ticket to the resource computer along with a fresh
authenticator. (During initial logon, the resource computer is the client computer,
and the service ticket is used locally.)

9. The resource computer (the client) validates the timestamp by checking whether
the time is within the valid period, and then decrypts its portion of the ticket. This
tells the computer which resource is requested and provides proof that the client
has been authenticated. (Only the KDC would have a copy of the computer’s
password, and the KDC would not issue a ticket unless the client was
authenticated.) The resource computer (the client) then uses an authorization
process to determine whether the user is allowed to access the resource.

In addition to the authenticator and the use of computer passwords to encrypt
ticket data, other Kerberos controls can be used. Tickets can be reused, but they
are given an expiration date. Expired tickets can possibly be renewed, but the
number of renewals can also be controlled.

In most implementations, however, Kerberos relies on passwords, so all the
normal precautions about password-based authentication systems apply. If the
user’s password can be obtained, it makes no difference how strong the
authentication system is—the account is compromised. However, there are no
known successful attacks against Kerberos data available on the network. Attacks
must be mounted against the password database, or passwords must be gained in
an out-of-bounds attack (social engineering, accidental discovery, and so on).
One-Time Password Systems
Two problems plague passwords. First, they are (in most cases) created by people.
Thus, people need to be taught how to construct strong passwords, and most
people aren’t taught (or don’t care enough to follow what they’re taught). These
strong passwords must also be remembered and not written down, which means,
in most cases, that long passwords cannot be required. Second, passwords do
become known by people other than the individual they belong to. People do
write passwords down and often leave them where others can find them. People
commonly share passwords despite all your warnings and threats.

Passwords are subject to a number of different attacks. They can be captured
and cracked, or used in a replay attack in which the passwords are intercepted
and later used to repeat authentication.

One solution to this type of attack is to use an algorithm that requires the
password to be different every time it is used. In systems other than computers,
this has been accomplished with the use of a one-time pad. When two people need
to send encrypted messages, if they each have a copy of the one-time pad, each
can use the day’s password, or some other method for determining which
password to use. The advantage, of course, to such a system is that even if a key is
cracked or deduced, it is only good for the current message. The next message
uses a different key.

How, then, can this be accomplished in a computer system? Two current
methods that use one-time passwords are time-based keys and sequential keys.
Time-Based Keys Time-based keys use hardware- or software-based
authenticators that generate a random seed based on the current time of day.
Authenticators are either hardware tokens (such as a key fob, card, or pinpad) or
software. The authenticators generate a simple one-time authentication code that
changes every 60 seconds. The user combines their personal identification
number (PIN) and this code to create the password. A central server can validate
this password, since its clock is synchronized with the token and it knows the
user’s PIN. Since the authentication code changes every 60 seconds, the password
will change each time it’s used.

This system is a two-factor system since it combines the use of something you
know, the PIN, and something you have, the authenticator.
Sequential Keys Sequential key systems use a passphrase to generate one-time
passwords. The original passphrase, and the number representing how many
passwords will be generated from it, is entered into a server. The server
generates a new password each time an authentication request is made. Client
software that acts as a one-time generator is used on a workstation to generate
the same password when the user enters the passphrase. Since both systems
know the passphrase, and both systems are set to the same number of times the
passphrase can be used, both systems can generate the same password
independently.

The algorithm incorporates a series of hashes of the passphrase and a
challenge. The first time it is used, the number of hashes equals the number of
times the passphrase may be used. Each successive use reduces the number of
hashes by one. Eventually, the number of times the passphrase may be used is
exhausted, and either a new passphrase must be set or the old one must be reset.

When the client system issues an authentication request, the server issues a
challenge. The server challenge is a hash algorithm identifier (which will be MD5
or SHA-1), a sequence number, and a seed (which is a cleartext character string of
1 to 16 characters). Thus, a server challenge might look like this: opt-md5 567
mydoghasfleas. The challenge is processed by the one-time generator and the
passphrase entered by the user to produce a one-time password that is 64 bits in
length. This password must be entered into the system; in some cases this is
automatically done, in others it can be cut and pasted, and in still other
implementations the user must type it in. The password is used to encrypt the
challenge to create the response. The response is then returned to the server, and
the server validates it.

The steps for this process are as follows (illustrated in Figure 7-2):

Figure 7-2 The S/Key one-time password process is a modified challenge and response
authentication system.

1. The user enters a passphrase.
2. The client issues an authentication request.
3. The server issues a challenge.
4. The generator on the client and the generator on the server generate the same

one-time password.
5. The generated password is displayed to the user for entry or is directly entered by

the system. The password is used to encrypt the response.
6. The response is sent to the server.
7. The server creates its own encryption of the challenge using its own generated

password, which is the same as the client’s. The response is evaluated.
8. If there is a match, the user is authenticated.

Sequential key systems, like other one-time password systems, do provide a
defense against passive eavesdropping and replay attacks. There is, however, no
privacy of transmitted data, nor any protection from session hijacking. A secure
channel, such as IP Security (IPSec) or Secure Shell (SSH), can provide additional

protection. Other weaknesses of such a system are in its possible
implementations. Since the passphrase eventually must be reset, the
implementation should provide for this to be done in a secure manner. If this is
not the case, it may be possible for an attacker to capture the passphrase and thus
prepare an attack on the system. Sequential key implementation in some systems
leaves the traditional login in place. If users face the choice between using the
traditional login and entering a complicated passphrase and then a long,
generated password, users may opt to use the traditional login, thus weakening
the authentication process.
Certificate-Based Authentication
A certificate is a collection of information that binds an identity (user, computer,
service, or device) to the public key of a public/private key pair. The typical
certificate includes information about the identity and specifies the purposes for
which the certificate may be used, a serial number, and a location where more
information about the authority that issued the certificate may be found. The
certificate is digitally signed by the issuing authority, the certificate authority
(CA). The infrastructure used to support certificates in an organization is called
the Public Key Infrastructure (PKI). More information on PKI can be found
in Chapter 10.

The certificate, in addition to being stored by the identity it belongs to, may
itself be broadly available. It may be exchanged in e-mail, distributed as part of
some application’s initialization, or stored in a central database of some sort
where those who need a copy can retrieve one. Each certificate’s public key has
its associated private key, which is kept secret, usually only stored locally by the
identity. (Some implementations provide private key archiving, but often it is the
security of the private key that provides the guarantee of identity.)

An important concept to understand is that unlike symmetric key algorithms,
where a single key is used to both decrypt and encrypt, public/private key
algorithms use two keys: one key is used to encrypt, the other to decrypt. If the
public key encrypts, only the related private key can decrypt. If the private key
encrypts, only the related public key can decrypt.

When certificates are used for authentication, the private key is used to
encrypt or digitally sign some request or challenge. The related public key
(available from the certificate) can be used by the server or a central
authentication server to decrypt the request. If the result matches what is
expected, then proof of identity is obtained. Since the related public key can
successfully decrypt the challenge, and only the identity to which the private key
belongs can have the private key that encrypted the challenge, the message must
come from the identity. These authentication steps are as follows:

1. The client issues an authentication request.
2. A challenge is issued by the server.
3. The workstation uses its private key to encrypt the challenge.
4. The response is returned to the server.
5. Since the server has a copy of the certificate, it can use the public key to decrypt

the response.
6. The result is compared to the challenge.
7. If there is a match, the client is authenticated.

Figure 7-3 illustrates this concept.

Figure 7-3 Certificate authentication uses public and private keys.

It is useful here to understand that the original set of keys is generated by the
client, and only the public key is sent to the CA. The CA generates the certificate
and signs it using its private key, and then returns a copy of the certificate to the
user and to its database. In some systems, another database also receives a copy
of the certificate. It is the digital signing of the certificate that enables other
systems to evaluate the certificate for its authenticity. If they can obtain a copy of
the CA’s certificate, they can verify the signature on the client certificate and thus
be assured that the certificate is valid.

Two systems that use certificates for authentication are SSL/TLS and smart
cards.
SSL/TLS
Secure Sockets Layer (SSL) is a certificate-based system that is used to provide
authentication of secure web servers and clients and to share encryption keys
between servers and clients. Transport Layer Security (TLS) is the Internet
standard version (RFC 2246) of the proprietary SSL. While both TLS and SSL
perform the same function, they are not compatible—a server that uses SSL
cannot establish a secure session with a client that only uses TLS. Applications
must be made SSL- or TLS-aware before one or the other system can be used.

NOTE While the most common implementation of SSL provides for secure
communication and server authentication, client authentication may also be

implemented. Clients must have their own certificate for this purpose, and the
web server must be configured to require client authentication.

In the most commonly implemented use of SSL, an organization obtains a
server SSL certificate from a public CA, such as VeriSign, and installs the
certificate on its web server. The organization could produce its own certificate,
from an in-house implementation of certificate services, but the advantage of a
public CA certificate is that a copy of the CA’s certificate is automatically a part of
Internet browsers. Thus, the identity of the server can be proven by the client.
The authentication process (illustrated in Figure 7-4) works like this:

Figure 7-4 SSL can be used for server authentication and to provide secure
communications between a web server and a client.

1. The user enters the URL for the server in the browser.
2. The client request for the web page is sent to the server.
3. The server receives the request and sends its server certificate to the client.
4. The client’s browser checks its certificate store for a certificate from the CA that

issued the server certificate.
5. If the CA certificate is found, the browser validates the certificate by checking the

signature on the server’s certificate using the public key provided on the CA’s
certificate.

6. If this test is successful, the browser accepts the server certificate as valid.
7. A symmetric encryption key is generated and encrypted by the client, using the

server’s public key.
8. The encrypted key is returned to the server.

9. The server decrypts the key with the server’s own private key. The two computers
now share an encryption key that can be used to secure communications
between the two of them.

There are many potential problems with this system:
• Unless the web server is properly configured to require the use of SSL, the server

is not authenticated to the client, and normal, unprotected communication can
occur. The security relies on the user using the https:// designation instead of
http:// in their URL entry.

• If the client does not have a copy of the CA’s certificate, the server will offer to
provide one. While this ensures that encrypted communication between the
client and the server will occur, it does not provide server authentication. The
security of the communication relies on the user refusing to connect with a
server that cannot be identified by a third party.

• The process for getting a CA certificate in the browser’s store is not well
controlled. In the past, it may have been a matter of paying a fee or depended on
who you knew. Microsoft now requires that certificates included in its browser
store are from CAs that pass an audit.

• Protection of the private key is paramount. While the default implementations
only require that the key be in a protected area of the system, it is possible to
implement hardware-based systems that require the private key to be stored only
on a hardware device.

• As with any PKI-based system, the decision to provide a certificate to an
organization for use on its web server is based on policies written by people, and
a decision is made by people. Mistakes can be made. An SSL certificate that
identifies a server as belonging to a company might be issued to someone who
does not represent that company. And even though a certificate has expired, or
another problem is discovered and a warning is issued, many users will just
ignore the warning and continue on.
Smart Cards and Other Hardware-Based Devices
The protection of the private key is paramount in certificate-based authentication
systems. If an attacker can obtain the private key, they can spoof the identity of
the client and authenticate. Implementations of these systems do a good job of
protecting the private key, but, ultimately, if the key is stored on the computer,
there is potential for compromise.

A better system would be to require that the private key be protected and
separate from the computer. Smart cards can be used for this purpose. While
there are many types of smart cards, the ones used for authentication look like a
credit card but contain a computer chip that is used to store the private key and a
copy of the certificate, as well as to provide processing. Care should be taken to

select the appropriate smart card for the application that will use them.
Additional hardware tokens can be USB based and serve similar purposes. Smart
cards require special smart card readers to provide communication between the
smart cards and the computer system.

In a typical smart card implementation, the following steps are used to
authenticate the client:

1. The user inserts the smart card into the reader (or moves it close to the scanner).
2. The computer-resident application responds by prompting the user for their

unique PIN. (The length of the PIN varies according to the type of smart card.)
3. The user enters their PIN.
4. If the PIN is correct, the computer application can communicate with the smart

card. The private key is used to encrypt some data. This data may be a challenge,
or it may be the timestamp of the client computer. The encryption occurs on the
smart card.

5. The encrypted data is transferred to the computer and possibly to a server on the
network.

6. The public key (the certificate can be made available) is used to decrypt the data.
Since only the possessor of the smart card has the private key, and because a
valid PIN must be entered to start the process, successfully decrypting the data
means the user is authenticated.

The use of smart cards to store the private key and certificate solves the
problem of protecting the keys. However, user training must be provided so that
users do not tape a written copy of their PIN to their smart card, or otherwise
make it known. As in more traditional authentication systems, it is the person
who possesses the smart card and PIN who will be identified as the user.

Smart cards are also extremely resistant to brute-force and dictionary attacks,
since a small number of incorrect PIN entries will render the smart card useless
for authentication. Additional security can be gained by requiring the presence of
the smart card to maintain the session. The system can be locked when the smart
card is removed. Users leaving for any amount of time can simply remove their
card, and the system is locked against any individual who might be able to
physically access the computer. Users can be encouraged to remove their cards
by making it their employee ID badge and requiring the user to have their ID at
all times. This also ensures that the smart card will not be left overnight in the
user’s desk. Yearly certificate updates can be required to help keep the security
up to date.

Problems with smart cards are usually expressed in terms of management
issues. Issuing smart cards, training users, justifying the costs, dealing with lost
cards, and the like are all problems. In addition, the implementation should be

checked to ensure that systems can be configured to require the use of a smart
card. Some implementations allow the alternative use of a password, which
weakens the system because an attack only needs to be mounted against the
password—the additional security the smart card provides is eliminated by this
ability to go around it. To determine whether a proposed system has this
weakness, examine the documentation for this option, and look also for areas
where the smart card cannot be used, such as for administrative commands or
secondary logons.
Extensible Authentication Protocol (EAP)
The Extensible Authentication Protocol (EAP) was developed to allow pluggable
modules to be incorporated in an overall authentication process. This means
authentication interfaces and basic processes can all remain the same, while
changes can be made to the acceptable credentials and the precise way that they
are manipulated. Once EAP is implemented in a system, new algorithms for
authentication can be added as they are developed, without requiring huge
changes in the operating system. EAP is currently implemented in several remote
access systems, including Remote Authentication Dial-In User Service (RADIUS).

Authentication modules used with EAP are called EAP types. Several EAP types
exist, with the name indicating the type of authentication used:

• EAP/TLS Uses the TLS authentication protocol and provides the ability to use
smart cards for remote authentication.

• EAP/MD5-CHAP Allows the use of passwords by organizations that require
increased security for remote wireless 802.1x authentication but that do not have
the PKI to support passwords.
Biometrics
In biometric methods of authentication, the “something you have” is something
that is physically part of you. Biometric systems include the use of facial
recognition and identification, retinal scans, iris scans, fingerprints, hand
geometry, voice recognition, lip movement, and keystroke analysis. Biometric
devices are commonly used today to provide authentication for access to
computer systems and buildings, and even to permit pulling a trigger on a gun. In
each case, the algorithm for comparison may differ, but a body part is examined
and a number of unique points are mapped for comparison with stored
mappings in a database. If the mappings match, the individual is authenticated.

The process hinges on two things: first, that the body part examined can be
said to be unique, and second, that the system can be tuned to require enough
information to establish a unique identity and not result in a false rejection,
while not requiring so little information as to provide false positives. All of the
biometrics currently in use have been established because they represent

characteristics that are unique to individuals. The relative accuracy of each
system is judged by the number of false rejections and false positives that it
generates.

In addition to false negatives and false positives, biometrics live under the
shadow, popularized by the entertainment industry, of malicious attackers
cutting body parts from the real person and using them to authenticate to
systems.

Other attacks on fingerprint systems have also been demonstrated—one such
is the gummy finger attack. In May of 2002, Tsutomu Matsumoto, a graduate
student of environment and information science at Yokohama National
University, obtained an imprint of an audience member’s finger and prepared a
fake finger with the impression. He used about $10 of commonly available items
to produce something the texture of the candy gummy worms. He then used the
“gummy finger” to defeat ten different commercial fingerprint readers. While
this attack would require access to the individual’s finger, another similar attack
was demonstrated in which Matsumoto used latent fingerprints from various
surfaces. This attack was also successful. These attacks not only defeat systems
most people believe to be undefeatable, but after the attack, you can eat the
evidence!
Additional Uses for Authentication
Here are some additional uses for authentication:

• Computer authenticating to a central server upon boot In Windows, client
computers are joined in the domain login at boot and receive security policy.
Wireless networks may also require some computer credentials before the
computer is allowed to have access to the network.

• Computer establishing a secure channel for network
communication Examples of this are SSH and IPSec. More information on these
two systems is included in the following sections.

• Computer requesting access to resources This may also trigger a request for
authentication. More information can be found in the “Authorization” section
later in this chapter.
SSH
Secure Shell (SSH) is available for most versions of Unix as well as for Windows
systems. SSH provides a secure channel for use in remote administration.
Traditional Unix tools do not require protected authentication, nor do they
provide confidentiality, but SSH does.
IPSec
IP Security, commonly referred to as IPSec, is designed to provide a secure
communication channel between two devices. Computers, routers, firewalls, and

the like can establish IPSec sessions with other network devices. IPSec can
provide confidentiality, data authentication, data integrity, and protection from
replay. Multiple RFCs describe the standard.

Many implementations of IPSec exist, and it is widely deployed in virtual
private networks (VPNs). It can also be used to secure communication on LANs or
WANs between two computers. Since it operates between the network and
transport layers in the network stack, applications do not have to be aware of
IPSec. IPSec can also be used to simply block specific protocols, or communication
from specific computers or IP address block ranges. When used between two
devices, mutual authentication from device to device is required. Multiple
encryption and authentication algorithms can be supported, as the protocol was
designed to be flexible.

Authorization
The counterpart to authentication is authorization. Authentication establishes
who the user is; authorization specifies what that user can do. Typically thought
of as a way of establishing access to resources, such as files and printers,
authorization also addresses the suite of privileges that a user may have on the
system or on the network. In its ultimate use, authorization even specifies
whether the user can access the system at all. There are a variety of types of
authorization systems, including user rights, role-based authorization, access
control lists, and rule-based authorization.

NOTE Authorization is most often described in terms of users accessing resources
such as files or exercising privileges such as shutting down the system. However,
authorization is also specific to particular areas of the system. For example, many
operating systems are divided into user space and kernel space, and the ability of
an executable to run in one space or the other is strictly controlled. To run within
the kernel, the executable must be privileged, and this right is usually restricted
to native operating system components.
User Rights
Privileges or user rights are different from permissions. User rights provide the
authorization to do things that affect the entire system. The ability to create
groups, assign users to groups, log in to a system, and many more user rights can
be assigned. Other user rights are implicit and are rights that are granted to
default groups—groups that are created by the operating system instead of by
administrators. These rights cannot be removed.

In the typical implementation of a Unix system, implicit privileges are granted
to the root account. This account is authorized to do anything on the system.

Users, on the other hand, have limited rights, including the ability to log in, access
certain files, and run applications they are authorized to execute.

On some Unix systems, system administrators can grant certain users the right
to use specific commands as root, without issuing them the root password. An
application that can do this, and which is in the public domain, is called sudo.
Role-Based Authorization (RBAC)
Each job within a company has a role to play. Each employee requires privileges
(the right to do something) and permissions (the right to access particular
resources and do specified things with them) if they are to do their job. Early
designers of computer systems recognized that the needs of possible users of
systems would vary, and that not all users should be given the right to administer
the system.

Two early roles for computer systems were those of user and administrator.
Early systems defined roles for these types of users to play and granted them
access based on their membership in one of these two groups. Administrators
(superusers, root, admins, and the like) were granted special privileges and
allowed access to a larger array of computer resources than were ordinary users.
Administrators, for example, could add users, assign passwords, access system
files and programs, and reboot the machine. Ordinary users could log in and
perhaps read data, modify it, and execute programs. This grouping was later
extended to include the role of auditor (a user who can read system information
and information about the activities of others on the system, but not modify
system data or perform other administrator role functions).

As systems grew, the roles of users were made more granular. Users might be
quantified by their security clearance, for example, and allowed access to
specified data or allowed to run certain applications. Other distinctions might be
made based on the user’s role in a database or other application system.
Commonly, roles are assigned by departments such as Finance, Human
Resources, Information Technology, and Sales.

In the simplest examples of these role-based systems, users are added to
groups that have specific rights and privileges. Other role-based systems use
more complex systems of access control, including some that can only be
implemented if the operating system is designed to manage them. In the Bell-
LaPadula security model (described in Chapter 20), for example, data resources
are divided into layers, or zones. Each zone represents a data classification, and
data may not be moved from zone to zone without special authorization, and a
user must be provided access to the zone to use the data. In that role, the user
may not write to a zone lower in the hierarchy (from secret to confidential, for
example), nor may they read data in a higher level than they have access to (a

user granted access to the public zone, for example, may not read data in the
confidential or secret zones).

The Unix role-based access control (RBAC) facility can be used to delegate
administrative privileges to ordinary users. It works by defining role accounts, or
accounts that can be used to perform certain administrative tasks. Role accounts
are not accessible to normal logons—they can only be accessed with the su
command (as described in Chapter 21).
Access Control Lists (ACLs)
Attendance at some social events is limited to invitees only. To ensure that only
invited guests are welcomed to the party, a list of authorized individuals may be
provided to those who permit the guests in. If you arrive, the name you provide is
checked against this list, and entry is granted or denied. Authentication, in the
form of a photo identification check, may or may not play a part here, but this is a
good, simple example of the use of an access control list (ACL).

Information systems may also use ACLs to determine whether the requested
service or resource is authorized. Access to files on a server is often controlled by
information that is maintained on each file. Likewise, the ability for different
types of communication to pass a network device can be controlled by ACLs.
File-Access Permissions
Both Windows and Unix systems use file permissions to manage access to files.
The implementation varies, but it works well for both systems. It is only when
you require interoperability that problems arise in ensuring that proper
authorization is maintained across platforms.
Windows File-Access Permissions The Windows NTFS file system maintains an
ACL for each file and folder. The ACL is composed of a list of access control
entries (ACEs). Each ACE includes a security identifier (SID) and the permission(s)
granted to that SID. Permissions may be either access or deny, and SIDs may
represent user accounts, computer accounts, or groups. ACEs may be assigned by
administrators, owners of the file, or users with the permission to apply
permissions.

Part of the login process is the determination of the privileges and group
memberships for the specific user or computer. A list is composed that includes
the user’s SID, the SIDs of the groups of which the user is a member, and the
privileges the user has. When a connection to a computer is made, an access
token is created for the user and attached to any running processes the user may
start on that system.

Permissions in Windows systems are very granular. The permissions listed
in Table 7-1 actually represent sets of permissions, but the permissions can be
individually assigned as well.

*These permissions do not match the permission groupings indicated. Each permission listed in the

table can be applied separately.

Table 7-1 Windows File Permissions
When an attempt to access a resource is made, the security subsystem

compares the list of ACEs on the resource to the list of SIDs and privileges in the
access token. If there is a match, both of SID and access right requested,
authorization is granted unless the access authorization is “deny.” Permissions
are cumulative (that is, if the read permission is granted to a user and the write
permission is granted to a user, then the user has the read and write permission),
but the presence of a deny authorization will result in denial, even in the case of
an access permission. The lack of any match results in an implicit denial.

It should be noted that file permissions and other object-based permissions in
Windows can also be supplemented by permissions on shared folders. That is, if a
folder is directly accessible from the network because of the Server Message
Block (SMB) protocol, permissions can be set on the folder to control access. These
permissions are evaluated along with the underlying permissions set directly on
the folder using the NTFS permission set. In the case where there is a conflict
between the two sets of permissions, the most restrictive permission wins. For
example, if the share permission gives Read and Write permission to the

Accountants group, of which Alice is a member, but the underlying folder
permission denies Alice access, then Alice will be denied access to the folder.
Unix File-Access Permissions Traditional Unix file systems do not use ACLs.
Instead, files are protected by limiting access by user account and group. If you
want to grant read access to a single individual in addition to the owner, for
example, you cannot do so. If you want to grant read access to one group and
write access to another, you cannot. This lack of granularity is countered in some
Unix systems (such as Solaris) by providing ACLs, but before we look at that
system, we’ll examine the traditional file protection system.

Information about a file, with the exception of the filename, is included in
the inode. The file inode contains information about the file, including the user ID
of the file’s owner, the group to which the file belongs, and the file mode, which is
the set of read/write/execute permissions.

File permissions are assigned to control access, and they consist of three levels
of access: Owner, Group, and all others. Owner privileges include the right to
determine who can access the file and read it, write to it, or, if it is an executable,
execute it. There is little granularity to these permissions. Directories can also
have permissions assigned to Owner, Group, and all others. Table 7-2 lists and
explains the permissions.

Table 7-2 Traditional Unix File Permissions

ACLs are offered in addition to the traditional Unix file protection scheme.
ACEs can be defined on a file and set through commands. These commands
include information on the type of entry (the user or the ACL mask), the user ID
(UID), group ID (GID), and the perms (permissions). The mask entry specifies the
maximum permissions allowed for users (not including the owner) and groups.
Even if an explicit permission has been granted for write or execute permission,
if an ACL mask is set to read, read will be the only permission granted.
ACLs for Network Devices
ACLs are used by network devices to control access to networks and to control
the type of access granted. Specifically, routers and firewalls may have lists of
access controls that specify which ports on which computers can be accessed by
incoming communications, or which types of traffic can be accepted by the

device and routed to an alternative network. Additional information on ACLs
used by network devices can be found in Chapters 13 and 14.
Rule-Based Authorization
Rule-based authorization requires the development of rules that stipulate what a
specific user can do on a system. These rules might provide information such as
“User Alice can access resource Z but cannot access resource D.” More complex
rules specify combinations, such as “User Bob can read file P only if he is sitting
at the console in the data center.” In a small system, rule-based authorization
may not be too difficult to maintain, but in larger systems and networks, it is
excruciatingly tedious and difficult to administer.

Compliance with Standards
If you are following a specific security framework, here’s how NIST, ISO 27002,
and COBIT tie in to this chapter.
NIST
NIST offers several publications relating to authentication:

• SP 800-120: Recommendation for EAP Methods Used in Wireless Network Access
Authentication

• SP 800-63: Electronic Authentication Guideline
• SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC

Mode for Authentication
• SP 800-38C: Recommendation for Block Cipher Modes of Operation: The CCM

Mode for Authentication and Confidentiality
• SP 800-25: Federal Agency Use of Public Key Technology for Digital Signatures

and Authentication
ISO 27002
ISO 27002 contains the following provisions, to which this chapter’s contents are
relevant:

• 11.2.1 Formal user registration and deregistration procedures are used for
granting access to information systems and services.

• 11.2.2 Allocation and use of privileges in information systems is restricted and
controlled and allocated on a need-to-use basis only after formal authorization
process.

• 11.2.3 Allocation and reallocation of passwords is controlled through a formal
management process.

• 11.2.4 A process is used to review user access rights at regular intervals.
• 11.3.1 Guidelines are in place to advise users on selecting and maintaining secure

passwords.

• 11.4.2 Authentication mechanisms are used for challenging external connections
such as cryptography-based techniques, hardware tokens, software tokens, and
challenge/response protocols.

• 11.5.2 Unique identifiers are provided to every user and the authentication
method substantiates the claimed identity of the user.

• 11.5.3 A password management system enforces password controls, including
enforcement of password changes, storage of passwords in encrypted form, and
avoidance of onscreen display of passwords.
COBIT
COBIT contains the following provisions, to which this chapter’s contents are
relevant.

DS5.3:
• Ensure that all users and their activity on IT systems are uniquely identifiable.
• Enable user identities via authentication mechanisms.
• Confirm that user access rights to systems and data are in line with defined and

documented business needs and that job requirements are attached to user
identities.

• Ensure that user access rights are requested by user management, approved by
system owners, and implemented by the security-responsible person.

• Maintain user identities and access rights in a central repository.
• Deploy cost-effective technical and procedural measures, and keep them current

to establish user identification, implement authentication, and enforce access
rights.

Summary
Authentication is the process of proving you are who you say you are. You can
take that literally. If someone possesses your user credentials, it is possible for
that person to say they are you, and to prove it to the satisfaction of the system.
While many modern systems are based on hardware, such as tokens and smart
cards, and on processes that can be assumed to be more secure, such as one-time
passwords, most systems still rely on passwords for authentication. These
systems are not well protected, because passwords are a terrible way to identify
people. Other authentication methods are better. You should always evaluate an
authentication system based on how easy it would be to defeat its controls.

Authorization, on the other hand, determines what an authenticated user can
do on the system or network. A number of controls exist that can help define
these rights of access explicitly. User rights are often provided directly by the
operating system, either via permissions granted to the user account directly, or
through the use of groups. If the user account belongs to a particular group, it is

granted rights to do certain things. This method of authorization, while
commonly found in most organizations, is not easy to manage and has a high
potential for error. Role-based access controls are similar to group authorization,
but they are organized into sets of functions based on some key common
characteristic. Access control lists, in which specific, granular capabilities are
individually specified, are also used to authorize functions.

References
Ballad, Bill, Tricia Ballad, and Erin Banks. Access Control, Authentication, and
Public Key Infrastructure. Jones & Bartlett, 2010.
Clarke, Nathan. Transparent User Authentication: Biometrics, RFID and
Behavioural Profiling. Springer, 2011.
Jain, Anil, Patrick Flynn, and Arun Ross, eds. Handbook of Biometrics. Springer,
2010.
Newman, Robert. Security and Access Control Using Biometric Technologies.
Course Technology, 2009.
Nickell, Joe. Real or Fake: Studies in Authentication. The University Press of
Kentucky, 2009.
Smith, Richard. Authentication: From Passwords to Public Keys. Addison-Wesley,
2001.
Todorov, Dobromir. Mechanics of User Identification and Authentication:
Fundamentals of Identity Management. Auerbach Publications, 2007.