Access Control Systems And Methodology

snottysurfsideServers

Dec 9, 2013 (3 years and 7 months ago)

405 views







Access Control Systems

And

Methodology

Version 2.0



Certified Information Systems Security Professional

Open Study Guide






October 2002

All rights reserved
-

CISSP OSG and its contributors

The Domain Leader for this domain is: David Goodwin (domain1@isoga.net)
)

CISPP Study Guide



Domain 1


Access Control and Methodology



-

2

-


Contributors

Arun S


Bill Royds


Charles Cagliostro


ChuckB


Cl
ément Dupuis

cdupuis@cccure.org

Dave Goodwin

Domain1@isoga.net

Idrach


Jonathan Horner


Oberon


Proscribes


Rino


Ron Gula


Skully



Created on
10/11/2002 5:01 PM

Filename:
Domain1_12Oct.doc

CISPP Study Guide



Domain 1


Access Control and Methodology



-

3

-

TABLE OF CONTENTS

1

INTRODUCTION

________________________________
__________________

7

1.1

Look and Feel

________________________________
_

Error! Bookmark not defined.

1.2

Give and Take

________________________________
_______________________

7

2

DISTRIBUTION AGREEMENT

________________________________
______

8

3

DOMAIN DESCRIPTION

________________________________
___________

9

4

EXPECTED KNOWLEDGE AREAS

________________________________
__

10

5

THE MEAT

________________________________
______________________

13

5.1

Describe the principle of accountability

________________________________
_

13

5.2

Access Control Techniques

________________________________
____________

13

5.2.1

Access Control Categories

________________________________
_________________

14

5.2.2

Types of Controls

________________________________
________________________

14

5.3

Access Control Policies

________________________________
_______________

15

5.3.1

Discretionary Access Control (DAC)

________________________________
_________

16

5.3.2

Mandatory Access Control (MAC)

________________________________
___________

17

5.3.3

Lattice Based Access Control

________________________________
_______________

18

5.3.4

Rule
-
Based Access Control

________________________________
________________

20

5.3.5

Role
-
Based Access Control

________________________________
________________

23

5.3.6

Access Control Lists

________________________________
______________________

23

5.3.7

Other Access Control Methods

________________________________
______________

24

5.3.7.1

Low Water
-
Mark Mandatory Access Control

______________________________

24

5.3.7.2

FLASK

________________________________
___________________________

24

5.4

Access Control Administration

________________________________
________

25

5.4.1

Account Administration

________________________________
___________________

25

5.4.2

Account, Log, and Journal Monitoring

________________________________
________

26

5.4.2.1

Requirements

________________________________
_______________________

26

5.4.2.2

What should be logged?

________________________________
______________

27

5.4.3

Access Rights

and Permissions

________________________________
______________

30

5.4.3.1

Establishment (authorization)

________________________________
__________

30

5.4.3.2

Maintenance

________________________________
_______________________

32

5.4.3.3

Revocation
________________________________
_________________________

32

5.5

Access Control Models

________________________________
_______________

32

5.5.1

Bell
-
LaPadula

________________________________
___________________________

32

5.5.2

Biba

________________________________
________________________________
___

33

5.5.3

Clark and Wilson

________________________________
________________________

34

5.5.4

Non
-
Interference Model

________________________________
___________________

36

5.5.5

State Machine Model

________________________________
_____________________

36

5.5.6

Access Matrix Model

________________________________
_____________________

37

5.5.7

Information Flow Model

________________________________
___________________

38

5.5.8

Chinese Wall Model

________________________________
______________________

39

5.6

Identification and Authentication Techniques

____________________________

39

5.6.1

Knowledge
-
based P
asswords, Personal Identification Numbers (PINs), Pass
-
phrases

___

40

5.6.1
.1

Password Selection

________________________________
__________________

40

5.6.1.2

Password Management

________________________________
_______________

41

5.6.1.3

Password Control

________________________________
___________________

44

5.6.2

Characteristi
c
-
Based (Biometrics, Behaviour)

________________________________
__

44

5.6.2.1

Biometrics Performance

________________________________
______________

44

CISPP Study Guide



Domain 1


Access Control and Methodology



-

4

-

5.6.2.2

Fingerprints

________________________________
________________________

45

5.6.2.3

Retina Scan (blood vessels) and Iris Scan (color of eyes)

_____________________

47

5.6.2.4

H
and Geometry

________________________________
_____________________

48

5.6.2.5

Keyboard Dynamics

________________________________
_________________

50

5.6.2.6

Dynamic signatures

________________________________
__________________

50

5.6.2.7

Voice Print

________________________________
________________________

52

5.6.2.8

Facial Scan

________________________________
________________________

54

5.6.2.9

Vulnerabilities of Biometrics Systems

________________________________
___

56

5.6.2.10

The Zephyr Chart

________________________________
___________________

59

5.6.3

Tokens

________________________________
________________________________

62

5.6.3.1

Token Benefits and Limitations

________________________________
________

63

5.6.3.2

Memory Card, Smart Card, Key Card

________________________________
____

63

5.6.3.3

Smart Card or Memory card with some fixed logic (i.e. for encryption)

_________

63

5.6.3.4

Smartcard Attacks

________________________________
___________________

67

5.6.4

Tickets

________________________________
________________________________

68

5.6.5

One
-
time Passwords

________________________________
______________________

69

5.6.5.1

Token
-
based

________________________________
_______________________

69

5.6.5.2

Administration

________________________________
______________________

69

5.6.6

Single Sign
-
On (SSO)

________________________________
_____________________

69


Access Control Methodologies and Implementation

___

Error! Bookmark not defined.

5.7

________________________________
________________________________
_______

70

5.7.1

Centralized
/ Remote Authentication Access Controls

____________________________

70

5.7.1.1

RADIUS (Remote Authentication Dial
-
In User Service)

_____________________

70

5.7.1.2

TACACS
(Terminal Access Controller Access Control System)

_______________

71

5.7.2

Decentralized Access Control

________________________________
_______________

72

5.7.2.1

Domains

________________________________
__________________________

72

5.7.2.2

Trust

________________________________
_____________________________

72

5.8

File and Data Ownership and Custodianship

_____________________________

73

5.9

Methods of attack

________________________________
___________________

74

5.9.1

Phase 1
-

Information Gathering

________________________________
_____________

74

5.9.2

Phase 2


Gaining Access

________________________________
__________________

74

5.9.3

Phase 3


Denying Services

________________________________
________________

75

5.9.4

Phase 4


Evade Detection

________________________________
_________________

75

5.9.5

Phase 5


Back Door and Covering Tr
acks

________________________________
____

76

5.9.6

Brute force

________________________________
_____________________________

76

5.9.7

Denial of Service

________________________________
________________________

76

5.9.8

Dictionary

________________________________
______________________________

77

5.9.9

Spoofing

________________________________
_______________________________

77

5.9.10

Man
-
in
-
the
-
Middle

________________________________
_____________________

78

5.9.11

Spamming

________________________________
___________________________

78

5.9.12

Sniffers

________________________________
______________________________

78

5.9.13

Crackers

________________________________
_____________________________

78

5.10

Monitoring

________________________________
_________________________

78

5.10.1

Overview

________________________________
____________________________

79

5.10.1.1

What is intrusion detection?

________________________________
___________

79

5.10.1.2

Why should I use Intrusion Detection Systems?

____________________________

79

5.10.2

The threats and why use an IDS

________________________________
___________

81

5.10.3

Process model for Intrusion Detection

________________________________
______

81

5.10.4

Architecture

________________________________
__________________________

82

5.10.5

Goals

________________________________
_______________________________

82

5.10.6

Classification

________________________________
_________________________

82

5.10.6.1

Network
-
Based IDS

________________________________
_________________

82

5.10.6.2

Host
-
Based IDS

________________________________
_____________________

83

CISPP Study Guide



Domain 1


Access Control and Methodology



-

5

-

5.10.6.3

Application
-
Based IDS

________________________________
_______________

84

5.10.7

IDS Analysis

________________________________
_________________________

85

5.10.7.1

Misuse Detection

________________________________
____________________

85

5.10.7.2

Anomaly Detection

________________________________
__________________

86

5.10.8

Response Options for IDS

________________________________
_______________

87

5.10.8.1

Active Responses

________________________________
___________________

87

5.10.8.2

Change

the Environment

________________________________
______________

88

5.10.8.3

Take Action Against the Intruder

________________________________
_______

88

5.10.8.4

Passive Responses

________________________________
___________________

88

5.10.8.5

Alarms and Notifications
________________________________
______________

88

5.10.9

Tools that Complement IDS
________________________________
______________

89

5.10.9.1

Vulnerability Analysis or Assessment Systems

____________________________

90

5.10.9.2

Vulnerability Analysis System Process

________________________________
___

90

5.10.9.3

Vulnerability Analysis Types

________________________________
__________

90

5.10.9.4

Host
-
based Vulnerability Analysis

________________________________
______

91

5.10.9.5

Network
-
Based Vulnerability Analysis

________________________________
___

91

5.10.9.6

Advantages and Disadvantages of Vulnerability Analysis

____________________

91

5.10.9.7

Disadvantages and Issues

________________________________
_____________

92

5.10.10

File Integrity Checkers

________________________________
__________________

92

5.10.11

Honey Pot and Padded Cell Systems

________________________________
_______

93

5.10.11.1

Advantages

________________________________
______________________

93

5.10.11.2

Disadvantages

________________________________
____________________

93

5.10.12

Advice on selecting IDS products

________________________________
_________

94

5.10.13

Computer Attacks and Vulnerabilities

________________________________
______

94

5.10.14

Attack Types

________________________________
_________________________

94

5.10.14.1

Types of Computer Attacks Commonly Detected by IDS

__________________

95

5.10.15

The Future of IDS

________________________________
____________________

100

5.10.16

Conclusion

________________________________
__________________________

101

5.10.17

Tough Questions for Vendors

________________________________
___________

101

5.11

Penetration testing

________________________________
__________________

102

5.11.1

Why test?

________________________________
___________________________

103

5.11.2

Common Tools

________________________________
_______________________

103

5.11.3

White, Grey and Black Hat Testing

________________________________
_______

103

5.11.4

How much should a test cost?

________________________________
___________

104

5.11.5

Doing it yourself

________________________________
_____________________

104

5.11.6

Us versus Them

________________________________
______________________

104

5.11.7

The Slippery Slope

________________________________
____________________

104

5.11.8

Zero
-
Day Exploits

________________________________
____________________

105

5.11.9

Fratricide

________________________________
___________________________

105

5.11.10

Common Omissions

________________________________
___________________

105

5.11.10.1

DNS Spoofing

________________________________
__________________

105

5.11.10.2

Third Party Trust

________________________________
________________

107

5.11.10.3

Custom Trojan Horses

________________________________
____________

109

5.11.10.4

Database

________________________________
_______________________

110

5.11.10.5

Routing Infrastructure

________________________________
____________

111

5.11.10.6

Testing the IDS

________________________________
__________________

112

5.11.10.7

WWW Server Side Includes

________________________________
________

113

5.11.10.8

TCP Hijacking

________________________________
__________________

113

5.11.10.9

Testing the Firewall

________________________________
______________

114

5.11.10.10

ISDN Phone Lines

________________________________
_______________

115

5.11.10.11

Network Brute Force Testing

________________________________
_______

115

5.11.10.12

Testing non
-
IP networks

________________________________
___________

116

5.11.10.13

Ethernet Switch Spoofing

________________________________
__________

116

5
.11.10.14

Exploiting Chat Tools

________________________________
_____________

117

5.11.10.15

Final Thoughts

________________________________
__________________

118

CISPP Study Guide



Domain 1


Access Control and Methodology



-

6

-

6

GLOSSARY

________________________________
_____________________

119

7

REFERENCES

________________________________
__________________

120


CISPP Study Guide



Domain 1


Access Control and Methodology



-

7

-

1

INTRODUCTION

First I would like to

congratulate you on choosing the Open Study Guides as your sources of
information to help you quickly master the content of the 10 domains of expertise.



The study booklets are based directly on the ISC
2

CBK document. This document does not take
precedence over the information that is provided by ISC2. We will attempt to keep this
document in synch with the CBK, however ISC2 will always be your main point of reference for
the latest info on the requir
ements needed before attempting certification as a CISSP. You can
visit the ISC2 web site at the following address:
h
ttp://www.isc2.org



This document was produced by a consensus of security experts and students from the CISSP
Open Study Guide (OSG) web site. If you like this document, we invite you to contribute by
visiting the CISSP OSG at
http://www.cccure.org

1.1

Give and Take

I cannot stress th
is point enough. If you liked this guide and it’s content, and if it helped you
saved valuable time by allowing you to focus on the important material that must be covered for
the exam, please do take a bit of your time to give something back to other mem
bers of the site;
you do not need to be the world greatest security expert. Any contribution (web links, typo
correction, sample questions, etc…) is important and will help to improve these guides and the
site as a whole.

WARNING:

This guide does not repl
ace in any way the outstanding value of the ISC2 CISSP CBK Seminar,
nor the fact that you must have been directly involved in the security field or one of the 10
domains of expertise for at least 3 years if you intend to take the CISSP exam. This booklet
simply intends to make your life easier and to provide you with a centralized and compiled list of
resources for this particular domain of expertise. Instead of a list of headings, we will attempt to
give you the headings along with the information to sup
plement the headings.

SECOND WARNING:

As with any security related topic, this is a living document that will and must evolve as other
people read it and technology evolves. Please feel free to send comments and input to be added
to this document. Any com
ments, typo correction, etc… are most welcome and can be sent
directly to the domain leader listed on the first page of this document, or you can visit
http://www.cccure.org

and submit your feedback directly on the web site.

This is NOT a document sponsored by the authors, contributors, or the organizations that these
people belong to, nor is it to be interprete
d as a representation of the “Domain Leader” company
operating practices.

CISPP Study Guide



Domain 1


Access Control and Methodology



-

8

-

2

DISTRIBUTION AGREEMENT

This document is based on standards, online information, professional experience, b
ooks, and a
consensus of experts that took part in the development of this guide. Whenever possible the
source of information will be mentioned.

This document may be freely read, stored, reproduced, disseminated, translated or quoted by any
means and on a
ny medium provided the following conditions are met:



Every reader or user of this document acknowledges that he is aware that no guarantee is
given regarding its contents, specifically concerning veracity, accuracy and fitness for
any purpose. Do not bla
me me if some of the exam questions are not covered or the
correct answer is different from the content of this document.



No modification is made other than cosmetic, change of representation format,
translation, correction of obvious syntactic errors.



Comments and other additions may be inserted, provided they clearly appear as such.
Comments and additions must be dated and their author(s) identifiable. Please forward
your comments for insertion into the original document to the domain leader listed on

page 1 or submit them directly on the CISSP OSG web site at
http://www.cccure.org




Redistributing this document to a third party requires simultaneous redistribution of this
license, without modification, and in particular without any further condition or
restriction, expressed or implied, related or not to this redistribution. In parti
cular, in the
case of inclusion in a database or collection, the owner or the manager of the database or
the collection renounces any rights related to its inclusion and concerning the possible
uses of the document after extraction from the database or the

collection, whether alone
or in relation with other documents.

TIP:

Remember while taking your exam, you must look for the most correct answer and people
always come first.








CISPP Study Guide



Domain 1


Access Control and Methodology



-

9

-

3

DOMAIN DESCRIPTION

Access control is the collection of mechanisms that permits managers of a system to exercise a
directing or restraining influence over the behavior, use, and content of a system. It perm
its
management to specify what users can do, which resources they can access, and what operations
they can perform on a system.

The CISSP students should fully understand access control concepts, methodologies, and
implementation within centralized and de
centralized environments across the entire Enterprise.
Access control techniques, detection and corrective measures should be studied to understand the
potential risks, vulnerabilities, and exposures.

CISPP Study Guide



Domain 1


Access Control and Methodology



-

10

-

4

EXPECTED KNOWLED
GE AREAS



Accountability



Access Control Techniques

o

Discretionary Access Control

o

Mandatory Access Control

o

Lattice Based Access Control

o

Rule
-
Based Access Control

o

Role
-
Based Access Control

o

Access Control Lis
ts



Access Control Administration

o

Account Administration

o

Account, Log, and Journal Monitoring

o

Access Rights and Permissions



Establishment (authorization)



File and Data Owners, Custodians, and Users



Principle of least Privilege



Segregation of

Duties and Responsibilities



Maintenance



Revocation



Access Control Models

o

Bell
-
LaPadula

o

Biba

o

Clark and Wilson

o

Non
-
Interference Model

o

State Machine Model

o

Access Matrix Model

o

Information Flow Model



Identification and Authentication Techniques

o

Knowledge
-
based passwords, Personal Identification Numbers (PINs), phrases



Passwords



Selection



Management

CISPP Study Guide



Domain 1


Access Control and Methodology



-

11

-



Control

o

Characteristic
-
based (biometrics, behaviour)

o

Tokens

o

Tickets

o

One
-
time Passwords



Token
-
based (smart card, key card)



Administrative

o

Single Sign
-
On (SSO)



Access Control Methodologies and Implementation

o

Centralized
/Remote Authentication Access Controls



RADIUS



TACACS

o

Decentralized Access Control



Domains



Trust



File and

Data Ownership and Custodianship



Method of attacks

o

Brute force

o

Denial of Service

o

Dictionary

o

Spoofing

o

Man
-
in
-
the
-
middle attacks

o

Spamming

o

Sniffers

o

Crackers



Monitoring

o

Intrusion Detection



Type of intrusions



Intrusion prevention (Identification, authentication)



Intrusion Detection (data extraction, sampling, recognition, traffic)



Attack signature identification



Intrusion reactive response

CISPP Study Guide



Domain 1


Access Control and Methodology



-

12

-



Anomaly identification



Intrusion Response



Alarms



Signals



Audit Trails



Violation Reports



Corrections



Penetration testing

CISPP Study Guide



Domain 1


Access Control and Methodology



-

13

-

5

THE MEAT

Under this section you will find answers to most of the areas that you are required to know as a
security professional. This guide only touches the surface and at times will point you to
references to further enhance or develop your knowledge.

5.1

Describe the principle of accountability

The principle of accountability has been described in many references; it is a principle b
y which
specific action can be traced back to an individual. Any significant action should be traceable to
a specific user. The definition of “Significant” is entirely dependant on your business
circumstances and risk management model.

The Merged Glos
sary
i

has many definitions:



Means of linking individuals to their interactions with an IT product, thereby supporting
identification of and recovery from unexpected or unavoidable failure
s of the control
objectives
ii
.



The property that responsibility for events can be determined
iii
.



The quality o
r state that enables actions on an ADP system to be traced to individuals
who may then be held responsible. These actions include violations and attempted
violations of the security policy, as well as allowed actions
iv
.



The property that enables activities on a system to be traced to individuals who may then
be held responsible for their actions
v
.

The Canadian Medical association defines accountability as follows:



Having clearly defined and understood responsibilities in connection w
ith health
information, agreeing to accept those responsibilities and being subject to appropriate
sanctions for failing to fulfill the accepted responsibilities.

5.2

Access Control

Techniques

Access is the ability to do something with a computer resource (e.g., use, change, or view).
Access control is the means by which the ability is explicitly enabled or restricted in some way
(Usually through physical and system
-
based controls).

Computer
-
based access controls can
prescribe not only who or what process may have access to a specific system resource, but also
the type of access that is permitted. These controls may be implemented in the computer system
or in external devices.

Acces
s control primarily concerns the
Confidentiality

and to some extent
Integrity

axes of the
CIA information security areas.

Access


“The ability and opportunity to obtain knowledge of classified information”



DOD.5220.22M

Control


“The Manual or Informat
ion systems based steps, taken to mitigate the (security) risks
to the information assets” Source
-

Unknown


CISPP Study Guide



Domain 1


Access Control and Methodology



-

14

-


(A)
Subj
ect


Proc
ess acting on behalf of a User. eg/ Applications / DBs / Shells.

(B) Access Mode


The type of access requested. eg/ Open, Read, Execute Update.

(C) Reference Monitor


Mechanism that determines if access is allowed depending on rules.

(D) Reference M
onitor grants or denies access request.

(E) Object

Also known as a resource. eg/ File / Printer / Nodes on network.

5.2.1

Access Control Categories

Access control ca
n be divided into categories depending on at what level the control is enforced.
Some key categories are:



Physical Access Control :

Physical access control embraces any sort of real
-
world obstacle that prevents
people from accessing the protected resour
ces



Administrative Access Control :

Administrative access control covers policies and steps enforced by the
organization that is responsible for the resource



Logical Access Control

Logical access control covers the whole range of protections enforced by the
system itself. eg/ The OS. It not only governs who can access resources on the system but
also allows for a fine granularity in the access modes of users who have legitimate
acces
s.
vi



Data Access Control

Data access control is limit
ed to the protection of data residing in databases,
where granular access is outside of the control of the OS. The DB itself must control who
and the types of access permissible.

Access control is a bit like the four legs of a chair. Each of the legs must

be equal or else an
imbalance will be created. If you have very strict Physical Access controls but very poor Logical
Access Controls then you may not succeed in securing your environment.

5.2.2

Types of Controls

Each access control category may be categorized by the type of control that is enforced. Access
controls can provide various types of defense against would be intruders. Types of access control
can be categorized as follow
s:



Preventive :

Subject

Reference Monitor

Object

B

D

A

C

E

CISPP Study Guide



Domain 1


Access Control and Methodology



-

15

-

Systems that make it impossible to access resources that the user doesn’t have a
right to access such as a locked door or access bits on a file



Detective :

Systems that generate alerts when unauthorized access has occurred but don’t
the
mselves stop the access from occurring. eg/ Burglar alarm



Deterrent :

A control that doesn’t restrict access but makes it clear that permission to access the resource is
denied. eg/ A low fence or logon banner warning.

The following table shows examples
of many of the different types and categories of access
control.


Physical

Administrative

Logical

Data

Preventive

Walls, Lock and
key, Security
guards / dogs

Security training,
Separation of duties,
Hiring / firing
procedures, User
registration for
computer access
procedures,
Supervision

File permission bits,
Access control lists,
user passwords,
Callback systems,
Antivirus software,
smartcards, Firewalls

User
logon /
Password,
Access control
lists

Detective

Closed circuit
television,
Motion
detectors,
Burglar alarms,

Security reviews and
audits, Performance
evaluation,
Background
Investigation

Intrusion detection
sys
tems, Audit trails /
logging, system
monitoring, Honeypots

Audit trails

Deterrent

ID badges

Reprimands

Logon banner, Audit
trails

Audit trails


The Handbook of Information System Management
vii

has a very good chart that summarizes the
Physical, Technical, Administrative controls and their sub
-
categories.

5.3

Access Control Policies

Different types of access control are generally classified based on whether they are primarily
discretionary controls, or primarily mandatory controls. Discretionary controls are access
controls in which th
e data owners decide who may have access to the data. Ie/ They are expected
to use their discretion in deciding. For example, data may be accessible to one person, but not
another; the first person is expected not to copy the data and allow the second pers
on to access it.
Since a program generally runs with all the privileges of the person who invoked it, this
generally allows a rogue program to take action the person themselves would not do.

Mandatory controls are access controls that are based on a polic
y that the user, and more
importantly the processes running with that user's privileges, is not allowed to violate. An
CISPP Study Guide



Domain 1


Access Control and Methodology



-

16

-

example of this is "Top Secret" data is configured so that regardless of what the user does, the
data cannot be transmitted to someone wh
o does not have "Top Secret" status. Thus no "Trojan
horse" program could ever do what the user is not allowed to do anyway. The restrictions of
mandatory controls are (at least in normal mode) also applied to the user who in a discretionary
system would b
e "root", or the super
-
user.

In an access control system which implements both styles at the same time, the checks are
usually done sequentially. In any access check (e.g. A subject, which could be a process, wants
to access an object, which could be a fi
le) the discretionary controls are often checked first, and
if those succeed then the mandatory controls are checked. Only if both are successful is access
permitted. The mandatory access control cannot be bypassed, but in situations where MAC is not
enfor
ced, all subjects and objects can be assigned to the same category, meaning the mandatory
checks will always succeed.

5.3.1

Discretionary Access Control (DAC)

DACs place the burden of setting access to a reso
urce on the resource owner. In other words, the
owner of a file can decide who is allowed to read or modify it. Access control is thus handled in
a decentralized manner with no central control and no central policy can be enforced.

DAC is defined as follo
ws in the Handbook of Information Security Management:

Access controls that are not based on policy are characterized as discretionary controls by
the U.S. government and as need
-
to
-
know controls by other organizations. The latter term
connotes least privi
lege


those who may read an item of data are precisely those whose
tasks entail the need.

Discretionary access controls can extend beyond limiting which subjects can gain what type of
access to which objects. Resource owners can limit access to certain ti
mes of day or days of the
week. Typically, the period during which access would be permitted is 9 a.m. to 5 p.m. Monday
through Friday. Such a limitation is designed to ensure that access takes place only when
supervisory personnel are present, to discoura
ge unauthorized use of data. Further, subjects’
rights to access might be suspended when they are on vacation or leave of absence.

Under this type of control, the owner of a resource determines who has access and what privilege
they have. It maybe defined

in more formal language as:

a.

There is an owner

b.

There is an object

c.

There are other users

DAC is “The owner (a) decides who among users (c) has what level of access on the object
(b)”.

Advantages:



Flexibility and control at the object / resource level.



Can be combined with a MAC to enforce a global security policy. Access to a resource is
only granted when allowed by both the MAC and DAC policies.

Disadvantage:

CISPP Study Guide



Domain 1


Access Control and Methodology



-

17

-



Large administrative overhead


E
ach resource has to have permissions set individually.



Have to rely on all your users to ensure no valuable data can be leaked.



Can’t set a central policy.



Trojan horses can leak sensitive data by copying it to a new file and granting global read
p
ermissions.

5.3.2

Mandatory Access Control (MAC)

Mandatory Access Control describes an imposed access control policy across an organizational
unit. Here the policy and hence who has access to wha
t is controlled at a global level and not by
the owners of individual resources.

From the Handbook of Information Security Management:

With mandatory controls, only administrators and not owners of resources may make
decisions that bear on or derive from
policy. Only an administrator may change the
category of a resource, and no one may grant a right of access that is explicitly forbidden
in the access control policy.

It is important to note that mandatory controls are prohibitive i.e., all that is not exp
ressly
permitted is forbidden. This is in contrast to a permissive control system where everything is
allowed unless explicitly denied.

MACs are typically found in the military where strict control over the flow of information is
preferred to convenience

and individuals’ decisions.

In this model, decisions are based on whether the privilege (clearance) of a subject (user) meets
the requirements of the sensitivity (classification) of an object (file). It requires labeling.

a.


Every object is associated w
ith a classification level:

Object : Classification

b.

Every subject will have a classification associated with him or her indicating their highest
permissible clearance:

Subject : Clearance

c.

There is an ordering of the classification levels, also known
as compartments. Typically
the following are used:

Level

Clearance

Highest

Top Secret

Higher

Secret

Moderate

Confidential

Low

Sensitive

Lowest

Unclassified


CISPP Study Guide



Domain 1


Access Control and Methodology



-

18

-

The individual is granted access to an object, if the subject has an equal or higher
classification level than the object’s clearance level. The subject’s clearance is said to
dominate that of the object’s.

eg/ If I have Secret clearance then I can view ob
jects that are classified from SECRET,
CONFIDENTIAL, SENSITIVE and UNCLASIFIED. I cannot access TOP SECRET.

MAC systems may additionally add categories to their classification, with a user having a
different clearance for each category. In this case an obj
ect’s classification is a classification
level within a category.

eg/ I may have TOP SECRET clearance within the ‘Homeland Security’ category but only
SENSITIVE clearance in the ‘Foreign Intelligence’ category. In this case I cannot access an
object that

is classified ‘Foreign Intelligence: TOP SECRET’.

Advantages: Very strict enforcement of security, centrally administered

Disadvantages: No granularity on type of access to object. It’s either all or nothing.

5.3.3

Lat
tice Based Access Control

The Lattice Based Access Co
ntrol model was developed to deal mainly with information flow in
computer systems. Information flow is clearly central to confidentiality but to some extent it
also applies to integrity. The basic work in this area was done around 1970 and was driven
m
ostly by the defence sector. Information flow in computer systems is concerned with flow
from one security class (also called security label) to another. These controls are applied to
objects. An object is a container of information such as a director
y or file.

A lattice is a mathematical object that characterizes some kind of relationships between things
and may be described formally thus:

Mathematically it is defined as a set and a relationship( <= ) between members of the set with the
properti
es

For A, B, C elements of the set:

A <= A

A<=B and B<=C implies that A <= C

if A<=B and B <= A then A = B

There is some element L so that L <= A and L <=B for all pairs of elements A and B (greatest
lower bound)

There is some element H so the A <= H and B <= H for all A and B elements of set

In information security usage, the elements of the set are security labels on objects(unclassified,
confidential, secret, top secret etc.) and the relationship <= means "is at

same or lower level as"

What a lattice based security model allows one to do is combine objects from different security
classes and determine the appropriate classification for the result by showing that any
combination of security objects must maintain
the lattice rule between objects.

Mandatory Access Control models (MAC) are based on using the lattice rule.

The following information was provided by Arun S.:

CISPP Study Guide



Domain 1


Access Control and Methodology



-

19

-

In A lattice
-
model (Type of
MAC
and
Non
-
DAC
)

a.

There are pairs of elements


SUBJECT AND OBJEC
T

b.

They have Greatest


Lower bound of values

c.

They also have Lowest


Upper bound values

d.

The LbAC limits the SUBJECT’s scope of access of OBJECT, between the Values of (b)
and (c)


that is Greatest Lower bound and Lowest Upper bound of values. Thi
s results in
restricted access in the context of


“between the pair”.



The elements are as follows:

The subscript h = higher value; l = lower value

A
h

Private, {PERSONNEL)

A
l

Public, {PERSONNEL}

B
h

Private, {PERSONNEL
ENGINEERING)

B
l

Public, { PERSONNEL
ENGINEERING}

C
h

Private, {
ENGINEERING}

C
l

Public, {ENGINEERING}

D
h

Private, {XXX}

D
l

Public, {XXX}


The relation is:
<=

We can deduce, from the lattice diagram that:



A subject from Engineering can have a high level access, up to
C
h



which would be
LOWEST UPPER BOUND VALUE


i.e. he would not be allowed any further upwards
in the lattice

A
h

D
h

C
h

B
h


B
l

C
l

D
l

A
l

CISPP Study Guide



Domain 1


Access Control and Methodology



-

20

-



Similarly he can have a low level access, till,
C
l



which would be the HIGHEST UPPER
BOUND VALUE


i.e. he would not be allowed any further below, in the lattice



IMPORTANT: From the diagram, it is clear that the subject from Engineering will be out
of bounds from PUBLIC (PERSONNEL). But it is not so obvious (for those from NT
background, which uses DAC


This is based on MAC) that the subject from
ENGINNERING will
be out of bounds even to PUBLIC {PERSONNEL,
ENGINEERING)

5.3.4

Rule
-
Based Access Control

This section needs some input. I had difficulties in finding Rule Based Access Control
infor
mation. If you have any info I would appreciate it if you would forward it to
cdupuis@cccure.org

Rule based access control is based on a specific profile for each user. Information can be easily
changed for only one user but this scheme may become a burd
en in a very large environment.

A rule
-
based access control unit will intercept every request to the server and compare the source
specific access conditions with the rights of the user in order to make an access decision. A good
example could be a firewa
ll. Here a set of rules defined by the network administrator is recorded
in a file. Every time a connection is attempted (incoming or outgoing), the firewall software
checks the rules file to see if the connection is allowed. If it is not, the firewall cl
oses the
connection.

The RFC 2828


Internet Security Glossary talks about Rule Based Security Policy:

A security policy based on global rules imposed for all users. These rules usually rely on
comparison of the sensitivity of the resource being accessed
and the possession of corresponding
attributes of users, a group of users, or entities acting on behalf of users.

Tony Bruce sent me an example of Rule Based Access control based on ACF2, here it is:

ACF2 Administrators do the following:

-

Each User id is

defined with an Access Type / Group name (UID)

-

Each User has a User
-
id Rule built

-

Each piece of Data or Resource has a Rule defined in ACF2, and a User or Group is assigned
ownership of that Rule.

-

Every User or Group that needs access to that Dat
a is defined in a Rule
-
Line within that Rule
(see below).

-

Each time a user or user owned job accesses a piece of data, the system checks the ACF2
rules.

-

The ACF2 system either:



-

Gives them access if they are defined


-

Or denies them access,

and creates an Access Violation .

Example: (names have been changed)

ACF2 User
-
id

CISPP Study Guide



Domain 1


Access Control and Methodology



-

21

-

FB4104 WYZ FB4104 D772 F BROWN.FRED

Fred has a User
-
id of FB4104 and is allocated to a team using resources governed by UID (type)
WYZ

User Rule

There is a

User rule for each User
-
id, and this allows Fred to actually log on and access his data.
Only he can access data or libraries with a first field of FB4104

$KEY(FB4104)

$OWNER(ESS0772)

$PREFIX(******)

$USERDATA(WYZ)


-

UID(*)

5.3.4.1

Data / Resource Rules

All data and resources are defined and protected by unique rules. Each data name has 3
-

4 fields,
and is protected by the rule for that data name.

Eg. dataset




WZZZCCIF.DEV.DATA.~~~

will be governed by rule

WZZZCCIF

Inside the WZZZCCIF Rule will be
rule lines for each type of data that exists.

eg.

BKP = Backup data


DEV = Development data


PRD = Production Data


Etc

And within each type of data will be definitions:

-

for which Users or Groups can access that data type,

-

and what those user c
an do with it.


Eg. Read the data


Allocate new data


Change the data (Write)


etc

Dataset Rule activation

when a file WZZZCCIF.DEV.DATA is accessed by a job or user, ACF2 checks through the
WZZZCCIF rule.

$KEY(WZZZCCIF)

$OWNER(ESS0772)

CISPP Study Guide



Domain 1


Access Control and Methodology



-

22

-

$USERDATA(MT WASHIN
GTON ISC)

~

BKP.
-

~~~~~~

DEV.
-

UID(WYZ***FB4104) READ(A)

DEV.
-

UID(ABC) READ(A) WRITE(A) ALLOC(A) EXEC(A)

PRD.
-

~~~~~

~

~

All datasets with .DEV as the second field get protected by the DEV.
-

lines. The protection can
be given at the Group or Individual level. There will be 1 rule line for each separate access given.

In this case

a) The only member from Group WYZ who can a
ccess the data is Fred, (User
-
id FB4104 of the
Group WYZ), and he has been given READ ONLY access to the data

b) All of the Group ABC can access the DEV data, and they can do the following actions:


READ


A= Allow


WRITE

A= Allow


ALLOC

A= Allow


EXEC


A= Allow

c) Otherwise everyone else trying to access the WZZZCCIF.DEV.~~~ data gets access rejected
and a violation created.

Thus it can be seen that access can be simplified by linking users together into Groups, and
allocating the Group to a resource o
r dataset Then you only need to add the user to 1 rule, and
don't have to go back to each individual Data or Resource Rule to change an individuals access
when someone leaves or changes jobs.

The following information was provided by Arun S.:

Rule
-
based AC

is a type of MAC:

a.

As in MAC, there is an object with classification levels labeled

b.

As in MAC, there is a user with clearance levels defined

c.

The system correlates the level of Classification & Clearance (of object and subject
respectively) and dec
ides on Access Grant or Access Deny.

d.

This correlation is based on a set of rules.

e.

Thus it is called RULE based AC.

Advantages: Central control

CISPP Study Guide



Domain 1


Access Control and Methodology



-

23

-

5.3.5

Role
-
Based Access Control

R
ole
-
based access control (RBAC) is a technology that is attracting increasing attention,
particularly for commercial applications, because of its potential for reducing the complexity and
cost of security administration in large networked applications.

RB
AC is an alternative to traditional discretionary (DAC) and mandatory access control (MAC)
policies. The principle motivation behind RBAC is the desire to specify and enforce enterprise
-
specific security policies in a way that maps naturally to an organiza
tion's structure.
Traditionally, managing security has required mapping an organization's security policy to a
relatively low
-
level set of controls, typically access control lists.

With role
-
based access control, access decisions are based on the roles th
at individual users have
as part of an organization. Users take on assigned roles (such as doctor, nurse, teller, manager).
The process of defining roles should be based on a thorough analysis of how an organization
operates and should include input from

a wide spectrum of users in an organization.

Access rights are grouped by role name, and the use of resources is restricted to individuals
authorized to assume the associated role. For example, within a hospital system the role of
doctor can include oper
ations to perform diagnosis, prescribe medication, and order laboratory
tests; and the role of researcher can be limited to gathering anonymous clinical information for
studies.

The use of roles to control access can be an effective means for developing an
d enforcing
enterprise
-
specific security policies and for streamlining the security management process.

With RBAC, security is managed at a level that corresponds closely to the organization's
structure. Each user is assigned one or more roles, and each ro
le is assigned one or more
privileges that are permitted to users in that role. Roles can be hierarchical. For example, some
roles in a hospital may be health care provider, nurse, and doctor. The doctor role may include all
privileges available to the nur
se role, which in turn includes all the privileges available to the
health care provider role. Security administration with RBAC consists of determining the
operations that must be executed by persons in particular jobs, and assigning employees to the
prop
er roles. Complexities introduced by mutually exclusive roles or the RBAC software
handles role hierarchies, making security administration easier.

Users with similar or identical jobs are pooled into logical groups for the purposes of controlling
access

and access is provided according to business requirements. This is often contrasted to
"Rank
-
based access control"
-

unfortunately not a mythical scheme. Example
-

a junior
administrator may need to access your payroll details. If not in your line managem
ent tree, the
marketing director / VP has no business need for that information. The system administrator
needs to be able to fix problems with your email account. That may involve them being able to
read your email. The Corporate Security Officer should n
ot be able to read your email.

NIST has a nice paper on RBAC at
http://csrc.nist.gov/rbac


5.3.6

Access Control Lists

Access co
ntrol lists (ACLs) associate subjects and there permissions to resources. When a
subject tries to access a resource, its ACL is consulted to see whether the requested action is
CISPP Study Guide



Domain 1


Access Control and Methodology



-

24

-

permitted. ACLs can be used to implement a range of control policies such as M
AC, DAC and
RBAC.

The most famous ACL implementation is the standard UNIX files system permissions which is a
form of basic ACL.

Further information on ACLs is given in section
5.5.6

Access Matrix Model
.

5.3.7

Other Access Control Methods

In this section I am presenting other types of Access Control Methods that are
not on the CBK

but that may be interesting to look at for Security professionals that wish to learn more about
what is available. All readers are encouraged to send
me information on other methods that they
have seen or used that are not listed here.

5.3.7.1

Low Water
-
Mark Mandatory Access Control



Low Water
-
Mark Mandatory Access Control (LOMA
C) is a security enhancement for Linux
designed to protect the integrity of processes and data from viruses, Trojan horses, malicious
remote users and compromised root daemons. LOMAC is implemented as a loadable kernel
module
-

no kernel recompilations or
changes to existing applications are required. Although not
all the planned features are currently implemented, it presently provides sufficient protection to
thwart script
-
kiddies, and is stable enough for everyday use.

A white paper about Low Water
-
Mark

Mandatory Access Control can be found at:

ftp://ftp.tislabs.com/pub/lomac/lomac
-
sp00.pdf


The tool can be downloaded from:
http://www.pgp.com/research/nailabs/secure
-
execution/lomac.asp


5.3.7.2

FLASK

Flask is an operating system security architecture that provides flexible support for security
policies. The architecture was prototyped in the
Fluke
viii

research operating system. Several of
the Flask interfaces and components were then ported from the Fluke prototype to the
OSKit
ix
.
The Flask architecture is now being implemented in the Linux operating system (
Security
-
Enhanced Linux
x
) to transfer the technology to a larger developer and user community.

The components, wh
ich enforce security policy decisions, are referred to as Object Managers.
The components that provide security decisions to the object manager are referred to as security
servers. The decision
-
making subsystem may include other components such as admini
strative
interfaces and policy databases, but the interfaces among these components are policy
-
dependent
and are therefore not addressed by the architecture.

A thorough paper can be found at:
http://www.cs.utah.edu/flux/papers/micro/node7.html


More details can be found at:

http://www.cs.utah.edu/flux/
fluke/html/flask.html


CISPP Study Guide



Domain 1


Access Control and Methodology



-

25

-

5.4

Access Control Administration

Under this section you will find information about the administrative side of access control. It
will tell you how access

is set up, under which authority, what type of maintenance must be
performed, etc.

5.4.1

Account Administration

In many organizations accounts are created and then nobody ever touch
es those accounts again.
This is a very poor security practice. Accounts should be monitored regularly, you should look
at unused accounts and you should have a procedure in place to ensure that departing employees
have their rights revoke prior to leavi
ng the company. You should also have a procedure in place
to verify password strength or to ensure that there are no accounts without passwords.

The following points should be considered when creating and managing accounts:



Each user shall be assigned a unique identifier or user identification.



Access to the super
-
user or root account on a server must be limited to only the system
administrators that must absolutely have this level of access. Use of programs such as SUDO
is recommended to give limited and controlled root access to administrators that have a need
for such access.



The root account must be the only account with a user ID of 0 (zero) that has open access to
the UNIX shell.



It must not be possible for roo
t to sign on directly except at the system console. All other
access to the root account must be via the ‘su’ command.



Users must be authenticated before the system grants them access.



Users are responsible for all activities performed with their pe
rsonal user ID.



A record of user logins with time and date stamps must be kept.



User accounts shall be disabled and data kept for a specified period of time as soon as
employment is terminated.



All users must log on to gain network access.



Each

user assigned directory (home directory) is not to be shared with others.



If the computer system being used or to which a user is connected contains sensitive or
confidential information, users must not leave their computer, terminal, or workstation
wi
thout first logging off. Users should be reminded frequently to follow this rule.



If the computer, terminal, or workstation being used is connected to a network, users must
lock their terminal, computer, or workstation or log off before leaving it unat
tended. Users
should be reminded frequently to follow this rule.



Remove obsolete user
-
ids bimonthly



Compare with payroll (everyone gets paid) and human resource for an up
-
to
-
date list of
employees.



Suspend inactive user
-
ids (accounts) after 30
-
60
days

CISPP Study Guide



Domain 1


Access Control and Methodology



-

26

-



Delete suspended user
-
ids 30
-
60 days after suspension



Remove redundant UID, accounts, role
-
based groupings from resource ACL



Remove redundant resource rules from UID, accounts, and role based groups.

5.4.2

Account, Log, and Journal Monitoring

Security is a continuous process; as such you must closely monitor your systems on a regular
basis.
Logging is the activity that consists of collecting information
that will be used for
monitoring and auditing. Detailed logs combined with active monitoring allow detection of
security issues before they negatively affect your systems
.

Some care must be exercise as to what will be logged and how the logs are protected
. Having
corrupted logs is about as good as not having logs at all.

Usually logging is done 24 hours per day, 7 days per week, on all available systems and services
except during the maintenance window where some of the systems and services may not be
a
vailable while maintenance is being performed. Where metrics must be sampled periodically,
eg/ CPU usage, a suitable interval must be chosen. Often a 15 minute interval is chosen.

5.4.2.1

Requirements

The following pre
-
requisites must be met to ensure dependable and secure logging:



All computers must have their clock synchronized to a central timeserver to ensure accurate
time on events being logged.



If

possible all logs should be stored on a central server for easy analysis and also to help
detect patterns of abuse across servers.



Logging information traveling on the network must be encrypted if possible and hosts should
authenticate themselves to th
e log server.



Log files are stored and protected on a machine that has a hardened shell.



Log files must not be modifiable without a trace or record of such modification.



The system administrator actions, events, modifications, and changes must
be logged.



All production applications must generate a log that shows every addition, modification, and
deletion of information.



All production applications must keep logs of users activities and statistics related to those
activities.



All securi
ty relevant events must be logged.



Logs must provide sufficient data to support comprehensive audits of the effectiveness of,
and compliance with security policies.



All commands issued by users must be traceable to specific individuals via the use of

comprehensive logs.

All logs collected are used in the active and passive monitoring process.

CISPP Study Guide



Domain 1


Access Control and Methodology



-

27

-

All logs are kept on archive for a period of time. This period of time will be determined by your
company policies. This allows the use of logs for regular and

annual audits if retention is longer
then a year.

Logs must be secured to prevent modification, deletion, and destruction.

Only authorized persons should have access or permission to read logs. A person is authorized if
he or she is a member of the inter
nal audit staff, security staff, system administration staff, or he
or she has a need for such access to perform regular duties.

5.4.2.2

What should be logged?

The level of logging will be according to your company requirements. Below is a list of items
that could be logged, please note that some of the items may not be applicable to all operating
systems. What is being logged depends on wh
ether you are looking for performance problems or
security problems. However you have to be careful about performance problems that could
affect your security.

The following system activities, conditions, performance, and events are suggested to be logged

:

System



CPU

o

CPU load

o

Percentage of idle time

o

Percentage of load

o

Average CPU usage in past 5, 15 or 30 minutes



Memory Usage

o

Percentage available

o

Swapping



Storage Usage (hard disk, file system, volume)

o

Percentage free

o

Quota

o

Space allocated and used per user

o

Use of mount command

o

Uses of unmount command

o

Error messages from disk subsystem (eg/ time out, device not available)

Firewall

The following firewall activities, con
ditions, and events are logged:



Scanning of ports for service



Requests on ports without services

CISPP Study Guide



Domain 1


Access Control and Methodology



-

28

-



Requests on ports that run insecure services



Requests on ports that usually have no service



Request for the following services: systat, bootp, tftp,
sunrpc, snmp, snmp
-
trap, nfs



Attacks via sendmail vulnerabilities



Attacks via Syn flooding



Attacks via Ping of death



Probes by penetration tool such as ISS, Ballista, SATAN



Packets that have unusual header options set, eg/ source routing enabled



Repeated failed login attempts

The following firewall configuration problem are logged:



Reboot of the firewall



Proxies that cannot start (e.g. Within TIS firewall)



Proxies or other important services that have died or restarted



Changes to firewa
ll configuration file



A configuration or system error while firewall is running

Login and Failed Logins

The following login failures, attempts at, or events are logged:



Succe
ssful root login (ftp, su, at console, telnet, rlogin, X Windows)



Failed root login



Successful su to root



Failed su to root



Successful user login (ftp, su, at console, telnet, rlogin, X Windows)



Failed user login



Successful su to a user account



Failed su to a user account



Successful use of r commands



Failed use of r commands



Successful X Windows session



Failed X Windows session

Servers

The following servers activities, conditions, and

events are logged:

CISPP Study Guide



Domain 1


Access Control and Methodology



-

29

-



Start time



Stop Time



Load statistics



Configuration changes



Web files changes (new, deleted, modified)



FTP files changes (new, deleted, modified)



Successful admin login (with time and date)



Failed admin login (with time a
nd date)



Successful login (with time and date)



Failed login (with time and date)



Unavailability



Concurrent users/sessions

Routers

The following routers activities, conditions, and events are logged:



Reboot



Router CPU loads



Detection of IP Spoofing



Detection of source routing



Detection of Ping of death



Unavailability



Configuration changes

Processes

The following processes usage, conditions, and events are logged:



Critical Processes



Hung processes



Processes errors

Connectivity

The following connectivity statu
s, performance, conditions, and events are logged:



Local



Remote



Crucial Links

CISPP Study Guide



Domain 1


Access Control and Methodology



-

30

-



Bandwidth use



Collision rate



Number of Packets in



Number of Packets out



Interface errors



Verification that the interface is not in promiscuous mode

Critical Files Modification and Access

The following file changes, conditions, and events are logged:



.rhosts



UNIX Kernel



/etc/password



rc directory structure



bin files



lib files



Use of Setuid



Use of Setgid



Change of permission on system or critical files



Additions and changes to privileges

5.4.3

Access Rights and Permissions

5.4.3.1

Establishme
nt (Authorization)

Authorization determines who is trusted for a given purpose. More precisely, it determines
whether a particular principal, who has been authenticated as the source of a request to do
something, is trusted for that

operation. Authorization may also include controls on the time at
which something can be done (e.g. only during working hours) or the computer terminal from
which it can be requested (e.g. only the one on the system administrator desk).

File and Data Owne
rs, Custodians, and Users



All information generated, or used must have a designated owner. The owner must
determine appropriate sensitivity classifications, and access controls.



The owner must also take steps to ensure the appropriate controls for the

storage,
handling, distribution, and use of the information in a secure manner.

Principle of least Privilege

The principle of least privilege has been described as important for meeting integrity objectives
xi
.
The principle of least privilege requires that a user be given no more privilege than necessary to
CISPP Study Guide



Domain 1


Access Control and Methodology



-

31

-

perform a job. Ensuring least privilege requires identifying what the user's job is, determining the
minimum set of privileges required to perform that jo
b, and restricting the user to a domain with
those privileges and nothing more. By denying to subjects transactions that are not necessary for
the performance of their duties, those denied privileges couldn’t be used to circumvent the
organizational securi
ty policy. Although the concept of least privilege currently exists within the
context of the TCSEC
xii
, requirements restrict those privileges of the system administrator.
Through the use of RBAC, enforced minimum privileges for general system users can be easily
achieved.

Separation of Duties and Responsibilities
xiii

Separation of duties is considered valuable in deterring fraud since fraud can occur if an
opportunity exists for collaboration between various jobs related capabilities. Separation of duty
requires that for particular sets of transactions, n
o single individual be allowed to execute all
transactions within the set. The most commonly used examples are the separate transactions
needed to initiate a payment and to authorize a payment. No single individual should be capable
of executing both trans
actions.

Separation of duty is an important consideration in real systems. The sets in question will vary
depending on the application. In real situations, only certain transactions need to be restricted
under separation of duty requirements. For example
, we would expect a transaction for
“authorize payment'” to be restricted, but a transaction ``submit suggestion to administrator''
would not be.

Separation of duty can be either static or dynamic. Compliance with static separation
requirements can be det
ermined simply by the assignment of individuals to roles and allocation
of transactions to roles. The more difficult case is dynamic separation of duty where compliance
with requirements can only be determined during system operation. The objective behind
dynamic separation of duty is to allow more flexibility in operations. Consider the case of
initiating and authorizing payments. A static policy could require that no individual who can
serve as payment initiator could also serve as payment authorizer. Thi
s could be implemented by
ensuring that no one who can perform the initiator role could also perform the authorizer role.
Such a policy may be too rigid for commercial use, making the cost of security greater than the
loss that might be expected without th
e security. More flexibility could be allowed by a dynamic
policy that allows the same individual to take on both initiator and authorizer roles, with the
exception that no one could authorize payments that he or she had initiated. The static policy
could
be implemented by checking only roles of users; for the dynamic case, the system must use
both role and user ID in checking access to transactions.

Separation of duty is necessarily determined by conditions external to the computer system. The
Clark
-
Wilso
n scheme includes the requirement that the system maintain the separation of duty
requirement expressed in the access control triples. Enforcement is on a per
-
user basis, using the
user ID from the access control triple. As discussed above, user functions
can be conveniently
separated by role, since many users in an organization typically perform the same function and
have the same access rights on applications and data. Allocating access rights according to role is
also helpful in defining separation of du
ty in a way that can be enforced by the system.

Despite separation of duties, fraud can still occur when more than one person controlling a
component part collaborates with others to breach the security of a system. This is know as
collusion. One attempt
at preventing collusion is job rotation.

CISPP Study Guide



Domain 1


Access Control and Methodology



-

32

-

5.4.3.2

Maintenance

TBC

5.4.3.3

Revocation

TBC

5.5

Access Control Models

What is an access control model?
xiv

It is a formal description of a security policy.

What is a security policy? A security policy capture
s the security requirements of an enterprise
or describes the steps that have to be taken to achieve security.

Security models are used in security evaluation, sometimes as proofs of security.

I found a very interesting presentation of Access Control Model

on the web site at the University
of Oregon, Information System Laboratory. The presentation is in adobe PDF format and is a
must read for anyone that wishes to take the CISSP exam. It can be found at the following
address:
http://www.cccure.org/Document
s/Security_models/models.pdf


There are numerous Access Control Models that exist that have been developed for different
purposes. Some models have been developed to capture confidentiality issues,
others integrity.
Some models are aimed at commercial e
nvironments others at the military.

5.5.1

Bell
-
LaPadula

Bell
-
LaPadula (BLP) is a formal state
-
transition model of computer security policy that describes
a set of access control rules for a set of subjects an
d objects. It is a formalization of the MAC
model we have already seen and is used to prove that as information flows from one object to
another, the system remains in a secure state. That is to say, information that was prohibited to a
subject in one stat
e is also prohibited in all other reachable states.

A system state is defined to be "secure" if the only permitted access modes of subjects to objects
are in accordance with a specific security policy.

To determine whether a specific access mode is allowe
d, the clearance of a subject is compared
with the classification of the object, and a determination is made as to whether the subject is
authorized for the specific access mode.
xv

The BLP model is governed by two rules, which are the
Simple Security Property, Star
-
Property.

The Simple Security Property asserts that a subject can read an object only if the security
clearance of the subject is higher or equal to the security classific
ation of the object. This can be
written as follows, where L(x) indicates the security label of x:

Subject s can read Object o if L(s)


L(o)

The Simple Security Property is also known as ‘no read up’ and ensures that data remains
confidential

The Star
-
pro
perty asserts that a subject can only write to an object if the object has a higher or
equal security classification than the object. This can be written as follows:

CISPP Study Guide



Domain 1


Access Control and Methodology



-

3
3

-

Subject s can write to Object o if L(s)


L(o)

This is known as ‘no write down’ and ensure
s that sensitive data cannot be downgraded to a
lower level.

Limitations of the BLP



Has no policies for changing access data control



Intended for systems with static security levels



Contains covert channels: High clearance information can be transmit
ted to low clearance
users through the use of covert channels.



Restricted to confidentiality. Integrity can be breached by low
-
clearance user writing to a
high
-
clearance object.



As data is read and written, there is a tendency for security labels to rise, restricting
access to further and further until nobody is able to access it anymore.

See reference
xvi
,
xvii

and
xviii

for further links to BLP sites.

5.5.2

Biba

Biba is a state machine model similar to BLP but desi
gned to capture integrity aspects of access
controls. The basic concept is that low integrity information may not rise to a high integrity level.

T
he Handbook of Information System Management
xix
, presents the following definition:

In studying the two properties of the Bell
-
LaPadula model, Biba discovered a plausible
notion of integrity, which he defined as prevention of unauthorized modification. The
resulting Biba integrity model st
ates that maintenance of integrity requires that data not
flow from a receptacle of given integrity to a receptacle of higher integrity. For example,
if a process can write above its security level, trustworthy data could be contaminated by
the addition of

less trustworthy data.

Biba
xx

modeled a case of likewise cleared users accesses to integrity of classified documents.

It also has two rules, the Simple Integr
ity Property and the Integrity Star
-
Property. The rules
were similar to Bell
-
LaPadula’s rules, but reversed: