0% found this document useful (0 votes)
350 views

Security Management in Distributed Systems

This document is a certificate for a research project titled "Security Management in Distributed Systems". It contains signatures from the student, guide, and director/HOD to certify that the project was completed by the student under the guidance of the named guide. It also includes an acknowledgement section where the student expresses gratitude to the guide for their support and guidance during the project.

Uploaded by

daily care
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
350 views

Security Management in Distributed Systems

This document is a certificate for a research project titled "Security Management in Distributed Systems". It contains signatures from the student, guide, and director/HOD to certify that the project was completed by the student under the guidance of the named guide. It also includes an acknowledgement section where the student expresses gratitude to the guide for their support and guidance during the project.

Uploaded by

daily care
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 55

CERTIFICATE

I, Your name , Your Roll No,certify that the Research Project entitled
“Security Management in Distributed Systems” is done by me and it is
an authentic work carried out by me. The matter embodied in this project
work has not been submitted earlier for the award of any degree or diploma
to the best of my knowledge and belief.

Signature of the Student


Date:

Certified that the Research Project entitled “Security Management in


Distributed Systems” done by Student name, Roll No. is completed under
my guidance.

Signature of the Guide


Date:
Name of the Guide:
Designation:

Countersigned
Director/HOD

1
ACKNOWLEDGEMENT

I should like to express my sincere and profound gratitude to my guide, for


his invaluable guidance, continuous encouragement and whole hearted
support in every stage of this project. It is my privilege and honour to have
worked under his guidance. It is indeed difficult to put his contribution in a
few words.

2
TABLE OF CONTENTS

S No Topic Page
No
1 List of Figures:

List of Tables:

2 Chapter-1: Introduction 1
3 Chapter-2: Review of related work 4
4 Chapter-3: Proposed Work 8
5 Chapter 4: SECURITY MECHANISMS IN 9
DISTRUBUTED SYSTEM
6 Chapter 5: SECURITY POLICIES IN DISTRIBUTED 15
SYSTEM
7 Chapter 6: SECURITY STANDARDS IN 24
DISTRIBUTED SYSTEM
8 Summary/Conclusion 28
9 References 29

3
CHAPTER 1

INTRODUCTION

Security is the most important issue in the distributed systems. Security has

become more complicated with the expanded use and networking of

personal computers. At present, the local networks and the connections

between the large and small computers are such that each of them takes part

in the application. The application as a whole appears to be located on the

user's computer, but in fact each user and each application has access to, and

4
sometimes even control over, organizational data on various computers and

storage facilities.

Obviously, such openness invites unauthorized use, and requires data

security coordination and management (Appleton, 1997). Unfortunately,

many companies do not deal with data security and network management

problems until there is a crack in the network. To protect vital information,

the companies must set up a sound security system before the network is

intruded. This involves identification of the security risks, applying

sufficient means of security, and teaching the users data security awareness.

Unfortunately, many companies do not deal with data security and network

management problems until there is a crack in the network. Distributed

systems developed rapidly over the past two decades and security can be

measured in the concept in term of hardware aspect and software aspect. The

recent attacks on government and commercial computers indicate that

“hacking” has gone beyond the realm of domestic pranks and has entered the

domain of state sponsored cyber-terrorism

5
1.1 Objectives of the project:

It is helpful to distinguish between the primary and secondary objectives of

security.

The primary objectives correspond to threats such as disclosure, corruption,

loss, denial of service, impersonation, repudiation. The secondary objectives

lead to the specification of services to support the primary ones.

There are three primary security objectives which apply to both stored data

and messages in transit. They are:

 Confidentiality - maintaining confidentiality of information held

within systems or communicated between them.

 Integrity - maintaining the integrity of data held within systems or

communicated between systems. This prevents loss or modification of

the information due

 Availability - maintaining the availability of information held within

systems or communicated between systems, ensuring that the services

which provide access to data are available and that

data is not lost.


6
 Authentication - authenticating the identity of communicating

partners and authenticating the origin and integrity of data which is

communicated between them.

The secondary security objectives identified by the Security Architecture are

as follows:

 Access Control - providing access control to services or their

components to ensure that users can only access services, and perform

data accesses, for which they are authorized.

 Audit Trail - providing an audit trail of activities in the system to

enable user accountability.

 Security Alarm - the detection of occurrences indicating an actual or

potential security failure should raise an alarm and cause the system to

operate in a fail-safe mode.

1.2 Methodology:

For the development of this system I use the prototyping Model of Software

Development Life Cycle. A prototype is a model or a program which is not

based on strict planning, but is an early approximation of the final product or


7
software system. A prototype acts as a sample to test the process. From this

sample we learn and try to build a better final product. Please note that this

prototype may or may not be completely different from the final system we

are trying to develop. 

1.21 Need of Prototyping Model

This type of System Development Method is employed when it is very

difficult to obtain exact requirements from the customer (unlike waterfall

model, where requirements are clear). While making the model, user keeps

giving feedbacks from time to time and based on it, a prototype is made.

Completely built sample model is shown to user and based on his feedback,

the SRS (System Requirements Specifications) document is prepared. After

completion of this, a more accurate SRS is prepared, and now development

work can start using Waterfall Model. 

1.24 Data Collection:

Here most of the information was collected from the internet from as par

the part of the planning for the organization and was then framed into

8
logical data. Sources all data collection is based on secondary data

collection.

Secondary data are indispensable for most organizational research.

Secondary data refer to information gathered by someone other than the

researcher conducting the current study. Such data can be internal or

external to the organization and accessed through the internet or perusal of

recorded or published information.

The major site from where the data has been collected is

www.wikkipedia.com. Therefore the internet has been the source of data

for my research project and I would consult it for any further information

required during the research project.

9
CHAPTER 2

REVIEW OF RELATED WORK

In Sep 1983, Nessett spoke about A Systematic Methodology for

Analyzing Security Threats to Inter process Communication in a

Distributed System and said It is observed that a direct mapping exists

between a distributed system's physical configuration and the

10
security threats that can be mounted against inter process communication in

that system. A systematic methodology is presented which implements that

mapping for a large class of distributed systems. The methodology includes

a model of threats to inter process communication as well as a model

of distributed system security configurations. This methodology is useful in

situations where certain major characteristics of the

distributed system physical configuration will remain stable over a long

time.

In 2002 P. Y. Gan and K. S. Lee proposed The first paper by M. Ahamad, S.

Lakshmanan, and H. Venkateswaran explores the subject of responsive

security for stored data. A long-standing problem in

distributed systems security is how to specify and enforce

correctly security policies. In this paper, we mainly focus on how to

systematically specify correct policies instead of manually configuring them

and how to automatically enforce security policies in distributed systems.

In Oct 2004, Naqvi and S Riguidel proposed on the topic of

security architecture for heterogeneous distributed computing systems and

11
explained that distributed systems face a proliferation of users, applications,

networked devices, and their interactions on a scale never experienced

before. The advent of reliable spontaneous networking technologies has

ostensibly raised the stakes for the design of computing intensive

environments using intelligent devices. As environmental intelligence

grows, so will the number of heterogeneous devices connected to the

environment. The creation of security and trust paradigms for such

technology rich environments is today's great challenge.

In Feb 2005, Nessett and D.M. proposed to some factors, affecting in

distributed system security. Recent work

examining distributed system security requirements. is critiqued. A notion of

trust based on distributed system topology and distributed system node

evaluation levels proposed in that work is shown to be deficient. The notion

fails to make allowances for

the distributed system physical security environment, security factors related

to the management of distributed systems by more than one jurisdictive

authority, and the interactions that can occur between nodes supporting

different mandatory and discretionary security mechanisms.

12
In April 2006, Lin and Varadharajan proposed the use of trust based risk

management for distributed system security - a new approach and said that

Security measures alone are not sufficient for counteracting malicious

behaviors in distributed systems. The new trend is to use economical

models (mainly game-theoretic models) to characterize such malicious

behaviors in the security context with the aim to mitigate the risk introduced

by such malicious behaviors.

In Oct 2007, Hamdi, H proposed A Software Architecture for Automatic

Security Policy Enforcement in Distributed Systems, in which he tried to

explain that Policies, which are widely deployed in networking services

(e.g., management, QoS, mobility, etc.), are a promising solution for

securing wide distributed systems. However, the adoption of a policy-based

approach for security requires an appropriate policy specification and

enforcement tools. In fact, A long-standing problem in

distributed systems security is how to specify and enforce

correctly security policies. In this paper, we mainly focus on how to

systematically specify correct policies instead of manually configuring them

and how to automatically enforce security policies in distributed systems. A

software engineering approach is presented to overcome these issues. This


13
approach is based on design and development of a software architecture to

automating definition and enforcing policies. I. Introduction

In 2009, Benson and G Appelbe, proposed his views on the topic called

hierarchical model of distributed system security and explained that A

description is given of the hierarchical model (HM), an access matrix-based

model used to define nondisclosure in distributed multilevel secure

applications such as secure file systems, secure switches, and secure upgrade

downgrade facilities. The HM explicitly encodes access rights,

synchronization primitives, and indirection in its state matrix. Serializability

of concurrent commands is formally defined in terms of the HM syntactic

model of computation. HM serializability conditions are independent of the

semantic security predicate. Finally, an example that illustrates the HM is

presented

In 2011, Atmaja and T.D discussed on the topic of Cyber security strategy

for future distributed energy delivery system and told that energy

delivery systems in future manner will be referred to a modernization of

delivery system so it monitors, protects and automatically optimize the

14
operation of its interconnected elements. Its contain power generations,

transmission network and user automation. It characterized by two way flow

of electricity and information to create an automated distributed energy

delivery system. From the viewing side of information flow, there are

management and protection of the system that must be strategized to ensure

the effective operation of the energy delivery system.

In 2012, the research was published with the name of Garcia, M, “Applying

dynamic separation of aspects to distributed systems security,” and

exclaimed that Distributed systems are commonly required to be flexible and

scalable, as the number and arrangement of their (potentially mobile)

devices may easily change. Security in distributed systems is a complex

issue which can produce several problems such as eavesdropping, phishing

or denial of service. To overcome these problems, there are

various security measures that can be applied. This study proposes the use of

dynamic aspect-oriented software development (AOSD) to

implement security mechanisms in distributed systems.

In 2012, Yue Ma, gave the presentation on a distributed feedback control

mechanism for security-critical Real-time system and stated that since the

real-time systems are becoming increasingly networked, there are some

15
growing critical challenges of security management and risk control. For the

unpredicted and especially unsecured environments, such security-

critical distributed real-time embedded systems need to enforce security on

multiple nodes in order to against the potential threats as well as satisfying

the real-time requirements. Unlike the traditional ad hoc static designing

approaches, based on feedback theory, this paper proposes an Adaptive Risk

Control and Security Management (ARCSM) mechanism for

centralized distributed systems. ARCSM has the ability to guarantee the soft

real-time and provide as strong security protection as possible. To meet this

requirement, the host server is able to refuse to serve for the deadline missed

tasks. In each node, a two-level scheduling framework is designed to

implement the feedback control twice. In the first feedback, an appropriate

initial security level is assigned for new task. At the runtime, the second

feedback can dynamically adjust the ready tasks' security level based on

runtime status. Considering features of embedded systems, we measured the

energy and time costs of cryptographic algorithms and established a method

to quantify the security risk. Moreover, the relationship between time and

energy costs analyzed in this paper leaves its significance for the future

researches. Experimental results demonstrate that our mechanism can be

16
adaptive to the fluctuation of input workloads and has better performance

than open-loop schemes.

CHAPTER 3

PROPOSED WORK

3.1 Definition:

This section discusses the complexity of the problem and the difficulty in

solving

Unfortunately, development of data security in distributed systems takes

place simultaneously with the development of the network, as described

above.

Development in stages may result in an increase of the sensitive points in the

network security, as described Denning, P. J. (Ed.). (1990).

1) In some non automatic security subsystems, manual login

mechanisms force users to type their user name and password. Not

only does this make the system inefficient, it even exposes the data

17
security mechanism, for the users often write down their password on

paper next to their working station, for everyone to see Denning

2) Furthermore, most users do not make a habit of changing their

passwords every so often and continue using the same password over

and over again.

3) How should the monitoring be done? Usually, a distributed

monitoring architecture is recommended to minimize performance

overheads. However, this may impose serious security problems as

the information gathered from the system is distributed at different

sites.

CHAPTER 4

SECURITY MECHANISMS IN DISTRUBUTED SYSTEM

A number of different mechanisms are used to achieve security

objectives. They include:

1. Physical and electronic security of components of the

system

2. Authentication mechanisms

3. Access control mechanisms

18
4. Communication security mechanisms

They are described briefly here. Interested reader are referred to

Further Reading for more detail.

1. PHYSICAL SECURITY MECHANISMS

Physical security mechanisms are used for protection of equipment and for

access control outside the scope of logical access control or encryption.

They are necessary for protection against risks such as fire, tempest, terrorist

attacks and accidental or malicious damage by users and technicians.

Physical security requires a variety of mechanisms:

 Preventive Security - strong construction, locks on doors, fire

resistance and waterproofing,

 Detection and Deterrence - movement detectors and door switches

linked to alarms, security lighting and closed circuit television,

 Recovery - the provision of a backup site, with alternative computing

and communication arrangements.

19
A basic level of physical security is always necessary even in the presence of

logical access control and encryption. In some situations physical protection

may be simpler and more secure than a logical solution, for example, by

controlling physical access to terminals and personal computers and their

data and by storing sensitive data on demountable media.

2. ELECTRONIC SECURITY MECHANISMS

Electronic security mechanisms may be needed for protection against

interference from static electricity and RF (Radio Frequency) interference,

both of which can cause computer and communication equipment to

malfunction. They are also required for Radiation Security to avoid the

passive eavesdropping of electromagnetic radiation from visual display

units, printers and processors. The modulated signals can be detected by

nearby radio receivers and analyzed to reveal the data being displayed,

printed or processed. Preventive devices are commercially available, and

there are also military standards of protection (so-called "Tempest"

proofing).

3. AUTHENTICATION

a) Personal Authentication

20
The aim of personal authentication in computer systems is to verify the

claimed identity of a human user. There are a number of different

mechanisms for it, all based on one or more of the following principles:

 A personal characteristic of the user, (fingerprint, hand geometry,

signature, etc.) which is unique to the individual.

 A possession of the user, such as a magnetically or electronically

coded card, which is unique to that person.

 Information known only to the user, for example, a secret password or

encryption key.

Secret personal passwords are the simplest and cheapest method to

implement, and they provide an adequate level of protection for medium and

low security applications. They need a number of supportive measures if

they are not to be undermined. The measures include, regular change by the

user, one-way encrypted storage, minimum length and controlled format

(such as no dictionary words), limited number of permitted attempts, and

logging and investigation of all failures. They can be reinforced by

restricting users to logging in at specific physically protected terminals, for

21
example, Payroll clerks may only log on in that capacity using one of the

terminals sited within the Payroll Office.

The use of passwords across open communication channels in distributed

systems is a particular problem because the password can be discovered by

eavesdropping on the channel and then used to impersonate the user. One

solution to this is the use of one-time passwords generated by smart cards

(see below).

Magnetically coded cards have some advantages over passwords - they

cannot be copied so easily and are less easy to forget. However, they also

suffer from the potential exposure of their contents in open communication

channels.

Smart cards offer increased security because they can be programmed to

provide variable information. There are several modes in which they can be

used for personal authentication.

Two of these are:

22
 One-time password generators which generate a different password

each time they are used. One commercial product changes the

password every minute. In all cases the computing service must

synchronize with the password generator.

 Challenge response devices. The host sends a challenge number and

the smart card has to calculate the correct response, including input

from the user.

Smart cards are becoming cheaper and easier to use and they promise to

provide a satisfactory way of overcoming the problems of personal

authentication in distributed systems. However, any authentication system

must cope with the problem of protecting the secure information upon which

it is based.

b) Message Authentication

The aim of message authentication in computer and communication systems

is to verify that the message comes from its claimed originator and that it has

not been altered in transmission. It is particularly needed for EFT (Electronic

Funds Transfer). The protection mechanism is generation of a Message

Authentication Code (MAC), attached to the message, which can be

23
recalculated by the receiver and will reveal any alteration in transit. One

standard method is described in (ANSI, X9.9). Message authentication

mechanisms can also be used to achieve non-repudiation of messages.

4. LOGICAL ACCESS CONTROL

Logical access control has to be used when physical access control is

impossible, as is the case in multi-user systems. A model for logical access

control is provided by a Reference Monitor, which intercepts all access

attempts and allows them only if the access is authorized. Otherwise the

access is blocked, an error message is returned to the user and appropriate

logging and alarm actions are taken.

There are two main implementations of access rules:

 An Access Control List (ACL) is attached to the target entities,

defining the users who are authorized to access them and the

operations which they can perform.

 Users obtain authenticated Capabilities which act as tickets

authorizing them to access defined resources.

24
5. COMMUNICATION SECURITY MECHANISMS

There are two main mechanisms in ensuring communication security, in

addition to physical protection of the lines and equipment: encryption, and

traffic padding.

Encryption is one of the most important techniques in computer and

communications security. Cryptography means literally "secret writing".

Encryption transforms enciphers) plain text into cipher text, which is

impossible to read, and decryption transforms it back again into readable

plain text (deciphers it). Cryptography has been practiced for thousands of

years, but the advent of computer-based decipherment algorithms has

changed it from a difficult and unreliable to a simple and powerful one.

Algorithms such as the Data Encryption Standard, described below, are

easily available, simple to use, and provide a high degree of protection

against threats to the confidentiality and integrity of communications.

Traffic padding will only be dealt with briefly here. Its purpose of is to

conceal the existence of messages on a communication line, by inserting

25
dummy messages on the line to ensure that there is a uniform level of traffic

at all times. It is mainly of interest in a military level of security.

Encryption can be used for several purposes: the prevention of

eavesdropping, the detection of message alteration, and, in conjunction with

the use of unique message identities, the detection of message deletion and

replay.

a) Link or End-to-end Encryption

Encryption may be used on individual links or on an end-to-end basis. Link

encryption only covers the communication links, and the information is "in

clear" at each communication processor. By contrast, end-to-end encryption

is carried out directly between the initiating and target systems. An

intermediate level is network encryption, where encryption spans an entire

network, but not the gateways between networks. In all cases where

encryption is carried out by a separate hardware unit, the link between the

terminal and the unit is not covered by encryption, and physical protection is

required in addition.

b) Encryption Algorithms
26
There are two main types of encryption:

 Secret key encryption, which uses a single secret key shared between

sender and receiver.

 Public key encryption, which uses a related pair of keys. One key is

publicly available and may be used to encrypt messages, while the

other key is secret, known only to the receiver, and may be used to

decrypt messages.

Secret key encryption is available in a number of proprietary algorithms, and

in the Data Encryption Standard (DES) which is an American, but not an

international, standard. The DES is described in a number of text books

(Davies & Price, 1989). The DES algorithm is available in software and also

in hardware as a semi-conductor chip, providing higher performance. The

chip is subject to export restrictions from the USA, and the hardware is

therefore not suitable for multi-national applications. Any secret key

algorithm suffers from key management problems, because of the need to

transport secret encryption keys securely. There is a standard method of key

management, described in (ANSI, X9.17), which covers: key generation and

27
distribution, protection of the key management facility, and protocols for the

cryptographic service.

28
CHAPTER 5

SECURITY POLICIES IN DISTRIBUTED SYSTEM

Policies are the plans of an organization to meet its objectives. Within the

context of security, a security policy defines the overall objectives of an

organization with regard to security risks, and the plans for dealing with the

risks in accordance with these objectives. Policies are usually hierarchical;

the plans of a high-level policy are the objectives which a lower level policy

must address.

All organizations should have a high-level security policy, defining the

overall security goals of the organization and setting out a framework of

plans to meet the goals. These high-level objectives vary substantially from

organization to organization. Military organizations place a high value on

secrecy in contrast to academic institutions which value openness of

information. Financial institutions are concerned above all with maintaining

the integrity of data and messages which represent money. The default for

simple social organizations is to have no security policy at all.

29
Security policies are not always precisely formulated or written down, but an

effective computer security policy requires that the following questions are

answered:

 What are the assets to be protected, and what is their

value?

 What are the threats to these assets?

 Which threats should be eliminated and by what means?

The security policy for a distributed system should reflect the senior

managers' expectations of the organization’s security objectives. Often, just

as an organization’s security objectives may not be precisely formulated,

those in a distributed processing environment are unstated and they must be

extracted from other documents, or identified and agreed by persuasion and

discussion with the staff of the organization in question.

A high-level security policy can make general statement about the goals of

the organization, but in order to be effective it requires a risk analysis to be

carried out so as to understand the vulnerability of the organization and the

consequences of security breaches. Risk management, discussed below in


30
section V.C, is required because of the possible trade-offs between the

anticipated cost of threats and the actual costs of security measures. The

security measures taken to counter a threat should be commensurate with the

threat itself. The results of a risk analysis may help to redefine or focus high-

level policies, as well as define the lower-level policies for managing the

system in a secure manner.

The choice of security services will have to reconcile a number of

conflicting objectives which include the following:

 Security policy is often defined centrally but applied locally, or in

each application, and at many intervening points in the

communication between each user. There are therefore practical

difficulties in ensuring that a security policy is met.

 Design of existing standard communication products and many

operating systems has avoided or neglected considerations of security.

Security requirements therefore have to be negotiated separately with

system suppliers, requiring much greater effort in procurement than if

they were defined as part of a standard or an intrinsic part of the

operating system.

31
A. SECURITY INTERACTION POLICIES

It is possible to create a distributed system in which all aspects of security

are centrally managed to a common standard. Because a distributed system

is more likely to evolve by federation of a number of existing different (and

heterogeneous) systems, they may have previously operated to a variety of

security policies. It is always possible that these may be incompatible, either

because the policies of the systems differ in the level of security they

provide or tolerate, or because there is technical incompatibility, for example

because different encryption algorithms have been selected.

ISO have recognized this problem and have introduced the concept of a

Security Interaction Policy as part of the Security Frameworks. This is a

policy which is acceptable to all parties in an interaction. It has to be

negotiated between them before they can communicate. The Issues which

have to be resolved between them are both the level of security and the

technical compatibility of their security mechanisms. So far as the level of

security is concerned, this is not limited to the security parameters relating to

their communication.

32
An inter-organizational Security Interaction Policy agreed and committed to

by all parties, may be difficult to negotiate because of the need for more

widespread compatibility than simply of communication security standards.

For example, there may be incompatibilities in the levels of security of their

operating systems. If a common security policy cannot be agreed it may be

decided to decline to communicate, either because the risk is unacceptable or

to avoid the imposition of unacceptable or uncongenial security practices.

For example, most organizations which are running their installations to

government military security standards do not allow electronic mail to run

on any of their networked computers, because of the known security

exposures associated with it. They have to use a special free-standing

electronic mail which is disconnected or buffered from the rest of their

systems.

A Security Interaction Policy in a distributed system should lead to the

generation of an agreed schedule of required security services and their

supporting mechanisms.

33
B. THE PRACTICAL APPLICATION OF ITS SECURITY

POLICIES

To illustrate the practical application of information technology (IT) security

polices in a distributed processing environment, some of the policies which

could apply to a typical company are described. They are divided into the

following areas:

 Security administration policies,

 Security levels,

 Communication security,

 System access control,

 Data access control,

 Disaster planning,

 System audit ability,

 Legal and regulatory policies relating to security.

Note first of all the extent and limits of these policies. They include

the areas needed to ensure the confidentiality, integrity and availability of


34
information, with two notable exceptions. First, they do not cover the

backup and recovery procedures which are part of normal day-today IT

operations. It is assumed that, in addition to an IT Security Policy, the

organization has an IT Computer Operation Policy which covers day-to-day

computer operating procedures, including recovery from incidents such as

system failures and disc crashes, and also an IT Communication

Management Policy covering procedures such as alternate routing in the

event of line failures. The exclusion of these areas from security policies is

to some extent arbitrary, but is common to many organizations, which prefer

to regard them as aspects of system and communication operations. It is of

course essential to ensure that these subjects are covered in one policy

document or another.

Second, these security policies also exclude system change control. This too

may be regarded as arbitrary, but the justification is again that it should be

covered in other policies. Those aspects of change control relating to

reconfiguration of the system by changing hardware components such as

processing systems and networks should be covered by IT Computer

Operations and Communication Management Policies. Software change

35
control should be covered by polices for IT Computer Operations and

Development.

In a typical commercial organization, security will make little or no direct

contribution to each department's achievement of its immediate goals (until

something goes wrong), while costing a substantial amount of effort and

money. Therefore if the security policies are to be effective they need to be

endorsed at the highest possible level of management, usually Board level,

and included in the targets which are set for each department. Only then will

business managers regard them as an integral part of their goals.

Further, they must be communicated effectively. Many organizations have

informal security policies which can be deduced from other policy

documents and from management decisions which may be buried in internal

memoranda and difficult to find. Effective security policies need to be

separately and clearly documented, preferably as a Security Policy document

or as a section in an IT Policy document. It is then possible for IT and user

personnel to find out easily what the policies are, there is no possibility of

effective implementation of a policy which nobody knows about.

36
The first recommendation for a company is therefore that the director

responsible for IT obtains Board approval for the creation and enforcement

of IT security policies, as set out in an IT Security Policy document.

1. Security administration policies

The foundation of the security policies of the organization will be an

effective organizational structure. While information processing is

centralized, it is sufficient to put someone in charge of enforcement of IT

security throughout the organization. However, as soon as it becomes

distributed it is necessary to have a two-tier organizational structure: a

central Security Coordinator, and Security Administrators covering every

department of the organization. To respect the autonomy of distributed

systems, direct responsibility for security in each system should be held by

its Security Administrator, but in order to ensure that the level of security is

consistent throughout the organization the Security Coordinator should have

the goal of ensuring that each system is working to compatible standards and

procedures. Typically the Security Coordinator has two tasks: ensuring that

each Security Administrator is aware of the standards and procedures, and

37
helping departmental business managers to ensure that they are adhered to

the main concern of a company, apart from setting up its IT security

organization, must be to ensure that the net is spread widely enough, every

independent system which has eluded the control of communication or

systems management is a potential security risk. The personal computers

which have “gone independent” may or may not be operating to company

standards of security. Each must be brought in under the umbrella of the

appropriate Security Administrator.

2. Security levels

Management policies should be made about groups of objects, rather than

individuals. Most organizations will need to apply this concept to security

measures also. If just a few levels of security can be identified, and a

package of security measures defined for each level, then detailed decisions

about individual objects can be avoided.

Commercial organizations are likely to define two types of security level: for

data and for users. Most aim to give the same level of protection to all their

data, so that there will only be one security level defined for data. This is

38
much easier to administer than multiple levels and accords with the usual

requirement, that sharing and mobility of data must be enabled but

controlled. However, there may be a requirement to treat some data

especially securely, either because its confidentiality is critical to the success

of the business or, more commonly, because of the terms of a government

contract.

On the other hand, it is quite common to wish to make distinctions between

categories of users, especially when outsiders are given limited access to the

system for special purposes, or when insecure dial-in access is permitted. So

there may be a policy to treat three categories of user differently: normal

users, who have the least restricted access, the same users when they dial in,

whom to be are allowed access to specifically pre-defined data, and

outsiders, with a similar restriction. Note that this concept of security levels

has similarities to the military-type security levels of mandatory security

(Department of Defense (USA), 1985), but is much less formally defined.

3. Physical Security

39
Physical security is the basis of all other system security. There should be a

policy which requires an appropriate level of physical protection for all

physical assets within its control.

4. Communications security

Communications security policies typically define the required levels of

confidentiality, integrity and availability. They are divided into two

categories: the security of the corporate networks, and the criteria for

applications to provide a higher level of security on an end to end basis.

Based on today's technology, the policy is likely to require assured integrity

and a defined percentage of availability from the network, but not to insist

on assured network confidentiality. Within a few years, with increasing

availability of cheap encryption products, the policy is likely to be upgraded

to insist on network confidentiality also.

5. System access control

Perhaps the most important security measures to be taken in an organization

with open distributed systems are to do with controlling the access of users

to the system. Their needs therefore to be a policy about system access

control, with two main parts. The first part states the requirement for unique

40
user identifiers and the need for users to respect them. The second defines

the strength of authentication which must be applied to users who attempt to

log on to the system. Typically there will be two levels of authentication:

 Normal users logging in from terminals and workstations within

ABC's premises. The policy will state the standards for passwords,

like the minimum length and required format, and the frequency of

change.

 Users, whether company staff or external, who log in from outside

ABC's premises. There will be a much higher level of authentication,

probably using smart cards or other one-time password generators.

6. Data access control

The policy for data access control contains the following elements:

Ownership of all elements of the organization’s data should be defined, with

the owner being responsible for decisions about the use of the data.

All the data should be protected, and access should only be permitted when

authorized By its owner, All systems should have access control systems

which protect data to a defined Standard. Typically the “Orange Book” C2

41
level of protection (see section VI.A) is suitable for a commercial

organization.

7. Disaster planning

Most organizations are now critically dependent upon the working of many

of their communications and computer systems. If any one of them fails, the

business will have difficulty in functioning at all. Their needs therefore to be

a disaster planning policy which requires each system to be considered for

its criticality and defines how any critical system is to be recovered. It

should define what is the maximum recovery time, and how all of data,

communication and processors are to be backed up to enable rapid recovery

in the event of any conceivable disaster. For distributed systems, the

problems of back-up are eased by the existence of compatible systems at

several sites.

8. System audit ability

There are several reasons for having a policy requiring the audit ability of all

systems that is the ability to trace any significant action which has taken

place in the system. It gives a greater ability to control systems, it is usually


42
a requirement of the auditors and it enables the company to demonstrate that

it is complying with legal requirements. It is normally impractical to log all

actions all of the time, so there should be a policy dividing systems and

applications into three categories: events, such as security administrators'

actions and financial transactions, which should be logged all the time,

events which can be logged whenever necessary, and events which are so

trivial that they never need logging.

9. Legal and regulatory policies relating to security

A policy is needed which makes it clear to all staff that all legal and

regulatory requirements are to be complied with, for example data protection

legislation.

10. Use of External Organizations

There are many applications in which external organizations are used for

processing an organization’s data, for example EFT and EDI. The policy

should require that an appropriate level of security should exist on the

systems of any external organization which processes this organization’s

data.
43
11. Concluding Comment on the Security Policies

The security policies outlined above are a minimum set for a typical

commercial organization. Most of them “state the obvious”, but it is notable

how often obvious security needs are ignored.

44
CHAPTER 6

SECURITY STANDARDS IN DISTRIBUTED SYSTEM

There are three main categories of security standards which concern

distributed systems. The first are standards related to the security of

individual computers, which have been in existence for some time, and are

quite mature. The second are standards for the protection of communication

transmission and remote authentication. These too are quite mature. The

third, still under development, are those which integrate computer and

communication security standards to provide distributed systems security

standards.

The standards do not generally prescribe physical or procedural

mechanisms, nor do they prescribe risk management or risk assessment

procedures or requirements for their use. These are all necessary elements to

be considered and resolved for the resources that comprise the whole

distributed system. Therefore, although security standards are an important

support to distributed system security policies, they have to be viewed in the

context of an overall security policy which uses other measures as well.


45
A. COMPUTER SECURITY STANDARDS

The USA Department of Defense Trusted Computer System Evaluation

Criteria (TCSEC-the Orange Book) (Department of Defense (USA), 1985),

deals with access control to individual systems. It defines a number of

possible levels of trust which may be placed in a system, ranging from the

certified high security of the A1 level down to a low level of informally

defined security at the C1 level. It is commonly used as a means of

indicating the level of security required or supplied in computer systems.

Access control is divided by this standard into two categories: mandatory

and discretionary access control. The former enforces policies which are

built into the design of the system and cannot be altered except by installing

a new version of the system. An example is the policy that in multi-layer

security systems data cannot be read by a user with a lower security

classification than has been assigned to the data. Discretionary access

control mechanisms are defined as those which allow users to specify and

control sharing of resources with other users. For example the C2 level

discretionary access control policy is defined as requiring mechanisms

46
which ensure that information and resources are protected from unauthorized

access and that access permission is only assigned by authorized users.

The Trusted Network Interpretation of the Trusted Computer System

Evaluation Criteria (Department of Defense (USA), 1987) (The Red Book)

extends the criteria of the Red Book to networks. It is chiefly concerned with

the security criteria to be met when accessing remote hosts.

The Red Book is now quite old and it has always been more oriented to

military type security than to commercial security. A standards effort which

is now under way is the Information Technology Security Evaluation

Criteria (ITSEC) (CEC, 1991). This is a joint undertaking by the UK, Dutch,

French and German governments. Its aim is to take into account the needs of

commercial users and improve on the Red Book by separating concerns

about security levels from the way in which the security is evaluated. In the

UK, the Department of Trade and Industry and the Communications-

Electronics Security Group have established the UK IT Security Evaluation

and Certification Scheme (CESG, 1991) which evaluates and certifies

47
products using the criteria of ITSEC. Similar efforts are under way in other

countries.

B. COMMUNICATION SECURITY STANDARDS AND

ENCRYPTION

1. Transmission Security

Transmission security standards are mainly concerned with encryption

methods. One Algorithm in particular has been the subject of standards

efforts: the DES algorithm for secret key encryption which is an American,

but not an international, standard. On the other hand, the RSA algorithm for

public key encryption is the subject of USA patents. It has become a de facto

standard for public key cryptography but because of its patented status is not

currently defined as a national or international standard.

Encryption depends for its strength upon the security of the hardware which

is used, and (BSI, 86/67937) describes standards for the Physical Security of

Cryptographic Equipment

48
The basic standard for DES is (NBS, 46), supplemented by (ANSI, X3.92).

There are supplementary standards describing its Modes of Operation (NBS,

81) and Guidelines for Installation and Use (NBS, 74), the management of

keys in banking applications is

Described in (ANSI, X9.17), but this standard is rather generally expressed

and would apply to other applications also. A detailed discussion of DES

standards is in (Davies & Price, 1989).

2. Authentication Standards

A number of standards have been developed for banking applications for

peer-to-peer communication and message authentication. They too are quite

general in format and could be used for other purposes. They include (ANSI,

X9.19) for Message Authentication and (ANSI, X3.118) for personal

authentication using a Personal Identification Number (PIN).

C. OSI SECURITY STANDARDS

Network security was not a primary concern when the Open Systems

Interconnection (OSI) effort first got under way in the late 1970s. However

there is now a series of ISO standards under development which aim to add
49
security to OSI. The standards define the security services which the

partners in a communication could agree upon, and the protocols to be used

in setting up a secure interaction.

The security services which may be required for the communication

facilities have been defined in the ISO 7498-2 Security Architecture (ISO,

7498-2). The protocols for their provision are still largely under

development and are not yet available in OSI products.

The security services described in the Security Architecture are described in

more detail in a of Security Frameworks which are currently in production.

They will eventually appear as International Standards 10181-1 to 10181-8.

The planned framework parts are:

 Overview - a general introduction (ISO, 10181-1),

 Authentications,

 Access Control,

 Non-repudiation,

 Integrity,

50
 Data Confidentiality,

 Audit frameworks,

 Key management.

Chapter 7

CONCLUSION

Security issues in distributed systems are classical problems, which have

partly been solved using techniques such as cryptographic systems, access

control and auditing mechanisms. There has also been an approach to

monitor the communication channels to obtain secure communication. On

the other hand, adaptation has seen a wide acceptance among researchers

since it has the purpose of presenting a good quality of service to the users of

distributed systems. Adaptation requires the monitoring of data under

communication.

51
Chapter 8

REFERENCES

1. Lin, C., Varadharajan , “Trust based risk management

for distributed system security - a new approach ”, IEEE Trans.

Comput., vol. 25, pp. 2273 - 2275, April 2006

2. Nessett, D.M.,  “Factors Affecting Distributed System Security “,

IEEE Trans. Comput., vol. SE- 13, pp. 2290-2235, Feb 2005

3. Hamdi, H, “A Software Architecture for Automatic Security Policy

Enforcement in Distributed Systems,” IEEE Trans. Comput., vol. C-

29, no. 12, pp. 187-192, Oct. 2007

52
4. Nessett, D, “A Systematic Methodology for Analyzing Security

Threats to Inter process Communication in a Distributed System ,”

vol. 31, pp.  1055 - 1063 , Sep 1983

5. Garcia, M, “Applying dynamic separation of aspects to

distributed systems security” , vol. 6, pp.  231- 248 , June 2012

6. Benson, G., Appelbe, W., Akyildiz, “The hierarchical model

of distributed system security”, IEEE Sch. of Inf. & Comput. Sci.,

Georgia Inst. of Technol., Atlanta, GA, vol 24, pp. 194 – 203, May

2009

7. Atmaja, T.D, “Cyber security strategy for future distributed energy

delivery system”, vol 10, pp  1 - 6, July 2011

8. Naqvi, S Riguidel, “Security architecture for

heterogeneous distributed computing systems”, Dept. of Comput. Sci.

& Networks, Graduate Sch. Of Telecommunication, Paris, France,

vol. no 48, pp. 34-41, Oct. 2004

9. Yue Ma, “ARCSM: A Distributed Feedback Control Mechanism

for Security-critical Real-time System”, IEEE Trans. Sch. of

Comput. Sci.& Eng., Univ. of Electron. Sci. & Technol. of China,

Chengdu, China, vol 44, pp. 379 – 386,  July 2012


53
10.ANSI X3.118 (1984). Personal Identification Number - PIN Pad.

American National Standards Institution.

11.ANSI X3.92 (1981). Data Encryption Algorithm. American National

Standards Institution.

12.ANSI X9.17 (1985). Financial Institution Key Management,

(Wholesale). American National Standards Institution.

13.ANSI X9.19 (1986). Financial Institution Retail Message

Authentication. American National Standards Institution.

14.ANSI X9.9 (1986). Financial Institution Message Authentication,

(Wholesale). American National Standards Institution.

15.BSI 86/67937 (10 Dec 1986). Physical Security of Cryptographic

Equipment. British Standards Institution.

16.CEC (1991). Information Technology Security Evaluation Criteria

(ITSEC): Provisional Harmonised Criteria, Version 1.2 (Report No.

Office for Official Publications of the European Communities,

Luxembourg.

17.CESG (1991). UK IT Security Evaluation and Certification Scheme.

Description of the Scheme (Report No. UKSP 01, Issue 1.0).


54
Communications-Electronics Security Group, Room 2/0804, Fiddlers

Green Lane, Cheltenham GL52 5AJ, UK.

18.Davies, D. W., & Price, W. L. (1989). Security for Computer

Networks. John Wiley.

19.Denning, P. J. (Ed.). (1990). Computers Under Attack: Intruders,

Worms and Viruses. Addison-Wesley.

20.Department of Defense (USA) (1985). Department of Defense

Trusted Computer System Evaluation Criteria (Report No. DOD

5200.78 - STD).

21.Department of Defense (USA) (1987). Trusted Network

Interpretation of the Trusted Computer System Evaluation Criteria

(Report No. NCSC-TG-005 version 1). Technical Guidelines

Division, National Computer Security Center (USA).

22.Gilbert, I. E. (1989). Guide for Selecting Automated Risk Analysis

Tools (NIST Special Publication 500-174

55

You might also like