MIS risk and security project
Access Control
We can view access control as a central element of computer security. The principal
objectives of computer security are to prevent unauthorized users from gaining
access to resources, to prevent legitimate users from accessing resources in an unauthorized
manner, and to enable legitimate users to access resources in an authorized
manner.
We begin this chapter with an overview of some important concepts. Next
we look at three widely used techniques for implementing access control policies.
We then turn to a broader perspective of the overall management of access control
using identity, credentials, and attributes. Finally, the concept of a trust framework
is introduced.
1
Access Control Definition
RFC 4949 defines access control as:
“a process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy”
2
2. RFC 4949, Internet Security Glossary , defines access control as a process by
which use of system resources is regulated according to a security policy and
is permitted only by authorized entities (users, programs, processes, or other
systems) according to that policy.
Access Control Principles
In a broad sense, all of computer security is concerned with access control
RFC 4949 defines computer security as:
“measures that implement and assure security services in a computer system, particularly those that assure access control service”
3
In a broad sense, all of computer security is concerned with access control. Indeed,
RFC 4949 defines computer security as follows: measures that implement and assure
security services in a computer system, particularly those that assure access control
service. This chapter deals with a narrower, more specific concept of access control:
Access control implements a security policy that specifies who or what (e.g., in the
case of a process) may have access to each specific system resource, and the type of
access that is permitted in each instance.
Single Sign-On
4
Single sign-on lets a user log on once per session but access many different applications/systems. It often works in conjunction with federated identity management, with the federated identity provider acting as the source of authentication for all the applications.
4
Single sign-on (SSO)
is a property of access control of multiple related, but independent software systems.
With this property a user logs in with a single ID and password to gain access to a connected system or systems without using different usernames or passwords
5
Multifactor Authentication
Combining authentication information
Increasing the number of authentication forms, increases the user’s inconvenience
6
Limited privilege
is the act of restraining users and processes so that any harm they can do is not catastrophic.
A system that prohibits all accesses to anything by anyone certainly achieves both confidentiality and integrity, but it completely fails availability and usefulness.
Limited privilege is a management concept, not a technical control.
The process of analyzing users and determining the privileges they require is a necessary first step to authorizing within those limits.
After establishing the limits, we turn to access control technology to enforce those limits
7
Access Control
8
8
Access Control Policies
Role-based access control (RBAC)
Controls access based on the roles that users have within the system and on rules stating what accesses are allowed to users in given roles
Attribute-based access control (ABAC)
Controls access based on attributes of the user, the resource to be accessed, and current environmental conditions
Discretionary access control (DAC)
Controls access based on the identity of the requestor and on access rules (authorizations) stating what requestors are (or are not) allowed to do
Mandatory access control (MAC)
Controls access based on comparing security labels with security clearances
9
An access control policy, which can be embodied in an authorization database,
dictates what types of access are permitted, under what circumstances, and by
whom. Access control policies are generally grouped into the following categories:
• Discretionary access control (DAC): Controls access based on the identity
of the requestor and on access rules (authorizations) stating what requestors
are (or are not) allowed to do. This policy is termed discretionary because an
entity might have access rights that permit the entity, by its own volition, to
enable another entity to access some resource.
• Mandatory access control (MAC): Controls access based on comparing
security labels (which indicate how sensitive or critical system resources are)
with security clearances (which indicate system entities are eligible to access
certain resources). This policy is termed mandatory because an entity that has
clearance to access a resource may not, just by its own volition, enable another
entity to access that resource.
• Role-based access control (RBAC): Controls access based on the roles that
users have within the system and on rules stating what accesses are allowed to
users in given roles.
• Attribute-based access control (ABAC): Controls access based on attributes
of the user, the resource to be accessed, and current environmental
conditions.
DAC is the traditional method of implementing access control, and is examined
in Sections 4.3 and 4.4. MAC is a concept that evolved out of requirements for
military information security and is best covered in the context of trusted systems,
which we deal with in Chapter 27. Both RBAC and ABAC have become increasingly
popular, and are examined in Sections 4.5 and 4.6, respectively.
These four policies are not mutually exclusive. An access control mechanism
can employ two or even all three of these policies to cover different classes of system
resources.
Subjects, Objects, and Access Rights
10
The basic elements of access control are: subject, object, and access right.
A subject is an entity capable of accessing objects. Generally, the concept of
subject equates with that of process. Any user or application actually gains access to
an object by means of a process that represents that user or application. The process
takes on the attributes of the user, such as access rights.
A subject is typically held accountable for the actions they have initiated,
and an audit trail may be used to record the association of a subject with security relevant
actions performed on an object by the subject.
Basic access control systems typically define three classes of subject, with
different access rights for each class:
• Owner: This may be the creator of a resource, such as a file. For system resources,
ownership may belong to a system administrator. For project resources, a project
administrator or leader may be assigned ownership.
• Group: In addition to the privileges assigned to an owner, a named group of
users may also be granted access rights, such that membership in the group is
sufficient to exercise these access rights. In most schemes, a user may belong
to multiple groups.
• World: The least amount of access is granted to users who are able to access the
system but are not included in the categories owner and group for this resource.
An object is a resource to which access is controlled. In general, an object
is an entity used to contain and/or receive information. Examples include records,
blocks, pages, segments, files, portions of files, directories, directory trees, mailboxes,
messages, and programs. Some access control systems also encompass, bits,
bytes, words, processors, communication ports, clocks, and network nodes.
The number and types of objects to be protected by an access control system
depends on the environment in which access control operates and the desired tradeoff
between security on the one hand and complexity, processing burden, and ease
of use on the other hand.
An access right describes the way in which a subject may access an object.
Access rights could include the following:
• Read: User may view information in a system resource (e.g., a file, selected
records in a file, selected fields within a record, or some combination). Read
access includes the ability to copy or print.
• Write: User may add, modify, or delete data in system resource (e.g., files,
records, programs). Write access includes read access.
• Execute: User may execute specified programs.
• Delete: User may delete certain system resources, such as files or records.
• Create: User may create new files, records, or fields.
• Search: User may list the files in a directory or otherwise search the directory.
Subject
An entity capable of accessing objects
Three classes
Owner
Group
World
Object
A resource to which access is controlled
Entity used to contain and/or receive information
Access right
Describes the way in which a subject may access an object
Could include:
Read
Write
Execute
Delete
Create
Search
Mandatory Access Control (MAC)
The strictest of all levels of control
Controlled by settings defined by the system administrator.
A system-enforced access control based on a subject’s clearance and an object’s labels.
Subjects and Objects have clearances and labels, such as confidential, secret, and top secret.
A subject may access an object only if the subject’s clearance is equal to or greater than the object’s label.
Subjects cannot share objects with other subjects who lack the proper clearance, or “write down” objects to a lower classification level (such as from top secret to secret).
MAC systems are usually focused on preserving the confidentiality of data.
Explain in details
11
Discretionary Access Control (DAC)
Allows each user to control access to their own data.
Often provided using an access matrix
One dimension consists of identified subjects that may attempt data access to the resources
The other dimension lists the objects that may be accessed
Each entry in the matrix indicates the access rights of a particular subject for a particular object
12
As was previously stated, a discretionary access control scheme is one in which an
entity may be granted access rights that permit the entity, by its own volition, to
enable another entity to access some resource. A general approach to DAC, as
exercised by an operating system or a database management system, is that of an
access matrix. The access matrix concept was formulated by Lampson [LAMP69,
LAMP71], and subsequently refined by Graham and Denning [GRAH72, DENN71]
and by Harrison et al. [HARR76].
One dimension of the matrix consists of identified subjects that may attempt
data access to the resources. Typically, this list will consist of individual users or
user groups, although access could be controlled for terminals, network equipment,
hosts, or applications instead of or in addition to users. The other dimension lists
the objects that may be accessed. At the greatest level of detail, objects may be
individual data fields. More aggregate groupings, such as records, files, or even the
entire database, may also be objects in the matrix. Each entry in the matrix indicates
the access rights of a particular subject for a particular object.
Data Owners can transfer ownership of information to other users
Data Owners can determine the type of access given to other users (read, write, copy, etc.)
Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user's access
A user can only set access permissions for resources which they already own
User A cannot, change the access control for a file that is owned by User B
Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
14
15
In practice, an access matrix is usually sparse and is implemented by decomposition in one of two ways. The matrix may be decomposed by columns, yielding access control lists (ACLs); see Figure 4.2b. For each object, an ACL lists users and their permitted access rights. The ACL may contain a default, or public, entry. This allows users that are not explicitly listed as having special rights to have a default set of rights. The default set of rights should always follow the rule of least privilege or read-only access, whichever is applicable. Elements of the list may include individual users as well as groups of users.
When it is desired to determine which subjects have which access rights to a particular resource, ACLs are convenient, because each ACL provides the information for a given resource. However, this data structure is not convenient for determining the access rights available to a specific user.
Decomposition by rows yields capability tickets (Figure 4.2c). A capability
ticket specifies authorized objects and operations for a particular user. Each user
has a number of tickets and may be authorized to loan or give them to others.
Because tickets may be dispersed around the system, they present a greater
security problem than access control lists. The integrity of the ticket must be
protected, and guaranteed (usually by the operating system). In particular, the
ticket must be unforgeable. One way to accomplish this is to have the operating
system hold all tickets on behalf of users. These tickets would have to be held in
a region of memory inaccessible to users. Another alternative is to include an
unforgeable token in the capability. This could be a large random password, or a
cryptographic message authentication code. This value is verified by the relevant
resource whenever access is requested. This form of capability ticket is appropriate
for use in a distributed environment, when the security of its contents cannot
be guaranteed.
The convenient and inconvenient aspects of capability tickets are the opposite
of those for ACLs. It is easy to determine the set of access rights that a given user
has, but more difficult to determine the list of users with specific access rights for a
specific resource.
An access matrix is implemented in two ways:
ACL and Capability ticket
Access control lists (ACLs); it lists users and their permitted access rights.
It contains a default, or public, entry.
This allows users that are not explicitly listed as having special rights to have a default set of rights.
The default set of rights should always follow the rule of least privilege or read-only access,
Advantages:
Easy to determine which subjects have which access rights to a particular resource, because each ACL provides the information for a given resource.
Disadvantages:
Not convenient for determining the access rights available to a specific user.
A capability ticket specifies authorized objects and operations for a particular user.
Advantages:
the opposite of those for ACLs.
It is easy to determine the set of access rights that a given user
Disadvantages:
difficult to determine the list of users with specific access rights for a specific resource.
All
18
Table 4.2
Authorization Table
for Files in Figure 4.2
(Table is on page 113 in the textbook)
19
[SAND94] proposes a data structure that is not sparse, like the access matrix,
but is more convenient than either ACLs or capability lists (Table 4.2). An authorization table contains one row for one access right of one subject to one resource. Sorting or accessing the table by subject is equivalent to a capability list. Sorting or accessing the table by object is equivalent to an ACL. A relational database can easily implement an authorization table of this type.
Bell-LaPadula model
The Simple Security Property (ss Property) states that a subject at a given security level cannot read data that resides at a higher security level (No Read Up).
The * (star) Security Property states that a subject in a given security level cannot write information to a lower security level. (No Write Down).
The Strong Star Property states that a subject that has read and write capabilities can only perform those functions at the same security level, nothing higher and nothing lower. A subject to be able to read and write to an object, the clearance and classification must be equal.
tranquility principle of the Bell–LaPadula model states that the classification of a subject or object does not change while it is being referenced.
20
The Bell-LaPadula Model
Simple
Security
Property
Star (*)
Property
Strong
Star (*)
Property
Layer of
Lower Secrecy
Layer of
Higher Secrecy
Read
Write
Read/Write
Χ
Χ
Χ
Reading
Secrets
Reading
Secrets
Χ
21
Biba model
describes read and write restrictions based on integrity access classes of subjects and objects. It is the first model to address integrity.
The Simple Integrity property: States that a subject at one level of integrity is not permitted to observe (read) an object of a lower integrity. No Read Down.
The * (Star) Integrity property : States that an object at one level of integrity is not permitted to modify (write to) an object of a higher level of integrity. No Write Up.
Invocation property states that a subject at one level of integrity cannot invoke (call up) a subject at a higher level of integrity.
22
The Invocation Property
The Biba model can be extended to include an access operation called invoke. A subject can invoke another subject, such as a software utility, to access an object.
The subject cannot send message (logical request for service) to subjects of higher integrity. Subjects are only allowed to invoke utilities or tools at the same or lower integrity level (otherwise, a dirty subject could use a clean tool to access or contaminate a clean object).
23
The Biba Model
Simple
Integrity
Property
Integrity
Star (*)
Property
Layer of
Lower Secrecy
Layer of
Higher Secrecy
Read
Write
Χ
Contamination
Χ
Get
Contaminated
24
Role-Based Access Control (RBAC)
Traditional DAC systems define the access rights of individual users and groups of users.
RBAC is based on the roles that users assume in a system rather than the user’s identity.
RBAC models define a role as a job function within an organization.
RBAC systems assign access rights to roles instead of individual users.
In turn, users are assigned to different roles, either statically or dynamically, according to their responsibilities.
The relationship of users to roles is many to many, as is the relationship of roles to resources, or system objects
The set of users changes, in some environments frequently, and the assignment of a user to one or more roles may also be dynamic.
The set of roles in the system in most environments is static, with only occasional additions or deletions.
Each role will have specific access rights to one or more resources.
The set of resources and the specific access rights associated with a particular role are also likely to change infrequently.
RBAC is an effective implementation of the principle of least privilege.
Each role should contain the minimum set of access rights needed for that role.
A user is assigned to a role that enables him or her to perform only what is required for that role.
Multiple users assigned to the same role, enjoy the same minimal set of access rights.
Constraints - RBAC
Provide a means of adapting RBAC to the specifics of administrative and security policies of an organization
A defined relationship among roles or a condition related to roles
Types:
Constraints provide a means of adapting RBAC to the
specifics of administrative and security policies in an organization. A constraint is
a defined relationship among roles or a condition related to roles. [SAND96] lists
the following types of constraints: mutually exclusive roles, cardinality, and prerequisite
roles.
Mutually exclusive roles are roles such that a user can be assigned to only
one role in the set. This limitation could be a static one, or it could be dynamic, in
the sense that a user could be assigned only one of the roles in the set for a session.
The mutually exclusive constraint supports a separation of duties and capabilities
within an organization. This separation can be reinforced or enhanced by use of
mutually exclusive permission assignments. With this additional constraint, a mutually
exclusive set of roles has the following properties:
1. A user can only be assigned to one role in the set (either during a session or
statically).
2. Any permission (access right) can be granted to only one role in the set.
Thus the set of mutually exclusive roles have non-overlapping permissions. If two
users are assigned to different roles in the set, then the users have non-overlapping
permissions while assuming those roles. The purpose of mutually exclusive roles is to
increase the difficulty of collusion among individuals of different skills or divergent job
functions to thwart security policies.
Cardinality refers to setting a maximum number with respect to roles. One
such constraint is to set a maximum number of users that can be assigned to a given
role. For example, a project leader role or a department head role might be limited
to a single user. The system could also impose a constraint on the number of roles
that a user is assigned to, or the number of roles a user can activate for a single session.
Another form of constraint is to set a maximum number of roles that can be
granted a particular permission; this might be a desirable risk mitigation technique
for a sensitive or powerful permission.
A system might be able to specify a prerequisite role, which dictates that a user can
only be assigned to a particular role if it is already assigned to some other specified
role. A prerequisite can be used to structure the implementation of the least privilege
concept. In a hierarchy, it might be required that a user can be assigned to a senior
(higher) role only if it is already assigned an immediately junior (lower) role. For
example, in Figure 4.9 a user assigned to a Project Lead role must also be assigned
to the subordinate Production Engineer and Quality Engineer roles. Then, if the user
does not need all of the permissions of the Project Lead role for a given task, the user
can invoke a session using only the required subordinate role. Note that the use of
prerequisites tied to the concept of hierarchy requires the RBAC3 model.
28
Mutually exclusive roles
A user can only be assigned to one role in the set (either during a session or statically)
Any permission (access right) can be granted to only one role in the set
Cardinality
Setting a maximum number with respect to roles
Prerequisite roles
Dictates that a user can only be assigned to a particular role if it is already assigned to some other specified role
Summary
Attribute-based access control
Attributes
ABAC logical architecture
ABAC policies
Identity, credential, and access management
Identity management
Credential management
Access management
Identity federation
Trust frameworks
Traditional identity exchange approach
Open identity trust framework
Bank RBAC system
Access control principles
Access control context
Access control policies
Subjects, objects, and access rights
Discretionary access control
Access control model
Protection domains
UNIX file access control
Traditional UNIX file access control
Access control lists in UNIX
Role-based access control
RBAC reference models
29
Chapter 4 summary.
User Single Sign-On Shell
Identification and Authentication
Credentials
Application
Authentication
Token
AuthenticationAuthentication
ApplicationApplication
Password
User
Single Sign-On
Shell
Identification and
Authentication
Credentials
Application
Authentication
Token
AuthenticationAuthentication
ApplicationApplication
Password
PROG1. C
PROG1.EXE
BIBLIOG
HELP.TXT
TEMP
ORW
ORW
ORW
OX
R
BIBLIOG
TEST.TMP
PRIVATE
HELP.TXT
R
ORW
OX
R
File NameFile Name Access Rights
Access Rights
File Pointer
File Pointer
User A Directory User B DirectoryFiles
PROG1.C
PROG1.EXE
BIBLIOG
HELP.TXT
TEMP
ORW
ORW
ORW
OX
R
BIBLIOG
TEST.TMP
PRIVATE
HELP.TXT
R
ORW
OX
R
File NameFile Name
Access
Rights
Access
Rights
File
Pointer
File
Pointer
User A Directory
User B Directory
Files
F
TEMP
BIBLIOG
HELP.TXT
File Access List
Pointer User Access Rights
USER_S
USER_B
USER_A ORW
RW
R
BIBLIOG
TEMP
F
HELP.TXT
USER_A ORW
USER_S
USER_A ORW
R
USER_S
USER_B
USER_A R
R
R
USER_T R
SYSMGR
USER_SVCS
RW
O
Directory Access Lists Files
F
TEMP
BIBLIOG
HELP.TXT
File
Access List
Pointer
User
Access
Rights
USER_S
USER_B
USER_AORW
RW
R
BIBLIOG
TEMP
F
HELP.TXT
USER_AORW
USER_S
USER_A
ORW
R
USER_S
USER_B
USER_AR
R
R
USER_T
R
SYSMGR
USER_SVCS
RW
O
Directory Access Lists
Files
Subject Access Mode
Object
A Own File 1 A Read File 1 A Write File 1
A Own File 3 A Read File 3
A Write File 3 B Read File 1 B Own File 2
B Read File 2 B Write File 2 B Write File 3
B Read File 4 C Read File 1 C Write File 1
C Read File 2 C Own File 4 C Read File 4
C Write File 4
Subject Access
Mode
Object
A Own File 1
A Read File 1
A Write File 1
A Own File 3
A Read File 3
A Write File 3
B Read File 1
B Own File 2
B Read File 2
B Write File 2
B Write File 3
B Read File 4
C Read File 1
C Write File 1
C Read File 2
C Own File 4
C Read File 4
C Write File 4