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
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.