852 lines
43 KiB
Plaintext
852 lines
43 KiB
Plaintext
|
||
* * * * * * * * * * * * * NOTE * * * * * * * * * * * * * * * * *
|
||
|
||
This file is a DRAFT chapter intended to be part of the NIST
|
||
Computer Security Handbook. The chapters were prepared by
|
||
different parties and, in some cases, have not been reviewed by
|
||
NIST. The next iteration of a chapter could be SUBSTANTIALLY
|
||
different than the current version. If you wish to provide
|
||
comments on the chapters, please email them to roback@ecf.ncsl.gov
|
||
or mail them to Ed Roback/Room B154, Bldg 225/NIST/Gaithersburg, MD
|
||
20899.
|
||
|
||
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
||
|
||
DRAFT DRAFT DRAFT DRAFT DRAFT
|
||
|
||
Logical Access Control
|
||
|
||
|
||
1 Introduction
|
||
|
||
IT systems today can process and store a wide variety of
|
||
information and provide access to it to a large number of users. It
|
||
is not unusual for a system in a large organization to contain some
|
||
information that must be accessible to all users, some that is
|
||
needed by several groups or departments, as well as some that
|
||
should be accessed by only a few individuals. Having information
|
||
reside centrally on a system used by everyone contributes to cost
|
||
effective and efficient information sharing and processing.
|
||
|
||
Information residing on a system that is accessed by many users,
|
||
however, can also create problems. A significant concern is
|
||
ensuring that users have access to information that they need but
|
||
do not have inappropriate access to information that is sensitive.
|
||
It is also important to ensure that certain items, though readable
|
||
by many users, can only be changed by a few.
|
||
|
||
Logical access controls are a means of addressing these problems.
|
||
Logical access controls are protection mechanisms that limit users'
|
||
access to information and restrict their forms of access on the
|
||
system to only what is appropriate for them. Logical access
|
||
controls are often built into the operating system, or may be part
|
||
of the "logic" of applications programs or major utilities, such as
|
||
Database Management Systems. They may also be implemented in
|
||
add-on security packages that are installed into an operating
|
||
system; such packages are available for a variety of systems,
|
||
including PCs and mainframes. Additionally, logical access
|
||
controls may be present in specialized components that regulate
|
||
communications between computers and networks.
|
||
|
||
Some rudimentary forms of automated access controls have been
|
||
available for many years, but today there are increasingly
|
||
sophisticated and cost-effective methods that managers will find
|
||
well worth investigating. This chapter will discuss some of the
|
||
advantages provided by logical access control and issues to be
|
||
considered when investigating logical access control. It will also
|
||
provide an introduction to common forms of logical access control
|
||
available today.
|
||
|
||
2 Background Information
|
||
|
||
As noted above, logical access control limits users' access to
|
||
information, and it can restrict the capabilities or modes of
|
||
access they have. It can therefore help promote efficiency and IT
|
||
security at the same time, but there are potential drawbacks that
|
||
should be weighed and considered. While logical access controls
|
||
can be of great benefit to an organization, adding them to a system
|
||
does not automatically make the system more secure. A poorly
|
||
chosen or improperly configured control mechanism can have a
|
||
detrimental effect, as can inadequate understanding of the
|
||
complexities involved in implementing and managing the technology.
|
||
Following is general information and background on logical access
|
||
control, and an introduction to some of the associated issues.
|
||
|
||
2.1 Types of Access Restrictions
|
||
|
||
Many of the advantages as well as many of the complexities involved
|
||
in implementing and managing logical access control are related to
|
||
the different kinds of user accesses supported. Not only are the
|
||
types of accesses allowed an important consideration, but so are
|
||
the kinds of data, programs, devices, and services. Some
|
||
information on the system, such as the data displayed on an
|
||
organization's daily calendar of nonsensitive meetings, should be
|
||
readable by literally everyone in the organization. The program
|
||
that formats and displays the calendar, however, might be
|
||
modifiable by only a very few IT system administrators, while the
|
||
operating system controlling that program might be accessible by
|
||
still fewer.
|
||
|
||
2.1.1 Access Modes
|
||
|
||
The concept of access modes is fundamental to logical access
|
||
control. The effect of many types of logical access control is to
|
||
permit or deny access by specific individuals to specific
|
||
information resources in specific access modes. An introduction to
|
||
the common access modes follows.
|
||
|
||
Read only: This provides users with the capability to view, copy,
|
||
and usually print information but not to do anything to alter it,
|
||
such as delete from, add to, or modify it in any way. Read- only
|
||
accesses are probably the most widely allowed to data files on IT
|
||
systems.
|
||
|
||
Read and Write: Users are allowed to view and print as well as
|
||
add, delete, and modify information. Logical access control can
|
||
further refine the read/write relationship such that a user has
|
||
read-only ability for one field of information but the ability to
|
||
write to a related field. An example would be a project Action
|
||
Item program that allows a user read-only ability for the assigned
|
||
action items and permits responses to be written in the space below
|
||
an action item.
|
||
|
||
Execute: The most common activity performed by users in relation
|
||
to applications programs on a system is to execute them. A user
|
||
executes a program each time he or she uses a word processor,
|
||
spreadsheet, database, etc. Users would not ordinarily be given
|
||
read or write capabilities for an application, however, since it
|
||
would appear in a format that is unintelligible to most users. It
|
||
might be desirable, though, for software programming specialists to
|
||
be able to read and write applications.
|
||
|
||
Successfully refining, implementing, and managing these different
|
||
access modes have resulted in greatly improved information sharing,
|
||
both for government and industry as well as for the general public.
|
||
There are systems, for example, referred to as public access
|
||
systems, whose purpose is to disseminate information to the public
|
||
at large. The ability to read from these systems, therefore, has
|
||
been made widely available. With logical access control, the
|
||
crucial requirement of preserving the integrity of the information
|
||
being disseminated that is, protecting it against improper
|
||
modification, can be met while the information remains available
|
||
for all to view.
|
||
|
||
2.1.2 Other Restrictions
|
||
|
||
In addition to restrictions based on access mode, logical access
|
||
controls may deny or permit access based on a number of other
|
||
factors.
|
||
|
||
Access may be permitted only during particular hours of the day, or
|
||
only from particular terminals or network locations.
|
||
|
||
Access may be permitted or denied based on information content or
|
||
numerical thresholds. For example, an ATM machine may restrict
|
||
transfers of money between accounts to certain dollar limits. A
|
||
supervisor may be allowed to read salary or other personnel
|
||
information, but only for employees whom he or she supervises.
|
||
|
||
Access may be permitted selectively based on the type of service
|
||
requested. For example, users of computers on a network may be
|
||
permitted to exchange electronic mail but might not be allowed to
|
||
log in to each others' computers.
|
||
|
||
2.2 Relationship to Identification & Authentication
|
||
|
||
The subject of identification and authentication (I&A) is discussed
|
||
in more detail in Chapter 16. The basic relationship between I&A
|
||
and logical access control is included here because I&A forms the
|
||
basis for logical access control. I&A is the process by which
|
||
anyone attempting to interact with a system establishes his/her
|
||
identity to the system, for example, by use of a password or token.
|
||
The logical access control process then associates the appropriate
|
||
information and permissible forms of accesses with that identity.
|
||
This means that logical access control can only be as effective as
|
||
the I&A process employed for the system. If users tell one another
|
||
or write down passwords, both I&A and logical access control for
|
||
the system are compromised.
|
||
|
||
2.3 Relationship to Physical Access Control
|
||
|
||
Before logical access controls were widely available, physical
|
||
access control was the main means of protecting information on an
|
||
IT system. Access to information was controlled solely by
|
||
controlling access to the system, for example, by keeping the
|
||
system in a locked room or having a guard on duty to restrict
|
||
admittance to a facility. Once logged onto a system, though, a
|
||
user could generally access all of its data. In some environments,
|
||
this is not a problem. Physical access control may be sufficient
|
||
in environments where all users of a system need to access to all
|
||
of the information on it and need to perform all of the same types
|
||
of accesses in relation to it (read it, add to it, delete it, etc).
|
||
In environments where not all information resources on a system
|
||
should be equally available to all users, a more precise control is
|
||
necessary.
|
||
|
||
Logical access control can enhance the security provided by
|
||
physical access control by acting as an additional guard against
|
||
unauthorized access to or use of the system's resources. It can
|
||
also augment physical access control by providing added precision,
|
||
since different users are able to perform different functions. An
|
||
example would be a team of scientists who all need access to
|
||
up-to-the minute information in a field of research. Everyone in
|
||
the group could be given physical access to a system where the
|
||
information is being posted and the ability to read all
|
||
information. Senior scientists might also be able to add comments
|
||
on the information, while perhaps only the head of the research
|
||
effort might be able to add and delete files.
|
||
|
||
3 Administration of Logical Access Controls
|
||
|
||
Administration is the most complex and challenging aspect of
|
||
logical access control. Administration of logical access controls
|
||
involves implementing, monitoring, modifying, testing, and
|
||
terminating user accesses on the system and can be a demanding
|
||
task. Administration typically does not include making the actual
|
||
decisions as to who may have access to what and be given which
|
||
capabilities. Those decisions are usually the data owner's
|
||
responsibility, perhaps made in conjunction with management.
|
||
Decisions regarding accesses should be guided by organizational
|
||
policy, employee job descriptions and tasks, information
|
||
sensitivity, user "need to know" determinations, and many other
|
||
factors. Procedures and forms for the request and approval process
|
||
are also typically developed.
|
||
|
||
Regardless of how and at whose discretion the decisions on user
|
||
accesses are made, implementation and management are accomplished
|
||
through an administrative function. There are three basic
|
||
approaches to administration: centralized, decentralized, or a
|
||
combination. Each has relative advantages and disadvantages, and
|
||
which is best will depend upon the needs and complexity of the
|
||
particular organization.
|
||
|
||
3.1 Centralized Administration
|
||
|
||
Centralized administration means that one element (usually a group
|
||
in large organizations, an individual in small ones) is responsible
|
||
for configuring access controls so that users can access data and
|
||
perform the activities they need to. As users' information
|
||
processing needs change, their accesses can be modified only
|
||
through the central administration, usually after requests have
|
||
been approved through an established procedure and by the
|
||
appropriate authority.
|
||
|
||
The main advantage of centralized administration is that very
|
||
strict control over information can be maintained because the
|
||
ability to make changes resides with a very few persons. Each
|
||
user's account can be centrally monitored, and closing all accesses
|
||
for any user can be easily accomplished if that individual leaves
|
||
the organization. Consistent and uniform procedures and criteria
|
||
are usually not difficult to enforce, since relatively few
|
||
individuals oversee the process.
|
||
|
||
A major disadvantage, though, is that the change process can be
|
||
constant, due to employees being hired, terminated, and reassigned.
|
||
Constant changes can make the task of administration time-
|
||
consuming and costly in terms of staffing and equipment. Also,
|
||
when changes are needed quickly in order for users to complete
|
||
important tasks, going through central administration can be
|
||
time-consuming. Another problem that can arise is that permissions
|
||
for access can be too limited. This can interfere with users'
|
||
ability to get work done.
|
||
|
||
3.2 Decentralized Administration
|
||
|
||
In contrast to centralized administration, decentralized
|
||
administration means that access to information is controlled by
|
||
the owners or creators of the files, whoever or wherever those
|
||
individuals may be. An advantage of decentralized administration
|
||
is that control is in the hands of the individuals most accountable
|
||
for the information, most familiar with it, and best able to judge
|
||
who should be able to do what in relation to it. One disadvantage,
|
||
however, is that there may not be consistency among owners/creators
|
||
as to procedures and criteria for granting user accesses and
|
||
capabilities. Another is that when requests are not processed
|
||
centrally, it may be much more difficult to form a system-wide
|
||
composite view of all user accesses on the system at any given
|
||
time. Different data owners may inadvertently implement
|
||
combinations of accesses that introduce conflicts of interest or
|
||
that are in some other way not in the organization's best interest.
|
||
It may also be difficult to ensure that accesses are properly
|
||
terminated when an employee transfers within or leaves an
|
||
organization.
|
||
|
||
3.3 Hybrid Approach
|
||
|
||
In a hybrid approach, centralized control is exercised for some
|
||
information and decentralized is allowed for other information.
|
||
One typical arrangement is that central administration is
|
||
responsible for the broadest and most basic accesses, and the
|
||
owners/creators of files control types of accesses or changes in
|
||
users' abilities for the files under their control. For example,
|
||
when a new employee is hired into a department, a central
|
||
administrator might provide him with a set of accesses, perhaps
|
||
based on the functional element he is assigned to, his job
|
||
classification, and a specific task he was hired to work on. He
|
||
might have read-only access to an organizationwide bulletinboard
|
||
and to project status report files, but read and write privileges
|
||
to his department's weekly activities report. Over time, was
|
||
assigned to other projects, the project managers could modify his
|
||
capabilities on their respective files to include the ability to
|
||
write information in project files such as project status reports.
|
||
Also, if he left a particular project, the project manager could
|
||
close the employee's access to that file.
|
||
|
||
The main disadvantage to a hybrid approach is adequately defining
|
||
which accesses should be assignable locally and which centrally.
|
||
|
||
3.4 "Super Users"
|
||
|
||
Regardless of the type of administration chosen, the prevailing
|
||
needs of adequate user access plus maintenance of IT system
|
||
security need to be ensured. To contribute to meeting these needs,
|
||
all logical access control schemes allow for "super user"
|
||
capabilities for some individual or small group. This enables all
|
||
user and administrator activities to be changed or superseded
|
||
immediately when necessary. Consider the possibility that an
|
||
employee with very select accesses or capabilities for data in a
|
||
department is unexpectedly absent, due to a personal emergency or
|
||
illness. A super user could provide someone else the same accesses
|
||
and capabilities. Such emergency changes are usually governed by
|
||
policy and subject to close scrutiny, to ensure limited
|
||
implementation. Super users also typically have capabilities for
|
||
accessing and interacting with critical system programs, such as
|
||
the operating system, not accessible by others. This type of
|
||
access is necessary for maintenance and upgrades.
|
||
|
||
Because super users have sufficient privileges to bypass or modify
|
||
logical access controls, super user capabilities present a
|
||
potential vulnerability and must be guarded carefully.
|
||
Organizations should stringently minimize the number of individuals
|
||
who are authorized to act as super users. Furthermore, additional
|
||
I&A precautions, such as ensuring that super users' passwords are
|
||
robust and changed regularly, are important to minimize
|
||
opportunities for unauthorized individuals to gain super user
|
||
access to the system.
|
||
|
||
4 Integration
|
||
|
||
Uniform enforcement of logical access control in IT systems is made
|
||
more complicated because of the pervasiveness of networks and
|
||
applications. No longer is a single operating system responsible
|
||
for enforcing all access control decisions. Many applications or
|
||
utilities run by the operating system, such as Database Management
|
||
Systems (DBMS), also enforce logical access control, but at a
|
||
different level than the operating system. The degree to which the
|
||
logical access control performed by an operating system and that
|
||
performed by an application are integrated can vary significantly.
|
||
It is important in any event that they do not conflict.
|
||
|
||
Returning to the example of a DBMS will provide an illustration.
|
||
A DBMS manages a collection of information called a database. The
|
||
DBMS is responsible for controlling who can access the data in the
|
||
database. Databases are frequently stored in files, and operating
|
||
systems are responsible for enforcing protection on files. In
|
||
order for the DBMS logical access control to be effective, the
|
||
underlying operating system has to ensure that no user or program
|
||
other than the DBMS can access the database. This is a minimal,
|
||
but necessary, form of logical access control integration between
|
||
an operating system and a DBMS.
|
||
|
||
Integration issues also arise in a network environment. Instead of
|
||
coordinating access control decisions between the operating system
|
||
and applications on one host, coordination needs to take place
|
||
across a collection of hosts. It is generally considered desirable
|
||
for information to be protected in a uniform manner, regardless of
|
||
the particular location where it is stored. This requires
|
||
coordination among the administrators of the various hosts
|
||
comprising an organization's IT system and comparable access
|
||
control mechanisms on each host.
|
||
|
||
5 When Logical Access Control Is Not Necessary
|
||
|
||
While logical access control can greatly increase the flexibility
|
||
and ease with which information can be shared on an IT system, it
|
||
is not always necessary. As noted earlier, logical access controls
|
||
are best suited for situations where multiple users of a system
|
||
should not all have the same form of access to all of the
|
||
information on the system. A personal computer used solely by one
|
||
person, for example, does not necessarily need logical access
|
||
control, nor does a multi- user system in an environment where all
|
||
users should have access to all of the data and have all of the
|
||
same forms of accesses.
|
||
|
||
There are also environments where logical access control would be
|
||
appropriate and beneficial but may not be cost effective. Logical
|
||
access control might be quite useful, for example, to a small
|
||
company for tightly restricting access to personnel salary
|
||
information, if that data were stored on a multi-user system.
|
||
However, the costs of the technology and administration might be
|
||
higher than the cost and operational impact of keeping the salary
|
||
data on a separate, isolated system within a locked office.
|
||
|
||
A small group of users dedicated to single task often indicates
|
||
lack of a need for logical access control. Consider, for example,
|
||
a four person technical publications group that is drafting the
|
||
manual for a software product. They share a single IT system, but
|
||
logical access controls may not be utilized because all of the
|
||
users need to be able to access and interact with the manual as it
|
||
is being written. With such a small number of users, simply
|
||
scheduling assignments so that only one person is working on a
|
||
given section at a time might suffice to keep team members from
|
||
interfering with one another's work.
|
||
|
||
Even in circumstances where logical access control is not
|
||
necessary, it may still be beneficial for preventing inadvertent
|
||
errors or deletions. On the single-user PC noted above, for
|
||
example, restricting access to the operating system or to very
|
||
critical functions for purposes of ensuring integrity can be highly
|
||
desirable. Whether or not logical access control will be worth the
|
||
investment will depend on how much benefit will be derived from the
|
||
expenditure.
|
||
|
||
6 Mechanisms
|
||
|
||
Many mechanisms have been developed to provide logical access
|
||
control on IT systems, and they vary significantly in terms of
|
||
precision, sophistication, and cost. This section will provide an
|
||
overview of some of the methods. It should be noted that these
|
||
methods are not mutually exclusive and that many systems employ a
|
||
combination. Managers need to analyze their organization's
|
||
information processing needs and their information's sensitivity
|
||
and criticality in order to decide what is the optimal method or
|
||
combination of methods.
|
||
|
||
6.1 Passwords/Keys/Tokens
|
||
|
||
Passwords are probably the most common way of protecting
|
||
information on an IT system in that they are the most frequently
|
||
used means for users to be identified and authenticated on the
|
||
system. Thus, they are often the first line of protection afforded
|
||
an IT system. In addition, passwords are also used to protect data
|
||
and applications on many IT systems. Passwords are also used
|
||
frequently in PC applications as a means of logical access control.
|
||
For instance, an accounting application may require a password in
|
||
order to access certain financial data or invoke a sensitive
|
||
application.
|
||
|
||
The primary advantage of password-based logical access control is
|
||
that it is provided by a large variety of PC applications and thus
|
||
often does not have to be implemented as a new/separate feature on
|
||
an operating system. The drawbacks of this approach center on the
|
||
difficulty for users to manage even moderate numbers of passwords.
|
||
As discussed in the Identification and Authentication chapter, the
|
||
security of a password-based system is significantly diminished
|
||
when users write down their passwords. If users need to use more
|
||
than a few different passwords in the course of their work, there
|
||
will be a strong likelihood that they will write them down, thus
|
||
exposing the IT resources the passwords were meant to protect.
|
||
Also, if passwords are the same for several different applications,
|
||
then a user who learns the password for one can gain access to the
|
||
others.
|
||
|
||
Encryption can also be used as a means of logical access control.
|
||
Information of a certain type can be encrypted with a particular
|
||
key, and possession of that key would entitle a user to access that
|
||
information. Encrypting financial data from a previous year to
|
||
protect it from improper modification can be part of the process of
|
||
"closing the books." Tokens, as discussed in the Identification
|
||
and Authentication chapter, act as an alternative for passwords or
|
||
keys.
|
||
|
||
6.2 Permission Bits
|
||
|
||
Permission bits are now a widely available means of providing
|
||
logical access control on multi-user IT systems. In this scheme,
|
||
access rights to objects are based on the concepts of owner, group,
|
||
and world; for each of these, a set of access modes (typically
|
||
chosen from read, write, and execute) is specified. The owner of
|
||
an object, such as a file, is typically its creator, though in some
|
||
cases system or project administrators may be automatically
|
||
assigned ownership of all objects regardless of who created them.
|
||
The owner of an object can specify the allowed modes of access to
|
||
the object.
|
||
|
||
Each object is also associated with a named group of users. Users
|
||
who are members of the group associated with an object can be
|
||
granted modes of access distinct from non-members, who belong to
|
||
the rest of the "world" that includes all of the IT system's users.
|
||
Typically user groups are arranged according to department,
|
||
project, or other teaming relationships. For example, groups may
|
||
be established for members of the Personnel and Accounting
|
||
departments. Changing the membership of a group typically requires
|
||
action by a system administrator.
|
||
|
||
As an example of the use of permission bits, consider a file that
|
||
contains a personnel appraisal report. The permission bits could
|
||
be set by the report's owner such that it was readable and writable
|
||
by the report's owner, readable by the Personnel group, but neither
|
||
writable nor readable by the rest of the organization's users.
|
||
|
||
In a system employing permission bits, access to a file is at the
|
||
discretion of the file's owner. This method of access control can
|
||
be quite useful in a project-oriented environment and one in which
|
||
there are relatively few organizationwide restrictions for
|
||
information-sharing. There are some aspects of access restriction,
|
||
however, that cannot be represented using permission bits, such as
|
||
explicitly denying access to an individual that is a member of the
|
||
file's group. Additionally, as is the case with Access Control
|
||
Lists (discussed in the next section), permission bits can not
|
||
guarantee that the contents of a file will not be disclosed or
|
||
modified by an unauthorized user. For example, a member of a
|
||
file's group could copy the file and then set the copy's permission
|
||
bits to allow world read access.
|
||
|
||
6.3 Access Control Lists
|
||
|
||
Access Control Lists (ACLs) are similar to permission bits in that
|
||
they provide a form of logical access control that is at the
|
||
discretion of the information's owner. They do, however, provide
|
||
finer precision in control. An ACL is associated with each file
|
||
and specifies by name each user or group who can access the object
|
||
and the type of access they are permitted. By way of example,
|
||
consider a medical research experiment. The file containing
|
||
experimental results could have an ACL that permitted read and
|
||
write access by all the members of the research group. There could
|
||
then be an additional ACL that prohibited any access by one member
|
||
of the group who was responsible for conducting another experiment
|
||
whose results should not be influenced by the results of the first.
|
||
While the independence of the two experiments relies primarily on
|
||
the researchers refraining from exchanging information via
|
||
discussion, the ACL reduces the chance that independence will be
|
||
compromised by snooping or inadvertent browsing of files. ACLs,
|
||
however, like permission bits, can be defeated if an authorized
|
||
individual copies sensitive information to another object whose ACL
|
||
provides fewer access restrictions.
|
||
|
||
ACLs provide a fine grained form of logical access control that can
|
||
be useful for complex information sharing situations. The
|
||
flexibility provided by ACLs also makes them more of a challenge to
|
||
manage. The rules for determining access in the face of apparently
|
||
conflicting ACL entries are not uniform across all implementations
|
||
and can be confusing to users. If such a system is introduced, it
|
||
should be coupled with training to ensure that it is used
|
||
correctly.
|
||
|
||
6.4 Labels
|
||
|
||
For IT systems with stringent security requirements, such as those
|
||
associated with national security, labels are often used as the
|
||
basis for logical access control. Systems employing labels
|
||
associate an unchangeable label with each file that indicates its
|
||
sensitivity. Similarly, user sessions are assigned labels that
|
||
designate the degree to which access to information at different
|
||
sensitivities is granted. In addition, users are authorized to
|
||
initiate sessions with specific labels only. For example, a file
|
||
bearing the label Organization Proprietary Information would not be
|
||
accessible (readable) except during user sessions with the
|
||
corresponding label. Moreover, only a restricted set of users
|
||
would be able to initiate such sessions; other users would be
|
||
allowed to initiate sessions at lower sensitivity levels only, and
|
||
would consequently have access only to less sensitive information.
|
||
|
||
Labels are a robust form of logical access control. Unlike
|
||
permission bits or access control lists, labels cannot ordinarily
|
||
(e.g., accidentally) be changed, and labels for new files are
|
||
automatically determined by the access control mechanism. By
|
||
removing users' ability to arbitrarily designate the accessibility
|
||
of files they own, opportunities for certain kinds of human errors
|
||
and malicious software problems are eliminated. In the example
|
||
above, it would not be possible routinely to copy Organization
|
||
Proprietary Information into a file with a less sensitive label.
|
||
This prevents inappropriate "leakage," but it may also interfere
|
||
with legitimate extraction of less sensitive information.
|
||
Label-based access controls may also be used to prevent low
|
||
integrity information from leaking into and contaminating high
|
||
integrity information.
|
||
|
||
Labels are well-suited for consistently and uniformly enforcing
|
||
organization-wide access restrictions, sometimes called system
|
||
security policies. For this reason, label-based controls can
|
||
provide a level of protection not found in other approaches.
|
||
Presently, labels are in relatively limited use. As more operating
|
||
systems that provide labels become available, though, access
|
||
controls based on labels may become more familiar and attractive to
|
||
larger user populations.
|
||
|
||
6.5 Roles
|
||
|
||
A role is a job assignment or function. Examples of roles include
|
||
data entry clerk, purchase officer, project leader, programmer,
|
||
technical editor, etc. Logical access controls can support user
|
||
roles on the IT resource. This means allowing access rights to be
|
||
grouped by role name, and restricting use of those access rights to
|
||
individuals authorized to assume the associated role. An
|
||
individual may be authorized for more than one role, but may be
|
||
required to act in a single role at a time. Changing roles may
|
||
require logging out and then in again, or entry of a special
|
||
role-changing command.
|
||
|
||
Many IT systems already support a small number of special purpose
|
||
roles, such as System Administrator or Operator. An individual who
|
||
is logged on in the role of a System Administrator can, for
|
||
example, perform operations that would be denied to the same
|
||
individual acting in the role of an ordinary user. Recently, the
|
||
use of roles has been expanded beyond system tasks to application
|
||
oriented activities. For example, in a company there could be an
|
||
Order Taking Role. A user with this role would be able to collect
|
||
and enter customer billing information, check on availability of
|
||
particular items, request shipment of items, and issue invoices.
|
||
In addition, there could be an Accounts Receivable Role which would
|
||
receive payments and credit them to particular invoices. A third,
|
||
Shipping Role, could then be responsible for shipping products and
|
||
updating the inventory. To provide additional security,
|
||
constraints could be imposed such that a single individual user
|
||
would never be simultaneously authorized to assume all three roles.
|
||
Constraints of this kind are sometimes referred to as separation of
|
||
duty constraints.
|
||
|
||
The use of roles and the corresponding concept of a business
|
||
transaction can be a very effective way of providing logical access
|
||
control. The process of defining roles and their relationships
|
||
should be based on a thorough analysis of the way in which an
|
||
organization operates and should include input from a wide spectrum
|
||
of users in an organization. Standardization of role-based access
|
||
control systems, as is being done for some database management
|
||
systems, will make the adoption of role-based logical access
|
||
control easier. The user group mechanism described in the
|
||
discussion of permission bits can in some cases support roles, but
|
||
at present, more explicit support for application oriented roles in
|
||
commercial operating systems is limited.
|
||
|
||
6.6 Constrained User Interfaces
|
||
|
||
The principle underlying constrained user interfaces is that a user
|
||
should be able to access system functions for which he/she is
|
||
specifically authorized. Menu driven systems are a common paradigm
|
||
for constrained user interfaces, the implementation being that
|
||
different users are provided different menus for the same system.
|
||
A user is not given menu options for unauthorized operations and so
|
||
has no means by which to invoke them. A common example of a
|
||
constrained user interface is an Automated Teller Machine (ATM).
|
||
An ATM presents a user with a limited list of permitted operations.
|
||
The user is prevented from escaping to any other system interface
|
||
and so is prevented from bypassing the logical access controls.
|
||
|
||
With an ATM machine the menu options permit a user to undertake a
|
||
number of transactions, e.g., deposit, withdrawal, transfer. There
|
||
is a hierarchy of menus that support these transactions. In other
|
||
IT systems, a menu-based constrained user interface can similarly
|
||
provide a hierarchy of menus to support arbitrarily complex
|
||
transactions.
|
||
|
||
As is the case with roles, constrained user interfaces can provide
|
||
a form of logical access control that closely models the way in
|
||
which an organization operates. The use of menus also makes this
|
||
an approach that will be easy for non-technical users to
|
||
understand. The primary drawback to this approach is the cost
|
||
associated with tailoring such a system to an organization.
|
||
|
||
7 Interdependencies
|
||
|
||
7.1 Policy
|
||
|
||
The most fundamental interdependency of logical access control is
|
||
with policy. Control is performed by the system, but the decisions
|
||
as to accesses are made and enforced at the discretion of
|
||
individuals who must act in concert with the organization's IT
|
||
security policy. Policy should specify who authorizes access to
|
||
what kinds of information and provide the criteria for making
|
||
access control decisions.
|
||
|
||
7.2 Audit
|
||
|
||
It is sometimes not possible to make logical access control as
|
||
precise, or fine-grained, as would be ideal for an organization.
|
||
Given the difficulty of configuring logical access controls in a
|
||
complex IT system, there are may be occasions when a user is
|
||
inadvertently allowed access to resources he should not have. In
|
||
some cases, users will be granted access in case they need to act
|
||
in someone's place. In addition, the policy or rules governing
|
||
access may change over time, and there is a window of time between
|
||
when the policy changes and when the logical access control system
|
||
is updated. The net result in these cases is that it is possible
|
||
for users to abuse access permissions they have. Automated
|
||
auditing provides a source of information that can be used to
|
||
identify users who have abused their access permissions. Audit
|
||
analysis can perform such functions as checking accesses to very
|
||
sensitive or critical resources, the membership of very powerful
|
||
groups, verifying the consistency of rights with roles, and
|
||
generating access violation reports.
|
||
|
||
7.3 Identification & Authentication
|
||
|
||
In most logical access control scenarios, the identity of the user
|
||
must be established before an access control decision can be made.
|
||
This is especially true with the permission bit and ACL methods.
|
||
Establishing the identity of users is a necessary prerequisite for
|
||
enforcing logical access control.
|
||
|
||
7.4 Data Categorization
|
||
|
||
Just as the identity of users plays a role in determining access,
|
||
so does a characterization of the information being protected. At
|
||
one end of the spectrum, labels are a direct representation of a
|
||
data categorization and are the basis of a logical access control
|
||
method. Even in the other access control methods discussed above,
|
||
data categorization plays a role. For example, recall the medical
|
||
experiment in which the results had a specific categorization that
|
||
required additional access protection.
|
||
|
||
7.5 Assurance
|
||
|
||
By its very nature, logical access control is normally a critical
|
||
component of the security provided by a system. If an IT system's
|
||
logical access control does not function correctly, is not
|
||
configured properly, or is not effective for the application,
|
||
serious harm to the organization could result. Even in situations
|
||
in which there are limited resources to provide assurance for a
|
||
system, it is important to that they be directed in part towards
|
||
assuring the proper functioning of the logical access control
|
||
system.
|
||
|
||
|
||
8 Costs
|
||
|
||
Incorporating logical access control into an IT system involves
|
||
both the purchase or utilization of access control mechanisms as
|
||
well as a change in behavior on the part of users.
|
||
|
||
8.1 Direct Costs
|
||
|
||
Among the direct costs associated with the use of logical access
|
||
control methods are the purchase and support of hardware, operating
|
||
systems and applications that provide the controls, and any add-on
|
||
security packages necessary or desirable. The most significant
|
||
personnel cost in relation to logical access control is usually for
|
||
administration. Most multi-user operating systems provide some
|
||
protection mechanism such as permission bits or ACLs, so there is
|
||
less acquisition cost associated with these. Support for
|
||
label-based access control is available in a limited number of
|
||
commercial products, but at greater cost and with less selection
|
||
than for permission bits or ACLs. Role-based systems are becoming
|
||
more available with time, but there is the cost of customizing
|
||
these systems for particular organizational purposes. Training
|
||
users to understand and use a logical access control system is a
|
||
very necessary cost. If users are not comfortable in using an
|
||
access control system they will attempt to configure it so that it
|
||
places few or no restrictions. This may provide the organization
|
||
with false confidence in the security ofits IT resources, resulting
|
||
in a security situation worse than if the protection mechanisms had
|
||
not been provided in the first place.
|
||
|
||
8.2 Indirect Costs
|
||
|
||
The primary indirect cost associated with introducing logical
|
||
access controls into an IT system is the effect on user
|
||
productivity. There are two primary dimensions to this situation.
|
||
The first is the additional overhead individual users have in
|
||
properly determining (when it is under their control) the
|
||
protection attributes of information. This determination requires
|
||
both an understanding of the relevant policy governing the
|
||
treatment of the information and an understanding of the technology
|
||
supporting the logical access control. The other dimension centers
|
||
on the situation of users not being able to access information
|
||
necessary to their jobs because the permissions were incorrectly
|
||
assigned. While infrequent, this situation is familiar to most
|
||
organizations that put strong emphasis on logical access control.
|
||
|
||
It is important to understand, though, that through the
|
||
proliferation of PCs, the decreased costs of computers, and
|
||
increased use of networking, the amount and variety of information
|
||
processed on shared IT systems is increasing at a rapid rate.
|
||
Without the assurance provided by logical access control that
|
||
information will be protected appropriately, there will be a
|
||
reluctance to share that information in the most effective manner.
|
||
The result would then be a decrease in the usefulness of an IT
|
||
system. SIDEBAR NOTES:
|
||
|
||
(1) Sec 1 para 3: Logical Access Controls are a means of
|
||
controlling the types of information different users of the same
|
||
system may access.
|
||
|
||
(2) Sec 2.1.1 para 1: Logical Access Controls manage interactions
|
||
among different users, different types of information, and
|
||
different types of access modes.
|
||
|
||
(3) Sec 2.2: Identification & Authentication, covered in Chapter
|
||
16, forms the basis for logical access control.
|
||
|
||
(4) Sec 2.3 para 2: Logical access control can augment physical
|
||
access control.
|
||
|
||
(5) Sec 3 para 1: Administration is one of the most challenging
|
||
aspects of logical access control.
|
||
|
||
(6) Sec 3.1 para 1: Central administration means that one element
|
||
in the organization is responsible for configuring all user access
|
||
controls.
|
||
|
||
(7) Sec 3.2: Decentralized administration means that accesses are
|
||
controlled by the owners or creators of files.
|
||
|
||
(8) Sec 3.4: "Super users" can change or supersede all user and
|
||
administrator activities, when necessary, but such privileges must
|
||
be monitored stringently.
|
||
|
||
(9) Sec. 5, para 2: In some environments, although logical access
|
||
controls would be beneficial, the costs might be prohibitive.
|
||
|
||
(10) Sec. 6: A variety of logical access control mechanisms are
|
||
available, and they vary in terms of precision, sophistication, and
|
||
cost.
|
||
|
||
(11) Sec. 6.3, para 1: Permission bits and Access Control Lists
|
||
provide logical access control that is at the discretion of the
|
||
information's owner, but ACLSs provide finer precision.
|
||
|
||
(12) Sec. 6.5, para 1: Logical access control through roles means
|
||
that rights are grouped by role name and access rights are
|
||
restricted to persons authorized to assume the associated role. REFERENCES:
|
||
|
||
Caelli, William, et al. Information Security Handbook. Stockton
|
||
Press, 1991, New York, NY.
|
||
|
||
Abrams, M.D., et al. A Generalized Framework for Access Control:
|
||
an Informal Description. Mitre Corporation: McLean, VA, 1990.
|
||
|
||
Baldwin, R.W. "Naming and Grouping Privileges to Simplify Security
|
||
Management in Large Databases." In Proc. 1990 IEEE Symposium on
|
||
Security and Privacy, pages 116-132, Oakland, CA, May 1990.
|
||
|
||
Dinkel, Charles. Secure Data Network System Access Control
|
||
Documents. National Institute of Standards and Technology:
|
||
Gaithersberg, MD, 1990.
|
||
|
||
Thomsen, D.J. "Role-based Application Design and Enforcement."
|
||
In Proc. of the Fourth IFIP Workshop on Database Security,
|
||
Halifax, England, September 1990.
|
||
|
||
Pfleeger, Charles P. Security In Computing. Prentice-Hall, Inc.:
|
||
Englewood Cliffs, NJ, 1989.
|
||
|
||
Gasser, Morrie. Building a Secure Computer System. Van Nostrand
|
||
Reinhold Company, Inc.: New York, NY, 1988.
|
||
|
||
Sandhu, R. "Transaction Control Expressions for Separation of
|
||
Duty." In Fourth Annual Computer Security Applications Conference,
|
||
pages 282-286, Orlando, FL, December 1988.
|
||
|
||
Clark,D. and D. Wilson. "A Comparison of Commercial and Military
|
||
Computer Security Policies." In Proc. 1987 IEEE Symposium on
|
||
Security and Privacy, pages 184-194, Oakland, CA, April 1987.
|
||
|
||
Bach, M.J. The Design of the Unix Operating System. Prentice-Hall,
|
||
Englewood Cliffs, NJ, 1986.
|
||
|
||
Boebert, W. E. and R. Y. Kain. "A Practical Alternative to
|
||
Hierarchical Integrity Policies." In Proc. 8th National Computer
|
||
Security Conference, pages 18-27, Gaithersburg, MD, September 1985.
|
||
|
||
Landwehr, C., C. Heitmeyer and J. McLean. "A Security Model for
|
||
Military Message Systems." In ACM Transactions on Computer Systems,
|
||
Vol 2, No.3, August 1984.
|
||
|
||
"Guideline on User Authentication Techniques for Computer Network
|
||
Access Control," U.S. Department of Commerce (NIST), FIPS
|
||
Publication 83, September 1980.
|
||
|
||
"Guidelines for Security of Computer Applications," U.S. Department
|
||
of Commerce (NIST), FIPS Publication 73, June 1980.22
|
||
|
||
|