Information Security in The Clientserver Environme

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/36369521
Information security in the client/server environment /
Article · January 1997

Source: OAI
CITATIONS READS
0 6,379
1 author:
Reinhardt A Botha
Nelson Mandela University
87 PUBLICATIONS 603 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Masters Degree View project
All content following this page was uploaded by Reinhardt A Botha on 07 November 2014.
The user has requested enhancement of the downloaded file.

Information Security
in the
Client/Server environment
by
Reinhardt A. Botha
Information Security in the Client/Server environment
by
Reinhardt A. Botha
DISSERTATION
submitted for fulfillment of the requirements
for the degree of
MAGISTER SCIENTIAE
in
COMPUTER SCIENCE
in the
FACULTY OF SCIENCE
of the
RAND AFRIKAANS UNIVERSITY
Study leader : Prof J.H.P. Eloff
May 1997
To my wife, Adéle
SUMMARY
Client/Server computing is currently one of the buzzwords in the computer

industry. The client/server environment can be defined as an open systems
environment. This openness of the client/server environment makes it a very
popular environment to operate in. As information are exceedingly accessed
in a client/server manner certain security issues arise.
In order to address this definite need for a secure client/server environment it

is necessary to firstly define the client/server environment. This is
accomplished through defining three possible ways to partition programs
within the client/server environment.
Security, or secure systems, have a different meaning for different people.

This dissertation defines six attributes of information that should be
maintained in order to have secure information. For certain environments
some of these attributes may be unnecessary or of lesser importance.
Different security techniques and measures are discussed and classified in

terms of the client/server partitions and the security attributes that are
maintained by them. This is presented in the form of a matrix and provides an
easy reference to decide on security measures in the client/server
environment in order to protect a specific aspect of the information.
The importance of a security policy and more specifically the influence of the
client/server environment on such a policy are discussed and it is
demonstrated that the framework can assist in drawing up a security policy for
a client/server environment.
This dissertation furthermore defines an electronic document management

system as a case study. It is shown that the client/server environment is a
suitable environment for such a system. The security needs and problems are
identified and classified in terms of the security attributes. Solutions to the
problems are discussed in order to provide a reasonably secure electronic
document management system environment.
OPSOMMING
Kliënt/Bediener rekenarisering is huidiglik een van die modewoorde in die

rekenaarbedryf. Die kliënt/bediener omgewing kan as ‘n oop stelselomgewing
gedefinieer word. Hierdie openheid van die kliënt/bediener omgewing lei
daartoe dat dit ‘n gewilde omgewing vir stelselontwikkeling is. Namate
toegang tot meer en meer inligting op ‘n kliënt/bediener wyse verkry word,
kom sekere aspekte betreffende sekerheid na vore.
Ten einde die spesifieke behoefte aan ‘n veilige kliënt/bediener omgewing
aan te spreek, is dit noodsaaklik dat die kliënt/bediener omgewing eers
gedefinieer moet word. Dit word gedoen aan die hand van die definiëring van
drie moontlike verdelingsmetodes binne die kliënt/bediener omgewing.
In hierdie verhandeling word eienskappe van sekure inligting gedefinieer
waaraan voldoen moet word ten einde sekerheid van inligting te verseker. In
bepaalde omgewings mag sommige van hierdie eienskappe oorbodig of van
geringer belang wees.
Verskillende sekerheidstegnieke en -maatreëls word bespreek en
geklassifiseer in terme van die kliënt/bediener verdelingsmetode en die
sekerheidseienskappe wat daardeur onderhou moet word. Die voorafgaande
word deur middel van ‘n matriks voorgestel en verskaf ‘n eenvoudige
verwysingsraamwerk vir die neem van besluite rakende sekerheidsmaatreëls
wat binne die kliënt/bediener omgewing benodig word ten einde ‘n spesifieke
aspek van die inligting te beskerm.
Die belangrikheid van ‘n sekerheidsbeleid en, meer spesifiek, die invloed wat
die kliënt/bediener omgewing op die beleid uitoefen, word bespreek. Dit word
verder aangetoon dat die matriks ‘n bydrae kan lewer in die bepaling van ‘n
sekerheidsbeleid vir ‘n kliënt/bediener omgewing.
Die verhandeling definieer ook ‘n elektroniese dokument bestuurstelsel as ‘n
gevallestudie. Daar word aangetoon dat die kliënt/bediener omgewing vir so
‘n stelsel geskik is. Die sekerheidsbehoeftes en -probleme word geïdentifiseer
en in terme van die sekerheidseienskappe geklassifiseer. Oplossings vir die
probleme word bespreek ten einde ‘n redelik sekure elektroniese dokument
bestuurstelsel daar te stel.
TABLE OF CONTENTS
1. INTRODUCTION ...............................................................................................................1
1.1 BACKGROUND INFORMATION.............................................................................................1
1.2 DEFINITION OF KEY CONCEPTS..........................................................................................2
1.3 STATE OF THE ART ...........................................................................................................2
1.4 PROBLEM STATEMENT ......................................................................................................3
1.5 OVERVIEW OF THIS STUDY ................................................................................................4
2. INFORMATION SECURITY ATTRIBUTES ......................................................................6

2.1 AVAILABILITY ...................................................................................................................6
2.2 UTILITY............................................................................................................................7
2.3 INTEGRITY .......................................................................................................................8
2.4 AUTHENTICITY .................................................................................................................8
2.5 CONFIDENTIALITY.............................................................................................................9
2.6 POSSESSION ...................................................................................................................9
2.7 CONCLUSION .................................................................................................................10
3. CLIENT/SERVER ARCHITECTURE...............................................................................11
3.1 CLIENT/SERVER ARCHITECTURE......................................................................................11
3.2 THE UI PARTITION ..........................................................................................................14
3.3 THE STORAGE PARTITION ...............................................................................................16
3.4 THE LOGIC PARTITION.....................................................................................................19
3.5 ORACLE AND THE VARIOUS CLIENT/SERVER PARTITIONS ................................................22
3.5.1 ORACLE and the UI partition ...........................................................................22
3.5.2 ORACLE and the storage partition ..................................................................23
3.5.3 ORACLE and the logic partition .......................................................................24
3.6 CONCLUSION .................................................................................................................25
4. THE FRAMEWORK.........................................................................................................26
4.1 THE FRAMEWORK ...........................................................................................................26
4.2 A STRATEGY FOR COMPLETING THE FRAMEWORK.............................................................27
5. EVALUATION CRITERIA AND THE CLIENT/SERVER ENVIRONMENT.....................28

5.1 TCSEC.........................................................................................................................28
5.1.1 TCSEC and the client/server environment.......................................................29
5.1.2 Products evaluated against TCSEC ................................................................30
5.2 ITSEC ..........................................................................................................................30
5.2.1 ITSEC and the client/server environment ........................................................31
5.2.2 Current evaluations against ITSEC..................................................................32
5.3 COMMON CRITERIA (CC)................................................................................................32
5.4 EVALUATION CRITERIA AND THE SECURITY FRAMEWORK ...................................................34
5.5 CONCLUSION .................................................................................................................38
6. APPLICATION FRAMEWORKS.....................................................................................39
6.1 ECMA SECURITY FRAMEWORK .......................................................................................39
6.1.1 ECMA and the client/server environment ........................................................42
6.1.2 ECMA and the security framework ..................................................................43
6.2 OSF DCE .....................................................................................................................45
6.2.1 The DCE and the client/server environment ....................................................47
6.2.2 The DCE and the security framework ..............................................................48
6.2.3 Kerberos...........................................................................................................49
6.2.3.1 Kerberos and the client/server environment ............................................................... 52
6.2.3.2 Kerberos and the security framework ......................................................................... 52
6.3 CONCLUSION .................................................................................................................54
7. THE WORLD WIDE WEB ...............................................................................................55

7.1 THE WWW AND A SECURE ENVIRONMENT .......................................................................57
7.1.1 Server security issues ......................................................................................58
7.1.2 Client security issues .......................................................................................61
7.2 THE WWW AND SECURE TRANSFER OF INFORMATION .....................................................61
7.3 JAVA AND SECURITY .......................................................................................................62
7.3.1 Java security features ......................................................................................63
7.3.1.1 A language designed to be safe ................................................................................. 63
7.3.1.2 Verifying the bytecode ................................................................................................ 64
7.3.1.3 The class loader ......................................................................................................... 64
7.3.1.4 The class libraries ...................................................................................................... 65
7.3.2 Java-enabled browsers ....................................................................................65
7.4 INTERNET AND THE SECURITY FRAMEWORK .....................................................................66
7.5 CONCLUSION .................................................................................................................69
8. THE CONSOLIDATED FRAMEWORK...........................................................................70

8.1 UI DESIGN ISSUES FOR THE CLIENT/SERVER ENVIRONMENT ..............................................70
8.1.1 UI design issues and the security framework ..................................................71
8.2 OTHER ISSUES ...............................................................................................................72
8.3 CONSOLIDATING THE MATRIXES ......................................................................................73
9. AN ELECTRONIC DOCUMENT MANAGEMENT SYSTEM AS CASE STUDY............76

9.1 TERMINOLOGY ...............................................................................................................76
9.2 TYPICAL CONFIGURATION ...............................................................................................78
9.3 SECURITY ISSUES IN AN EDMS ENVIRONMENT ................................................................80
9.3.1 Access to documents .......................................................................................81
9.3.2 Authenticity of different revisions .....................................................................82
9.3.3 Propagation of access rights............................................................................83
9.3.4 Governing the security behavior of native applications ...................................84
9.3.5 Multiple logins required ....................................................................................85
9.3.6 Protection of document files.............................................................................85
9.4 CONCLUSION .................................................................................................................86
10. SECURITY POLICIES FOR THE CLIENT/SERVER ENVIRONMENT .........................87

10.1 WHAT MANAGERS SHOULD BE CONCERNED ABOUT ......................................................88
10.2 AN INFORMATION SECURITY POLICY FOR THE CLIENT/SERVER ENVIRONMENT ................89
10.2.1 Differences between a centralized environment and the client/server
environment .....................................................................................................................89
10.2.2 Components of the information security policy ................................................91
10.3 THE NETWORK SECURITY POLICY ................................................................................92
10.4 SERVER SECURITY POLICY .........................................................................................94
10.5 CLIENT SECURITY POLICY ...........................................................................................97
10.6 CONCLUSION ...........................................................................................................100
11. CONCLUSION...............................................................................................................101
11.1 FURTHER RESEARCH ...............................................................................................102
A. BIBLIOGRAPHY ...........................................................................................................103
B. ARTICLE........................................................................................................................108
1. INTRODUCTION
1
1.1 Background information
Throughout the world information is expanding at a phenomenal rate. In order

to remain in business industry has to keep up with this information explosion.
This need for up to date information forces businesses to rely more and more
upon the facilities provided to them by the computer industry.
Developments within the computer industry did not stagnate either. In fact, the
information explosion and the technology explosion within the computer
industry go hand in hand. The result of all this growth is that a large collection
of different technologies exists today within the business community.
The need for these technologies to interact with one another brought many
challenges to the computer industry. Research directions, such as
client/server computing, federated databases and networking, paved the way
for these different technologies to work together in an efficient manner.
These “new” technologies are leading to an increased level of data and other
resource sharing between different users. This co-operative way of working
has led to more openness in systems, in that data is more accessible and
available. This growing importance of openness in systems, places a definite
burden on the security of the system. The notions “open systems” and “secure
systems” seem to be contradicting one another.
The emphasis within open systems is to share information and other

resources using a network. These networks were originally designed for ease
of use and not mainly for security purposes.
INTRODUCTION
The client/server architecture can be considered a specific case of an open

system, in that the server provides the client with data and other services over
a network. The next section will define terms typically used in the client/server
environment.
1.2 Definition of key concepts
This section defines certain key concepts used throughout the dissertation.
Information security is the steps taken, tools implemented and mechanisms

used to ensure that the hardware, software and netware are protected against
incidental, intentional or unauthorized damage, harm or loss and that the
hardware, software and netware are always available to the people that must
get access to it [ELOF94].
Client/server computing devides the processing of tasks in an application

between the network resources best suitable for the different tasks. These
resources consist of two groups: clients and servers.
A client is an intelligent workstation, typically a PC, with capabilities of doing

local data manipulation and maintaining a user interface.
A server is a computing device that is used with the specific intention of

handling database functions or other numerical intensive processing [SINH92].
1.3 State of the art
The continued increase in the usage of computer systems to manage the

information within organizations has also led to a bigger need for secure
systems. The need for security and the need for more openness in a system
can work detrimentally against each other. It is therefore necessary for
companies to investigate which degree of security and which degree of
openness should be allowed when developing secure open systems.
Currently companies world wide opt for “down-sizing” to a client/server
environment, without top-management realizing all the implications thereof.
2
INTRODUCTION
The network boom paved the way for the uprising of the client/server
infrastructure [STRA93].
If companies are questioned as to why they are changing to client/server

architecture the reasons are multiple[MART94, SCHU94]. Reasons include the
retaining of current investment, the scalability of the architecture and an
increase in application performance.
For the above reasons client/server systems are gaining popularity by the
day. However, frequently security is given little consideration when the
decisions are made.
1.4 Problem statement
This dissertation attempts to address the following questions:
• How much has been done to address the issue of security within the
client/server environment?
• What are the functional security components of the client/server

environment? How is this influenced by the specific client/server
implementation?
• What influence does the client/server architecture have on the

design/development of secure applications?
• Research has lead to well-defined standards and policies for the

traditional centralized (resource sharing) and distributed systems. What
makes the client/server environment different from the more traditional
architectures? Which information security standards are available and
how are they applicable to the client/server environment?
• The application, together with its user interface, provides a means of

accessing the resources available in the environment. What security
3
INTRODUCTION
measures need to be taken on the application level? How does the user
interface influence the security of the system?
• In which way should the specific characteristics of a client/server

environment be reflected within the computer security policy of an
organization? How can security and integrity rules be defined for a
client/server environment?
Some of the aforementioned issues were addressed partially by other

authors. [HART95] identified the idea of different client/server partitions, but did
not relate the partitions to information security needs. Other authors [FRAN93,
DIXO96], on the other hand, realized the need for security in the client/server
environment, but failed to distinguish a client/server environment from a more

generalized distributed open systems environment. Several information
security issues in the distributed open systems environment have been
addressed by various authors, for example [GOLL93, HARR94, KRUY91, REIT93],
but they did not indicate how these techniques and methods are influenced by
the manner in which the applications are distributed across the environment.
This study shows that a synergy between the client/server partition and its
information security needs exists.
1.5 Overview of this study
Chapter 2 describes the information security attributes that will be used to

evaluate the level of information security of a client/server environment.
Client/server implementations can be distinctly grouped according to the

components residing on the client and the server respectively. In chapter 3
the different client/server partitions are identified and discussed.
Chapter 4 ties the concepts of client/server partitions and security attributes

together by proposing a security framework for the client/server environment.
4
INTRODUCTION
Chapters 5 – 7 subsequently study the potential sources for security methods

and techniques.
Chapter 5 studies evaluation criteria and evaluates it as a source of security

methods and techniques applicable in the client/server environment. Current
application development frameworks for open distributed environments are
investigated in chapter 6. Chapter 7 studies the World Wide Web and
techniques that are used in this environment.
Chapter 8 consolidates the methods and techniques identified through

studying the evaluation criteria, the application development frameworks and
the World Wide Web in chapters 5,6 and 7. As a result, the consolidated
client/server security framework is presented.
Chapter 9 identifies certain problems in electronic document management

systems and uses the framework to propose possible solutions.
Chapter 10 presents a possible structure for an information security policy in

a client/server environment. Thereafter the components of the policy are
discussed with special reference to the security framework presented in
Chapter 8.
Chapter 11 summarizes the findings of this dissertation and identifies further

research areas.
A bibliography of the literature consulted is provided and a copy of an article

presented at an international conference is attached as an appendix.
5
2. INFORMATION SECURITY
2 ATTRIBUTES
Traditionally the purpose of information security for information security
specialists is to preserve the three security attributes: confidentiality, integrity
and availability [PARK95]. However, Donn Parker [PARK95] presents a further
three attributes of secure information: utility, authenticity and possession. This
chapter will define all six attributes within the context of this dissertation.
2.1 Availability
Information availability can be described as the ability to immediately obtain

the information required for the accomplishment of a specific purpose.
Two areas impact on the availability attribute. Firstly the information should be
accessible, i.e. it should be reliably stored in an appropriate place. Secondly
the means to actually access the information should exist, i.e. the necessary
computer infrastructure should exist and be at the disposal of whoever
requests the information.
List 2-1: Possible threats to availability of information
deleting of files
accidental overwriting of files
disk crashes
infrastructure problems, e.g. network unavailability
natural disasters
List 2-1 presents a list of possible threats to the availability of information. The
deleting of files off the magnetic storage medium results in the loss of
availability since it cannot be retrieved by the average user. Note however
that this may be influenced by the operating system under which the file
system was created. In certain instances it may not result in a permanent loss
of the information, but merely present an inconvenience to the knowledgeable
user. In the case of a disk crash the loss could be permanent if the necessary
INFORMATION SECURITY ATTRIBUTES
precautions have not been taken. Accidental overwriting of a file could occur
when an existing file is replaced by another, e.g. copying a file to the same
name, resulting in the original information becoming unavailable. If the
network infrastructure becomes unavailable the information, although still
intact at storage level, cannot be accessed by the users and is therefore
unavailable. Similarly natural disasters may cause the abovementioned
network unavailability, the breakdown of equipment or the destruction of the
magnetic media, resulting in information becoming unavailable.
2.2 Utility
The utility attribute describes the usefulness of the information. In other

words, whether the available information is fit for a specific purpose.
List 2-2: Possible threats to information utility
availability of information
user interface design
loss of cryptography key
misrepresentation of data
List 2-2 presents a list of possible threats to the utility value of the information.
The usefulness of the information depends on the availability of the
information, since unavailable information cannot be useful in any way.
Furthermore the usefulness is greatly enhanced by the proper design of a
user interface. The user interface design should form an integral part of the
system’s development lifecycle to ensure that the information presented is
meaningful to the user. Although all relevant information may be presented to
the user the actual manner in which this is done may to a large extent
influence the utility value of the information. For example, information
presented in a massive table may prove useless to users unless studied for
days, whereas the same information depicted on an appropriate graph can be
used instantly.
7
2.3 Integrity
Integrity of the information points to the unimpaired soundness of the

information.
List 2-3: Possible threats to integrity of information
storage errors
electrical/magnetical interference
database design
unauthorized changes
As displayed in List 2-3 several threats exist that endanger the integrity of
information. Storage errors, like the malfunctioning of a disk drive, could lead
to the loss of integrity of the data that is stored on it. Similarly writing to a bad
sector on a disk could cause the written data to be unsound.
Other chances of corrupting the information are during transmission of the

information where electrical or magnetical interference can corrupt the data
being transmitted.
Both of the above issues have to do with physical integrity, whereas database
design points to the logical integrity of the data. This could be increased
considerably by enforcing referential integrity during the design process.
It is also noteworthy to mention that the integrity of data depends on the ability
to only allow properly authenticated authorized users to change information in
the database. If unauthorized changes are allowed then the integrity of the
information in the system can be seriously damaged.
2.4 Authenticity
Information authenticity represents an authoritative quality, indicating that the

information is worthy of acceptance or belief.
List 2-4: Possible threats to authenticity
masquerading as somebody else

forging of messages
altering existing information
8
Two important aspects of authenticity are (1) the authenticity of

communicating parties and (2) the authenticity of content. If a possible
intruder can masquerade as somebody else then the authenticity of the
communicating parties is threatened. If the messages between
communication partners can be altered or forged then authenticity of content
can be lost.
2.5 Confidentiality
Confidentiality of information indicates the state of being private. It implies that

access to the information can only be gained by authorized users.
List 2-5: Possible threats to confidentiality of information
reading of information by unauthorized people

deduction of information
Possible threats to confidentiality are listed in List 2-5. The issue of users
being authorized to access the information is of the utmost importance for
confidentiality of information. If an unauthorized user can read the information
it cannot be considered confidential. Sometimes confidentiality can be
threatened by the mere knowledge of the existence of certain information. For
example, if a company is in the process of considering the rationalization of
staff then knowledge of the existence of such documents by staff, who could
possibly be influenced by the rationalization process, could be very disruptive
to the organization.
2.6 Possession
The attribute of possession indicates the state of being in control of

information.
List 2-6: Possible threats to the possession of information
stolen hardware
natural disasters
stolen magnetic media
copyright and trade secret violations
9
As listed in List 2-6 several threats to the possession of information exist. If

the hardware containing the information is stolen then possession of that
information is influenced. Possession can be lost completely if the stolen
hardware is never recovered or it could be lost temporarily until the hardware
is found. Similar arguments can be made in the case of stolen magnetic
media and natural disasters. Exclusive possession is threatened by copyright
violations, i.e. if a copy of the information is stolen, but one or more copies are
still in the possession of the owner.
2.7 Conclusion
This chapter defined the different security attributes that need to be protected
to have secure information. Different organizations, however, have different
security needs. These attributes therefore form a part of the presented
framework in order to allow an organization to choose the attributes that are
relevant to their situation.
The following chapter will identify the different partitions that exist in the
client/server environment, explaining how an EDMS could be implemented for
each of these partitions.
10
3.
3 CLIENT/SERVER ARCHITECTURE
Popular literature has made “client/server” one of the leading industry

buzzwords. Yet a definition of what the term means is still not agreed upon
[ORFA94].
This chapter defines the term client/server. Thereafter it studies possible ways
in which a system can be partitioned within a client/server environment. These
partitions are then presented in more detail by evaluating how an electronic
document management system could be implemented for each of the
partitions.
3.1 Client/server architecture
One fact that exists when defining the term client/server is that by virtue of the
name it consists of at least the following two components: clients and servers.
The first controversy, however, arises just after this fact has been established,
namely what is the role of the client and what is the role of the server. In order
to answer this question the basic components firstly have to be considered:
♦ Servers
The server can be seen as a resource providing a service to other resources.

For example, a computer providing services for database management.
♦ Clients
The clients represent the “other” resources requesting a service from the
server. For example, a workstation running a program requiring information
from a database.
11
CLIENT/SERVER ARCHITECTURE
Logic Module
User Interface Information
Presentation Application Information
Module sub-module logic sub- logic sub- Storage
(UI) module mudule Module
Figure 3-1: Program partitions
A client/server system can be partitioned into clients and servers in several

ways, similar to the ways that programs that run on a single machine are
partitioned. Three modules are identified: the user interface module, the logic
module and the information storage module (Figure 3-1 refers). If all of the
modules are situated on different machines then the arrangement is called the
three-tier client/server model [HART95]. The logic module can be further
subdivided into three sub-modules, namely the presentation logic sub-module,
the application logic sub-module and the information logic sub-module.
The user interface module controls all user interaction, i.e. all input and
output. The presentation logic sub-module processes the user input and
prepares the user output. The application logic sub-module is where the
computationally complex tasks are performed. The information logic sub-
module determines which data is stored and retrieved and the manner in
which it is done, e.g. it would determine the query which has to be sent to the
database. The information storage module reads and writes data from the
media where it is stored.
These modules can be distributed amongst clients and servers in several

different ways within a client/server environment. If it is assumed that each of
the five modules or sub-modules reside on maximum one machine and that
they are distributed amongst at least two machines then 2500 (i.e. 4x54)
different partitions are possible. Of course the assumption that each sub-
module resides on maximum one machine is not necessarily valid since any
specific sub-module could be distributed amongst many different machines.
This results in an infinite number of possible partitions.
12
Logic module
SERVER
CLIENT
module logic sub- logic sub- logic sub- Storage
(UI) module module mudule module
UI partition
Logic module
SERVER
CLIENT

Logic partition
Logic module
SERVER
CLIENT

Storage partition
Figure 3-2: Three client/server partitions
For illustration purposes three possible partitions will be studied. These

partitions currently are representative of the more popular approaches to
client/server computing environments. These three partitions are depicted in
Figure 3-2.
An UI partition is achieved by placing the user interface module on a different

node (the client) than the logic and information storage modules (the server).
Similarly a logic partition is achieved by grouping some of the logic modules
and the user interface on one node (the client) and the information storage
module together with some other logic modules on a different node (the
server). A third possibility, a storage partition, is achieved by placing the
information storage module on a different node (the server) than the logic and
user interface modules (the client).
These three partitions, together with the security attributes discussed in

Chapter 2, will form the basis for evaluating security in the client/server
environment. To enhance understanding of the different partitions a more
detailed investigation into each of these partitions follows.
13
3.2 The UI partition
This partition shows similarities to the typical mainframe environment. The

server does all the processing and storage functions. The main difference is
that the user interface module is located on the client, utilizing the graphical
display capabilities of the client.
The information security requirements of the UI partition are similar to those of

the more traditional environments in that the server is performing the
identification, authentication and authorization functions. Either the database
or the application, both residing on the server, controls integrity of the data.
The client workstation will only present the information. In other words, the
client will present the information according to instructions received from the
server. For example, the server will decide which document has to be
displayed, as well as the manner in which the document should be displayed.
The UI module, therefore, has extremely limited logic embedded in it, as it
only has to know how to write to the output devices and how to receive input
from the user.
To best understand this partition the execution of a query has to be

considered. In this scenario it is assumed that a user wants to read the
memos that were sent by Mr. A.N. Other during September 1996.
Figure 3-3 (next page) graphically represents this scenario:
{ The user requests “the memos that were sent by Mr. A.N. Other during
September 1996“ by using the input devices provided by the client
workstation.
| The user interface module on the client interprets the input and
translates it into a format that is understandable by the presentation
logic sub-module on the server. This could, for example, be
“memos”;;;; “A.N.Other”;;;”September 1996”.
14
SERVER
Storage module

Storage logic
sub-module

Application logic
sub-module

Presentation logic
sub-module

User Interface
module

CLIENT
Figure 3-3: The working of the different modules in the UI partition
} The presentation logic sub-module interprets the input provided by the

user interface module and passes it on to the application logic sub-
module. For example:
DOCUMENT_TYPE = “MEMOS”;
AUTHOR = “A.N.OTHER”;
ISSUE_DATE IN “SEPTEMBER 1996”
~ The application logic sub-module will further translate this application

specific information in a way understandable by the information logic
sub-module. This could, for example, be the following SQL-query:
SELECT DOCUMENT_NUMBER, FILENAME

FROM DOCUMENT D, PAGES P
WHERE D.DOCUMENT_NUMBER = P.DOCUMENT_NUMBER
AND DOCUMENT_TYPE = ‘MEMO’
AND AUTHOR = “A.N.OTHER”
AND TO_CHAR(ISSUE_DATE) LIKE ‘__-SEP-96’;
The information logic sub-module on receipt of the SQL-statement will

do the logical translation to determine which data needs to be returned.
It will formulate the necessary requests for the information storage
module.
15
The information storage module translates the logical read requests

into physical attributes, e.g. which disk, which sector and which blocks.
It then executes the read requests, retrieving the required information.
Thereafter the requested information is returned to the information logic
sub-module.
The information logic sub-module receives the information and formats

it in the way that it was requested by the application logic sub-module.
For example:
13524 H:\dir1234\d1145873.wpd
13892 E:\dir9876\f8935467.wpd
14121 Z:\dir7845\e6428193.xls
The application logic sub-module does further operations on the

information, if needed, and returns it to the presentation logic sub-
module.
The presentation logic sub-module on the server decides in which

manner to present the information to the user. In this example a tabular
display of the information may be sufficient.
The user interface module on the client presents the information as

requested by the presentation logic sub-module utilizing the output
facilities of the client.
From the above explanation it is evident that the client has very limited
responsibility in the user interface partition.
3.3 The storage partition
This partition represents a widely used client/server platform. Due to the fact
that vendors frequently develop products for multiple platforms the application
program often addresses certain issues, e.g. integrity checking. The main
reason behind this is the different levels of offered security features between
commercial databases. The server therefore only performs a storage function
and all the other functions are shifted to the client.
16
Identification of the user is done by the client. Authentication and authorization

(access control) involve both the client and server. Access to the application
could be governed by the client, whilst access to the database is governed by
the server.
Any application submitting information to the database must ensure that the
integrity of the database is not damaged through manipulation of the values.
This however leaves the integrity of the database to “good faith” as any
person who can gain access to the database could intentionally or
unintentionally harm the integrity of the data.
In order to ascertain how a query will function within this partition the following
task should be considered: Store the index information of a new electrical
drawing draughted by N.O.Green on 10 September 1996.
Figure 3-4 depicts the execution of above task within a storage partition
environment.
{ The user issues a command utilizing the user interface presented by
SERVER
Storage module

Storage logic
sub-module

Application logic
sub-module

Presentation logic
sub-module

User Interface
module

CLIENT
Figure 3-4: The working of the components in the storage partition

17
the UI module. In this case the command is “to store the index
information of a new electrical drawing draughted by N.O.Green on 10
September 1996”.
| The user interface module interprets the input and translates it into a
format that is understandable by the presentation logic sub-module.
For example: “drawing”;;”electrical”;;”N.O.Green”;;;”10
September 1996”.
} The presentation logic sub-module translates the request further, for

example:
DOCUMENT_TYPE = “DRAWING”;
DOCUMENT_DISCIPLINE = “ELECTRICAL”;
AUTHOR = “N.O.Green”;
ISSUE_DATE = “10 SEPTEMBER 1996”
The request is then passed on to the application logic sub-module.
~ The application logic sub-module interprets the input provided by the

presentation logic sub-module. Firstly it performs several integrity
checks. Amongst others this could include a check that certain values
exist in other tables and that the issue date is not later than the present
date. Thereafter a SQL-statement may be formulated to insert the
necessary record into the database. This may include mandatory index
fields, e.g. DOCUMENT_NUMBER, that possibly can be generated
automatically. An example of such a statement is:
INSERT INTO DOCUMENT

(DOCUMENT_NUMBER,REVISION,DOCUMENT_TYPE,
DOCUMENT_DISCIPLINE,AUTHOR,ISSUE_DATE)
VALUES (“147856”,”01”,“DRAWING”,
“ELECTRICAL”,“N.O.Green”,“10-SEP-96”);
The information logic sub-module will logically translate the write

request and pass it on to the information storage module.
The information storage module interprets the logical write request in

order to perform the physical write. Once the physical write has taken
18
place the information storage module returns a status code to the

information logic sub-module.
The information logic sub-module interprets the status code and

decides on an appropriate action. Actions could include the re-
execution of the previous command and the return of a status code to
the application logic sub-module.
The application logic sub-module’s behavior is governed by the value

of the status code. If the status code implies an unsuccessful addition
of the record then an appropriate corrective action could be decided
upon by the application logic sub-module. A status code will be passed
on to the presentation logic sub-module.
The presentation logic sub-module interprets the received status code

and decides in which manner the information will be best presented to
the user. In the case of a successful addition of the record a change to
the status bar could be appropriate, whereas an unsuccessful addition
of the record might necessitate the display of a message box with a
descriptive error message and suggested corrective actions.
The UI module will receive the instruction to display the output which
was decided upon by the presentation logic sub-module. Thereafter it
performs the necessary actions to update the relevant output devices.
From the discussion of the storage partition it is evident that the client, for the
storage partition, has a much larger responsibility than the server.
3.4 The logic partition
The ideal within a client/server environment is to utilize the client and the
server for the functions that they are respectively good at. The client is best at
displaying information and servers are best at storing information, which
would imply that the UI module must reside on the client and the information
storage module must reside on the server. The question that subsequently
arises is “What about the logic module?” The logic module consists of three
19
sub-modules that can be positioned in various ways. Since the client presents
the user interface the presentation logic sub-module can be located on the
client. The information logic sub-module can reside with the server as this is
where the information is stored. The application logic sub-module could then
reside on the client if no intensive processing is done; or it could reside on the
server if much processing power is needed; or it could be split between the
client and the server to appropriately share computing resources.
Consider the following scenario:
It is assumed that the user wishes to view document “ABCD”. Document

ABCD is a scanned image compressed using a highly efficient compression
algorithm.
Figure 3-5 can be used as reference for discussion on how this will take
place.
SERVER
Storage module

Storage logic
sub-module

Application logic
sub-module

Presentation logic
sub-module

User Interface
module

CLIENT
Figure 3-5: EDMS and the logic partition
20
{ The user manipulates the user interface by using the various input
devices to request to view document “ABCD”.
| The client interprets the input and provides the presentation logic sub-
module with the corresponding request.
} The presentation logic sub-module interprets the request and passes it

on to the application logic sub-module. For example:
REQUEST = ‘VIEWDOC”; DOCUMENT_ID = “ABCD”
~ The application logic sub-module on the client evaluates the request

and supplies the information logic sub-module on the server with the
following request.
SELECT DOCUMENT_IMAGE
FROM DOCUMENT
WHERE DOCUMENT_ID = “ABCD”
The information logic sub-module on the server interprets the request

and translates it to physical read requests.
The information storage module returns the requested information to

the information logic sub-module. The information logic sub-module
formats the information as requested by the user, e.g. trims excess
information off if the block that was read contains non-relevant
information. The requested information is returned to the application
logic sub-module on the server.
The application logic sub-module on the server does the interpretation

of the information. In this case it will apply resource-intensive
decompression techniques. The decompressed image will be passed
on to the application logic sub-module on the client which may apply
further operations on it.
The application logic sub-module on the client will pass the prepared
image to the presentation logic sub-module on the client.
21
The presentation logic sub-module decides how the document should

be viewed and instructs the UI module to display the document.
The UI module will utilize the output devices to communicate with the
user.
This partition thus allows for effective balancing of loads. Clients perform
generally less resource intensive duties, whilst servers execute the more
resource intensive processes. This arrangement allows for the best properties
of both the client and the server respectively to be exploited in order to obtain
the most efficient application.
3.5 ORACLE and the various client/server partitions
ORACLE Corporation has a wide range of relational database management

software available. It ranges from Personal ORACLE, for a PC, to ORACLE
Enterprise Server, for a large distributed environment [ORA97]. The next three
sub-sections will discuss how ORACLE products can be used in the various
client/server partitions.
3.5.1 ORACLE and the UI partition
}
Storage module
Mainframe disk storage

ORACLE ™
Storage logic sub-module RDBMS engine
SQL-based interface
}
Application logic sub-module
Third party
programming
Presentation logic sub-module
tools
UI module UI module
Terminal emulation Not utilized -- character-
software based terminal
CLIENT SERVER
PC Workstation Mainframe
Figure 3-6:ORACLE and the UI partition
22
If an ORACLE database is used in the mainframe environment it is possible to

do all the application development in the typical mainframe environment using
character-based screens. The UI partition can then be attained if the client
workstations are set up to do some terminal emulation, possibly with some
added features, e.g. mouse manipulation. The sole responsibility of the client
then is to translate the user input into a format that is understandable by the
presentation logic sub-module on the server. The aforementioned represents
what was previously presented as the UI partition in Chapter 3. This scenario
is depicted in Figure 3-6.
3.5.2 ORACLE and the storage partition
Personal ORACLE [ORA97] can be installed on personal computers in such a

way that it can act as the information logic sub-module on the client
workstation. The information storage module can still be set up to be on a
server. Using ORACLE’s development tools, or any third party tools that allow
for communication with the database, for example Microsoft Visual Basic,
application programs can be developed on the client.
23
The interface is presented using the windowing capabilities of, for example,
Microsoft Windows. This situation is depicted in Figure 3-7.
3.5.3 ORACLE and the logic partition
The logic partition represents the most popular approach for installing
ORACLE. The ORACLE database engine and storage will reside on the
server. The user interface module is represented by the Windows capabilities.
The presentation logic sub-module can be developed using third party
products on the client workstation. The application logic sub-module is
represented on both the client and the server. On the server this could be
done using the PL/SQL language of ORACLE developing triggers and stored
procedures [ORA92]. Another possibility is to develop separate server
programs which can act on special requests, using a language, e.g. C. In a
UNIX environment this could, for example, be implemented as deamons, i.e.
processes that are always running in the background.
Storage module
Server-based disk storage
Storage logic sub-module
Personal ORACLE ™
Application logic sub-module

Third party program in e.g.
MS Visual Basic
Third party program in e.g.
MS Visual Basic
UI module
Terminal emulation
software
CLIENT SERVER
PC Workstation LAN Server (e.g. Novell server)
Figure 3-7: ORACLE and the storage partition
24
Above scenario is depicted in Figure 3-8.
3.6 Conclusion
This chapter presented three different client/server partitions for which the
security measures that need to be implemented differ depending on the
particular partition implemented and the required security features.
The next chapter will develop a framework based on the security attributes
(chapter 2) and the client/server partitions (chapter 3) to be used when
securing a client/server environment.
Storage module
Server-based disk storage
Storage logic sub-module
Personal ORACLE ™
Application logic sub-module Application logic sub-module

Third party programs in e.g. ORACLE PL/SQL
MS Visual Basic procedures and triggers
Third party programs in
e.g. C
Third party programs in e.g.
MS Visual Basic
UI module
Terminal emulation
software
CLIENT SERVER
PC Workstation UNIX server
Figure 3-8: ORACLE and the logic partition
25
THE EMPTY FRAMEWORK
4.
4 THE EMPTY FRAMEWORK
Chapter 2 defined the different security attributes that need to be preserved in

a secure system. Various client/server partitions were defined and functionally
discussed in Chapter 3.
The questions “How can it be decided which security techniques are relevant
when only some of these attributes require protection?“ and “What influence
does the choice of partition have on the security techniques that need to be
implemented?” now arise. This chapter suggests a strategy for generating a
framework that can be used to answer both the aforementioned questions.
4.1 The framework
The security techniques required may depend on the attributes that need
protection as well as on the client/server partition implemented. The possible
influence of the two aforementioned factors on the security techniques
selected suggests that a two-dimensional matrix could be used to map the
different security techniques.
Figure 4-1 presents the empty framework. The X-axis contains the six
attributes of secure information: integrity, authenticity, confidentiality,
availability, possession and utility. The Y-axis contains three client/server
partitions: the UI partition, logic partition and storage partition. In addition each
of these partitions is divided into a client and server part.
The highlighted entry “A” in Figure 4-1, therefore, presents the standards and
techniques applicable to the client in a logic partition in order to preserve
integrity of the information. Likewise the entry “B” presents the standards and
techniques applicable to the server in a storage partition in order to preserve
the availability of the information.
26
THE EMPTY FRAMEWORK
Integrity Authenticity Confidentiality Availability Possession Utility
Server Client
UI
partition
A
Server Client
Logic
partition
Server Client
Storage
partition
Figure 4 1: The framework
4.2 A strategy for completing the framework
This framework will be completed by exploring several issues.
Currently several evaluation criteria exist. These criteria evaluate a system’s

security in terms of certain pre-set conditions that have to be met to qualify for
a given classification. Chapter 5 will explore these conditions in order to
determine their relevance in the client/server environment, as well as to
determine at which security attributes it is aimed.
Within the open distributed systems arena certain application frameworks

have been developed to set standards for developing secure applications for
the client/server environment. Chapter 6 investigates these application
frameworks and positions the accompanying techniques proposed within the
framework.
An excellent example of client/server technology at work can be found in the

World Wide Web (WWW). Chapter 7 contributes to the framework by studying
security mechanisms applicable to WWW sites.
Chapter 8 presents all of the findings of the previous chapters by providing a

consolidated framework of security techniques.
27
EVALUATION CRITERIA AND THE CLIENT/SERVER ENVIRONMENT
5.
5 EVALUATION CRITERIA AND THE
CLIENT/SERVER ENVIRONMENT
Particular user communities drive most of the standardization efforts in the

computer system security arena. The earlier work of the American
Department of Defense (DoD) probably laid the groundwork for research in
computer security [REIT93]. However, the continued growth in non-military and
commercial type systems lead to the expansion of security requirements in
those areas. A brief look at the Trusted Computer Security Evaluation Criteria
(TCSEC), the Information Technology Security Evaluation Criteria (ITSEC)
and the Common Criteria will be taken. This will be followed by a discussion
of the role that the evaluation criteria will play, firstly in terms of the
client/server environment in general, and secondly in terms of specifically
developing the contents of the framework.
5.1 TCSEC
The Trusted Computer Security Evaluation Criteria (TCSEC) of the United

States Department of Defence (DoD) evaluates security according to
evaluation classes D, C1, C2, B1, B2, B3 and A1 in order of increased
functionality and assurance [DODS85, OSHE91, REIT93].
Each class is identified by a set of criteria that addresses the security policy,
accountability, assurance and documentation [DODS85].
A distinction is made between the rating of products and the rating of installed
systems. This is because specific systems, particularly when networked, may
have certain vulnerabilities in spite of the evaluated ratings of the individual
components of such a system.
28
5.1.1 TCSEC and the client/server environment
The most important aspect of the TCSEC with respect to the client/server
environment is the differentiation between rating products and rating systems.
In the client/server environment this is particularly useful as the installed
system frequently consists of multi-vendor, multi-product installations.
The TCSEC can be used very successfully for evaluating certain components
of the client/server environment. The TCSEC is particularly useful and strong
in the evaluation of database security and operating systems. As pointed out
in [CAEL92] the evaluation process is complex and very time consuming. The
evaluation of a single component, e.g. the operating system, is a large task.
The complexity of this task increases as the number of components
increases. This is due to the complexity of the interaction between the
different components. The TCSEC therefore seems a rather clumsy way of
evaluating a complete system. [CAEL92] also points out that a commercial
developer can at best perform an incomplete evaluation. This is mostly due to
the fact that the developer needs a certain element of trust in the vendor, as it
needs to be assumed that certain steps, for example design and
development, have been fulfilled in the “proper secure way”.
Above scenario certainly holds in the client/server architecture where several

products from potentially different vendors need to interact. Typically
components such as the operating systems, network software, databases and
applications will be sourced from different companies. An effective evaluation
will then require co-operation from all the vendors involved, as well as an
independent evaluation authority to facilitate the whole process. This
“openness” may however necessitate the sharing of perceived “trade secrets”,
which may cause certain vendors not to co-operate fully.
29
5.1.2 Products evaluated against TCSEC
ORACLE is a well-known and widely used database management system. Its

popularity and flexibility lead to it being a popular choice for current
client/server developments. According to [HARR94] ORACLE 7 has received a
C2 rating, while Trusted ORACLE 7 received a B1 rating.
These ratings indicate that ORACLE 7 enforces individual accountability for

user actions through finely grained access control and audit trails. The
Trusted ORACLE 7 version enhances this level of security by constraining the
user even for data that he controls.
5.2 ITSEC
The Information Technology Security Evaluation Criteria (ITSEC) is the

harmonized criteria of France, Germany, the Netherlands and the United
Kingdom. It was created as an effort to establish a set of requirements for
international use.
They introduced the concept of a target of evaluation (TOE), being the

product or system that has to be evaluated. A security target is defined,
containing a precise specification of the features of the TOE that contribute
towards security. This security targets act as the baseline for evaluation and
must contain three items: (1) functionality, (2) correctness and (3)
effectiveness [CAEL92].
Effectiveness provides an acclaimed rating of the minimum strength of the

security mechanisms and is expressed as basic, medium and high. These
ratings are described as follows [CAEL92]:
A basic rating would indicate that the TOE provides protection against
the random accidental subversion, although knowledgeable attackers
may defeat it.
30
A medium rated TOE would provide protection against attackers with

limited resources and opportunities.
A high rating would indicate that the TOE can only be defeated by
attackers possessing a high level of expertise, opportunity and
resources. A successful attack is being judged beyond normal
practicality.
5.2.1 ITSEC and the client/server environment
ITSEC’s positioning in the client/server architecture is very similar to that of

the TCSEC. The TOE that is defined could be a product or a complete
system. As with TCSEC evaluation of a single product is much simpler than
the evaluation of a complete system.
In a typical client/server environment where a system will consist of many

possible products the complexity multiplies as more players appear. For a
successful evaluation of a complete client/server system against ITSEC the
full cooperation of all vendors, as well as an independent testing authority, will
be needed.
The client/server environment lends itself to the modern trend of plug-and-

play technology. Not only can hardware change effortlessly, but as standards
develop the different components of the client/server architecture should
become easily interchangeable. The configuration will therefore be flexible
and potentially continuously changing, making the evaluation of a complete
system very difficult, if not completely impossible.
If it is assumed that the evaluation of a complete client/server system cannot

be better than the worst product in the suite constituting the complete system,
then the evaluation of single products can prove quite useful.
The distinction that is made in ITSEC between functionality, correctness and

effectiveness can be extremely useful in weighing the different ratings of the
31
various products. For example a F2 (F-C2) rating with an assurance level of

E4 may be considered better than a F3 (F-B1) rating with an assurance level
of E2.
5.2.2 Current evaluations against ITSEC
HP-UX is a popular UNIX operating system for the server component in the
client/server environment. The HP-UX operating system, version 6, has been
evaluated against ITSEC as having a functionality class F2, an evaluation
level for correctness of E2 and a minimum strength rating of basic [CAEL92].
This would indicate that HP-UX, version 6 allows for individual accountability
through finely grained access control and audit trails; that it has been
methodically tested and that it should provide protection against accidental
subversion, but could be defeated by knowledgeable attackers [CAEL92].
For version 7 of HP-UX [CAEL92] proposes a basic strength rating of high. This
rating is conditional and can effectively be negated on a sliding scale relative
to the competency of the system administrator. This would indicate that the
security kernel can only be defeated by attackers with a high level of
expertise, opportunity and resources. These conditions seem to be beyond
normal practicality.
Harris states that ORACLE has been evaluated to an assurance level of E3

[HARR94], which according to [REIT91] indicates that it has been methodically
tested and analyzed.
5.3 Common Criteria (CC)
Development on the CC started in late 1993 and the first public “preliminary
draft” was published in late 1994. The development of the CC is a joint effort
between France, Germany, the United Kingdom, the Netherlands, the USA
and Canada in order to align the existing and emerging criteria: ITSEC
(Europe), USA New federal criteria (including TCSEC), CTCPEC (Canada)
and ISO SC27 WG3 security evaluation criteria [OVER95].
32
The main purpose of the CC is to produce a common set of criteria that will
ease the recognition of evaluation results between nations. The primary goal
of the CC is to remain compatible with the individual source criteria and to
provide sufficient flexibility to allow the choice of security functionality and
assurance levels that adequately represent the required security and business
needs [OVER95].
The following key concepts are used in the Common Criteria:
Protection Profile (PP): The PP defines the security needs in a general threat
environment. The PP defines security objectives and security requirements,
respectively describing why protection is necessary and what functionality is
needed to offer the required protection. A PP for security in client/server
environments can therefore be defined in terms of the threats that the
environment must be protected against (hostile outsiders, unavailable servers,
etc.) and the functional specifications for providing the protection (firewalls,
access control restrictions, recovery procedures, etc.).
Security Target (ST): The ST serves both as a definition of the security

functions and of the assurance measures of the product that will be evaluated.
A developer of a product will therefore produce a ST that describes the
implementation of a PP in a product.
Security functionality specification: The security functionality specification will

describe how the functionality that is claimed necessary by the Protection
Profile or Security Target is offered.
Assurance levels: Seven assurance levels are defined, AL1 - AL7, being
graduated classes of security differing in an increasing degree of assurance.
AL0 is reserved for products that failed the evaluation.
33
5.4 Evaluation criteria and the security framework
The evaluation criteria are very general documents that instruct the reader
about the results but, unfortunately, do not specify how to obtain the desired
results. Following is a discussion on some of the criteria and how they are
interpreted in the light of the client/server environment and the proposed
framework (Figure 5-1 refers).
User identification
Several criteria that need to be met whilst evaluating a product using the
criteria have to do with the identification of users that need to use the system.
In addition the issue of proving the authenticity of the claimed identities comes
to play a part. This whole issue is discussed at length in paragraph 6.2.3 and
therefore does not receive attention in this discussion.
Access control
It is important to note that, depending on the security rating required, two

different forms of access control are mentioned: discretionary access control
and mandatory access control.
Discretionary access control refers to the separation of users and data. In

[DODS85] it is pointed out that discretionary in this sense does not mean “take
it or leave it”. It rather indicates that individual users are accountable for their
actions.
For greater security levels mandatory access control refers to the introduction
of security labels for all subjects and objects. A subject can only access an
object with a security label equal or less to its own security label. For
example, if a user (subject) has a security label of confidential then that user
can only access documents (objects) with a security label of open and
confidential. Objects with a security label of secret and top-secret are not
available to that user. The aforementioned example assumes that the security
34
labels are ordered open, confidential, secret and top-secret in order of

increased confidentiality.
The need for mandatory access control over all storage objects and all
subjects will strongly influence the confidentiality of information in terms of
reading the information. If it is considered that control is also exercised over
the writing of information it will also assist in maintaining integrity of the
information (assuming that the low level integrity controls in terms of
communication and storage are functioning properly) in that a user will not be
able to write information with a security label higher than his own. In the
client/server environment mandatory access control can be enforced on the
storage level. Although the information storage module may store the access

documentation
Client
UI
partition
audit facilities security labels; trusted recovery off-site backups documentation
storage and techniques; trusted
memory object re- facility
Server
use management
security labels; configuration documentation

memory object re- management;
use recovery planning
Client
Logic
partition
storage and techniques; trusted
memory object re- facility
Server
use management
security labels; configuration documentation

memory object re- management;
use recovery planning
Client
Storage
partition
storage object re- techniques; trusted
use facility
Server
management
Identification and authentication are covered in the evaluation criteria and w ill be discussed in detail in paragraph 6.2.3
Figure 5-1: The evaluation criteria and the security framework
35
control list the interpretation will happen through the information logic sub-
module. In both the UI and logic partition the responsibility for mandatory
access control will therefore reside with the server. In the storage partition,
however, the information logic sub-module resides on the client and the
responsibility for mandatory access control will therefore reside with the client.
It should be emphasized that the implementation of a mandatory access
control policy strongly relies on the effective implementation of security labels,
i.e. all subjects and objects should be allocated security labels.
Object re-use
The concept of object re-use should also be mentioned. The information

storage module will store objects on physical media, whilst the logic module
will work with “copies” of those stored objects in memory. No information
produced by a prior subject’s actions should be available to the current
subject prior to initial assignment, allocation or re-allocation of any object to
the current subject. This will ensure that information stays confidential, since
no copies of objects would exist for illegitimate use by unauthorized users.
In the UI partition neither the logic module, nor the information storage module
resides on the client and therefore the client will play no role. However, in the
storage partition and in the logic partition objects will reside on the server and
on the client. Care should therefore be taken to ensure that objects are not
illegally (or accidentally) re-used, thereby disclosing confidential information. It
is therefore necessary that object re-use takes place in a synchronized way
between the client and the server.
Trusted recovery
In order to maintain availability of the information the evaluation criteria

require trusted recovery techniques. In the UI partition the main aim of
recovery will be the server, since the client has almost no significance in the
availability of the information. Recovery techniques for the client can be
36
limited to the speedy replacement of the workstation or the availability of

“redundant” equipment.
For the logic partition the importance of the server remains high because the
information is still resident on the server and, therefore, without the server
none of the information will be available. The importance of recovery for the
client, however, increases considerably. Since the means of operating on the
data, i.e. the application logic sub-module, is split between the client and
server, it is vitally important to have a correctly configured client available in
order to utilize the data. Planning for recovery can therefore be more difficult
since it is not easy to keep redundant clients for all the different
configurations. Furthermore, to keep all the different configurations could be
very expensive. This is described by the term “configuration management”.
This term is also used in the TCSEC where it refers to the different versions of
the trusted computing base, not the overall configuration of the system.
If recovery is planned properly it should also guard against loosing possession

of the information. In all three partitions the information resides on the server.
It is necessary to keep off-site backups of all information in order to allow
speedy recovery in event of disasters that can destroy the site where the
server is located. An entry “off-site backups” in the “Possession” column for all
three “Server” rows indicates this in Figure 5-1.
The role of the client in the storage partition becomes even more important,
since the server is essentially only used as an information store and all
processing occurs on the client. As the custodian of the information the server
needs carefully planned, trusted recovery techniques. The importance, of both
trusted recovery for the clients and effective configuration management of the
client configurations, is even greater than in the logic partition.
Security management
The information contained on the server can only be of value if the facility
(server) is managed properly. The effective separation of the operator and
37
administrator functions, which entails the execution of all security relevant

administration duties, including the examination of audit files, are therefore
necessary.
Presentation of information
The usefulness of the information, and more specifically the usefulness of the
security rating of the information, is strongly influenced by the presentation of
the information in human-readable format. It is therefore essential that the
client, which in all three partitions presents the information to the user, always
displays human-readable security labels for the displayed information.
Documentation
In order to ensure that the installed system is used in a meaningful manner it

is of the utmost importance that the necessary documentation is available.
This holds for both the client and the server in all three partitions, albeit to a
different degree depending on the partition implemented. The TCSEC
evaluation criteria stipulate four kinds of security relevant documentation:
security features user’s guide, the trusted facility manual, the test
documentation and the design documentation. The test documentation only
serves a purpose during the classification of the system, whilst the other three
manuals are useful during system operation.
5.5 Conclusion
It is evident that the evaluation criteria, although not directly aimed at the
client/server environment, could provide a useful reference when secure
client/server systems are designed.
38
APPLICATION FRAMEWORKS
6
6. APPLICATION FRAMEWORKS
Whereas the security evaluation criteria are aimed at measuring the security
functionality of a system or product, application frameworks on the other hand
provide a frame of reference in the design and development of a secure
system by providing guidelines as to the security functionality and services
that should be present in a secure system. In other words, the evaluation
criteria stated what should be accomplished without saying how, but the
application frameworks provide a framework as to how certain security
features can be implemented.
In paragraph 6.1 the European Computer Manufacturers Association (ECMA)

framework for developing secure systems will be investigated and the security
techniques which are presented will be highlighted. In paragraph 6.2 the Open
Systems Foundation’s (OSF’s) Distributed Computing Environment (DCE) is
discussed with emphasis being placed on the security techniques that are
presented by the DCE.
6.1 ECMA security framework
The ECMA security framework defines two structural concepts: security

domains and security facilities. A security domain is a management concept
relating to a number of users (subjects) and a number of computing resources
(objects). The security facilities are a modeling technique for developing and
describing a framework for security in an open systems environment. This
framework provides a model from which a complete set of security services
can be developed [REIT93].
In order to facilitate understanding of the ECMA security framework consider

figure 6-1. This provides an overview of the ECMA security architecture by
39
Application and Privilege

Attribute server
{ Authentication
dialogue
“Security server”
User sponsor
| PAC and
“Ticket granting ticket”
Local
applications IAM
} Application selection + PAC
TAM ~ User access decision

CLIENT Application
dialogue
User attributes
SERVER
Remote applications
¤ Global Time service
Figure 6-1: Simplified ECMA security framework
means of a walkthrough of a typical user attempting to logon to a system in

order to gain access to an application.
{ The user sponsor will act as an agent between the user and the system
[PRES91]. The user sponsor resides on the client workstation. When the
user activates his workstation the user sponsor will be the first form of
intelligence that he encounters. The user sponsor will arrange for the
user to be authenticated by the authentication service, using the
authentication mechanism suitable for that user. The authentication
mechanism could, for example, be a password (in the simplest case),
smart card, biometrics or challenge-response token. The user can be
authenticated in a specific role, e.g. manager, clerk or supervisor.
There will be only one authentication service in the security domain,

although the service might be distributed over more than one server.
40
| If the authentication was successful, a security attribute service will

issue the user with a privilege attribute certificate (PAC). The minimum
content of the PAC contains the initiator privileges and the authority
name [KRUY91]. The initiator privileges describes the actions which the
initiator may perform. Alternatively it may contain initiator qualifiers, i.e.
information that delimits which initiator may actually use the certificate.
This could be used to implement proxy access. The PAC could also
include information delimiting the target objects against which the
certificate may be used, time constraints on the use of the certificate
and PAC identifiers for tracing, recovery, auditing and accounting.
According to the contents of the PAC a user will be presented with a

menu of services for selection purposes. These services or
applications can be hosted locally on the client or remotely on the
server.
} If a user selects a service, the user sponsor will invoke the “Initiating
Association Manager” (IAM) on the client to establish a connection to a
“Target Association Manager” (TAM) on the server which hosts the
application. The PAC and the details of the services selected are
passed on to the TAM by the IAM.
~ An access decision is made by the TAM using the privilege attributes in

the PAC, the security attributes in the target application and the
security policy that is in place. The association management facility
provided by the IAM and TAM relieves the application from dealing with
associations between objects that are hosted on different servers.
If access is permitted the TAM will map the privilege attributes in the
PAC to a form appropriate for the requested application. The TAM will
send these mapped attributes to the target application.
The user can now interact with the application in a normal way, with the
user sponsor transparently in the background.
41
The aforementioned represents a simplified view of the functioning of the

ECMA security framework. Other important issues pertaining to the ECMA
application framework include [PRES91]:
1. The framework allows for the implementation of a single login facility.
This is possible because the PAC is a generalized form of certification
and the user does not have to re-authenticate himself before accessing
applications on other end systems, provided that the security policy of
the end system allows it.
2. PACs can be used as a mechanism to confer privileges to other objects.
A PAC could be obtained for an object which should act on behalf of the
user. For example, a PAC may be obtained to allow a text editor to edit
files on behalf of the user. This “proxy PAC” can restrict the rights of the
object acting in proxy, e.g. only allow the text editor to edit files
belonging to the specific user.
3. The framework also allows for an audit and recovery facility that is not
included in this simplified view.
6.1.1 ECMA and the client/server environment
The ECMA security framework was developed with security in an open

systems environment in mind. Since the client/server environment essentially
is an open systems environment the ECMA security framework fits the
client/server environment well.
The user sponsor, local applications and initiating association manager reside
on the client workstation. The ”security server”, as well as the remote
applications and a target association manager, reside on a server node.
Remote applications could be complex databases, image manipulation

servers, object servers or any application normally associated with large
processing requirements. The secure association service can be compared to
specialized “middleware”, i.e. software that provides the glue between clients
and servers [ORFA95].
42
In the following paragraph the security facilities within the ECMA security
framework and the influence thereof on the security framework are discussed.
6.1.2 ECMA and the security framework
The ECMA security services contribute to the security framework. An

evaluation of each of these services in terms of the client/server partitions and
the security attributes follows.
The security attributes service provides certificates in return for an

authenticated identity. These certificates can be used to obtain authorization
for the services to which the user requests access. Since authorization is
essentially an attempt to ensure confidentiality of information it can be said
that the possession of a certificate by the client acting on behalf of the user is
effectively helping to maintain confidentiality. This is independent of the
client/server partition implemented and is indicated with the entry “certificates”
in the “client” row of all three partitions in the “confidentiality” column. The
client will only use the certificate and therefore does not need any specific
logic.
The authorization service enables systems and applications to be

independent of specific security policies [KRUY91]. Access decisions are made
based on the contents of certificates issued to users and the control attribute
package that is associated with the object provided. In the UI partition the
control attribute packages will be stored on the server. The interpretation of
the control attribute packages will be the responsibility of the information logic
sub-module that resides on the server. For the logic partition certain objects,
e.g. application programs, with their associated control attribute packages
reside on the client. The storage objects, however, still reside on the server,
hosting more associated control attribute packages. If the storage partition is
considered, the client will do the interpretation of the control attribute package
since the information logic sub-module resides on the client. This distinction is
indicated in Figure 6-2 by placing the “control attribute package” entry in the
43

OSI level services
Client
UI
partition
OSI level services security attribute control attribute recovery
server package; secure
association server;
inter-domain service;
Server
cryptographic service
OSI level services certificate; recovery

cryptographic
service; control
attribute package
Client
Logic
partition
OSI level services security attribute control attribute recovery
server package; secure
association server;
inter-domain service;
Server
cryptographic service
OSI level services certificate; control recovery

attribute package;
secure association
service; inter-domain
service;cryptographic
Client
Storage
partition service
OSI level services security attribute cryptographic service recovery
server
Server
Figure 6-2: ECMA and the security matrix

“confidentiality” column and in the “client” row for the storage partition. For the
UI partition the “control attribute package” entry is in the “confidentiality”
column and in the “server” row. For the logic partition the “control attribute
package” entry is in the “confidentiality” column and in both the “client” and
the “server” rows.
The secure association service provides facilities for setting up secure

associations between objects. The inter-domain service provides for the
translation of security attributes between different security domains. This
could, for example, be the mapping between read- and write-privileges in one
domain to read-, update-, create-privileges in another domain. Both the
secure association service and the inter-domain service relate to the
information logic sub-module in that they are involved with the relation
between objects that will be stored on the server either as applications or as
storage objects. The application logic and the information logic sub-module
reside on the client for the storage partition, positioning the secure association
service and the inter-domain service on the client. This difference is indicated
44
through the use of the “client” row in the storage partition and the “server” row
in the UI and the logic partition.
The aforementioned services include other facilities, e.g. a cryptographic

facility, a security state facility and a security recovery facility [KRUY91]. In
order to ensure confidential communication it is necessary for both the client
and server in all three partitions to host a cryptographic facility. However, the
UI partition does not allow for such logic to be present on the client. The
cryptographic facility is indicated in Figure 6-2 in both the “logic partition” row
and the “storage partition” row to ensure confidentiality. If encryption is done
on information on the server then the client will need a cryptographic function
to decrypt the information and vice versa. The cryptographic facility is
indicated for the server in the UI partition in order to allow for the encryption of
information while stored on the server. The security recovery facility acts on
certain security events. Recovery always points to the “making available
again” concept, which is indicated in the availability column in Figure 6-2. In
the UI partition recovery is only needed on the server as only the presentation
of the user interface is occurring on the client. However, for both the logic and
storage partitions recovery facilities are necessary on the client and the
server.
Figure 6-2 summarizes ECMA’s role in the development of the client/server

security framework. The following section evaluates another application
framework, called OSF DCE.
6.2 OSF DCE
OSF, the Open Software Foundation, is an integrated consortium of

information technology suppliers who came together to agree on and develop
an open applications environment. This lead to the defining of the Distributed
Computing Environment (DCE).
The DCE consists of many integrated components, each of which provides

important functions, but it is the DCE Remote Procedure Call (RPC) software
45
that makes the distributed operation possible. If the underlying operating

system does not support threads then DCE provides a component to enable
threading, i.e. to handle multiple concurrent requests.
When considering Figure 6-3 it can be noted that the DCE also provides for a
directory service, a time service and security services, each of which is briefly
discussed in the following paragraphs.
The directory service provides the DCE’s distributed applications with a place
to store and retrieve information concerning resources available in the
distributed computing environment. It makes it possible to contact people and
use resources anywhere in the network without knowing their physical
location.
The time service allows for synchronization of clocks in order to be able to

determine the sequencing, duration and scheduling of events, independently
of where they occur [ROSE93].
The DCE security service provides authentication and authorization services

that assist in protecting DCE resources against illegitimate access. For
example, a directory server allows a user only to create a directory once the
Application
DCE Distributed File System
Directory Service
Security Time
X.500 CDS
Remote Procedure Calls (RPCs)

Threads
Operating System
Network Transport
Figure 6-3: OSF DCE Components
46
CLIENT SERVER
CDS clerk CDS clerk
DTS clerk DCE

DTS clerk
client
software
Security clerk Security clerk
DCE runtime library DCE runtime library
CDS server
DCE
server DTS server
software
Security server
Figure 6-4: DCE client and server software

user’s identity has been verified through the DCE authentication service.
Kerberos (discussed in the section on authentication mechanisms) has been
incorporated in the DCE as the authentication mechanism. Access control
lists can be associated with individual resources, specifying which operations
which user may perform.
6.2.1 The DCE and the client/server environment
OSF developed the DCE for, as the name suggests, open distributed
computing environments. The DCE can therefore be used with great success
in the client/server environment. Figure 6-4 shows the client and server
software components that are involved when DCE is implemented. The DCE
runtime library should be present on both the client and the server. This library
provides the RPC and DCE threading capabilities. The other client software
includes the clerks for the Cell Directory Service (CDS), for the Domain Time
Service (DTS) and for the Security Service. These clerks are responsible for
the interrogation of the CDS server, for the synchronization of the local clock
with the DTS server and for the communication with the security server.
The server components could be implemented as separate machines, or

alternatively as one server.
47
6.2.2 The DCE and the security framework
As a result of the specialized software used on the client it can be reasoned

that the DCE does not support implementation in the UI partition. The
presence of the DCE runtime libraries and the various clerks represents
definite application logic on the client, thus ruling out the UI partition. This is
indicated in Figure 6-5 by the omission of entries for the “UI partition” row.
The presence of the DCE runtime libraries on both the client and the server
ensure accessibility of the DCE functionality. This need is depicted in Figure
6-5 by placing a “DCE runtime” entry in both the “client” and “server” rows of
the logic and storage partition for the “availability” column.
Authorization using a DCE environment allows the usage of access control

lists (ACLs). ACLs associate users and objects by allocating rights.
Interpretation of the ACLs in the logic partition lies with the server, which is
indicated in Figure 6-5 in the “confidentiality” column for the “server” row of
the logic partition. In the storage partition the client does the interpretation of
the ACLs since the information logic sub-module resides on the client. Figure

Server Client
UI
partition
DCE runtime
Server Client
Logic
partition
ACLs DCE runtime;
DFS
ACLs DCE runtime

Server Client
Storage
partition
DCE runtime;
DFS
Catered for by DCE through the use of Kerberos. Discussed in parraph 6.2.3
Figure 6-5: OSF DCE and the security framework
48
6-5 depicts this with an “ACLs” entry in the “confidentiality” column of the
“client” row of the storage partition.
DCE uses the Kerberos authentication mechanism that will be discussed in

the next section [SCHI95, ROSE93]. Kerberos will be discussed next in order to
provide more detail on the role of authentication mechanisms. In Figure 6-5
the “authenticity” column is shaded in order to indicate that DCE do allow for
authenticity , but more detail will be given in Figure 6-6.
6.2.3 Kerberos
The Kerberos authentication system has been developed at the

Massachusetts Institute for Technology (MIT) within the Athena project
[GOLL93] and is named after Cerberus, the watchdog of hell in Greek
mythology.
Users using Kerberos are authenticated through the possession of a pre-

arranged cryptographic key that is derived from their passwords, which they
share with the Kerberos Authentication Server (KAS) through a one-way
function. The KAS issues a ticket which, in turn, is used to obtain the
necessary tickets to access other network services which requires
authentication, from Ticket Granting Servers (TGSs).
Figure 6-6 (next page) represents the process involved in establishing a

mutually authenticated message exchange between client C and server S.
The following notation is used in explaining the functioning of the Kerberos

protocol:
KX,Y the encryption key shared between parties X and Y
{I}KX,Y I encrypted using the encryption key shared between X and Y.
TI timestamp i
WX the address of the workstation of X
L the lifetime of a ticket.
49
Kerberos
Authentication
Server (KAS)
Ticket
Granting
| Server (TGS)
~
{ }
Client Server
C S
Figure 6-6: Mutual authentication using Kerberos
The authentication prototcol for Kerberos Version 5 is summarized below

[GOLL93,KOHL94,RFC1510]:
Assume that client C wishes to communicate with server S. At login the client,
C, request a ticket for the TGS from the KAS. Message { contains C’s
identity, the name of the TGS and a timestamp.
{ C, TGS, T1
The KAS generates a session key, KC,TGS, later to be used between C and
TGS. It also generates a ticket containing this session key, a timestamp, the
lifetime of the ticket and the client’s name. This ticket is encrypted using a pre-
arranged key that it shares with the TGS and it is sent to C in message |.
| {KC,TGS}KC,KAS , {TicketC,TGS}KKAS,TGS ,where

TicketC,TGS = {KC,TGS, C, TGS, T2, WC, L}
The client, C, stores this encrypted ticket and calculates KC,TGS using its secret
key KC,KAS. Hereafter C requests a ticket for communication with S from the
50
TGS. Message } contains C’s name and a timestamp, encrypted with KC,TGS
as well as the encrypted ticket and the identification of S.
} {C,T3,WC}KC,TGS, S, {TicketC,TGS}KKAS,TGS
The TGS decrypts the ticket using KTGS,KAS and validates the timestamp
against the local clock. Thereafter it uses KC,TGS to decrypt the request. Upon
success a random session key, KC,S, is generated for use between C and S at
a later stage. The session key is encrypted using KTGS,C. Message ~ consists
of this encrypted random session key and a ticket containing the session key
and the timestamp and lifetime encrypted using KS,KAS, the shared key
between S and KAS.
~ {KC,S}KC,TGS , {TicketC,S}KS,KAS where
TicketC,S = {KC,S,C,T4,L}
C stores the encrypted ticket and decrypts the new session key.
Message is sent from C to S containing C’s name and address and a

timestamp T5 encrypted with the new session key, as well as the encrypted
ticket received in message ~.
(5) {C, T5, WC}KC,S , {TicketC,S}KS,KAS
The server, S, firstly decrypts the ticket, verifying its timeliness, before
decrypting the rest of the message. Upon successful verification and
decryption C is considered authentic by S.
Server S replies in message with T5+1 encrypted with the session key KC,S.
(6) {T5+1}KC,S
C decrypts the message and compares it with his own copy of T5. Upon
successful verfication S is considered authentic by C.
51
6.2.3.1 Kerberos and the client/server environment
The Kerberos authentication protocol has been designed for authentication in

an open systems environment and, therefore, proofs to be very useful in the
client/server environment as an authentication mechanism.
The dependence of the protocol on timestamps, however, presents us with a

shortcoming. Since the timeliness of each message is checked by timestamps
reasonably synchronous clocks are required within the whole system
[GOLL93]. This should not present problems if the client/server system
operates within a single computing realm. With the explosion of networking
and related technology it is, however, highly likely that access to the
client/server system will be widespread and that synchronous clocks will be
much more difficult to manage. It is a necessity that the clocks themselves
should also be secure.
6.2.3.2 Kerberos and the security framework
Kerberos requires the client to have some intelligence. If messages {, } and

, originating from the client are considered, it can be seen that the above
statement is justified. The client at least needs an encryption/decryption
facility. Furthermore, because of the dependency of Kerberos on timestamps
it is necessary that the client has a clock which can be synchronized with a
global time service.
Providing aforementioned facilities in a client/server environment, whilst

utilizing the storage and logic partitions, should not present any problems
since the client should have sufficient specifications to fulfill the additional
requirements.
52
In the UI partition, however, the amount of logic required would indicate that
much more than just the presentation of the user interface is required from the
client. From the above it is evident that the Kerberos authentication scheme
does not suit the UI partition. No entries in the UI partition row is therefore
made in Figure 6-6.
The requirements are the same, regardless of the partition implemented. On

the client some functionality is required which for the purpose of the security
framework will be referred to as the Kerberos client software. This software
will be necessary for communicating parties to be authenticated. This is
appropriately indicated on the framework in the column “authenticity”. Part of
the software, however, will provide cryptographic support to protect the
confidentiality of the information being exchanged. This need for
cryptographic support is appropriate labeled in the “confidentiality” column
and the “client” row of all three partitions.
Similarly, on the server some specialized server software is needed. This

software will provide the means for communicating parties to be

Client
UI
partition
Server
Kerberos client cryptographic

software support
Client
Logic
partition
Kerberos server cryptographic trusted third
software; KAS, support party
Server
TGS
Kerberos client cryptographic

software support
Client
Storage
partition
Kerberos server cryptographic trusted third
software; KAS, support party
Server
TGS
Figure 6-7: Kerberos and the security framework
53
authenticated. The cells formed by the “server” rows of the logic and storage
partitions and the “authenticity” column are appropriately labeled with
“Kerberos server software”. The need for cryptographic support to ensure
confidentiality of exchanged information is shown by a “cryptography support”
label in the cells in the “confidentiality” column representing the server in the
logic and storage partitions.
The need for a trusted third party, in the form of a KAS and TGS, exists
whenever Kerberos is implemented. Since this is a specialized service
provided for authentication it is indicated in the “authenticity” column in the
cells representing the server requirements for all three partitions. The KAS
and TGS could be implemented as separate machines, as one machine
different from the server, or as part of the server. Without the user
authenticating no information will be made available. The presence of a
trusted third party is therefore not only necessary for authentication, but also
for ensuring information availability. Since the trusted third party can be seen
as a specialized server this argument is reflected in the security framework by
the entry “trusted third party” in the “server” rows of both the “logic partition”
and “storage partition” columns.
6.3 Conclusion
This chapter presented ECMA and OSF DCE as two application frameworks
that can contribute significantly towards the identification of security
functionality required to secure the client/server environment.
Other techniques and standards to follow in the development of secure

client/server systems do exist, but is not presented as part of this thesis. It is
foreseen that a study of the X.509 standard [ISO90] could possibly also
contribute towards the security framework, particularly in the usage of public
key cryptographic techniques.
The following chapter will address the contribution that current research on
World Wide Web security can make towards the security framework.
54
THE WORLD WIDE WEB
7.
7 THE WORLD WIDE WEB
The Internet, which includes the World Wide Web (WWW), is the fastest
growing communication medium in the world. Some of the most important
issues and developments on the Internet, therefore, warrant closer inspection.
Originally the WWW was created for scientific and research purposes, but
soon non-academic organizations world-wide, ranging from flower shops to
government institutions, were publishing WWW pages on the Internet.
Since its creation in 1992 [MAGI95], the amount of Internet traffic used by the
WWW, has increased from approximately 72 megabytes to over 200 000
megabytes in one year. By November 1994, WWW traffic accounted for more
than 3 million megabytes. WWW servers have also grown from 50 in January
1993 to over 1500 in June 1994 [MAGI95]. Businesses have realized that the
WWW is a very viable communication medium for various business needs,
e.g. displaying product information, making bookings or even purchasing
products. Information, furthermore, is available 24 hours a day, 365 days a
year. Any company that is proactive and gearing up for the 21st century must
consider using the WWW, either to display product or company information or
for commerce. Although other, more traditional means of communication, e.g.
television, is by no means obsolete yet it can be seen that the normal
broadcast communication environment has changed to an environment of
information on demand. The differences between the traditional broadcast
media and the WWW are listed in Table 7-1 [VISS96].
Client/server systems, in general, meet the criteria of the interactive

broadcasting environment. There are attributes which are not different from
the traditional broadcasting media, however their importance is increased due
to the nature of the threats that are introduced by them. For example, in both
the scenarios the actual server and its location are transparent to the end-
55
THE WORLD WIDE WEB
user [ORFA95]. This allows for masquerading as a server. However, due to the
nature of the information content (as well as the costs involved) the possibility
of a masquerading threat is considerably greater in the client/server
environment. Note however that the possibility of tracing such a
masquerading server is easier in traditional broadcasting than in interactive
broadcasting (see the fixed/variable identity in Table 7-1).
Traditional zero-risk broadcasting Interactive broadcasting
e.g. television e.g. the World Wide Web

Unidirectional systems Bi-directional systems
Information travels one way only, which is Information travels in both ways between the
from the sender (server) to the receiver client and the server. This information may
(client). Nothing is sent back to the sender. be public information, such as the client’s
name, or private information, such as the
client’s credit card details.
One-to-many systems Many-to-many systems
There is one sender (server) with many Information can, in principle, be transferred
receivers (clients). from any computer system on the WWW
(server) to any other computer on the WWW
(client).
Fixed identity Variable identity
The sender’s (server’s) identity is fixed. The sender’s identity (and that of the client) is
Within your geographical area, you can easily software programmable which makes it
establish where the transmission is coming difficult to identify and validate the identity of
from and you can be sure that transmission is the client and the server.
not coming from anyone else claiming to be a
sender.
Passive content Active content
Information is sent as passive content. The Information can be sent as active content.
information that you receive can only be Information that is sent over the Internet can
displayed on your television set and has no be data or programs. These programs can
way of controlling your TV by, for example, be Java programs or CGI scripts which can
changing channels, changing the colors of compromise the security of both the client
the display or adjusting the volume. and the server. Even the data is a potential
security risk. If you download a file that calls
an external viewer program, the client’s
security could be compromised.
Table 7-1: Differences between traditional broadcast systems and the WWW
56
THE WORLD WIDE WEB
WWW servers are designed for public usage and this open-endedness is the
reason why World Wide Web security has become an issue. Two main
security issues are relevant: (1) how to transmit information over the Internet
in a secure fashion, and (2) how to protect the WWW servers and clients from
unwanted access. The next paragraph will discuss the problems that can be
encountered if the environment is not properly secured.
7.1 The WWW and a secure environment

Access to a WWW resource is generally obtained according to the following
steps, as depicted in Figure 7-1:
{ The user selects a link on a WWW page.
| The browser interprets the selection and sends a request to the
{ |
User }

Client Server
Storage
C S
~

Figure 7-1: Functioning of the WWW
appropriate server.
} The request from the browser is accepted and processed by the server
by validating the request.
~ The user is informed of the current status of the request.
The server retrieves any applicable data from the relevant storage
area.
57
THE WORLD WIDE WEB
The server sends the requested media or text file to the browser to be
interpreted.
The user accepts information from the server.
The user views either the rendered WWW page by means of the
browser or the external media by means of a viewer.
Certain security issues in this process should be considered. The issues will
be discussed under two headings: Server security issues and Client security
issues.
7.1.1 Server security issues
Problems that influence the server security include the server operating
system environment, the server process, Server Side Includes (SSIs) and
Common Gateway Interface (CGI) scripts. These potential security
vulnerabilities are briefly discussed below.
The operating systems environment
The operating system environment in which the web-server is executed needs

special consideration. Access permissions on files are extremely important
since incorrectly specified permission will introduce further vulnerabilities to
the system in that files could be altered, deleted or executed by unauthorized
users.
The server process
If the web-server process is initiated with superuser privileges then subverting

the server could allow commands to be executed with superuser privileges.
Web-servers therefore allow for certain restrictions to be implemented by
means of global configuration files. Such issues include restricting access to
certain areas of the file system, restricting access to usernames and
passwords, as well as restricting access to specified computer systems.
58
THE WORLD WIDE WEB
The server operating system may include, e.g. the ability to change the
effective root directory of the file system. The UNIX operating system
implements this as the chroot() command, restricting the web-server view of
the file system to a specific sub-tree [HPUX91].
Server Side Includes
Server Side Includes (SSIs) allow users to place commands in HTML

(Hypertext Markup Language) documents that enable users to execute
arbitrary programs on the server. These commands are executed when the
HTML document is loaded. The commands are run with the same privileges
as the web-server deamon, again emphasizing the need to carefully evaluate
the environment in which the deamon is executed.
Common Gateway Interface Scripts
The Common Gateway Interface (CGI) is a standard for interfacing external

applications with WWW servers. The CGI introduced dynamism to the WWW.
CGI scripts can be used, for example, to interface a DBMS with the web-
server. This would allow the user to, for example, query a database for current
pricing and availability when doing hotel reservations.
CGI scripts could intentionally or unintentionally leak information about the

server which could assist an intruder in gaining unauthorized access to the
server. Remote users could also trick certain vulnerable scripts into executing
commands although the users may not have the appropriate authorization
[STEI96]. Four strategies are suggested by [BUHL95] to protect misbehaving
CGI scripts:
• Configure the server deamon to limit the use of scripts.
• Program defensively.
• Use wrapper programs to launch the scripts after arranging for a more
secure environment. Wrapper programs do not generate any response to
59
THE WORLD WIDE WEB
a request, but only arrange for another program to handle the request and
generate a response.
• Arrange barriers between the web-server and the resources that need
protection. These barriers are known as firewalls and will be discussed in
more detail.
Firewalls
A firewall is a collection of filters and gateways that shield trusted networks

within a locally managed security perimeter from external, untrusted networks.
Firewalls are generally used to protect networks against unauthenticated

logins but it can also be used to block traffic from the outside to the inside, as
well as from the inside to the outside [BUHL96]. Firewalls provide a single point
where the precise access to the network can be controlled and it can provide
important logging and auditing functions.
A firewall can either be implemented at network level by using a packet filter,

that permits access based on information in each packet of data, or at
application level, by using proxy servers, which act as intermediaries between
clients and servers. A proxy acts as a server to an application client and as a
client to an application server. The proxy server can therefore monitor all
communications, only allowing packets that it deems trustworthy to enter the
network.
Firewalls, unfortunately, cannot protect networks against all possible attacks.

It can, for example, not protect against the automatic launching of a malicious
program. Java (discussed in paragraph 7.3) can also still traverse a firewall,
i.e. execute malicious code on the client.
Above discussion identified certain security threats pertaining to the server on

the WWW. Certain security issues on the WWW, however, relate to the client.
The next section investigates these security issues.
60
THE WORLD WIDE WEB
7.1.2 Client security issues
Automatic application launches
The WWW client can launch applications automatically, provided that the
application is available to the client. This allows the client to provide, e.g. a
document to a user in an immediately useful format. At the same time it
introduces a new vulnerability to the WWW environment. Several applications
integrate a macro language into their environment in order to allow for
automation of the tasks performed by them. However, these macro languages
proof to be very powerful. For example, it could allow for the execution of
operating system commands such as the delete file commands. This would
allow a user to publish a file on a server claiming to be something of general
interest. On viewing the file the client will launch the application and in doing
so execute a command to delete all files on the local storage. The user will
only realize this after he has lost all his data.
Java
Since Java code is downloaded to the client, a Java program can contain
code that can potentially harm the client. Java and its security features and
problems are discussed in paragraph 7.2.
7.2 The WWW and secure transfer of information
In order to be able to conduct business on the Internet it is necessary to be

able to pass information securely between the different business partners.
Several secure payment protocols exist. STT, the Secure Transaction

Technology protocol, jointly developed by a VISA/ Microsoft alliance and the
Secure Electronic Payment Protocol (SEPP) which resulted from collaboration
between MasterCard, IBM, Netscape and several other parties are two such
protocols [VSOL96a]. Early in 1996 these two protocols, independently
announced by VISA and MasterCard were replaced by SET (Secure
61
THE WORLD WIDE WEB
Transaction Protocol), a secure payment protocol jointly developed by VISA

and MasterCard [VSOL96b].
The SET protocol is based on the theory of public key certification. This is
based on the ability to decrypt messages signed by a public key only by
possession of the corresponding private key. The protocol furthermore relies
on the existence of a trusted third party referred to as the certificate
management center responsible for the publishing of the public keys.
Aforementioned protocols enable trading on the Internet. Another noteworthy

issue pertaining to the Internet is the introduction of Java. The development of
Java led to the solving of some problem issues on the WWW, but it also
introduced other security issues. The next section positions Java within the
client/server security environment.
7.3 Java and security
Java, developed by Sun Microsystems [FRIT96], has revolutionized the WWW.

Java has changed the WWW from a distribution medium for static pages to a
truly interactive environment, by allowing small programs called “applets” to
be loaded and run by the user’s browser while browsing the WWW. Java is an
object-orientated language that is based on C++. Therefore everything that
can be done in C++, should also be possible in Java. Java provides
executable content to WWW browsers with an embedded Java interpreter and
runtime library. The WWW browsers download these Java applets and the
Java interpreter executes the program [DEIT97, NEWM96].
The applets are the same for all operating systems, only the interpreter will
change. This machine independence is a major advantage as it allows
software developers to write applications without considering the type of
machine that the applications will run on. Also, software developers do not
have to be concerned about end users installing programs or upgrading the
systems, as this could be done automatically from anywhere in the world
[SCOT96].
62
THE WORLD WIDE WEB
Java makes it unnecessary to use external viewers. As stated previously,

automatic application launches present definite security vulnerabilities that
have to be addressed. Java has eliminated the need for these viewers, by not
recognizing any file types whatsoever. When a Java browser receives a file, it
also receives the means through which to view the file.
7.3.1 Java security features
Java has built-in security mechanisms that act at four different levels of the
system architecture [LEMA96]. These security mechanisms are:
(7.3.1.1) The language itself is designed to be safe and its compiler ensures
that the source code does not violate its safety rules.
(7.3.1.2) All bytecodes are screened by Java’s runtime engine to ensure that
an altered compiler does not violate the safety rules.
(7.3.1.3) The class loader verifies that classes do not violate name space or
access requirements.
(7.3.1.4) A final layer relies on security and integrity guarantees from the
previous three layers, using API-specific restrictions to prevent applets from
performing any destructive functions.
A discussion on each of the security mechanisms follows [LEMA96, NEWM96]:
7.3.1.1 A language designed to be safe
As previously mentioned, Java is based on C++. A major security problem

with C++ is the use of pointers (for example, running off the end of an array).
Java has eliminated this problem completely by eliminating pointers from the
language. Java also deals with potential problems by the use of garbage
collection to recover unused memory, instead of relying on explicit user
deallocation. Classes are declared as final, which disallows a programmer
from subclassing a critical library class or overriding the methods of a class.
63
THE WORLD WIDE WEB
Java is also designed to be a type-safe language. This entails that the

compile time variables and the runtime variables are guaranteed to be
compatible, which prevents the forging of access to objects to get around
access control.
7.3.1.2 Verifying the bytecode

In order for Java applets to be as portable as possible, the Java compiler does not
compile to machine code, but instead compiles to bytecodes for an architecture
independent virtual machine. The Java interpreter runs a program by interpreting
these bytecodes. Therefore, applets are transmitted in bytecode form instead of
source code or machine code. These bytecodes are verified by a bytecode
verifier to ensure that they were generated by a trustworthy compiler and meet all
the safety requirements.
The verifier checks that the applet conforms to the Java language specifications
and that there are no violations of the Java language rules or name space
restrictions. The verifier also checks for common violations of memory
management, like stack overflows or underflows. Furthermore, it is checked that
methods are called with appropriate arguments of the appropriate type, i.e. that
no illegal type casts, which could allow a hostile applet to corrupt part of the
security mechanism or to replace part of the system with its own code, are done
[FRIT96].
The verifier is crucial for the security of Java applets, as it only allows bytecodes
that passed the security test through.
7.3.1.3 The class loader

The class loader is similar to the verifier, except that it operates at a higher level.
The class loader protects classes from other classes. Firstly it ensures that
external classes do not replace internal classes. The internal classes define the
file system’s I/O primitives, and no external class should be allowed to replace
these classes and spoof Java code into using dangerous versions of these
primitives.
64
THE WORLD WIDE WEB
The class loader also ensures that classes cannot call other classes, unless
methods are explicitly declared public in classes. This implies that classes from
any other origin than your local computer cannot even view the file system I/O
methods, unless your system allows them to do it. This also implies that no
applets can access another applets’ methods or variables without the user
applet’s permission.
7.3.1.4 The class libraries

At each layer additional security features are added. The final security layer is the
Java class libraries themselves, which have several carefully designed classes
and API’s. These libraries provide file system access, network access, a window
toolkit and a variety of other tools. Correct library specification is of critical
importance as the libraries are the part of the Java runtime that provide access to
the system resources.
7.3.2 Java-enabled browsers

The mere fact that your class and libraries are secure does not ensure security as
the Java-enabled browser used might not correctly implement these security
features.
Although the security mechanisms have made Java secure for the server and
in part for the client, Java is not without other security problems. For example,
Java applets create windows, but this same feature can result in locking or
crashing the Java-enabled browser by opening too many windows [LADU96].
Other problems that may be encountered include making loud noises,
refusing to terminate, shutting down other applets and forging e-mail. Java
applets are programs and need to use the host computer’s resources to
execute. This property makes them untrustworthy programs, since users do
not want to download a small program that could wipe out their hard disk or
send private data over the network.
65
THE WORLD WIDE WEB
These applets are called hostile applets. A hostile applet is any applet that,
when downloaded, attempts to monopolize the system or exploit the system’s
resources in an inappropriate manner. A hostile applet thus is an applet which
performs, or causes you to perform, an action which you would not otherwise
care to do [LADU96]. A large variety of hostile applets exist and it is a very
difficult task to build effective defenses against all of these applets.
An example of a hostile applet is one that forges electronic mail by interacting

with the “sendmail” command. This allows a person to send an electronic
mail message from anyone to anyone [LADU96]. This in itself is not a problem,
as the header information includes the sender’s identity. The problem
however arises when this is done by using someone else’s account without
authorization, as is the case with this program. By viewing the applet, the user
is forced to connect to a specific port on the applet’s WWW server. The
applet sends an electronic mail message to the author and the header
identifies the user (or the user’s machine) as the originator of the message. If
the author views the mail header, he can obtain the user name of a person
who was viewing the applet. This is obviously undesirable and a potential
security risk.
Firewalls are powerless against hostile applets, as an attack would originate

behind the firewall [FRIT96]. There are currently only two ways of securing the
client against hostile Java applets [ONLI95]: Firstly the Java feature in the
browser should be disabled and secondly, an HTTP proxy server could be
used which disables Java applets by not fetching Java '.class' files. The
Online Business Consultant [ONLI95] suggests that users should avoid using
Java-enabled browsers (such as Netscape) and that Java sites should be
avoided until complete safety can be confirmed.
7.4 Internet and the security framework
The previous paragraphs showed that security is indeed an issue on the

Internet. Certain issues were discussed and high-level suggestions presented.
66
THE WORLD WIDE WEB
Figure 7-2 presents the suggested solutions in terms of the security

framework.
Currently the security issues on the Internet focus mainly on authorization

issues, in other words confidentiality. The typical mode of operation on the
Internet relates well to the logic partition. A server provides some services,
e.g. price lists, through an application residing on the server. The client
accesses that information through a browser application, possible utilizing
other programs that are available on the client.
In the typical Java environment the client does not store the application, but it
is downloaded whenever accessed. The Java interpreter, however, resides on
the client, putting a distinct logic partition flavor to the environment.
Another typical service on the Internet is to download information from a

Client
UI
partition
firewalls
Server
firewalls no Java, no
automatic
application
Client
Logic
partition launches
firewalls; limit
execution
Server
rights; limit root

environment
firewalls no Java, no
automatic
application
Client
Storage
partition launches
firewalls; limit
execution
Server
rights; limit root

environment
Figure 7-2: The Internet and the security framework
67
THE WORLD WIDE WEB
server. This resembles the storage partition since the server only acts as a
storage area. The software can be seen as part of the operating environment
rather than a software application.
At this stage operations on the Internet do not take the form of the UI partition.
Leaving the UI partition “client” row empty in the security framework (Figure 7-
2) indicates this. However, issues pertaining to servers in the environment,
even if not web-servers, will be entered.
Firewalls protect servers from unauthorized access, whilst also protecting the
client identity in the case of a proxy firewall. This is indicated by a “firewall”
entry in the “confidentiality” column for the “logic partition” and “storage
partition” rows. Firewalls, however, protect all servers including the non web-
servers and therefore a “firewall” entry is also included in the “confidentiality”
column for the “server” row of the UI partition.
As pointed out all processes providing web services should be run with
minimum rights. This is indicated in the “server” rows of the logic and storage
partition in the “confidentiality” column by an entry labelled “limit execution
rights”. In the same cells the entry “limit root environment” indicates the need
to change the perceived view of the superuser to the absolute minimum.
Automatic application launches and Java could cause malicous or annoyance

code to be executed. This would result in temporary unavailability of
information since the client workstation will be temporarily unavailable. The
need to allow neither automatic application launches, nor the execution of
Java applets in order to maintain availability of workstations are therefore
indicated by the entry “no Java, no automatic application launches” on the
intersection of the “client” rows of the logic and storage partitions and the
“availability” column.
68
THE WORLD WIDE WEB
7.5 Conclusion
This chapter discussed several security issues in the client/server

environment that specifically surfaced with the fast growth of the Internet.
The next chapter will present some other issues that could contribute to the
security framework. It will present a consolidated security framework,
comprising of the entries in the individual “matrixes”.
69
THE CONSOLIDATED FRAMEWORK
8.
8 THE CONSOLIDATED FRAMEWORK
This chapter will evaluate the role of user interface design in securing a
system. Furthermore it will present some other issues, such as checksums,
which could not be positioned otherwise and position them in the framework.
Finally the chapter will complete the security framework by consolidating all of
the matrixes presented.
8.1 UI design issues for the client/server environment
This section provides proof that the design of the user interface can indeed
contribute to the security of the system.
If certain options in the application are not available to a user two options
exist: display the option but disallow access or don’t display the option at all. If
the option is not displayed then a user may not be tempted to attempt
unauthorized access to them. However, it is important to always justify the
decision. For example, because of complexity in the system the cost incurred
by additional development and the additional training of users and writing of
manuals may not be justified by the value of the information protected.
Standardization through the continuous display of all possible options and the
disablement of certain of the options will flatten the learning curve of users
and result in training being easier and cheaper, but it may be detrimental to
the security of the system.
The user interface reflects the state of the system. It will therefore be
responsible for requesting password information from the user. It is important
that the user interface will not display any password information in clear text.
This will prevent accidental disclosure of passwords to bystanders.
70
Aforementioned examples show that the user interface, which is often largely
ignored, can indeed play a role in securing a system.
8.1.1 UI design issues and the security framework
As is pointed out in the previous paragraph certain design issues will influence
the overall security of the system to a large extent.
In certain instances potential breaches in confidentiality can occur due to a

lack of proper design of the user interface. Special users for specific reasons
may only know certain values of certain fields. If this is the case then the user
interface element presenting that information must be properly re-initialized

user interface
design;
consistent
interface
Client
UI
partition
re-initialization presentation
of interface formats
elements
Server
re-initialization user interface

of interface design;
elements consistent
interface;
Client
Logic presentation
partition formats
Server
re-initialization user interface

of interface design;
elements consistent
interface;
Client
Storage presentation
partition formats
Server
Figure 8-1: UI design and the security framework
71
before usage and de-initialized after usage. This is indicated in Figure 8-1 in
the “confidentiality” column by the label “re-initialization of interface elements”.
In the logic and storage partitions the decision for the initialization of visual
information objects lies with the client (presentation logic sub-module) and the
entry is therefore in the “client” rows. In the UI partition, however, the
presentation logic sub-module resides on the server, thereby placing control
over the visual interface objects with the server. This would, for example,
point to the initialization of list boxes in order to ensure that the contents of a
list box is always in line with the user’s security profile.
A bad user interface can render a functional system useless. One such issue
is consistency, i.e. standardization as far as the design of the interface is
concerned. The utility value of information can be greatly enhanced by the
correct decision on the presentation format to use. The security framework
represents this information by the entries “user interface design” and
“standardization of interface” in the “client” row of the “utility” column for all
three partitions. The entry “presentation formats” in the “server” row, “utility”
column for the UI partition indicates that those decisions lie with the server. In
the logic and storage partition the entry “presentation formats” is in the “utility”
column and the “client” rows, indicating that the client makes presentation
decisions.
8.2 Other issues
Certain issues could not be addressed using the chapter framework. It is the
purpose of these paragraphs to briefly position certain other issues in terms of
the security framework.
Message Authentication Codes (MACs), hash functions, checksums and error

detection codes (EDC) are techniques used to ensure integrity of transmitted
data. They ensure that errors during transmission can be detected, enabling
the receiver (client or server) to be sure of the integrity of the received
information. These techniques involve both client and server communication
72
software and are therefore reflected in the security framework in the “integrity”
column for all three partitions’ “client” and “server” rows.
An electronic signature is generated by appending an encrypted summary of

the information to the actual information. The summary is obtained by
applying a one-way hash function to the information. The encipherment is
done by the private key of the user who signs the data. Due to the one-way
nature of the hash function it is impossible to generate false information that
can be substituted in order to produce the same hash result. Firstly applying
the hash function to the information and thereafter deciphering the signature
by applying the public key of the signee allows the verification of the
signature. If the two results match, then the signature is verified.
The electronic signature allows us to proof the integrity of the message due to
the one-way nature of the hash function. It also proofs the origin of the data
(authenticity) as only the public key that pairs with the private key of the
signee could successfully yield the result. The signee is the only one in
possession of his private key.
Due to the complex processing involved the UI partition does not lend itself to
the implementation of electronic signatures for communication purposes. The
entry “electronic signatures” therefore only appears in the “server” row of the
UI partition for the “authenticity” column. For the “logic partition” and “storage
partition” rows the entry “electronic signatures” appear in both the “client” and
“server” rows for the “integrity” and “authenticity” column.
8.3 Consolidating the matrixes
The matrixes that were presented throughout this chapter can now be
consolidated to form the complete framework (Figure 8-2). No explanation as
to the reason why any entry is placed in a specific position will be provided in
this section since it has already been done in the relevant section.
73
In Figure 8-2 the terms “control attribute package” and “ACLs” are combined
by using the entry “access control structures”. The motivation behind this
consolidation is that both the control attribute package and ACL are structures
that controls access to objects.
In the “Possession” column the entries “copyright”, ”intellectual property

rights” and “trade secrets” are added to all rows to indicate methods provided
by law to protect possession of information. Since these rights provide a
general form of protection no distinction is made between client and server.
For example, whether a trade secret is stolen by illegally accessing the
database on a server or by looking over the shoulder of a user at a
workstation does not make any difference.
The next chapter will illustrate how the framework can be utilized to assist in
the securing of systems in the client/server environment by applying it to an
electronic document management system.
74

OSI level services; copyright; intellectual documentation; user
Client
MACs, hash functions, property rights; trade interface deign;
UI partition checksums and EDC secrets consistent interface
audit facilities;OSI level security attribute server;
security labels; storage trusted recovery copyright; intellectual documentation;
services; MACs, hash electronic signatures and memory object re- techniques; trusted property rights; trade presentation formats
functions, checksums use; control attribute facility management secrets; off-site backups
and EDC package; secure
Server
association server; inter-
domain service;
cryptographic service;
firew alls; access control
structures
OSI level services; Kerberos client softw are; security labels; memory configuration copyright; intellectual documentation; user
electronic signatures; electronic signatures object re-use; certificate; management; recovery property rights; trade interface deign;
Client MACs, hash functions, cryptographic service; planning; DCE runtime; no secrets consistent interface;
checksums and EDC control attribute package; Java, no automatic presentation formats
firew alls; access control application launches
Logic partition structures
audit facilities; OSI level security attribute server; security labels; storage trusted recovery copyright; intellectual documentation
services; electronic Kerberos server and memory object re- techniques; trusted property rights; trade
signatures; MACs, hash softw are; KAS, TGS; use;control attribute facility management; DCE secrets off-site backups
functions, checksums directory server; package; secure runtime; DFS
and EDC electronic signatures association server; inter-
Server
domain service;
ACLs; firew alls; limit
execution rights; limit root
environment; access
control structures
OSI level Kerberos client softw are; security labels; memory configuration copyright; intellectual documentation; user
services;electronic electronic signatures object re-use; certificate; management; recovery property rights; trade interface design;
signatures; MACs, hash control attribute package; planning; DCE runtime; no secrets consistent interface;
functions, checksums secure association Java, no automatic presentation formats
Client
and EDC service; inter-domain application launches

service;cryptographic
service; ACLs; firew alls;
Storage access control structures
partition
audit facilities; OSI level security attribute server; security labels; storage trusted recovery copyright; intellectual documentation
services; electronic Kerberos server object reuse; techniques; trusted property rights; trade
Server
signatures; MACs, hash softw are; KAS, TGS; cryptographic service; facility management; DCE secrets off-site backups
functions, checksums directory server; firew alls; limit execution runtime; DFS
and EDC electronic signatures rights; limit root
environment
Figure 8-2: The consolidated security framework
75
AN ELECTRONIC DOCUMENT MANAGEMENT SYSTEM AS CASE STUDY
9.
9 AN ELECTRONIC DOCUMENT
MANAGEMENT SYSTEM AS CASE
STUDY
The purpose of this chapter is to introduce an electronic document

management system as a specific application of the client/server
environment.
The first section defines certain terminology that is crucial throughout the rest
of the chapter. Some security problems that are experienced in this
environment are then discussed. This chapter is concluded by showing how
the security framework can be used to solve some of these problems.
9.1 Terminology
In order to comprehend the concept of an Electronic Document Management

System (EDMS), it is necessary to understand the definitions of the individual
words in the term EDMS:
Electronic
The term electronic in this concept indicates two things. Firstly it indicates that
the management will be done with the aid of computers, and secondly it
indicates that the documents (or at least some of them) will be stored on
electronic media.
Document
A document is a collection of information forming a logical unity. Any

document may consist of a collection of other documents. A document
76
consists of two parts: index information and an image1. This is depicted in

Figure 9-1.
Management
The term management indicates that control is exercised over the document
throughout its lifecycle. In order to sensibly manage any document,
information about the history of that document is needed.
Company overview
Proposal
Index information
Company Attribute Value
Proposal overview Security class Confidential
Owner Eng manager

Product
overview Type Memorandum
Discipline Electrical
Quotation
+
etc.
Sample
contract
Image information
Electronic
file
/shared area/compovw.doc
Figure 9-1: The composite nature of a document
System
The components that perform electronic document management are called a

system, indicating that they form a logical unity. All components should
seamlessly work together to facilitate the management of electronic
documents.
After it has been established what an electronic document management

system is, it is also necessary to understand the following terminology:
1
Definition of image on the next page.
77
Revision control
The concept of revision control has a legal origin. In order to be able to prove
the legality of a decision or statement in a court of law it is necessary to be
able to exactly track the state of any supporting documentation at the date of
the alleged irregularity. This process of keeping a document in all its released
states is being referred to as revision control. The index information of a
document will reflect these changes in the revision of a document.
Image
The context of an image in a document management system is broader than

what is normally understood by the term. The electronic format of a document
is referred to as the document image. This holds irrespective of the type of
electronic file concerned, i.e. it doesn’t matter whether it is a spreadsheet,
word processor or a scanned image. If the electronic format of the document
is not available it will refer to the physical hard-copy of the document.
Red-lining
The term red-lining originates from the traditional drawing office. Changes to a
drawing were done in red ink, thus the term red-lining. This term overflowed
into the commercial documentation arena and currently refers to the making
of notes (comments, annotations) on a document with the intent of creating a
revision (new version) of that document.
9.2 Typical configuration
The configuration of an electronic document management system can be very

diverse. It will be influenced by a number of factors, including the size of the
organization, the amount of money being spent, the type of documents that
are kept and the kind of operations that must be performed with the
documents.
78
In today’s environment an electronic document management system will

probably be implemented as a client/server solution as this kind of application
lends itself to a client/server environment for the following reasons:
• The main purpose of the electronic document management system is to

allow for the easy and fast tracking of documents through an extensive
indexing system. It therefore makes sense to use a database server to
handle the indexing of the documents.
• The documents must be available to authorized personnel throughout the

whole organization. The logical option thus is to use a shared directory
service that can be accessed throughout the organization.
• The typical user will use a PC workstation to access the information

through a specialized application that will access the database server and
the directory server.
• Other typical operations, for example scanning, printing or the advanced

manipulation of images, can be done by computers specially designed for
those tasks. These computers will therefore render a specialized service to
the rest of the organization and can therefore be seen as servers within
the client/server environment.
It can be seen that the environment can be implemented in several different

ways. Figure 9-2 presents an example of a typical client/server
implementation of an electronic document management system. Note that
the directory server, image manipulation server and database server are
logically three different servers performing very distinct tasks. The broken line
grouping them in Figure 9-2 indicates that physically they may be
implemented on the same server machine. However the option to have the
three logical parts distributed amongst two, three or even more machines
does exist.
79
LAN / WAN
Print server
printer
Directory
server
Workstation
Image
manipulation
server
Database
server
Scan station
scanner
Figure 9-2: A typical EDMS configuration
9.3 Security issues in an EDMS environment
This section describes some security problems encountered in the electronic

document management system environment. After each problem has been
identified it is shown how the security framework can be used to suggest
possible solutions to the problem. Figure 9-3 shows the parts of Figure 8-2
that are used in these examples.
Integrity Authenticity Confidentiality Availability

Client
UI partition
electronic signatures security labels; storage trusted recovery
and memory object re- techniques; trusted
Server
use; secure association facility management

server; access control
structures
electronic signatures Kerberos client softw are; security labels; memory configuration
Client
electronic signatures object re-use; access management; recovery

Logic partition control structures planning; DCE runtime;
electronic signatures Kerberos server security labels; storage trusted recovery
Server
softw are; KAS, TGS; and memory object re- techniques; trusted
directory server; use; access control facility management; DCE
electronic signatures structures runtime; DFS
electronic signatures Kerberos client softw are; security labels; memory configuration
electronic signatures object re-use; secure management; recovery
Client
association service; planning; DCE runtime

Storage access control structures
partition
electronic signatures Kerberos server security labels; storage trusted recovery
Server
softw are; KAS, TGS; object reuse techniques; trusted

directory server; facility management; DCE
electronic signatures runtime; DFS
Figure 9-3: Extract from consolidated matrix
80
9.3.1 Access to documents
Since documents contain information with various levels of sensitivity it is

evident that access to the documents should be restricted. This is therefore
essentially a confidentiality issue.
The security framework presented in Figure 9-3 can now be used to

determine the different measurements that have been identified to ensure
confidentiality in the different partitions. From these an appropriate selection
can be made in order to solve the specific problem.
Following is a brief discussion of the measurements that will allow restricted

access to documents.
Security labels are needed to classify the documents and the users. These
labels will have a hierarchical structure. For example, if the labels top-secret,
secret, confidential and open have been identified, then the hierarchy would
indicate that user with a security label top-secret can also access documents
with security labels top-secret, secret, confidential and open. A user with a
security label of confidential can access documents with a security label of
confidential and open. This is in line with the mandatory access control policy
presented by the TCSEC [DODS85].
A simple hierarchy of security labels, however, is insufficient to protect

electronic documents. An engineering manager may have a security label of
secret, however, the business policy may not allow him to view secret
documents of a human resource nature. This argument could easily be
expanded to include any of the document attributes, e.g. type of document or
discipline. The use of additional access control structures could provide
functionality to support this requirement.
The access control structures could furthermore provide for the type of access
to be controlled. Type of access refers to the operations that can be
81
performed on the document, e.g. view, create new, delete, redline or revise a
document.
With the introduction of electronic workflow it is important that the business

process also governs the access to documents. An example could be the
engineering manager that normally has view access to human resources
documents pertaining to staff in his project team. During performance reviews
this situation change as the manager may allocate bonuses or even salary
increases and therefore needs review access to the relevant human
resources documents.
In the electronic document management environment the access control

structures should therefore cater for different access types which would be
dependent on a documents attributes, as well as on the business process that
is being performed. The secure association service would do the
interpretation of the security labels and other access control structures.
The implementation of aforementioned services will differ depending on the

client/server partition that is encountered. Note that for the UI partition the
security labels, access control structures and secure association service are
located on the server. In the logic partition certain objects on the client will be
representing the subject (user), implicating that the security labels and access
control structures will therefore be distributed between the client and the
server. For the storage partition the server will merely act as an object store.
The responsibility for the security labels and access control structures
therefore lies with the client. Note that the physical implementation may still
require storage of the security labels and access control structures on the
server. The secure association service, however, will be residing on the client.
9.3.2 Authenticity of different revisions
With the move towards handling documents in an electronic fashion certain

questions arise. One of these questions is how it can be proven that a specific
document was in a specific state at a specific time, or even that it is the
82
correct document at all. The question can be broken down into essentially two
issues: integrity of the document and authenticity of the information.
The security framework (Figure 9-3 refers) again provides us with certain
solutions. When evaluating the integrity and authenticity columns of the
framework it can be seen that electronic signatures could offer a solution to
both the issues.
If a document is signed with an electronic signature tampering with the

document can be detected. If no tampering can be detected the integrity of
the document was not violated.
The public key of a user can decipher the signature if and only if it was signed
by using the private key of that user. The use of an electronic signature can
therefore also proof that the document originated from its claimed origin.
9.3.3 Propagation of access rights
Sometimes, because of special circumstances, it may be necessary to allow

users to delegate authority to a user to perform certain tasks which, under
normal circumstances, he would not be permitted to perform and, therefore,
he won’t possess the relevant access rights.
This obviously has a huge impact on the confidentiality of information. Several

issues can be identified from the confidentiality column in the framework
(Figure 9-3). A brief discussion on each follows:
Security labels
The changing of the security label of a document is not advisable as this

would make it accessible to all users with the relevant security label. Similarly
changing the security label of the user will make several other documents
available to the user.
83
Changing of the security label therefore does not solve the problem, but rather
introduces more problems.
Storage and memory re-use
The temporary nature of this propagation of rights makes it extremely

important to ensure that all forms of storage, but especially temporary
storage, as well as memory are cleared properly on completion of the task.
This is necessary to ensure that all temporary access is properly revoked.
Access control structures
Provision for this situation could be made in the access control structures by
allowing changes to the access control structures. It is foreseen that
delegation of authority will be a specific right in the access control structure
and that a user will need that and at least the rights that he is trying to
propagate. Because of the very specific nature of the access control
structures this may be done for specific documents.
It is further suggested that a time-stamp be combined with the propagated

rights in order to allow only time-limited access. The rights should then
automatically revoked when the time has lapsed. Should a user finish prior to
the allowed time the rights should be revoked to prevent misuse.
9.3.4 Governing the security behavior of native applications
Electronic documents are generated by various applications. In order to view

and/or edit such a document it is necessary to use the native application, i.e.
the application through which the file originated. When these documents are
accessed through the native applications all rights pertaining to the native
application are assumed. This would thus enable a person with view
capabilities only to change the document by using the editing features of the
word processor in which the specific document was created.
84
A possible way of solving this problem would be to use viewers for the native
application files and only access a file through the editor if the user specifically
possesses edit rights. This situation would require good configuration
management on the clients. According to Figure 9-3 is evident that
configuration management of the clients could influence availability of
information in the logic and storage partitions. It is furthermore obvious that if
a specific viewer is not available on a client workstation that availability of the
information to view-only users using that workstation is severely hampered.
Another solution would be to use native applications that can accept

instructions as to which functionality should be enabled. This can be achieved
by viewing the application as an object acting on behalf of the subject. The
user can then propagate the necessary rights to the object (application) and
from there on the arguments of paragraph 9.3.3 hold again.
9.3.5 Multiple logins required
The problem of providing multiple logins, which have to be authenticated, to

the different network services is not limited to the electronic document
environment. Kerberos allows for a single sign-on facility to be implemented.
Note that the UI partition does not allow for the implementation of the
Kerberos authentication mechanism due to the amount of logic that must take
place on the server.
The electronic document management system should therefore be able to

interpret the tickets as provided by the authentication server.
9.3.6 Protection of document files
Electronic documents are essentially files. These files need to be stored on a

file system. If all users can view the file system then they may be able to
access the information without even using the electronic document
management system.
85
Two issues can therefore be identified: availability and confidentiality. In other

words, document files must be available, but only to the proper users.
By evaluating Figure 9-3 certain measurements to consider can be identified.
Using a file system such as the one provided by OSF DCE, called DFS can
solve the availability issue. DFS ensures availability, but also relies on the
authentication mechanisms provided by DCE.
From the confidentiality column it follows that access should be governed by

the security labels and access control structures. In DCE the control
structures are represented by Access Control Lists (ACLs).
It can therefore be seen that the solution provided by OSF DCE DFS attends
to both the availability and confidentiality requirements of this problem. Again
it should be noted that this solution is not possible within the UI partition. This
is a result of the logic involved with the DCE runtime that has to be present on
the client.
9.4 Conclusion
This chapter explained how the security framework presented in Chapter 8

could be used in a practical situation by evaluating the requirements of an
electronic document management system operating within a client/server
environment. The following chapter discusses how the framework can be
used in the generation of an information security policy for an organization.
86
SECURITY POLICIES FOR THE CLIENT/SERVER ENVIRONMENT
10. SECURITY POLICIES FOR THE

10 CLIENT/SERVER ENVIRONMENT
This chapter addresses the need for an information security policy in a

client/server environment. Furthermore the needs pertaining to the information
security policy are discussed in accordance with the framework presented in
Chapter 8.
The biggest problem today with most security efforts is the lack of a corporate
information security policy [WOOD94]. For a successful security implementation
in the client/server environment it is vital that management supports a
direction giving set of policies. Policies are the primary building blocks for any
security effort.
There are two opposing viewpoints regarding information security problems.

On the one hand it is said that information security is a people problem, whilst
on the other hand it is claimed that it is a technology problem. Both of these
viewpoints are correct. However, before anything can be done about
information security, management needs to be involved. Without management
support the necessary budgets would not be available, nor will there be
sufficient attention paid to the problem. Information security is therefore
essentially a management problem [WOOD94]. During 1994 a survey of 870
US based companies was done, yielding the shocking result that only 34% of
the Chief Information Officers thought that information security is extremely
important [SNEL94].
This chapter will firstly discuss what management should typically be

concerned about. Subsequently the development of a typical security policy
for the client/server environment will be discussed with special reference to
various sample policy statements derived from the security framework
presented in Chapter 8.
87
10.1 What managers should be concerned about
It is an undeniable fact that modern information technology can offer

considerable business benefits. One of the biggest problems, however, lies in
not recognizing the true power that information technology can provide the
company with. This ignorance with regard to the “good” power of information
technology also comes to the fore as ignorance to the “bad” things that
information technology can bring about. Symonds suggests that the biggest
danger is ignorance of the power that networks provide companies with
[SYMO94].
This leads to the next question: What should managers be concerned about?
Managers should be asking themselves “high-level” questions such as:
• Who else has access to my network?
• Who is responsible for the network? Could this include any of my

competitors?
• Who is responsible for the network? Do they manage it properly?
• Is my network reliable? What if it fails?
• How do I ensure confidentiality of certain information, e.g. business plans?
• Which platforms are being utilized in my organization? Which of those

platforms are also accessible to people external to the organization?
• How are we partitioning our client/server platforms?
• How are the platforms partitioned?
• Is my network safe from viruses and hackers?
Asking questions similar to those above will lead to the identification of

vulnerabilities in the system. These vulnerabilities may result from the parallel
evolvement of the system, and its security arrangement, with the evolution of
88
the network, which in turn is closely linked to the growth within the
organization as such. This again emphasizes the importance of developing a
corporate information security policy that can govern the extension of the
system along certain lines.
10.2 An information security policy for the client/server

environment
In order to develop an information security policy for the client/server

environment two questions need to be answered: “Why should this be any
different from the more traditional environments?” and “What would the
components of such a policy be?”.
The following section will attempt to answer the first question by discussing
some of the attributes of a client/server environment that distinguishes it from
a centralized environment.
10.2.1 Differences between a centralized environment and the

client/server environment
Figure 10-1 summarizes the main differences between the traditionally

centralized environment and a distributed client/server environment. The
client/server environment is created by combining a variety of physical
environments, whereas the centralized environment was designed and built
for a specific purpose, adhering to strict standards. Each of these
environments may have its own requirements regarding management and
security.
To complicate matters further management of the distributed client/server

environment is often left in the hands of non-specialist staff. This is possibly
the result of the geographical spread that is involved, as well as the tendency
for business units within an organization to take ownership of their own
information and technological infrastructure. In the centralized environment,
on the other hand, responsibility for management and operations lies with
highly trained specialist staff who could attend to the environment which was
89
CENTRALIZED ENVIRONMENT DISTRIBUTED CLIENT/SERVER

ENVIRONMENT
Purpose built physical environment A variety of physical environments that

are technically diverse
Operation and management by Management by non-specialized staff,

specialized staff as well as specialized staff
Single point of control Multiple points of control
Straightforward security review and Audit difficulties

auditing
Less complicated data communications Data communications much more

involved
Figure 10-1: Differences between a centralized environment and distributed

client/server environment
largely restricted to a small geographical area.
Due to the decentralized management of this decentralized environment the

points of control have also increased dramatically from the single point of
control that was present in the centralized environment. In the centralized
environment auditing was relatively simple since all activities took place in one
place. Within the decentralized environment, however, activities occur in a
multitude of places, resulting in immense difficulties in providing auditing
facilities.
In a distributed environment the manner in which data communications takes

place have become much more complicated. In a centralized environment
data communications were less complicated. The communication abilities in
the distributed environment form the backbone of the distributed environment,
i.e. it enables the other technologies.
From the foregoing it is evident that the needs of the client/server environment
vastly differ from that of the centralized environment. In the following section it
is considered what the typical components of an information security policy for
the client/server environment should be.
90
10.2.2 Components of the information security policy
The information security policies used or needed within an organization can

be very extensive. Unfortunately a set of policies cannot be taken “off-the-
shelf”, approved and implemented. Each organization has a unique set of
business, legal, organizational, human resources and technological factors
contributing to the unique set of policies that need to be employed in the
company.
The development of a policy for information security is an extensive process

that should involve a risk assessment in order to establish the exact value of
the information that needs protection. This value will determine the extent of
the policy that has to be drawn up.
The policy will also be influenced by the attributes for secure information that
need protection. For example, if confidentiality is not much of an issue then
implementing extensive measures to ensure confidentiality of information will
not be necessary. The security framework presented in Chapter 8 can serve
as a guideline to determine information security requirements that are
applicable to secure a specific environment.
Although it is not possible to develop an information security policy that is

applicable to all situations, it is possible to determine the general content of
such a policy.
An important aspect of information security in any organization, as previously

mentioned, is that management should be involved. It is therefore necessary
for top management to officially and clearly state their intention in terms of
protecting information belonging to the company through the information
security policy.
A “network security policy” can state general issues in terms of security that
pertain to the whole networked environment. It sets out responsibilities and
general guidelines for security in the organization.
As a result of the variety of resources that can form part of the client/server
91
environment it is necessary to control the computers that “join” the

client/server environment. As demonstrated by the security the two kinds of
resources that may “join”, namely clients and servers, have different
requirements depending on the implemented partition. A need therefore exists
to have a “server security policy” and a “client security policy”.
The following paragraphs will consider each of the components of an

information security policy for a client/server environment in turn, i.e.
(10.3) Network security policy
(10.4) Server security policy, and
(10.5) Client security policy.
10.3 The network security policy
The network security policy should clearly state general roles, responsibilities
and functions [SYMO94]. The following statements reflect the aforementioned
characteristics:
The Information Security Department owns the information security policy and
no deviation from it is allowed without proper investigation by and written
permission from the Information Security Department.
The Information Security Department will do all maintenance to the

information security policy. The information security policy is subject to an
annual revision cycle and must be revised by a relevant panel according to
the cycle. It is important in a fast moving environment, such as the computer
environment, that the most recent technological changes are considered
specifically with regards to their security impact. The revision cycle should be
shortened according to the importance of information security in a specific
organization. Note that the revision cycle applies to the information security
policy as a whole, i.e. the network security policy, the server security policy
and the client security policy.
Managers of end-systems will be responsible for the enforcement of security
92
on their end-systems. They should, however, adhere to the specifications and

guidelines provided by the Information Security Department. Wherever central
control is to the advantage of the company it is required that the managers of
end-systems waiver their rights to control. Managers of end-systems are
subject to auditing of their security principles and practices at any random
time.
It should also include certain rules that have to be applied throughout the
system. This could, for example, include how access to the network will be
negotiated.
For a user to obtain access to the computer network of Company X it is

necessary to apply in writing to the Information Technology Department. In
practice this would probably happen through the completion of forms which
ask the relevant questions, such as the reasons for the request and the users
identification. The applicant’s superior should approve these access forms.
Computer systems handling sensitive, valuable, or critical information must

securely log all significant computer security relevant events. Examples of
computer security relevant events include: password guessing attempts,
attempts to use privileges that have not been authorized, modifications to
production application software and modifications to system software
[WOOD94].
Business application development staff should not possess the ability to

transfer any software to the production-processing environment.
The network policy can also stipulate how the network should be partitioned in
different security domains. This would specify the grouping of clients and
servers in computing realms.
Management should also prepare, periodically update and regularly test a

disaster recovery plan that will allow all critical computer and communication
systems to be available in the event of a major loss such as a flood,
earthquake, or tornado [WOOD94].
93
The network security policy should also address the issue of encryption
across the network. Firstly it should state whether encryption will be used at
all. If encryption is used it should state whether a symmetric key scheme or a
public key scheme is going to be used. It will furthermore state how the
distribution of keys is going to be managed.
In addition to the network security policy document a network security

guideline may also be maintained which could facilitate the sharing of
experiences and research results. The difference between the guidelines and
policies are that guidelines would not be enforced, whilst policies are
enforced.
10.4 Server security policy
The “server security policy” will state the conditions that have to be met before
a server can participate in the client/server environment of the organization.
Information in this policy can range from standards that were set on the
acquisition of server machines through to policy statements on the
development of software on the server.
The security framework presented in Figure 8-2 can be used to determine

certain of the security issues by considering the “server” rows of the
framework. Figure 10-2 present the portion of the security framework that is

audit facilities; electronic security attribute server security labels; storage trusted recovery copyright; intellectual documentation;
signatures; MACs; hash and memory object re- techniques; trusted property rights; trade presentation formats
functions use; control attribute facility management secrets; off-site backups
Server
package; secure
domain service;
UI partition firew alls
audit facilities; electronic security attribute server; security labels; storage trusted recovery copyright; intellectual documentation
signatures; MACs; hash Kerberos server and memory object re- techniques; trusted property rights; trade
functions softw are; KAS, TGS; use;control attribute facility management; DCE secrets; off-site backups
directory server package; secure runtime; DFS
Server

domain service;
ACLs; firew alls; limit
execution rights; limit root
Logic partition environment
audit facilities; electronic security attribute server; security labels; storage trusted recovery copyright; intellectual documentation
signatures; MACs; hash Kerberos server object re-use; techniques; trusted property rights; trade
Server
functions softw are; KAS, TGS; cryptographic service; facility management; DCE secrets; off-site backups
directory server firew alls; limit execution runtime; DFS
Storage rights; limit root
partition environment
Figure 10-2: The security matrix – server related issues
94
relevant to the server security policy.
Figure 10-2 can be used to determine issues that should be addressed by the
server security policy. Firstly the attributes that need protection have to be
identified. It may be determined that integrity of information is important, but
that confidentiality may not really be an issue. Thereafter the client/server
partition that is implemented should be established, i.e. it should be
determined whether a logic, storage or UI partition is implemented. Finally the
entries in the cell formed by the intersection can be read off and a policy
statement built around it.
The rest of the discussion is structured around the security attributes that are
protected and provides example statements that can be included as part of
the server security policy.
Integrity
Regardless of the partition implemented the integrity of all data stored on the
server must be ensured by the use of standard OSI level services, like
checksums.
Authenticity
The development of client/server software utilizing the UI partition is

prohibited. In other partitions communicating parties should mutually
authenticate using the Kerberos authentication mechanism.
The Information Security Department maintains the Kerberos authentication

realms. Access to the Kerberos authentication server and Ticket-granting
server is prohibited.
For the purpose of supporting public key encryption schemes the Information
Security Department will make an enterprise-wide directory server available.
Generation of the private-public key combination is done off-line by the
Information Security Department.
A server must subscribe to a trusted timeserver and continuously synchronize
95
its clock with the timeserver.
Confidentiality
All network traffic entering or leaving the organization must traverse the
firewall of the organization.
All objects stored on the server have to have the necessary security labels
associated with them. The security labels should be in accordance with the
standard set by the Information Security Department.
All development done on the server should ensure that objects which are
accessed and stored are properly initialized and that any representation of the
objects are cleared from any form of temporary storage as soon as they
become not relevant to the processing tasks.
All sensitive information should be saved in an encrypted format.
Access to servers from clients and servers outside the domain must be
facilitated by an inter-domain service. The inter-domain server will determine
the access rights that a user from outside the domain will be allocated by
translating the security attributes between the different domains.
Availability
Daily incremental backups of the server should be made. A full backup of the
server has to be made once a week.
All backups must be stored off-site.
Possession
All information stored on a server is the property of the company and is as

such protected by the relevant legislation regarding copyright, intellectual
property rights and trade secrets. No user is therefore allowed to make a copy
of the information or use the information in any way except for explicit
business purposes.
96

OSI level services; electronic Kerberos client software copyright; intellectual documentation; user
Client
UI partition signatures property rights; trade secrets interface design; consistent
interface
OSI level services; electronic Kerberos client software security labels; memory configuration management; copyright; intellectual documentation; user
Client signatures object reuse; certificate; recovery planning; DCE property rights; trade secrets interface design; consistent
cryptographic service; runtime; no Java, no interface; presentation
Logic partition control attribute package; automatic application formats
firewalls; access control launches
structures
OSI level services;electronic Kerberos client software security labels; memory configuration management; copyright; intellectual documentation; user
signatures object reuse; certificate; recovery planning; DCE property rights; trade secrets interface design; consistent
control attribute package; runtime; no Java, no interface; presentation
secure association service; automatic application formats
Client
Storage inter-domain launches

partition service;cryptographic
service; ACLs; firewalls;
access control structures
Figure 10-3: The security matrix – client related issues
Utility
Proper documentation must accompany all aspects of the server. This

includes documentation on hardware configuration as well as any system or
application software that resides on the server.
If the UI partition is used as the client/server partition of choice the server

software should be designed to cater for the applicable presentation formats
in order to ensure the usability of the information.
10.5 Client security policy
The “client security policy” will govern the joining of client workstations to the
corporate client/server network. It should include technical specifications and
standards to be adhered to by client workstations. This includes specifications
such as the permitted operating systems and all specialized software that
should be able to run on the client.
The security framework presented in Figure 8-2 can be used to determine

certain of the security needs of the implemented client/server partition. Figure
10-3 presents the framework cells that represent the client issues in Figure 8-
2. Similar to the manner in which Figure 10-2 was used in the establishing of
the server security policy it is now possible to use Figure 10-3 to assist in the
development of the client security policy.
97
Some examples are given according to the security attributes that are
protected.
Integrity
All client software should use standard OSI level techniques, like checksums,
to ensure the integrity of the communications taking place between client and
server.
When utilizing either the logic partition or the storage partition electronic
signatures should be used to sign sensitive information. This would allow for
verification of the integrity.
Authenticity
All clients in either a logic partition or a storage partition client/server

environment must have Kerberos client software installed to allow for
authentication of communicating parties.
Important information, as those which have possible legal implications, should

be electronically signed to provide proof of origin. Due to the lack of
processing logic on the client in the UI partition this can only be done if the
environment is either a logic or a storage partition.
Confidentiality
When client software is developed for either the logic or storage partition the
client should retain any security labels and access control structures
pertaining to objects passed to it from the server.
Client software developed for the client in a logic partition or the storage
partition should retain objects for the shortest possible time. Any storage area
used for temporary access for objects should be properly re-initialized after
the objects have been used in order to prevent illegal object re-use.
All communication, incoming and outgoing, generated between a client and

any server outside of the organization should be routed through the
98
company’s firewall.
Availability
In order to ensure continuous availability of information to the user, redundant

client equipment should be kept.
It is specifically crucial for the logic and storage partitions to have a proper
configuration management system available in order to ensure that all
possible breakdowns can be catered for.
Should any client workstation utilize specialized software not normally used in
the organization the Information Technology Department should be provided
with a proper backup copy that can be installed should the client workstation
break down. The Information Technology Department should also be formally
notified of any specific hardware requirements of such specialized software.
A recovery plan should be maintained and updated on a regular basis to allow

for the control of any problems with availability.
Possession
All information retrieved via a client workstation is the property of the company
and is as such protected by the relevant legislation regarding copyright,
intellectual property rights and trade secrets. Thus no user is allowed to make
a copy of the information or to use the information except for explicit business
purposes.
Utility
For all client related issues proper documentation should be provided. This
documentation must be made available in an electronic form at allowing it to
be accessed from any client workstation.
The user interface design of any client software must be formally matched to
the usability factor of consistency.
For client software developed under the logic or storage partition the software
99
should be designed to cater for the applicable presentation formats in order to

ensure the usability of the information.
10.6 Conclusion
This chapter stressed the importance of the implementation of an information

security policy. The security policy sets the foundation for implementing a
secure system, based on technical and human policies that cannot effectively
operate separately.
It was furthermore identified that the complexity involved in a typical

distributed client/server environment warrants an investigation into the specific
needs of this complex environment.
A framework for the development of information security policies for the

client/server environment was also proposed. Some examples of typical policy
statements were discussed for each of the components of the framework.
100
CONCLUSION
11
11. CONCLUSION
This study presented a security framework comprising of the client/server

partitions on the one axis and the attributes for secure information on the
other. Presenting different standards and techniques and thereafter applicably
positioning them in the security framework have completed the framework.
Aforementioned activity presented proof that the needs of clients and servers
in the client/server environment differ according to the client/server partition
implemented. The presented security framework distinguishes between the UI
partition, the logic partition and the storage partition. It can therefore be used
as a tool to establish the security needs required by a specific client/server
environment.
The framework furthermore differentiated between the different attributes that

need to be maintained in order to ensure secure information, namely
availability, utility, integrity, authenticity, confidentiality and possession. It was
pointed out that different environments might have different needs, or at least
different priorities, in terms of securing information. The framework could
therefore also be applied to determine the areas of greatest concern, by
determining which security attributes requires protection, or which attributes
take priority.
In addition a framework for devising a security policy for the client/server

environment is proposed. It is demonstrated that the security framework can
be utilized in assisting with the establishment of the client security policy and
the server security policy which form a part of the presented framework.
This study also identified an electronic document management system as a

case study to practically demonstrate the research done. Some security
issues in a typical EDMS environment have been identified and it has been
demonstrated that the security framework that was proposed could assist us
101
CONCLUSION
in addressing those issues.
This study also lead to the identification of specific areas for further research
which are discussed in the following paragraphs.
11.1 Further research
The evaluation of electronic document management as a case study lead to

the realization that the environment in which information needs to be
protected is not only becoming more distributed, but also more dynamic. The
business process that is supported by a specific workflow, for example, might
also have a significant influence on the access that a user may be granted to
a specific object. An engineering user, for example, may not normally have
access to alter financial documents. However, for budget purposes he may
need to be able to update certain figures within a document. Current ways of
administrating this authorization process do not take this dynamic aspect into
consideration. It is believed that further research needs to be done on this
aspect.
The EDMS case study identified the management and maintenance of

security profiles, relating to both documents and users, as an extremely
important issue. With the previous paragraph in mind it is evident that this
already complicated task is being complicated even further. Investigation into
the development of tools to simplify this user profile management process will
proof very useful.
The task of classifying the documents is largely a manual process. The

automation of certain management tasks might be possible, thereby
decreasing the margin for human error. These mechanisms or techniques
might exploit standards such as the Open Document Architecture (ODA) to
automate these human processes to some extent. However, for tasks which
can not be fully automated, a solution that provides for detection of possible
human errors could proof to be extremely useful.
It is believed that this study, and any other studies that might result from this,
can assist in securing the rapid growing electronic environment.
102
BIBLIOGRAPHY
A BIBLIOGRAPHY
[AXEN95] Axent Technologies, “Information Security for Client/Server

Computing”, 1995
[BUHL95] Buhle, L.E. et al., “Webmaster’s Professional Reference”, New

Riders Publishing, 1995
[BOCK95] Bock, G.E. & Marca, D.A., “Designing groupware”, McGraw-Hill,

1995
[CAEL92] Caelli, W.J., Rhodes, A.W. and Russell, N.C., “An Evaluation of
HP-UX (Unix) for Database Protection Using the European
ITSEC”, Computers and Security, Vol. 11, 1992, pp. 463 - 479
[COLE90] Cole, R., “A Model for Security in Distributed Systems”,

Computers and Security, Vol. 9, 1990, pp. 319 - 330
[COOP95] Cooper, F.J. et al., “Implementing Internet Security”, New

Riders, 1995
[DAVI89] Davies, D.W. & Price, W.L., “Security for Computer Networks”,
2nd Edition, John Wiley & Sons, 1989
[DEIT90] Deitel, H.M., “An Introduction to Operating Systems”, 2nd Edition,

Addison-Wesley, 1990
[DEIT97] Deitel, H.M. & Deitel, P.J., “Java – How to program”, Prentice
Hall, 1997
[DELO93] Deloitte & Touche Management Consulting, “Information

Protection and Client/server: New Approaches for New
Environments.”, 1993
103
BIBLIOGRAPHY
[DIXO96] Dixon, R., “Client/Server and Open Systems”, John Wiley &
Sons, 1996
[DODS85] Department of Defense Standard DOD 5200.28-STD,

“Department of Defense Trusted Computer System Evaluation
Criteria”, December 1985
[DONO93] Donovan, S., “Security of PCs in a Distributed Environment”,

[ELOF94] Eloff, M.M., “Information Security in a Distributed environment”,

M.Sc dissertation, RAU, 1994
[ELOF96] Eloff, J.H.P., Holbein, R. and Teufel, S., “Security classification

for documents”, Computers and Security, Vol. 15, 1996, pp. 55-
71
[FRAN93] Francis, R., “The Search for Client/Server Security”, Datamation

Vol. 39, May 1993, pp. 39 – 43
[FRIT96] Fritzinger, J.S and Mueller, M., “Java Security”, Sun

MicroSystems, Inc., 1996
[GOLL93] Gollman, D., Beth, T. and Damn, F., “Authentication Services in

distributed systems”, Computers and Security, Vol. 12, pp. 753 -
764
[GRAH92] Graham, I.G. & Wieten, S.H., “The PC as A Secure Network

Workstation”, Computers and Security, Vol. 11, pp. 237 – 244
[HARR94] Harris, D. and Sidwell, D., “Distributed Database Security”,

[HART95] Hart, J.M. and Rosenberg, B., “Client/Server Computing for

Technical Professionals”, Addison-Wesley, 1995
[HUGH95] Hughes, L.J., “Actually Useful Internet Security Techniques”,

New Riders, 1995
104
BIBLIOGRAPHY
[HIGH93] Highland, H.J., ”A View of Information Security Tomorrow”,

Computers and Security, Vol. 12, 1993, pp. 634 – 639
[HPUX91] “HP-UX Reference Manual – Volume 3: Sections 1M,4,5,7 & 9 –

HP-UX Release 8.0”, First Edition, 1991
[ISO90] ISO/IEC 9594-8 “Information Technology - Open Systems

Interconnection - The Directory - Part 8: Authentication
framework”, 1990
[KANU94] Kanungo, S., “Identity authentication in heterogeneous

computing environments: A comparative study for an integrated
framework”, Computers and Security, Vol. 13, pp. 231 - 253
[KING94] King. S., “After Downsizing: Overcoming Client/server Chaos”,

Data Communications, May 21, 1994, pp. 52 - 60
[KRUY91] Kruys, J.P., “Progress in Secure Distributed Systems”,

Computers and Security, Vol. 10, 1991, pp. 429 – 441
[LADU96] LaDue, M.D., “Hostile Applets on the Horizon”,

http://www.math.gatech.edu/~mladue/HostileArticle.html, 1996
[LEMA96] LeMay, L. et al., “Yes, Java’s secure. Here’s why”, Datamation,

March 1996, Vol. 42 No 5 pp. 47 – 50
[MAGI95] Magid, J. et al., “Authors explain how to navigate Web, build

sites (excerpt from ‘The Web Server Book’)”, Computer Reseller
News, Nov 13, 1995, pp.269 – 273
[MART94] Martin RJ “The Premise and the Promise” Journal of Systems

Management, January 1994, pp. 26 – 27
[ONLI95] Online Business Consultant, “Deadly Black Widow on the Web:

Her name is JAVA”, http://www.hpp.com/javablackwidow.html,
May 1996
105
BIBLIOGRAPHY
[ORA92] Oracle Corporation, “Oracle 7 Server Administrator’s Guide”,

1992
[ORA97] Oracle Home Page, http://www.oracle.com
[ORFA94] Orfali, R., Harkey, D. and Edwards, J., “Essential Client/Server

Survival Guide”, John Wiley & Sons, 1994
[OSHE91] O’Shea, G.F.G., “Operating Systems Integrity”, Computers and

Security, Vol 10, 1991, pp. 443 – 465.
[OVER95] Overbeek, P., “Common Criteria for Information Technology

Security Evaluation”, Proceedings of the 11th IFIP/Sec ‘95, May
1995, pp. 31 – 39.
[PARK95] Parker, D., “A new framework for Information Security to avoid

Information Anarchy”, Proceedings of the 11th IFIP/Sec ’95, May
1995, p.135 – 144.
[PRES91] Press, J., “Secure Transfer of Identity and Privilege Attributes in

an Open Systems Environment”, Computers and Security, Vol.
10, 1991, pp.117-127.
[REIT93] Reitenspies M “Open Systems Security Standards” Computers

and Security, Vol. 12, 1993, pp. 341 – 361.
[ROOS96] Roos Lindgreen, E, “A Sense of Secureness”, PhD thesis,

Technische universiteit Delft, 1996
[ROSE93] Rosenberry, W., Kenny, D. and Fischer, G., “Understanding

DCE” O’Reill & Associates, 1993
[ROSE94] Rosenthal, P.H. “The Emerging Enterprise Systems

Architecture” Journal of Systems Management, February 1994,
p. 16 – 21.
[SCHI95] Schill, A., “Cooperative Office Systems”, Prentice Hall, 1995
106
BIBLIOGRAPHY
[SCHU94] Schulteis, R.A. & Bock, D.B., “Benefits and Barriers to

client/server Computing”, Journal of Systems Management,
February 1994, p. 12
[SCOT96] Scotkin, J., “Business uses for Java”, Datamation, March 1996,
Vol. 42(5), pp. 40 – 42.
[SINH92] Sinha, A., “Client/server Computing”, Communications of the

ACM, Vol. 35, No. 7, 1992, pp. 77 – 97.
[SNEL94] Snell, M., “Information Security not high up on CIO’s list”,

Computer Fraud and Security Bulletin, August 1994, p. 7
[STEI96] Stein, L.D., “The World Wide Web Security FAQ”, http://www-
genome.wi.mit.edu/WWW/faqs/www-security-faq.txt, 1996
[STRA93] Strauss, P. “LAN Boom paves the way for Client/Server”

Datamation, Nov 15, 1993, p.40-48
[SYMO94] Symonds, I.M., “Security in Distributed and Client/Server

Systems - A Management View” Computers & Security, Vol. 13,
1994, pp. 473 – 480.
[VSOL96a] von Solms, B., “Information Security on the Electronic

Superhighway”, South African Computer Journal, Number 17,
September 1996, pp. 36 – 44. (reprinted from “Proceedings of
the 12th IFIP/Sec ’96”)
[SOL96b] Von Solms, B., “Information Security – The Family Member Who
Came Home”, South African Computer Journal, Number 17,
September 1996
[WOOD94] Wood, C.C., “Information Security Policies Made Easy”,

Bookmasters, Auckland, 1994
107
ARTICLE
B
12. ARTICLE
The article included has been submitted to, accepted by and presented at the
workshop of the International Federation of Information Processing’s
Workgroup 11.2 on Small Systems Security that took place in Copenhagen,
Denmark on the 13th May 1997. One of the areas of interest of the
aforementioned workgroup is client/server security.
108
Management considerations for securing a
distributed client/server infrastructure
R.A. Botha1 and J.H.P. Eloff2

1
Faculty of Computer Studies, Port Elizabeth Technikon
Port Elizabeth, South Africa, reinhard@ml.petech.ac.za
2
Department of Computer Science, Rand Afrikaans University
Johannesburg, South Africa, eloff@rkw.rau.ac.za
Abstract
This paper is firstly aimed at defining the client/server environment, with specific reference
to partitioning a client/server platform. The term “partitioning” in a client/server environment
refers to the location of the user interface, the logic and the information storage modules on
either the client or the server, or on both. Typically, this could be a user interface and
application that run off a client and the database that stores the information that resides on the
server.
The relative importance of the specific partition chosen for the client/server environment
with respect to six attributes of secure information is discussed. Each of these attributes is
discussed, identifying the standards and/or techniques that are relevant to maintain secure
information in the client/server environment.
The partitioning directly impacts on the security of the system for the different attributes,
which, in turn, have a considerable impact when securing a distributed client/server
infrastructure.
Keywords
Information security, client/server systems, distributed computing, security management
1. THE CLIENT/SERVER ENVIRONMENT

The boom of the network era has paved the way for client/server technology [SINH91]. The
term “client/server” has many definitions [ORFA95]. A common factor among all of these
definitions can be found in the name: a client and a server need to be present. The latter could
be either in the form of a physical machine or simply in the form of separate processes
performing the various functions. A client requests a service(s) from the server. “Client” and
“server” are, therefore, relative words, whose meanings are dependent on the contextual
Logic module
Figure 1 Application partitions
usage. What can be considered a server in one set of circumstances may well be deemed to be
a client in another set of circumstances.
Client/server applications can be partitioned in the same way as that in which non-
distributed applications are partitioned into three components (see Figure 1): (1) the user
interface, (2) the logic and (3) the information storage modules [HART95]. The user
interface module controls user interaction and the information storage module is responsible
for writing to and reading from a variety of media. The logic module is responsible for all the
processing and can as such, be divided into three sub-modules. The Information logic sub-
module accesses the information storage system and controls the distribution of data. The
Presentation logic sub-module is in control of how information will be displayed and it
evaluates the user input. The Application logic sub-module is responsible for the
computational-intensive tasks.
The said partitioning is important because of the following two reasons:
(1.1) The modules will be distributed among multiple nodes (clients and servers)
depending on the exact partition chosen for the specific client/server
implementation.
(1.2) The specific way of partitioning could severely impact on the security of the
system. For example, responsibility for the integrity of information in a
database could lie with either the server or the client, depending on the partition
chosen. The database management system (DBMS) could be responsible for
overseeing the integrity of the data that gets stored by it, thus placing the
responsibility at server level. Alternatively, the integrity rules could be
implemented on client-application level.
1.1 Various client/server partitions

The various partitions depicted in Figure 2 need further explanation. In general, there is
nothing that prevents one from putting each of the three modules on a different node (three-
tiered model), or even from spreading some of the partitions across different nodes. The three
partitions presented here do not, therefore, represent all possibilities, but can merely be
considered a representative sample. Following a summary of the three partitions, indicating
how they will typically look and providing an example of how the information security needs
differ between them. A closer look is taken at the information security issues in paragraph
1.2.
UI partition
This partition bears a close resemblance to the typical mainframe environment, in which all
the processing and storage functions are performed by the server. Only the user interface
module is located on the client, utilizing the graphical-display capabilities of the client. The
information security requirements of the UI partition are very similar to those of the more
traditional environments, in that the identification, authentication and authorization functions
are being performed by the server. The integrity of the data is controlled either by the
database or by the application, both being on the server.
Storage partition
This partition represents a widely used client/server platform. Vendors develop products for
multiple platforms. Because the level of security differs between commercial databases,
certain issues, e.g. integrity checking, frequently get addressed by the application program.
The server, therefore, merely performs a storage function. All other functionality is shifted to
the client.
Identification of the user is done by the client. Authentication and authorization involve
both the client and the server. Access control for the application could be governed by the
client, whilst access to the database is governed by the server.
Any application submitting information to the database must check that the integrity of the
database is not compromised by any manipulation of the values. This, however, leaves the
preservation of the integrity of the database to “good faith”, as anybody that can gain access
to the database could, be it intentionally or unintentionally, compromise the integrity of the
data.
Logic Module SERVER

CLIENT

Module logic sub- logic sub- logic sub- Storage
(UI) module module mudule Module
UI partition
Logic Module
SERVER
CLIENT

Logic partition
Logic Module
SERVER
CLIENT

Storage partition
Figure 2 Partitioning the client/server model.

Logic partition
The principle aim in a client/server environment is to make the most of both the client and the
server. The client, for example, is good at displaying information, while servers are good at
storing information. From this it follows that the UI module must reside on the client and that
the information storage module must reside on the server. But what about the logic module?
The logic module consists of three sub-modules that can be positioned as follows: since the
client presents the user interface, the presentation logic sub-module can be located on the
client. The information logic sub-module, in turn, can reside with the server, as this is where
the information is stored. The application logic sub-module can then reside on the client if no
intensive processing is necessary; it could reside on the server if great processing power is
needed; or it can be split between the client and the server appropriately to share computing
resources.
In practice, this could be a PC running in a windowing environment (the user interface
module). The application on the PC will determine the manner in which to present the
information (take the returned data and graph it -- presentation logic sub-module), as well as
do some limited calculations (add all of the monthly figures to an annual total -- application
logic sub-module). The server, on the other hand, can maintain a database (information
storage module). The server will also check the integrity of the data by means of integrity
rules, and will determine the manner in which to distribute the information (information logic
sub-module). Furthermore, the server will do more complex operations, requiring number-
crunching capabilities, such as those required for extensive forecasting or what-if analyses by
means of sophisticated statistical methods (application logic sub-module).
The logic partition divides the responsibility for maintaining secure information between the
client and server. It does not, however, burden the client with responsibilities which it is not
equipped for, e.g. maintaining of the integrity of the database, yet it still plays an important
part in making the information available to the user in a useful manner. Identification of the
user is effected by the client, while the responsibility of authentication is shared between the
client and the server. Similarly, authorization is effected by the client and/or the server,
depending on the location of the resource that needs to be accessed.
Table 1 Client/Server partitions vs. information security attributes

Attributes of secure information
Confidentiality
Authenticity
Possession
Client/server
Availability
partitions
Integrity
Utility
UI partition S cS3 S S S cs
Logic partition S CS3 S cS cS C
Storage partition Cs CS3 cs CS CS C
C: Client highly significant S: Server highly significant
c: Client less significant s: Server less significant
3: Third party significant
1.2 Information security and client/server partitions.
Since the role of the client and the server hinges upon and varies according to the chosen
partition (refer Figure 2), it follows that the importance of the client and the server with
respect to the information security of the system will also depend on the exact
implementation.
Given the structure of the client/server partitions as defined in paragraph 1.1, a structure or
paradigm is required in terms of which the information security impact of the various
partitions could be studied. The following six attributes of secure information presented by
[PARK95] are considered: integrity, authenticity, confidentiality, availability, possession and
utility. Following, a discussion on the security impact of each of the client/server partitions
mapped onto the said security attributes. This discussion is formatted according to Table 1.
1.2.1 Integrity
The term “integrity” is defined as “the protection of the contents of information”, i.e. the
impact on the correctness, completeness and consistency of data. The integrity of the data is
threatened not only when information is being stored, but also when it is being transmitted.
Let us consider integrity at storage level. The modules involved in the storage of
information are the information storage module and the information logic sub-module. As
depicted in Figure 2, the location of the information logic sub-module differs from one
partition to the next. In the UI and the logic partitions both the information storage module
and the information logic sub-module are located on the server, with the result that the
responsibility will solely rest with the server. This set of circumstances is aptly labeled with a
capital “S” in the rows “UI partition” and “Logic partition” (Table 1).
Now consider the storage partition, where the information logic resides on the client, thus
shifting some of the responsibility for integrity to the client. From this, it follows that all
application systems will bear responsibility for the preservation of the integrity of a system,
even though, through this arrangement, the possibilities for integrity violations are thrown
wide open. The server will only be held responsible for correctly writing information to the
media. This is indicated in the “Storage partition” row of Table 1 by a capital “C” and a small
“s”.
Preserving the integrity of the data while it is being transmitted (or at least detecting
unwanted alterations) is an important issue. The integrity of data can be preserved thanks to a
variety of techniques ranging from the use of checksums and parity bits to cyclic redundancy
checks [DAVI84].
1.2.2 Authenticity
Authentication provides functionality through which to verify the accuracy of information,

e.g. the identity of a user or the authenticity of information. The importance of authentication
is two-fold, namely to verify the authenticity of the communicating parties, and to verify the
authenticity of the information that is being communicated.
A client and server can only trust each other if they can mutually authenticate each other’s
identities. Several such authentication frameworks have been developed. MIT’s Kerberos and
the ISO’s X.509, or slight variations on these themes, seem to be extremely popular
[KANU94,GOLL93]. Such protocols involve both the client and the servers, as well as a
trusted third party. Another commonality between authentication protocols is that they rely
on cryptographic techniques. Kerberos, for example, uses a private-session key while X.509
is based on a public-key scheme.
Another authentication concern in the distributed client/server environment is the
distribution of encryption keys. Kerberos needs a shared key between all possible
communicating parties, which would mean an exponential increase in the number of keys.
X.509, on the other hand, uses a key pair per client, server or certification authority, which
modus operandi results in a linear growth in the number of keys. In X.509, certificates are
public information, with the result that no special precautions need to be taken to protect
them [ISO90], as their integrity is assured thanks to the fact that the certification authority
(CA) has signed them (and that the CA’s private key is used off-line), thus facilitating the
identification of any tampering. The Kerberos Authentication Server and the Ticket Granting
Server, however, need special protection, as session keys are continually generated and can,
therefore, be compromised by an attack on the Ticket Granting Server [KANU94,COOP95].
Information can only be considered authentic if its origin could be determined and if
conclusive proof can be furnished that no tampering occurred with the data. The concept of a
digital signature, based on public-key encryption, can be employed to verify the origin of the
data. This will be based on the client‘s agreement (acting on behalf of a user) to sign the data
with its private key, thus rendering it accessible only through the use of the client’s public
key.
From the above discussion, it follows that the client, the server and the third party play an
equally important part in proving authenticity in the Logic and in the Storage partitions.
Table 1 indicates this by adding a “C”, an ”S” and a “3” of equal importance for the storage
and logic partitions. In the case of the UI partition, the role of the client is simply to obtain
the information from the user and to provide it as it is to the server to use. This change is
indicated by using a small “c” in the entry for the UI partition/authenticity entry in Table 1.
The role of the server and the third party stays the same.
1.2.3 Confidentiality
“Confidentiality” refers to the “who has access to what” in a system and, therefore, includes
aspects such as authorization and/or access control. The confidentiality of information within
the client/server environment could be threatened in the following three different ways:
(a) The first threat could be encountered at the storage level of the data. If an intruder
were to gain access to the data files of the database on the server, he could possibly
obtain some information by analyzing those data files. Encrypting the data files
would, however, make this analysis more difficult and time-consuming. The server-
operating system should, therefore, provide the necessary access control restrictions
to the server.
(b) The data could be intercepted whilst being transmitted across the network. This could,
however, also be countered through the application of cryptographic techniques.
(c) The definition of security profiles for the users and the information could also pose a
confidentiality problem. Maintaining security profiles are a time-consuming,
resource-intensive operation. If not done with the necessary care, a user could
accidentally be given the incorrect rights, thus enabling him/her unlawfully to access
confidential information. This argument also extends to the classification of
information. If the information were wrongly classified, then users who should not be
able to access that information might indeed be allowed to do so. The maintenance of
the user profiles, as well as the maintenance of the classification of information,
requires resources that must be made available by management, which would, in turn,
have an effect on the security policy of the organization.
In the UI and logic partitions, the server-operating system will be responsible for the
protection of the data files, whilst the information logic sub-module will be responsible for
the interpretation of the access-control list (ACL), possibly introducing a filter on the queries.
The client, therefore, does not play a significant part in the confidentiality of the information,
as the major responsibility for this function rests with the server. Table 1 indicates this with a
capital “S” in the confidentiality column for rows “UI Partition” and “Logic partition”.
In the storage partition, the role of the server-operating system stays the same, even though
the information logic sub-module resides on the client and the responsibility for the
interpretation of the access-control lists, therefore, rests with the client, thus reducing the
server responsibility. The “Storage partition/Confidentiality” entry of Table 1 indicates this
with a small “s” and “c”.
1.2.4 Availability
The concept of “availability of information” refers to the fact that information will always be
available to authorized users. Availability of the information is, in turn, influenced by the
availability of the clients and the servers.
In the case of an unavailable server, the availability would influence the entire
environment, whereas an unavailable client would merely influence the availability at that
specific client. It could, therefore, be argued that although the unavailability of a subset of
clients does influence the availability of information, it does not cause a complete loss of
availability.
In the storage partition, the state of the data could be dependent on automated processes
being performed by the application logic sub-module. If this were the case, then the
necessary data might not be available if a client were not available. This argument could also
be extended to include a fully distributed environment, in terms of which an unavailable
client would implicate an unavailable server, as the client and the server could switch roles as
required. Such a fully distributed environment would indicate that either the logic partition or
the storage partition is implemented, as the UI partition does not allow for any processing on
the client.
The part the server plays in the availability of information is stressed in Table 1 by
indicating a capital “S” in the “Availability” column in Table 1 for all rows. Table 1 indicates
the relatively insignificant role of the client by altogether omitting an entry for it from the UI
partition row. In the Logic partition, the potential importance of the client (in a fully
distributed environment) is indicated by including a small “c” in the “Logic
partition/Availability” entry. In the storage partition, the client could play an important part
in generating data for the database and, in a fully distributed environment, that would even be
more likely. The “Storage Partition/Availability” entry in Table 1, therefore, includes a
capital “C”.
1.2.5 Possession
The phrase “information security attribute of possession” refers to the concept of having
information at one’s disposal. It is different from availability in that although information is
possessed by an user it might still not be available for utilization by that user. Losing
possession of such information would, therefore, indicate that the company does not have the
information at its disposal any more. This could happen if the information were physically
stolen -- in the client/server environment, therefore, if somebody were to steal the server or at
least the disks containing the data. This danger could be averted by ensuring that proper
physical server-access controls are implemented.
Another possibility for possession being lost is if the disks containing the data were
damaged (owing to a disk crash or a flood). A company could only recover from such
incident if proper backups of the information had been made and care had been taken as to its
storage. This would change the loss of possession to loss of availability in case of a flood.
The importance of the server is stressed in Table 1 by marking the “Possession” column for
all partitions with a capital “S”. In the UI partition, the client involvement is limited to
displaying the information and could, therefore, not play a significant part in protecting the
possession of information. The logic and storage partitions, however, make intensive use of
the information through the application logic sub-module and the presentation logic module
that are situated on the client. Loss of the client could, therefore, also indicate the possibility
of exclusive possession of the information being lost. As in the case of the argument being
advanced in paragraph 1.2.4 for the availability of data, the risk of complete loss of
possession when losing a client in a fully distributed environment is considerably greater.
The importance of the client in the Logic and Storage partitions is indicated in Table 1 with a
small “c” in the corresponding rows of the “Possession” column.
1.2.6 Utility
The utility value of the data is determined by how useful the data is, i.e. the extent to which it
conforms to the users’ requirements, which are, in turn, determined by the way in which the
data is presented to the user by the application. If this attribute is not protected in its own
right, the data, which could be sound and authentic, possessed by the legal owner and
available only to authorized parties, could be of as little value as when it does not possess any
of these attributes.
The presentation function is to be performed by the user interface and the presentation
logic. These modules, in the case of the Storage and Logic partitions, reside on the client. In
Table 1, the importance of the client is stressed through the use of a capital “C” in the
corresponding rows. The server is omitted from the “Logic partition” and the “Storage
partition” rows in Table 1 because it has no relevance in presenting the data to the user.
In the case of the UI partition, however, the presentation logic resides on the server. This
places the responsibility for the presentation on the server, thereby directly influencing the
utility value of the data. The burden on the client is relieved in that the client will only
display whatever the server returns and in that it will not make any decisions on the
presentation. The responsibility is, therefore, shared between the client and the server,
indicated by the small “s” and “c” in the “UI partition/Utility” entry in Table 1.
1.3 Information security services and mechanisms for the various
client/server partitions
In paragraph 1.1, various client/server partitions were defined. Paragraph 1.2 contained a
detail discussion of the information security issues obtaining to each of these partitions in
terms of the six attributes of secure information. The next step, will therefore be to define a
framework that could be used when securing a client/server environment. Table 2 (next page)
graphically represents the security services and mechanisms in the form of a matrix, with the
different partitions given as the rows and the security attributes as the columns. This matrix
could be used to determine what measures need to be implemented in a specific client/server
installation.
In order to use the matrix, the user would need to identify the partition to be implemented.
Furthermore, the required level of security needs to be decided, that is the security attributes
that need to be present. For example, if the information that is present in the environment
could be considered not sensitive (in other words, suitable for access by all users who have
access to the system), then the confidentiality issues with respect to the authorization are not
important.
In order to explain how Table 2 could be used, we will consider a few entries in it:
UI partition/Authenticity
In the UI partition, the client responsibility is limited to the display of information. This does
not imply that the client has no intelligence, however, but merely points to the fact that the
main decisions regarding the presentation of the user interface reside with the presentation
logic on the server. In order to allow for authentication techniques such as Kerberos to
function in this environment, the client should be able still to do encryption and decryption. If
Kerberos is employed as the authentication technique, then the client will capture the user-
ID, send it, together with a request for a ticket-granting ticket, to the authentication server
(AS) and receive a ticket back that is encrypted by the AS with the user password. The client
then prompts the user for a password and tries to decrypt the ticket, using the supplied
password as key. If successful, the client receives a session key from the AS, which is used in
subsequent messages in the protocol to encrypt sent messages.
At server level, we could distinguish three kinds of servers that need to be present (in the
Kerberos case), namely the authentication server, the ticket-granting server and the
application server. These services could be provided either by a single machine or they could
be distributed among three machines. The authenticity of information can be proven by
digitally signing the information before it is stored. The server can vouch for the authenticity
of the data, as it was encrypted using a private session key. In order to sign the information a
public-key encryption scheme is used. Data signed by A (encrypted with the private key of
A) can only be decrypted using the public key of A and, as such, advance proof of
authenticity.
Table 2 Information security services and mechanisms for the various client/server partitions

Hashing, error detection, Capturing of user-ID and Decryption and Speedy replacement of User interface design;
parity bits. passw ord. encryption faulty equipment; standardization of
UI- Encryption and redundant equipment interface (consistency).
partition
Client
decryption. made available
Integrity rules on Authentication protocol ACLs (id and/or role- Backup procedures; Physical security: access Presentation formats, e.g.
database or application involving third party. based). disaster recovery plans; control to disaster- graphs, charts and maps.
level. Kerberos AS and TGS. Encryption & decryption. RAID; automated resistant secure area.
Server
Hashing, error detection. Digital signatures. Firew alls. processes; redundant Backups stored off-site.
routing.
Hashing, error detection, Kerberos client softw are. Firew alls. Speedy replacement of Replication of databases. User interface design;
parity bits. Unw rapping of X.509 faulty equipment; Access control. standardization of
Logic certificates. redundant equipment Backups. interface (consistency);
partition
Client
made available presentation formats, e.g.
graphs, charts and maps.
Integrity rules on Kerberos authentication ACLs (id and/or role- Backup procedures; Physical security: access
database or application server and ticket-granting based). disaster recovery plans; control to disaster-
level. server. Encryption & decryption. RAID; automated resistant secure area.
Server
Hashing, error detection. Off-line generation of Firew alls. processes; redundant Backups stored off-site.
certificates by CA. routing.
Integrity rules in Kerberos client softw are. ACLs. speedy replacement of Replication of databases. User interface design;
application Unw rapping of X.509 Firew alls. faulty equipment; Access control. standardization of
Storage certificates. redundant equipment Backups. interface (consistency);
partition
Client
available presentation formats, e.g.
graphs, charts and maps.
Kerberos authentication Encryption of information. backup procedures; Physical security: access
server and ticket-granting Firew alls. disaster recovery plans; control to disaster-
server. RAID; redundant routing resistant secure area.
Server
Off-line generation of Backups stored off-site.
certificates by CA.
Logic partition/Integrity
Both the client and the server need mechanisms such as hashing, checksums and parity bits to
ensure that integrity problems are not introduced during transmission. Integrity of the data
when stored can be protected by defining the integrity rules as part of the database
(information logic sub-module). If this is not the case, the integrity rules can be implemented
as a special application logic sub-module which will reside on the server. Keeping the rules
on the server(s) and not at the client level, will reduce the possible points of attacks and
facilitate control.
Storage partition/Confidentiality
The server-operating system is responsible for protecting the data files. Encryption
techniques can be employed by the server to ensure that the data files cannot be read, even if
the access-control mechanisms of the server-operating system were bypassed. Information
and users need to be classified and accessed mapped in an ACL. The ACL may be stored in a
form of database (information-storage module), but is interpreted by the information logic
sub-module on the client.
The user also plays an important part in maintaining the confidentiality of the information.
Agreements between company management and the users must protect the company from
sensitive information being lost because of authorized users providing it to unauthorized
users.
Firewalls could be introduced between the company networks and other external networks
in order to ensure that unwanted communications do not take place. It can protect
confidentiality in two ways: firstly incoming traffic can only be allowed from certain places,
reducing the chances of unauthorized access to information. Secondly, “inside” users could
be limited only to communicate with certain “outside” addresses, thus reducing the chances
of users sharing sensitive information with outsiders.
1.4 Conclusion
In this article, proof is advanced that the client/server partition that is implemented does
influence the security requirements of an organization. These different security requirements
must be conformed to by implementing various security services and techniques, depending
on the level of security required. The security policy of an organization should, therefore,
clearly reflect these security requirements, with specific reference to the client/server
partition implemented and the security attributes that are protected by the various techniques.
The services and techniques referred to in the article are all relatively technical issues. It is
important to note, however, that the security policy should also provide for less technical
issues, such as agreements between the users in and the management of the organization.
Further work on Table 2 will prove invaluable in laying down security policies for a
distributed client/server environment.
2. REFERENCES
[COLE90] Cole, R. “A Model for Security in Distributed Systems”, Computers and
Security, Vol 9, 1990, pp. 319-330.
[COOP95] Cooper, F.J., et al., “Implementing Internet Security”, New Riders, 1995.
[DAVI89] Davies, D.W. & Price, W.L., “Security for Computer Networks”, 2nd Edition,
John Wiley & Sons, 1989.
[DEIT90] Deitel, H.M., “An Introduction to Operating Systems”, 2nd Edition, Addison-
Wesley, 1990.
[DELO93] Deloitte & Touche Management Consulting, “Information Protection and
Client-Server: New Approaches for New Environments.” 1993.
[DIXO96] Dixon, R., “Client/Server and Open Systems”, John Wiley & Sons, 1996.
[FRAN93] Francis, R., “The Search for Client/Server Security” Datamation v39, May
1993, pp 39-43.
[GOLL93] Gollman, D., Beth, T. & Damn, F. “Authentication services in distributed
systems”, Computers and Security, Vol 12, pp. 753-764.
[HART95] Hart, J.M. and Rosenberg, B., “Client/Server Computing for Technical
Professionals”, Addison-Wesley, 1995.
[HUGH95] Hughes, L.J., “Actually Useful Internet Security Techniques”, New Riders,
1995.
[ISO90] ISO/IEC 9594-8 “Information Technology -- Open Systems Interconnection --
The Directory -- Part 8: Authentication framework”, 1990.
[KANU94] Kanungo, S., “Identity authentication in heterogeneous computing
environments: A comparative study for an integrated framework”, Computers
and Security, Vol 13, pp. 231-253.
[KRUY91] Kruys J.P., “Progress in Secure Distributed Systems”, Computers and
Security, Vol 10, 1991, pp. 429-441.
[ORFA94] Orfali, R., Harkey, D & Edwards, J., “Essential Client/Server Survival
Guide”, John Wiley & Sons, 1994.
[PRES91] Press, J., “Secure Transfer of Identity and Privilege Attributes in an Open
Systems Environment”, Computers and Security, Vol 10, 1991, pp.117-127.
[REIT93] Reitenspiess, M., “Open Systems Security Standards”, Computers and
Security, Vol 12, 1993, pp.341-361.
[SINH92] Sinha, A., “Client-Server Computing”, Communications of the ACM, Vol 35,
No 7, 1992, p. 77-97.
[STRA93] Strauss, P., “LAN Boom paves the way for Client/Server”, Datamation, Nov
15, 1993, pp.40-48.
[SYMO94] Symonds, I.M., “Security in Distributed and Client/Server Systems -- A
Management View”, Computers & Security, Vol 13, 1994, p. 473-480.
View publication stats

Information Security in The Clientserver Environme

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Security in The Clientserver Environme

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Information security in the client/server environment /

Article · January 1997

Masters Degree View project

The user has requested enhancement of the downloaded file.

submitted for fulfillment of the requirements

for the degree of

RAND AFRIKAANS UNIVERSITY

Study leader : Prof J.H.P. Eloff

Client/Server computing is currently one of the buzzwords in the computer

In order to address this definite need for a secure client/server environment it

Security, or secure systems, have a different meaning for different people.

Different security techniques and measures are discussed and classified in

This dissertation furthermore defines an electronic document management

Kliënt/Bediener rekenarisering is huidiglik een van die modewoorde in die

2. INFORMATION SECURITY ATTRIBUTES ......................................................................6

5. EVALUATION CRITERIA AND THE CLIENT/SERVER ENVIRONMENT.....................28

7. THE WORLD WIDE WEB ...............................................................................................55

8. THE CONSOLIDATED FRAMEWORK...........................................................................70

9. AN ELECTRONIC DOCUMENT MANAGEMENT SYSTEM AS CASE STUDY............76

10. SECURITY POLICIES FOR THE CLIENT/SERVER ENVIRONMENT .........................87

Throughout the world information is expanding at a phenomenal rate. In order

The emphasis within open systems is to share information and other

The client/server architecture can be considered a specific case of an open

1.2 Definition of key concepts

Information security is the steps taken, tools implemented and mechanisms

Client/server computing devides the processing of tasks in an application

A client is an intelligent workstation, typically a PC, with capabilities of doing

A server is a computing device that is used with the specific intention of

1.3 State of the art

The continued increase in the usage of computer systems to manage the

If companies are questioned as to why they are changing to client/server

1.4 Problem statement

This dissertation attempts to address the following questions:

• What are the functional security components of the client/server

• What influence does the client/server architecture have on the

• Research has lead to well-defined standards and policies for the

• The application, together with its user interface, provides a means of

• In which way should the specific characteristics of a client/server

Some of the aforementioned issues were addressed partially by other

environment, but failed to distinguish a client/server environment from a more

1.5 Overview of this study

Chapter 2 describes the information security attributes that will be used to

Client/server implementations can be distinctly grouped according to the

Chapter 4 ties the concepts of client/server partitions and security attributes

Chapters 5 – 7 subsequently study the potential sources for security methods

Chapter 5 studies evaluation criteria and evaluates it as a source of security

Chapter 8 consolidates the methods and techniques identified through

Chapter 9 identifies certain problems in electronic document management

Chapter 10 presents a possible structure for an information security policy in

Chapter 11 summarizes the findings of this dissertation and identifies further

A bibliography of the literature consulted is provided and a copy of an article

Information availability can be described as the ability to immediately obtain

List 2-1: Possible threats to availability of information

The utility attribute describes the usefulness of the information. In other

List 2-2: Possible threats to information utility

Integrity of the information points to the unimpaired soundness of the

List 2-3: Possible threats to integrity of information

Other chances of corrupting the information are during transmission of the

Information authenticity represents an authoritative quality, indicating that the

List 2-4: Possible threats to authenticity

masquerading as somebody else

Two important aspects of authenticity are (1) the authenticity of

The information logic sub-module on receipt of the SQL-statement will

The information storage module translates the logical read requests

The information logic sub-module receives the information and formats

The application logic sub-module does further operations on the

The presentation logic sub-module on the server decides in which

The user interface module on the client presents the information as

The information logic sub-module will logically translate the write

The information storage module interprets the logical write request in

The information logic sub-module interprets the status code and

The application logic sub-module’s behavior is governed by the value

The presentation logic sub-module interprets the received status code

The information logic sub-module on the server interprets the request

The information storage module returns the requested information to

The application logic sub-module on the server does the interpretation

The presentation logic sub-module decides how the document should