United States Office of Information
Environmental Protection Resources Management
Agency Washington DC 20406 December 1989
£EPA EPA INFORMATION
SECURITY MANUAL
-------
Information Security Manual 12/15/89
PREFACE
Recently, information security has achieved a new and unfamiliar prominence. In-
formation security issues have appeared on the covers of both "Time" and "Business
Week" magazines. Congress has emphasized the importance of information secu-
rity through its passage of the Computer Security Act of 1987.
What this newfound prominence seems to highlight is that we are now truly in the Age
of Information. The explosion in personal computing is the latest step in creating this
information society. As we have become more dependent on our information re-
sources, so have we also become more concerned about what might happen if those
resources were lost or misused.
At the Environmental Protection Agency (EPA), the Agency information security
policy is contained in a formal policy statement. (The policy statement, issued in
1987, is reproduced here as Appendix A.) The policy statement recognizes that
information is an Agency asset and that the EPA is highly dependent on its informa-
tion resources to carry out program and administrative functions in a timely, efficient,
and accountable manner.
The policy statement formally establishes a comprehensive, Agency-wide informa-
tion security program and describes individual and organizational responsibilities
under the program. Two procedural manuals which explain to EPA managers and
staff how to comply with these responsibilities have now been developed.
This is one of the two manuals and it deals comprehensively with all types of infor-
mation assets (paper records, mainframes and minicomputers, information sys-
tems, PCs, and word processors). The other manual deals exclusively with PC
security. Because PC security affects the most employees and is a relatively new
area of security vulnerability, it is important to handle it separately so that the PC
procedures will be accessible and will not get lost in discussions of mainframe or
software development security.
Each manual begins with similar introductory sections. Information security and in-
formation sensitivity are defined in terms of the three objectives of the EPA program,
which are to maintain information availability, integrity, and confidentiality. The in-
formation security problem is then described in terms of threats to the objectives.
-------
Information Security Manual 12/15/89
Each manual is structured to allow the reader, whether manager or staff member, to
tailor it to his/her own particular security situation by completing one or two work-
sheets and by reading selected portions of the text. Specifically, each reader works
through a sensitivity evaluation table to determine if he/she has sensitive informa-
tion. If not, only minimal security controls need to be implemented. If the reader
does have sensitive information, he/she uses a worksheet to identify why the
information is sensitive and which of the three security objectives are relevant. The
reader is then referred to later sections of the manual as appropriate. For example,
there is a subsection on safeguards for maintaining the availability of critical PC ap-
plications and a subsection on safeguards for preserving the confidentiality of
confidential paper records.
Because a common problem in information security is determining exactly who is re-
sponsible for what aspects of security, each manual devotes a chapter to information
security roles and responsibilities. While the manuals are as user friendly as pos-
sible in explaining to readers howto fulfill those responsibilities, they are not painless.
To ensure that information resources are adequately protected, they describe three
different control processes. The processes establish a structure of security checks
and balances by approaching security both from an equipment perspective and from
an application or information system perspective.
-------
Information Security Manual 12/15/89
TABLE OF CONTENTS
Section Page
1. GENERAL INFORMATION 1-1
2. INFORMATION SECURITY ROLES AND RESPONSIBILITIES 2-1
3. MINIMAL SECURITY CONTROLS FOR MINICOMPUTER/MAINFRAME
INSTALLATIONS, PCs, PC LANS, AND WORD PROCESSORS 3-1
4. DETERMINING THE NEED FOR ADDITIONAL CONTROLS 4-1
5. PERSONNEL SECURITY AND TRAINING 5-1
6. SECURITY FOR MINICOMPUTER AND MAINFRAME INSTALLATIONS 6-1
7. SECURITY FOR PERSONAL COMPUTERS AND PC LANs 7-1
8. SECURITY FOR WORD PROCESSORS 8-1
9. SECURITY FOR APPLICATION SYSTEM DEVELOPMENT, OPERATIONS AND
MAINTENANCE 9-1
10. SECURITY FOR PAPER RECORDS 10-1
APPENDIX A: POLICY A-1
APPENDIX B: APPLICATION RISK ANALYSIS AND
APPLICATION CERTIFICATION B-1
APPENDIX C: INSTALLATION RISK ANALYSIS C-1
APPENDIX D: DISASTER RECOVERY AND CONTINUITY
OF OPERATIONS PLANS D-1
in
-------
Information Security Manual 12/15/89
1. GENERAL INFORMATION
1.1 PURPOSE, SCOPE, AND APPLICABILITY
In accordance with the Agency's Information Security Policy, this manual estab-
lishes security procedures for safeguarding Agency information resources and
provides overall guidance to EPA managers and staff in implementing those
procedures. The security controls specified in this manual are designed to ensure
that information resources are adequately protected and that EPA organizations and
staff are in compliance with all requirements of the policy.
As used in this manual, information resource (or information asset) is a broad term.
It includes automated information systems, computerized data bases, computer
programs, collections of paper records, information on microfiche or microfilm, and
computer installations.
Consistent with the Information Security Policy, this manual applies to a! EPA or-
ganizations and their employees. It also applies to the personnel of agents (including
contractors and grantees) of the EPA who are involved in designing, developing,
operating, or maintaining Agency information and information systems.
The specific purposes of this manual are as follows:
To save organizations money by ensuring that only focused, cost-
effective security safeguards (or controls) are implemented
To protect organizations and individuals from the embarrassment of an
unauthorized disclosure or from the disruption that would result if critical
information were destroyed
To help organizations meet internal control review requirements by
providing them with a sound basis for assuring that automated information
systems are adequately protected
To assist staff in developing the system documentation required by the
"EPA System Design and Development Guidance"
To enable organizations to successfully undergo any security audits that
may be conducted by the Office of the Inspector General.
1-1
-------
Information Security Manual 12/15/89
1.2 INTRODUCTION TO THE EPA INFORMATION SECURITY PROGRAM
Through the Information Security Policy, the EPA has established a comprehensive,
Agency-wide information security program to adequately safeguard the Agency's in-
formation resources. (The policy, which is Chapter 8 of the EPA's "Information
Resources Management Policy Manual," is reproduced here as Appendix A.) The
concept of adequacy means that security controls should be neither overapplied nor
underapplied. Overapplication wastes financial and ADP resources, and underap-
plication exposes the information to various security threats.
The policy categorizes information and applications (or systems) as either sensitive
or not sensitive. Sensitive information means information that requires protection
due to the loss or harm that could result from inadvertent or deliberate disclosure, al-
teration, ordestruction of the information. Examples of sensitive information include
Confidential Business Information (CBI), Privacy Act Information, and data critical to
the performance of primary Agency missions. A sensitive application is an applica-
tion that processes sensitive information or an application that requires protection
because of the loss or harm that could result from the improper operation or
deliberate manipulation of the application itself.
In short, information security involves the precautions taken to protect sensitive in-
formation resources from potential loss and misuse. The three major objectives of
the EPA program, as illustrated in Exhibit 1-1, are to maintain:
Information Availability
Information Integrity
Information Confidentiality
The availability objective is associated with information where the loss of the infor-
mation would cause serious problems, either because it would be costly to replace
the information or because it would be difficult to function without the information.
Thus, availability involves both the dollar value and the time value (or criticality) of
the information. An example of an Agency information system or application where
availability is important is the Resource Conservation and Recovery Information
System (RCRIS).
The integrity objective is associated with information or applications where accuracy
1-2
-------
Information Security Manual
12/15/89
EXHIBIT 1-1
INFORMATION SECURITY OBJECTIVES
Prevent
Information
Loss
Prevent
Information
Corruption
Prevent
Information
Disclosure
1-3
-------
Information Security Manual 12/15/89
and reliability are of particular concern. In short, integrity is concerned with protecting
information from corruption. An example of an Agency information system where in-
tegrity is important is the Integrated Financial Management System (IFMS).
The confidentiality objective is concerned with information where disclosure would
be undesirable or unlawful. Examples of information of this type include Toxic
Substances Control Act (TSCA) CBI or personnel files.
As Exhibit 1-1 indicates, a particular application could involve only one objective or
could involve some combination of objectives. For example, a data base could
contain information critical to a primary Agency mission and yet contain no confiden-
tial information. In other words, while the availability objective is key, confidential-
ity is not a factor and the information in the data base could be widely disseminated
without any damage resulting from disclosure. On the other hand, anotherdata base
could be both critical and confidential.
1.3 THE INFORMATION SECURITY PROBLEM
The EPA is highly dependent on its information resources to carry out program and
administrative functions in a timely, efficient, and accountable manner. For
example, the Agency relies on its information collection authority under various
enabling statutes to fulfill its environmental missions. The willingness of the regu-
lated community and state and local agencies to supply requested information in a
cooperative and timely fashion depends on their confidence that the information will
be adequately protected.
The nature of the information security problem is illustrated in Exhibit 1-2. A wide
range of intentional or unintentional events can threaten Agency information
resources. These threats include:
External and environmental threats, such as fire, waterdamage, or power
failure
Hardware and software error, such as disk or operating system failure for
automated information systems
Operations/procedural error, such as accidental modification or destruc-
tion of data
Malicious actions, such as theft or data sabotage.
1-4
-------
Information Security Manual
12/15/89
EXHIBIT 1-2
THE SECURITY PROBLEM
Environmental Threats
Hardware & Software Errors
Malicious Actions
\
lp
'ersonnel jijil
Controls -^V
i>X Software X4i|
rJrV &Data MT^T
WM, Controls rVr1
X
<*' v
;;l
x- ^
-,,,,
//
'">*',
, ,y , ' ,
'"-, '' ' ',
INF
PLJI^ Equipment 4jM
TV & Physical S?
ptt Controls 44
ORMATION
g Administrative S
g Controls g
RESOURCES
Programs
Data
Equipment
' ' ' - '-y1- ^L-i
1-5
-------
Information Security Manual 12/15/89
How vulnerable a particular information resource is to these threats depends on two
basic factors. The first is the type or nature of information involved, that is, the
relevance of each of the three security objectives. The second factor is the environ-
ment in which the information asset is used, for example, is a PC stand-alone or part
of a network. Information security involves identifying threats and applying controls
to prevent threats from being realized. When threats are realized (for example, dis-
closure or damage/loss of information), the three security objectives are not
achieved.
1.4 STRUCTURE OF THIS MANUAL
Security manuals are typically organized by type of security and include chapters on
physical security, data security, and communications security. While such manuals
provide good technical discussions of security controls, they typically overwhelm the
reader with a hodgepodge of safeguards that leave him/her unclear about exactly
which safeguards should be implemented. In addition, these manuals provide little
overall implementation guidance.
This manual is structured in a completely different manner. It is organized to allow
each reader, whether manager or staff member, to tailor it to his/her own particular
security situation. In a very real sense, the manual allows each reader to work
through his/her security problem by completing one or two worksheets and by
reading selected portions of the text.
Following the introductory material presented in this first section, Section 2 ad-
dresses individual and organizational information security responsibilities and is to
be read by all EPA managers and staff. Because it is not easy to coordinate the
diverse elements of an information security program, Section 2 recommends that
one management official, the Senior Information Resources Management Official
(SIRMO), be the focal point for information security in each major organizational unit.
Section 3 describes minimal security controls to be used regardless of the type of
information involved. Section 3 should also be read by all EPA managers and staff.
Section 4 is the last section that needs to be read by all managers and staff. Section
4 analyzes the need for additional security controls by determining whether or not the
reader has a sensitive information asset. Based on the Section 4 determination, the
1-6
-------
Information Security Manual 12/15/89
reader is referred to later sections of the manual as appropriate.
1.5 RELATIONSHIP TO OTHER SECURITY PROCEDURES
In this manual, the Office of Information Resources Management (OIRM) is estab-
lishing overall, Agency-wide security procedures for safeguarding EPA information
resources. Other EPA organizations have developed specialized procedures in
particular information security areas. As an important example, the National Data
Processing Division (NDPD) in Research Triangle Park issues technical policies
concerning systems (for example, Prime or VAX) supported and approved by it.
These policies are contained in the "NDPD Operational Policies Manual." In
addition, EPA organizations with statutory authority for certain types of information
(for example, the Office of Toxic Substances for TSCA CBI) issue security proce-
dures dealing exclusively with a certain type of information.
Nothing contained in this manual is intended to contradict or replace the specialized
security procedures of these other organizations. Those specialized procedures
supplement the core procedures presented in this manual. EPA organizations that
issue such procedures must ensure that they are consistent with this manual. EPA
employees must make sure they adhere to all such specialized procedures, as well
as to the procedures presented in this manual.
1-7
-------
Information Security Manual 12/15/89
2. INFORMATION SECURITY ROLES
AND RESPONSIBILITIES
2.1 BACKGROUND
Information security involves much more than technical hardware and software
issues. Above all, a successful information security program needs strong organ-
izational and administrative controls. Administrative/managerial factors such as top
management support and employee awareness contribute significantly to program
success. An information security program needs to involve all employees and to be
a part of the day-to-day operations of an organization.
Because of these factors, the Information Security Policy assigns information secu-
rity responsibilities to top management, to supervisors, and to employees. This
manual is intended to explain to EPA managers and staff how to comply with these
responsibilities without burdening programs and individuals. The remainder of this
section describes a suggested overall framework for implementing the Information
Security Policy.
The framework of security roles set forth in this section is not mandatory. While
programs must meet the requirements of the Information Security Policy, they may
find they are able to do so by creating somewhat different roles than those defined
here. OIRM recognizes that programs may need to modify the framework to meet
unique program needs. The framework is not meant to be inflexible and bureau-
cratic; instead, its intent is to assist programs and individuals in implementing
adequate protection of sensitive information.
2.2 INFORMATION SECURITY ROLES: AN INTRODUCTION
A common problem in information security is determining exactly who is responsible
for what aspects of security. In determining accountability for information security,
it is extremely useful to start with a framework of owner/user/custodian. Throughout
this manual, security actions are cast in terms of this framework, while oversight and
coordinating actions are the responsibility of management. The framework is
described in detail in the next subsection.
2-1
-------
Information Security Manual 12/15/89
It is important to recognize that there may not always be a one-to-one correspon-
dence between individuals and roles. In other words, at times it may be more
efficient to have several individuals share the responsibilities of a role. Again, the
framework described here is meant to be a flexible implementation tool.
2.2.1 Owners. Users, and Custodians
These three roles are defined as follows:
Application (or Information) Owner: The owner of the information is the
individual or organization who creates and sponsors it. Ownership in-
volves authority and responsibility forthe information, either in a program-
matic or administrative sense. For example, the Office of Solid Waste and
Emergency Response is the owner of RCRIS. The Office of Administra-
tion and Resources Management is the owner of IFMS. The owner
determines the sensitivity of the application (or information system),
assigns custody of the application, and decides who will be allowed to use
the application. Consulting with the custodian as appropriate, the owner
specifies and approves security controls and ensures that the application
is protected on an ongoing basis. The owneralso determines backup and
availability requirements and communicates them to the custodian.
Application (or Information) User: Users are individuals who are author-
ized by the owner to access an application or collection of information.
Custodian: Custodians possess (or have physical custody of) ADP equip-
ment or the files housing paper records. For example, for PCs and word
processors (WPs), the custodian is the individual to whom the PC or WP
is assigned, that is, the person responsible for the equipment in the
property management sense. In the minicomputer or mainframe environ-
ment, custodians are typically suppliers of information services who
possess, store, process, and transmit the information. For certain major
applications, the custodial role is shared by OIRM and the National
Computer Center (NCC). In these cases, OIRM acts as a "software
custodian," that is, OIRM acts as a custodian of the files, databases,
libraries, and programs that are stored and processed at NCC.
These roles are not always discrete; the owner can be the principal user and cus-
todian of the information. For example, an individual who develops an end-user ap-
plication for stand-alone processing on his or her own PC is at once the PC custodian,
application owner, and application user.
2.2.2 The SIRMO as Focal Point
Because information security covers a variety of information resources and involves
2-2
-------
Information Security Manual 12/15/89
so many different employees and supervisors, it is important to have one manage-
ment official in each major organizational unit coordinate the security program for
that organization. This individual will serve as a security focal point by identifying all
owners, custodians, and users, and by disseminating security-related information
throughout the organization. While each Primary Organization Head (as defined in
the policy statement) may designate whomever he/she wishes for this coordinating
role, the SIRMO is strongly recommended for this function. The designate may
delegate portions of this security function (for example, identifying owners) to other
knowledgeable individuals in the organization, as long as the Primary Organization
Head approves and as long as the coordinating role is retained.
2.2.3 Managerial and Administrative Roles
In addition to owners, users, custodians, and SIRMOs, the implementation of the se-
curity procedures in this manual also requires the involvement of several other
individuals in eight different roles. The first six of these roles exist at present while
the remaining two are unique to the security program.
The eight roles are:
Primary Organization Head
First-line supervisors
PC Site Coordinators
Records Management Officer (paper and microform)
Systems Analyst/Application Programmer
Local Area Network (LAN) System Administrator
Certifying Official: A management official(s) appointed by the Primary Or-
ganization Head. This official certifies that the security safeguards in
place for each sensitive application are adequate.
Minicomputer/Mainframe Security Officer: An official(s) appointed by the
Primary Organization Head to be responsible for security at the organiza-
tion's own on-site computer processing installation(s). The term computer
installation covers the range of computer processing capabilities from
large scale service center support for multiple users (such as NCC) down
to smaller general purpose systems for multiple users or dedicated use
(such as Prime or VAX systems). The term does not include personal
computer installations.
2-3
-------
Information Security Manual 12/15/89
2.2.4 Tying Roles to Information Assets
It is important to recognize that not all roles apply to all types of information assets.
Clearly, the role of Minicomputer/Mainframe Security Officer does not apply to PCs
and a PC site coordinator is not relevant for paper record systems. Table 2-1 ties
roles to the various types of assets.
2.3 ASSIGNING RESPONSIBILITIES TO THE SECURITY ROLES:
IMPLEMENTING INFORMATION SECURITY
Ensuring that information resources are adequately protected involves three differ-
ent management control processes. First, basic common-sense security measures
need to be implemented for ADP equipment, regardless of whether or not it
processes sensitive information. Second, an application certification process must
be established to determine the sensitivity of each automated application and to
certify that the security safeguards for each sensitive automated application are ade-
quate. Third, an installation risk analysis process needs to be established to make
sure that the security measures in place at the installation adequately protect the
sensitive automated applications stored and processed there. Note that the second
and third processes establish a structure of security checks and balances. They
approach information security both from an installation or equipment perspective
and from an application (or information system) perspective.
Each of the three management control processes is described in more detail below.
Table 2-2 lays out the security responsibilities associated with the processes on a
role-by-role basis.
2.3.1 Minimal Controls
Section 3 describes the safeguards that need to be in place to ensure the basic
physical and environmental protection of ADP equipment and magnetic media.
Section 3 also sets forth administrative procedures governing the use of computers
and commercial software. Minimal controls for PCs and word processors are imple-
mented by custodians or users as appropriate, with oversight provided by the
cognizant PC site coordinator. Minimal controls for minicomputer/mainframe instal-
lations are implemented by the Minicomputer/Mainframe Security Officer.
2-4
-------
Information Security Manual
12/15/89
TABLE 2-1
TYING SECURITY ROLES TO INFORMATION ASSETS
Primary Organization Head
SIRMO
Owner
PC/WP Custodian
Mini/Mainframe
Security Officer
User
Supervisor
PC Site Coordinators
Certifying Officer
LAN Administrator
Records Management
Officer
Application Programmer/
Systems Analyst
Information Resource or Asset
Mini/
Mainframe
Installation PC
WP
Paper/ Software
Microform Development/
Records Maintenance
2-5
-------
Information Security Manual
12/15/89
TABLE 2-2
IMPLEMENTING A MANAGEMENT CONTROL PROCESS FOR
INFORMATION SECURITY: RESPONSIBILITIES BY ROLE
Role
Primary Organization Head
SIRMO
Application (or Information System Owner)
PC/Word Processor Custodian
Minicomputer/Mainframe Security Officer
Application (or Information System) User
Supervisor
PC Site Coordinator
Certifying Officer
LAN System Administrator
Records Management Officer
Applications Programmer/Systems Analyst
Responsibilities
Implements the organization-wide security pro-
gram. Designates Certifying Officer(s). Assigns
a person the responsibility for information
security at each installation.
Coordinates the organization-wide security
program. Identifies owners, users, and
custodians.
Determines information sensitivity. Assigns cus-
tody. Initiates application certification process.
Authorizes users. Specifies and approves
security controls. Specifies backup and avail-
ability requirements. Makes sure users and
custodian adhere to security requirements.
Responsible for the security of his/her equip-
ment. Must implement minimal controls.
Performs risk analysis.
Responsible for the security of the equipment
at the installation. Implements minimal controls.
Performs risk analysis. Establishes disaster
recovery/continuity of operations plan. Assists
owner in selecting controls during system
development/operation.
Adheres to security requirements of owner.
Reviews application certification form. Ensures
employees fully comply with information
security responsibilities.
Ensures minimal controls are in place. Advises
owner on application certification process.
Certifies sensitive applications. Advises owner
on application certification process.
Coordinates the selection of security safe-
guards for networks.
Responsible for ensuring that controls are in
place for his/her "manual" record systems.
Incorporates controls into software. Coordinates
selection of safeguards with owner and
custodian.
2-6
-------
Information Security Manual 12/15/89
2.3.2 Sensitivity Determination. Automated Application Risk Analysis, and
Automated Application Certification
The requirements of the certification process, including the completion of the Appli-
cation Certification Worksheet, are described in detail in Appendix B. Key elements
of the process are summarized below:
Each Primary Organization Head will designate one or more Certifying Of-
ficials for his/her organization.
Each application/information owner will determine the sensitivity of each
of his/her applications or collections of information. This determination will
be made in accordance with the instructions set forth in Section 4 of this
manual.
Each sensitive automated application must undergo initial certification
and then review or audit leading to re-certification every three years. The
certification or recertification process will begin with the application
owner's completion of the Application Certification Worksheet. The work-
sheet will capture basic information on application sensitivity, security
specifications, design reviews, and tests of security safeguards.
When the worksheet is complete, it will be forwarded through the owner's
immediate supervisorto the cognizant Certifying Official for approval/dis-
approval.
The worksheet will be used by the application owner to communicate the
sensitivity of the application and the required security procedures to the
users of the application.
It should be noted that in developing the worksheet, the owner performs
a qualitative risk analysis, that is, the owner assesses the relative vulnera-
bilities and threats to the application and then specifies safeguards.
2.3.3 Installation Risk Analysis Process
All Agency installations, including PCs and word processors, are requiredto undergo
a risk analysis. A risk analysis is a means of measuring and assessing the relative
vulnerabilities and threats to an installation. Its purpose is to determine how security
safeguards can be effectively applied to minimize potential loss. In everyday terms,
risk analysis is a procedure for identifying what could go wrong, how likely it is that
things could go wrong, and what can be done to prevent them from going wrong.
There are two accepted methods for performing a risk analysis quantitative and
2-7
-------
Information Security Manual 12/15/89
qualitative. For all Agency installations, a qualitative risk analysis approach may
be used. Simply put, this method handles typical situations quickly and efficiently by
combining the analysis of risks with safeguard selection. It consists of the following
basic components:
Determine what information is sensitive and non-sensitive. This determi-
nation will be made in accordance with the instructions set forth in Section
4 of this manual. If the installation does not process any sensitive
information, the risk analysis is at an end and only minimal controls need
to be implemented. If the installation does process sensitive information,
categorize the sensitive information, for example, "confidential" sensitive.
For each category of sensitive information, determine the level of sensi-
tivity, for example, highly confidential.
Decide on an overall set of safeguards or security controls to use.
Tie subsetsof those safeguardstoparticularcategories of information and
to levels of sensitivity.
Implementation of a PC or word processor installation risk analysis is the responsi-
bility of the custodian. Implementation of a minicomputer/mainframe installation risk
analysis is the responsibility of that installation's Security Officer. By working
through this manual, an informal and qualitative risk analysis will be performed. The
custodian or Security Officer need only adhere to the procedures presented in this
document and complete the Risk Analysis Worksheet described in Appendix C. No
special analytical process has to be undertaken.
Under certain circumstances, PC custodians and Security Officers may feel that
more rigorous, quantitative methods are warranted. OIRM does not wish to prohibit
quantitative analyses. Interested individuals should reviewthe last section of Appen-
dix C for more information.
2.4 STREAMLINING THE IMPLEMENTATION OF INFORMATION SECURITY
In establishing these management control processes, OIRM wants to achieve ade-
quate security throughout the Agency without unduly burdening programs and indi-
viduals. To that end, organizations may find that the following can help streamline
the management control processes discussed above:
In some organizations, one individual (or a handful of individuals) may be
knowledgeable enough about an information asset (forexample, PCs and
2-8
-------
Information Security Manual 12/15/89
the information contained on them) to function as a composite or aggre-
gate owner, user, and custodian for the asset. In other words, the
individual has the requisite knowledge to complete the organization's
Application Certification and Risk Analysis Worksheets, not just the work-
sheets for his/her own hardware and applications. This aggregated
approach is consistent with the owner/user/custodian framework and is an
acceptable approach to achieving compliance.
In identifying applications for sensitivity determination and certification, in-
dividuals/organizations may find that some applications are subsystems
or "children" of larger "mother" applications. Similarly, some applications
may be so related that the boundaries between them are fuzzy and that
for the purposes of this document they can be thought of as one. In
implementing the certification process, such sensitive applications may
be combined into a single sensitive application. A key test of whether or
not a sensitive application has been properly delineated is whether or not
the questions on the certification worksheet can be meaningfully an-
swered. If the responses are full of exceptions and two-part answers, the
aggregation is probably incorrect.
2.5 ORGANIZATIONAL SECURITY REPORT
To tie together the diverse elements of its information security program, each major
organizational unit (corresponding to each Primary Organization Head) will prepare
an annual security report. In establishing this reporting requirement, OIRM wants to
make sure organizations are implementing and maintaining security safeguards;
OIRM does not want to bog organizations down in atime-consuming paper exercise.
To that end, the report will be a compilation of the worksheets and documents
prepared during the day-to-day implementation of each organization's security
program.
Specifically, the report should contain the following:
A listing of all sensitive automated information systems in the organization
Copies of Application Certification Worksheets and Installation Risk
Analysis Worksheets prepared in the organization within the past year
Copies of installation disaster recovery/continuity of operations plans or
quantitative installation risk analyses prepared or updated in the last year
Copies of any local security procedures developed in the last year
A statement, signed by the SIRMO, that all employees in the organization
2-9
-------
Information Security Manual 12/15/89
have completed basic security awareness training (per Section 5.5)
Descriptions of any security concerns or weaknesses that the organiza-
tion may wish to discuss. This could include weaknesses identified as part
of audits, vulnerability assessments, or other internal control review
processes.
The security report should be sent by the end of each calendar year to the Director,
OIRM. The first report will be due at the end of 1990. The report will provide OIRM
with evidence of compliance with the security program.
2.6 SECURITY PLANS
The Computer Security Act of 1987 required the EPA to prepare security plans for
certain of its applications and computer processing installations. The purpose of the
security plan was to provide a basic overview of the security requirements of the
subject application or installation and EPA's plan for meeting those requirements.
The plan was not intended to be a detailed technical description of risks or security
mechanisms. The plans were a new reporting requirement for agencies; they were
not designed to replace such existing processes as application certification.
Completed security plans were submitted in FY 1989 to the National Institute of
Standards and Technology (NIST) (formerly the National Bureau of Standards) and
to the National Security Agency (NSA) for comment and review. Requirements for
FY 1990 and beyond have not yet been determined by NIST, NSA or the Office of
Management and Budget. Organizations will be informed of any reporting require-
ments under separate cover.
2-10
-------
Information Security Manual 12/15/89
3. MINIMAL SECURITY CONTROLS FOR
MINICOMPUTER/MAINFRAME INSTALLATIONS,
PCs, PC LANs, AND WORD PROCESSORS
3.1 INTRODUCTION
This section applies to all individuals with security responsibilities for minicomputer/
mainframe installations, PCs, or word processors (such as PC users, PC custodians,
LAN Administrators, or Computer Installation Security Officers). This section does
not apply to individuals with security responsibilities for paper records or for applica-
tion system development. Because there are no minimal security controls associ-
ated with paper records or application system development, individuals responsible
only for these types of assets should skip to Section 4.
The purposes of this section are: (1) to describe the security measures that need
to be taken to ensure the basic physical and environmental protection of ADP
equipment and magnetic media, and (2) to set forth administrative procedures
governing the use of computers and commercial software. All measures described
in this section can be implemented at little or no cost, ensuring their overall cost-
effectiveness. The emphasis here is on common-sense measures that are justified
without a risk analysis. Section 3.2 below deals with PCs and word processors;
Section 3.3 addresses minimal controls for minicomputer/mainframe installations.
3.2 MINIMAL CONTROLS FOR PCs, PC LANS, AND WORD PROCESSORS
The responsibility for making sure these controls are in place rests with custodians
or users as indicated below. Cognizant PC site coordinators should ensure compli-
ance with these requirements through periodic, informal inspections.
3.2.1 Physical Controls
Agency physical security procedures issued by the Facilities Management and
Services Division (FMSD) state that:
"All office equipment...should be locked up when not in
use...Cables and anchor pads can be used to secure
typewriters, calculators, computer peripherals, and the
like. See SCR 1-08 for information about locking de-
vices." (Directives Volume 4850-1, SCR 1-06, page 7)
3-1
-------
Information Security Manual 12/15/89
Consistent with these procedures, the following controls for PCs and word proces-
sors are required to prevent theft and physical damage. Custodians are responsible
for ensuring that these controls are in place.
Locate equipment away from heavily traveled and easily accessible areas
to the extent possible.
When possible, install the device in a locked room, making sure the lock
is used whenever the room is unoccupied (and not just at night). If the
device cannot be installed in a locked room, a locking device such as a
locking anchor pad or hardened cables can be used. For further informa-
tion or assistance, contact the Security Management Section of FMSD.
All IBM PC/AT and most compatible microcomputers are delivered with
standard system locks which prevent the system from being operated and
prevent the cover from being removed, guarding against component theft.
Use these locks. When adding valuable expansion boards (such as
additional memory or graphics interfaces) to PCs that do not have factory-
installed locks, install a cover lock.
Place equipment and peripherals on stable and secure platforms away
from objects that could fall on them.
Portable PCs require additional security considerations because their
portability increases their vulnerability to theft. In addition to the physical
security measurers already mentioned, store all portable PCs in a locked
cabinet when not in use. For further information or assistance, contact
the Security Management Section of FMSD. Assign a person to track the
location of the portable PCs on a regular basis, log them out for use to
authorized users, and ensure the portable PCs have been returned to the
locked storage area when not in use. Moreover, any employee removing
a portable PC from an EPA building for official use must have a property
pass.
3.2.2 Environmental Controls
Custodians are responsible for ensuring that the following controls are in place:
PCs and word processors are sensitive to surges in electrical power. To
provide protection against current surges, install a surge protection
device. Good quality, multi-stage surge protectors are available for under
$100.
Do not install the device in direct sunlight or in a location with extremes of
hot and cold temperatures (less than 50 degrees Fahrenheit or greater
than 100 degrees Fahrenheit). Do not leave a portable PC in a parked
car, which would also subject it to temperature extremes.
3-2
-------
Information Security Manual 12/15/89
Equipment (and media) are sensitive to contamination from dirt, smoke,
or magnetic fields. Do not eat or drink in the immediate vicinity of the
equipment and media. In accordance with the Agency's smoking policy,
do not smoke in the vicinity of the equipment. (Smoke is drawn into the
vents and through the disk units, covering the units with tar. Tar reduces
the life of the disk and the read head.)
To avoid problems from dust and possible overhead water leaks, protect
equipment with inexpensive plastic covers when not in use. Install the
equipment as far as practical from overhead water pipes or sprinkler
heads.
Control static electrical charges by placing antistatic mats under the
equipment or workstation or by using antistatic sprays. (Laundry fabric
softeners containing antistatic ingredients can be used for this purpose
and they are quite inexpensive when compared to special purpose
antistatic sprays.) Because the problem of static electricity is increased
when the air is extremely dry, it can be reduced by the use of humidifiers
if these are available.
3.2.3 Magnetic Media Controls
At present, virtually all information on microsystems is stored on magnetic media in
the following forms:
Diskettes
Fixed disks inside the computer
Cartridge tapes
Removable disk cartridges (for example, Bernoulli cartridges).
PC and word processor users need to treat the magnetic media with special care.
Flexible diskettes are especially susceptible to damage.
Keep all magnetic media away from all electrical devices and magnets to
avoid magnetic fields. This includes magnetic paper clip holders, building
passes or credit cards with magnetized strips, PC hard drive units, and
telephones. For example, if a diskette is left on a desk and a telephone
is placed over the diskette, data on the diskette may be destroyed when
the telephone rings.
Do not flex diskettes. Bending the media can damage its delicate surface
and destroy data.
Store diskettes in their jackets as soon as they are removed from the
equipment. The jackets are made of a special material that is intended to
3-3
-------
Information Security Manual 12/15/89
protect the diskette. Cartridge tapes and removable disk cartridges
should also be stored in their original containers.
Never touch the surface of the diskette platter.
Do not write on a diskette with a pencil or hard-tipped pen. Useonlyasoft-
tipped marker.
Keep diskettes in a disk file container when not in use. Dust and other par-
ticulate materials can scratch and damage the disk.
To prevent permanent loss of data on the fixed disk drive, all files need to
be backed up and the heads need to be parked before a PC is moved.
Some portable PCs also may require that the heads be parked and/or a
disk inserted into the disk drive when transporting the portable.
3.2.4 Backups
When it comes to making backups of data and programs, it unfortunately seems that
experience is the best teacher. A user often needs to lose an important file before
he/she realizes the importance of backup.
For certain types of applications (discussed later in Sections 4 and 6), routine and
systematic backups are of particular importance and this manual sets forth specific
backup procedures. As a minimal control, however, users should be in the habit of
regularly backing up their work. While a precise set of criteria for determining how
often to make these backups cannot be provided, how active the data file is and how
long it took to create are key factors to consider. The appropriate backup media can
vary and can include floppy disks, cartridge tapes, removable disk cartridges, or
remote hosts such as minicomputers.
Users should note that if they are using their PC as a terminal for processing data
and programs stored at another site (such as a minicomputer, LAN file server, or
mainframe facility like the National Computer Center), that site may already be
backing up the data on a regular basis. Consult the manager of the remote facility
or the LAN System Administrator for information.
3.2.5 Software Copyrights/Licenses and Master Copies
Owners and users who purchase commercial software must follow the procedures
below. Supervisors are responsible for ensuring that their employees adhere to
these procedures.
3-4
-------
Information Security Manual 12/15/89
Commercial software is typically under copyright and accompanied by a
licensing agreement which specifies whether copies may be made. EPA
employees must adhere to these licensing agreements; unauthorized
duplication of software is strictly prohibited and is not condoned by the
Agency under any circumstances. A copyright means that any duplicat-
ing, selling, or other distribution of the software for other than backup use
by the lawful user(s) is a crime. Willful violations of U.S. copyright law can
result in significant penalties (civil damages of up to $50,000 in addition
to actual damages plus criminal penalties of up to one year in jail and/or
a $10,000 fine).
In general, there are two types of licensessingle-machine and site. A
single-machine license allows the user to install the master copy of the
software on his/her machine only. With a site license, the software may
be installed on more than one machine, typically for a higher fee.
Software purchased by EPA must be used exclusively on PCs and word
processors owned by EPA.
Software licensing agreements should be signed upon receipt and imme-
diately filed with the vendor. A copy of the agreement containing the
registration number should be filed in a safe place. Returning the agree-
ment to the vendor will register the purchase and may result in free user
assistance, free or reduced price software upgrades, and other advan-
tages. Registration of the software will also provide the basis for getting
assistance from the manufacturer if the software is lost, stolen, or
damaged.
Existing OIRM procedures concerning master copies of software state
that each Primary Organization Head needs to establish a central reposi-
tory for the organization's master copies to ensure accountability and
control. The Washington Information Center (WIC) can be used for this
purpose if an organization executes an Operational Service Agreement
for Archiving of PC Software.
3.2.6 Unauthorized Use of Personal Computers. Word Processors, and
Associated Software
EPA PCs, word processors, and associated software are for official EPA business
only. Use of these devices is not allowed for personal business of any kind, even
if it is done on the employee's own time. Appropriation of EPA-owned software for
personal use, whether done by unauthorized copying or by actual removal of the
master software, is prohibited. Training and practice on EPA PCs and word
processors should be done using work-related examples. Employees who use this
equipment for other than official Agency business are subject to disciplinary action
ranging from a reprimand to dismissal.
3-5
-------
Information Security Manual 12/15/89
3.2.7 Non-EPA Software and Viruses
Computer viruses have received a great deal of attention in the press. While some
of the coverage is sensational, it is clear that the problem is real and that risk does
exist. The threat of viruses has made the need for regular backups (per Section
3.2.4) even greater.
In general, a computer virus is an extra program hidden within an apparently normal
program or software package referred to as the virus "host" or 'Trojan Horse". Like
a biological virus, the computer virus has two important characteristics it can
replicate itself and it can cause harm or mischief. This replicating ability means that
a virus can quickly spread via shared diskettes, networks, electronic bulletin boards,
or file servers as programs or files are stored, executed, uploaded, or downloaded.
Potentially infected host software includes operating system tools such as an editor
or file utility, data base management software, or spreadsheet macro languages.
Some viruses are relatively harmless and only flash a message on the monitor before
destroying themselves. Others are truly malicious and modify or destroy programs
and data. To detect and combat viruses, a number of specialized programs or
software "vaccines" have been developed. Because various computer viruses op-
erate in different ways, no single vaccine is currently effective against all of them.
Indeed, some of the vaccines have harbored viruses themselves.
Under these circumstances, it is not possible to develop a set of generic, straightfor-
ward procedures to ensure the integrity of non-EPA or public domain software.
Consequently, EPA employees should not install non-EPA or public domain soft-
ware on theircomputers without the express approval of their SIRMOortheSIRMO's
designate. In addition, EPA employees and contractors who use PCs or LANs
supported and approved by NDPD are also subject to virus prevention policies set
forth in the "NDPD Operational Policies Manual." Those policies include recom-
mendations related to new software, backups, and regular checks for program/file
size changes.
Readers may also wish to consultthe additional guidance presented in NIST Special
Publication 500-166, entitled "Computer Viruses and Related Threats: A Manage-
ment Guide." The publication, which was issued in August 1989, provides general
guidance for managing the threats of computer viruses and unauthorized use. It
deals with different computing configurations such as multi-user systems, personal
3-6
-------
Information Security Manual 12/15/89
computers, and networks. A copy is available in the EPA Headquarters Library or
through the Government Printing Office.
3.3 MINIMAL CONTROLS FOR MINICOMPUTER/MAINFRAME
INSTALLATIONS
Computer Installation Security Officers are responsible for making sure the following
controls are in place.
3.3.1 Physical Controls
Locate computer installations away from heavily traveled and easily ac-
cessible areas, and away from potential sources of explosions (such as
boiler rooms, laboratories, or hot water heaters). When choosing a site,
take advantage of existing physical security.
Avoid locating installations on the ground floor, where an intruder is more
likely.
Install locks on doors and windows. Make sure the lock is used whenever
the room is unoccupied (and not just at night).
Limit the number of entrances to the installation to those needed for
effective, efficient operations.
3.3.2 Environmental Controls
When possible, locate master power switches near emergency exits. The
switch should cut all power to the computer system and should also turn
off the air conditioning system if it is not designed to filter out smoke. Make
sure these master switches are clearly labeled to avoid an accidental
power shut-down.
Mount hand-held fire extinguishers in visible, accessible areas. Usetypes
that will not damage computer equipment, that is, do not use extinguishers
that emit water or powder.
Install smoke and heat detectors.
Avoid installing the computer room underneath water pipes or steam
pipes. If this is not possible, use water sensors to detect water seepage.
Store waterproof plastic in a visible, accessible location so that it can be
draped over equipment in the event of an emergency.
Computer equipment (and media) are sensitive to contamination from dirt,
3-7
-------
Information Security Manual 12/15/89
dust, and smoke. Prohibit eating, drinking, and smoking in the computer
room. To cut down on dust, avoid coat racks, throw rugs, Venetian blinds,
and other furnishings that collect dust and static electricity. Vacuum
carpeted areas frequently.
Control static electrical charges by using antistatic carpeting or sprays.
Laundry fabric softeners containing antistatic ingredients can be used for
this purpose and they are quite inexpensive when compared to special
purpose antistatic sprays.
To reduce fire hazards, never store flammables in the computer room.
Keep on-site paper supplies to a minimum.
3.3.3 Configuration Management and Change Control
Because threats can be introduced through unauthorized hardware or software, only
Agency authorized hardware and software should be used. Before installation,
changes to both hardware and software need to be tested and properly authorized.
To help achieve effective configuration management, adhere to the following
procedures:
Maintain accurate records of hardware/software inventories, configura-
tions, and equipment locations.
Comply with the terms of software licensing agreements. Penalties for
violations of U.S. copyright law are set forth in Section 3.2.5 above.
Adhere to the procedures concerning non-EPA software and viruses that
are set forth in Section 3.2.7 above.
More detailed guidance concerning configuration management and change control
as they relate to the software life cycle is contained in the EPA "Operations and
Maintenance Manual."
3.3.4 Unauthorized Use of Computers and Software
EPA computers and associated software are for official EPA business only. Use of
these computers is not allowed for personal business of any kind, even if it is done
on the employee's own time. Employees who use hardware and software for other
than official Agency business are subject to disciplinary action ranging from a
reprimand to dismissal.
3-8
-------
Information Security Manual 12/15/89
4. DETERMINING THE NEED FOR
ADDITIONAL CONTROLS
The minimal controls described in Section 3 are always required regardless of
information sensitivity. The purpose of this section is to determine whether or not
additional controls are necessary.
Application/information owners use this section to evaluate the sensitivity of each
of his/her applications or collections of information. Determining sensitivity is an
owner responsibility. If sensitive applications/information are owned, later sections
of this manual need to be consulted to determine safeguards and to develop the
information required for the application certification process and the Application
Certification Worksheet (see Appendix B).
Application/information users review this section to develop a working understand-
ing of information sensitivity. Users can also use this section to determine the
sensitivity of applications or collections of information not yet evaluated by the owner
(for example, existing applications that are undergoing certification). Later sections
of this manual should then be reviewed as appropriate.
PC custodians. LAN System Administrators, and Minicomputer/Mainframe Security
Officers review this section to develop a working understanding of information
sensitivity. They then combine this understanding with owner sensitivity designa-
tions to determine the number and type of sensitive applications being processed by
users of his/her installation. This determination becomes an input to the risk analy-
sis process outlined in Appendix C.
4.1 DETERMINING SENSITIVITY AND THE TYPE OF INFORMATION
The reader should review Section 2.4 before proceeding. That section contains in-
formation on combining applications or collections of information for sensitivity
determination purposes.
The questions presented in the sensitivity evaluation table (Table 4-1) are designed
to determine whether a particular application or collection of information is sensitive.
To use the table, first read through all 11 questions presented in columns (1 )-(11) of
4-1
-------
r
Nameol
Application/
Information
EXAMPLE-
QUESTIONS
0)
National
Security
(2)
Drtlcalto
'ertormlng a
Primary
Agency
Mission?
YES
3)
Lie Critical?
4)
Financial
Where
riisuse Could
Causa Loss?
5)
Automated
Decision-
Making
Application?
6)
Subject to the
Privacy Act?
YES
7)
Confidential
Jtnlnoss
rtormatton?
B)
nforooment
Conlldentlal?
9)
ludgetary
Prior to OMB
Release?
10)
High
Value?
11)
Other
Sensitive?
OBJECTIVE/LEVEL
I
HIGH
£
I
HIGH
i
MEDIUM
~
o
03
I
m
n
O
3-H
z >
05 DO
HI-
is
D)
3
C
0)
NOTES:
Question (2)
Question (3)
Question (4)
Question (5)
Question (10)
Question (11)
Answer YES il disablement or unavailability ol the application, or the loss, compromise, or undesired alteration of the information could jeopardize the Agency's ability to perform a primary
mission.
Answer YES il the loss ol information or disruption ol the application could jeopardize human life or welfare.
Relates to check issuance, funds transfer, etc., where misuse could cause loss.
Answer YES if the application makes unsupervised automated decisions based on programmed criteria (for example, issuing checks, ordering supplies, or performing similar asset
accounting/control functions) and if the wrong automated decision could cause loss.
Answer YES il this is an application/information of "High Value' to the Agency or a particular organization. The term 'High Value' must be defined by the owner ol the information or
application. While a precise set of criteria for determining High Value cannot be provided, the cost of replacing the information and the problems that would result from doing without the
information are primary factors to consider.
Answer YES if: (1) you answered NO to all other questions, and (2) this is an application/information whose loss would acutely embarrass the Agency, subject the Agency to litigation, or
impair the long-run ability of the Agency to fulfill its mission.
cn
00
CD
-------
Information Security Manual 12/15/89
the table.
If all questions can be answered "No" for all applications/information, the remainder
of this manual does not apply. If any question can be answered "Yes" for any
application or collection of information, continue with the instructions in the next
paragraph. (After completing the table, make sure to have it reviewed as described
in Section 4.3.)
The table has been designed to be a worksheet for evaluating sensitivity. To use the
table, list in the first column the name of each application or collection of information
for which at least one question can be answered "Yes." For each listed application
or collection of information, answer each question. A sample entry is provided.
(Leave the last three columns (security objectives) blank for the time being; how to
use these columns is explained below.) If more than one type of sensitive information
asset is at issue (for example, three sensitive paper record systems and two sensitive
PC applications), fill out a separate worksheet for each type of asset.
4.2 DETERMINING RELEVANTSECURITY OBJECTIVES AND THE DEGREE
OF SENSITIVITY
The next step is to determine the degree of sensitivity and the relevance of each of
the three security objectives. Table 4-2 maps each type of information to its
corresponding objective(s) and sensitivity level (that is, high versus medium).
(Cases of little or no sensitivity are covered by the minimal controls specified in
Section 3.)
For each application or collection of information, determine the relevant security
objective(s) and sensitivity level(s) based on the type of information the application/
collection contains. Note that the time value of critical information/applications must
be evaluated to determine sensitivity level, and the approximate dollar value of high
value information/applications must be estimated to determine sensitivity level.
Most life critical and mission critical applications will probably involve high level
sensitivity.
It may be helpful to make notes about security objectives and sensitivity levels in the
last three columns of the Table 4-1 worksheet. A sample entry is provided. In
instances where an application or collection of information turns out to be at both the
4-3
-------
Information Security Manual 12/15/89
TABLE 4-2
DETERMINING RELEVANT SECURITY OBJECTIVES
AND DEGREE OF SENSITIVITY
Availability Integrity Confidentiality
High Med. High Med. High Med.
Type of Information Level Level Level Level Level Level
National Security Information x
Critical to Performing a
Primary Agency Mission
-Must be Available Continu-
ously or Within 1 Day x x
-Must be Available
Within 1 -5 Days x x
Life Critical
-Must be Available Continu-
ously or Within 1 Day x
-Must be Available
Within 1-5 Days x
Financial Where Misuse
Could Cause Loss x
Automated Decision-
Making Application x
Subject to the Privacy Act x
Confidential
Business Information x
Enforcement Confidential x
Budgetary Prior to
OMB Release x
High Value
-Very High Value* x
-Other High Value x
Other** xxx
"While a precise set of criteria for distinguishing between "very high value" and "other high value"
cannot be provided, the cost of replacing the information is the primary factor to consider. Clearly, an
automatedinformationsystemthatcost$3,000,000ormoretodevelopandprogramwouldbeof"very
high value."
" Reader must determine which objectives are relevant based on characteristics of information/
application.
4-4
-------
Information Security Manual 12/15/89
high and medium sensitivity levels vis-a-vis an objective, the higher level dominates.
For example, an application that contained both National Security Information (high
level confidentiality) and Privacy Act data (medium level confidentiality) would be of
high level confidentiality.
By completing the Table 4-1 worksheet, a security profile is developed that includes
information on types of sensitive information or applications, security objectives, and
sensitivity levels. The security profile contains the basic information owners need to
complete the top of the Application Certification Worksheet. It also contains the basic
information PC custodians and Security Officers need to complete the top of the
Installation Risk Analysis Worksheet.
4.3 VALIDATING SENSITIVITY RESULTS
Determinations of sensitivity and degree of sensitivity must always be reviewed by
the cognizant supervisor. Because implementing security safeguards can involve
considerable expense and investment of staff time, management review of these
determinations is important.
Management review is also important because some of these determinations can in-
volve an element of judgment for which an organizational perspective is important.
Critical or high value information is not as easily identified as Confidential Business
Information or Privacy Act data. There may be a tendency for individuals to
overdesignate theirapplication as critical or high value. SIRMOs should be consulted
when employees and supervisors need guidance in making a sensitivity determina-
tion.
4.4 USING THE REST OF THIS MANUAL
The next section, Section 5, discusses personnel security. This section needs to be
read by all EPA managers and staff who have sensitive applications or information.
The remainder of the manual, Sections 6-10, is organized on an information
resource-by-information resource basis, such as PCs or paper records. Within each
of these sections, procedures are presented in terms of security objective, for
4-5
-------
Information Security Manual 12/15/89
example, security procedures to maintain high-level availability. Read only those
sections and subsections that are applicable. If more than one security objective is
applicable (for example, an application where both availability and confidentiality are
relevant), make sure to read the subsection pertaining to each applicable objective.
4-6
-------
Information Security Manual 12/15/89
5. PERSONNEL SECURITY AND TRAINING
5.1 INTRODUCTION
Given the large number of Agency information resources, security is as much a
people issue as it is a technical issue. SIRMOs need to make sure that cognizant
supervisors in their organizations adhere to the following procedures.
5.2 SCREENING AND CLEARANCE
Federal regulations require clearance of all persons involved in the design, develop-
ment, maintenance, and operation of sensitive automated systems and facilities.
These requirements apply to Federal employees and to the personnel of agents
(including contractors and grantees) of the EPA who have access to sensitive EPA
information. Determinations of the degree of sensitivity of each position are accom-
plished by the program office. The level of screening required should then vary from
minimal checks to full background investigations, depending upon the sensitivity of
the information to be handled by the individual in the position and the risk and mag-
nitude of loss or harm that could be caused by the individual. The responsibility for
the implementation and oversight of the personnel clearance program rests with the
Office of the Inspector General and the Personnel Management Division. EPA
organizations should consult with them when obtaining clearances or designating
sensitive positions.
5.3 SEPARATION OF DUTIES
An individual has a hardertime concealing errors and irregularities if he/she does not
control all aspects of an activity or transaction. For example, by separating the
functions of cash handling and bookkeeping, the bookkeeper cannot get to the cash
and the cash register clerk cannot adjust the books to hide cash shortages.
To the extent possible, the following 11 functions should be assigned to different
individuals:
Data Creation and Control Functions:
1. Data collection and preparation
2. Data entry
5-1
-------
Information Security Manual 12/15/89
3. Data base administration
4. Custody of data
Software Development and Maintenance Functions:
5. Applications programming
6. Design review
7. Application testing and evaluation
8. Application maintenance
Administrative Functions:
9. Security planning
10. Security implementation
11. Security audit.
Given the very definition of personal computing, it is often impractical to separate
functions for PCs. The same individual often collects data, programs the application,
enters the data, and generates the reports. Given the realities of computer-related
staffing, it is also sometimes difficult to separate functions in the minicomputer or
mainframe environment. To minimize the potential for fraud, abuse, or sabotage,
these functions should be performed by separate individuals to the maximum extent
practicable. When it is not possible to have each function performed by a different
individual, try to separate the following: (1) data creation/control functions from
software development/maintenance functions, (2) application programming and
maintenance functions from design review and testing/evaluation functions, and
(3) security audit from all other functions.
In the case of all financial applications (relating to check issuance, funds transfer, and
the like) where misuse could cause loss, separation of functions or duties is
mandatory. This separation also applies to financial applications which may be PC-
based. For example, the task of preparing payment vouchers must be kept separate
from the task of approving payments. For such financial applications, other preven-
tive measures include periodically rotating jobs and asking people to take vacations
of one to two weeks. Because the perpetrator of a fraud often has to manipulate
accounts on a daily basis to avoid detection, these measures may be a strong
deterrent.
5.4 TERMINATION/SEPARATION
In the event an employee must be removed or laid off, it is a good idea to rotate the
employee to a non-sensitive position prior to giving notice of the action. While this
5-2
-------
Information Security Manual 12/15/89
may seem extreme, angry and demoralized employees have been known to
sabotage programs, erase data bases, or plant computer viruses.
Regardless of the type of separation (resignation, removal, etc.), supervisors need
to make sure the following actions are performed for personnel separating from a
sensitive position:
Change or cancel all passwords, codes, user IDs, and locks associated
with the separating individual
Collect all keys, badges, and similar items
Reconcile any financial accounts over which the employee had control.
The SIRMO or his/herdesignate should then certify thatthese procedures have been
accomplished by signing and dating a short statement that says: "Information
security procedures for separating employee (NAME) have been completed."
These statements should be kept on file for inspection by OIRM or the Office of the
Inspector General.
5.5 TRAINING
The Office of Administration and Resources Management (OARM) is coordinating
the development of a comprehensive information security training program for the
Agency to supplement the procedures in this manual. Details and requirements of
the program will be issued under separate cover. These requirements will include
mandatory basic security awareness training for every employee. The program will
include both information security awareness training for all employees and training
in accepted security practices for those employees involved in the management,
use, or operation of sensitive information. The program will identify and reference,
as appropriate, existing training in the information security area, such as training
done by NDPD.
5-3
-------
Information Security Manual 12/15/89
6. SECURITY FOR MINICOMPUTER AND
MAINFRAME INSTALLATIONS
6.1 INTRODUCTION
This section sets forth security procedures for minicomputer and mainframe instal-
lations. Installations of this type coverthe range of computer processing capabilities
from large scale service center support for multiple users (such as the NCC) down
to smaller general purpose systems for multiple users or dedicated use (such as
Prime or VAX systems).
Minicomputer/Mainframe Security Officers are responsible for implementing the
procedures in this section. Because of the size of WIC and NCC, certain of the
procedures below apply only to the Security Officers of those two installations.
However, NCC/WIC procedures may also be appropriate for other installations,
depending on the results of the risk analyses performed for those installations. Pro-
cedures that distinguish between NCC/WIC and other installations will be clearly
identified.
The remainder of this section is organized as follows. Because the selection of
safeguards or security measures fora minicomputer/mainframe installation needs
to begin with a risk analysis, Subsection 6.2 introduces techniques for performing
this analysis. Subsection 6.3 introduces a second important technique disaster
recovery and continuity of operations planning. Subsection 6.4 specifies controls
that help achieve all three security objectives simultaneously. The last three
subsections set forth specific controls for ensuring the availability, integrity, or
confidentiality of installation information resources. If more than one objective
applies to the installation (for example, availability and confidentiality), make sure to
review the subsection for each applicable objective.
The reader must note that NDPD issues technical policies (for example, governing
passwords or backup frequency) for systems supported and approved by it.
Readers also need to refer to these policies, which are contained in the "NDPD
Operational Policies Manual". These policies are typically more hardware specific
and technically oriented than the procedures presented here. Security Officers must
also comply with NDPD policies when applicable.
6-1
-------
Information Security Manual 12/15/89
6.2 RISK ANALYSIS
As explained in Section 2, each Minicomputer/Mainframe Security Officer must
perform a risk analysis for his/her installation. For all installations, a qualitative risk
analysis may be used. Detailed procedures for performing the analysis are pre-
sented in Appendix C.
Any harm to an installation will manifest itself as a loss of information integrity, a loss
of information confidentiality, and/or a loss of processing availability. One of the key
outputs of the risk analysis process will be an understanding of the threats (fire, theft,
etc.) likely to cause harm to the installation.
In selecting control measures from Subsections 6.4-6.7, Security Officers must
always consider the reduction in risk the security measures will achieve. In other
words, do not implement the procedures in this section in a vacuum; instead
implement these procedures only in conjunction with the Appendix C risk analysis.
6.3 DISASTER RECOVERY AND CONTINUITY OF OPERATIONS PLANNING
Security Officers are responsible for preparing a plan for disaster recovery and
continuity of operations for each minicomputer/mainframe installation. Procedures
for preparing the plan are presented in Appendix D.
Such plans are particularly important for ensuring the availability of critical or high
value Agency applications. To the extent an installation limits itself to confidential or
integrity-oriented applications, contingency planning is less important. Appendix D
requires a less extensive plan for installations of this type.
6.4 PROCEDURES FOR ALL SENSITIVE INSTALLATIONS
For sensitive minicomputer/mainframe installations, there are a number of controls
that help achieve all three security objectives simultaneously. For example,
requiring the user to provide a password when logging on to a system can prevent
disclosure by denying unauthorized users access to the host computer. The
password scheme can also reduce the potential for fraud or sabotage by effectively
locking-out unauthorized users. Finally, the chance of accidental data destruction
6-2
-------
Information Security Manual 12/15/89
(a threat to availability) is reduced if inexperienced users are unable to access the
host computer due to password protection.
Universal controls of this type fall into four broad categories: (1) hardware controls,
(2) software controls, (3) procedural controls, and (4) communications controls. All
four categories are discussed below.
6.4.1 Hardware Controls
Many important security safeguards can be built into hardware. Hardware-based
protection mechanisms are often cost-effective because they can be applied to so
many different information systems and files. By way of contrast, most application-
based controls are limited in usefulness to the one application. Hardware-based
controls are also typically more difficult to circumvent.
To determine what hardware security features are standard and what features can
be obtained at additional cost, contact the appropriate vendor representative.
From a security perspective, the following hardware features need to be imple-
mented when they are available and cost-effective:
User Isolation: This is the capability to isolate users from each other.
Alarm: An audible alarm notifies the computer operator when certain
events occur, such as an unauthorized access attempt.
Identifiable Remote Terminals: This is the capability of knowing the
identity of remote terminals. This feature augments a password scheme
which authorizes each user. With terminal identification, an intruder must
have a valid password and access to a valid terminal.
Error Detection During Processing: This feature involves checking for
errors each time memory is accessed. The error checks typically take the
form of parity and address bounds checks. Error detection is particularly
useful for maintaining integrity.
Memory Access Control: This capability limits each user to the memory
of his/her own partition.
Privileged Command Control: With this feature, certain commands are
only executed when the computer is in a master or executive mode (as
opposed to a user mode). Commands of this type include input/output
instructions and partition transfers, and are generally available only to
operators or system programming personnel.
6-3
-------
Information Security Manual 12/15/89
6.4.2 Software Controls
The following controls need to be implemented using the operating system and other
system software (unless they have already been built into the hardware):
User programs must be prevented from executing privileged instructions.
Users must be isolated from each other.
Hardware and software error logs need to be maintained.
Error checking needs to occur each time memory is accessed.
Atypical occurrences that may indicate a security violation need to be
recorded. These include unlocking terminals via operator overrides or
access failures, such as incorrect passwords.
In addition, the operating system must control the following functions:
Information transfers between the main memory and on-line storage, and
between the central computer and remote equipment
All functions that allocate ADP resources, such as memory or peripher-
als
Utilities and programs that maintain and change the operating system.
6.4.3 Procedural Controls
Memory dumps must be limited to a user's memory partition. System
memory dumps need to be strictly controlled.
When installation size warrants it, maintain astorage location and a library
system for tape and disk storage.
- Only the media librarian or individuals authorized by the installation's
Security Officer will be allowed access to the storage location.
- All media not scheduled for use within the next day should be stored
in the library.
- Mark each item with a serial number.
- Keep a record of each item that includes its sensitivity designation,
age, frequency of usage, owner, and cleaning schedule.
Maintain console logs and operating logs.
6-4
-------
Information Security Manual 12/15/89
6.4.4 Communications Controls
Host-level password protection is required for any on-line access to the computer.
(Host-level passwords are those used when first logging on to the computer system,
for example, VAX or IBM Mainframe.) In implementing password protection, make
sure of the following:
Passwords are at least six characters in length.
The password must contain at least one alpha and one numeric character.
Passwords can be deleted or changed in a straightforward, controlled
fashion. Passwords are changed at least quarterly.
Consecutive password failures are limited to no more than four before a
user is revoked from the system.
Passwords are not composed of names or similar personal types of
information.
6.5 ADDITIONAL PROCEDURES TO MAINTAIN AVAILABILITY
6.5.1 Procedures for Medium-Level Availability
6.5.1.1 Backups and Continuity of Operations
In general, the most important step to be taken to protect information availability is
to implement a regular schedule of backups. If information has been backed up and
if the backup has been safely stored, the information will be recoverable no matter
what happens. Procedures for backup, disaster recovery, and continuity of opera-
tions are contained in Appendix D.
6.5.1.2 Power Protection
Provide for adequate power to guard against fluctuations and failures through the
use of surge protectors. Consider implementation of an Uninterruptible Power
Supply (UPS) to avoid system failure during brief power disruptions.
6.5.1.3 Physical Access Control
NCC and WIG must maintain a physical access control that includes at least one of
the following: key cards, magnetic card locks, remote controlled locks, or closed-
circuit television. At night, this system must be supplemented with either an intrusion
6-5
-------
Information Security Manual 12/15/89
alarm or a guard patrol.
Other installations must, at a minimum, maintain a list of personnel authorized to
enter the installation. At night, this must be supplemented with a guard control. More
rigorous access control systems are acceptable for other installations if they are
cost-effective.
6.5.1.4 Visitor Control
All visitors must log-in/log-out and be escorted during the visit.
6.5.1.5 Fire Control
WIC and NCC must install a centralized fire suppression system.
6.5.2 Procedures for High-level Availability
Follow all procedures set forth in Subsection 6.5.1. In addition, install an emergency
power standby capability.
6.6 ADDITIONAL PROCEDURES TO PRESERVE INTEGRITY
To maintain medium level integrity, adhere to the procedures in Subsection 6.5.1
above. To maintain high level integrity, adhere to the procedures in Subsection 6.5.2
above.
6.7 ADDITIONAL PROCEDURES TO PRESERVE CONFIDENTIALITY
6.7.1 Procedures for Medium-Level Confidentiality
6.7.1.1 Control Hard-Copy Reports and Output
Control the production and distribution of confidential output. Keep such output in
a locked cabinet or room when not in use. Establish safeguards to prevent confi-
dential reports from being misrouted.
6-6
-------
Information Security Manual 12/15/89
6.7.1.2 Encryption
Some application system owners may determinethat encryption is a needed security
control when transmitting confidential data. The NCC will provide encryption where
required upon request. Other installations may also provide encryption if it is cost-
effective, but they must consult with the NCC regarding potential technical and
logistical problems.
6.7.1.3 Physical Access Control
See Subsection 6.5.1.3.
6.7.1.4 Visitor Control
All visitors must log in/log out and be escorted during the visit.
6.7.1.5 Disposal Practices
Shred confidential reports when they are no longer needed. Make sure that
confidential data are erased from magnetic tapes before releasing them as work
tapes, etc. Assist application system owners who wish to erase confidential data
from their disk space before releasing it for other uses.
6.7.2 Procedures for Hiah-Level Confidentiality
The EPA has only one type of information in this category - National Security
Information (NSI). The amount of NSI possessed by the Agency is extremely small
and the need to computerize any of it would be very infrequent.
Because of the small quantity of NSI in the Agency and because NSI involves special
security considerations (emanations security and TEMPEST devices), NSI should
not be placed on computers without the express approval of the Director, OIRM.
6-7
-------
Information Security Manual 12/15/89
7. SECURITY FOR PERSONAL COMPUTERS
AND PC LANs
7.1 BACKGROUND
This section applies to personal computers (PCs) only. A single PC installation is
generally comprised of a microprocessor, a video monitor and various peripheral
devices for entering, storing, transmitting and printing data. The PC installation may
process in isolation as a standalone personal tool and/or it may function as a smart
terminal in a communications configuration (such as PC to mainframe). This section
does not apply, however, to other types of microsystems such as Lexitron word
processors (see Section 8) or dumb terminals (those that are not programmable).
The expanding use of personal computers is creating major new opportunities for
productivity improvement at the EPA. At the same time, however, this expanding
use of personal computers is placing new information security responsibilities on
office managers, research personnel, and others not previously considered to be in-
formation processing professionals. This decentralized processing of Agency
information means that mainframe and minicomputer processing installations can
no longer be relied upon to protect all automated Agency operations.
Certain PC characteristics pose special problems in information security. In general,
these include the following:
Personal computer systems software is typically rudimentary and affords
little protection to information and programs.
Personal computers typically lack the built-in hardware mechanisms
needed to isolate users from each other and from certain system functions
(such as reading and writing to memory).
PC information is typically in the form of reports, spreadsheets, lists, and
memoranda. These relatively final forms mean that PC data are more
readily accessed and understood by unauthorized users than are data in
larger computer systems.
7-1
-------
Information Security Manual 12/15/89
7.2 DETERMINING THE PROCESSING ENVIRONMENT; RELATIONSHIP TO
OTHER PROCEDURES
Several of the procedural controls specified in Subsections 7.4-7.6 are presented in
terms of the environment in which the application or information is being processed.
In using those subsections, be alert to procedures that depend on three key
environmental characteristics, which can be defined by answering the following
questions:
Is the PC a single-user device or is it shared among multiple users?
Is the information/application stored on removable media (like a floppy
disk) or non-removable media (like a fixed disk) or both (like a fixed disk
with a floppy disk backup)?
Does the PC process in isolation or does it communicate with other
hardware? If it does communicate, which of the following communication
configurations applies:
- Remotely accessible by modem (dial-up capability)?
- PC to resource server?
- Local area network (LAN)?
Regarding LANs, LAN System Administrators must note that NDPD issues policies
(for example, governing access control or backup frequency) for Agency LANs.
These policies are contained in Section 310 of the "NDPD Operational Policies
Manual." These policies are typically more detailed and technically oriented than
the core procedures presented here. LAN System Administrators must make sure
that they comply with applicable NDPD policies.
7.3 USING THE REST OF THIS SECTION
The remainder of this section is organized by information security objective. Consult
completed Table 4-1 to determine which security objective orobjectives are relevant.
If availability is a security objective, review Subsection 7.4
If integrity is a security objective, review Subsection 7.5
If confidentiality is a security objective, review Subsection 7.6.
7-2
-------
Information Security Manual _ 1 2/1 5/89
In discussing procedural controls, Subsections 7.4-7.6 reference hardware and
software security products that are available under the PC contract. Information on
products and prices was current as of December 1989. Because the Agency peri-
odically updates contract offerings and prices, the reader should consult with his/her
PC site coordinator prior to placing an order.
7.4 MAINTAINING INFORMATION AVAILABILITY
7.4.1 Introduction
This subsection sets forth security procedures for owners, users, LAN System
Administrators, and custodians of applications of high-level and medium-level
availability (as determined in Section 4). This section is to be used as follows:
Owners develop the security specifications and the tests needed for ap-
plication certification based on the procedures presented here.
sure they are in compliance with ownersecurity specifications
based on these procedures. In addition, users may consult these proce-
dures when an owner has designated an application as sensitive, but has
not yet identified his/her security specifications.
Custodians and LAN System Administrators use these procedures to
make sure that applications can be recovered in the event of a processing
disaster and can be run elsewhere if necessary. They also use these
procedures to develop the information required for the risk analysis
outlined in Appendix C.
The remainder of this subsection is organized as follows. The next part catalogs and
describes specific threats to information availability. Subsections 7.4.3 and 7.4.4
specify security measures for medium availability applications and high availability
applications, respectively. The last part describes some steps that can be taken to
recover from a processing disaster.
7.4.2 Threats to Application and Information Availability
Specific threats to data availability include:
Theft
Damage to magnetic media
Hardware failure: inability to restart
7-3
-------
Information Security Manual 12/15/89
Hardware failure: failure during use
Accidental data destruction or other operator errors
Sabotage (deliberate data destruction)
Failure of users to back-up data and programs.
The threats of theft and damage to magnetic media were addressed in Section 3.
The remaining threats are described below.
7.4.2.1 Hardware Failure: Inability to Restart
Because of the generally high reliability of microcomputers, users tend to become
overconfident and to not protect themselves from system failures.
In some cases, microcomputer systems are incapable of being restarted (booted)
because of a hardware failure.
If the inability to start the system is caused by a failure of the hard disk drive
subsystem and it is necessary to repair or replace the drive, the data on the drive will
probably be unavailable after the system has been repaired.
7.4.2.2 Hardware Failure: Failure During Use
Although microcomputers do not often break down, the hardware can fail during use
for a variety of reasons. The most common problem is a disruption or surge of electric
power, but the failure of almost any internal component can cause the system to
crash.
In addition to the problems that may be encountered if the system cannot be booted,
failure during use will result in a disruption of ongoing processing. If the system
crashes while in use, all data in the volatile, random access memory (RAM) will be
lost. In addition, if data files are open at the time of the failure, they may be corrupted.
7.4.2.3 Accidental Data Destruction
The most common way that data are accidentally destroyed is by users issuing
incorrect commands. For example, it is possible for users to destroy all of the data
on a disk by inadvertently reformatting it. This can be especially damaging if the hard
disk is reformatted. Files can also be inadvertently deleted. It is also possible to copy
a file on top of an existing file if the name of the existing file is used as the destination
7-4
-------
Information Security Manual 12/15/89
of a copy command.
Data can also be accidentally destroyed by software malfunctions or incompatibility.
A particularly serious potential problem is caused by an incompatibility between
versions 2.x and 3.x of PC/MS DOS. Specifically, if a system containing a 20mb or
larger fixed disk formatted under version 3.x of DOS is booted from a diskette that
contains a 2.x operating system, the File Allocation Table of the hard disk will be
damaged when data are written to the hard disk. If this happens, it might not be
possible to access data stored on the hard disk.
7.4.2.4 Sabotage
Data can be deliberately destroyed by malicious individuals, who may be either
authorized or unauthorized users. Such destruction can be the result of vandalism
by those outside the office, but it can also be an act by an employee who has been
dismissed or disciplined, an act by an individual who is hostile to the mission of an
office, or an act by an individual hostile to the implementation of a new computer
system. Examples include:
An employee may oppose the implementation of performance monitoring
software.
An individual may use the data overwriting programs in PC utilities
packages to erase files or disks.
An individual may feel that the automation of the individual's duties may
make him or her more expendable.
A dismissed employee may plant a "virus" in an organization's software
prior to departure.
An individual may believe that the implementation of a system intended to
make his or her job easier will actually make his or her job more difficult.
7.4.2.5 Failure to Backup Data and Programs
When it comes to regular and systematic backup, it unfortunately seems that expe-
rience is the best teacher. A user often needs to lose an important file before he/
she realizes the importance of backup. Failure to perform regular backups is
probably the most common and the most serious threat to availability.
7.4.3 Procedures to Maintain Medium-Level Availability
This part applies to applications that can be unavailable for a period of only one-to-
7-5
-------
Information Security Manual 12/15/89
five days and/or applications that are of other high value.
7.4.3.1 Lock-up Media
To avoid theft, store media in a locked cabinet or room.
7.4.3.2 Write Protection
Whenever possible, write-protect files and programs to avoid accidental destruction.
7.4.3.3 Isolated Storage
Isolate the critical/high value application on its own storage media to the extent
possible. For an application residing on a floppy disk, this means dedicating the disk
to the one sensitive application. For an application residing on a fixed disk, this could
mean dedicating a separate subdirectory or partition to the software. Such isolation
speeds the backup process (discussed below).
7.4.3.4 Backups
In general, the most important step to be taken to protect information availability is
to implement a regular schedule of backups. Backups are performed to provide for
easy recovery from a disaster. If information has been backed up and if the backup
is safely stored, the information will be recoverable no matter what happens.
Note, however, that transactions that have occurred since the last backup may have
been lost and may need to be re-input.
DATA BACKUPS
Each PC user needs to establish a backup loop to protect his/her data and
files. The backup loop is a systematic way of creating multiple generations
of copies. The frequency and number of backup generations made and
stored should be a direct function of the value of the information and the cost
of regenerating it. In general, two to five generations are recommended. Two
examples involving diskettes are provided below.
A two-generation scheme for a floppy disk would be performed as follows:
- On the first day, the data on the original diskette would be copied on
to diskette 1.
- On the second day, the data on the original diskette would be copied
on to diskette 2.
- On the third day, the data would be copied on to diskette 1, over the
backup from the first day.
7-6
-------
Information Security Manual . 12/15/89
A five-generation scheme for a fixed disk system would be performed as
follows:
- On Monday of the first week, the user's data on the fixed disk would be
copied to a set of diskettes designated as set 1.
- On Tuesday, the data could be copied to set 2. Wednesday's backup
would be copied to set 3, Thursday's to set 4, and Friday's to set 5.
- On Monday of the second week, the data would be copied to set 1, over
the Monday backup from the previous week.
Under a five-generation scheme, the user has a significant level of protection.
Even if the original data and one or two of the backups were destroyed, only
one or two days of work would be lost.
The backup loop does not have to involve diskettes. As discussed below, tape
backup systems or Bernoulli boxes can be more efficient. Moreover, if the
PC is connected to a LAN file server or remote host (such as a mainframe
computer), the remote device may provide backup protection. Consult the
manager of the remote facility or the LAN System Administrator for informa-
tion.
Backup copies stored in the general vicinity of the original data protect against
problems such as a system crash or an accidental erasure of data. They do
not, however, protect against a threat such as a fire which could affect an
entire floor or building. As a result, each month a copy should be taken out
of the backup loop and stored in a physically separate location. This archival
copy would probably not be completely current in the event of a major
disaster, but it would have great data recovery utility. To prevent archival
copies from piling up, the copy that has been in archives can replace the one
taken out of the backup loop. There may also be advantages in retaining
several generations of archival copies.
For Headquarters employees, the WIC is recommended as an "off-site"
location. The WIC does charge a fee for storing backup copies. Participating
organizations execute an "Operational Service Agreement for Archiving of
PC Software" with the WIC. If the PC is connected to a remote host or file
server, it may be possible to use the remote device as the off-site location.
Consult the manager of the remote facility or the LAN System Administrator
7-7
-------
Information Security Manual 12/15/89
for assistance.
When files get large, users are tempted to employ the incremental backup
approach. An incremental backup focuses only on what has been changed
and includes only those files that have been modified since the last backup.
The advantage of an incremental backup is that it can be performed faster
than the full backups discussed above. The disadvantage of incremental
backups is that no single backup will contain all of the files and data. If the
original files are destroyed or lost, it will be necessary to reconstruct the data
from the most recent full backup and all of the incremental backups that have
been performed since. In addition to being inconvenient, this process of
reconstructing the files is risky. If the last full backup or any of the incremental
backups has anything wrong with it, it may be impossible to perform a fully
successful recovery.
Because of these difficulties, incremental backups are not recommended.
Instead, if the data files are so large that the backup process fills about 15
diskettes, consider using a streaming tape backup system or a Bernoulli box.
A streaming tape backup system is available under the PC contract for about
$500. The Bernoulli box, which is available for about $800 (10 megabyte) or
about $1200 (20 megabyte) under the PC contract, makes backups straight-
forward and quick. It also provides certain access controls, for example,
partitioning software. If the PC is also used for confidential processing, the
box becomes more cost effective. In addition, if software as well as data are
stored on Bernoulli disks and a second PC with a Bernoulli box is available,
each PC can be a backup facility for the other.
SOFTWARE BACKUPS
Backups should not be limited to data and files. End user applications (soft-
ware developed or maintained locally) should also be backed up and stored
at the off-site storage facility. Source program files, loadable versions of all
software, and required compiler or interpreter programs should be included.
7.4.3.5 Continuity of Operations
Backup computing facilities shall be identified for critical applications and an
agreement for the use of the backup facility shall be executed. The agreement for
7-8
-------
Information Security Manual 12/15/89
the backup facility should not be an informal and vague oral agreement, but instead
must involve a memorandum between the PC custodians identifying all conditions
(for example, the amount of machine time to be made available).
7.4.4 Procedures to Maintain High-Level Availability
This part applies to applications that must be available continuously or within one day
and/or applications that are of very high value. All procedures set forth in Subsection
7.4.3 also apply here. In addition, the following additional procedures will be adhered
to.
7.4.4.1 Uninterruptible Power
Obtain an Uninterruptible Power Supply (UPS) device to provide virtually complete
surge protection, a filter for line noise, and power in the event of an outage. A UPS
is available for approximately $1100 under the PC contract.
7.4.4.2 Manual Fallback
Identify and formalize manual procedures to be followed in the event of a complete
disaster.
7.4.4.3 More Frequent Backups
Consider preparing full backups for off-site storage on a weekly or even daily basis.
7.4.5 Suggestions for Recovering from a Disaster
In the event of a problem or disaster, it is often best to stop using the PC and seek
help from the PC Site Coordinator. The following may then help restore availability:
It may be possible to recover data stored on the undamaged portions of
the damaged medium using the DOS DEBUG facility or some other
hexadecimal editor. This will be a difficult task and should only be
undertaken by individuals with a thorough understanding of theirsystems.
Commercially available utility packages (such as the Norton Utilities
package available under the PC contract for about $100) can help in
recovering data and in unformatting an accidentally formatted disk.
If backups have been made, data and software that are not copy-protected
can be restored from the backups. Contact the manufacturers of copy-
protected software to investigate their policy for replacing damaged
software.
7-9
-------
Information Security Manual 12/15/89
If summary data have been damaged, but detailed records or other audit
trails were undamaged, it may be possible to recreate the summary data
from the detailed records. In some cases it might even be possible to
recreate detailed records if sufficient audit trail information is available.
7.5 PRESERVING INFORMATION INTEGRITY
7.5.1 Introduction
This subsection sets forth security procedures for owners, users, LAN System
Administrators, and custodians of applications of high-level and medium-level integ-
rity (as determined in Section 4). This section is to be used as follows:
Owners develop the security specifications and the tests needed for ap-
plication certification based on the procedures presented here.
Users make sure they are in compliance with owner security specifica-
tions based on these procedures. In addition, users may consult these
procedures when an owner has designated an application as sensitive,
but has not yet identified his/her security specifications.
Custodians and LAN System Administrators use these procedures to
determine what security measures must be in place at his/her installation
to maintain integrity. They also use these procedures to develop the
information required for the risk analysis outlined in Appendix C.
The remainder of this subsection is organized as follows. The next part catalogs and
describes specific threats to information integrity. Subsections 7.5.3 and 7.5.4 then
specify security measures for applications of medium-level integrity and high-level
integrity, respectively. Finally, the last part describes some steps that can be taken
to recover from data corruption.
7.5.2 Threats to Integrity
7.5.2.1 Deliberate Distortion of Information: Fraud and Sabotage
Data integrity can be damaged by the deliberate actions of system users or other in-
dividuals with access to the system. Such damage could take the form of a virus.
These actions could be motivated by revenge (for example, by recently disciplined
or reprimanded employees) or could be intended to perpetrate or cover up fraudulent
activities, mismanagement, or waste.
7-10
-------
Information Security Manual 12/15/89
Fraudulent activities include embezzlement or any other deception intended to
cause the deprivation of property or some lawful right. Fraud could be intended to
prevent or influence enforcement actions or other operations of the Agency.
7.5.2.2 Accidental Damage
Accidental damage to data integrity results when individuals inadvertently and un-
knowingly modify data, erase files, input incorrect data, or introduce program bugs.
Accidental threats to data integrity overlap with the issues discussed under data
availability. The distinction is based on whether the data distortion is discovered. If
so, the distortion would be generally be considered to consist of a loss of data and
would therefore be considered to be a data availability problem. When the damage
remains undetected, decisions may be made or other actions may be taken based
upon incorrect information, resulting in a failure of data integrity.
7.5.2.3 Other Considerations
In addition to the above, information integrity can also be affected by flaws in soft-
ware applications design and development (for example, incorrect algorithms or
mathematical formulae). A review of all system design issues that are relevant to
data integrity is beyond the scope of this manual. Instead, the reader is referred to
the three volume set of "EPA System Design and Development Guidance" issued by
OIRM. This comprehensive set of standards includes references to security at
appropriate points in the software design/development process. For more explicit
guidance on designing security into applications, the reader is also referred to
Federal Information Processing Standard (FIPS) 73 and to Section 9 on application
system development. FIPS 73 is available in the EPA Headquarters library or
through the National Technical Information Service.
This section will limit itself to a consideration of threats to data integrity involving
deliberate and accidental actions of users and involving other events that can occur
during system use.
7.5.3 Procedures to Maintain Medium-Level Integrity
The security measures needed to ensure integrity reoresent a mix of-those aaaooi
ated with maintaining availability and those associated wnh preserving confidential-
ity. Availability and confidentiality are almost opposites; backup copies of a data
7-11
-------
Information Security Manual 12/15/89
base made to enhance availability can aggravate the problem of preventing the
disclosure of data stored in the data base. In a very real sense, however, integrity
is the objective in the middle.
Integrity involves elements of the availability objective because if data are corrupted
or partially destroyed, intact backup copies are essential. On the other hand,
integrity involves elements of the confidentiality objective because preventing fraud
and sabotage are largely problems of controlling access.
7.5.3.1 Availability-Related Procedures
Adhere to the procedures described in Subsection 7.4.3, with the exception of those
associated with continuity of operations. This will ensure that backups are created.
7.5.3.2 Confidentiality-Related Procedures
Adhere to the access control procedures described in Subsections 7.6.3.2 and
7.6.3.3. Also, follow the password management practices outlined in Subsection
7.6.3.1. In addition, for PCs in a local area network (LAN), adhere to the procedures
outlined in the following two paragraphs.
In a LAN, all points can read traffic on the network. In addition, all points have access
to common storage media. Indeed, the ability to share printers or storage (file
servers) is often a primary reason why networks are created.
The LAN System Administrator is responsible for coordinating the selection of
security safeguards for the network to ensure overall effectiveness. LANs some-
times have security packages available as pan: of their operating systems. These
may be considered in selecting safeguards forthe network. If all network users have
access to all information processed on the network, establish a formal list of those
authorized users (an administrative control). To the extent possible, bolster this
administrative control by keeping each PC on the network under lock and key when
not in use. Require users to provide a password when logging on to the network.
7.5.3.3 Audit Trails and User Accountability Tracking
if fraud and sabotage are threats, audiUrails and operator tracking should be incor-
porated inio the application software. The software should be designed to automati-
cally insert the operator identifiers into each record based upon a password supplied
during the system sign-on process. Data integrity and user accountability would be
7-12
-------
Information Security Manual 12/15/89
further enhanced if the application software and data base were compiled and
encrypted to prevent the password and accountability tracking mechanism from
being bypassed.
7.5.4 Procedures to Maintain High-Level Integrity
All procedures set forth in Subsection 7.5.3 above also apply here. In addition, the
procedures listed below will be followed.
7.5.4.1 Uninterruptible Power
Obtain an Uninterruptible Power Supply (UPS) device to provide virtually complete
surge protection, a filter for line noise, and power in the event of an outage. A UPS
is available for about $1100 under the PC contract.
7.5.4.2 Manual Fallback
Identify and formalize manual procedures to be followed in the event of a complete
disaster.
7.5.4.3 More Frequent Backups
Consider.preparing backups for off-site storage on a weekly or even daily basis.
7.5.5 Suggestions for Recovering from a Disaster
In the event of a problem or disaster, it is often best to stop using the machine and
seek help from the PC Site Coordinator. The following may then help restore
integrity:
It may be possible to recover data stored on the undamaged portions of
the damaged medium using the DOS DEBUG facility or some other
hexadecimal editor. This will be a difficult task and should only be
undertaken by individuals with a thorough understanding of theirsystems.
Commercially available utility packages (such as the Norton Utilities
package available under the PC contract for about $100) can help in
recovering data and in unformatting an accidentally formatted disk.
If backups have been made, data and software that is not copy-protected
can be restored from the backups. Contact the manufacturers of copy-
protected software to investigate their policy for replacing damaged
software.
7-13
-------
Information Security Manual 12/15/89
If summary data have been damaged, but detailed records or other audit
trails were undamaged, it may be possible to recreate the summary data
from the detailed records. In some cases it might even be possible to
recreate detailed records if sufficient audit trail information is available.
7.6 PRESERVING INFORMATION CONFIDENTIALITY
7.6.1 Introduction
This subsection sets forth security procedures for owners, users, LAN System
Administrators, and custodians of confidential applications and information. This
section is to be used as follows:
Owners develop the security specifications and the tests needed for ap-
plication certification based on the procedures presented here.
Users make sure they are in compliance with owner security specifica-
tions based on these procedures. In addition, users may consult these
procedures when an owner has designated an application as sensitive,
but has not yet identified his/her security specifications.
Custodians use these procedures to determine what security measures
must be in place to protect the confidential information being stored and
processed by users of his/her installation. They also use these proce-
dures to develop the information required for the risk analysis outlined in
Appendix C.
LAN System Administrators must note (per Section 7.6.3.3) that no
confidential data may be loaded on to a LAN or made available via a LAN
unless specifically approved in writing by the Director, OIRM.
The remainder of this subsection is organized as follows. The next part catalogs and
describes specific threats to confidentiality. Subsections 7.6.3 and 7.6.4 specify
security measures for applications of medium level confidentiality and high level con-
fidentiality, respectively. Features of the processing environment are particularly
important for preserving confidentiality and are discussed in those subsections as
appropriate.
Unlike Subsections 7.4 and 7.5, there is no separate discussion here of steps to
recover from a breach of confidentiality. Once information has been disclosed, there
is little the individual can do to remedy the situation. Instead, the breach must be
reported to appropriate Agency officials, as described in the Information Security
Policy.
7-14
-------
Information Security Manual 12/15/89
7.6.2 Threats to Application and Information Confidentiality
Specific threats to information confidentiality are largely problems of access control.
Note that the threats described below apply to confidential information in its various
forms, that is, in the computer, in hard copy, on removable media like diskettes, and
on printer ribbons.
Magnetic media containing confidential data can be accessed by individu-
als from whom the data should be restricted. If the computer is not in a
secure area, intruders can start the system containing the information and
browse information on the fixed disk. If diskettes containing confidential
information are not secured, unauthorized individuals can install them on
a computer and browse their contents.
Unauthorized individuals could see data on a computer screen or printout
if confidential data are processed in an unsecured area or if printouts are
not protected in storage.
Confidential data can be deciphered from printer ribbons used to print
confidential reports.
Unauthorized individuals could access confidential data across a local
area network or other communications device if confidential data are
stored or processed on a microcomputer that can be accessed remotely.
Files erased from a magnetic disk using only the standard DOS "DEL" or
"ERASE" commands are not actually erased from the computer disk
they are only marked for deletion and the space on which they are written
is freed for use by later files. For this reason, until they have been
overwritten, they can be "unerased" using commercially available utility
programs.
Some software systems use work files that are temporarily stored on disk.
Although the systems usually delete these files when they are finished
with them, the deleted files may be recoverable using commercially
available utility programs. Similarly, information could be left in the volatile
(RAM) memory of the computer if the computer is not turned off after
confidential data have been processed.
Individuals authorized to access confidential information could deliber-
ately share printed reports or magnetic media containing confidential data
with unauthorized individuals.
7.6.3 Procedures to Preserve Medium-Level Confidentiality
Preserving confidentiality involves controlling access to information and applica-
tions. How easy or difficult it is to control access is highly dependent on the three
7-15
-------
Information Security Manual 12/15/89
key environmental characteristics (single user versus shared, stand-alone versus
communicating, removable versus non-removable media). The simplest situation
consists of a single user who does stand-alone processing and stores all confidential
information on floppy disks. When the PC is shared or in a communicating
configuration, the security situation becomes more complicated.
The procedures which follow are presented largely in terms of processing environ-
ment. Following a short subsection on controls which apply to all environments,
more complicated environments are discussed. The security controls required fall
into the following categories:
Physical, such as door locks
Administrative, such as lists which specify who is allowed access to a
given PC
System-based, such as password protection
Information-based, that is, rendering information unusable (even if it is
obtained by unauthorized individuals) through scrambling or encryption
techniques. As an example, some commercial software (for example,
Lotus 1 -2-3 Version 2) contain data encryption capabilities. The Lotus 1 -
2-3 data encryption capability enables users to password-protect their
Lotus spreadsheets. The encrypted spreadsheets cannot be accessed
without the assigned password and data in them are encoded to prevent
the data files from being read through DOS functions or other utilities.
It should be noted that EPA organizations with statutory authority for certain types
of confidential information may issue security procedures dealing exclusively with a
particular type of information (for example, TSCA or FIFRA CBI). Because of
statutory requirements, some of those procedures may be more stringent than those
required here. EPA employees must make sure that they also adhere to such
organizational standards and procedures.
7.6.3.1 Procedures for all Environments
Discourage traffic in the area where the computer is located when in use.
Unauthorized individuals should be kept out of the area so that they cannot
view data that might appear on the computer screen.
Log off or otherwise inactivate the PC whenever leaving it.
Store hard-copy reports and removable media containing confidential
data in locked cabinets or rooms.
Printer ribbons used to print confidential data should be considered
confidential as well. Destroy exhausted ribbons so that they cannot be
7-16
-------
Information Security Manual 12/15/89
deciphered by an unauthorized individual.
Be careful when disposing of disks, diskettes, or tapes that contain
confidential data. Before these media are thrown away or recycled, they
must be degaussed, overwritten, or shredded. (Degaussing erases data
through demagnetization.) The WIPEDISK program in the Norton Utilities
package (available underthe PC contract for about $100) destroys all data
on a disk by overwriting them.
When erasing individual files on diskettes or fixed disks, use an overwrit-
ing program like WIPEFILE in the Norton Utilities package. These over-
writing programs are effective; be careful not to erase needed files.
It should be noted that programs designed to purge and overwrite individ-
ual files (like WIPEFILE) may only overwrite the most recent generation
of a file. This would also destroy previous generations of the file if they
were physically located in the same disk addresses as the last generation
of the file. If the previous generations were located elsewhere on the disk,
or if the last generation file is smaller than the previous generations, the
previous generations may not be entirely overwritten by the file destruc-
tion utility. Recovery of these undestroyed fragments, however, would be
extremely difficult and tedious for even the most knowledgeable intruder,
and it is unlikely that more than small fragments of the sensitive informa-
tion could be recovered.)
If passwords are selected as a control measure (based on the procedural
guidance below), make sure passwords are selected and handled as
follows:
- Passwords are at least six characters long
- Passwords contain at least one alpha and one numeric character
- Passwords are not composed of names or similar personal types of
information
- Passwords are not shared
- Passwords are changed at least quarterly
- Passwords are not written out and left where an unauthorized person
could find them
- Passwords are not incorporated into automated log-on procedures in
batch files or application programs (for example, Crosstalk) and they
are not defined under function keys.
Passwords can either be incorporated into applications systems or imple-
mented through add-on circuit boards. While application-based pass-
word schemes may prevent casual intruders, they usually do not thwart
7-17
-------
Information Security Manual 12/15/89
the knowledgeable intruder unless special steps are taken (for example,
encryption). Knowledgeable intruders may be able to avoid the pass-
words altogether or may scan application listings to determine the
password. For this reason, the more sophisticated hardware-based
password schemes are recommended. Cyiock, available under the PC
contract for about $300, is hardware based.
7.6.3.2 Procedures for Stand-Alone Processing
This part applies to PCs that process in isolation and do not communicate with any
other equipment.
CONFIDENTIAL DATA ON REMOVABLE MEDIA ONLY; SINGLE OR
SHARED USER PC
Clear the system of confidential information after each confidential process-
ing session. Power off the unit to clear any volatile memory, that is, random
access memory (RAM).
CONFIDENTIAL DATA ON NON-REMOVABLE MEDIA; SINGLE OR
SHARED USER PC
Keep the computer under lock and key when not in use, that is, keep it in a
locked cabinet or a locked room.
If all users of a shared PC have access to all information processed on the PC,
establish a formal list of those authorized users (an administrative control).
Limit access to those on this authorized list. If this is not the case, users must
be protected from each other via either a password scheme or encryption.
Encryption software (Datasafe) is available under the PC contract for under
$100.
7.6.3.3 Procedures for Communicating PCs
This part applies to PCs that are connected to other equipment such as auto-answer
modems, other PCs, or resource-servers.
AUTOANSWER MODEM; SINGLE USER OR SHARED
PCs are sometimes used as host systems. An autoanswer modem allows a
person to use the system remotely. Keep the computer under lock and key
when not in use, that is, keep it in a locked room or a locked cabinet.
7-18
-------
Information Security Manual 12/15/89
Use a password scheme that requires both a traditional user identifier and a
password logon process. Under no circumstances should users share
passwords.
TERMINAL EMULATION
At times, a PC is used as a terminal device to a large host system. In this
situation, security controls are the responsibility of the host system. The host
should control access and the extent to which data are sent (uploaded) or
received (downloaded).
The PC user needs to make sure he/she adheres to all host-imposed security
requirements. In addition, the PC must never store host telephone numbers,
logon sequences, or passwords in the PC itself.
LOCAL AREA NETWORKS; SINGLE USER OR SHARED PC
No confidential data may be loaded on to a local area network (LAN) or made
available via a LAN unless specifically approved in writing by the Director,
OIRM.
7.6.4 Procedures to Preserve High-Level Confidentiality
The EPA has only one type of information in this category - National Security
Information (NSI). The amount of NSI possessed by the Agency is extremely small
and the need to computerize any of it would be very infrequent.
Because of the small quantity of NSI in the Agency and because NSI involves special
security considerations (emanations security and TEMPEST devices), NSI should
not be placed on PCs without the express approval of the Director, OIRM.
7-19
-------
Information Security Manual 12/15/89
8. SECURITY FOR WORD PROCESSORS
8.1 INTRODUCTION
This section applies to users of equipment designed primarily for word processing,
such as the remaining Lexitrons still in use. Such equipment has little or no
programming capability. Under certain circumstances, this section applies to the
newer Telex devices (which have been replacing Lexitrons) and to PCs. This section
can be used for a Telex or PC if all of the following conditions are met:
The Telex or PC is used exclusively for word processing
The Telex or PC does not communicate with other computers
Confidential documents are never stored on non-removable media like a
fixed disk
If the above conditions are not met, the Telex or PC is covered by the Section 7
procedures. (The Telex is a programmable, IBM-compatible microcomputer,
making Section 7 applicable when the conditions above are not met.)
In terms of security threats and safeguards, word processors have much in common
with PCs. Both are office automation microsystems used by large numbers of EPA
employees. In essence, the procedures presented here are a simpler, quicker-to-
use version of the PC procedures set forth in Section 7.
The remainder of this section is organized as follows. The next subsection identifies
and describes specific threats to information security. Subsections 8.3 and 8.4
specify security measures for maintaining availability and preserving information
integrity, respectively. The last subsection specifies security measures for preserv-
ing information confidentiality. If more than one security objective applies to the word
processor (for example, availability and confidentiality), make sure to review the
subsection for each applicable objective.
8.2 THREATS TO SECURITY
8.2.1 Threats to Information Availability
Specific threats to information availability include:
Hardware Failure: In some cases, word processors are incapable of
8-1
-------
Information Security Manual 12/15/89
being restarted because of hardware failure. In addition, sometimes the
hardware fails during use for a variety of reasons. The most common
problem is a disruption or surge of electrical power, but the failure of almost
any internal component can cause the system to crash.
Accidental Data Destruction: The most common way that information is
accidentally destroyed is by users issuing incorrect commands. For
example, documents can be inadvertently deleted.
Sabotage: Information can be deliberately destroyed by malicious
individuals. Such destruction can be the result of random vandalism, but
it can also be an act by an employee who has been dismissed or
disciplined, or an act by an individual who is hostile to the mission of the
office.
Two additional threats to availabilitytheft and damage to mediawere discussed
in Section 3.
8.2.2 Threats to Information Integrity
Specific threats to information integrity include:
Deliberate Distortion of Information Fraud and Sabotage: Data integ-
rity can be damaged by the deliberate actions of system users or other
individuals with access to the systems. These actions could be motivated
by revenge (for example, by recently disciplined or reprimanded employ-
ees) or could be intended to perpetrate or cover up fraudulent activities,
mismanagement, or waste.
Accidental Damage: This occurs when individuals unknowingly modify
information or erase pages and documents.
Accidental threats to information integrity overlap with the issues discussed under
availability. The distinction is based on whether the distortion is discovered. If so,
the distortion would be generally be considered to consist of a loss of information and
would therefore be considered to be a availability problem. When the damage
remains undetected, decisions may be made or other actions may be taken based
upon incorrect information, resulting in a failure of integrity.
8.2.3 Threats to Information Confidentiality
Specific threats to information confidentiality are largely problems of access control.
Note that the threats described below apply to confidential information in its various
forms, that is, in hard copy, on removable media like diskettes, and on printer ribbons.
8-2
-------
Information Security Manual 12/15/89
Magnetic media containing confidential information can be accessed by
individuals from whom the information should be restricted. If diskettes
containing confidential information are not secured, unauthorized indi-
viduals can install them on a microsystem and browse their contents.
Unauthorized individuals could see information on a screen or printout if
confidential data are processed in an unsecured area or if printouts are not
protected in storage.
Confidential information can be deciphered from printer ribbons used to
print confidential reports.
Individuals authorized to access confidential information could deliber-
ately share printed reports or magnetic media containing confidential data
with unauthorized individuals.
8.3 PROCEDURES TO MAINTAIN AVAILABILITY
8.3.1 Lock-up Media
To avoid theft, store media in a locked cabinet or room.
8.3.2 Write Protection
Whenever possible, write-protect files to avoid accidental destruction.
8.3.3 Isolated Storage
Isolate the critical/high value information on its own storage media. This means
dedicating the diskette to the one sensitive document or collection of information.
8.3.4 Backups
In general, the most important step to be taken to protect information availability is
to make copies of the information. Backups are performed to provide for easy
recovery from a disaster. If information has been backed up and if the backup is
safely stored, the information will be recoverableno matter what happens. Note,
however, that information or documents that have been created since the last
backup may have been lost and may need to be re-input.
Two backup copies should be made of information or documents of medium-level
availability. One of the copies should be a hard copy (paper) version for storage in
8-3
-------
Information Security Manual 12/15/89
the office files. The second copy should be on magnetic media and should be kept
in a location other than the original (for example, in the offices of another branch or
division).
Two backup copies should also be made of information or documents of high-level
availability. The paper copy should be stored as above. The copy on magnetic
media, however, should be kept in a physically separate, off-site location.
8.4 PROCEDURES TO PRESERVE INTEGRITY
The security measures needed to ensure integrity represent a mix of those associ-
ated with maintaining availability and those associated with preserving confidential-
ity. Availability and confidentiality are almost opposites; backup copies of informa-
tion made to enhance availability can aggravate the problem of preventing the
disclosure of the information. In a very real sense, however, integrity is the objective
in the middle.
Integrity involves elements of the availability objective because if information is
corrupted or partially destroyed, intact backup copies are essential. On the other
hand, integrity involves elements of the confientiality objective because preventing
fraud and sabotage are largely problems of controlling access.
8.4.1 Availability-Related Procedures
Adhere to all procedures described in Section 8.3. This will ensure that backups are
created.
8.4.2 Confidentiality-Related Procedures
Adhere to the access control procedures described in Section 8.5.
8.5 PROCEDURES TO PRESERVE CONFIDENTIALITY
8.5.1 Procedures for Medium-Level Confidentiality
EPA organizations with statutory authority for certain types of confidential informa-
tion may issue security procedures dealing exclusively with a particular type of
8-4
-------
Information Security Manual 12/15/89
information (for example, TSCA or FIFRA CBI). Because of statutory requirements,
some of those procedures may be more stringent than those required here. EPA
employees must make sure that they also adhere to such organizational standards
and procedures.
8.5.1.1 Discourage Traffic
Discourage traffic in the area where the word processor is located when in use.
Unauthorized individuals should be kept out of the area so that they cannot view data
that might appear on the screen.
8.5.1.2 Printer Ribbons
Printer ribbons used to print confidential documents should be considered confiden-
tial as well. Destroy exhausted ribbons so that they cannot be deciphered by an
unauthorized individual.
8.5.1.3 Disposal
Be careful when disposing of diskettes or paper containing confidential information.
Before the paper is thrown away, it must be shredded or burned. Diskettes must
either be degaussed or placed in burn bags. (Degaussing erases information
through demagnetization.)
8.5.1.4 Lock-Up Media
Lock-up diskettes and paper copies when not in use in a locked cabinet or a locked
room.
8.5.1.5 Clear System
Clear the system of confidential information after each confidential processing ses-
sion. Power-off the unitto clear any volatile memory, that is, random access memory
(RAM).
8.5.2 Procedures for High-Level Confidentiality
The EPA has only one type of information in this category - National Security
Information. Procedures for handling and storing this information are contained in
the "National Security Information Handbook" issued by OARM. The Handbook also
contains procedures governing self-inspection.
8-5
-------
information Security Manual 12/15/89
9. SECURITY FOR APPLICATION SYSTEM
DEVELOPMENT, OPERATIONS AND
MAINTENANCE
9.1 INTRODUCTION
The determination of application security requirements and appropriate controls
requires three-way communication among the owner, application programmer/
system analyst, and processing installation. Once the owner has determined and
communicated the system's sensitivity and security objectives, the owner needs to
work with the installation and the application programmer/system analyst to develop
the appropriate, cost-effective mix of installation and software-based controls. Once
the system has become operational, the installation maintains the installation-
oriented controls and the owner authorizes users and makes sure the users and the
installation adhere to the security requirements.
Security issues and concerns must be an essential part of the entire software
lifecycle (from development to operation to modification). If they are not, the owner
runs the risk the application will be underprotected oroverprotected. Overprotection
wastes resources and underprotection requires that security safeguards be imposed
afterthe fact. Retrofitting security measures on adeveloped piece of software is both
complex and expensive.
This section sets forth security procedures for the application system development
and operation process. While this section emphasizes the importance of installation
involvement in developing a cost-effective mix of system controls, this section deals
with security primarily from an application, ratherthan installation, perspective. The
focus here is on application systems and the responsibilities of ownership. The
responsibilities of installations and custodians are set forth in Sections 6 and 7. This
section is to be used as follows:
Application Programmers/System Analysts use these procedures to de-
termine what security measures must be in place to protect the availability,
confidentiality, and integrity of sensitive Agency applications.
Owners develop the security specifications and the tests needed for ap-
plication certification based on the procedures presented here and based
on dialogue with the application developers and processing installation.
9-1
-------
Information Security Manual 12/15/89
Owners then make sure the operational application is protected on an
ongoing basis using the procedures presented here.
The remainder of this section is organized as follows. The next subsection catalogs
and describes the basic application development controls that can be used to
achieve the three security objectives. Subsection 9.3 introduces the concept of the
software lifecycle and explains how to address, build in, and maintain security
controls at the various life cycle stages.
The overall structure and content of this section is based in large part on Federal
Information Processing Standards Publication (PIPS PUB) 73, entitled "Guidelines
for Security of Computer Applications." FIPS PUB 73 is extremely helpful and
application developers may wish to consult it for more detailed information on
selected topics. A copy is available in the EPA Headquarters library or through the
National Technical Information Service. To a lesser extent, this section is also based
on the "Management Guide to the Protection of Information Resources" issued by
the National Institute of Standards and Technology.
9.2 BASIC DEVELOPMENT CONTROLS
This subsection introduces six basic development controls to be used to meet the se-
curity objectives of availability, integrity, and confidentiality. The six controls, which
are explained in detail below, are as follows:
Data Validation
User Identity Verification
Authorization
Joumalling or Logging
Variance Detection
Encryption
Table 9-1 shows the security objective (or objectives) addressed by each of these
basic controls. Note that most controls preserve confidentiality and integrity rather
than maintain availability. This is because continued availability is often achieved
through administrative/procedural safeguards such as backup routines and contin-
gency planning.
9-2
-------
Information Security Manual
12/15/89
TABLE 9-1
BASIC CONTROLS AND THE
OBJECTIVES THEY ADDRESS
Objectives
Control
Data Validtion
User Identity
Verification
Authorization
Joumalling/
Logging
Variance
Detection
Encryption
Availability
X
X
X
Integrity
X
X
X
X
X
X
Confidentiality
X
X
X
X
X
9-3
-------
Information Security Manual 12/15/89
It should be noted that some of these controls may be partially implemented by the
operating system, the hardware, or the management of the processing installation.
Such joint implementation results because the boundaries between the application
and operating systems or between hardware and software are sometimes fuzzy.
9.2.1 Data Validation
Data validation involves checking data to make sure they are accurate, complete,
and consistent. This checking or examination should occur both during entry and
during processing. In addition, input data elements should be compared with one
another to ensure consistency and reasonableness.
Techniques for validating data during entry include:
Examining fields for various characteristics, including proper format,
values within certain bounds, and check digits.
Maintaining control totals, record/transaction counts and batch number
checks for groups of records or transactions.
Techniques for validating data during processing include:
Incorporating dummy records into a data base and doing test transactions
against these records during normal processing of the application to
evaluate processing accuracy.
Tracing specially marked transactions through the processing cycle to de-
termine if processing was correct.
Sampling methods where certain data are selected for close examination
to determine their validity.
Techniques for ensuring consistency and reasonableness include:
Comparing one field against another for a certain relationship, for ex-
ample, one field with a value less than half of another field.
Evaluating the current record against the previous record.
9.2.2 User Identity Verification
User identity verification involves establishing a means to control access to the
application by requiring each individual to prove who he/she is. The basic access
9-4
-------
Information Security Manual . 12/15/89
control methods include: (1) passwords, (2) objects like magnetic cards or keys,
and (3) personal characteristics such as signatures or voiceprints.
User identification based on personal characteristics like signature is prohibitively
expensive. For most on-line applications, the most practical technique is a password
scheme.
There are two predominant types of passwords: (1) Host-level passwords, and (2)
information access passwords. Host-level passwords are those used when first
logging-on to the computer system, for example, VAX, Prime, or IBM mainframe. A
host-level password verifies the identity of the user before the user is allowed to do
anything on the system.
An information access or "second level" password is used to protect individual files
or data sets resident on the computer system. Information access passwords are
entered when the logged-on user requests access to a password-protected file or
data set. Information access passwords can be either unique like host-level
passwords or shared by multiple users needing access to common data. Unique
information access passwords require access control software apart from the host-
level log-on process.
Host-level passwords are administered by the processing installation, as described
in Section 6. NDPD (which operates NCC and WIC and supports other sites) does
not advocate the use of information access passwords. Instead, the NCC makes
Resource Access Control Facility (RACF) available to application owners. RACF
bases information access on user identification; Prime and VAX have similar
schemes based upon access control lists (ACL).
Any contemplated use of information access passwords at an NDPD managed or
supported facility must be discussed with the Security Officer for that facility. If
information access passwords are selected as a control measure, make sure of the
following:
Passwords of at least six characters in length can be accepted
Passwords must contain at least one alpha and one numeric character
Passwords can be deleted or changed in a straightforward, but controlled
fashion.
9-5
-------
Information Security Manual 12/15/89
9.2.3 Authorization
For automated applications, some users may only be authorized to perform certain
functions or to use certain data files. If there are many users of a sophisticated
application that has many data files, confidentiality and integrity will be preserved if
users are only allowed access to needed functions and files. A basic authorization
scheme can be enforced if the application has different interfaces for different
purposes, for example, for data entry or for report generation.
While the security literature describes many different types of authorization schemes,
they all have three essential features. They control: (1) who will have access, (2)
what modes of access they will have, and (3) which objects or resources they will be
allowed to access. The "who" component includes both users and terminals. Modes
of access usually include read-only access, read/Write access, and the like. Objects
or resources typically include:
Data objects like files, record types, and libraries
Executable objects like commands or programs
Devices like printers or various storage media such as tapes or disks.
Any authorization scheme that is selected should have two basic properties. First,
it should operate under the principle of least privilege where users should be limited
to only what they need to do. Second, the scheme should be flexible enough to allow
for changes in authorization in a straightforward, yet controlled way.
9.2.4 Journalling or Logging
Joumalling or logging involves recording particular events as they occur during data
entry or processing. Joumalling provides an audit trail for tracking down errors or
security violations. Joumalling provides a basis for establishing accountability, that
is, a basis for holding individuals responsible for their activities. It also may aid in
recovering from a processing mishap or disaster.
While it is possible to journal every event and transaction, this is typically impractical
and not cost-effective. In selecting what to log, owners and system developers
should focus on the type of information and security objectives involved. Clearly a
financial system that disburses funds must keep track of who makes each credit and
9-6
-------
Information Security Manual 12/15/89
debit transaction, exactly when each transaction was made, and similar events. In
an application where integrity is not as crucial, associating each transaction with a
user is probably unnecessary.
Any joumalling activity typically falls into one or more of the following categories:
Logging the nature of the event (for example, system usage like log-ons,
input/output like opening a file, or updates like file changes).
Logging the identity of those associated with the event, including users,
devices, or files.
Logging characteristics of the event such as time, date, or number of data
entry errors.
9.2.5 Variance Detection
As the term implies, variance detection is concerned with identifying departures from
the norm that are deemed to be of significance. Variance detection may either
augment an authorization scheme or be used instead of authorization when
authorization is impractical.
Variance detection can be accomplished through:
Review and analysis of the results of the joumalling or logging process
External methods such as audits or surprise visits
Dynamic monitoring, which involves real-time detection of certain trigger
events. For example, an application designed to electronically transmit
funds only at certain times could be programmed to warn the console
operatoriftransferisattemptedatsomeothertime. As a second example,
a system can automatically count the number of attempts made to gain
access through password guesses before it ends the log-in session.
9.2.6 Encryption
Encryption involves scrambling or encoding information so that it is of no use even
if it is obtained by unauthorized individuals. Encryption is the primary means of
protecting data during communication. The decision whether or not to encrypt data
during communication would depend on the communication configuration. If confi-
dential data are being transmitted over a dedicated line, encryption may be unnec-
essary unless line tapping is a serious threat. If the data are traveling over a network
9-7
-------
Information Security Manual 12/15/89
where many unauthorized users could potentially intercept the information, encryp-
tion may be effective.
Information stored off-line in tapes or other media may also be encrypted to prevent
it from being read if it is stolen. In most instances, however, physical security
measures (such as keeping the media under lock and key) are easier to implement
and are adequate.
The encryption of on-line data files will be cumbersome unless the operating system
and hardware have certain supporting capabilities. In most instances, a password
protection scheme should probably be sufficient. In instances where it is deemed
necessary to supplement the passwords with encryption, choose a processing
location like the NCC where the supporting hardware and operating system features
are already in place.
9.3 CONTROLS AND THE SOFTWARE LIFECYCLE
9.3.1 The Software Lifecycle
The only way to ensure that the kind of controls described in Section 9.2 are correctly
implemented is to make them an explicit part of the software development process.
The three-volume "EPA System Design and Development Guidance" issued by
OIRM describes the software design and development process at EPA and includes
general references to security at appropriate points. The "Operations and Mainte-
nance Manual," also issued by OIRM, completes the guidance for managing the
software lifecycle by addressing the day-to-day performance of system operations
and maintenance activities. It also includes general references to security at appro-
priate points. The purpose of this section is to describe more specifically how to
incorporate security controls into the lifecycle.
The "EPA System Design and Development Guidance" and the "Operations and
Maintenance Manual" define four basic lifecycle phases:
Phase 1: Mission Need Analysis
Phase 2: Preliminary Design and Option Analysis
Phase 3: System Design, Development, and Implementation, including
system testing and evaluation
9-8
-------
Information Security Manual 12/15/89
Phase 4: Operations and Maintenance
At a minimum, application development and operation need to include security
specifications, security design reviews, system tests of security controls, and
ongoing system monitoring to ensure controls are implemented. Table 9-2 presents
the relationship between these requirements, the EPA lifecycle, and the participants
or roles associated with the lifecycle.
The process begins with the owner's determination of sensitivity and relevant
security objectives. The next step is to develop control requirements based on
Section 9.2. Determining a cost-effective mix of adequate controls depends on the
owner understanding why the application is sensitive (that is, relevant security
objectives and degree of sensitivity) and the types of controls the processing
installation can provide to address that sensitivity.
If the availability objective is relevantto the application, the owner needs to determine
backup and availability requirements and communicate them to the installation. The
owner then needs to make sure the installation can satisfy any special requirements,
such as more frequent backup than is typical or the need for continuous availability
(that is, downtime of more than just a few hours would be unacceptable).
As the development process proceeds, the owner creates the security information
needed for the Application Certification Worksheet. Please see Appendix B.
The development process ends with the application being placed into use or produc-
tion. This is a formal milestone that clearly separates the developmental version of
the system from the operational version. At this point, key security responsibilities
transfer to the installation; the required installation controls are specified in Section
6. Once the system is ready to use, the owner needs to make decisions about who
can access the system and what kind of access they will have (for example, read-
only access). The responsibilities of ownership do not end atthis point, however. On
a continuing basis, the owner needs to make sure the application is protected and
that the users and installation adhere to security requirements.
In the middle of the development process, the focus is on security design and testing.
These activities are the subject of Subsection 9.3.2 below.
9-9
-------
Information Security Manual
12/15/89
TABLE 9-2
SECURITY AND THE SOFTWARE LIFECYCLE
Lifecycle
Phase
Security
Activity
Role/
Participant
Mission Need Analysis
Preliminary Design
and Options Analysis
System Design,
Development, and
Implementation
Operations and
Maintenance
Identification of Security
Needs and Considerations
Determine Security
Requirements and
Specifications
Design Controls; Conduct
Design Review; Test and
Review Security Controls;
Determine Backup and
Availability Requirements
Maintain/Alter Security
Controls as needed;
Authon'ze Users; Monitor
Users/Installation for
Compliance with Security
Requirements
Owner
Owner with
Application Programmer/
System Analyst and Mini/
Mainframe Computer
Security Officer
Application
Programmer/System
Analyst with Owner
Conducting Reviews;
Owner Determines Back-
up and Availability Needs
Owner with Applic-
ation Programmer
as needed and Mini/
Mainframe Computer
Security Officer
Implementing Installation-
Based Controls
9-10
-------
Information Security Manual 12/15/89
9.3.2 Implementing Controls: Building Security into the Development Phase
9.3.2.1 Designing for Security
This is the stage when decisions about how to implement the basic development
controls must be made. Security considerations should be an integral part of the
overall design effort because security opportunities missed now will be difficult to
recapture later. In designing the necessary basic controls, adhere to the following
overall procedures:
Restrict user interfaces to the functions and files users need to access.
Unnecessary flexibility greatly complicates security. Limit the number of
- unsuccessful attempts to access an application or file. It should be noted
that certain processing facilities have made access control features
readily available. For example, Resource Access Control Facility (RACF)
is available on the NCC IBM mainframe and on the logical mainframes.
RACF can be used to protect data sets from unauthorized users or from
deletion. The NCC and other installations also limit the number of
consecutive password failures before a user is blocked from the system.
See the "NDPD Operational Policies Manual" for more information.
Design user interfaces that are easy to understand. This reduces user
errors and the potential for data corruption. Specific engineering tasks can
include intelligible system and error messages and on-line help functions.
If the application will be used continuously and has significant storage re-
quirements, consider dedicating a micro or minicomputer to the applica-
tion. The choice of hardware environment involves many other factors,
including needed physical security, access controls, and logging/auditing
capability. Dedicated hardware, such as a micro or minicomputer, can
make it easier to protect software and data. In many circumstances a
mainframe environment may be more appropriate. This is why three-way
communication among the owner, application developer, and installation
is important.
Isolate the code that is critical to security. If possible, create separate mod-
ules for the security controls, which facilitates both protection and audit.
Consider using automated controls to protect these modules. These
include: (1) checksums on the object code to detect unauthorized
changes, (2) hardware protection states or domains to protect code, and
(3) placin g critical code in a fixed area of memory so that read-only
memory can be used.
Design the system so that it is auditable, that is, so that it is relatively easy
to confirm that the system is functioning as it was intended to function.
Systems that are not designed for auditability are harder to test and
evaluate.
If availability is important, design the system so that recovery from minor
9-11
-------
Information Security Manual 12/15/89
problems or major disruptions is facilitated. For example, if a computer
at another site has been designated as a backup, make sure the system
is readily transportable to the alternative environment.
9.3.2.2 Programming for Security
Programming practices can have three impacts on security. First, errors in program-
ming security controls (such as joumalling or logging) can limit or cancel the effec-
tiveness of the control. Second, programming errors in the non-security-related
portions of the code can greatly affect data reliability and accuracy. Finally,
unauthorized additions or changes to the code by programmers can result in fraud
or abuse.
During the programming stage, adhere to the following practices:
Have each section of the code peer-reviewed as it is completed. The
review should focus on the efficiency, maintainability, and correctness of
the code.
Have the program library:
- Limit access to program modules to authorized individuals
- Record all accesses to program modules
- Store previous versions of a module so that comparisons with the
present version can be made.
Document all security-related portions or modules of code. Security-
related code is code that implements basic controls, code that accesses
sensitive data, or code that processes sensitive data. Once the documen-
tation is developed, it also needs to be protected so that the integrity or
confidentiality of the system are not compromised.
9.3.2.3 Testing and Evaluating Software
The last thing the application developer needs to do is to test the software to make
sure it meets the security requirements. Effective testing begins with the develop-
ment of a test plan, which describes what will be tested with what methods. For
effective security testing, particular emphasis should be placed on how the applica-
tion handles unusual, unlikely, and illegal events.
The test plan should include both static evaluation and dynamic evaluation. For
9-12
-------
Information Security Manual 12/15/89
static evaluation, the following techniques are recommended:
Code review by an independent party
Source code analyzers to provide details about selected characteristics of
the source program
Penetration analysis to determine whether a determined individual could
bypass controls.
Dynamic evaluation is concerned with testing the operation of portions of the
program with dummy data and comparing the results with the expected results. To
aid in the evaluation process, the following techniques are recommended:
Program analyzers to collect operating data about the executing program,
for example, the number of times a particular data file is accessed
Comparative analysis, which involves testing the new system for known
flaws in similar existing systems.
If disclosing confidential information is a security concern, care should be taken
when granting individuals testing the software access to "live" data from the
operational environment.
9.3.3 Operating and Maintaining Controls
Security considerations do not cease once the application becomes operational.
Even the best conceived and developed controls need to be managed on a
continuing basis. In operating and maintaining security safeguards, adhere to the
following procedures:
As the system becomes operational, the owner needs to make decisions
about who can access the system and what kind of access they will have
(for example, read-only access). The responsibilities of ownership do not
end at this point, however. On an ongoing basis, the owner needs to make
sure that the application is protected and that users and the installation
adhere to security requirements. At a very minimum, the application must
be re-certified every three years (see Appendix B).
Mechanisms for ensuring ongoing compliance can vary from system to
system. If, for example, journallmg/logging or variance detection are
important controls, the owner can request that the installation produce
standard reports. If frequent backup is essential, the owner can simulate
a disaster by requesting that certain files be restored within a specified
time period. Or, the owner may structure an internal control review or
related study as part of the Agency's internal control review process to
9-13
-------
Information Security Manual 12/15/89
gauge user and installation compliance with security requirements.
In monitoring compliance, it is not expected that the owner will have a
detailed technical understanding of how all his/her security controls work
(for example, how an encryption algorithm operates or how variance
detection code operates), but ratherthat he/she will take the steps needed
to be confident that the system is adequately protected.
Maintenance programmers are subject to the same procedures as system
development programmers for programming, testing, and evaluating
software (see Section 9.3.2). In addition, if disclosing confidential infor-
mation is a security concern, care should be taken when granting main-
tenance programmers access to "live" confidential systems for problem
identification or testing purposes.
9-14
-------
Information Security Manual 12/15/89
10. SECURITY FOR PAPER
AND MICROFORM RECORDS
10.1 INTRODUCTION
The purpose of this section is to describe the security measures that need to be taken
to ensure adequate protection of collections of paper and microform (that is,
microfiche and microfilm) records. The focus here is not on normal desk or office
files, but rather on significant quantities of records that constitute manual information
systems.
This section is to be used as follows:
Owners develop the security requirements for the information collection
based on the procedures presented here.
Records Management Officers assign responsibility for the physical
custody of the records and make sure that custodians are properly
implementing these procedures.
Custodians are responsible for making sure the necessary security
controls are in place.
The remainder of this section is organized as follows. The next subsection explains
the relationship between this section and other Agency security procedures, for
example, the TSCA CBI Manual." Subsection 10.3 catalogs and describes specific
threats to the security of manual information systems. The last three subsections
set forth security measures for ensuring the availability, integrity, and confidential-
ity of record systems. If more than one objective applies to the record system (for
example, availability and confidentiality), make sure to review the subsection for
each applicable objective.
10.2 RELATIONSHIP TO OTHER PROCEDURES
Over the years, the EPA has developed several sets of procedures governing
specific types of sensitive information. The great majority of these existing proce-
dures deal with some type of confidential information, especially CBI. These
procedures are typically issued by EPA organizations with statutory authority forthe
information (for example, the Office of Pesticides and Toxic Substances for TSCA
10-1
-------
Information Security Manual 12/15/89
or FIFRA CBI). EPA employees must make sure they adhere to all of these
organizational standards and procedures, as well as to the procedures presented
here.
The scope and nature of these other, type-of-information procedures is as follows:
The Office of Administration and Resources Management has issued
procedures governing National Security Information (in the "National
Security Information Handbook") and Privacy Act data. The NSI hand-
book also contains self-inspection procedures for organizations dealing
with National Security Information.
The Office of Pesticides and Toxic Substances has developed manuals
governing both TSCA and FIFRA CBI.
The Office of Solid Waste and Emergency Response has issued proce-
dures concerning RCRA CBI.
The Office of Enforcement and Compliance Monitoring has established
enforcement docket security procedures for handling and disposing of
docket reports.
Within the Office of Air and Radiation, the Office of Mobile Sources has
procedures for the handling of proprietary data received from auto
manufacturers and the Office of Air Quality Planning and Standards
(Emission Standards and Engineering Division) has procedures for safe-
guarding the CBI it receives.
The Office of the Inspector General Manual contains sections dealing with
confidential information obtained during the course of investigations and
audits.
The Office of Water has developed procedures related to trade secret data
obtained under Section 308 of the Clean Water Act.
Most of these procedures contain special instructions and handling requirements.
To make sure they are in compliance, EPA employees must review these other
procedures when appropriate.
10.3 THREATS TO MANUAL INFORMATION SYSTEMS
10.3.1 Threats to Availability
Specific threats to record availability include:
Theft: Paper and microform records are small, light, and easily moved.
10-2
-------
Information Security Manual 12/15/89
Accidental Destruction of Records: A record may be accidentally de-
stroyed or lost through an act of nature (such as a flood or fire) or through
human error (such as inadvertently throwing it away).
Deliberate Destruction of Records: Records can be deliberately de-
stroyed by malicious individuals. Such destruction can be the result of
random vandalism, but it can also be an act by an employee who has been
dismissed, disciplined, or is hostile to the mission of the office.
10.3.2 Threats to Integrity
Specific threats to record integrity include:
Accidental Damage: This occurs when individuals inadvertently and
unknowingly change records. While this is a common threat to automated
information systems, it is less prevalent for manual systems. It would
occur, for example, if a system of records became jumbled. If the
disorganization went undetected, decisions could be made based on
information that seemed complete, but was not because crucial informa-
tion had been misfiled elsewhere.
Deliberate Distortion of Records Through Fraud and Sabotage: The
integrity of records can be damaged by the deliberate actions of individu-
als with access to the records. These actions could be motivated by
revenge (for example, by recently disciplined or reprimanded employees)
or could be intended to perpetrate or cover up fraudulent activities,
mismanagement, or waste.
10.3.3 Threats to Confidentiality
Threats to confidentiality are largely problems of access control. Specific threats to
record confidentiality include:
Unauthorized Disclosure: If rooms or cabinets housing confidential rec-
ords are not secure, unauthorized individuals can open them and review
the records. Unauthorized disclosure can alsooccurif authorized individu-
als deliberately share confidential records with unauthorized individuals.
Typewriter and Printer Ribbons: Confidential information can be deci-
phered from typewriter and pri nter ribbons that have been used to produce
confidential reports.
10-3
-------
Information Security Manual 12/15/89
10.4 PROCEDURES TO MAINTAIN AVAILABILITY
10.4.1 Procedures for Medium-Level Availability
10.4.1.1 Environmental Controls
To avoid water damage, do not store the records directly beneath sprinkler heads or
water pipes. Do not locate the records near boiler rooms or water heaters.
10.4.1.2 Access Control List
The information owner must establish for the custodian a list of individuals who are
allowed access to the records. On a quarterly basis, the owner should review the list
to update it with employee additions or deletions.
10.4.1.3 Document Control and Tracking
To prevent the loss of records, establish a document control and tracking system.
This system may be automated or manual. In either the case, the system must
include:
A unique identifier, the Document Control Number (DCN), for each
document in the collection of records.
A cradle-to-grave tracking capability which follows a record from the time
it is received or written until it is destroyed or transferred elsewhere. For
a manual system, the worksheets shown as Exhibits 10-1 and 10-2 can
be used. Exhibit 10-1 isaninventoryofallrecordsinthecollection. Exhibit
10-2 is a sign-out log indicating who has which records. Automated
tracking systems should capture the same information shown in the
exhibits, that is:
- Date record created or received
- DCN
- Dates record checked out and returned
- Identity of who has a checked out record
- The disposition of a record, that is, transter or destruction
10.4.1.4 Backup Copy
Maintain a second copy of the records at an off-site storage location. In the event
of a major disaster that destroys the original set of records, this second set will prove
invaluable. The backup copy may be in several different forms, including microfiche,
10-4
-------
Information Security Manual 12/15/89
EXHIBIT 10-1
INVENTORY
Date No. of Document
Received DCN Pages Originator Disposition
10-5
-------
Information Security. Manual 12/15/89
EXHIBIT 10-2
SIGN-OUT LOG
Date User Information Date
Checked Out DCN User Name EPA ID Number Checked In
10-6
-------
Information Security Manual 12/15/89
paper, or word processing diskettes.
10.4.2 Procedures for High-Level Availability
This part applies to all record collections that must be available continuously or within
one day and/or collections that are of very high value. All procedures set forth in
Subsection 10.4.1 also apply here. In addition, the procedures described below will
be followed.
10.4.2.1 Fire Protection
Store the records in a fireproof file cabinet.
10.4.2.2 More Accessible Backup Copy
For critical collections, make sure the second copy that is being stored at an off-site
location can be retrieved within a few hours. Storage locations that require one to
two days notice to retrieve records are of limited usefulness.
10.5 PROCEDURES TO MAINTAIN INTEGRITY
The security measures needed to ensure integrity represent a mix of those
associated with maintaining availability and those associated with preserving
confidentiality. As was noted earlier, copies of records made to enhance availability
can aggravate the problem of preventing the disclosure of information stored in the
record collection. In a very real sense, integrity is the objective in the middle.
Integrity involves elements of the availability objective because if information is
altered or partially destroyed, an intact backup copy is essential. On the other hand,
integrity involves elements of the confidentiality objective because preventing fraud
and sabotage are largely problems of controlling access.
10.5.1 Procedures for Medium-Level Integrity
10.5.1.1 Availability-Related Procedures
Adhere to all procedures described in Section 10.4.1.
10.5.1.2 Confidentiality-Related Procedures
Make sure the records are kept in a locked cabinet or a locked room. Use the lock
10-7
-------
Information Security Manual 12/15/89
whenever the records are not in use, not just at night. If the lock is a combination lock,
change the combination at least annually or whenever there is a change in who is
allowed access to the records.
10.5.2 Procedures for High-Level Integrity
All procedures set forth in Section 10.5.1 above also apply here. In addition, store
the records in a fireproof cabinet or container.
10.6 PROCEDURES TO PRESERVE CONFIDENTIALITY
Preserving confidentiality involves controlling access to information and records.
Access controls for manual information systems are of two types: (1) physical, such
as door locks, and (2) administrative, such as lists which specify who is allowed
access to the records.
10.6.1 Procedures for Medium-Level Confidentiality
10.6.1.1 Access Control List
The information owner must establish for the custodian a list of individuals who are
allowed access to the records. On a monthly basis, the owner should review the list
to update it with any additions or deletions.
10.6.1.2 Document Control and Tracking
To maintain accountability and to further control access, establish a document
control and tracking system. This system may be automated or manual. Develop
and maintain the system in accordance with the procedures described in Section
10.4.1.3.
10.6.1.3 Lock Up Records
Make sure the records are kept in a locked cabinet or a locked room. Use the lock
wheneverthe records are notin use, not just at night. If the lockisacombination lock,
change the combination at least annually or whenever there is a change in who is
allowed access to the records.
10.6.1.4 Photocopies
A lack of photocopying controls can defeat strong access controls in other areas. It
10-8
-------
Information Security Manual 12/15/89
does little good to lock everything up and log each document in and out if the person
using the document is allowed to make copies at will.
Only the owner or custodian should be allowed to make photocopies. Photocopying
by all others should be prohibited. All photocopies must be entered into the
document control and tracking system under their own DCNs.
10.6.1.5 Disposal
All confidential paper documents must be shredded or burned before being thrown
away. Place discarded microfiche or microfilm into burn bags for proper disposal.
10.6.1.6 Typewriter and Printer Ribbons
Ribbons used to produce confidential documents should be considered confidential
as well. Place exhausted ribbons in bum bags so that they cannot be deciphered by
an unauthorized individual.
10.6.2 Procedures for High-Level Confidentiality
The EPA has only one type of information in this category - National Security
Information (NSI). Procedures for handling and storing NSI are contained in the "NSI
Handbook" issued by OARM.
10-9
-------
Information Security Manual 12/15/89
APPENDIX A
INFORMATION SECURITY *
1. PURPOSE. This document establishes a comprehensive, Agency-wide
security program to safeguard Agency information resources. This document sets
forth the Agency's information security policy for both manual and automated
systems and assigns individual and organizational responsibilities for implementing
and administering the program.
2. SCOPE AND APPLICABILITY. This document applies to all EPA organiza-
tions and their employees. It also applies to the facilities and personnel of agents
(including contractors and grantees) of the EPA who are involved in designing,
developing, operating or maintaining Agency information and information systems.
3. BACKGROUND
a. Information is an Agency asset, just as property, funds and personnel are
Agency assets. The EPA is highly dependent upon its information re-
sources to carry out program and administrative functions in a timely,
efficient and accountable manner.
b. The EPA relies on its information collection authority under various
enabling statutes to fulfill effectively its environmental missions. The
willingness of the regulated community and State and local agencies to
supply requested information in a cooperative and timely fashion depends
on their confidence that the information will be adequately protected.
c. The Agency's information resources are exposed to potential loss and
misuse from a variety of accidental and deliberate causes. This potential
loss and misuse can take the form of destruction, disclosure, alteration,
delay or undesired manipulation. Moreover, the Agency can be subject to
acute embarrassment and litigation if certain business or personal infor-
mation is inadvertently or maliciously disclosed.
d. As a result, it is essential that an overall program be established to
preserve and adequately protect the Agency's information resources. At
the same time, it is equally essential that the program not unnecessarily
restrict information sharing with other Federal agencies, universities, the
Source: EPA Information Resources Management Policy Manual,
Chapter 8.
A-1
-------
Information Security Manual 12/15/89
public and State and local environmental authorities. Such information
sharing has historically played a vital role in the overall fulfillment of the
Agency environmental mission.
e. The management, control and responsibility for information resources
within EPA are decentralized. Consequently, the management and re-
sponsibility for information security are also decentralized. An important
example of this is the expanding use of personal computers, networking,
distributed data bases and telecommunications. These trends place new
responsibilities on office managers, research personnel and others not
previously considered information processing professionals. The "com-
puter center" cannot be relied upon to protect Agency operations. Controls
must be implemented and maintained where they are most effective.
f. In determining responsibilities for information security, it is useful to define
a framework of owner/custodian/user. Owners are those who create or
maintain information. Custodians are typically suppliers of information
services who possess, store, process and transmit the information. These
roles are often not discrete; the owner is often the principal custodian and
user of the information.
4. AUTHORITIES
a. OMB Circular A-130, Management of Federal Information Resources.
5. POLICY. It is EPA policy to protect adequately sensitive information and
sensitive applications, maintained in any medium (e.g., paper, computerized data
bases, etc.), from improper use, alteration or disclosure, whether accidental or
deliberate. Information and applications will be protected to the extent required by
applicable law and regulation in accordance with the degree of their sensitivity in
order to ensure the cost-effectiveness of the security program.
a. Information security measures will be applied judiciously to ensure that
automated systems operate effectively and accurately and to ensure the
continuity of operation of automated information systems and facilities
that support critical agency functions.
b. As required by OMB Circular No. A-130, all automated installations will
undergo a periodic risk analysis to ensure that appropriate, cost-effective
safeguards are in place. This risk analysis will be conducted on new
installations, on existing installations undergoing significant change and
on existing installations at least every five years.
c. Appropriate administrative, physical, and technical safeguards shall be
incorporated into all new ADP application systems (including PC-based
applications) and major modifications to existing systems.
A-2
-------
Information Security Manual 12/15/89
d. As required by OMB A-130, all new applications will undergo a control
review leading to formal certification. Existing sensitive applications will
be recertified every three years.
e. Access to sensitive personnel information and employment applications
will be limited to appropriate personnel in accordance with procedures
established by the Office of Personnel Management and monitored by the
EPA Office of the Inspector General.
f. Appropriate ADP security requirements will be incorporated into specifi-
cations for the acquisition of ADP related services and products.
g. An information security awareness and training program will be estab-
lished so that all Agency and contractor personnel are aware of their
information security responsibilities.
h. Information security must be a major factor in evaluating the use of
microcomputers. Microcomputer systems software is typically rudimen-
tary and affords little or no protection to information and programs.
Consequently, networked microcomputers, the ability to download data
from larger, protected computers onto microcomputers and microcom-
puter data processing, generally present problems in information security
(for example, problems of access control or control overthe dissemination
of information). All EPA employees and managers must be aware of the
information security implications of storing and processing sensitive infor-
mation on microcomputers, whether networked or stand-alone.
i. Therefore, it is EPA policy to discourage the use of microcomputers for
storing or processing sensitive information, unless cognizant EPA em-
ployees and managers have made sure that adequate information secu-
rity measures are in use. If adequate information security cannot be
maintained, an alternative system configuration must be used.
j. Information security violations will be promptly reported to appropriate
officials, including the Inspector General.
6. RESPONSIBILITIES
a. The Office of Information Resources Management is responsible for:
(1) Developing and issuing an information security policy in accordance
with all applicable Federal laws, regulations, and executive orders.
(2) Ensuring that all Agency organizational units are in compliance with
the information security program.
(3) Establishing training criteria and coordinating the development of an
information security training and awareness program.
A-3
-------
Information Security Manual 12/15/89
(4) Providing guidance on selecting and implementing safeguards.
(5) Participating as it deems appropriate, in management and internal
control re views conducted by the Office of the Comptroller to ensure
compliance with the information security program.
b. Each "Primary Organization Head" (defined by EPA Order 1000.24 as the
Deputy Administrator, Assistant Administrators, Regional Administrators,
the Inspector General and the General Counsel) is responsible for:
(1) Ensuring that sensitive information and applications within the organi-
zation are adequately protected.
(2) Establishing an organization-wide program for information security
consistent with organizational mission and Agency policy, including
assigning responsibility for the security of each installation to a
management official(s) knowledgeable in information technology and
security.
(3) Assure annually the Assistant Administrator for Administration and
Resources Management that organizational information resources
are adequately protected. This will be done as part of the internal
control review process required under OMB Circular No. A-123
(revised) and implemented under EPA Order 1000.24.
(4) Making sure that all automated installations within the organization
undergo a periodic "risk analysis" to ensure that appropriate, cost-
effective safeguards are in place.
(5) Ensuring the continuity of operations of automated information sys-
tems and facilities that support critical functions.
(6) Making sure that appropriate safeguards are incorporated into all new
organizational application systems and major modifications to existing
systems, that all new organizational applications undergo an informa-
tion security review leading to formal certification and that existing
sensitive applications are recertified every three years.
(7) Making sure that Federal employees and contractor personnel under-
stand their security responsibilities and that organizational security
regulations are properly distributed.
(8) Making sure that all organizational procurements of ADP equipment,
software and services incorporate adequate security provisions.
c. The Director, Facilities Management and Services Division, is responsible
for:
(1) Establishing and implementing physical security standards, guide-
lines and procedures in accordance with EPA information security
policy.
A-4
-------
Information Security Manual ' 12/15/89
(2) Establishing and implementing standards and procedures for National
Security Information in accordance with EPA information security
policy and all applicable Federal laws, regulations and executive
orders.
d. The Procurement and Contracts Management Division and the Grants
Administration Division are responsible for:
(1) Ensuring that Agency grant and contract policies, solicitations and
award documents contain provisions concerning the information
security responsibilities of contractors and grantees that have been
promulgated by OIRM.
(2) Establishing procedures to ensure that contractors and grantees are
in compliance with their information security responsibilities. Project
Officers are responsible for ensuring contractor compliance with
security requirements on individual contracts. Violations shall be re-
ported to the contracting officer, Inspector General and appropriate
OIRM official. Specific violations involving National Security Informa-
tion shall be reported to the Director, FMSD and the Contracting
Officer.
e. The Office of the Inspector General is responsible for:
(1) Establishing and implementing personnel security standards, guide-
lines and procedures in accordance with EPA information security
policy and all applicable Federal laws and regulations.
(2) Conducting or arranging investigations of known or suspected person-
nel security violations as it deems appropriate.
f. The Office of the Comptroller is responsible for:
(1) Allowing OIRM to review written internal control reports so that OIRM
is aware of the status of information security weaknesses.
g. Each EPA Manager and Supervisor is responsible for:
(1) Making sure their employees are knowledgeable of their information
security responsibilities.
(2) Ensuring that their employees adhere to the organizational informa-
tion security program established by the applicable Primary Organiza-
tion Head.
h. Each EPA Employee, Contractor and Grantee is responsible for:
(1) Complying fully with his/her information security responsibilities.
(2) Limiting his/her access only to information and systems he/she is
authorized to see and use.
A-5
-------
Information Security Manual 12/15/89
(3) Adhering to all Agency and organizational information security poli-
cies, standards and procedures.
(4) Reporting information security violations to appropriate officials.
Violations involving National Security Information shall also be re-
ported to the Director, FMSD.
7. DEFINITIONS.
a. "Applications Security" means the set of controls that makes an informa-
tion system perform in an accurate and reliable manner, only those
functions it was designed to perform. The set of controls includes the fol-
lowing: programming, access, source document, input data, processing
storage, output and audit trail.
b. "Confidential Business Information" includes trade secrets, proprietary,
commercial/financial information, and other information that is afforded
protection from disclosure under certain circumstances as described in
statutes administered by the Agency. Business information is entitled to
confidential treatment if: (1) business asserts a confidentiality claim, (2)
business shows it has taken its own measures to protect the information,
(3) the information is not publicly available or (4) disclosure is not required
by statute and the disclosure would either cause competitive harm or
impair the Agency's ability to obtain necessary information in the future.
c. "Information" means any communication or reception of knowledge such
as facts, data or opinions, including numerical, graphic, or narrative forms,
whether oral or maintained in any medium, including computerized data
bases (e.g., floppy disk and hard disk), papers, microform (microfiche or
microfilm), or magnetic tape.
d. "Information Security" encompasses three different "types" of security:
applications security, installation security and personnel security. In total,
information security involves the precautions taken to protect the confi-
dentiality integrity and availability of information.
e. "Information System" means the organized collection, processing, trans-
mission and dissemination of information in accordance with defined
procedures, whether automated or manual.
f. "Installation" means the physical location of one or more information
systems, whether automated or manual. An automated installation
consists of one or more computer or office automation systems including
related peripheral and storage units, central processing units, telecommu-
nications and operating and support system software. Automated instal-
lations may range in size from large centralized computer centers to
stand-alone personal computers.
g. "Installation Security" includes the use of locks, badges and similar
measures to control access to the installation and the measures required
A-6
-------
Information Security Manual 12/15/89
for the protection of the structure housing the installation from accident,
fire and environmental hazards. In addition to the above physical security
measures, installation security also involves ensuring continuity of opera-
tions through disaster planning.
h. "National Security Information" means information that is classified as Top
Secret, Secret, or Confidential under Executive Order 12356 or predeces-
sor orders.
i. "Personnel Security" involves making a determination of an applicant's or
employee's loyalty and trustworthiness by ensuring that personnel inves-
tigations are completed commensurate with position sensitivity definitions
according to the degree and level of access to sensitive information.
j. "Privacy" is the right of an individual to control the collection, storage and
dissemination of information about himself/herself to avoid the potential
for substantial harm, embarrassment, inconvenience or unfairness.
k. "Risk Analysis" is a means of measuring and assessing the relative
vulnerabilities and threats to a collection of sensitive data and the people,
systems and installations involved in storing and processing that data. Its
purpose is to determine how security measures can be effectively applied
to minimize potential loss. Risk analyses may vary from an informal,
quantitative review of a microcomputer installation to a formal, fully
quantified review of a major computer center.
I. "Sensitive Information" means information that requires protection due to
the risk and magnitude of loss or harm that could result from inadvertent
or deliberate disclosure, alteration or destruction of the information. For
the purposes of this program, information is categorized as being either
sensitive or not sensitive. Because sensitivity is a matter of degree,
certain sensitive information is further defined as being "highly" sensitive.
Highly Sensitive: This is information whose loss would seriously
affect the Agency's ability to function, threaten
the national security or jeopardize human life
and welfare. Specifically, information of this
type includes National Security Information, in-
formation critical to the performance of a pri-
mary Agency mission, information that is life
critical and financial information related to check
issuance, funds transfer and similar asset ac-
counting/control functions.
Other Sensitive: This is information whose loss would acutely
embarrass the Agency, subject the Agency to
litigation or impair the long-run ability of the
Agency to fulfill its mission. Information of this
A-7
-------
Information Security Manual 12/15/89
type includes Privacy Act information, Confi-
dential Business Information, enforcement con-
fidential information, information that the Free-
dom of Information Act exempts from disclo-
sure, budgetary data prior to release by OMB
and information of high value to the Agency or
a particular organization (see below).
The sensitivity if any, of all other information, shall be determined by the
organizational owner of the information. While a precise set of criteria for
determining the sensitivity of this other information cannot be provided,
the cost of replacing the information and the problems that would result
from doing without the information are primary factors to consider in de-
termining sensitivity.
m. "Sensitive Applications (or Systems)" are applications which process
highly sensitive or sensitive information or are applications that require
protection because of the loss or harm which could result from the
improper operation or deliberate manipulation of the application itself.
Automated decision-making applications are highly sensitive if the wrong
automated decision could cause serious loss.
8. PROCEDURES AND GUIDELINES. Standards, procedures and guidelines
for the Agency information security program will be identified and issued under
separate cover in the "Information Security Manual." This manual will identify and
reference, as appropriate existing procedures in the information security area, such
as the "Privacy Act Manual," the "National Security Information Security Handbook,"
and Confidential Business Information manuals like the TSCA Security Manual.
9. PENALTIES FOR UNAUTHORIZED DISCLOSURE OF INFORMATION.
a. EPA employees are subject to appropriate penalties if they knowingly,
willfully or negligently disclose sensitive information to unauthorized
persons. Penalties may include, but are not limited to, a letter of warning,
a letter of reprimand, suspension without pay, dismissal, loss or denial of
access to sensitive information (including National Security Information),
or other penalties in accordance with applicable law and Agency rules and
regulations, which can include criminal or civil penalties. Each case will
be handled on an individual basis with a full review of all the pertinent facts.
The severity of the security violation or the pattern of violation will
determine the action taken.
b. Nqn-EPA personnel who knowingly, willfully or negligently disclose sen-
sitive information to unauthorized persons will be subject to appropriate
laws and sanctions.
A-8
-------
Information Security Manual 12/15/89
APPENDIX B
APPLICATION RISK ANALYSIS
AND APPLICATION CERTIFICATION
A. The Certification Process
Owners should review Section 2.4 before proceeding with this Appendix. That
section contains information on combining applications for certification purposes.
Owners should also note that in working through this Appendix a qualitative risk
analysis is performed, that is, relative vulnerabilities and threats are assessed and
safeguards are specified.
1. New Applications
Each new sensitive application must undergo initial certification and then re-
certification every three years. This certification must take place prior to the appli-
cation being put into use or production. The certification or recertification will begin
with the application owner's completion of the Certification Worksheet, Exhibit B-1.
The worksheet and specific instructions for completing it are described in Section B.
For PC applications, the Certifying Official, PC site coordinator, and PC custodian
will be available to answer owner questions on an as needed basis. For minicom-
puter/mainframe applications, the Minicomputer/Mainframe Security Officer, the
Systems Analyst, and the Applications Programmer must not only answer questions
on an as needed basis, but they must also be an integral part of the process. The
determination of security requirements and appropriate controls requires communi-
cation among all these parties. Safeguards to meet the owner's sensitivity
requirements can be placed in the application itself and/or at the installation level.
How the application is ultimately protected depends upon the safeguards already in
place at the installation (and the results of the installation risk analysis) and the
particular threats to the application.
After completing the worksheet, the owner will forward it to his/her immediate
supervisor for review. The supervisor will review the worksheet for completeness
and then forward it to the designated Certifying Official.
The Certifying Official will either certify that the application is adequately safe-
B-1
-------
Information Security Manual
12/15/89
EXHIBIT B-1
CERTIFICATION WORKSHEET AND EXAMPLE
SENSITIVE APPLICATION CERTIFICATION WORKSHEET
1. APPLICATION TITLE
RCRA Settlement Offers
2. OWNER
ImaSafe
OSWER, OSW
3. TYPE(S) OF INFORMATION
Enforcement confidential;
high value
4. SENSITIVITY LEVEL & OBJECTIVE
Confidential: Medium Level
Availability: Medium Level
5. PROCESSING ENVIRONMENT
Standalone; non-removable and
removable media; shared user; Room 1123,
West Tower, Washington, D.C.
6. DESCRIPTION
Database application that tracks
settlement offers by case. All
users of PC may see confidential
data.
7. SECURITY SPECIFICATIONS/REQUIREMENTS
Controls to Maintain Availability
- Back-up database to diskettes in accordance with the procedures manual.
- Identify backup computing facility.
b. Controls to Maintain Integrity
(Minimal controls only)
Controls to Maintain Confidentiality
- Keep PC and removable media in a locked room.
- Establish a formal list of authorized users.
8. EVIDENCE OF ADEQUACY/DESIGN REVIEW
Check to make sure door took installed.
Check to see that formal list of authorized users created.
Are backups created by user?
Memorandum outlining agreement for backup facility.
9. TEST SCENARIO AND RESULT
Lock installed on 6-15-89.
List developed on 6-5-89.
Local backups kept in adjacent office; archival backup stored in Crystal City.
Memorandum with PC custodian in same branch executed 6-15-89.
10.
CERTIFIED
_NOT CERTIFIED
B-2
-------
Information Security Manual 12/15/89
guarded or deny certification by marking the appropriate box on the worksheet and
returning it to the supervisor. A Certifying Official may conclude that safeguards are
adequate if the application is protected in accordance with the procedures set forth
in Sections 6-9 of this manual. When certifying the application, the Certifying Official
must mark the appropriate box on the worksheet and sign the one-page certification
statement shown as Exhibit B-2. These documents must be retained on file for
inspection by OIRM, auditors, or the Office of the Inspector General.
Recertification of the operational application should be based on reviews or audits
that test and evaluate the adequacy of implemented safeguards and that identify any
new vulnerabilities. These reviews or audits should be considered part of vulnera-
bility assessments and internal control reviews conducted in accordance with OMB
Circular No. A-123.
2. Existing Applications
Each existing sensitive application must also undergo initial certification (and recer-
tification every three years) in accordance with the instructions above. However, to
avoid overwhelming organizations, initial certification may take place on a phased
basis over the next two years. All initial certifications of existing systems should be
complete by the end of 1991. More sensitive applications (as defined in Section 4)
and those for which security plans were prepared (as described in Section 2.6) need
to be certified first and as expeditiously as possible (by the end of 1990 at the latest).
Because of their overall organizational knowledge, SIRMOs may be able to quickly
prioritize applications for certification.
B. The Certification Worksheet
The certification worksheet should be completed by the application owner as follows.
The numbers below correspond to the numbered blocks on the worksheet. The
worksheet has been filled in with a PC application as an example of what is expected.
In instances where major applications have many security requirements, owners
may wish to reproduce the worksheet several times, using one copy for each
individual requirement.
1. Application Title: Provide the name of the information system or applica-
tion.
B-3
-------
Information Security Manual 12/15/89
EXHIBIT B-2
CERTIFICATION STATEMENT
I have carefully examined the information presented on the Certification Worksheet
for (application name} . dated . Based on my authority and judgement,
and weighing any remaining risks against operational requirements, I authorize con-
tinued operation of (application name) under the restrictions/conditions listed
below.
(List any Restrictions and Special Conditions 01 enter "None")
(Signature and Date)
B-4
-------
Information Security Manual 12/15/89
2. Owner: List the application owner and organization.
3. Type of Information: Indicate the type of sensitive information (for
example, CBI or high value) in terms of Section 4 of this manual.
4. Sensitivity Level and Objective: Provide the relevant security objective
(for example, availability) and the associated sensitivity level (for ex-
ample, high level).
5. Processing Environment: For PC applications, describe the processing
environment in terms of shared versus single user PC, removable versus
non-removable storage media, and standalone processing versus com-
municating with other equipment. Also indicate the physical and geo-
graphic location of the system. For other applications, describe the
processing hardware, the communications configuration, the user com-
munity, and the physical and geographic location of the system.
6. Description: Provide a brief functional description of the application.
7. (a)-(c). Security Specifications/Requirements: For PC applications, ex-
press the needed availability, integrity and/or confidentiality security
controls in terms of Section 7 of this manual. For other applications,
describe the needed availability, integrity, and/or confidentiality controls
in terms of Sections 6 and 9.
8. Evidence of Adequacy/Design Review: Indicate how the owner will
ensure the security specs are being implemented.
9. Test Scenario and Results: Describe how the owner will satisfy himself/
herself that the safeguards work orthatthe procedures are being followed.
10. Certifying blocks to be checked by the Certifying Officer as appropriate.
The application owner should note that the worksheet can also be used as a set of
security procedures for the application's users. In other words, the worksheet can
be used to communicatethe sensitivity of the application and the security procedures
to the user.
B-5
-------
Information Security Manual 12/15/89
APPENDIX C
INSTALLATION RISK ANALYSIS
A. Background
A risk analysis is a means of measuring and assessing the relative vulnerabilities and
threats to an installation. Its purpose is to determine how security safeguards can
be effectively applied to minimize potential loss. In everyday terms, risk analysis is
simply a procedure for identifying what could go wrong, how likely it is that things
could go wrong, and what can be done to prevent them from going wrong.
Risk analyses may vary from an informal, qualitative review of a microcomputer or
minicomputer installation to a formal, fully quantified review of a major computer
center. Forall Agency installations, including PCs and WP equipment, a qualitative
approach may be used (see part C below).
B. Applicability and Required Schedule
All Agency installations, including PCs and word processors, are required to undergo
a risk analysis. An installation risk analysis shall be performed:
Prior to the approval of design specifications for a new installation. In the
case of a PC or WP, the risk analysis shall be performed at the time the
equipment is installed.
Whenever a significant change occurs to the installation. ForaPCorWP
installation, significant changes include:
- Physically moving the equipment to another location
- Going from a single user to multiple users, or vice versa
- Altering the communication configuration, for example, adding a dial-
up capability or becoming part of a LAN.
For a minicomputer/mainframe installation, significant changes include,
but are not limited to:
- Adding new equipment that is not the same as existing equipment
- Adding new technology
C-1
-------
Information Security Manual 12/15/89
- Adding dial-up capability
It is difficult to specify a precise set of criteria for identifying significant
changes for mini/mainframe installations. At a large installation like NCC,
adding hardware is commonplace and changing network definitions is
also common; for the NCC, these do not constitute significant changes.
If more guidance is needed to determine if a change warrants a new risk
analysis, the Security Officer should consult his/her SIRMO.
At least every five years, if no significant change to the installation
necessitating an earlier analysis has occurred. Existing installations that
have not undergone a risk analysis dun ng the last five years must undergo
one by the end of 1990.
C. Risk Analysis: Qualitative Approach
To perform the qualitative risk analysis required by this manual, the Security Officer
or PC/WP custodian should complete the worksheet shown as Exhibit C-1 as
follows. The numbers below correspond to the numbered blocks on the worksheet.
The worksheet has been filled in for a hypothetical installation as a simple example
of what is expected.
1. Location: Provide the physical and geographic location and the organi-
zation for the equipment.
2. Custodian and Equipment Type: List the person to whom the equipment
is assigned and the type of equipment.
3. Type of Information: Indicate the type of sensitive information (for
example, CBI or high value) in terms of Section 4 of this manual. If the
Installation does not process any sensitive information, the risk analysis
is at an end and only the minimal controls set forth in Section 3 need to be
implemented.
4. Number of Sensitive Applications: Indicate the number of sensitive
applications processed at the installation.
5. Processing Environment: For a PC/WP, describe the processing envi-
ronment in terms of shared versus single user, removable versus non-
removable storage media, and standalone processing versus communi-
cating with other equipment. For other installations, describe the com-
munications environment, the users, the operating system, and installa-
tion hardware not described in 2 above.
6. Sensitivity Level and Objective: Provide the relevant security objective
(for example, availability) and the associated sensitivity level (for ex-
ample, high level).
C-2
-------
Information Security Manual
12/15/89
EXHIBIT C-1
INSTALLATION QUALITATIVE RISK ANALYSIS
WORKSHEET AND EXAMPLE
1. LOCATION
Room 1123, West Tower
OIRM
2. CUSTODIAN & EQUIPMENT TYPE
R.U. Secure
IBM 4381
3. TYPE(S) OF INFORMATION
Enforcement confidential;
high value
4.
NUMBER OF SENSITIVE
APPLICATIONS
5. PROCESSING ENVIRONMENT
Storage/communications capability
located at OIRM: users limited to OIRM
and other specifically authorized/trained
personnel; OEM operating system.
6. SENSITIVITY LEVEL & OBJECTIVE
Confidential: Medium Level
Availability: Medium Level
7. CONTROLS TO MAINTAIN AVAILABILITY
Disaster recovery/continuity of operations plan developed.
Uninterruptible power supply installed.
- List of personnel authorized to enter installation established.
Visitor log developed; all visitors escorted during visit.
8. CONTROLS TO PRESERVE INTEGRITY
See items 7 and 9.
9. CONTROLS TO PRESERVE CONFIDENTIALITY
Confidential hard-copy reports stored in a locked cabinet prior to distribution. Confidential
reports are delivered by hand in sealed envelopes.
Unneeded confidential reports are shredded and outdated magnetic tapes with confiden-
tial data are degaussed.
Physical access control and visitor control are as described in 7 above.
10. COMMENTS
The procedures for all sensitive install-
ations described in Section 6.4 have
been implemented, including those
related to password protection. RACF
implemented for sensitive applications.
11. MINIMAL CONTROLS IN PLACE?
x YES
NO
C-3
-------
Information Security Manual 12/15/89
7. Controls to Maintain Availability: Express the needed availability controls
in terms of Section 6,7, or 8 of this manual.
8. Controls to Preserve Integrity: Express the needed integrity controls in
terms of Section 6,7, or 8 of this manual.
9. Controls to Preserve Confidentiality: E
controls in terms of Section 6,7,or 8 of this manual.
10. Comments: Self-explanatory.
11. Minimal Controls in Place: Indicate whether or not the minimal physical
and environmental controls described in Section 3 are in place.
D. Risk Analysis: Quantitative Approach
In essence, a quantitative risk analysis is an exercise in cost/benefit analysis.
Specifically, it involves the following steps:
Identify the asset to be protected (equipment, application, data, etc.)
Determine the threats to the asset
- Natural, such as flood or earthquake
- Man-made, such as fraud or accidental error
Determine the probability the threat will be realized and the dollar loss (re-
placement cost, damages, etc.) if the threat is realized. Manipulate the
two numbers to obtain the annual loss expectancy (ALE).
Calculate the cost of security safeguards.
Compare the cost of safeguards with the ALE and implement those
controls that are cost-effective.
A simple example involving protecting a data base from fire follows:
Asset is data base with a replacement cost of $20,000
Threat is fire
Rate of occurrence of fire is once every 50 years
Annual probability of fire is 2%
C-4
-------
Information Security Manual 12/15/89
Annual Loss Expectancy is $400 (.02 x $20,000)
Cost of safeguard (fire extinguisher) is $100 with a life of 5 years, or $207
year
Obtain the fire extinguisher because it is cost-effective ($20 versus $400).
As the example shows, the concept of risk analysis is not difficult and is one the
Agency already uses in formulating regulatory policy. What is challenging about risk
analysis is identifying all the installation assets and threats and coming up with the
needed dollar figures. Once these activities have been performed for the first
analysis, however, subsequent risk analyses for the installation should be less time-
consuming.
There are several different approaches for developing the numbers needed for a
quantitative analysis. The procedures presented here are based in large part on
Federal Information Processing Standard (FIPS) 65, entitled "Guideline for Auto-
matic Data Processing Risk Analysis." Additional analytical concepts presented
here are based on information in the HUD "ADP Security Procedures" handbook,
the GSA "Automated Information Security" handbook, and the USDA "ADP Security
Manual".
The approach outlined here should provide a reasonably accurate risk assessment,
but other quantitative approaches may also provide accurate results. Security
Officers may use alternative approaches if: (1) the approach includes the basic
steps outlined at the beginning of this part, and (2) the approach yields all the
information required for the risk analysis report (described in Step 5).
1. Step 1: Identify Assets and Determine Threats
Any risk analysis must begin with an inventory of installation assets. The essential
first question is: "What potentially requires protection?" Basic categories of assets
are as follows:
Building (furnishings, detection systems, etc.)
Supplies
Hardware
Communication Systems (equipment and service)
C-5
-------
Information Security Manual 12/15/89
Environmental "Systems" (power, air conditioning, etc.)
Software (operating system and application)
Data (source documents, output, files, data bases)
Documentation and Procedures.
The threats to those assets must then be determined. To assist in this process,
Exhibit C-2 has been developed. Exhibit C-2 is a simple matrix which presents
assets by threats. To use the worksheet, put a check in each relevant square or
matrix cell. For example, fire isathreatto hardware. Note that the threats have been
tied to the three security objectives of availability, integrity, and confidentiality.
2. Step 2: Identify Existing Safeguards
The next step is to list all security safeguards that are currently in place. Each
safeguard also needs to be tied to the asset it is protecting and to the threat it is
counteracting. In other words, in terms of the Exhibit C-2 matrix, each safeguard
should be tied to one or more squares or cells.
It is important to identify existing safeguards early, since additional controls can only
be meaningfully selected in light of the existing security baseline. In addition, to the
extent that threat/asset combinations are without corresponding safeguards, vul-
nerabilities are present. For example, if fire is a threat to hardware and there are no
fire protection controls in place, the installation is vulnerable to fire.
3. Step 3: Calculate Annual Loss Expectancies
This step involves determining the annual loss expectancy (ALE) of each checked
matrix cell. This calculation involves two components:
Determining the probability the threat will be realized (or the frequency of
occurrence)
Determining the dollar loss if the threat is realized (the dollar impact of the
occurrence)
Note that the frequency of occurrence implicitly incorporates how applicable the
C-6
-------
Information Security Manual
12/15/89
Installation:
THREAT
Availability:
Fire
Water
Storms
Earthquakes
Environ. System
Failures
Equip./System
Failure
Theft
Accidental Data
Destruction
Sabotage
Confidentiality:
Unauthorized
Disclosure
Integrity:
Fraud
Sabotage
Accidental
Damage
EXHIBIT C-2
ASSET/THREAT WORKSHEET
Prepared by:
Date:
Assets
Hard- Comm. Environ.
Bldg. Sup. ware Systems Systems
Soft-
ware Data Doc.
C-7
-------
Information Security Manual 12/15/89
threat is. For example, if a threat is not relevant to an asset, the frequency of
occurrence is zero.
To simplify the analysis without reducing its usefulness, the impact and frequency
estimates should be rounded to the factors of 10 shown below. This is the approach
recommended in FIPS 65.
Impact:
$ 10
$ 100
$ 1,000
$ 10,000
$ 100,000
$ 1,000,000
$ 10,000,000
$ 100,000,000
Frequency:
100 times a day
10 times a day
1 time a day
Once in 10 days
Oncejn 100 days
Once in 3 years (1000 days)
Once in 30 years
Once in 300 years
This kind of rounding is possible because it really makes little difference to the overall
analysis if a threat is realized every 20 years or every 30 years. Similarly, the
analysis is not significantly affected by an estimated dollar loss of $80,000 versus
$125,000.
Impact and frequency estimates can be developed through interviews with Agency
operational and technical experts. In many instances, common sense will be of great
help. For example, in estimating the frequency of a wind storm, once in three years
is probably too often and once in 300 years is probably too long. A more reasonable
C-8
-------
Information Security Manual 12/15/89
estimate may be once in 30 years. Similarly, in assigning a dollar impact to fraud
involving the payroll system, $1,000,000 is probably too much while $10,000 is too
little. $100,000 is probably a reasonable estimate.
Oftentimes, impact and frequency estimates are more readily developed for physical
or facility-related assets such as buildings or hardware. Estimates for assets such
as data or documentation can involve more judgment, making the risk analysis
conclusions for such assets less certain.
The ALE of a particular asset/threat combination is the product of the annualized fre-
quency and impact estimates. To simplify the computation, Exhibit C-3 has been
developed. Exhibit C-3 presents ALEs by impact/frequency combinations. For
further convenience in performing the analysis, Exhibit C-4 has been developed.
Like Exhibit C-2, Exhibit C-4 is a simple matrix which presents assets by threats. The
cells in Exhibit C-4 should be filled not with checkmarks, however, but with ALEs. In
other words for each checkmark in Exhibit C-2, there should be a corresponding ALE
in Exhibit C-4.
In developing ALEs, two final items should be noted. First, in developing these
estimates, do not factor in the effect of existing safeguards. For example, an existing
fire detection system could reduce the dollar loss in the event of a fire, but to include
that reduction here would muddy the analysis because it would assume the cost-
effectiveness of the existing system. Instead, all ALEs should be developed as if
there were no existing security controls. (The cost-effectiveness of existing safe-
guards is factored in later in the analysis.)
The second item to note is that in many instances it may be useful to make several
copies of both Exhibits C-2 and C-4 and to create new asset headings on those
copies. For example, Exhibit C-2 includes the assets "software" and "data." Within
each of these categories, there may be several different data bases and applications,
each with its own unique set of threats. In determining threats for applications and
collections of information, always consult with the owner to find out the sensitivity
designation and the relevant security objectives.
4. Step 4: Evaluate and Select Safeguards
To begin this final analytical step, identify the types of safeguards needed based on
C-9
-------
Information Security Manual 12/15/89
EXHIBIT C-3
ALE by IMPACT/FREQUENCY COMBINATION
FREQUENCY
1 in 1 in 1 in 1 in 1 in 1 in 10 100
300 30 3 100 10 1 Per Per
IMPACT Years Years Years Days Days Day Day Day
$10 $300 $3K $30K $300K
$100 $300 3K 30K 300K 3M 30M
$1,000 $300 3K 30K 300K 3M 30M
$10,000 $300 3K 30K 300K 3M 30M
$100,000 $300 3K 30K 300K 3M 30M 300M
$1,000,000 3K 30K 300K 3M 30M 3COM
$10,000,000 30K 300K 3M 30M 300M
$100,000,000 300K 3M 30M 300M
Source: PIPS 65
C-10
-------
Information Security Manual
12/15/89
EXHIBIT C-4
CALCULATING EXPECTED LOSS ALE WORKSHEET
Installation:
THREAT
Availability:
Fire
Water
Storms
Earthquakes
Environ. System
Failures
Equip./System
Failure
Theft
Accidental Data
Destruction
Sabotage
Confidentiality:
Unauthorized
Disclosure
Integrity:
Fraud
Sabotage
Accidental
Damage
Total
Prepared by:
Date:
Assets
Hard- Comm. Environ.
Bldg. Sup. ware Systems Systems
Soft-
ware Data Doc.
C-11
-------
Information Security Manual 12/15/89
the procedural guidance in Section 6. This is now the appropriate point to include
existing safeguards, so make sure to factor those in to this process.
Once the safeguards have been identified, estimate their annual costs. Again, a high
degree of precision is unnecessary. For example, if a physical access control
system has a cost of $50,000 and a useful life of about 5 years, use $10,000 as the
annual cost. Remember, however, that the cost of an existing control is only the
annual maintenance cost and does not include the initial installation costs. Those
initial costs have already been expended.
Construct alternative clusters of safeguards that address the threats to the installa-
tion's assets. Compute the costs, benefits, and overall cost-effectiveness of each
set of safeguards as shown in Exhibit C-5.
Remember that most security measures are effective against more than one threat
and will reduce the ALE of several different asset/threat combinations. Indeed, it is
this characteristic that makes administrative and physical safeguards so cost-
effective.
Experiment with various combinations of safeguards until a satisfactory aggregation
is achieved. A satisfactory aggregation is one that: (1) addresses all important
threats, (2) results in a significant reduction in the ALE, (3) creates overall benefits
that are greater than costs, and (4) is affordable for the organization. A satisfactory
aggregation need not drive the ALE to 0. Indeed, at an ALE of 0, it is possible that
safeguard costs will exceed their benefits.
5. Step 5: Prepare A Report
Complete the risk assessment process by documenting the results. There is no
standard length required. The report could be 10 pages long or 200 pages long,
depending on the size and sensitivity of the installation. The report should include
the following sections:
Summary of Findings and Recommendations
Introduction
C-12
-------
Information Security Manual 12/15/89
EXHIBIT C-5
COSTS AND BENEFITS OF SAFEGUARDS
(1) ALE Now
(2) New ALE with
Safeguards
(3) Benefits ((1)-(2))
(4) Safeguard Costs
(5) Cost-Effectiveness
(0) - (4))
Safeguard Safeguard Safeguard
Set 1 Set 2 Set 3
C-13
-------
Information Security Manual 12/15/89
Description of Existing Security Controls
Discussion of Asset/Threat Combinations and the Overall Risk Profile of
the Installation
Findings and Recommendations
V.
Appendix Containing the Risk Analysis Worksheets.
C-14
-------
Information Security Manual 12/15/89
APPENDIX D
DISASTER RECOVERY AND CONTINUITY OF
OPERATIONS PLANNING
A. GENERAL
A disaster recovery and continuity of operations plan is required for each minicom-
puter/mainframe computer processing installation. Preparation of the plan is the
responsibility of the installation's Security Officer. The Security Officer may delegate
portions of this function to other knowledgeable individuals as long as the coordinat-
ing responsibility is retained.
These plans cover three distinct areas:
Emergency Response Procedures: These are the actions taken during
or immediately after an emergency to protect life and property and to
minimize the impact of the emergency.
Backup: This area involves two components: (1) establishing a routine
schedule for backing up programs and data, and (2) determining where
those programs and data would run in the event of an emergency. Taken
together, the two backup components ensure the continuity of installation
operations.
Recovery: While the backup area focuses on establishing an alternative,
temporary processing capability, the recovery area focuses on restoring
a permanent, ongoing capability.
Clearly, disaster recovery plans are crucial for ensuring the continued availability of
applications identified by owners as being critical or high value Agency applications.
To the extent an installation does not process applications of this type, contingency
planning is less important. Consequently, installations that only process applica-
tions involving confidentiality and integrity should focus primarily on emergency
response and recovery; continuity of operations is relatively unimportant for these
installations and may be omitted from their plans.
Each installation should prepare a plan in accordance with these procedures by the
end of 1990. Plans should then by updated on an annual basis. Forward completed
plans or updates to your organization's SIRMO.
D-1
-------
Information Security Manual 12/15/89
B. STEPS TO DEVELOP THE PLAN
1. Step 1: Determine What Constitutes a Disaster
An emergency can vary from a temporary disruption of processing to the complete
destruction of the installation. Determine what kinds of events will cause: (1)
limited, temporary disruption, (2) major, serious disruption, and (3) catastrophic
disruption. If the Asset Threat Worksheets were developed as part of the risk
analysis, they can assist in this determination.
2. Step 2: Develop Emergency Procedures
Define and describe what needs to happen during and immediately after an emer-
gency by developing procedures for:
Notifying personnel of the emergency
Responding to fire and other acts of nature
Evacuating the installation
Shutting the hardware down
Protecting data and records.
These procedures must be written and must identify who will be responsible for what
function during the emergency. All installation employees should have an assigned
function during an emergency, which may be simply to evacuate the installation
immediately and to remain home until called.
The procedures should be accompanied by an installation floor plan that shows the
location of fire extinguishers, plastic for covering equipment, and other items useful
in responding to the emergency.
3. Step 3: Ensure Continuity of Operations
Based on owner sensitivity designations, develop a listing of critical and high-value
applications. Establish a plan for data and software backup that includes frequency
of backup, a retention schedule, and an off-site location for storage. The plan should
recognize that transactions that have occurred since the last data backup maybe lost
and may need to be re-input. Make sure the plan is responsive to any special owner
D-2
-------
Information Security Manual 12/15/89
requirements, such as more frequent backup than is typical.
Locate and execute an agreement for an alternative processing site to be used in the
event of major or catastrophic damage. Because of cost and compatibility consid-
erations, it is probably best to be backed-up by another installation at the EPA, for
example, one Prime location backing-up another or WIC and NCC backing each
other up. NCC can also back-up regional logical mainframe facilities and will
consider backup arrangements for VAX and microVAX.
Make sure the agreement is in writing and spells out such key items as the amount
of processing capability to be made available, the associated cost, and the extra
supplies like blank tapes to be maintained at the backup site.
4. Step 4: Plan for Recovery
Develop a plan for re-establishing a permanent, on-going processing installation.
Identify a new installation location in the event the old site cannot be rebuilt.
Determine how hardware supplies and other needed items will be obtained.
Determine how applications will be migrated back to the original processing
installation or to the new installation.
5. Step 5: Testing and Training
Test the plan. For example, confirm compatibility with the backup processing in-
stallation by actually running a critical application there.
Train personnel in their emergency responsibilities.
6. Step 6: Prepare a Written Plan
Complete the process by documenting the plan. The report should include the
following sections:
Introduction
Definition of Disaster for the Installation
Description of Emergency Procedures
Strategy for Ensuring Continuity of Operations (not required for installa-
tions with only confidentiality and/or integrity as objectives)
D-3
-------
Information Security Manual 12/15/89
Plan for Recovery
Testing Procedures
Training Plan
Appendix Containing a Listing of Critical and High Value Applications at
Installation.
D-4
------- |