ASSESSING FEDERAL AND COMMERCIAL
                   INFORMATION SECURITY NEEDS






                           NISTIR 4976
                          November 1992








      David F. Ferraiolo                  Dennis M. Gilbert





                         Nickilyn Lynch






                   Computer Security Division
                   Computer Systems Laboratory
         National Institute of Standards and Technology
                        Gaithersburg, MD

                            ABSTRACT


In a cooperative effort with government and industry, the National
Institute of Standards and Technology (NIST) conducted a study to
assess the current and future information technology (IT) security
needs of the commercial, civil, and military sectors.

The primary objectives of the study were to:

     o    determine a basic set of information protection policies
          and control objectives that pertain to the secure
          processing needs of organizations within all sectors; and
          

     o    identify protection requirements and technical approaches
          that are used, desired or sought so they can be
          considered for future federal standards and guidelines.

The findings of this study address the basic security needs of IT
product users, including system developers, end users,
administrators, and evaluators.  Security needs have been
identified based on actual existing and well-understood security
organizational practices.

                        EXECUTIVE SUMMARY

The federal government and private industry rely heavily on
information processing systems to meet their individual
operational, financial, and information technology requirements. 
Corruption, unauthorized disclosure, or theft of resources have the
potential to disrupt operations and could have financial, legal,
human safety, personal privacy, and public confidence impact. 

Each organization interviewed exhibited unique security
characteristics described in terms of the organization's missions
and goals.  Security needs were further characterized from system
to system within an organization.

System and organizational security requirements were found to be
based on a higher set of environmental and policy factors and
conditions.  Computer security technology is applied uniquely in
each situation even though there are common concerns.

Because each organization has unique security needs, security
products have been applied on a case by case basis to meet
individual security threats and concerns.  Products should be
flexible enough to serve a broad spectrum of security needs at the
operating system level, the application level, the organizational
level, and the site level.  Organizational security requirements
also change over time and cannot be totally specified at the time
of product acquisition.  

For organizations that process unclassified sensitive information,
the availability of a greater variety of trusted products that go
beyond C2 in terms of functionality and flexibility is needed. 
There is a demand to address data integrity in a more direct and
user friendly manner.  Vendors should consider new mechanisms that
directly address discretionary and non-discretionary controls, such
as role-based access controls, separation of duties, separation of
transactions, and user-oriented least privilege.

Most organizations felt security standards should include a wide
range of assurances including a "generally accepted commercial
practice" level.  This new level should minimize the cost of
developing new systems or retro-fitting new security functionality
in existing systems.  

Nearly all of those interviewed expressed the desire to have an
independent third party give a "stamp of approval" with regard to
the trustworthiness of the systems they were buying.  However, the
current evaluation and certification process (i.e., with respect to
a TCSEC class) was not perceived by users as meeting their needs
for a variety of reasons.  

Those interviewed felt that security standards have not emerged 
that will allow integrating security across a multi-vendor
environment.  A system should provide a single user view of
security services across a wide range of operating systems. 
Security features should inter-operate with other security services
on both local and remote machines, without the need to train users
in new security products.  Security technology must support users
working effectively together, sharing information, resources and
network applications from whatever desktop device they choose
within their authority, while providing a common set of security
services.  

This study has attempted to identify basic security needs of
information technology product users, administrators, developers,
and evaluators based on actual organizational practices.  Although
the findings of this study should not be considered conclusive, it
is hoped that they will be considered in the development of future
protection requirements, standards, guidelines and evaluation
programs.    
                        TABLE OF CONTENTS

                                                              PAGE

ABSTRACT             . . . . . . . . . . . . . . . . . . . . . .i

EXECUTIVE SUMMARY    . . . . . . . . . . . . . . . . . . . . . ii

LIST OF APPENDICES   . . . . . . . . . . . . . . . . . . . . . .v

1   INTRODUCTION 

    1.1  Development of Security Technology. . . . . . . . . .1-1
    1.2  Notions of Trust. . . . . . . . . . . . . . . . . . .1-2
    1.3  Conventions Used in this Document . . . . . . . . . .1-2
    1.4  Document Overview . . . . . . . . . . . . . . . . . .1-2

2   PROJECT APPROACH

    2.1  Overview    . . . . . . . . . . . . . . . . . . . . .2-1
    2.2  Profile of the Organizations  . . . . . . . . . . . .2-1
    2.3  Topics Covered. . . . . . . . . . . . . . . . . . . .2-2

3   FINDINGS

    3.1  Basis for Protection. . . . . . . . . . . . . . . . .3-1
         3.1.1  Driving Requirements . . . . . . . . . . . . .3-1
         3.1.2  Types of Information . . . . . . . . . . . . .3-3
    3.2  Sector Protection Requirements. . . . . . . . . . . .3-3
         3.2.1  Common Notions of Protection . . . . . . . . .3-3
         3.2.2  Distinguishing Protection Characteristics. . .3-5
    3.3  Organizational Security Approach. . . . . . . . . . .3-6
         3.3.1  Identification and Authentication. . . . . . .3-6
         3.3.2  Access Control . . . . . . . . . . . . . . . .3-7
              3.3.2.1  Discretionary Access Control  . . . . .3-7
              3.3.2.2  Role-Based Controls . . . . . . . . . .3-8
              3.3.2.3  Separation of Transactions. . . . . . .3-9
              3.3.2.4  Separation of Related Duties. . . . . 3-10
              3.3.2.5  Principle of Least Privilege. . . . . 3-10
              3.3.2.6  Label-Based Mandatory Access
                         Controls  . . . . . . . . . . . . . 3-11
              3.3.2.7  Object-Label Association. . . . . . . 3-12
         3.3.3  User Accountability. . . . . . . . . . . . . 3-12
    3.4  Electronic Data Interchange (EDI) . . . . . . . . . 3-13
    3.5  Assurance and Quality . . . . . . . . . . . . . . . 3-13
    3.6  Evaluation        . . . . . . . . . . . . . . . . . 3-14
    3.7  Current Criteria Not Keeping Pace . . . . . . . . . 3-15
    3.8  Need for Security in Open Systems . . . . . . . . . 3-16
    3.9  Owner-Custodian Relations . . . . . . . . . . . . . 3-16
    3.10 Security Policies and Environments Can 
              Change Over Time . . . . . . . . . . . . . . . 3-17                                                             PAGE

4   CONCLUSIONS

    4.1  Minimum Security Requirements . . . . . . . . . . . .4-1
         4.1.1  Baseline Capabilities. . . . . . . . . . . . .4-1
    4.2  Computer Security Features Enabled by Default . . . .4-2
    4.3  Assurance   . . . . . . . . . . . . . . . . . . . . .4-2
    4.4  Evaluation  . . . . . . . . . . . . . . . . . . . . .4-2
    4.5  Administration  . . . . . . . . . . . . . . . . . . .4-3
         4.5.1  Password Management. . . . . . . . . . . . . .4-3
         4.5.2  EDI Capabilities . . . . . . . . . . . . . . .4-3
    4.6  Add-On Packages   . . . . . . . . . . . . . . . . . .4-3
    4.7  Current Criteria. . . . . . . . . . . . . . . . . . .4-4
    4.8  Security Standards for Multi-Vendor Systems . . . . .4-4
    4.9  Closing Thoughts. . . . . . . . . . . . . . . . . . .4-5



LIST OF APPENDICES

APPENDIX A:  LIST OF ORGANIZATIONS . . . . . . . . . APPENDIX A-1

APPENDIX B:  SAMPLING OF JOB TITLES. . . . . . . . . APPENDIX B-1

APPENDIX C:  SAMPLE QUESTIONS. . . . . . . . . . . . APPENDIX C-1

APPENDIX D:  RELATED NIST ACTIVITIES AND SOURCES
              OF INFORMATION . . . . . . . . . . . . APPENDIX D-1
1.   INTRODUCTION

In a cooperative effort with government and industry, the National
Institute of Standards and Technology (NIST) conducted a study to assess
the current and future security needs of the commercial, civil, and
military sectors.

The primary objectives of the study were to:

     o     determine a basic set of information protection policies, and
           control objectives that pertain to the secure processing needs
           within all sectors; and 

     o     identify protection requirements and technical approaches that
           are used, desired or sought so they can be considered for
           future federal standards and guidelines.

The findings of this study address the basic security needs of
information technology (IT) product users.  This includes application
developers, end users, and administrators.  As such, security
requirements can be identified based on actual existing and well
understood security organizational practices.

The NIST study team used a set of topics as guidance when meeting with
the various organizations.  The topics are discussed in Section 2. 
Appendix C contains a sample of the questions asked and the issues
explored during the interviews.

1.1  Development of Security Technology

The U.S. government has been involved in developing security technology
for computer and communications security for some time. 

Although advances have been great, it is generally perceived that the
current set of security technology has, to some extent, failed to address
the needs of all.  This is especially true of organizations outside the
Department of Defense (DoD).

The current set of security criteria, criteria interpretation, and
guidelines has grown out of research and development efforts of the DoD
over a period of twenty plus years.  There exists one U.S. computer
security standard, the Trusted Computer System Evaluation Criteria
(TCSEC).  It consists of security features and assurances, exclusively
based on DoD security policy.  The TCSEC concentrates particularly on
those policies created to prevent the unauthorized disclosure of
classified information.  The result is a collection of security products
built to TCSEC requirements that do not fully address unclassified
sensitive security issues.  This study indicates that these security
products can be useful in providing computer security in non-DoD sectors,
but they provide a partial solution at best and are used in lieu of a
more appropriate set of controls.

Until recently, the government has paid little comparable attention to
researching and addressing IT security needs of the government and
commercial sectors that do not process classified information.  During
the past few years, however, managers and security officers of commercial
and government organizations have paid increasing attention to IT
security needs. 

To help address these protection issues, NIST publishes standards and
guidelines for the unclassified community.  The Computer Security Act of
1987 (Public Law 100-235) assigned NIST the responsibility of developing
security standards and guidelines for sensitive (non-classified) federal
computer systems.  The law gave NIST responsibility for developing
validation procedures for cost-effective security and privacy of
sensitive information in federal computer systems.  The law also gave
NIST the authority to perform research, conduct studies, and devise
techniques appropriate to a computer system's security and privacy.  To
gain a better understanding of the needs of our constituents, NIST
conducted this study.  


1.2  Notions of Trust

As commercial and civil sectors have become increasingly dependent on
complex and interconnected computer systems, trust in these systems has
become an increasing concern.  Examples of trust issues include:
maintaining the privacy of employees, ensuring the correctness and
accuracy of medical and credit records, and protecting national secrets
from unauthorized disclosure or modification.  The term "trusted systems"
refers to systems supporting substantially increased safety, reliability,
and, in particular, security mechanisms.  "Security" refers to protection
against unwanted disclosure, modification, or destruction of data. 

To be effective, however, security must also address safeguarding system
security features themselves.  Security, safety, and reliability are
elements of system "trustworthiness" - a level of confidence that a
system will do what it is expected to do. 


1.3  Conventions Used in this Document

"Federal government" refers to all government agencies, military and non-
military.  The "civil sector" refers to the civil "federal government"
(and in some instances "state government").  DoD and military are used
interchangeably, unless otherwise stated, and cover both classified and
sensitive (non-classified) activities.  


1.4  Document Overview

The sections following this introduction detail the study project.  

Section 2, Project Approach, gives an overview of the project, discusses
the project approach, profiles the organizations that were interviewed,
and reviews the topics covered in the interview.  

Sections 3, Findings, presents the study findings in terms of required
protection policies, security, feature needs, security assurance needs,
and product and application assessment. 

Section 4, Conclusions, contains the study conclusions. 

Appendices A - D present information not covered in the main body of the
paper, including sample questions, study participants, and additional
resources.
2.   PROJECT APPROACH

2.1  Overview

The NIST study team conducted in-person discussions with key persons in
28 commercial and civil organizations between March and June 1991. 
Organizations were represented by 1 to 12 people.  The participants came
from a wide variety of perspectives, environments, applications, and
system architectures.  They included users and systems management,
systems operations, computer security, and information resources
management personnel.  The study especially sought to reach people with
major organizational mission responsibilities, who must react to breaches
in information accuracy, availability, or privacy.  

An invitational workshop was held at the beginning of the project. 
Numerous discussions at the workshop provided valuable input and
direction.  Participation in the study was strictly voluntary.  The study
was not part of any audit or Computer Security Act security and privacy
plans review effort.

In order to encourage candor and to respect individual and organizational
privacy, details are not attributed to individuals or organizations in
this report without permission.  NIST sent copies of the report to study
participants for comment.


2.2  Profile of the Organizations 

The NIST study team met with 28 organizations - 17 federal agencies, 10
commercial organizations, and 1 state government.  Fourteen of the
organizations were in the Washington/Baltimore area and 14 were outside
of this area, and included Arizona, California, New Jersey, New York,
Pennsylvania, and Texas.  Companies representing energy, financial,
communications, insurance, manufacturing, computers, and service were
included.  Of the federal organizations, both the executive and judicial
branches were represented.  Activities included law enforcement, benefits
delivery, nuclear/energy, space exploration, defense, tax system,
information collection and dissemination, air traffic, and service center
operations.  Contractors participated in a number of the federal agency
meetings.  State functions represented included justice, transportation,
lottery, franchise tax, health and welfare, motor vehicles, controllers
office, and data center operations.

Appendix A provides a detailed list of the organizations.  A sampling of
job titles of the approximately 120 people interviewed can be found in
Appendix B.


2.3  Topics Covered

The following topics were addressed at each meeting:

     o     Key, significant information protection requirements - those
           elements that were the driving force in establishing the
           protection requirements, e.g. legal or regulatory, business
           practices, organization policy regarding customer and employee
           privacy, fear of litigation, etc.

     o     Organizational information processing environment - in general
           terms, such things as centralization vs. distribution of
           resources, management and administration, and issues regarding
           networking, connectivity, interoperability, and homogeneity.

     o     Organizational information protection objectives - the
           concerns regarding system trustworthiness including
           confidentiality, integrity, availability, safety, and
           reliability.

     o     Important information protection features and assurances -
           what type of computer security products, features, and
           mechanisms were used, desired, or sought?  This included
           discussion of the organization's baseline protections
           including design, development, and operational controls for
           providing confidence that the security features exist and work
           as intended.

     o     Needed confidence level in protection mechanisms - the degree
           of confidence in the protection mechanisms required by the
           organization.

     o     Methods to achieve confidence - what methods the organization
           uses, would like to use, or have available to achieve the
           desired confidence.

     o     Addressing evolving protection requirements of the 1990s -how
           the organization sees its situation and environment changing
           over the next few years and how that impacts its protection
           requirements.

Each organization was also invited to make additional comments or ask
additional questions.  Because of the free-form "discovery" nature of the
meetings not all of the topics were covered in the same level of detail
at every meeting. 

The questions used at each meeting are in Appendix C.  They served as
background as well as guidance to the team during the meetings with the
organizations.  The questions represent the types of information sought,
but were not necessarily asked during the sessions.  
3.   FINDINGS

Each organization interviewed exhibited unique security characteristics. 
Security was often described in terms of the organization's missions and
goals.  Security objectives were also different from system to system
within an organization.  For example, the requirements (security features
and types of assurance) for the financial and administrative system
within a hospital were drastically different from those for the computer
resources devoted to the clinical treatment of patients within that
hospital.

System and organizational security requirements are based on a higher set
of environmental and policy factors and conditions.  These factors and
conditions are referred to in this document as "basis for protection" and
discussed below.

At the system level, representatives from each organization generally
described their security requirements in terms of the following control
objectives:

     o     identification and authentication, 
     o     access control, and 
     o     user accountability.  

The emphasis and specifics of each area were largely different.  This was
particularly true for the control objective access control.  The TCSEC C2
class was often cited as a practical baseline for referencing applicable
requirements.  While C2 does provide many baseline requirements, it falls
short in both security features, (e.g., password complexity, resource
access control, and system access control) and assurances.  

In addition, the need for a variety of access controls was noted.  The
TCSEC label-based mandatory policy was commonly viewed as inappropriate
for the protection of commercial and civil sector data.  

Specifics of these computer security approaches are described in
Subsection 3.3, Organizational Security Approach.  


3.1  Basis for Protection

Significant and broadly sweeping security requirements were found to
exist within all organizations.  Such requirements included protecting
the integrity, availability, and confidentiality of key software systems,
databases, and data networks.  

3.1.1      Driving Requirements

Both federal government and corporations were found to rely heavily on
information processing systems to meet their individual operational,
financial, and information technology requirements.  The corruption,
unauthorized disclosure, or theft of resources could disrupt operations
and have immediate serious financial, legal, human safety, personal
privacy and public confidence impacts.  Computers must also be protected
against misuse by an individual committing such acts as data interchange
fraud, harassment or personal terrorism, and pornography.

Organizations processing and storing classified information focus on
preventing unauthorized observation/disclosure of data as the basis for
protection.  For these organizations, the unauthorized flow of
information from a high level to a low level was the principal concern.

For the federal government, requirements exist for protecting the privacy
of personal information.  These requirements come from the Privacy Act of
1974.  The Act provides privacy safeguards by requiring federal agencies
to protect the personal information it collects, maintains, uses, and
disseminates.  Additionally, when an agency contracts for services, the
contractor must protect the information subject to the Act's
requirements. 

Protecting the privacy of personal information was also relevant to
commercial sector organizations.  The need to protect sensitive data from
unauthorized access resulted from operational environment (including
threats) and data sensitivity factors.  These factors include legal
obligations and self-imposed requirements including confidentiality of
salary, performance, and health (mental, drug, and alcohol related
illness), as well as data involving legal incidents.  

Privacy issues were perceived as particularly critical in medical and
insurance applications.  Educational, employment and personnel, banking
and financial institutions, and credit bureaus also acknowledged
protecting the privacy of individuals as a high organizational priority. 

The need to preserve customer, insurer, and stockholder confidence was
also cited as a basic security objective for many organizations.  The
vice president of a major bank described the need to "provide a good
service at a reasonable cost" as an important capability of most savings
and financial institutions but described the need for "maintaining a
general sense of customer confidence" as critical.  

The basis for protection takes on a specific meaning for those
organizations, such as banks, credit companies, and insurance companies,
concerned with preventing unauthorized distribution of financial assets. 
These businesses are subject to federal regulatory requirements of the
Federal Trade Commission and the Federal Reserve Board under the Fair
Credit Billing Act, Equal Credit Opportunity Act, and Truth-in-Lending
Act.

Security issues can also be unique to a specific industry.  Of all the
organizations interviewed, only PACBELL and BELLCORE were concerned with
preventing unauthorized use of long-distance telephone circuits.  Only
hospitals and those who develop hospital systems were concerned with
preventing unauthorized distribution of prescription drugs. 

Professional standards, health and safety, prevention of embezzlement,
good business practices, and profit were also stated as key factors in an
organization's basis for protection.

3.1.2      Types of Information 

In general, the interviews focused on the protection of information that
a user may entrust to a system.  During the course of the interviews, two
other types of information were noted as requiring protection.  These two
types were:
 
     o     system-operating information (software, tables, etc.); and

     o     system-generated information (user activity data, general
           traffic data, audit information, etc.).

Each type of information was found to have its own security policy
requirements.  In the case of system-operating information and system-
generated information, the system itself was perceived as the owner and
primary custodian of the information.  The system owner/operator sets the
policy requirements for protecting information.  The owner of system-
generated information is the system owner/administrator, who also sets
its policy.  


3.2  Sector Protection Requirements

Some similarities and differences of security needs within the
commercial, civil, and military sectors were noted.  Security objectives
were specified and governed by many independent levels of authority, from
general legislation, to organizational rules of operation, to rights and
needs of the individual.  Standards of due care were different in each
environment, just as controlling laws differ in each state.  Each
organization had its own objectives and rules for computer access
privileges.  The U.S. DoD confidentiality policy was unique in applying
a single set of security services across a large number of applications. 

3.2.1      Common Notions of Protection 

"Conventional wisdom" holds that the military is concerned only with
protecting the confidentiality of classified information.  Similarly, a
policy of integrity and reliability is associated primarily with
commercial and civil sectors.  The study team found those view points to
be over-simplified. 

Integrity issues are critical to the commercial and civil sectors, as
well as the military sector.  For example, integrity takes on a critical
meaning within a military Nuclear Command and Control (NC2) system.  The
NC2 system may disseminate a critical message from a top command tier of
a tactical network down to a field terminal associated with a weapon. 
This dissemination must occur in a timely and unaltered manner.  The
knowledge of the contents of such a message during a nuclear exchange
would have little or no value to an adversary.  However, the ability of
an adversary to alter the contents of, or to deny or delay the delivery
of, such a message could alter the course of a war.  

The study team found that a computerized hospital support system, whether
in a VA or commercial hospital, also imposes stringent integrity
controls.  The integrity controls of such a system must provide for the
ethics and laws associated with the clinical treatment of patients. 
Prior diagnoses can never be destroyed or altered; only doctors can
perform a diagnosis and prescribe medicine.  Protecting the accuracy of
patients medical records may be critical if there is an accident where
the patent becomes unconscious.  The correctness of information including
the patient's reaction to medications, pre-existing ailments, blood type,
or medication currently being prescribed can all prove to be health-
threatening or even life-threatening.

Integrity issues, in general, were found to address a richer and more
dynamic facet of security than confidentiality.  These issues often
pertained not only to who can access what data (which is common to most
confidentiality access control models) but also how and when the data is
accessed.  The more commonly agreed upon objectives of integrity include:

     o     Ensuring the consistency of data values within a computer
           system;

     o     Recovering to a known consistent state in the event of a
           system failure;

     o     Ensuring that data is modified only in authorized ways,
           whether by users or by the system;

     o     Maintaining consistency between information internal to the
           computer system and the realities of the outside world. 

Integrity issues were particularly relevant to applications such as funds
transfer, clinical medicine, environmental research, air traffic control,
and avionics, as well as many classified and sensitive (non-classified)
DoD applications.  For some systems, integrity was closely related to the
issue of system safety.  Two examples are maintaining the safe operation
of a manned space vehicle and a doctor relying on the correct results of
a medical diagnostic machine.

While usually associated with the military sector, the commercial and
civil sectors are also concerned with protecting the confidentiality of
their information.  Examples include the protection of personnel data,
marketing plans, product announcements, formulas, and manufacturing and
development techniques.

Commercial and civil sector organizations are obligated to protect the
results of mandatory medical exams and substance abuse tests from
unauthorized disclosure.  The compromise of a preliminary agricultural
report could provide an unfair advantage within the futures market.  The
knowledge of the thresholds used by IRS computers to flag tax returns for
subsequent audits could have great financial benefits.

3.2.2      Distinguishing Protection Characteristics

Although a common core of high-level security needs have been found to
exist across all sectors, some basic differences exist.  These
differences are in the way information is handled and where the emphasis
is placed on security within the commercial, civil, and military sectors. 

The military emphasizes strong access controls placed between users and
classified information.  These controls must be highly resistant to
bypass and alteration.  To achieve this and other requirements, the
operating environment is designed around a requisite security
architecture. 

Because of the potential consequences, organizations that process
classified information are willing to go through greater expense than the
rest of the federal government in terms of dollars, system development
time, and computer performance, to mitigate risk.  Where add-on security
products are not available, the military has designed and developed
secure systems from the ground up to meet its security needs.  Such
expenses are normally not justified in the commercial and civil sectors. 

On the other hand, the commercial and civil sectors have traditionally
emphasized auditing techniques, along with basic access control methods. 
This was based on (1) the belief that a user who knows he or she is being
watched is less likely to violate security and (2) the average user
knowing little about computers.  In contrast, the military has always
placed less emphasis on auditing since it is concerned with threats from
malicious software, such as Trojan Horses and trap doors, that can be
designed to bypass ordinary auditing mechanisms.  However, since the
average person is more knowledgeable and comfortable with computers, the
threat to commercial systems has increased.  Consequently, the difference
between the security threats to commercial computer systems and those of
the military is becoming less extreme.  

The study team found that most commercial organizations take a carefully
measured and cost-effective approach to computer and communications
security issues.  Each commercial organization interviewed described
computer security as an important and necessary capability of their
computer systems.  However, such statements were quickly caveated with
the reality that a business case is also presented regarding the merits
of such capabilities.  This business case was described as balancing the:

o    cost to implement, maintain, and administer security;

o    benefits gained by imposing security; and

o    impact on the user.

The costs associated with security are absorbed as part of overhead,
resulting in reduced profits and a potential loss of competitiveness.  On
the other hand, by neglecting security, an organization becomes more
vulnerable to attack.  An attack could result in an unexpected and direct
cost to the company through a loss of confidence in the organization by
its customers, or legal actions.  These factors can affect profits.  

Another consideration is how security effects the user.  The goal is to
make security features as transparent as possible to the user.  If a
user's ability to utilize the system is impeded due to security
constraints, then the organization is that much less efficient.  An
organization risks becoming less competitive due to higher overhead cost
or absorbing the added operational cost through lower profits.

A great deal of importance is placed on being in-step with other
organizations of like size and function in terms of a security program. 
This provides confidence that the organization is staying within the norm
of generally accepted business practices, thereby reducing risk in terms
of incurred liability.  Such considerations, along with more traditional
risk analysis, are used as the basis for determining requirements and
implementing safeguards.  Within the commercial sector, there is a trade-
off between the cost associated with potential loss and the cost
associated with implementing security mechanisms. 

Computer security programs of the federal government, in general, look at
different cost factors than those of the commercial sector.  The concerns
in federal government, like the commercial sector, are budgetary,
"regulatory," and reputation.  The difference is that the federal
government is not profit-oriented, nor does it worry about market share. 
Of more concern is maintaining public confidence, complying with new
regulations, and keeping a good reputation with the public.  A major
security incident can impact all three factors.  


3.3  Organizational Security Approach 

The NIST study team discussed with each organization the type of computer
security products, features, and mechanisms that were used, desired, or
sought.  This included the organization's approach to providing
confidence that the security features exist and work as intended. These
include design, development, and operational control aspects.  These
approaches will only consider information technology and not discuss
other safeguards, such as physical and procedural controls. 

3.3.1  Identification and Authentication

Identification and authentication were critical to every system the NIST
study team reviewed.  The most common method of authentication was
passwords.  Passwords can also be required at the data file level.

Passwords are considered by many to be a relatively weak security
mechanism.  Users tend to use easily guess passwords (e.g., spouse's
name, birth date, sport team, etc.).  A randomly generated password is
difficult to remember, causing the user to write it down and creating the
possibility of loss or disclosure.  Other vulnerabilities include
spoofing users, users stealing passwords through observing key strokes,
and users sharing passwords.  The unauthorized use of passwords by
hackers or insiders is a primary concern. 

Those interviewed felt that NIST should encourage vendors to provide a
strong password management capability at the operating system level that
would be tailorable to specific environmental needs.     

Along with the availability of a strong password management capability,
they felt NIST should continue to promote research on improving the
integrity of the identification and authentication process.  Technologies
such as smart cards, signature verification, and voice authentication
were mentioned as having a potential place in an overall approach to
security.  However, for organizations with large numbers of users, only
a low-cost solution would be practical.

3.3.2      Access Control

The access control needs and control policies of each organization
interviewed varied.  Many of these policies consider site,
organizational, industry, or agency-unique factors. 

Access control policies are context-dependent; it is not possible to know
the environment in which such control will be applied.  Not all stated
access control policies can be easily mapped and implemented using the
existing access control framework of the TCSEC. The TCSEC specifies two
types of controls:  Discretionary Access Controls (DAC) and Mandatory
Access Controls (MAC).  Since the TCSEC's appearance in December of 1983,
DAC requirements have been perceived as being technically correct for
commercial and civil security needs, as well as for single-level military
systems.  MAC is used for multi-level secure military systems, but its
use in other applications is rare.  The need for access controls more
appropriate to the commercial and civil sector, than that of DAC, was
found to exist.  There is a need for DAC, but DAC falls short when
implemented alone in solving the wide breath of security problems facing
sensitive processing environments.

The remainder of this section describes the applicability of DAC and MAC,
as well as other access control approaches, to the policy needs of those
organization interviewed.
 
3.3.2.1    Discretionary Access Control

DAC plays an important role in supporting security requirements of many
organizations, especially within engineering and research environments
where the discretionary sharing of access and exchange of information is
important.  For many organizations, users must be able to specify what
access other users have to resources that they control, without the
intercession of an administrator.  This makes the controls discretionary. 
Within a true DAC environment, the ability for a user to access
information is dynamic and changes rapidly over short periods.  

Organizations expressed concerns about relying solely on DAC as the
primary means of protection.  Specifically, they were concerned with the
propagation of access rights, reliance on the cooperation of users, and,
to a lesser extent, DAC's vulnerabilities to a Trojan Horse.

Some organizations expressed concern over exactly who has the capability
to specify group membership.  By granting membership to a group, user
access rights to protected data can dynamically change without the
knowledge of the owner of that data.  For some organizations, the ability
to specify group membership was described as appropriately placed at the
project level, while for other organizations, group membership was more
appropriately placed at the security officer level.  The organizations
were concerned with this capability and would like the option of
specifying control over group ownership within their computer systems. 
In addition, the ability to list group membership before granting access
privileges to that group was considered by some as a necessary part of
this capability.    

The most common approach to implementing DAC is through access control
lists (ACLs).  The TCSEC encouraged ACLs as appropriate for user-
controlled access rights.  However, when centrally administered, ACLs can
become clumsy and difficult to maintain. In centrally administrating DAC,
the system administrator assumes responsibility for ownership of all
resources, determining what resources and modes of access are needed for
the performance of each user's function within the organization.  For
each new user or every change in responsibility, the central
administrator establishes the appropriate access rights within the
system.  Additionally, when a person leaves the organization, the central
administrator deletes the person from all ACLs within the system.  Many
of the organizations felt ACLs were difficult for the central control and
management of access rights.

3.3.2.2    Role-Based Controls

Many organizations preferred a centrally administered, non-discretionary
set of controls to meet their security policies and objectives.  During
the course of this study, organizational policies and objectives have
included maintaining and enforcing the rules and ethics associated with
a judge's chambers, and the laws and respect for privacy of diagnosing
ailments, treating of disease, and administering of medicine within a VA
hospital.  To support such policies, a capability to centrally control
and maintain access rights is needed.  The security administrator is
responsible for enforcing policy and represents the organization as the
"owner" of system objects.  Access control decisions were found to be
based on the roles individual users take on as part of an organization. 
This includes the specification of duties, responsibilities, obligations,
and qualifications.  For example, the roles included doctor, nurse,
clinician, or pharmacist associated with a VA hospital; or teller or loan
officer associated with a banking system.  The doctor's role includes
privileges to perform diagnoses, prescribe medication, or add a entry to
(not simply modify) a record of treatments performed on a patient.  The
privileges defined for the role of pharmacist include those to dispense
(not prescribe) prescription drugs. 

The determination of membership and the allocation of privileges to a
role is not so much in accordance with discretionary decisions on the
part of a system administrator, but rather in compliance with
organization-specific protection guidelines.  These guidelines derive
from existing laws, ethics, regulations, or generally accepted practices. 
The guidelines are non-discretionary in the sense that they are
unavoidably imposed on users.  For example, a doctor can prescribe
medication, but cannot pass that privilege on to a nurse.

Once roles are established within the system, the privileges associated
with these roles remain relatively constant or change slowly over time. 
The administrative task is then to grant and revoke user membership to
the set of specified roles within the system.  The capability of an
administrator to simply grant and delete membership to existing roles has
been described as desirable.  When a user's function changes within the
organization, the user's membership to existing roles should be easily
deleted and new ones granted.  Finally, when a person leaves the
organization, all of that person's memberships to all roles are deleted. 
For an organization that experiences a large turnover of personnel, a
role-based implementation security policy is the only logical choice. 
 
The NIST study team talked with several organizations that felt role-
based access or access based on function was a control more suited to
their needs than DAC or MAC.  While add-on packages will give an
organization access based on function for their systems, role-based
access control should be generally promoted as are DAC and MAC. 
Currently no standard exists to promote the wide availability of role-
based access control.

3.3.2.3    Separation of Transactions

Separation of transactions is a design and implementation approach which
partitions a task-oriented set of programs and data.  This set is
available to a specific user who is allowed access only to these
resources.  A group of available transactions define a particular task
that can be assumed by a user.  Although similar, separation of
transactions differs from role-based control in that creation of roles
and the granting of membership to roles are an administrative function
while the underlying access control rules enforced through separation of
transactions is achieved through a combination of administrative and
transaction-design decisions.  

Because of the stable functionality and the deterministic characteristics
of transactions within some organizations, security engineers or those
knowledgeable of security issues facing an organization (i.e., privacy,
data integrity, etc.) play an important role in specifying access-control
decisions during the design and development of the system.  For example,
for one organization, transactions were designed to retrieve an entire
customer record minus the customer's social security number.  In
addition, design-time access control decisions can consider aggregation
problems that are difficult to address within conventional run-time
access control environments.  Security guidelines are addressed by the
designer and developers of a transaction or by direct involvement in the
design and development effort of proposed transactions.  

Once a transaction has been developed and introduced into the operational
environment, a security administrator may assign the named transaction to
specific users or user groups.  The importance of control over
transactions, as opposed to simple read and write access, can be seen by
considering a simple banking transaction.  Tellers may execute a savings
deposit transaction, requiring read and write access to specific fields
within a savings file and a transaction log file.  An accounting
supervisor may be able to execute correction transactions, requiring
exactly the same read and write access to the same files as the teller. 
The difference is the process executed and the values written to the
transaction log file.

A major insurance company enforces its corporate policy through the use
of separation of transactions.  Within the organization, each unit
(performing a specified task) is assigned a collection of transactions to
perform an assigned task or function.  A unit security administrator
determines "what users get access to what transactions," within that
unit.  The security administer can add and delete users to the unit, but
cannot assign transactions to individuals outside the unit.  

3.3.2.4    Separation of Related Duties

Although more of a policy than a mechanism, separation of related duties
is used in deterring fraud within financial systems.  Such duties can
include authorizing, approving, and recording transactions, issuing or
receiving assets, and making payments.  Separation of related duties
refers to the situation where different users are given distinct, but
often interrelated tasks such that a failure of one user to perform as
expected will be detected by another.  For separation of related duties
to be effective, computer capabilities must be partitioned.  These
capabilities must be accessible only to users or processes associated
with specific tasks.

Several organizations described the need for an add-on capability of
separation of related duties.  One example would be a program or device
to separate users who authorize or commit the expenditure of funds from
those authorized to place orders for services and equipment.  The IRS has
used this policy as a requirement from the outset and a system with this
capability was developed especially for them.

3.3.2.5    Principle of Least Privilege

The principle of least privilege was described by some of those
interviewed as an important control approach in meeting security policies
and objectives.  This principle gives the user no more privilege then is
necessary to perform a job.  Implementing least privilege requires
identifying what the user's job is, determining the minimum set of
privileges required to perform that job, and restricting the user to a
domain with those privileges.  Least privilege allows a user to have
different levels of privilege at different times, depending on what task
is being performed.  By denying access to transactions and privileges
that are not necessary for the performance of their duties, those
privileges cannot be used to circumvent the organizational protection
policy.  Least privilege is particularly important for those systems
where there is a "privileged user" or "superuser" capability that would
otherwise grant a wide set of privileges to users that need only a subset
of those privileges.

The principle of least privilege is similar to separation of
transactions.  It differs in that separation of transactions restricts
the set of programs that can access data and places restrictions on which
users can execute what programs.  Least privilege restricts a user's
access to data by denying users privileges that are not necessary to do
their job.

Several organizations would like an operating system capability that
supports the principle of least privilege.  This capability is currently
supported in upper end secure systems (B2 and above), but many
organizations expressed the desire to see this capability at a more basic
level.

3.3.2.6    Label-Based Mandatory Access Controls 

The other form of access control specified in the Orange Book is label-
based mandatory access control.  MAC is a non-discretionary access
control, restricting users in their access to data on levels implemented
through labels.  These are (1) the level associated with the trust of the
user, i.e., clearance, and (2) the level associated with the sensitivity
of the data.

Forming an alliance among companies that are otherwise competitors was
cited as a reason to enforce a confidentiality policy.  For such an
alliance to exist, the ability to isolate and share information on a non-
discretionary, formal "need-to-know" basis is required.    

The formal "need-to-know" has primary emphasis on categories and, to a
lesser extent, on hierarchical levels.  The term "category" is used to
describe non-hierarchical separation.  Outside the DoD, few organizations
operate using hierarchical levels.  Most non-DoD organizations have
employees and users belonging to one level, but with different
responsibilities, i. e., in different categories.

For example, a commercial organization recently formed strategic
alliances with some of its competitors.  Although this organization has
always allowed access to some of its most sensitive proprietary
information by outside consultants, this access was narrow and limited. 
Because of the frequency and scope of past access requirements, physical
and procedural measures could provide the necessary isolation. However,
the physical and procedural controls of the past have become impractical
with current information needs.  The only practical solution is label-
based mandatory categorization.  This type of access would allow limited
partnership between competitors.

As business alliances become a corporate reality for many U.S. companies,
label-based mandatory access controls will become more important. 
Currently, label-based MAC is not generally available as part of an
operating system, but it can be added.  

3.3.2.7    Object-Label Association

The ability to associate a label (not necessarily used in access
decisions) with an object was described as a needed capability by several
organizations interviewed.  These labels would carry warning, advisory,
and other information associated with an object and would not be used for
making mandatory access control decisions.  For example, within a
hospital system, a label would associate a warning with a prescription
drug, i.e., "not for use if person has high blood pressure".  The
association between a drug and a warning is an important relationship. 
For medical systems in general, the capability to associate an
information label describing the quality of an x-ray, CATscan, sonogram,
or any other image shared among medical professionals, can be a vital
capability.  Currently, object-label association is neither a capability
available within most systems nor encouraged through security standards. 

3.3.3      User Accountability

User accountability means holding individual users responsible for their
actions.  Imposing a policy of accountability on system users was
described by organizations as both a detection and deterrent mechanism. 
This implies that an individual is knowledgeable of some standard of
conduct and answerable to a higher authority who may impose penalties on
those who fail to adhere to this standard.  Also, making users aware that
their actions are being monitored is thought to prevent a would-be
violator from committing a breach of security.  

Individual accountability is accomplished through:

     o     uniquely identifying and authenticating the individual user;

     o     authorizing access to the system; 

     o     generating an audit trail of security relevant events; and 

     o     reviewing the database of security relevant events for
           deviations from some specified standard of conduct.

Although acknowledging vulnerabilities with the process of identifying
and authenticating an individual, organizations are aware that
technological solutions are available, but not yet affordable.  In
addition, they recognize that existing administrative interfaces are
inadequate for an effective review of the database of security-relevant
events.  This was especially true for environments doing distributed
processing. 

A related issue raised in a few interviews was intrusive employee
monitoring/surveillance.  A few organizations indicated employees or
their representatives had expressed concern about potential misuses of
increasingly sophisticated data gathering and analysis tools.

NIST should promote incorporating computer security auditing standards in
products.  Those interviewed expressed frustration with various aspects
of auditing computer security events.  Current auditing features,
although sufficient in meeting evaluation criteria, are of limited
practical use in distributed and networked environments.  There was
limited understanding of what events should be audited, what information
should be collected, what form that information should be in, and how to
compare and consolidate the information from one system to another. 
Interoperability and a common format for auditing security-relevant
events is needed.  Common formats would facilitate the central collection
and reduction of security-relevant events.  This is integral to achieving
security in the heterogeneous, distributed environment many organizations
are facing.


3.4  Electronic Data Interchange (EDI)

EDI is the computer-to-computer interchange of messages representing
business documents.  Most organizations expect EDI to become a common
part of their business practices.  They recognize that while EDI can
provide an opportunity for improved efficiency, it has the potential for
additional risk. 

Some expressed concern that by using EDI technology, original hard-copy
evidence of obligation and commitment by concerned parties would not be
available.  For EDI to be a practical alternative to paper, specific
assurances must be provided that EDI messages are authentic and properly
authorized.  The goal of EDI technology is to provide the same
capabilities as traditional paper-based administrative functions with
more efficiently and the same level of trust.


3.5  Assurance and Quality

Assurance gives a user or system owner a degree of reliability that
claims of security functionality and policy support can be relied on with
confidence.  Assurance is gained through various methods using evaluation
criteria as a metric.  Some people felt that part of confidence was an
effective user interface, with quality equating to ease of use. 

Security assurance is an important factor in any secure system
development effort and an important element of an existing or emerging
security standard.  The desired level and types of specific assurance
requirements are, at best, difficult to assess.  Most of those
interviewed felt that, at a minimum, security features should be
implemented with the same level of confidence, quality, and robustness as
other non-security-related operating environment system features.  

Some interviewees said that they saw a general increase in the level of
quality in computer products and felt a higher degree of confidence in
those products.  However, they could not report comparable improvements
in the security features associated with new system releases or versions
of systems, or the confidence they had in them.  One aspect of quality
notably missing from security features is a friendly user and
administrator interface.  This is particularly apparent when managing
ACLs, reviewing audit reports, and administering passwords.  Several
interviewees felt that resolving such problems would enhance the
effectiveness of security.

A sizable segment of those interviewed felt that the current assurance
and evaluation process is not cost-effective.  The security associated
with many systems and applications should not be viewed any differently
than any other aspect of the system.  It should be subject to the same
cost-benefit analysis as other features.  In regard to assurance levels,
a basic level needs to accommodate the notion of generally accepted
commercial practices.   

For the majority of organizations interviewed, a moderate level of
assurance was described as appropriate.  However, there is a class of
software/hardware systems where it is necessary that the system be shown
to be probably correct with respect to some aspects of its trusted
operation.  As noted, maintaining the confidentiality of classified data
within a military system may warrant such a confidence level.  However,
critical systems exist outside the military.  Security functionality is
critical to electronic funds transfer systems, as is safety within
avionic and transportation control systems.  In addition, with the
increased use of embedded computers in medical systems, improved methods
of assuring their correct operation becomes increasingly important.  


3.6  Evaluation

The process of security evaluation validates the functionality of the
features as well as assurances of a system.

The current process of evaluation was described to those interviewed by
the NIST study team as being an adjunct to the assurance process.  The
evaluation process is not without its costs in terms of product
development costs, development delays, and its availability.  The
development costs included the production of evaluation evidence (which
in many cases is not necessarily a byproduct of normal system
development), additional phases and activities added to the system design
and development, and enhanced architectural requirements.  The
availability and development delays included evaluation time and evidence
preparation time.

Those interviewed were almost uniformly concerned with the cost.  Some
interviewees expressed concerns about vendors passing along the added
design and development cost to the customer.  Another concern was the
availability of evaluated products.  Most noted that the products they
were currently using were not the same version as the product that was
evaluated.  

Even with the visibility and concern over the costs associated with
evaluation, most organizations recognized a need for an independent and
faster evaluation.  Surprisingly, there was not strong support for vendor
self-assertion with respect to evaluations.  Most organizations possessed
a basic distrust for vendors based on past experiences.  

Many organizations also took exception with the current format of
evaluations and viewed them as limited in scope.  It was suggested that
evaluations include other security-related aspects such as performance,
ease of use, compatibility with existing applications and hardware, and
interoperability issues.  Some even suggested that a "Consumer Report"-
style product assessment would be useful.  Such a report would support
their procurement needs as well as provide incentives for vendors to
develop a quality set of user and administrator interfaces rather than
meeting minimum requirements.  

Most organization representatives viewed the performance of evaluations
in a stand-alone laboratory environment as unrealistic for their actual
operating environments.  Of all the organizations interviewed, not one
processed in a stand-alone environment.  Almost all organizations had
intelligent workstations directly or remotely connected through a local-
area network. 


3.7  Current Criteria Not Keeping Pace 

Although advances have been great, several organizations stressed that
the current state of security technology has failed to address the needs
of all.  This is especially true of organizations outside the DoD who
felt little attention has been paid to current criteria in addressing
their security requirements. 

Trusted technology has also failed to keep pace with technological
advances in information processing.  Existing security theory and
criteria are founded on the multi-user stand-alone computing environment,
such as the mainframe computer.  However, the trend is toward distributed
storage, processing, and communication functions, on low-cost specialized
machines on a network.  The network is becoming the computer.  Current
product evaluations exclude general network facilities, while many
computers are installed in networks. 

The Trusted Network Interpretation (TNI) of the TCSEC was developed to
address the security network issue.  It provides security evaluation and
design criteria for networks of systems that are developed, installed,
and administered as though they were a single time-sharing system. 
However, most organizations procure systems in an evolutionary fashion
with new computer resources added, replaced, deleted, and added again. 
The system may be connected to another network which may be connected to
still another network.  The TNI does not address this evolution. 

3.8  Need for Security in Open Systems

Those interviewed felt that security standards which allow the
comprehensive implementation to integrate security across a multi-vendor
environment have failed to emerge.  It should be possible to:

     o     interface many systems, both present and future;

     o     provide a single user view of security services across a wide
           range of operating systems; and

     o     have security features interoperate with other security
           services on both local and remote machines, without the need
           to train users in new security products. 

The need to implement security should not limit an organization in
choosing the best solution and integrating it into their existing system. 
Security technology must support users working effectively together.  


3.9  Owner-Custodian Relations

Organizations assume a certain risk when they permit their information to
be transmitted over a commercial or public network and used by computer
systems they do not control.  They are aware that simply connecting to a
network can increase the vulnerability of their own computer system to
hackers or malicious software.  Some users conclude that, in addition to
providing mechanisms to protect information on their own systems, they
need to consider the security implications of sharing resources with
subscribers on other systems.  When an information owner passes
information to another system for use on that system, the user wants
assurance that information is protected in accordance with the owner's
protection criteria.

In an owner-custodian relationship, there is a transfer of responsibility
for safeguarding information from one party to another.  In practical
terms, the owner of the information defines what protection it requires;
any system that processes the information must ensure that the system
security policy satisfies the owner's protection policy.

An example is a military contractor who protects classified information
using DoD policy.  Another example is the Financial Intelligence Center
(FINCEN) of the Department of the Treasury.  To be effective in its
counter-narcotic efforts, FINCEN must interact and share information with
other law enforcement organizations, such as the Coast Guard, IRS, Secret
Service, postal inspection, gambling commissions, banks, etc.  FINCEN, as
a custodian of information belonging to a large number of organizations,
must provide security services that can be demonstrated effective at
meeting a variety of security policies.


3.10 Security Policies and Environments Can Change Over Time

For many organizations, security requirements cannot always be considered
at the outset of system procurement, or service or custodial
establishment.  For these organizations, the ability to integrate
security into existing processing environments in an evolutionary fashion
is critical.  All of the organizations interviewed reported significant
changes in their environments, as new computer and information
technologies are acquired.  In some cases, the changes are new customers
or new alliances with other organizations.  Some of the organizations
interviewed became custodians of others' data, in some instances data of
their competitors, as well as their own data.  In some situations,
organizations faced changing requirements regarding with whom they
exchange data.

In addition, threats can change over time.  For example, attackers can
devise new techniques.  Hidden vulnerabilities can be discovered after
system deployment.  Vulnerabilities can also be missed during system
evaluation and discovered in operational use.
4    CONCLUSIONS

The NIST study team concluded that computer security is applied uniquely
in each situation even though there are common concerns in all sectors. 
Because each organization has unique security needs, security products
have been applied on a case-by-case basis to meet individual computer
security threats.  Security at the operating system level, the
application level, the organizational level, and the site level must be
considered.  Products need to be flexible enough to serve a broad
spectrum of security needs.

Considerations must be made for the reality that security requirements
evolve and cannot be totally specified at the time of product
acquisition.  Security capabilities need to include new system and
network connections.  Security managers need to be aware of changing laws
and regulations.

At the operating system level, basic capabilities need to be adaptable to
a variety of organizational policies and applications.  These
capabilities should include security extensions that allow more security
to be added at a later date.  These extensions can include trivial
password checkers, system built options, and enhanced system
administrative capabilities, such as setting minimum-length password,
creating roles, granting and revoking access and capabilities).  

More classes of operating systems beyond C2 with more flexibility within
the classes are needed.  Users are concerned with computer security
issues beyond confidentiality and disclosure.  There is a need to address
data integrity in a more direct and user-friendly manner.  Vendors should
consider new mechanisms that more directly address such things as role-
based access controls, separation of duties, separation of transactions,
and user-oriented least privilege.  


4.1  Minimum Security Requirements

A majority of those interviewed wanted a baseline of computer security
controls in the systems they purchase.  These would include a more
flexible DAC, role-based non-discretionary access controls, and principle
of least privilege.  While acknowledging their responsibility in
determining security requirements, they saw value in knowing that their
systems met a pre-existing computer security baseline.

4.1.1      Baseline Capabilities

While DAC was considered useful, that capability was not flexible enough
for group membership.  A number of organizations were administering
access control policies based on the roles or job functions of its staff. 
However, these policies were implemented by mechanisms, such as access
control lists, that were not designed to facilitate a role-based world
view.     

Organizations felt that role-based or access-based functions were
controls more suited to their needs than DAC or MAC.  While there are
add-on packages that provide this function, this type of access control
should be as widely promoted as are DAC and MAC.  Lack of standards for
role-based access control contributes to the problem.

Within DAC environments, organizations need control over group ownership
within their computer systems.  In addition, the ability to list group
membership before granting access privileges to that group was considered
to be necessary.

Several organizations described the need for an operating system
capability that supports the principle of least privilege.  This
capability is currently supported in upper-end secure systems (B2 and
above), but many organizations expressed the desire to see this
capability at a more basic level.


4.2  Computer Security Features Enabled by Default

Vendors should deliver computer security systems with the security
features turned on or enabled.  This would provide an initial security
state and enforce a disciplined consideration of those features to be
disabled.  A very small minority wanted computer systems delivered with
the security features turned off.  They wanted the choice of turning on
only those features they needed in order to not excessively inhibit
system performance.


4.3  Assurance

Most organizations felt evaluation criteria should include a wide range
of assurance levels.  This includes a "generally accepted commercial
practice" level which minimizes the cost of developing systems and the
length of time associated with evaluation.  Evidence used in the
assurance process should be founded on a sound base of experience and
observations.  Evidence should be limited to that which has shown to be
beneficial in the past, not that which, in theory, should be beneficial. 


4.4  Evaluation

The current evaluation and certification process (i.e., with respect to
TCSEC) is not perceived by users as meeting their needs for a variety of
reasons.  One reason cited was the time lag between new product releases
and formal certification.  Another reason was that the existing
certification process does not address other issues associated with
operational environments, such as effectiveness of mechanism,
performance, version compatibility, adaptability, and ease of
integration.

Each organization felt that the products they acquired needed to be
evaluated regarding security features and assurances.  None felt that
vendor self-certification or vendor representation were adequate.  While
a few wanted to do a portion of the evaluation themselves, the vast
majority wanted an independent third party evaluation.  A federal
government-operated or commercial government-accredited process was the
most desirable.  Many factors contributed to each organization's attitude
toward certification, including sensitivity of the applications,
corporate culture, time and cost considerations, mission criticality,
past experience with vendors, and availability of assessment sources.


4.5  Administration

The vast majority of the organizations interviewed felt that
administering computer security, particularly access control, was
burdensome in a heterogeneous, distributed environment.  Given their
other responsibilities, this function took more time and effort than they
felt was appropriate.

Interviewees wanted computer security-related products that would easily
implement organization security policy and manage security functions. 
These functions included centralized network security administration and
single logon for network data and services.  Organizations felt that
improved security administrator interfaces were essential to balance the
increasing need for protection and limitations on the staff resources
devoted to it.

4.5.1      Password Management

Most organizations felt that vendors should provide a strong password
management capability at the operating system level and it should be
tailorable to specific environmental needs.  Along with that, most felt
NIST should continue to promote research on improving the integrity of
the identification and authentication process.  Technologies such as
smart cards, signature verification, and voice authentication have a
potential place in an overall approach to security.  However, for most
organizations, only a low-cost solution would be practical due to a large
number of users.

4.5.2      EDI Capabilities

For EDI to be a practical alternative to the exchange of paper,
organizations want specific assurances that EDI messages are authentic
and properly authorized.  The goal of EDI technology is to provide the
same capabilities as traditional paper-based administrative functions
with more efficiently and the same level of trust.  This requires EDI
standards that are part of the baseline operating system.


4.6  Add-on Packages

Several organizations described the need for a variety of add-on
products.  In some cases, these products are available, but do not
interface with the already-purchased computer systems.  In those cases,
organizations felt that the add-on packages should be capable of working
with a wider variety of machines.

An add-on package that provides separation of related duties is needed. 
Currently, this feature must be contracted out.  Object-label association
is neither a capability available within most systems nor is it
encouraged through security standards.  Organizations were interested in
add-on products that would meet this need.  They also felt that security
standards for object-label association should be developed. 

Currently, label-based mandatory access controls are not generally
available as part of the operating system, but as an add-on.  Since this
type of access control will be used more and more by companies forming
alliances with competitors, the capability to isolate and share
information on a non-discretionary, formal "need-to-know" basis will be
required.  


4.7  Current Criteria 

Although advances have been great, several organizations stressed that
the current state of security technology criteria has failed to keep pace
with technological advances in information processing.  Computer security
criteria needs to be kept current.  In addition, criteria which addresses
the evolving technology of networked computers is needed.

Current criteria also does not address procurement in an evolutionary
fashion with computers interconnected to networks. 


4.8  Security Standards for Multi-Vendor Systems

Those interviewed felt that security standards that allow comprehensive
implementation of security across a multi-vendor environment have failed
to emerge.  The possible standards would provide for:

     o     interfacing many systems, both present and future;

     o     a single user view of security services across a wide range of
           operating systems; and

     o     security features inter-operating with other security services
           on both local and remote machines, without the need to train
           users in new security products. 

The need to implement security should not limit an organization in
choosing the best solution and integrating it into their existing system. 
Security technology must support users working effectively together.


4.9  Closing Thoughts

Because each organization has unique security needs, security products
have been applied on a case-by-case basis in meeting individual computer
security threats.  Security at the operating system level, the
application level, the organizational level, and the site level must be
considered.  Products need to flexible enough to consider a broad
spectrum of security needs.

At the operating system level, basic capabilities that are adaptable to
a variety of organizational policies and applications need to be part of
a computer security baseline.  These capabilities would be extensions so
that more security can be inserted, such as a trivial password checker,
or system build-in options, as well as enhanced system administrative
capabilities, such as setting minimum-length password, creating roles,
granting and revoking access and capabilities.  

Security requirements evolve and cannot be totally specified at the time
of product acquisition.  Security capabilities need to include new system
and network connections, while security managers need to be aware of
changing laws and regulations.