Forum of Incident Response & Security Teams/Forum_of_Incident_Response_and_Security_Teams_FIRST_October_1994.iso/teaminfo/nist/csl05_93.txt

Text File | 1994-07-02 | 22KB | 449 lines

**************             CSL Bulletin       *************

                             May 1993

SECURITY ISSUES IN PUBLIC ACCESS SYSTEMS
Many federal agencies have begun to design, develop and implement
public access systems for the electronic dissemination of federal
information to the public.  Such systems offer agencies the
opportunity to increase the timely distribution of federal
information to meet the needs of their consumers.  Public access
systems can also provide electronic interaction by allowing the
public to send information to the government as well as receive
it.  Filing tax returns electronically or completing a survey on
a computer bulletin board are examples of electronic interaction.
Both electronic dissemination and interaction offer many positive
benefits, such as substantial increases in customer satisfaction,
and many agencies are exploring their uses.  With increasing
frequency, Congress is also requiring agencies to provide direct
electronic public access to specific agency information.

The growing use of these systems and commensurate public reliance
upon them, require that agencies afford them appropriate
protection.  This bulletin presents some of the major security
issues which agencies should examine when planning or operating
public access systems.

Definition
For the purpose of this bulletin, a public access system is
defined as:

     a system used by either 1) the general public or 2) a large
     or significant subset of the public.

Agency dial-in bulletin board systems fall under this definition
as well as systems which provide information to individual
members of the public.  These systems, called client-based
systems, provide account-specific information to users of
government services.  Systems made available only to non-
government specialists in a given research field are also
considered public access systems.

PUBLIC ACCESS SYSTEMS REQUIRE SPECIAL ATTENTION

Public Confidence
The dissemination of information by the federal government
requires that public access systems maintain data integrity while
ensuring data availability.  Like non-public access systems, the
consequence of a loss of integrity or availability ranges from
inconvenience to loss of life.

However, there is also the consequence of reduced trust by the
public in the federal government, or a specific agency, if a
public access system has significant problems, such as prolonged
system outages, distribution of incorrect data, or distribution
of a computer virus.  These problems could reduce the level of
public confidence and impact an agency's effectiveness.

Because of the public confidence issues in public access systems,
there is an increased risk of hackers and insider malice.  For
example, to embarrass or discredit the agency, a disgruntled
employee could try to introduce errors into data files intended
for distribution.  Similarly, hackers may be tempted to break
into a popular system in order to gain notoriety.  Because of
public confidence issues, agencies may want to designate some
public access systems as "high threat" systems.

Increased Connectivity and Visibility of Public Access Systems
Public access systems, by their definition, must provide an
interface for the public, such as a phone number or network
address.  In addition, the systems and interfaces are often
advertised to the public.  This well-publicized connectivity is a
necessity for public access systems, but it can be an invitation
for hackers.

Difficulty of Security Administration
In non-public access systems, procedures for enrolling users
often include user training and signatures on forms acknowledging
user responsibilities.  In public access systems, by contrast,
users are often anonymous and untrained in the system and their
responsibilities.

In most non-public computer systems, security controls are based
on "user accountability" which holds users responsible for their
actions.  In addition, user profiles can be created and
sophisticated audit mechanisms developed to detect unusual user
activity.  However, public access systems which have anonymous or
unverified users cannot implement user accountability-based
controls.

Some agencies are adding public access capabilities to existing
systems.  The retrofitting of this capability compounds the
difficulty of implementing effective security controls.

TECHNICAL CONSIDERATIONS

Identification of Users
Some public access systems allow anonymous use while others
require some form of identification and authentication of system
users.  For example, the Internal Revenue Service operates a
system to provide the current status of the processing of income
tax refunds.  The system requires users to provide their social
security number (SSN), filing status, and amount of the expected
refund.  This is a form of identification (i.e., the SSN) and
authentication (only the taxpayer, and perhaps the tax preparer,
is likely to know the amount of the expected refund).  In this
case, identification and authentication is needed to protect the
confidentiality of the information.

The decision to require the identification and authentication of
system users must be made by an agency in light of mission and
operational considerations.  Often this is not an easy decision.
Factors to be considered include the size of the user population,
the frequency of their use, confidentiality of the data being
distributed, whether the system allows alterations or updates to
data, and agency-specific issues.

Access Controls
Many of the security issues involving public access systems are
strongly tied to the need to provide for access control.  The
term "access" is often confused with "authorization" and
"authentication."

     Access is the ability to do something with information in a
     computer.  Access refers to the technical ability to do
     something (e.g., read, create, modify, or delete a file or
     execute a program).

     Authorization is the permission to do something with
     information in a computer, such as read a file.

     Authentication is proving (to a reasonable degree) that
     users are who they claim to be.  It is normally paired with
     the term identification.  Typically, identification is
     performed by entering a name or a userid, and authentication
     is performed by entering a password, although many
     organizations are moving to stronger authentication methods.
     For example, banks require a magnetic stripe card and a
     personal identification number to authenticate users at
     ATMs.

Although the ability to sign onto a computer system (enter a
correct userid and password) is often called "accessing the
system," this is actually the identification and authentication
function.  Once a user has entered a system, access controls
determine what the user can do, i.e., which data the user can
read or modify and what programs the user can execute.

Using Access Controls to Build a Strong Security Foundation
Public access systems require access control to system functions,
data, and other resources.  Neither hackers nor legitimate users
should be able to break through system access controls to modify
data intended for public distribution or gain system management
or other supervisory privileges.  Public users should be
restricted to only those functions and data for which they are
authorized.  Broadly speaking, if users are appropriately
restricted in their ability to access data and resources on the
system, their ability to cause harm or disruption is reduced or
eliminated.  These controls provide for data and system integrity
and help ensure the availability of system resources.  Data
confidentiality can also be supplied, as necessary.

Unfortunately, implementing and maintaining effective access
controls is not an easy task.  Both technical and procedural
difficulties arise, often due to incorrect access control
implementation or inadequately trained system management
personnel.  A 1988 study by the President's Council on Integrity
and Efficiency (PCIE) showed that at ten federal data centers
which had purchased and installed high quality access control
software, computer systems were still vulnerable to unauthorized
access; that is, users were able to access more information than
they were authorized to access.  Since 1988, there have been many
improvements in access control, but industry experts warn that
most computer systems that implement access controls are still
vulnerable.

In most non-public access systems, users are known employees or
contractors.  For these systems, imperfectly implemented access
control schemes may be tolerated because other controls, such as
user accountability-based controls discussed above, are used.
However, when opening up a system to public access, additional
precautions may be necessary because of increased threats.  In
these situations, strict attention to the implementation of
access controls becomes much more important.

For more details on the theory and implementation of access
control see the References Section.

SPECIFIC SECURITY ISSUES
Sound access controls provide the foundation for the security of
public access systems, but the difficulty of implementing
controls raises other security issues.  Agencies should examine
the following security issues when planning or operating public
access systems.  Not all of these issues apply in every situation
nor is this list exhaustive.  Each public access system operates
in a unique environment and will have individual security
requirements.

#1 - Maintaining Data Integrity
Users of government public access systems should not be able to
modify data without authorization.  A number of available
techniques can complement access controls in providing data
integrity.  As noted above, access control alone may not provide
sufficient security.

One new technique is to use digital signatures to sign the data
files to be distributed by the system.  Thereafter, each time a
file is requested by a user, the system automatically (and
transparently to the user) verifies the signature.  Verification
indicates that the file remains unaltered.  Should the
verification fail, it must be assumed that the data has been in
some way corrupted.  Measures can then be taken so that incorrect
data is not distributed.

This technology can be extended to the users or redistributors of
the data.  Users and redistributors can verify that the data has
not been corrupted, both on the government system and on their
own system after downloading.  This helps to ensure that the
agency's data is distributed and used in an error-free state.

Another approach to maintaining data integrity is to use CD-ROM
technology for on-line storage of data for distribution.  Files
stored on CD-ROM technology are physically protected from user
modification.

#2 - Maintaining Data Quality
Data quality is similar to, but distinct from, data integrity.
In this context, data quality refers to the general reliability,
accuracy, and precision of the data.  Data integrity, on the
other hand, helps ensure that the data (regardless of quality)
remains unaltered or is only altered in an authorized manner.

Public access to data can result in increased data quality if the
public is able to inform the government of errors in the data.
The public, however, should not be allowed to alter the data
directly.  Procedures for receiving and verifying alterations
should be established.

The agency "owner" of the data should be consulted as to the
general reliability and accuracy of the data.  Users can then be
provided with a summary of the agency's understanding of the
quality of the data (e.g., "uncertainty" in measurement data,
confidence levels, etc.) so that use of the data is consistent
with its quality.

#3 - Avoiding Public Access to "Live" or Permanent Record Data
and Systems
In most cases, direct public access to an agency's "live"
database or computer system presents an unacceptably high level
of risk.

Agencies collect, generate, and process information to meet their
mission requirements and rely on the availability, integrity, and
confidentiality of the information to perform their mission.
Depending upon the threat environment, an agency may not wish to
allow direct public access to the same copy of a database or the
same computer system the agency relies upon to fulfill its
mission.  For example, an agency may determine that allowing such
access may provide an unacceptably high level of risk from
hackers and may jeopardize system availability and integrity.

Access to "Live" Data.  Agencies should generate a copy of agency
databases and allow public access only to the "copies."  Users
should be informed of the date/time of the version of the data to
which they have access.  "Owners" of data should be consulted as
to how often updates to the database should occur.  The system
operator can then update the public access copy accordingly.

Access to "Live" Systems.  Public access applications may be
provided to the public on either standalone single-purpose
systems or on existing multipurpose agency systems.  Agencies
sometimes allow the public to access existing agency systems
because of a perception that the impact on agency resources and
operations will be minimal.  However, there may be a significant
threat to agency operations if a hacker or malicious code
disrupts a system which the agency relies upon for day-to-day
operations.  Recovery from such incidents can be highly resource-
intensive.  Agency systems may also process data not authorized
for public release, placing a high degree of reliance upon the
proper implementation of access controls to maintain the
confidentiality of such data.  While integrity and availability
can be "recovered," confidentiality cannot.  NIST strongly urges
agencies to consider separating public access applications from
general use agency systems.

In some cases agencies can realize cost savings and security
benefits by sharing dedicated public access systems.  This should
result in reduced agency hardware and system management
expenditures.

#4 - Maintaining System and Data Availability
Many federal computer systems have strong requirements for the
system to be operational and available as needed.  Unavailability
of public access systems, however, may have additional
consequences because of their unique position as a direct
government interface with the public.  Demand for system
resources may increase, often beyond expectation, as users learn
about the availability of information in electronic form.
Because of the convenience and speed of electronic access, more
traditional means of obtaining information may be reduced or
eliminated causing an increased public dependence on the system.

Providing for backup telecommunications may present special
problems for public access because of the widespread geographic
distribution of the user population.  When developing
contingency plans, planning backup schedules, and implementing
other "availability" measures, agencies must consider the special
needs of public access systems.

#5 - Preventing Computer Viruses
Agencies should ensure that public access systems are designed to
minimize the distribution of computer viruses by the agency.

Many computer systems are vulnerable to infection by computer
viruses and other forms of malicious code.  Public access systems
may be more highly vulnerable to virus infection.  In addition, a
special risk is the possibility of government systems spreading
viruses to public users.

Computer viruses are usually distributed via infected executable
code.  Therefore, the easiest method to avoid virus infections is
to prohibit users from uploading or downloading executable code
by allowing only the downloading of data files.  If
upload/download capability is necessary to meet the agency's
programmatic requirements, agencies must implement additional
security precautions.

In some cases, there may be a requirement to allow users of the
public access system to download software from the system.  This
may be necessary in order to allow the user to process or analyze
data files available on the system.  In such cases, the system
operator should use up-to-date anti-virus tools.  This will
reduce, but not eliminate, the risk of users obtaining infected
software from the agency system.

Once software has been determined to be virus-free, the agency
may wish to digitally sign the software file (as discussed in #1
above).  The addition of a virus or any other modification to the
software would then be readily detectable.  The system operator
could periodically verify the digital signature, as could the
user after downloading the software.  Each time the signature is
verified the user will have confidence that the software has not
been modified.  Some operating systems offer utility programs
that compute check sums.  These can provide some degree of
assurance that the code is unaltered.

Public access systems (e.g., a bulletin board system) that allow
for users to both upload and download files (either data or
executable code) require additional security measures.  When
users wish to post a file, the system should be configured so the
file is made available only to the system operator.  Using up-to-
date anti-virus tools, the administrator can verify that data
files and executables contain no viruses.  Files found to be
virus-free can then be posted.  System managers and users should
be aware, however, that new viruses appear every day and that
tools cannot detect all viruses.  Therefore, system users should
be warned against the possibility of virus transmission and urged
to take appropriate precautions, such as backing up files on
their systems.

#6 - Audit Trails and User Confidentiality
In performing routine security and operational tasks, system
managers collect information on system use in audit trails.
Audit trails are used to determine usage patterns, to develop
typical user profiles so that anomalous behavior (such as an
intruder) can be detected, and other system management functions.

These standard procedures raise some confidentiality issues when
they are applied to public access systems since they can be used
to identify or distinguish among users and to identify what
information a user has requested.  For example, a system's audit
trail may identify the network address of all users calling into
a system.  This information is used to help in troubleshooting
potential problems.  The same information, however, could be used
to identify a user or user's organization.  This may create
difficulties if the system in question promised or implied user
confidentiality, such as an Inspector General Hotline.

#7 - Legal Considerations
Agency personnel may encounter many security-related legal issues
in the operation of public access systems.  For example, on
bulletin board systems, users should be warned not to post
copyrighted software or information.  Notices should be posted to
warn users whether by signing onto the system they are expressly
consenting to keystroke monitoring.  For specific guidance on
legal issues, system operators are urged to contact their Office
of the General Counsel.

Conclusion
This bulletin highlights areas of particular concern for public
access systems.  These are in addition to the many security
issues which must be addressed for all systems.  Technical,
administrative, and operating controls cannot be ignored in
public access systems.  Standard security measures and good
system management principles cannot be neglected.

The Computer Security Act of 1987 specifies that security plans
must be developed for sensitive systems.  Although public access
systems may not contain information sensitive to disclosure,
there may well be integrity and availability concerns which would
require the development of a security plan.

Appendix III to Office of Management and Budget Circular A-130,
"Management of Federal Information Resources," provides general
security requirements for federal systems, including public
access systems.

References
Abrams, M.D. et al.  A Generalized Framework for Access Control:
An Informal Description.  MITRE Corporation, McLean, VA, 1990.

Caelli, William, et al.  Information Security for Managers.
Stockton Press, New York, NY, 1989.  (See pages 130-157.)

Environmental Protection Agency.  Public Access:  A "How To"
Guide.  Environmental Protection Agency, Washington, DC, 1992.

Gasser, Morrie.  Building a Secure Computer System.  Van Nostrand
Reinhold Co., Inc., New York, NY, 1988.

Jacobson, Robert V.  The PC Virus Control Handbook.  Miller
Freeman Publications, San Francisco, CA, 1990.

National Institute of Standards and Technology, Computer Systems
Laboratory.  CSL Bulletin, Guidance on the Legality of Keystroke
Monitoring.  National Institute of Standards and Technology,
Gaithersburg, MD, March 1993.

Office of Management and Budget.  Management of Federal
Information Resources, OMB Circular A-130.  Office of Management
and Budget, Washington, DC, December 1985.

Pfleeger, Charles P.  Security in Computing.  Prentice-Hall,
Inc., Englewood Cliffs, NJ, 1989.

Polk, W. Timothy and Bassham, Lawrence E.  A Guide to the
Selection of Anti-Virus Tools and Techniques, NIST Special
Publication 800-5.  National Institute of Standards and
Technology, Gaithersburg, MD, 1992.

President's Council on Integrity and Efficiency.  Review of
General Controls in Federal Computer Systems.  Washington, DC,
1988.

Wack, John P. and Carnahan, Lisa J.  Computer Viruses and
Related Threats:  A Management Guide, NIST Special Publication
500-166.  National Institute of Standards and Technology,
Gaithersburg, MD, 1989.