The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/hacking/general/hk_acces.txt

Text File | 2003-06-11 | 42.8 KB | 852 lines

* * * * * * * * * * * * *  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 [e-mail]
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