OSWER Dir.
logical structure and accompanying definition* in thie Appendix.
Printed on Recycled Paper
-------
OSWER Dir. //9028.00c
- 2 -
The Application Security Management Practice Paper
implements Agency-wide security policies regarding the
availability, integrity, and confidentiality of OSWER systems.
It lays out security objectives, key decisions, activities and
products for each life cycle phase or stage. It also contains a
glossary of computer security terminology, a comprehensive
reference to related documents and lists of typical threats,
vulnerabilities and security measures.
If you have any questions concerning the System Life Cycle
Management Guidance or the two new Practice Papers which will be
added to Part 3 of the Guidance, call me at 202-260-6760.
Attachments
Addressees;
OSWER Office Directors
Regional Waste Management Division Directors
OSWER Information Management Coordinators
OIRM Office Director
OIRM Division Directors
National Data Processing Division Director
Regional IRM Branch Chiefs
-------
?/EPA
Unites Slates -': rcnmeniai .--ejection
b. Ooes It Supplement Previous Directive(s)?
Yes What directive (number, title)
n
No
x j Yes What directive (number, tftle) go?8 00
OSWER'S System Li'fe Cycle Mgmt'. Guld/"
Level',.,;- l:..-.- '.
A - Signed by,AA/d'AA' {
.-_; | 3-- Signed by Office Director
C - ror Review & Comment
8.
Document
to
be
distributed
to
States
by
Headquarters? ! lYes
jr
No
This Request Meets OSWER Directives System Format Standards.
9. Signature of Lead Office Directives Coordinator
Date
10. Name and Title/oTAppro1
f/L;
I Asi^i
(Date
EPA Form 1315-17. (Rev. 5-87) Previous edi^pns are obsolete.
OSWER OSWER - OSWER
., ""let *"' *-j*>ta^ '-.'-n«*
DIRECTIVE DIRECTIVE^1:'
i -.
W.
Q
-------
OSWER DIRECTIVE #9028.00c
OFFICE OF SOLID WASTE
AND EMERGENCY RESPONSE
(OSWER)
rSYSTEM
LIFE
SYSTEM LIFE CYCLE
MANAGEMENT GUIDANCE
Part 3: Practice Paper
Data Modeling Practice Paper
May 1992
-------
OSWER Directive #9028.00c
TABLE OF CONTENTS
1. INTRODUCTION 1
1.1. Purpose 1
1.2. Scope 1
2. DATA MODELS 3
2.1. WHAT ARE DATA MODELS? 3
2.1.1. What are Conceptual and Logical Data Models? 5
2.1.2. What are the Benefits of a Data Model? 5
2.1.3. What are the Components of a Data Model?..... . 6
2.2. What are Data Entity Relationship Diagrams? 7
2.2.1. How Do You Read an ERD? ......7
2.2.2. What is the Purpose of an ERD? 10
3. DATA ENTITIES 13
3.1. CREATING DATA ENTITIES 13
3.1.1. What is a Data Entity? . 13
3.1.2. How Do You Distinguish Between Data Entities and Data Elements?. 14
3.1.3. How Does One Gauge the Scope of Analysis? 15
3.1.4. What are Sources for Identifying Data Entities? 18
3.1.5. Does System Life Cycle Phase Dictate Which Entities to Create?. 20
3.1.6. What are Data Entity Homonyms and Synonyms? 24
3.1.7. What are Natural Data Entity Identifiers? 25
3.1.8. What is Data Entity Subtyping? 26
3.2. NAMING DATA ENTITIES ~ 26
33. DESCRIBING DATA ENTITIES 27
4. DATA RELATIONSHIPS 31
4.1. CREATING RELATIONSHIPS BETWEEN DATA ENTITIES 31
4.1.1. What are Data Relationships? 31
4.1.2. Can There be More Than One Relationship Between Data Entities? ...32
4.1.3. When Should Zero Cardinality be Used? 33
4.1.4. Is it Permissible to Have Redundant Relationships? 33
Data Modeling Practice Paper
-------
OSWER Directive #9028.OOc
4.1.5. What are Recursive Relationships? 34
4.2. NAMING DATA ENTITY RELATIONSHIPS 34
4.3. DESCRIBING DATA ENTITY RELATIONSHIPS ....35
5. DATA ELEMENTS 37
5.1. CREATING DATA ELEMENTS 37
5.1.1. What are Data Elements? 37
5.1.2. What are "Normalized" Data Models? 37
5.1.3. What are Primary and Foreign Key Identifiers? 41
5.2. NAMING DATA ELEMENTS 42
5.2.1. Does a Data Element Only Have One Name? 42
5.2.2. How Do You Construct the Data Element Full Name? 43
5.2.3. How are Abbreviated Data Element Names Created? 45
5.3. DESCRIBING DATA ELEMENTS . 46
6. CHANGING THE MODELS 49
7. CONCLUSION 51
7.1. When is the model "right"? 51
7.2. "Manage" issues 51
7.3. Presenting a Data Model 51
7.4. Data Modeling Expertise , 52
APPENDIX A: DATA ENTITY PROPERTIES
APPENDIX B: DATA RELATIONSHIP PROPERTIES
APPENDIX D: DATA MODELING QUICK REFERENCE
APPENDIX E: GLOSSARY
APPENDIX F: OSWER-WIDE CONCEPTUAL DATA MODEL
II . Data Modeling Practice Paper
-------
OSWER Directive #902S.OOc
LIST OF FIGURES
Figure 1. The House Constructior Analogy 4
Figure 2. Difference Between Conceptual and Logical Data Model 8
Figure 3. Conceptual ERD Example ..9
Figure 4. Anticipated CRUD Actions of Business Function on Data Entity 17
Figure 5. Example Data Flow Diagram of Inventory Management Function ...19
Figure 6. Progression of Data Modeling During the SLC 21
Figure 7. Logical ERD Example ; 23
Figure 8: List of Properties for Defining Data Entities 28
Figure 9. Data Entity Property Completion Matrix 29
Figure 10. Example of Data Entity Relationship 31
Figure 11. Example of Multiple Data Entity Relationships 32
Figure 12. Examples of Recursive Data Entity Relationships ..34
Figure 13. List of Properties for Defining Data Relationships 36
Figure 14. Logical ERD Example with Data Elements 38
Figure 15. Examples of Non-normalized Data Entities 40
Figure 16. Primary and Foreign Keys .42
Figure 17. Data Element Class Words 44
Figure 18. List of Properties for Defining Data Elements. 46
Figure 19. Data Element Property Completion Matrix .....,. 48
Figure 20. Entity Relationship Components B-2
Figure 21. RCRA Data Model F-3
Figure 22. CERCLA Data Model : F-4
Data Modeling Practice Pfper 111
-------
This page intentionally left blank
-------
OSWER Directive #9028.OOc
1. INTRODUCTION
1.1. PURPOSE
This paper defines the OSWER standards for developing a logical data model
during the System Life Cycle (SLC). This material is intended for business analysts
and systems analysts who will be defining data requirements during the early stages
of the SLC, primarily during the Concept Phase and Definition Stage. Other
relevant data standards are provided by the Office of Information Resources
Management (OIRM) and by outside agencies, such as the National Institute of
Standards and Technology (NIST).
Most papers on this subject tend to describe the products of data modeling, but
do not offer much about how to go about doing it. While this paper is not a
replacement for instructor led training, it does provide guidance throughout the
paper.
It is important to understand that like most subject matters of a technical
nature, data modeling is not learned by book alone. Experience in this subject is the
only way to acquire technical proficiency and to appreciate some of the more subtle
aspects of data modeling.
This paper offers three basic aspects to the subject matter. This paper (1)
introduces data modeling techniques; (2) defines specific data standards for logical
data modeling to follow during the SLC; and (3) offers some "how to" guidance
throughout the data modeling process.
1.2. SCOPE
The topics included in this paper are:
» Data Models: Describes the components of data models, data entities,
data relationships, and data elements; and introduces Entity
Relationship Diagrams, the primary graphic tool for illustrating data
models.
** Data Entities: Describes what data entities are, when to include them in
a data model; how to name data entities; and how to describe them in
the data model.
** Data Relationships: Describes what data relationships are; when to
include them in a data model; how to name data relationships; and
how to describe them in the data model.
Data Modeling Practice Paper
-------
OSWEK Directive #902S.OOc
« Data Elements: Describes what data elements are; when to include
them in a data model; how to name data elements; and how to describe
them in the data model.
This paper also contains several appendices. Appendix A defines the
standards for describing data entities. Each property used to describe a data entity is
described in detail. Similarly, Appendix B defines the standards for describing data
relationships. Appendix C defines the standards for describing data elements.
Appendix D contains a quick reference of data modeling guidelines, which is a brief
excerpt of ideas from this paper. Appendix F contains a version of the OSWER-wide
Data Model.
Data Madding Practice Paper
-------
OSWER Directive #9028.00c
2. DATA MODELS
2.1. WHAT ARE DATA MODELS?
Before answering the question, What are data models?, we should first be
sure we have a common definition for model, Webster defines model as "a small
object, usually built to scale, that represents another, often larger object" or "a
preliminary pattern serving as the plan from which an item not yet constructed will
be produced". Aha! Models are not just smaller versions of the real thing, they are
the architectural plans for building the real thing.
To better understand what a data model is, we can use a common analogy
between data modeling and designing buildings. Think of a data modeler as
analogous to the architect in Figure 1 who must design a building. The building
itself represents a physical data base. Before construction on the building can be
started, the architect must talk to the buyer to find out what kind of a building the
buyer wants, such as whether it will be a factory, warehouse, office building, or
private home. Likewise, the data modeler must talk to the users of the information
to scope out what kind of information is needed and roughly how big it will be. To
do this the modeler builds a conceptual data model.
Once high-level drawings are finished, the architect must add enough detail
to capture all of the requirements of the client requesting the house. For this to
happen, the architect needs to create detailed blueprints of all of the rooms of the
building. This new diagram contains information sufficient for communicating
with system designers and developers. Similarly in data modeling, we create a
logical data model. This model will have all of the specifications needed by the
client, such as the data elements and their formats, and the relationships between
groups of data elements. This detailed data model is used to communicate with
database designers.
The design of the building is adjusted to accommodate the unique
construction technologies that are being used (such as the electrical wiring and
heating, AC, and ventilation). In data modeling this step is analogous to the
transformation from a logical data model to a physical data base design. Thus
database designers need their own model to work with - a model with sufficient
detail needed to build the database.
Lastly, construction of the building results in the building itself and is where
the people will reside. Similarly, once the physical data base design is complete,
construction can begin to create the actual data base where the data will reside.
Thus a data model is simply an architectural plan for data of some predefined
scope. Sometimes the scope of a data model is for a single system, but data planning
Data Modeling Practice Baper
-------
OSWER Directive #9028.00c
can also be done for selected areas of the business or even at the enterprise-wide
(organizational) level.
Returning to our analogy, when designing a building, the architect does not
design a building in a vacuum. The architect must consider existing landscaping,
zoning regulations, and the types of buildings are already in the neighborhood. In
our analogy, the architect plays the role of "city planner" by providing different types
of structures to serve specific needs. If a hotel is on the plot next door, it probably
does not make sense to build another one next to it (assuming the capacity of the
first was not exceeded). Perhaps it would make more sense to construct a restaurant
or a municipal garage on the adjacent plot.
Likewise it behooves the data modeler to consider the data that already exists
in "adjacent" systems, i.e., the systems and databases already available to the users.
The best solution to satisfying users' needs isn't necessarily designing and building
yet another database of information already contained elsewhere - a better solution
might be to utilize the information already provided and build on that base to
accommodate the expanding informational needs of users.
Figure 1. The House Construction Analogy
Jj
An archfcect MentMee what
tha buyer wants butt
(Conceptual Data Modeling)
ROOT plans and sketches ar»
to reflect buyer's requirements
(Logical Data Mooting)
Plane ara agreed upon prior to
ctual
tructio
(Data Modal Confirmation)
Plant ara updated to include wMng,
plumbing, hwitafen. ate.
(Physical Database Design)
Construction begins
(Databaaa Implementation)
CompMad houaa la daBvarad
(Completed Database)
Data Modeling Practice Paper
-------
OSWER Directive #9028.OOc
2.1.1. What are Conceptual and Logical Data Models?
A data model can also be developed at varying degrees of detail, depending
upon the phase of the SLC. For instance, in the Concept Phase of the SLC, the data
model is usually referred to as a conceptual data model', in the Definition Stage, it is
most often called a logical data model. Note that the term logical does not mean
"rational"; logical here is an industry term implying technology independence, as is
the architects first blue-prints.
So what's the difference between the models in the Concept Phase and
Definition Stage, the conceptual and logical data models? The difference is the
amount of detail within each. Conceptual data models are used early in the SLC for
scoping out the data that a project will be working with. Data are referenced at a
high-level of analysis, primarily because in the early stages there may not be much
known about the specific data elements to be included. Conceptual data models are
also useful for presentation purposes due to their simplicity.
Whereas conceptual data models usually remain at the data entity level,
logical data models decompose the data entities into the data element level. Data
elements are the smallest items of data that are considered meaningful. Examples of
data elements are employee social security number, contract approval date, and site
identification number. A typical organization can have thousands of data elements
within its information systems. Data elements are characteristics of a data entity,
such as the data element employee social security number is a characteristic of the
entity employee. In a conceptual model, these data elements are assumed and not
explicitly documented. As the next chapter on Data Entities will indicate, each data
entity is a logical grouping of data elements.
It should be understood that neither of these models represent data as; it
would be physically stored in a system or on a hard disk drive. Data from the logical
model is further refined into a physical data model, called a physical data base
design, which is prepared as part of the Design Stage of the SLC.
2.1.2. What are the Benefits of a Data Model?
While the transition from a logical data model to a physical data design is
beyond the scope of this paper, the logical data model provides important
information for physical data base design. The purpose of logical data modeling is
to ensure that the resulting data base(s):
"Contain the appropriate information to support the business
functions and processes; have a flexible structure for current and future
needs: provide maximum availability of data, data integrity, security.
and recovery; provide access paths to support transaction processing,
Data Modeling Practice Paper
-------
J * _ -
OSWER Directive *9028.00c
batch processing, and ad hoc queries; and provide timely execution of
database maintenance utilities."1
Another benefit is that data models provide a structured tool for
communicating business requirements between systems people and business people
during the early phases of the SLC. It is during these early phases that a project team
identifies most of the business needs for a future system. When a project team
identifies data requirements later in the SLC, it is generally much more expensive
since more change to the design and possibly to the actual system will be required.
Like the architect who presents sketches and floor plans to the buyer, system
developers can use data models directly with the users to ensure that all business
requirements are designed into the early stages of the SLC.
Data models are also used to communicate data requirements across system
development efforts. This information becomes crucial when one system is
providing data that another system needs. The data model provides the definition
of data in a structured and consistent way for each system project. Thus system
developers can better exploit data sharing opportunities across OSWER operational
systems. For more information on Data Management practices refer to the Practice
Paper for Data Management During the System Life Cycle.
2.13. What are the Components of a Data Model?
Data models contain four main components:
Data Entities are anything that an organization collects, processes,
and/or reports information about. For example, Site, Chemical
Substance, and Spill are all data entities. While the determination of
an organization's data entities can be a subjective, process, it is not
entirely arbitrary. Chapter 3, Data Entities, describes entities in greater
detail.
Data Entity Relationships are the valid associations between data
entities, and are ultimately translated into the access paths that are
required in order to retrieve data from a data base. The relationships
reflect the real world business rules as they exist for a particular
organization, such as OSWER. For instance, a Spill Occurs At a Site,
and a Chemical Substance Is Found In a Spill. Chapter 4, Data Entity
Relationships, describes data relationships in greater detail.
1Courtesy of DB2 Date Base Design and Administration Course Handout by Data
Base Management Inc. (DBMI)
Data Modeling Practice Paper
-------
OSWER Directive #902S.OOc
Data Elements are the smallest meaningful items of data. Data
elements are characteristics of data entities. Thus each data entity in a
logical data model is comprised of a set of data elements. As the
chapter on Data Elements will indicate, there are specific guidelines for
identifying data elements - such as a data element describes one and
only one data entity, or in other words, two data entities can not
contain the same data element. Chapter 5, Data Elements, describes
them in greater detail.
Data Entity Relationship Diagrams (ERD) are graphical depictions of
two of the three components of a data model: data entities and data
entity relationships. Data elements are not shown on an ERD. The
ERD can be used to represent the data in a system at both the
conceptual and the logical levels of detail.
Figure 2 summarizes the difference between the conceptual and logical data
model. Note that one of the key differences between the two models is based on a
technique called data normalization, which is applied to the logical data model.
Data normalization is a process by which the model is simplified to make each data
element in the model dependent on (i.e., determined by) the unique identifier of a
single entity. This simplification of the model actually results in many more data
entities to be defined. Data normalization is described further in Chapter 5, Data
Elements.
2J2. WHAT ARE DATA ENTITY RELATIONSHIP DIAGRAMS?
As we have already said, the ERD is an essential part of the data model. It
depicts the data requirements in a graphical form. This allows for a significant
amount of information to be documented and maintained in a fairly simple
structure. In fact, one ERD replaces the need for writing what can amount to an
entire book of requirements, and a book that would be nearly impossible to
understand.
24.1. How Do You Read an ERD?
The best way to understand an ERD is to examine one. Figure 3 depicts an
example conceptual ERD for an organization. Each box represents a data entity. For
example, EPA Organization, Contractor, and Site are all data entities. Each data
entity represents all of the possible occurrences of the data entity. For example, EPA
Organization represents many occurrences, such as OGC, OIG, OPFE, OECM, OARM,
ORD, OIA, OPTS, OAR, OW, OSWER, and many others.
Data Modeling Practice-Paper
-------
OSWER Directive #9028.00c
Figure 2. Difference Between Conceptual and Logical Data Model
Data Model
Conceptual
Data Model
Logical Data
Model
Data Model Component
Data Entity
/
High-level data
entities, not
usually
normalized
S
Normalized
data entities -
results in many
more entities
than in
Conceptual
model
Data
Relationship
/
All pertinent
relationships
should be
identified
V
Normalized
data entities -
results in many
more
relationships
than in
Conceptual
model
Entity
Relationship
Diagram
/
A diagram
should be
developed
/
A diagram
should be
developed
Data Element
None usually,
except entity
identifiers
/
All business-
oriented data
elements
should be
defined; system
specific data
elements are
defined in
design stage
Relationships are the connections between the boxes, for example, EPA
Organization Oversees Cleanup Contract is a relationship between EPA
Organization and Cleanup Contract. Every relationship has a reverse relationship
as well. In the example, Cleanup Contract is Overseen by EPA Organization.
An easy way to read the relationship names on the diagram is to read the
entity and relationship names in a clockwise fashion. For example, the name of the
relationship corresponding to the top-to-bottom entities on the diagram appears to
the right of the relationship line (and the reverse relationship name appears on the
left). The relationship name corresponding to the left-to-right entities on the
diagram appears above the relationship line (and the reverse relationship name
appears below).
8
Data Modeling Practice Paper
-------
OSWER Directive #9028.OQc
Figure 3. Conceptual ERD Example
PA
Overseen
Sit*
Oversees
Occurs at
Location of
Ctamup
Contraot
Provides for
Provided by
Aouvily
Counter-
measure for
Spill
Agrees to
Agreement
with
Counter-
measured by t
Sourcedat
Source of
Spill Samplo
T
Contained in
Contains
O
A
Sutetane*
The ERD contains more information about relationships than simply the fact
that a relationship exists. Each relationship contains information about the
minimum and maximum occurrences allowed (cardinality) of related entities to a
given occurrence of an entity. In the diagram the "chicken feet" symbol on the
relationship should be read as "more than one"; the small straight line means;
"one"; and the circle means "zero". The minimum occurrence cardinalities are the
inner symbols, and the maximum cardinalities are the outer symbols. For example,
to completely interpret the relationship between EPA Organization and Cleanup
Contract, we should read the relationship as follows:
Data Madding Practice Paper
-------
OS WE* Directive #9023.QQc
An EPA Organization Oversees a Minimum of Zero Cleanup Contracts
AND
An EPA Organization Oversees a Maximum of More than One Cleanup Contracts
In addition, the same relationship has information about the reverse
relationship, that is how Cleanup Contract relates to EPA Organization:
A Cleanup Contract is Overseen by a Minimum of One EPA Organization
AND
A Cleanup Contract is Overseen by a Maximum of One EPA Organization
Why is all this important? Actually it is critically important, because the ERD
depicts essential information about the valid business rules. The data model
contains the business rules to ensure that future system(s) contain appropriate and
valid data relationships. The relationships between entities provide access
paths to data that will be provided in the physical data base. In a physical data base,
these access paths are sometimes implemented using primary and foreign key
identifiers (depending upon the data base management system). Primary and
foreign keys are discussed in more detail in Chapter 5, Data Elements.
2.2,2. What is the Purpose of an ERD?
An Entity Relationship Diagram (ERD) serves several purposes. An ERD is
an effective communication tool. Since an ERD dearly illustrates the major data
requirements and business rules, it can be used effectively with users (and
developed with users) to ensure that all data requirements are identified and are
identified accurately.
ERDs are also used amongst project team members to ensure that data
requirements are consistent across different parts of a system. When a project team
performs process modeling (the complement to data modeling which examines
business processes), etch process analyzed is documented with data inputs and
outputs. These data inputs and outputs should be components of the data model.
Thus it will be critically important to ensure that the data used by a particular
process has been created by another process, and to ensure that the data identified for
the process is the same data as that in the data model
The ERD can be used across project teams to communicate the scope and
nature of the data within a particular system or functional area of a business.
Communication of data requirements across teams is critical when two or more
systems will be required to share data.
20 Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
Also, an ERD can highlight areas of potential data sharing, or simply clarify
what data a particular system uses. Organizations, such as OSWER, are moving
toward identifying data sharing opportunities by examining data requirements
across systems. This will, in the future, allow for the development and use of
common databases. Appendix F contains an OSWER-wide data model and an
explanation of its development.
Data Madding Practice Paper
-------
This page intentionally left blank
-------
OS WER Directive #9028.OQc
3. DATA ENTITIES
3.1. CREATING DATA ENTITIES
So far we have introduced data entities but have not fully described them nor
given any guidance as to when to create them. This chapter discusses this
somewhat subjective topic in greater detail.
3.1.1. What is a Data Entity?
Earlier we defined a data entity as "anything that an organization collects,
processes, and /or reports information about". This was probably a bit misleading.
For example, do forms translate into data entities? That is to say, if we have a data
collection form called "Form 1234", do we also have a data entity called Form 1234?
The answer is definitely NO. In fact, forms tend to comprise data across multiple
data entities.
One of the challenges then, is to discern the logical aggregations of data from
the way they might be physically captured, stored, or retrieved in an organization's
systems. One way to help us think logically, instead of physically, is to define data
entities into six descriptive types2:
Person Humans that carry out some activity(ies). Examples include
Employee, Inspector, Attorney, On-scene Coordinator,, and Contract
Officer.
Place - Areas or locations. Examples include Facility, Site, and Region.
Thing - Tangible (physically touchable) objects. Examples include
Chemical Substance, Storage Equipment, and Product.
Organization - Formally organized collections of people, resources,
facilities, and capabilities. Examples include Contractor, State Agency,
and EPA Organization.
Concept - Intangible ideas (not physically touchable). Examples include
Cleanup Contract (which is essentially an agreement between two
parties), Schedule, and Budget.
Event - Things which happen at a particular point or period in time.
Examples include Spill, Shipment, Cleanup Activity, and Sales Order.
2Descriptions of entity types adapted from Entity Modeling: Techniques and
Application by Ronald G. Ross
Data Modeling Practice Paper 13
-------
OSWER Directive *9028.00c
Data entities are the types of things in an organization about which
information must be recorded. Each data entity has many possible occurrences, but
these occurrences are not depicted in an entity relationship diagram. Examples of
occurrences for a Chemical Substance entity might be hydrochloric acid, potassium
nitrate, or water.
The above types are useful for identifying data entities. For example, if we are
interested in an inventory system, we might think about the types of data entities
needed for a complete inventory system. What Person entity types might be
needed? We might need Employee, and perhaps Supplier Contact. Place entities
might be Retail Store and Warehouse. What Things might we keep information
about? Perhaps Product, Product Part, Storage Equipment, and Transportation
Equipment. We might include Delivery Schedule and Supplier Contract as Concept
entities. Various Organization entities are of interest, such as Internal Department,
Supplier, and Exchange Partner. Lastly, Event entities might be Retail Store Order,
Warehouse Shipment, and Store Delivery.
3.1 JL How Do You Distinguish Between Data Entities and Data Elements?
A common source of confusion is distinguishing between data entities and
data elements. Suppose we had a data requirement to know the names of the
chemical substances in a spill sample. We said earlier that data entities are
comprised of data elements, and that no data elements are describing more than one
data entity. So then, is Chemical Substance a data entity or a data element? Well
that depends...
Chemical Substance Name is probably a data element since it seems to be at
the smallest meaningful level of detail. In other words, to break Chemical
Substance Name down further produces no additional meaningful information. If
the scope of our analysis (for a given project) requires that we capture Chemical
Substance Name as part of spill sample data, then Chemical Substance Name may be
a data element of Spill Sample.
However, if the scope of the analysis includes knowledge about the chemical
substance itself, for example, the texture, viscosity, toxicity, color, etc, then we
should include a Chemical Substance data entity as well. If that is true, then does
Chemical Substance Name still describe Spill Sample? No. In this case, Chemical
Substance Name describes Chemical Substance. Returning, to our original data
requirement, which is to know the names of the chemical substances found in a
particular Spill Sample, all we need is a data relationship between the two data
entities, as shown in Figure 3.
If the above scenario seems arbitrary, it really isn't entirely. We are simply
saying that if a data entity has only a single data element defined for it, it may not be
14 D*t* Madding Practice Piper
-------
OSWER Directive #902S.OOc
a data entity at all for the given scope of the analysis. Rather it might be a data
element of another data entity.
There is an exception to this that is worth mentioning. While it may be true
that the scope of analysis might not include information about Chemical Substance,
except for the Chemical Substance Name as it describes a Spill Sample, and thus
according to the above it would be a data element of Spill Sample, what if we know
we need unique occurrences of Chemical Substance Name? This would be
particularly true if there were a requirement to be able to examine Spill Sample data
based on unique Chemical Substance Names. Now it seems that it will be necessary
to create a Chemical Substance entity with only a single data element, called
Chemical Substance Name.
3.13. How Does One Gauge the Scope of Analysis?
As part of planning any system development project, the project team, must
put some boundaries on the scope of the project. Sometimes the scope is expressed
generally in terms of addressing existing data problems or current system issues. At
other times the scope suggests the intended business functions and data that will be
addressed by the project. The sooner that scope is defined in terms of data and
business functions, the better the project team will be positioned to conduct the
more detailed analysis in a structured and methodical way.
As early as the Initiation Phase some preliminary high-level modeling (or
"sketches") can be developed by the project team to begin to get an understanding of
project scope. During the Concept Phase of the SLC the project team should develop
a reasonably complete conceptual data model and high-level process model of the
area of business to be analyzed. Process modeling (sometimes referred to as function
modeling), like data modeling, examines business requirements but does so from
the perspective of analyzing business activities. Data modeling, on the other hand
focuses on data.
In order to do a thorough analysis in either, it is important to bring function
and data modeling together, sometimes called interaction analysis. Interaction
analysis should be an on-going activity that is addressed each time new information
is learned about the process and data requirements for a system project. Interaction
analysis is very important since it is the activities that the business performs that
creates and maintains the data the business needs.
To illustrate the concept of interaction analysis, suppose we have a need to
improve inventory management capabilities to support operations in a company.
What business functions might be in scope? Some possible inventory management
functions are:
. Stock Purchaging
^ Stock RocmMng
Data Madding Practice Paper 15
-------
OSWER Directive #902S.OOc
Order Filling
Stock Reconciliation
Once we have ah idea what high-level functions are in the scope, we need to
define the high-level data or conceptual entities. Examples of conceptual data
entities might be:
Product
Product Inventory
Supplier
Stock Order
Cuetomer Sales Order ,
How did we arrive at the above data entities? Well, one way is simply to
brainstorm, ensuring that the brainstorming session remains within the context of
inventory management. Another, more precise, way to determine data entities is to
think about the information requirements that each of the above functions
"creates", "reads", or "updates".
"Create" means that the function adds a new occurrence of the data entity that
was not stored before; "read" means that the information about an existing
occurrence of a data entity is needed, but not changed; and "update" means that
change(s) are a made to an existing occurrence of a data entity.
Typically, an analyst maps the functions as shown in Figure 4 to validate the
list of conceptual data entities and the list of functions. Analysis of this mapping,
called CRUD (Create, Read, Update, and Delete) action analysis, is illustrated by the
following discussions.
Note that in Figure 4, the following data entities are not shown as "created"
anywhere: Product, Product Inventory, and Customer Sales Order. This means that
no functionality addresses their creation. Should the potential future system create
the Product entity information? For this business the answer might be no, because
product data could be created as a result of a larger product management function. If
so, the creation of this data is therefore not in scope. Product data must then be
integrated into this system by some other means, such as providing an automated
interface to a Product database in another system.
Product Inventory is also not shown as created. However, it could have been
a part of one of the above business functions or created as a result of some other
business function. In order to be discrete about which functions create what data, a
new function, called "Product Distribution Planning", which might create
inventories (in other words, places where product will be distributed from) could be
included. In this way, by evaluating the function-to-data interaction table, we can
determine if we are missing any critical functions from our scope, such as "Product
Distribution Planning".
16 D*t* Modeling Practice Piper
-------
OSWER Directive #9028.OOc
Figure 4. Anticipated CRUD Actions of Business Function on Data Entity
BUSINESS
FUNCTION
Stock
Purchasing
Stock
Receiving
Order Filling
Stock
Reconcil-
iation
DATA ENTITY
Product
R
R
R
R
Supplier
CRUD
R
Stock
Order
CRUD
UR
Product
Inventory
R
UR
R
UR
Customer
Sales Order
UR
Note: C=Create, R=Read, UsUpdate, Q^Deiete
Lastly, Customer Sales Order is not created. Sales data are not a result of the
above functions/ since this information is created by a sales function. Thus some
interface to this data is necessary, as with Product data.
The results of examining the CRUD matrix above yields an architecture for
the future system. Typically this architecture is depicted in a data flow diagram
(DFD). Figure 5 depicts an example DFD for the inventory management business
function.
If we think about the "Stock Receiving" function we might need to create a
record of the delivery, which in this example, can contain products fulfilling many
stock orders. Thus by evaluating the function-to-data interaction table, we can
determine if we are missing any critical data from our scope, such as Stock Delivery
information. Similarly, the "Product Distribution Planning" function needs
warehouse locations, which may suggest that our data model needs to include an
entity - perhaps called Warehouse.
We know that various other organizational users may need some of the
above information, such as inventory valuation data for accounting. If we're not
careful, the scope of the system could be expanded to include everyone's
requirements to solve all of their problems. For example, the scope of the system
could end up including a sales function and various accounting functions as well.
This situation is called "scope creep" and must be managed carefully. The result of
Data Modeling Practice Paper
17
-------
OS WEI? Directive #9028.OOc
scope creep can be a project with very high risk due to a tremendous development
effort and potential maintenance problems.
While it makes sense that the resulting system provides the data that others
need, it is critically important to be sure that the system does not attempt to create
more data than it should. Ideally the system should not create redundant data. For
example, if our inventory management system creates data that is inherently part of
other business activities, such as sales, then this system may be doing more than it
should. This is particularly true if the system is going to create data that is outside of
the functional scope. If data from outside the functional scope are needed in this
system (that is the business functions use the data but do not create it), then one of
the following techniques should be used:
1. Show the data as external "reads" into the functions in scope, and
identify existing systems (or organizations) t -at can provide the
necessary data. This is the best way to handle data needs that are not
inherently created as part of a project scope.
2. Show the data as external "reads" into the functions in scope, but also
indicate that the system will have to create this data temporarily, until
the data can be provided from some other existing or future system.
3. Increase the scope of the project to include the functionality which
creates the external data (and thus making it internal to the project).
This approach may lead to scope creep and redundant data collection,
as indicated earlier. Care should be taken to limit project scope to a size
that can be managed, is cost effective, and is feasible for a reasonable
period of time.
Note that in any of the three cases above, the data that are not created by the
system should still be represented in the data model. "Not created" in this case
implies that the data are sourced from within the organization, even though the
system may re-enter it redundantly. Thus while figure 5 does not show a data store
for warehouse information (because it is being provided by Facilities Management),
the data model would include a data entity for Warehouse. This ensures that all the
data used by the system is modeled in an integrated manner.
3.1.4. What are Sources for Identifying Data Entities?
Project teams use various sources of information to develop a data model.
Initially, the earliest inklings of a conceptual data model begin in the Initiation
Phase as the team defines the information management "problem" to be solved. As
the problem definition becomes dearer, the team identifies types of data needed and
puts together an initial data entities list. This list is developed in various ways, such
as by brainstorming the information requirements, and by "noun searching"
documents and interview notes. Noun searching is a simple technique of looking
~18 '~ Data Madding Practice Paper
-------
OSWER Directive #9028.00c
for key nouns that have been used to describe the information management
problem. Often, these nouns constitute the basic data entities that the system will
need to keep information about.
If an Information Strategy Plan (ISP) was performed, a set of initial data
entities will be available to a project prior to its initiation. An ISP is a high-level
organization-wide study within Information Engineering Methodology (IEM), a set
of system development techniques and practices developed by James Martin. The
purpose of an ISP is to identify high-level business activities, objectives, and data,
and use this information to develop plans for implementing integrated information
systems within an organization.
Figure 5. Example Data Flow Diagram of Inventory Management Function
During the Concept Phase, as appropriate representatives from organizations
participate in determining project scope; information will come mostly from the
individuals. Sometimes supporting documentation is used, such as issue papers or
Data Modeling Practice Paper
19
1
-------
OSWER Directive #902S.00c
problem reports. This documentation identifies data requirements and can be
analyzed to put together a straw-man conceptual data model.
As the analysis continues in the Definition and Design Stages, other sources
of information are used, such as interview results; Joint Application Design (JAD)
results (a JAD is a structured meeting led by a trained facilitator where the primary
objective is to reach consensus on requirements and resolution to issues); and
current system reports, screens, and other documentation. The information from
these sources must be "pushed through an analytical sieve" to extract meaningful
data requirements and other system requirements.
Interviews generate information about data needs, critical success factors,
objectives, goals, and business activities. All of these things contribute toward the
identification of potential data entities. Data needs expressed in vague terms are
typically called "information requirements" and must be analyzed further to
determine 'the data entities which support the information requirements. Critical
success factors, objectives, goals, and strategies can also be examined to identify
information needed but not otherwise identified.
Current system information, such as reports or forms, should almost always
be reviewed, since in most cases much of the existing data is needed in a new
system. Current reports can be analyzed in a bottom-up fashion to determine the
kinds of data entities represented by the report or form. However, it is critical to
keep in mind that a data model should represent the way the business area or
system will be defined as, not how it exists currently. If we don't build into the data
model the appropriate business rules that should exist, then future goals will not be
met.
3.1.5. Does System Life Cycle Phase Dictate Which Entities to Create?
The phase of the SLC suggests, but does not dictate, which entities should be
defined. As stated earlier, the conceptual level of analysis has far fewer data entities
than the logical model. This is due to the way in which the models are developed,
and because much more analysis is performed to create a logical model than a
conceptual one. The truth is, though, there is still some subjectivity in deciding
whether or not to define a data entity in either model.
Figure 6 illustrates the progression of analysis for the first four phases of the
SLC It shows the evolution of the conceptual data model (developed in the
Concept Phase) to the logical model (developed in the Definition Stage), and the
logical model to the physical data base design (developed in the Design Stage). The
decision as to when to revise the conceptual or logical models is based on the
identification of new data requirements or refinements to data requirements already
identified.
-------
OSWER Directive #9028.00c
Figure 6. Progression of Data Modeling During the SLC
Data
Model
Conceptual
Data
*m^ ~M~*
MOOW
Logical
Data
m.m «-
OOvf
Phyateal
Baaa
Oaalgn
System Ufe Cycle Phase/Stage
/nWatfon
Phaae
Concept
Pnaaa
O^Mtton Oaalgn
Stag. staga
p-MMoJ«Ef«ttM I
Cone*
Oafti
IM*»
ft**
Ifcdil
«MIMf
iodvl
J
-1
'
L L
LogMOMi
Moy»aiOMi
J- B~~~ J
^S^j m"*^1? J
T 1 '«-*-'
1 HMtad I «V«-I*TAJ
' ii '"prV J t^mm^m
|_ _ Danlfad^ , /
i ; J
In general, the following guideline works for adding new data entities: As
soon as there is evidence to suggest that the scope of a project includes a particular
data element for which there is no data entity, then add to the model at least the
conceptual data entity that represents the new data requirement. To appreciate
whether an entity should be defined or not it sometimes helps to understand three
categories of data entities: Kernel/Conceptual, Attributive, and Associative Data
Entities.
Kernel I Conceptual Data Entities are generally those that can exist
independently of any others. In Figure 3, EPA Organization, Contractor, Site, and
Chemical Substance are all kernel entities, because there are no business rules
implied by the model that require any other data entities to exist in order for the
kernel entities to exist. (This can be explicitly verified by examining the cardinalities
of the related entities. All related entities must have a minimum cardinality of
zero.) .
Datf Madding Pnetiee Paper
21
-------
OSWER Directive #9028.00c
Some of the conceptual entities in the example are dependent on other
entities and thus are not kernel, such as Spill, Cleanup Contract, Cleanup Activity,
and Spill Sample. These were all considered to be conceptual in Figure 3 because of
their perceived degree of importance and they are inherently different entity types
than the ones they are related to. A spill (event entity), for example, is inherently
different than a site (place entity), and a contract (concept entity) is not the same
thing as a contractor (another concept entity).
Conceptual data models contain mostly kernel entities. However, as just
described, Figure 3 does include non-kernel data entities as well. By including these
entities, we have a better sense of the data within the scope of the example project.
Attributive Data Entities are those that further describe a conceptual data
entity and are dependent upon the existence of the conceptual data entity for its own
existence. Generally, few attributive data entities are shown in a conceptual data
model. If, for example, a Contractor had more than one address, we might define an
attributive data entity for Contractor Address and relate that to the Contractor entity.
This kind of entity, depicted in Figure 7, is usually the result of data normalization
and would most likely appear in a logical data model and not the conceptual model.
Associative Data Entities are data entities created to resolve many-to-many
data relationships. A many-to-many relationship is any relationship where each
side of a single relationship between two entities is "many" (or more than one). For
example, Figure 3 shows a many-to-many relationship between Spill Sample and
Chemical Substance. The problem with many-to-many relationships is that they
can not be easily implemented (since the physical data base would have to maintain
foreign keys as part of both entities). Associative data entities are usually created as a
result of data normalization and would most likely appear in a logical data model
and not the conceptual model.
Many-to-many relationships often result in the need to store information
about the relationship itself. Using the example from Figure 3, if we wanted a
system to store the quantity of the chemical substance found in a particular spill
sample, it would be incorrect to suggest that the data element chemical substance
quantity in spul sample describes Spill Sample. Nor does this data element describe
Chemical Substance. This is because we would have to store this element many
times for each occurrence of either of these two data entities, which violates the data
modeling rule of representing data non-redundantly.
Data normalization, which attempts to store all data once and only once,
suggests that we need to do something different. Instead, we define a new data
entity, Chemical Substance in Spill Sample, and indicate that the data element,
chemical substance quantity in spill sample, describes this data entity. This new
associative data entity, depicted in Figure 7, is also called an intersection entity, since
each occurrence of this entity is uniquely identified by the intersecting identifiers
from the other two entities.
22 ' £>«<« Modeling Practice Paper
-------
OS WER Directive W028.00c
As shown in Figure 7, each occurrence of the intersecting entity, Chemical
Substance in Spill Sample, relates to one Spill Sample and one Chemical Substance.
Thus, if we wanted to know all of the chemical substance quantities in a particular
Spill Sample, we would retrieve all the occurrences of the intersecting entity that
related to the Spill Sample of interest. Then, if we needed information about the
chemical substance itself, we could retrieve information from Chemical Substance,
such as name, toxicity, chemical properties, etc., based on the relationship from the
resulting occurrences of the intersecting entity to Chemical Substance.
Figure 7. Logical ERD Example
with Attributive and Associate Data Entities
EPA
OrvMiteatlon
Sft«
. == ^
Cv*rs**n Overs*** Occurs at
by
6 <
/\. Counter- S
Provkfosfor s , rn.ww.far
CfcMIIIMp II aS Ctoamw Xn /
Contmut II u\ AetMty /** \
Provided by > ^ >
f
Location of
\
\
SplH
nMwsurad by
Agremto AgrMnMrrt Souiwdat
with . .
-- A
HAS Lofurtoo s ^/s//^^f//s
1 ju-iliL ~l \ S//S///S/
l,ttVmuKJt\ Oi ^ rS/s/////S
M»
Sourco of
)
K
p«l tempi*
^
Cont*Jn*din
Conc*ptiMl/K*mal | | S
A~*fim*um II Contaln*dln s
AMOClrtvw OMmkMil 1 1 rt /
Attributiv* 1Z7A * Contains >
»
Contains
>
k
£S?
Date Madding Prtetiee Paper^
23
-------
OSWER Directive *9028.00c
In a similar fashion, if we wanted to know all of the spill samples for a given
Chemical Substance, we could retrieve all of the intersecting entities that relate to a
particular Chemical Substance and proceed to retrieve the spill samples as we did
with Chemical Substance above.
3.1.6. What are Data Entity Homonyms and Synonyms?
When developing a data model, particularly with the collaborative effort of
one or more analysis teams, various issues will surface based on individual views of
the meaning of the data (or semantics) being analyzed. These semantic issues often
take the form of data entity homonyms and synonyms.
Data entity homonyms are entities that have the same name, but because
people have defined them differently, they are really not the same entity. For
example, two data entities called Contractor may be under consideration in a data
model. However, further analysis suggests that one definition,refers to Contractor
as the firm providing contract services, whereas the second definition is an
individual employee of the contracting firm. These are two different entities.
Data entity synonyms are entities with different names, but are actually
describing the same thing. For example, a data model might have Site and Location
as two data entities, but further analysis proves them to be the same entity.
Once found, the homonyms and synonyms should be reviewed to decide
whether or not the entities are the same or different. Possibilities for resolving a
homonym or synonym situation are:
1. If the entities are found to be different, devise different entity names;
2. If the entities are the found to be the same, use one name and
definition (or a revised compromise definition) and include any
synonym names in the description of the entity (refer to the
SYNONYM property in Appendix A); or
3. If the entities have overlapping meaning, additional analysis is
required to resolve the issue. Perhaps one or both of the data entities
are not defined discretely enough to distinguish it from the other(s).
This process can be difficult, particularly because it often means resolving
semantics issues across organizations. Data analysts and data modelers should be
wary of homonyms and synonyms as they progress their analysis to maintain the
integrity of their models and to prevent future time-consuming debates amongst
analysts and users on the data entities and their definitions.
-^T If- -1 ,1.T,,. <> T»
-------
OSWER'Directive. #9Q28.QOc
3.1.7. What are Natural Data Entity Identifiers?
One of the essential principles of a data model is that data occurs only once.
For example, for EPA Organization, some of the possible entity occurrences are
OSW, OERR, OUST, OWPE, and OSWER AA. Ideally, in order to maintain integrity
within a data base, the occurrence OSW should only exist once in the data entity
EPA Organization. For this to be true there must be some data element (or
combination of data elements) that would guarantee that each occurrence of EPA
Organization is unique. Such data elements are called natural identifiers. In this
simple case, the natural identifier might be the name of the organization.
A key principle of data modeling is that each and every data entity should
have at least one unique identifier. To continue with the example, the identifier for
Contractor might be the IRS employer identification number. While name may
seem to work as a unique id, it might be possible for two contractors to have the
same name, whereas their IRS id is presumed to be unique.
It is important to look for natural identifiers, such as the two examples just
given. Identifiers that are not natural are typically system-oriented identifiers and
arbitrary identifiers. Another possible identifier for EPA Organization is
organization number, but organization number is a devised data element and could
be assigned on an arbitrary basis. Natural identifiers are data elements that
eliminate any arbitrary possibilities. However, sometimes we must break the rule if
we know we need to uniquely differentiate between occurrences of a data entity and
no natural identifier can be defined. Although rare and somewhat subjective, in
those cases we define a new data element which serves as a sequential identifier.
If it is not possible to determine a unique identifier, the data entity is suspect.
This does not necessarily mean that it is not an entity, but critical analysis should
examine the legitimacy of the data entity's existence. From a theoretical standpoint,
if we can not determine what uniquely identifies an occurrence of a data entity, how
can we say we fully understand what a given occurrence of the data entity is?
Perhaps the candidate data entity is actually more than one data entity and should be
represented as such.
Determining unique identifiers can also help to determine whether or not
two data entities are the same. For example, if we included a Site Description entity
in Figure 3 and related it to the Site entity, what would its unique identifier be? If
the identifier for Site Description is the site address, then the entity is suspect, since
this identifier is the same as the Site identifier. In this case, the two entities Site and
Site Description are part of the same entity, called Site.
The identifiers also serve as the basis for accessing data in the data model. In
Figure 3, a Cleanup Contract relates to a Contractor. This means that a single
occurrence of the Cleanup Contract entity has related information in one occurrence
of the Contractor entity. The specific occurrence is the one with the corresponding
Data Madding Practice Paper 25
-------
OSWER Directive #9028.00c
Contractor identifier. In a physical data base, we might store a contractor identifier
with the Cleanup Contract data in order to know which Contractor they are related
to.
3.1.8. What is Data Entity Subtyping?
In most data modeling textbooks there is a section on data entity subtyping.
Although this is an important concept within data modeling, it is not explained in
detail within this paper. The entity subtyping technique results in expanding a
given high-level data entity into more detailed data entities where the high-level
entity has different types and the types either have unique data elements or unique
data relationships that only apply to those types.
For example, referring to Figure 7, a subtype of Chemical Substance might be
Toxic Chemical if for toxic chemicals we needed to store data that only applied to
toxic chemicals, such as toxicity and treatment parameters. Note that the supertype,
Chemical Substance, would still represent all of the data that is common to all of the
subtypes. Refer to a data modeling textbook for a more complete explanation on
defining entity subtypes and supertypes.
3.2. NAMING DATA ENTITIES
The names chosen for the components in a data model are important for
communicating the high-level data requirements for the scope of analysis. The
naming conventions for data entities are not as precise as those for data elements,
but here are some general guidelines worth following:
Ensure that the data entity name is unique across the model.
Always use the singular case of the name. Use singular nouns to name
data entities. For example, use Customer not Customers, or Waste
Management Activity, not Waste Management Activities. This
minimizes vagueness about what a single entity occurrence represents.
Create names as discretely and precisely as possible. For example, if the
scope of analysis includes a specific type of contract, like contracts for
cleaning up waste sites, use something like Cleanup Contract instead of
just Contract.
Use names which are the users' terminology, where possible. In some
cases, this approach is not desirable when the name chosen has
different connotations for different user groups, and devising a
standardized name may be more effective (and less problematic).
Remember that the entity definition helps to qualify the meaning of
the data entity.
26 Data Madding Practice Paper
-------
OSWER Directive #9028.00c
Include synonyms in the definition of the data entity to qualify the
entity name. This can help to reduce the problem in using
standardized names as described above. For example, if some clients
call a contract an agreement, then select one of the two as the "official"
name of the data entity (perhaps Agreement), and identify the other as
a synonym (in this case, Contract).
Avoid using physical aspects of data in the name. For instance, when
naming an entity to describe the event oriented data associated with
the receipt of a complaint from a customer, use something like
Customer Complaint, instead of Customer Complaint Letter. We do
not want to preclude the possibility that the information on a letter
might be submitted electronically in the future. Implicitly, it doesn't
matter if the information was submitted by letter or telegram or
whatever. It is the information on the communication that is
important.
Never use phrases like "data" as a catchall. For instance, the entity
name Site Data does not adequately describe what the entity is.
Avoid using form or report names, unless the entity represents
information about a form or report, like the form number, form
dimensions, purpose, distribution, etc. (Note that this is not the same
as the information on the form or report!)
Limit the length of the entity name to 30 characters. This is useful
since long names are too hard to read and understand. Also, if the data
entity information will be entered into a CASE tool, most of the tools
have this length limitation. Abbreviation of selected words can help to
shorten the name, but standard abbreviations should be used in this
case. Abbreviate the rightmost words first, moving backwards in the
name as needed. This allows for better sorting in reports. Try to use
letter characters only; avoid using special characters like
"/?!«#$%&*()-,." in the name.
A longer name, called a Full Name, is also specified for data entities.
The Full Name is an OSWER data standard and is one of the properties
for describing data entities (the Full Name property is described in
Appendix A).
33. DESCRIBING DATA ENTITIES
The naine of a data entity is not enough to Understand its precise meaning.
Therefore, as part of a complete data model, each data entity should be defined with
Data. Madding Practice Paper 27
-------
OS WER Directive #9028.OOc
a set of properties to document its precise meaning and other information about the
data represented by the entity. Figure 8 lists the properties used to define data
entities.
Figure 8. List of Properties for Defining Data Entities
Average Occurrences Examples
Comment* Full Name
Data Collector Growth Rate
Data Custodian Identifiers
Data Deflner Maximum Occurrences
Data Steward Minimum Occurrences
Data User References
Description Security
Documentor Name Synonyms
effective Date Version Number
Figure 9 indicates when each property should be completed and revised
during the SLC and whether the standard applies to the conceptual or logical data
model. Note that revising data entity properties during the SLC takes the form of
changing values from a prior phase and populating properties where no value was
provided in a prior phase.
The above properties, when completed for a data entity, completely describe
the data entity with tile exception of data elements. Recall that data elements also
describe data entities by defining specifically an entity's contents. In order to
completely understand a data entity in a logical design, it should be documented
with data elements, which have their own set of properties as described in Chapter
5, Data Elements.
Appendix A provides a complete set of definitions for each of the above
properties. Special attention should be given to completing the Description
property, since it is this property which will be used most often when
communicating the entity's meaning to others.
28 . - Data Madding Practice Piper
-------
OSWER Directive #9028.00c
Figure 9. Data Entity Property Completion Matrix
PROPERTY
Average
Occurrences
Comments
Data Collector
Data Custodian
Data Definer
Data Steward
Data User
Description
Documentor Name
Effective Date
Examples
Full Name
Growth Pate
Identifiers
Maximum
Occurrences3
Minimum
Occurrences
References
Security
Synonyms
Version Number \
CONCEPT PHASE
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
Cc
DEFINITION
STAGE
Q.
CLRC
CURC
CLRC
CURc
CLRC
CiRc
ClRc
CLRC
CLRC
CLRC
CLRC
d
CLRC
d
CL
CLRc
CL
CLRc
CLRc
DESIGN STAGE
RL
RL
RL
RL
RL
RL
RL
RL
Key to Table Cc means Complete for data entities in the Conceptual data model
CL means Complete for data entities in the Logical data model
Re means Revise data entities created in the Conceptual data model
RL means Revise data entities created in the Logical data model
%Carinum Occurrences and Growth Kate are sometimes used during the Concept phase as a way of
estimating database size for feasibility analysis and technical platform assessment
Data Modeling Practice Paper
29
1
-------
This page intentionally left blank
-------
OSWER Directive *9028.00c
DATA RELATIONSHIPS
4.1. CREATING RELATIONSHIPS BETWEEN DATA ENTITIES
In the Data Models section, Entity Relationship Diagrams were introduced
and instruction on interpreting an ERD was provided. This chapter describes data
entity relationships (or simply data relationships) and their creation and use in
more detail.
4.1.1. What are Data Relationships?
A data relationship is an association between two data entities, as it exists in
the real world. The creation of a relationship requires an understanding about the
nature of the data, particularly how the data elements (represented by the data
entities) relate to each other. For example, we might define a relationship between
Facility and Employee, as shown in Figure 10.
Figure 10. Example of Data Entity Relationship
The example above provides information about a real world relationship:
employees work at facilities. The cardinality tells us that:
An Employee Works at one (1) and at most one (2) Facility
and
A Facility is the Workplace of zero (3) or more (4) Employees
Thus, the data relationships are actually statements about the valid business
rules, which may differ from one business to another. In the example above, a
business rule has been defined which limits an employee from working at moire
than one facility. (Recall from the section on "How Do You Read an ERD?" in
Chapter 2, Data Models, that these rules are expressed in the form of cardinality,
Dtta Modeling Practice Paper
31
-------
OS WE/? Directive #9028.OOc
information about the minimum and maximum occurrences allowed of related
entities to a given entity.)
If, in the example above, an employee could work at several facilities, the
Personnel System would not be able to accommodate this information, except by
continually changing the facility related to the employee when the employee
changed facilities. This might be impractical if, at any point in time, we needed to
know all of the facilities that an employee works at
However, the relationship could be changed to allow employees to work at
more than one facility by making the relationship between employee and facility
many-to-many, instead of many-to-one. Assuming that the true business
requirement is to record all of the facilities an employee could work at, the initial
model would not meet the requirement. This relatively simple example illustrates
the importance of reflecting the true business requirements. If not reflected in the
data model, the relationships will not be designed into a future information system,
thus making the system far less useful to the organization, if not entirely
inadequate.
4.1.2. Can There be More Than One Relationship Between Data Entities?
What if we wanted to know the employee who manages each facility? Do we
need to change the above relationship? The answer is no. This is because for a
given occurrence of an employee we need to know about different facilities, and for
different purposes. As Figure 11 illustrates, the need to know about who manages a
facility is a different relationship than the relationship between a facility and the
employees who work there.
Figure 11. Example of Multiple Data Entity Relationships
(
Manages
>
w
«-
Managed by
V Works at s
\0 I/
/WfcplaceofN
(
/
>
N
PaeMty
The new relationship can be interpreted as follows:
An Employee Manages zero or more Facilities
32
Data Modeling Practice Paver
-------
OS WER Directive #9028.00c
and
A Facility is Managed by zero or one Employees
4.1 J. When Should Zero Cardinality be Used?
Cardinality of zero (also called optionality) is used as a minimum occurrence
when it seems that it is not absolutely necessary for one entity to exist when creating
another. In the prior example it seems reasonable that an employee maneges zero
or more facilities, since not all employees are managers. But for the reverse
relationship, facility is managed by zero or one employees, why wouldn't we make
it mandatory for a facility to have a manager? Well one reason might be that the
business may not have selected a manager at the time the facility is defined. While
unusual, this case illustrates that it is very important to model exceptions as well as
the general rule, thus ensuring that a future system will be able to handle
exceptions, no matter how infrequent they may be.
Zero cardinality applies at data creation time. In our example, the business
will allow the creation of a facility (and define it to their systems) without a manager
relationship defined. In addition, zero cardinality also applies at any time during
the existence of an entity (not just when the entity is created), so at any time a facility
can exist without a relationship to employee.
4.1.4. Is it Permissible to Have Redundant Relationships?
A data model may contain redundant relationships, which should be
scrutinized and eliminated. Redundant relationships typically result from different
members of the same project team creating the same implied relationship but using
different relationship names to do so. In the examples above, if a relationship was
added that said facility employs employee (and employee employed by facility in the
reverse direction), would we have a redundant relationship? Well that depends...
If when establishing this additional relationship between Facility, and
Employee, we were always interested in the same facility that the relationship
facility workplace of employee implied, then the two relationships would be
redundant This is because the information that the relationships are conveying for
both relationships is the same. (Jn both cases we would expect the same facility to be
related to the employee and thus both relationships are referring to a workplace
relationship.
However, it is possible that the relationships would be non-redundant, if
sometimes the facility employs employee relationship implied a different facility
than the facility workplace of employee relationship. In this case we might justify a
business rule which confirms this: the facility which is employing an employee
Data Madding Practice Ptper 33
-------
OSWER Directive #9028.00c
(perhaps paying for the employee's time) may be different than the facility that the
employee works at
4.1.5. What are Recursive Relationships?
A recursive relationship is a relationship between an entity and itself^ This
means that an occurrence of an entity has some relationship to one or more other
occurrences of the same entity. While this may seem strange at first, Figure 12
illustrates a few common examples of recursive entities.
The recursive relationship for Organization illustrates a way to represent an
organization's hierarchical structure; the recursive relationship for Machine Part is
typically referred to as a "bill of materials" and is a way to represent how parts are
made up of sub-parts, and sub-parts of sub-sub-parts, etc.; and the recursive
relationship for Employee captures the information that employees supervise other
employees.
Figure 12. Examples of Recursive Data Entity Relationships
CocnpnsoQ of
Comprised of
Notice in Figure 12 that all of the relationships show optionality (minimum
cardinality of zero) at both ends of the relationship. This will often be the case for
recursive relationships since they typically represent a real world hierarchy
consisting of "parent" occurrences with multiple "children" occurrences, and has a
definitive top (or root) and bottom (or child with no children of its own). For
example, the lowest level department in an organization is not comprised of any
other departments, nor is the highest level organization part of any higher level
departments.
NAMING DATA ENTITY RELATIONSHIPS
The name of the relationship is the English language description shown on
the relationship lines in the examples above. For instance, in the relationship
employee manages zero or more facilities, manages is the relationship name in this
direction and managed by is the relationship name in the reverse direction.
34
Dot* Moddin? Practice Payer
-------
OSWER Directive #902S.OOc
Together, manages and managed by comprise the name of the data entity
relationship.
Naming data entity relationships can sometimes take longer than necessary,
since it isn't always easy to come up with meaningful names. The following
guidelines are worth noting:
Use verbs of action. Describe the business interaction of the related
data entities. Think about the reason for needing a relationship
between the entities. The reason should be a clue for devising a good
name. For example, suppose we are considering a relationship
between Customer and Product. If we are interesting in relating the
two entities based on the fact that customers order products, a poor
name would be Customer has orders of Product. A better and more
succinct name using an active verb would be Customer Orders Product.
Use meaningful names. Names like related to or associated vrith do
not add enough meaning to the name to be useful when
communicating the relationship to others.
Eliminate "be" verbs from the name. Words like "is" are implied and
are generally not shown in the relationship name.
Try naming the active relationship direction first. For most
relationships there is an active and a passive direction for the
relationship. For example, customer places order is the active
direction, whereas order placed by customer is passive. It is generally
easier to name both sides of the relationship by starting with the active
side.
43. DESCRIBING DATA ENTITY RELATIONSHIPS
As with data entities, data relationships are described with a set of properties.
A complete data model should contain the properties shown in Figure 13. The
properties with "ERD" next to them are those that generally appear on a Data Entity
Relationship Diagram (ERD).
Appendix B provides a complete set of definitions for each of the properties
listed below.
DattTModelm% Practice Paper " 35
-------
OS WE/? Directive *9028.00c
Figure 13. List of Properties for Defining Data Relationships
Average From Occurrences ERD Maximum To Occurrences
Average To Occurrences ERO Minimum From Occurrences
Business Rule Description ERD Minimum To Occurrences
Comments ERD Relation From Name
Documentor Name ERD Relation To Name
Effective Date ERD To Entity
ERD From Entity Version Number
ERD Maximum From Occurrences
36 Dtt* Madding Practice Piper
-------
OSWER Directive #902£.00c
5. DATA ELEMENTS
5.1. CREATING DATA ELEMENTS
We have described data entities, when to define them, how to represent them
graphically using entity relationship diagrams, and defining data relationships
between data entities. All of these data model components are addressed in (the
Concept Phase and Definition Stage of the System Life Cycle (SLC). Data elements
are defined during the Definition Stage to complete the Logical Data Model, which
will be the primary input to a physical data base design.
5.1.1. What are Data Elements?
Data elements are the most specific facts of data in a data model that when
detailed further become meaningless to the needs of the organization. Examples of
data elements are employee first name, employee last name, employee hire date,
employee start date, and employee social security number. If we tried to be more
specific than "employee first name" we would have a set of characters that might
not be useful to the organization. Conversely, if we said°that employee address is a
data element, then we are assuming we do not need information about the street or
zip code independently from the entire address itself. Employee address may
actually be a collection of data elements.
Note that the data elements listed above are describing an employee, which is
a data entity. Recall that the reason employee is a data entity is because it is a person
about whom we need to keep information, specifically the data elements listed
above. Thus, data elements describe data entities and justify the data entity
definition; in fact, to understand the meaning of a data entity fully, we need to
know what data elements describe it. Figure 14 illustrates data elements for two of
the data entities on our earlier example ERD.
5.1.2. What are "Normalized" Data Models?
The amount of work to progress from a conceptual data model to a logical
data model is significant. Whereas data elements are not identified in a conceptual
data model (except for data entity identifiers, as previously discussed), each and
every data element in a logical model is explicitly identified and defined. In
addition, a series of analysis steps, termed data normalization, are performed to
ensure the integrity of the model. Data normalization ensures that the structure of
the data supports maximum accessibility to data with minimum data redundancy.
To better understand data normalization, it helps to recall that a data element
describes only one data entity. When a logical model shows the same data element
Data Madding Practice Paper 37
-------
OS WER Directive #902S.00c
in more than one data entity we may have data redundancy, which diminishes data
integrity. Sometimes, however, two data elements have inappropriately been given
the same name, such as "name" or "date". The two data elements actually represent
different data and should be given more descriptive names.
Figure 14. Logical ERD Example with Data Elements
EPA
Organization
Overseen
by
Oversees
6
/K
Cleanup
Contract
Site
Site Number (PK)
Srte Name
Site Street Description
Srte City Name
Site State Code
Site Zip Code
Site Longitude/Latitude Measurement j
Stte Contact Name
Site Contact Phone
Site Description
etc.
PK
FK:
measured by
Cleanup
Contract
Contract Number (PK)
EPA Organization Code (FK)
Contractor Number (FK)
Effective Date
Termination Date
Funding Source Name
Provisions Description
etc.
Spill Sample
Chemical
Substance
Location of
Agrees to
Source of
Contains
Primary Key
Foreign Key
Chemical
Substance in
SpiH Sample
We want to build a model such that each data element is found in only one
place - a particular data entity. If we build our data models, starting with the
38
Data Modeling Practice Paper
-------
OS WER Directive #9028.OOc
conceptual model and evolving to a logical data model, such that we always keep
this fundamental principle in mind, the resulting logical design will automatically
be highly normalized.
Normalization is "the decomposition of more complex data structures
according to a set of dependency rules/ designed to give simpler, more stable
structures."4 The objective of normalized data structures is that each and every data
element in a data entity should be determined by the identifier (and only by the
identifier) of the entity. Thus, it must be the case that knowing the value of the
unique identifier is enough to determine the values of the other data elements for a
given occurrence of an entity.
Normalization results in the creation of many more data entities in the
logical model than exist in the conceptual model. The conceptual data model for an
enterprise will typically have between 30 and 50 data entities, whereas the logical
model can have hundreds.
There are many books on data modeling and data normalization. Art article
which is frequently passed around in the industry is from IBM Corporation,
entitled, A Simple Guide to Five Normal Forms in Relational Database Theory. The
six page article provides a thorough description of data normalization.
In general, models that are not normalized typically have these (and
potentially other) undesirable characteristics:
Data elements are placed in data entities which have no unique
identifier and/or there are repeating groups in the entity. A repeating
group is the notion that the entity can have an indeterminate number
of data elements for a given occurrence. For example in Figure 15, if a
Customer can have an indeterminable number of locations and we
show customer location as a data element in a Customer entity, the
entity is not considered to be normalized. Fulling out Customer
Location and relating it to the Customer entity would serve to
normalize the data in this case.
Data elements are placed in entities which are identified bv only part of
the unique identifier. For example, suppose we have two data entities
as in Figure 15, invoice and invoice item, such that an invoice is
related to many invoice item. The data is not normalized if we store
invoice date in an invoice item entity (which has a unique identifier of
two data elements: invoice number and invoice item number), since
invoice date is identifiable by only the invoice number. Thus invoice
item number is not needed to identify the invoice date. In this case,
4Quote from James Martin, a pioneer in Information Engineering Methodology
Data Madding Practice Paper 39
I
-------
OSWER Directive #9028.00c
invoice date should be a data element of the invoice and not the
invoice item entity.
Data elements are placed in entities which are identified by a data
element in the entity other than the unique identifier. For example,
the data in Figure 15 is not normalized if we store chemical code and
chemical name in a spill sample entity. Since chemical name is
identified by chemical code and not the identifier of the spill sample,
another entity called chemical should be defined to store chemical
name. Then, the two entities, spill sample and chemical can be related
with a data relationship.
Figure 15. Examples of Non-normalized Data Entities
VtoteUon of Ftat Nonrni Form <1 NF)
CUBfOrmr
Customer Name
Customer Location 1
Customer Location 2
Customer Location 3
Customer Location n
Vtototton of Socond Nornwl rofin (2NF)
Vtotetton of Third Normal Rxm (3NF)
bwoice Number
CuBtomar Number
hwoio. Number and
Product Number
Quart*
Soft Sample
^n
i
i
f
>
BB>
V
Chemical
SamptolO
DMIIMNK
dttm ttumtnt et
5^iiS«n>*fc«f
itvMttMSNf.
ff«/*dUndantto
Chairtral Code
Other Oela
Torfdn/
AAvfM^ iff tfiw
The three anomalies described above correspond to three normal forms.
When a data model has been normalized to remove each of the three anomalies
above, the data model is said to be in either 1st, 2nd, or 3rd normal form. Thus if
the first anomaly is removed (a unique identifier exists and there are no repeating
groups) the model is in first normal form, or INF. Likewise, if the model has been
normalized to meet the first two anomalies, the model is in 2NF. The model is in
3NF, or 3rd normal form, if all three anomalies are eliminated. The anomalies
40
D*t* Modeimf Practice Paver
-------
OSWEJ? Directive W028.00c
associated with the three normal forms can be remembered with the phrase: The
key, the whole key, and nothing but the key.
5.13. What are Primary and foreign Key Identifiers?
Primary key (PK) and foreign key (FK) identifiers are terms typically used
when referring to a physical data base design, but they help our understanding of
logical data base design. Primary key identifiers (or simply primary keys) are really
just the unique identifiers described earlier. A primary key is one or more data
elements which ensure that a given occurrence of a data entity is unique across all
occurrences of the data entity. For example, the primary key of employee might be
social security number.
Thus far, we have stated that one of the cardinal rules of a logical data model
is that no data redundancy exists. While in the logical model, this remains true, in a
physical model it may not. This is due to the way in which data relationships are
represented in a logical model versus the way they may be represented in a physical
design. Some data redundancy may exist in implementing data relationships. Data
relationships are sometimes implemented in a data base through the use of primary
and foreign keys. It is through primary and foreign keys that data is accessed in a
relational data base.
Although there are other types of data bases, relational data bases are
described here because they more easily demonstrate how the relationships defined
in a logical model can be implemented. Instead of using primary and foreign key
identifiers, some physical data bases use physical file pointers. However, since
physical design is not the purpose of this paper, we will focus on logical design.
To illustrate how primary and foreign keys work. Figure 16 depicts a prior
example used in this paper. In order to know which facility is the workplace for a
given employee, we must know the identifier of the facility that corresponds to the
employee. If we physically stored a facility identifier within each employee record of
the physical data base, we could (1) locate the employee we are interested in,, (2) get
the facility number in his/her record, and then (3) locate the exact facility in the
facility entity, using the facility number, and find out about the facility's address,
name, etc
Date Madding Pruticejtps.' 41
-------
OSWER Directive #9028.OOc
Figure 16. Primary and Foreign Keys
Employee Number (PK)
Facility ID (FK)
mploy««
v Wbrteat
\o II
>>u \\
' Workplace of
Facility
Facility 10 (PK)
Similarly, if we wanted to know all of the employees working at a given
facility, we could find all of the employees that had the facility identifier we were
interested in by examining the facility identifier in the employee data. The facility
identifier in the employee data is known as the foreign key identifier (or simply
foreign key) and is a form of data redundancy in a relational data base.
5.2. NAMING DATA ELEMENTS
Data element naming is one of the on-going issues in the data standards
discipline today. While there is no de facto standard for naming data elements,
there are a set of practical techniques for developing names for data elements. One
organization, the National Institute for Standards and Technology (NIST)
developed standards for naming data elements. The concepts from the NIST
standard are incorporated into OSWER's standards, except for the generic element
concept. Generic elements are discussed briefly within this section.
It is expected that naming data elements will be done with greater precision
than data entities, since users relate mostly to specific data elements than data
entities, which are often too abstract for many users to want to deal with. As the
system development effort progresses into design and development it will be critical
for analysts to quickly identify data elements involved in business transactions,
screens, programs, and reports. Also after the system is operating, users will enter
data at the data element level. Using quality data names in the definition and
design process can make understanding the system easier for users as well,
particularly when users are provided with a data dictionary for the system.
5.2.1. Does a Data Element Only Have One Name?
Data elements will have more than one name, but should have one primary
name. The need for multiple names stems from the intended use of the data
elements. Different users typically have their own terminology for data elements.
Thus for documentation purposes, each data element may have synonym names
corresponding to different user terminology. However, there should still be a single
standardized name.
42
Data Modeling Practice Paper
-------
OS WE/? Directive *9028.00c
In addition, since data bases have different constraints on the length and
format of a data element name, we can create different names targeting the potential
implementation of a data element within different physical data bases. For example,
in the COBOL programming language a data element name can be 32 characters,
whereas many PC-based data bases restrict the name to eight characters. Once
defined, however, the name can be used in a consistent manner for each type of
physical data base that the element is found in. The use of standardized names
makes future data element analysis and tracking much simpler.
5.2JL How Do You Construct the Data Element Full Name?
The primary data element name, called the Full Name, is constructed by
concatenating several key words together to form a meaningful data element name.
Each Full Name should be comprised of:
Data Entity Nairn * Descriptors) 4- Class Word
The Data Entity Name is simply the name of the entity that the data element
is describing; the Descriptors) are words which describe the data element itself; and
the Class Word indicates the types of valid values (also called the domain) of the
data element
Examples of class words are number, date, flag; code, percent, etc. Class words
are placed at the end of the data element name to provide a quick understanding of
the type of data that a given data element represents. Figure 17 shows a complete
list of the valid class words for OSWER.
The following are examples of data element names:
Data Element Data Element Name
first name of an employee Employee First Name
date a shipment is received Shipment Receipt Date
whether or not employee can receive Employee Overtime Flag
overtime pay
estimated cost of cleanup activity Cleanup Activity Estimated Cost
Amount
Using the last data element above as an example, Cleanup Activity Estimated
Cost Amount, the components of the name are as follows: Cleanup Activity in the
Data Entity Name, Estimated Cost are the Descriptors, and Amount is the Clas«>
Word.
Data Modeling Practice Paper 43
-------
OS WER Directive *9028.00c
The three components are useful when reviewing data elements, since they ,
clearly describe the nature of the data element. The data entity name provides a
high-level framework for understanding what data element is being described. The
descriptors qualify the data meaning. The class word provides a consistent way to
indicate what kind of values-are expected in the data element.
The National Institute of Standards and Technology (NIST) also includes the
concept of generic elements. Generic elements, like data elements, include the
descriptors and class words, such as first name, state code, or account name. Thus
generic elements exclude the data entity name to formulate a generic version of the
data element having common characteristics, such as its valid values. For example,
the list of valid state codes is common to all state code data elements, such as
Employee State Code, Facility State Code, and Site State Code.
Figure 17. Data Element Class Words
CLASS WORD
ABBREV-
IATION
DEFINITION
Amount
AMT
Numeric value expressed as a quantity of
monetary currency
Code
CD
Character or string of characters used to represent
something in abbreviated form
Date
DT
Characters representing a fixed period of time,
such as month, day; and/or year; note that for data
elements representing only part of a date, the
name still uses the Date class word
DSC
Characters describing something using textual
information
Character or string of characters representing a
condition when there are only two possible
conditions for the value of the element (e.g., yes
or no); when more than two conditions can exist,
use Indicator below
Indicator
IND
Character or string of characters describing more
than two possible conditions for a data element
(e.g., short, medium, or long); if only two
conditions can exist, use Flag above
-------
OS WER Directive #9028,OOc
Figure 17 (continued). Data Element Class Words
CLASS WORD
Measurement
Name
Number
Percent
Quantity
Ratio (or Rate)
Time
Volume
Weight
ABBREV-
IATION
MEAS
NAM
NO
PCT
QTY
RAT
TM
VOL
WT
DEFINITION
Numeric value obtained by measurement such as
in miles, feet, inches, etc; can be used foir
measurements of height width, depth, etc.
Characters representing the name of something,
such as for a person, place, or thing
Numeric value representing a unique occurrence
of something (e.g., a part serial number)
Numeric ratio of two numbers x 100
Numeric value representing how much of
something; for monetary quantities use Amount
Numeric value representing the quotient of two
numbers
Characters representing time in any dimension,
such as in seconds, minutes, hours, etc.
Numeric value expressing bulk or cubic
measurements; used for measuring quantity of
liquids or solids
Numeric value of mass of something, such as in
tons, pounds, ounces, etc.
5.Z3. How are Abbreviated Data Element Names Created?
Abbreviated names are created from the full name by abbreviating each word
in the full name to a three-character code. Each abbreviation used should be
documented in a table showing the abbreviation, the full word name, and a brief
one or two-line definition of the word. Each time a word is to be abbreviated, the
table should be checked to see if an abbreviation already exists for the word. At
present OSWER does not manage a standard set of abbreviations. However,
standard abbreviation guidelines will be considered by the OSWER Information
Management staff in the future.
Data Madding Prtctiee Ptper
45'
-------
OSWER Directive #9Q28.QOc
It is likely that some words will use the same three-character code since it will
be difficult to create unique abbreviations across all possible names. For example,
the abbreviation ACT might represent Activity, Action, Actual, or Act. Although a
better set of abbreviations might be ACY for Activity, ACN for Action, ACL for
Actual, and ACT for Act. In any event, the resulting abbreviated data element name
should always be a unique name across all data elements. Class word abbreviations
are provided in Figure 17 above.
53. DESCRIBING DATA ELEMENTS
As with data entities, the name of a data element is not enough to understand
its precise meaning. Therefore as part of a complete data model, each data element
should be defined with a set of properties to document its precise meaning and
other information about the data element. Figure 18 lists the properties used to
define data elements.
Figure 18. List of Properties for Defining Data Elements
Aliases Documentor Name
Class Word Edit Criteria
COBOL Picture Effective Date
Comments Format
Data Capture Method Frequency of Update
Data Collector Full Name
Data Custodian Keywords
Data Definer Length
Data Steward Originating Source
Data User Security
Derivation Rules Valid Values
Description Version Number
Display Label
The properties for each data element are completed during the Definition and
Design stages of the SLC, as the specific requirements for the data element are
defined. Some revisions to the properties are inevitable during the Development
stage as well. Note that there are several different properties for naming a data
element as discussed in the previous section. Special attention should be given to
providing a dear Description of the data element, since it is this property that will be
used most often when communicating the entity's meaning to others. The
properties are described in detail in Appendix C.
46 Data Modeling Practice Paper
-------
OS WER Directive *9028.00c
Hgure 19 indicates when each property should be completed and revised
during the SLC for a given data element. Note that revising data element: properties
during the SLC takes the form of changing values from a prior stage and completing
properties where no value was provided in a prior stage. The guidance in Figure 19
is merely a suggested approach towards defining the data during the SLC If
properties are known earlier in the SLC, they can be completed prior to the stages
indicated in the figure.
Appendix C provides a complete set of definitions for each of the above
properties. Special attention should be given to completing the Description
property, since it is this property which will be used most often when
communicating the data element's meaning to others.
Data Madding Practice Paper 47
f
-------
OS WE/? Directive *9028.00c
Figure 19. Data Element Property Completion Matrix
PROPERTY
Aliases
Class Word
COBOL Picture
Comments
Data Capture
Method
Data Collector
Data Custodian
Data Definer
Data Steward
Data User
Derivation Rules
Description
Display Label
Documentor Name
Edit Criteria
Effective Date
Frequency of
Update
Format
Full Name
Keywords
Length
Originating Source
Security ;
Valid Values
Version Number
DEFINITION
STAGE
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
DESIGN STAGE
R
C
R
R
R
R
R
R
R
R
R
R
C
R
R
DEVELOPMENT
STAGE
R
R
R
R
R
R
R
Key to Table C means Complete data element property
R means Revise data element property
-------
OSWER Directive #902fi.00c
6. CHANGING THE MODELS
When a project team member makes a change to a data entity, data entity
relationship or data element definition, it is critically important that the changes be
made based on a pre-defined set of procedures. These procedures are commonly
referred to as Configuration Management (CM) or Change Control, which is
described in another OSWER practice paper entitled Configuration Management.
The benefits of Configuration Management procedures are documented in that
practice paper, but several benefits outlined in the paper are that CM:
Helps ensure clear identification and documentation of functional and data
requirements;
Helps ensure that all approved requirements are traceable through the system
design;
Helps ensure that an adequate review of requested changes to the system, and
approval by an authorized organization and individual, takes place before the
system is actually changed; and
Provides a means to reconstruct the evolution of the system, and rationale for
significant decisions, through the prior phases and stages of the system life
cycle.
Any changes should be made with the appropriate people notified.
Sometimes the nature of the change is not critical and may only involve the project
team itself. However, for many other changes to the design, change requests; must
be presented to a board of individuals, typically called a Configuration Management
Board.
Changes need to logged to provide an audit of prior decisions made and to be
able to regress the design to prior versions of data elements if necessary. Thus if the
meaning of a data entity or data element is revised, a new version should be
established and the old version should be archived. As indicated by the list of
properties for data entities, data entity relationships, and data elements, a version
number should be updated sequentially and an effective date should be completed
for each update to an entity, relationship, or element.
Data Modeing Practice Paper 49
-------
This page intentionally left blank
-------
OSWER Directive #9028.00c
7. CONCLUSION
7.1. WHEN IS THE MODEL "RIGHT?
In the Concept Phase of the SLC, the focus should be on comprehending the
high-level data requirements. The way in which the conceptual model is structured
may change during Concept, and even during subsequent phases of the SLC. This is
a normal refinement process during analysis and should be expected.
While there may be some known "holes" in the conceptual model, filling
some of these holes can be deferred until Definition. The recommendation, then, is
to have a reasonable level of comfort that the conceptual model represents the high-
level requirements accurately and that issues are identified. At the same time it
may be useful to define some entities in a conceptual model that would typically be
found in a logical model. This does not "break any rules", particularly if it provides
a better understanding of the data at the data entity level.
Remember that data modeling, like any analysis discipline, is an iterative
process. This means that changes will be made over time to the model. Team
members must appreciate this and not presume that any decision is "final" or that it
is a life or death commitment. Change is natural and is expected. When confronted
with a difficult data modeling issue, it is often best to take a position, document it,
make an issue of it for resolution, and move on. This will also make for better
working sessions, since each session will be less frustrating and more productive.
7.2. "MANAGF' ISSUES
While we encourage a fair amount of discipline in this technique, not all
issues are worth battling over, especially when they might adversely affect the
project schedule. As data modeling issues are uncovered, make it a point to manage
a list of outstanding issues and see to it that each issue is dealt with, perhaps with a
smaller group of project personnel. A smaller group may be able to investigate the
issue and return to the larger group with a recommendation for its resolution. In
general, then, don't belabor issues to the point that severe frustration and time
wasted affects the groups productivity.
73. PRESENTING A DATA MODEL
Be sensitive to the audience that will review your models. A simple
conceptual model is often better for presentation, particularly to management, than
a detailed and often cluttered logical model. For certain presentation needs, it may
be better to divide the logical model into manageable pieces to present coherent
components of the model in a focused manner. Try to divide the model into groups
Data Modeling Practice Pgper 51
-------
OS WET? Directive #9028.OOc
of data entities that are related functionally and are all connected with data
relationships (i.e., no disconnected data entities).
Also, presenting a data model may be the wrong approach. Not everyone will
fully understand the model, unless there is ample time spent in the beginning of
the presentation to walk through enough examples and to define the diagram
notation for the audience. Within a project team, however, data models should
almost always be used to document and communicate data requirements. Therefore
each team member should be "educated" at least to the point of knowing how to
read an ERD.
7.4. DATA MODELING EXPERTISE
This paper introduced an integrated set of logical design topics, all of which
are important for building quality conceptual and logical data models.
Unfortunately it is not enough to simply read this material and become an "expert"
in data modeling.
We recommend that when embarking on a data modeling project or task, an
experienced individual is consulted for advice and training. Expertise comes with
doing and is reflected in data models of higher quality and durability. Also
remember that any data modeling expert can not replace the expertise of the
business, which is what a data model is based on. Thus it is also important that data
modeling be led by programmatic-oriented experts (sometimes called business
analysts), and not by systems analysts or programmers.
52 * Data Modeling Practice Paper
-------
APPENDICES
-------
This page intentionally left blank
-------
OSWER Directive #902S.OOc
APPENDIX A: DATA ENTITY PROPERTIES
Appendix A describes each of the properties used to define a data entity. Each
property is described with a brief definition, an indication as to when to complete
the property (recall that Figure 9 is a table which also indicates when these
properties should be completed during the SLC), usage information, and one or two
examples to clarify the use of the property.
The properties are organized into categories, as follows:
Identification
Full Name
Synonyms
Identifiers
Definition
Average Occurrences
Comments
Data Collector
Data Custodian
Data Definer
Data Steward
Data User
Description
Examples
Growth Rate
Maximum Occurrences
Minimum Occurrences
References
Security
Configuration Management
Documentor Name
Version Number
Effective Date
The properties above are presented in alphabetic order.
Data Modeling Practice Paper A-l
-------
OSWER Directive #902S.OOc
AVERAGE OCCURRENCES
Definition - AVERAGE OCCURRENCES is an estimate of the average number of
occurrences that the data entity would be likely to have at any given point in time.:
Requirement - Refer to the MINIMUM OCCURRENCES property for requirement
information.
Usage - Refer to the MINIMUM OCCURRENCES property for usage information.
Examples - "100"; "100,000"; "10,000,000"
COMMENTS
Definition COMMENTS are used to qualify any other information about the data
entity not covered by the other properties.
Requirement - COMMENTS should be used, if needed, for conceptual and logical
data model entities during the Concept Phase and Definition Stage of the SLC.
Usage - COMMENTS might be useful to indicate current issues that are outstanding
for a given data entity. Once the issue is resolved, the resolution also can be entered
in the COMMENTS. Thus an audit of data entity issues and their resolution can be
maintained in the data entities themselves.
Examples - For a Site entity:
"Currently it is not known if Site and Facility are the same data entity or not.
For now these two are being treated as the same entity using this entity for
both."
DATA COLLECTOR
Definition - DATA COLLECTORS are the organizations responsible for collecting the
values of data required by an OSWER program.
Requirement - DATA COLLECTOR should be identified in the Concept Phase for
conceptual model entities, if known, and completed by the Definition Stage for
entities created in either the conceptual or logical data models.
Usage - Identify one or more organizations which actually collect the data. The data
collection is not necessarily via automated information systems. Thus, an
A-2 - Data Modeling Practice Paper
-------
OSWER Directive #902«:00c
organization using paper forms to collect data is a valid DATA COLLECTOR.
Examples * I'OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DATA CUSTODIAN
Definition - DATA CUSTODIANS are the organizations responsible for supporting
the storage and processing of data, and ensures the physical integrity of data used to
support OSWER missions while providing access to the users.
Requirement - DATA CUSTODIAN should be identified in the Concept Phase for
conceptual model entities, if known, and completed by the Definition Stage for
entities created in either the conceptual or logical data models.
Usage - Identify one or more organizations which store the data. The storage of data
is not necessarily via automated information systems. Thus an organization using
paper files as storage is a valid DATA CUSTODIAN.
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DATA DEFINER
Definition - DATA DEFINER is the organization responsible for determining and
documenting the requirements, meaning, and content of data, e.g., name,
description, and other properties, needed to support OSWER's mission.
Requirement - DATA DEFINER should be identified in the Concept Phase for
conceptual model entities, and completed by the Definition Stage for entities created
in either the conceptual or logical data models.
Usage - The organization defining the data entity should be entered as the Data
Definer. The DATA STEWARD selects the DATA DEFINER, which in most cases is
the primary DATA USER.
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples'
indicate, but should always be at the lowest possible level).
Data Modeling Practice Paper A-3
-------
OSWER Directive #9028.00c
DATA STEWARD
Definition - DATA STEWARD is the organization which requires the data
represented by the data entity to be collected, processed, stored or used in support of
OSWER's mission. The DATA STEWARD'S responsibilities include ensuring that:
"Data are clearly defined and documented in compliance with established
directives. Data that is collected is of sufficient quality to support OSWER's
missions. Only data relevant to OSWER's missions is collected. Data is
reused wherever appropriate within OSWER. Data management practices for
data under the organization's stewardship conform to OSWER guidance."5
Requirement - DATA STEWARD should be identified in the Concept Phase for
conceptual model entities, and completed by the Definition Stage for entities created
in either the conceptual or logical data models.
Usage - DATA STEWARD is typically the organization the defines who the other
data management organizations (Data Definer, Data Collectors, Data Users, and Data
Custodians) are for a given entity.
Examples - "OSWER AA"; "OERR"; "OSW"; "OWPE"; "OUST'
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DATA USER
Definition - The DATA USERs are the organizations that use/access the data in
some way. Usually there is one primary DATA USER (which is the DATA
DEFINER in most cases).
Requirement - DATA USER should be identified in the Concept Phase for
conceptual model entities, and completed by the Definition Stage for entities created
in either the conceptual or logical data models.
Usage - Identify one or more organizations which use the data. Because the use of
data is not necessarily via automated information systems, an organization using
paper forms to process data is a valid DATA USER. Note that moving forms
around is not considered processing; only organizations that perform business
activities with the data are considered DATA USERs.
5From the Practice Paper for Data Management During the System Life Cycle
A-4 * Data Modeling Practice Paper
-------
OSWER Directive #902S.OOc
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DESCRIPTION
Definition - DESCRIPTION is an accurate, concise and unique textual narrative of
the programmatic meaning of the data entity.
Requirement - Every data entity should have a DESCRIPTION when the data entity
is created in either the conceptual or logical data model.
Usage - The DESCRIPTION property should describe what the entities are, not what
they are for or how they are used. Descriptions should be brief and to the point.
Avoid using examples in the DESCRIPTION (EXAMPLES are a separate property of
the entity definition). When describing a data entity, think of the scope of wliat the
entity is (person, place, thing, organization, concept, or event) and define the entity
with that in mind. Then qualify the scope as necessary to further illustrate the
entity's meaning (see Examples below). Typically, the qualification of the scope
alludes to the kind of data relationships the entity has with other entities.
Examples - Scope: "A Consumer Customer is a person
Qualification: who has an agreement with XYZ
Company to buy products and/or
services."
Scope: "A Chemical is a material
Qualification: produced by or used in an industrial
activity at a site."
Note that it is not necessary to include the words "scope" and "qualification" in the
DESCRIPTION.
DOCUMENTOR NAME
Definition - The person who records the information about the data entity for the
current VERSION NUMBER of the data entity.
Requirement - Each version of the data entity should have the DOCUMENTOR
NAME entered.
Usage - The DOCUMENTOR NAME provides an audit trail of who updated the data
entity information for the VERSION NUMBER and EFFECTIVE DATE specified.
Since each update will result in a new data entity version, each version needs only
Data Modeling Practice Hapcr A-5
-------
OSWER Directive #9028.00c
one DOCUMENTOR NAME.
Examples - For a given entity:
"Joe Smith, OERR"
EFFECTIVE DATE
Definition - The date that this version of the data entity is valid for, generally the
date the information is documented.
Requirement - An EFFECTIVE DATE should be provided with each new version of
the data entity, as indicated by the VERSION NUMBER.
Usage - The EFFECTIVE DATE corresponds to the VERSION NUMBER and the
DOCUMENTOR NAME. This date should not be updated on prior versions, but
only provided for each new version of the data entity.
Examples - For a given entity:
"9/5/91"
EXAMPLES
Definition - The EXAMPLES are specific sample occurrences of a data entity.
Requirement - EXAMPLES should be identified in the Concept Phase for conceptual
model entities, if known, and completed by the Definition Stage for entities created
in either the conceptual or logical data models.
Usage - Use EXAMPLES to support the meaning of the data entity. Examples always
help a reader understand a subject.
Examples - For a Chemical entity:
"Hydrochloric Acid"; "Sulfur Dioxide"; and "Water"
FULL NAME
Definition - FULL NAME is the full unabbreviated name of the data entity.
Requirement - Every data entity should have a FULL NAME when the data entity is
created in either the conceptual or logical data model.
A-6 " Data Modeling Practice Paper
-------
OSWEK Directive #902«.00c
Usage - The FULL NAME should not contain abbreviations. Refer to the Data
Entities section for naming considerations.
Examples - "Manufacturing Facility Production Unit" and not ''Mfg Facil Prodn
Unit"
or
"Retail Clothing Customer Invoice" and notJ'Retail Cloth Cust Inv"
GROWTH RATE
Definition - GROWTH RATE is an estimate of the rate at which the volume of
occurrences will grow over time.
Requirement - Refer to the MINIMUM OCCURRENCES property for requirement
information.
Usage - Refer to the MINIMUM OCCURRENCES property for usage information.
Examples "10 per day"; "1000 per week"; "100,000 per year"
(Note that any time dimension is permitted, such as hour, day, week, or year.)
IDENTIFIERS
Definition - An IDENTIFIER is a collection of one or more data elements which
when combined together serve to uniquely identify an occurrence of a data entity.
Requirement - As part of defining a data entity one or more IDENTIFIERS should be
provided. However, sometimes even after a data entity has been established in the
Concept stage, it is unclear what the identifier will be. During the Definition stage
all data entities should have a unique identifier.
Usage - An identifier should be established to absolutely guarantee uniqueness.
When defining IDENTIFIERS, try to determine the natural IDENTIFIERS first. The
IDENTIFIERS should also be documented as data elements (which describe the data
entity). Refer to the Data Elements and Data Element Properties sections for
documenting data elements.
Examples - Unique identifiers for a regulated Power Company data entity:
Identifier 1: Customer Name + Customer Address
(name and address because more than one company may have the same name, but
not at the same place)
Identifier 2: Customer Number
(an internally used number for identifying Power Companies)
Data Modeling Practice Paper . A-7
-------
OSWER Directive #9028.OOc
Or for a Chemical data entity:
Identifier 1: Chemical Code
(a universally accepted code used to identify chemicals)
MAXIMUM OCCURRENCES
Definition - MAXIMUM OCCURRENCES is an estimate of the maximum number
of occurrences that the data entity would be likely to have at any given point in
time.
Requirement - Refer to the MINIMUM OCCURRENCES property for requirement
information.
Usage - Refer to the MINIMUM OCCURRENCES property for usage information.
Examples - "100"; "100,000"; "10,000,000"
MINIMUM OCCURRENCES
Definition - MINIMUM OCCURRENCES is an estimate of the minimum number of
occurrences that the data entity would be likely to have at any given point in time.
Requirement - MINIMUM OCCURRENCES is not generally populated until the
Definition Stage, but can be completed or revised in the Design Stage.
Usage - MINIMUM OCCURRENCES should be used as part of the Definition Stage
of the SLC to provide enough input for a quality physical data base design. This
information also complements the logical design by describing the sheer magnitude
of the data to be collected, processed, etc. A data base designer/administrator
translates the logical design into physical records (although not necessarily one-for-
one; it depends upon how the physical design is implemented). For instance, for
high contention files, the data base designer/administrator might want to partition
the physical file or denormalize files to improve system performance. These and
other related data base design decisions are based on various data volume estimates,
such as MINIMUM OCCURRENCES.
Examples - "Zero"; "100"; "100,000"
REFERENCES
Definition - REFERENCES are any sources of information that help to define the
data entity. .
A-8 - Data Modeling Practice Paper
-------
OSWEK Directive #902,J.OOc
Requirement - REFERENCES should be identified in the Concept Phase for
conceptual inodel entities, if known, and completed by the Definition Stage for
entities created in either the conceptual or logical data models.
Usage'- Use REFERENCES particularly in cases where a very specific source of
information was used to define a data entity.
Examples - "ABC Codebook"; "XYZ User Documentation Manual"; "Quarterly
Financial Report"
SECURITY
Definition - SECURITY is any information about the potential sensitive nature of
the data represented by the data entity.
Requirement - SECURITY should be completed in the Definition Stage of the SLC.
If no security restrictions apply to a data entity, identify this as well. For example,
use the word "None" to document this fact.
Usage - SECURITY may only exist for a subset of the data that the entity represents.
Use the property to describe which types of data may be sensitive or if sensitive for
certain users or certain circumstances. (Note that security information is also
included as part of describing data elements.)
Examples - For an Employee entity:
"This entity contains sensitive information about salary. Edit routines will be
required to only allow employees in personnel with a to-be-defined security
class to create, modify, or peruse this information."
SYNONYMS
Definition - The SYNONYMS are other names for the entity that some
organizations use.
Requirement - SYNONYMS should be identified in the Concept Phase for
conceptual model entities, if known, and completed by the Definition Stage for
entities created in either the conceptual or logical data models.
Usage - Use SYNONYMS to clarify the meaning of a data entity, particularly where
different organizations have different names for the same thing. The "official"
name should be standardized and most meaningful, whereas the SYNONYMS are
not necessarily so.
Data Modeling Practice Paper A-9
-------
OSWER Directive #9028.OOc
Examples - For a Chemical entity:
"Chemical Substance"; "Chemical Compound"; "Compound"; and "Constituent
Material"
VERSION NUMBER
Definition - The VERSION NUMBER is a sequential number corresponding to the
number of the update to the data entity.
Requirement - A VERSION NUMBER should be provided for each new version of
the data entity.
Usage - When the data entity is first defined, the VERSION NUMBER should be "1".
After each change to the definition or other properties of the data entity, the
VERSION NUMBER should be incremented by 1 for each new version. Each time
the VERSION NUMBER is updated (including the first time the data entity is
defined), an EFFECTIVE DATE and DOCUMENTOR NAME should be provided as
well. Also, version numbers should always be whole numbers, i.e., "1", "2", "3",
etc., and not "2.3" or "1.15".
Examples - For a given entity:
A-10 ' ' * Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
APPENDIX B: DATA RELATIONSHIP PROPERTIES
.*£._,., -
Appendix B describes each of the properties used to define a data relationship.
Each property is described with a brief definition, a note on its requirement, usage
information, and one or two examples to clarify the use of the property.
The properties are grouped into three categories, as follows:
Identification
From Entity
m To Entity
Relation From Name
Relation To Name
Definition
Business Rule Description
Maximum From Occurrences
Maximum To Occurrences
Minimum From Occurrences
Minimum To Occurrences
Average From Occurrences
Average To Occurrences
Comments
Configuration Management
Documentor Name
Version Number
Effective Date
For most of the data relationship properties, refer to Figure 20 to see how the
properties are illustrated on an Entity Relationship Diagram (ERD). The properties
above are presented in alphabetical order.
Data Modeling Practice Paper B-l
-------
OSWER Directive #9028.OOc
Figure 20. Entity Relationship Components
Minimum From Occurrences
Minimum To Occurrences
Relation From Name
From
Entity
Relation To Name
Maximum To Occurrences
Maximum From Occurrences
AVERAGE FROM OCCURRENCES
Definition - The AVERAGE FROM OCCURRENCES is an estimate of the number of
From Entity occurrences, on average, for a single occurrence of the To Entity.
Requirement - Average occurrences should be provided only to support a
specialized technical analysis, called transaction volume analysis. This is usually
performed in the latter portion of the Definition stage (pre-design), but may be done
even during the Concept stage.
Usage - Average occurrences are used to approximate the amount of data that is
involved with a particular system activity, such as Validate an Emission
Submission, or Post General Ledger Accounts. Average occurrences provide
assumptions for how many relationships are involved, on average, from one entity
to another. Thus using the minimum or a maximum for sizing purposes is not
desirable, since those two numbers are extreme values needed for defining lower
and upper bounds on requirements.
Examples - For a relationship between Customer Order and Product:
Customer Order contains an average of 5 Products
Or for a relationship between Spill Sample and Chemical:
Spill Sample contains an average of 10 Chemicals
B-2
Data Modeling Practice Paper
-------
OSWEJ? Directive #9028.00<:
AVERAGE TO OCCURRENCES
Definition rJThe AVERAGE TO OCCURRENCES is an estimate of the number of To
Entity occurrences, on average, for a single occurrence of the From Entity.
Requirement - Average occurrences should be provided only to support a
specialized technical analysis, called transaction volume analysis. This is usually
performed in the latter portion of the Definition stage (pre-design), but may be done
even during the Concept stage.
Usage - Average occurrences are used to approximate the amount of data that is
involved with a particular system activity, such as Validate an Emission
Submission, or Post General Ledger Accounts. Average occurrences provide
assumptions for how many relationships are involved, on average, from one entity
to another. Thus using the minimum or a maximum for sizing purposes is not
desirable, since those two numbers are extreme values needed for defining lower
and upper bounds on requirements.
Examples - For a relationship between Customer Order and Product:
Product contained on an average of 1.000 Customer Orders
Or .for a relationship between Spill Sample and Chemical:
Chemical contained on an average of 10.000 Spill Samples
BUSINESS RULE DESCRIPTION
Definition - The BUSINESS RULE DESCRIPTION is a textual explanation for the
relationship.
Requirement - A BUSINESS RULE DESCRIPTION should be provided to clarify the
business purpose for establishing a relationship, and under what conditions does
the relationship hold (and/or not hold).
Usage - Do not simply restate the relationship in a textual form. The BUSINESS
RULE DESCRIPTION should provide additional information about the
relationship.
Examples - For a relationship between Customer Order and Product:
A customer's request for a product must be documented with a Customer Order and
a relationship to at least one Product. An order without any products is not
considered to be an order and will hot be retained by the information system(s).
Data Modeling Practice Pgper B-3
-------
OSWER Directive #9028.00c
COMMENTS
Definition - COMMENTS are used to qualify any other information about the data
entity relationship not covered by the other properties.
Requirement - COMMENTS should be used, if needed, for conceptual and logical
data entity relationships during the Concept Phase and Definition Stage of the SLC.
Usage - COMMENTS might be useful to indicate current issues that are outstanding
for a given data entity relationship. Once the issue is resolved, the resolution also
can be entered in the COMMENTS. Thus an audit of data entity relationship issues
and their resolution can be maintained in the data entity relationship definitions
themselves.
Examples - For a relationship between Customer Order and Product:
"The current system only allows one product type to be assigned to an order. While
changing the relationship to many-to-many would change the way the organization
does business today, i.e., an order is for one product type only, the organization
would benefit from enhancing its customer service by allowing more than one
product to be assigned to a given order. This issue needs to be resolved."
DOCUMENTOR NAME
Definition - The person who records the information about the data entity
relationship for the current VERSION NUMBER of the relationship.
Requirement - Each version of the data entity relationship should have the
DOCUMENTOR NAME entered.
Usage - The DOCUMENTOR NAME provides an audit trail of who updated the d,ata
entity relationship information for the VERSION NUMBER and EFFECTIVE DATE
specified. Since each update will result in a new relationship version, each version
needs only one DOCUMENTOR NAME.
Examples - For a given data entity relationship:
"Joe Smith, OERR"
EFFECTIVE DATE
Definition - The date that this version of the data entity relationship is valid for,
generally the date the information is documented.
B_4 Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
Requirement - An EFFECTIVE DATE should be provided with each new version of
the relationship, as indicated by the VERSION NUMBER.
vi^V-
Usage - TriipFFECnVE DATE corresponds to the VERSION NUMBER and the
DOCUMENTOR NAME. This date should not be updated on prior versions, but
only provided for each new version of the data entity relationship.
Examples - For a given data entity relationship:
"9/5/91"
FROM ENTITY
Definition - The FROM ENTITY is the first entity in the pair of entities which have
a relationship between each other.
Requirement - Every relationship must specify a FROM ENTITY.
Usage - It does not matter which entity is considered the FROM ENTITY. The :
distinction between From and To entities are being made only to recognize that
there are two entities in every relationship and the relationship will have two .
names, one for the From-To direction of the relationship and the other for the To-
From direction.
Examples - For a relationship between Customer Order and Product:
Customer Order
Or for a relationship between Spill Sample and Chemical:
Spill Sample
MAXIMUM FROM OCCURRENCES
Definition The MAXIMUM FROM OCCURRENCES is the greatest number of
From Entity occurrences allowed for a single4 occurrence of the To Entity.
Requirement - Every data relationship should have MAXIMUM FROM
OCCURRENCES when the data relationship is created.
Usage - Always define occurrences with exceptions in mind. For example, even if it
is rare that a Customer orders more than one Product at a time, the MAXIMUM
FROM OCCURRENCES between Product and Customer should still be many.
Examples - For a relationship between Customer and Product:
Data Modeling Practice Paper B-5
-------
OSWER Directive #9025.00c
Product ordered by a maximum of Many Customer
t j*
Or for a relationship between Invoice and Invoice Item:
Invoice Item contained on a maximum of One Invoice
MAXIMUM TO OCCURRENCES
Definition - The MAXIMUM TO OCCURRENCES is the greatest number of To
Entity occurrences allowed for a single occurrence of the From Entity.
Requirement - Every data relationship should have MAXIMUM TO
OCCURRENCES when the data relationship is created.
Usage - Always define occurrences with exceptions in mind. For example, even if it
is rare that Employee is assigned to more than one Facility, the MAXIMUM TO
OCCURRENCES between Employee and Facility should still be many.
Examples - For a relationship between Customer and Product:
Customer orders a maximum of Many Product
Or for a relationship between Invoice and Invoice Item:
Invoice contains a maximum of Many Invoice Item
MINIMUM FROM OCCURRENCES
Definition - The MINIMUM FROM OCCURRENCES is the least number of From
Entity occurrences allowed for a single occurrence of the To Entity.
Requirement - Every data relationship should have MINIMUM FROM
OCCURRENCES when the data relationship is created.
Usage - Always define occurrences with exceptions in mind. For example, even if it
is rare that a Facility is not assigned any Employees, the MINIMUM FROM
OCCURRENCES between Employee and Facility should still be zero.
Also, keep in mind that a MINIMUM FROM OCCURRENCES of one or more (i.e.,
not zero) dictates that the From Entity must exist for a given occurrence of the To
Entity and that a relationship must be established between the two entities when the
To Entity is created. This may be too restrictive, especially if the To Entity is initially
defined independently of the From Entity.
B-6 Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
Examples - For a relationship between Customer and Product:
-t>-.:,
Product ordered by a minimum of Zero Customer
Or for a relationship between Invoice and Invoice Item:
Invoice Item contained on a minimum of One Invoice
MINIMUM TO OCCURRENCES
Definition - The MINIMUM TO OCCURRENCES is the least number of To Entity
occurrences allowed for a single occurrence of the From Entity.
Requirement - Every data relationship should have a MINIMUM TO
OCCURRENCES when the data relationship is created.
Usage - Always define occurrences with exceptions in mind. For example, even if it
is rare that an Employee is not assigned to any Facility, the MINIMUM TO
OCCURRENCES between Employee and Facility should still be zero.
Also, keep in mind that a MINIMUM TO OCCURRENCES of one or more (i.e., not
zero) dictates that the To Entity must exist for a given occurrence of the From. Entity
and that a relationship must be established between the two entities when the From
Entity is created. This may be too restrictive, especially if the From Entity is initially
defined independently of the To Entity.
Examples - For a relationship between Customer and Product:
Customer orders a minimum of Zero Product (note this assumes that Customer is
defined as anyone who might purchase a product)
Or for a relationship between Invoice and Invoice Item:
Invoice item contained on a minimum of One Invoice
RELATION FROM NAME
Definition - The RELATION FROM NAME is the textual description of the
relationship as read from one data entity to another. Figure 20 illustrates the
position of the RELATION FROM NAME, which is typically above the relationship
line (when the .entities are displayed horizontally) or to the right of the relationship
line (when the entities are displayed vertically).
Requirement - Every data relationship should have a RELATION FROM NAME
when the data relationship is created.
Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
Usage - It is probably best to make the RELATION FROM NAME the name of the
relationship in the active tense (see examples below). The active tense of phrases
are generally easier to come up with and are easier to understand when reviewing a
data model than are passive tense phrases (which are typically used in the
RELATION TO NAME).
Examples - For a relationship between Customer and Product:
"Places Orders for"
Or for a relationship between Employee and Expense Voucher:
"Submits"
RELATION TO NAME
Definition - The RELATION TO NAME is the textual description of the relationship
as read in the reverse direction of the RELATION FROM NAME.
Requirement - Every data relationship should have a RELATION TO NAME when
the data relationship is created.
Usage - It is probably best to make the RELATION TO NAME the name of the
relationship in the passive tense (see examples below), since the active tense of the
phrase will typically be the RELATION FROM NAME.
Examples - For a relationship between Customer and Product:
"Ordered by"
Or for a relationship between Employee and Expense Voucher:
"Submitted by"
Note that the above relationship names are in the reverse direction of the data
entities. "Ordered by" is describing the relationship between Customer and Product
in the reverse direction; Thus it can be read: Ftoduct ordered by Customer, or
Expense Voucher submitted by Employee.
TO ENTITY
Definition - The TO ENTITY is the first entity in the pair of entities which have a
relationship between each other.
B-8 Data Modeling Practice Paper
-------
OSWER Directive #9028.0()c
Requirement - Every relationship must specify a TO ENTITY.
Usage - It does not matter which entity is considered the TO ENTITY. The
distinction between From and To entities are being made only to recognize that
there are two entities in every relationship and the relationship will have two
names, one for the From-To direction of the relationship and the other for the To-
From direction.
Examples - For a relationship between Customer Order and Product:
Product
Or for a relationship between Spill Sample and Chemical:
Chemical
VERSION NUMBER
Definition - The VERSION NUMBER is a sequential number corresponding; to the
number of the update to the data entity relationship.
Requirement - A VERSION NUMBER should be provided for each new version of
the data entity relationship.
Usage - When the relationship is first defined, the VERSION NUMBER should be
"1". After each change to the definition or other properties of the data entity
relationship, the VERSION NUMBER should be incremented by 1 for each new
version. Each time the VERSION NUMBER is updated (including the first time the
relationship is defined), an EFFECTIVE DATE and DOCUMENTOR NAME should
be provided as well. Also, version numbers should always be whole numbers, i.e.,
"1", "2", "3", etc., and not "2.3" or "1.15".
Examples - For a given data entity relationship:
Data Modeling Practice Paper B-9
-------
This page intentionally left blank
-------
OSWEK Directive #9028.00c
APPENDIX C: DATA ELEMENT PROPERTIES
Appendix C describes each of the properties used to define a data element.
Each property is described with a brief definition, an indication as to when to
complete the property, usage information, and one or two examples to clarify the
use of the property.
The properties are presented in several categories, as follows:
Identification
Full Name
Aliases
Display Label
Keywords
Definition
Comments
Data Capture Method
Class Word
Data Collector
Data Custodian
Data Definer
Data Steward
Data User
Derivation Rules
Description
Edit Criteria
Format
Frequency of Update
Length
Originating Source
COBOL Picture
Security
Valid Values
Confi uration Management
Documentor Name
Version Number
Effective Date
The properties above are presented in alphabetical order.
Data Modeling Practice Paper C-l
-------
OSWER Directive #9028.00c
ALIASES
Definition - The ALIASES are (1) Other names, acronyms, and abbreviations for the
data element that different organizations use, or (2) Names for specific
programming languages, such as FOCUS, COBOL or ADABAS.
Requirement - ALIASES should be identified in the Definition Stage for the logical
data model.
Usage - Use ALIASES to clarify the meaning of a data element, particularly where
different organizations have different names for the same thing. Not every physical
name needs to be identified. However, as names are learned from studying existing
systems and from working with users, the names should be documented as
ALIASES. Note that ALIASES should not be invented; only define them where the
organization does in fact use more than name for the same thing.
When the target programming language is known, such as COBOL or FOCUS, a
COBOL or FOCUS name can be invented to provide a technical name for the data
element. The best names will be abbreviations of the data element FULL NAME.
By providing these names in the logical data model, less work will be required to
develop technical names later. Refer to COBOL, FOCUS, System 2000, ADABAS,
dBASE, and other target environment manuals for specific information on data
element formats.
If users have other names for the same data element, refer to those as General
ALIASES.
Examples - ALIASES used for different environments might look as follows for the
data element State Code:
Environment ALIASES
COBOL STATE-CODE
FOCUS ST-CDE
ADABAS NATURAL STATE-IDENTIFIER
dBASE STATE_CD
General (user ALIAS) STATE-ID
CLASS WORD
Definition - The CLASS WORD is the part of the data element name which
describes the contents of the data element. Refer to the Data Elements section for
information about data element CLASS WORDs.
C-2 Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
Requirement - Every data element should have a class word assigned, which is part
of the data element FULL NAME.
Usage - Refer to the Data Elements section.
Examples - For a Chemical Code:
"Code"
*.
Or for a Site Inspection Date:
"Date"
COBOLPICTURE
Definition - COBOL PICTURE is a COBOL representation of the format of a data
element (called a field in COBOL).
Requirement - The COBOL PICTURE is used when the target programming
language is known to be COBOL.
Usage - Use the standard COBOL picture clause notation found in a COBOL manual.
Examples - "PIC X(10)", "PIC 999V99"
»
COMMENTS
Definition - COMMENTS are used to qualify any other information about the data
element not covered by the other properties.
Requirement - COMMENTS should be used, if needed.
Usage - COMMENTS might be useful to indicate current issues that are outstanding
for a given data element. Once the issue is resolved, the resolution also can be
entered in the COMMENTS. Thus an audit of data element issues and their
resolution can be maintained in the data elements themselves.
Examples - For a Site Identification Number data element:
"Currently it is not known how the SIN will be constructed. One possible
solution will be to use a DUNS number appended by another sequential
number for making duplicate DUNS numbers unique."
Data Modeling Practice Payer ' C-3
-------
OSWER Directive #902S.OOc
DATA CAPTURE METHOD
Definition - DATA CAPTURE METHOD describes whether the data element is
entered into the system from an external source (such as a user or other agency) or if
the system will generate the data automatically.
Requirement - Every data element should have a DATA CAPTURE METHOD.
Usage - Specify the method is "Basic" if the data element is collected by data entry (or
fed from another system) and "Derived" if the element is generated, i.e., calculated
or supplied, by the system.
Examples - The data capture method is "Basic" for Chemical Code, and "Derived"
for Total Spill Samples Quantity (a calculated data element which is the count of the
number of Spill Samples for a particular Spill).
DATA COLLECTOR
Definition - DATA COLLECTORS are the organizations responsible for collecting the
values of data required by an OSWER program.
Requirement - DATA COLLECTOR should be identified.
Usage - Identify one or more organizations which actually collect the values of the
data element. The data collection is not necessarily via automated information
systems. Thus, an organization using paper forms to collect data is a valid DATA
COLLECTOR.
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DATA CUSTODIAN
Definition - DATA CUSTODIANS are the organizations responsible for supporting
the storage and processing of data, and ensures the physical integrity of data used to
support OSWER missions while providing access to the users.
Requirement - DATA CUSTODIAN should be identified.
Usage - Identify one or more organizations which store the data. The storage of data
is not necessarily via automated information systems. Thus an organization using
paper files as storage is a valid DATA CUSTODIAN.
C-4 Data Modeling Practice Paper
-------
OSWEJ? Directive #902S.OOc
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DATADEFINER
Definition - DATA DEFINER is the organization responsible for determining and
documenting the requirements, meaning, and content of data, e.g., name,
description, and other properties, needed to support OSWER's mission.
Requirement - DATA DEFINER should be identified.
Usage - The organization defining the data entity should be entered as the Data
Definer. The DATA STEWARD selects the DATA DEFINER, which in most cases is
the primary DATA USER.
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DATA STEWARD
Definition - DATA STEWARD is the organization which requires the data
represented by the data entity to be collected, processed, stored or used in support of
OSWER's mission. The DATA STEWARD'S responsibilities include ensuring that:
"Data are clearly defined and documented in compliance with established
directives. Data that is collected is of sufficient quality to support OSWER's
missions. Only data relevant to OSWER's missions is collected. Data is
reused wherever appropriate within OSWER. Data management practices for
data under the organization's stewardship conform to OSWER guidance."6
Requirement - DATA STEWARD should be identified.
Usage - DATA STEWARD is typically the organization the defines who the other
data management organizations (Data Definer, Data Collectors, Data Users, and Data
Custodians) are for a given entity.
Examples - "OSWER AA"; "OERR"; "OSW"; "OWPE"; "OUST1
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
6From the Practice Paper for Data Management During the System Life Cycle
Data Modeling Practice Paper C-5
-------
OSWER Directive #9028.00c
DATA USER
Definition - The DATA USERs are the organizations that process the data in some
way. Usually there is one primary DATA USER (which is the DATA DEFINER in;
most cases).
v :
Requirement - DATA USER should be identified.
Usage - Identify one or more organizations which process the data. Because the use
of data is not necessarily via automated information systems, an organization using
paper forms to process data is a valid DATA USER. Note that moving forms
around is not considered processing; only organizations that perform business
activities with the data are considered DATA USERs.
Examples - "OERR"; "OSW"; "OWPE"; "OUST"
(Note that the organization may be at a lower or higher level than the examples
indicate, but should always be at the lowest possible level).
DERIVATION RULES
Definition - DERIVATION RULES are the algorithms used to derive the value for
the data element.
Requirement - Only derived data elements require DERIVATION RULES. Derived
data elements are those specified as "Derived" for the DATA CAPTURE METHOD.
Usage - Describe the algorithm if it is not overly complex, or if complicated,
reference the documentation containing a description of the algorithm.
Examples - For a Current Age calculated data element, the algorithm might be:
"Subtract the date of birth from the current date."
DESCRIPTION
Definition - DESCRIPTION is an accurate, concise and unique textual narrative of
the programmatic meaning of the data element. :
Requirement - Every data element must have a DESCRIPTION when the data entity
is created.
Usage - The DESCRIPTION property should describe what the date elements are, not
what they are for or how they are used. Descriptions should be brief and to the
point.
C-6 Data Modeling Practice Paper
-------
OSWER Directive *9028.00c
Examples - Description of Treatment Change Code:
"The Treatment Change Code represents the projected change in the use of waste
water treatment method at a facility."
DISPLAY LABEL
Definition - DISPLAY LABEL is a name to be used on screens and reports.
Requirement - The DISPLAY LABEL may not be known until the Design stage.
Usage - For some systems, the DISPLAY LABEL varies depending on the screen or
report. In those cases, it is recommended that several be listed here with a
qualification in the COMMENTS section to clarify the different uses. For
consistency purposes, it is best to standardize the label as much as possible, since this
name of the data element is the one seen most by users.
Examples - A label for Spill Date:
"Date of Spill"
DOCUMENTOR NAME
Definition - The person who records the information about the data element for the
current VERSION NUMBER of the data element.
Requirement - Each version of the data element should have the DOCUMENTOR
NAME entered.
Usage - The DOCUMENTOR NAME provides an audit trail of who updated the data
element information for the VERSION NUMBER and EFFECTIVE DATE specified.
Since each update will result in a new data element version, each version needs
only one DOCUMENTOR NAME.
Examples - For a given element:
"Joe Smith, OERR"
EDIT CRITERIA
Definition - EDIT CRITERIA are the programmatic rules for the values.
Requirement - Every data element should have EDIT CRITERIA.
Data Modeling Practice Paper C-7
-------
OSWER Directive #902S.OOc
Usage - If there are no restrictions on the values that a data element can contain,
specify "No restrictions" for the EDIT CRITERIA. Note that specific values for the
data element can be provided in the VALID VALUES property.
Examples - For a Spill Date:
"Must be a valid calendar date."
Or for a Chemical Code:
"Must be a code listed in the Chemical Abstracts Registry listing of chemical codes."
EFFECTIVE DATE
Definition - The date that this version of the data element is valid for, generally the
date the information is documented.
Requirement - An EFFECTIVE DATE should be provided with each new version of
the data element, as indicated by the VERSION NUMBER.
Usage - The EFFECTIVE DATE corresponds to the VERSION NUMBER and the
DOCUMENTOR NAME. This date should not be updated on prior versions, but
only provided for each new version of the data element.
Examples - For a given element:
"9/5/91"
FORMAT
Definition - FORMAT is the format to be used in the technical environment.
Requirement - Every data entity should have a FORMAT. This of information can
be provided by a Data Base Administrator for the target environment, such as
ADABAS or dBASE.
Usage - The valid types of FORMAT are:
Binary Numeric
Character Floating Point
Hexadecimal Packed Decimal
Octal
Examples - For a Chemical Code:
C-8 Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
"Character"
Or for a Site Inspection Date:
"Binary" (if the target environment uses binary date format)
FREQUENCY OF UPDATE
Definition - FREQUENCY OF UPDATE is how often the content of the data element
is changed.
Requirement - The FREQUENCY OF UPDATE may not be known until late iin the
Definition or Design stage.
Usage - The FREQUENCY OF UPDATE is used in Design for physical storage
planning and for transaction processing design. Specify approximate average update
cycles if not sure of how often. Acceptable values are:
Bi-annually Monthly (or specify an alternate
Annually Weekly unit of time)
Semi-annually Daily
Quarterly Never
Examples - For Chemical Code the frequency may be "Never", and for Facility
Contact Name it might be "Quarterly" (on average).
FULL NAME
Definition - FULL NAME is the full unabbreviated name of the data element.
Requirement - Every data element must have a FULL NAME when the data
element is created.
Usage - The FULL NAME should not contain abbreviations. Refer to the Data
Elements section for guidance on constructing meaningful data element names.
Examples - "Manufacturing Facility Production Unit Number", "Retail Clothing
Customer Invoice Date"
KEYWORDS
Definition - KEYWORDS are words which describe data elements and represent
important concepts, events, or topics that are related to the data element.
Data Modeling Practice Paper C-9
-------
OSWEK Directive #9028.00c
Requirement - Keywords should be used according to OSWER standards.
Usage - Include different ways of classifying the data element, such as the program it
supports, the level of interest in the data, and the fact that it is an OSWER data
element. In addition, a list of keywords can be obtained from the Information
Management Staff. These words help to retrieve information about the data
definitions and organizing data elements topically for analysis and presentation.
Examples - "RECORDS MANAGEMENT SUPPORT', "CERCLA/SARA SUPPORT1,
and "SUBSTANCE TRANSPORTATION"
LENGTH
Definition - LENGTH indicates the maximum number of positions allowed for the
data element.
Requirement - All data elements should have the LENGTH indicated.
Usage - Specify the number of characters (i.e., positions) allowed for the values of
the data element.
Examples - For a data element containing dollar amount information and will be
less than $1 billion, can have two decimal places, and can also be negative:
LENGTH=16
Note the following representation of the maximum number of positions shows
how 16 was arrived at - "-$999,999,999.99".
ORIGINATING SOURCE
Definition - The ORIGINATING SOURCE is the organization and/or system that
OSWER obtains the data from.
Requirement Each data element should have an ORIGINATING SOURCE
indicated.
Usage - For any data elements whose DATA CAPTURE METHOD is "Basic", there
must be some source of the information. This will either be an internal source,
such as information originating from within an EPA organization, or an external
source. Note that this source is not the individual or organization who enters the
data into a system. The ORIGINATING SOURCE is where the data was obtained
from prior to its entry into a system.
C-10 Data Modeling Practice Paper
-------
OSWER Directive #902S,OOc
Examples - For Chemical Code, the source may be a particular EPA organization
responsible for defining code values; for a Hazardous Waste Shipment Quantity, the
source would be Facilities who provide the information to EPA.
SECURITY CLASSIFICATION
Definition - SECURITY CLASSIFICATION identifies the sensitivity class of the data
represented by the data element.
Requirement - SECURITY CLASSIFICATION should be completed in the Definition
Stage of the SLC If no security restrictions apply to a data element, identify this as
well using the phrase "Non-sensitive" to document this fact.
Usage - SECURITY CLASSIFICATION may only exist for certain situations, such as
Confidential Business Information related to a FOIA request. Use the following
categories to identify the classification of security required:
Non-sensitive - indicates there is no special requirement to protect the object from
deliberate manipulation or disclosure;
Government Privilege - indicates data are exempt from disclosure under 40 CFR 1.2;
Personal Information - is data on individuals exempt from disclosure under 40 CFR
1.16, "Implementation of the Privacy Act";
Subject to Manipulation - is data subject to modification for fraud, embezzlement, or
espionage;
Confidential Business Information (CBI) - is information pertaining to trade secrets
or commercial or financial information which has not been determined to be; non-
confidential under 40 CFR 1.2 Subpart B "Confidential Business Information"; and
Classified - pertains to national security information exempt from disclosure under
40 CFR 1.11, "Security Classification Regulations Pursuant to Executive Order
11652".
(Note that security information is also included as part of describing data entities.)
Examples - For an Employee Salary Amount data element:
"Personal Information"
SECURITY DESCRIPTION
Definition - SECURITY DESCRIPTION is information which describes the potential
sensitive nature of the data represented by the data element.
Data Modeling Practice Paper C-ll
-------
OSWER Directive #9028.00c
Requirement - SECURITY DESCRIPTION should be completed in the Definition
Stage of the SLC. If no security restrictions apply to a data element, identify this as
well using the phrase "Non-sensitive" to document this fact.
Usage - SECURITY DESCRIPTION may only exist for certain situations, such as
Confidential Business Information related to a FOIA request. Use the property to
describe the situation being sure to address the following areas of data security in the
SECURITY CLASSIFICATION property.
Examples - For an Employee Salary Amount data element:
'This data element contains sensitive information about salary. Edit routines
will be required to only allow employees in personnel with a to-be-defined
security class to create, modify, or peruse this information."
VALID VALUES
Definition - VALID VALUES are the list of allowable values that a data element can
contain.
Requirement - If the data element is limited to particular values, this VALID
VALUES should be used.
Usage - List the specific values or identify a reference, such as a codes manual, which
contains valid values. Sometimes the list is too large to be entered for each data
element, which is why references can be effective. Be sure to indicate the date and
version of the reference.
Examples - For a State Code data element, the valid values are:
VALID VALUE Meaning
AL Alabama
AZ Arizona
CA California
etc.
VERSION NUMBER
Definition - The VERSION NUMBER is a sequential number corresponding to the
number of the update to the data element.
Requirement - A VERSION NUMBER should be provided for each new version of
the data element.
C-12 ' * Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
Usage - When the data element is first defined, the VERSION NUMBER should be
"1". After each change to the definition or other properties of the data element, the
VERSION NUMBER should be incremented by 1 for each new version. Each time
the VERSION NUMBER is updated (including the first tiir"4 the data element is
defined), an EFFECTIVE DATE and DOCUMENTOR NAME should be provided as
well. Also, version numbers should always be whole numbers, i.e., "1", "2", "3",
etc., and not "2.3" or "1.15".
Examples - For a given element:
Data Modeling Practice Paper C-13
-------
This page intentionally left blank
-------
OSWEK Directive #9028.00c
APPENDIX D: DATA MODELING QUICK REFERENCE
The following are guidelines for building a logical data model.
These guidelines address the creation and naming of data entities,
data relationships, and data elements. The guidelines are
intended as a quick reference, and not as an instructional aid.
Using these guidelines assumes a basic understanding of data
modeling concepts and techniques.
General Guidelines
Represent data requirements to reflect real world business rules for
your business
Account for exceptions to normal business rules in the data model
Don't belabor issues - take a position, document it, create an issue, and
move on
Contact OSWER's Information Management Staff to obtain
information about available data models, which can be used to reduce
effort and take advantage of existing data definitions, where applicable
Document models in a data dictionary following OSWER guidelines
Inform and deliver to OSWER Information Management Staff data
model information for review and guidance
Data Entity Guidelines
Think of data entities as the persons, places, things, concepts, and
events that we need to keep information about
Establish discrete data entity boundaries - each data element should be
represented only once (non-redundantly)
Establish a data entity only if we need to store information about the
data entity itself - a data entity representing a single data element is not
a data entity
Data Modeling Practice Pqper D-l
-------
OSWER Directive #902S.OOc
Establish data entities within the scope of analysis - use the function
model, current system inputs and outputs, and future objectives to
identify data needs
Resolve many-to-many data relationships with intersecting entities
(typically done in the Definition Stage of the SLC as part of the logical
data model)
Create a data entity name in the singular case and avoid physical data
characteristics in the name
Resolve data entity homonyms and synonyms
Determine naturally occurring entity identifiers - the entity is suspect if
one can not be determined
Data Relationship Guidelines
Establish meaningful data relationships - be wary of redundant
relationships
Create more than one relationship between two data entities if needed -
may be redundant if they always imply the same entity occurrences
Use recursive relationships only if a data entity is truly related to itself
Create data relationship names using verbs of action to describe the
purpose of the relationship
Data Element Guidelines
Think of data elements as the most specific facts that are meaningful to
an organization
Create data elements such that each data element describes one and
only one data entity
Construct meaningful data element names:
data entity name + descriptor(s) + class word
D-2 * Data Modeling Practice Paper
-------
OSWER Directive #902S.OOc
APPENDIX E: GLOSSARY
AD ABAS - a mainframe-based data base management system by Software AG
business function - an activity performed by an organization
cardinality - a rule regarding the relationship of one data entity to another;
cardinality is the number of minimum and maximum occurrences that a data entity
is allowed to have in relation to a single occurrence of another data entity
CASE - Computer-aided Software Engineering; automated tools used to enhance the
development of information systems throughout their life cycle
COBOL - COmmon Business Oriented Language; a 3rd generation programming
language
.»
Concept Phase - the second phase of the OSWER System Life Cycle aimed at
identifying and documenting logical system requirements at a high-level of detail
conceptual data model - the data model produced during the Concept Phase of the
System Life Cycle; the model is usually not fully normalized and typically does not
have any data elements identified
data element - a characteristic or fact about a data entity; for example, Social Security
Number is a data element of the data entity, Employee
data entity - something about which information is needed for an organization to
operate; a person, place, thing, concept or event about which information is needed;
described by a set of data elements; for example, Employee, Site, and Contractor
might be data entities needed by an organization
data entity identifier - a data element whose values are unique across all of the
potential occurrences of a data entity
data entity occurrence - an instancy of an entity type; for example, "OSWER" !is a
data entity occurrence of the entity Organization
data entity relationship - an association between two data entities
data entity relationship diagram (ERD) - a graphical depiction of data entities and
data entity relationships
data flow diagram (DFD) - a graphical depiction of a subset of an organization's
business processes indicating the data inputs and outputs for each process and thus
the dependencies between the processes for data
Data Modeling Practice Paper E-l
-------
OS WEI? Directive #9028.OOc
data model - representations of an organization's data comprised of data entities,
data elements, data entity relationships, and their corresponding definitions, and an
entity relationship diagram
data modeling - the process of developing a data model
data normalization - a technique which simplifies data models by eliminating data
redundancy, and other anomolies in the model
data store - a group of related data shown on a data flow diagram; the data store
represents the data at rest, i.e., that which will be stored by a system
Definition Stage - the third stage of the OSWER System Life Cycle; details are added
to the requirements identified during the prior phase, the Concept Phase, to produce
logical models, such as a logical data model and data flow diagrams
FOCUS - a fourth generation language and data base management system
foreign key - a data element or group of data elements that are the primary key of
one data entity and are additionally placed in another data entity
Information Engineering Methodology (IEM) - a set of techniques, founded in
engineering principles, aimed at producing and maintaining detailed specifications
and executable code based on the examination of requirements in a top-down
manner, i.e., by analyzing and modeling requirements generally first, and then in
greater amounts of detail within specific phases of development and review
Information Strategy Plan (ISP) - the first stage of Information Engineering
Methodology aimed at identifying high-level organization-wide requirements and
strategies for deploying information resources, such as information systems,
hardware, software, communications, etc.
Initiation Phase - the first phase of the OSWER System Life Cycle; the essential
purpose of this phase is to define the information management problem which will
be addressed in successive stages of development
Joint Application Design (JAD) - a highly structured discipline for conducting a
group worksession which is facilitated usually by a trained JAD facilitator
logical - independent of a specific implementation, such as a particular software or
hardware platform; not physical
logical data model -.a data model which is normalized and has data elements
associated with each data entity in the model
E-2 " Data Modeling Practice Paper
-------
OSWER Directive #90ZS.OOc
natural identifier - a data entity identifier which is not based on data elements that
are contrived, such as a sequential number
physical - dependent upon a specific implementation, such as a particular software
or hardware platform
physical data base design - a set of specifications which represent the
implementation of a logical data model in a specific physical file structure, such as a
data base management system (DBMS); logical data models are altered due to DBMS
constraints and system performance considerations
primary key - a data entity identifier
process (or function) model - representations of an organization's business processes
(i.e., functions) and their relationship to data
process (or function) modeling - the process of developing a process (or function)
model
property - a characteristic which describes a data entity, data element, data entity
relationship, etc.; for example, length is a property of data element used to
document the number of characters allowed for a particular data element
relational data base - a data base management system (DBMS) which permits system
developers to define and access data based on its logical characteristics, instead of
having to know how the data is physically stored in a system; a relational data base
management system (RDBMS) also uses data values as primary and foreign keys,
instead of physical file pointers
System Life Cycle (SLC) - a set of activities, decisions, and products grouped into
inter-related stages addressing the solution of information management problems,
e.g., developing information systems to enhance user needs
Data Modeling Practice Paper E-3
-------
This page intentionally left blank
-------
OSWER Directive #9028.00c
APPENDIX F: OSWER-WIDE CONCEPTUAL DATA MODEL
F.I. CONTEXT FOR OSWER-WIDE DATA MODEL
Appendix F contains a version of OSWER's conceptual data model. Since the
data model is an evolving document, the current version of this model should be
obtained from the OSWER Information Management Staff (IMS).
OSWER's conceptual data model was originally developed by synthesizing
the results of a set of data analysis efforts targeted at OSWER's existing information
systems. Each analysis was performed by examining existing system documentation
first, and then confirming the individual system's data model with EPA program
experts, such as system and program managers.
The model in this appendix can be used to help individual project teams at
EPA to scope out their information requirements and to provide initial definitions
of high quality for key classes of information.
Equally important, however, is the ability to use the results of the analyses to
identify existing systems that may already contain information that is needed for a
particular program or other users. Interested program offices and individuals
should work with the Information Management Staff to identify opportunities for
best utilizing the OSWER-wide model and for a more complete understanding of its
meaning.
F.2. EXISTING OSWER SYSTEMS CONTRIBUTING TO OSWER-WIDE DATA
MODEL
The following sections identify the existing OSWER information systems
which were analyzed and incorporated into the OSWER-wide data model. In order
to present the entire model in a meaningful and understandable way, the data
model has been partitioned into two main pieces, a RCRA data model and a
CERCLA data model. Note that the completeness of these models are based largely
on the specific systems analyzed.
F.2.1. Systems Contributing to RCRA Portion of OSWER-wide Data Model
Biennial Report System
Federal Facilities Inventory System
Facilities Indexing System (FINDS)
Medical Waste Tracking System
Resource Conservation and Recovery Information System (RCRIS)
Date Modeling Practice Paper F-l
-------
OS WE/? Directive #9028.OOc
F.2.2. Systems Contributing to CERCLA Portion of OSWER-wide Data Model
Contract Lab Program (CLP) Analytical Results Data Base (CARD)
Comprehensive Environmental Response, Compensation, and Liability
Information System (CERCUS)
Emergency Response Notification System (ERNS)
Federal Facilities Inventory System
Facilities Indexing System (FINDS)
National Priorities List (NPL) Technical Database
National Priorities List (NPL) Site Database
Oil and Hazardous Materials Technical Assistance System (OHMTADS)
Records of Decision System (RODS)
Site Enforcement Tracking System (SETS)
Superfund Document Management System (SDMS)
p_2 " Data Modeling Practice Paper
-------
o
ft *H I »cl.v.t,
n * '
Tj
2
5
L, ? :
L0 » J :
I 0 i tc«v«r '
»-« r.,.,
>
C
...i
a
o
At
-------
OSWER Directive #9023.00c
Figure 22. CERCLA Data Model
F-4
Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
F.3. OSWBR-WIDE DATA ENTITY DEFINITIONS
Aggregate Planned Event - A commitment, target, or planning event to be
conducted by an authorized agency for one or more Handler(s). (RCRIS)
Air Documentation/Scores - Documentation of waste characteristics, targets, and
probability of release relating to contamination of air and the associated derived
scores used to determine NFL status of a CERCLA site. (NFL Technical)
CERCLA SI Site - A site that is undergoing site investigation as part of an effort to
determine the appropriate hazardous ranking score. (NFL Technical)
CERCLA Site - As mandated and defined by CERCLA, a site is a geographic area
where hazardous waste is either abandoned or uncontrolled. Hazardous waste is
defined in detail in the National Contingency Plan. (CERCUS, SDMS)
Chemical Sample - A specific portion of material at a site collected at a given itime
for analysis at a future date. (CARD)
Chemical Substance - A material produced by or used in an industrial or
commercial activity. Synonyms include Chemical Compound, Chemical Material,
Chemical, Material, Constituent, Element, Analyte. Examples include: Lead,
ammonium chloride, and water. (CARD, OHMTADS, NPL Technical, NPL Site
Database)
Contact Person - An individual who provides information regarding a
facility. There may be multiple contact people associated with a facility, where each
person has a specific area of expertise, i.e., technical, budget, etc. (Biennial Report)
Corporation - An organization responsible for fulfilling the terms of a given EPA
contract for determining the chemical composition of a given site sample. (CARD)
Corrective Action Area - A location at a Handler (or Handlers) where Corrective
Action activities are collectively managed. Corrective Action Area may be a
subcomponent of a Facility's geographic area or alternatively, it may encompass
multiple Facilities. It is typically a grouping of solid waste management units
(SWMU), corrective action management units (CAMU), and/or regulated units that
are defined by an instrument and may be addressed by one or more events. '(RCRIS)
Corrective Action Event An activity performed on an area by a handler or agency
(i.e., EPA or State) as part of a corrective action initiative. This entity includes
scheduled and actual dates for completion of a Corrective Action event, responsible
agency, and responsible person for a specific Corrective Action event. (RCRIS)
Data Modeling Practice Pjfper F-5
-------
OSWER Directive #9028.OOc
Cost/Recovery Dollars - The dollars recovered by EPA after litigation and
negotiation efforts with Potential Responsible Parties (PRPs). These dollars are used
to reimburse the fund for response actions performed at a site. (CERCUS)
Direct Contact Documentation/Scores - Documentation of targets and probability of
release relating to direct contacts and the associated derived scores used to determine
NPL status of a CERCLA site. (NPL Technical)
Document - Maintains information about the CERCUS Site (i.e., Superfund Site) file
documents. (SDMS)
Enforcement Activity - The actions taken by EPA to compel or negotiate with
Potential Responsible Parties (PRPs) to either conduct response actions or reimburse
EPA for EPA funded response actions. (CERCLIS, NPL Site Database)
Enforcement Event - An action to compel (directly or indirectly) a handler's
compliance to meet RCRA requirements, such as a phone call, lawsuit, threat of
lawsuit, or referral to another agency; information may include financial penalties.
(RCRIS)
Environmental Activity - An action related to the protection of public health and
environment from the release of hazardous substances at a Facility, such as
monitoring and corrective action. (Federal Facility)
Evaluation Event - Review of a single or comprehensive set of handler activities to
verify compliance with RCRA regulatory requirements, including on-site
inspections and off-site reviews. Information contained in this entity includes the
type, coverage area, date of evaluation, and responsible agency. (RCRIS)
Event - An activity performed by a facility or authorized authority in the review
and/or execution of a RCRA activity. (RCRIS)
Facility - A regulated entity uniquely identified by street address. (FINDS)
Financial Record - Information pertaining to the financial transactions (i.e.,
commitment, obligation, deobligation, outlay, etc.) which track money spent for
response events and those financial transactions (i.e., damage claim, cost recovery,
penalties, etc.) which seek to recover monies through enforcement activities.
(CERCLIS)
Fire and Explosion Documentation/Scores - Documentation of targets and
probability of release relating to contamination from fire and explosion and the
associated derived scores used to determine NPL status of a CERCLA site. (NPL
Technical)
F-6 * Data Modeling Practice Paper
-------
OSWER Directive *9028.00c
Fund Event - An action in a series of actions taken by EPA to further qualify and
treat the conditions at a site. Actions are generally categorized as follows: pre-
remedial, remedial, removal, or community relations. Examples include feasibility
study, health assessment, technical assistance, remedial design, etc. (CERCUS)
Generator - A person, by site, whose act or process produces regulated medical waste
as defined in subset D of 40 CFR 259 or whose act first causes a regulated medical
waste to become subject to regulation. In the case where more than one person (e.g.,
doctors with separate'medical practices) are located at the same building, each
individual business entity is a separate generator for the purposes of 40 CFR 259.
(Medical Waste Tracking)
Ground Water Documentation/Scores Documentation of waste characteristics,
targets, and probability of release relating to contamination of ground water and the
associated derived scores used to determine NFL status of a CERCLA site. (NFL
Technical)
Handler - A RCRA regulated entity that is defined by a unique identification
number from the Facilities Indexing System (FINDS). Although infrequent, a non-
regulated entity may comply voluntarily. Includes TSD's, waste transporters, waste
generators, burners, and blenders. Contains address, latitude and longitude data.
(Biennial Report, RCRIS)
Handler Demographics - Information pertaining to activities carried out at a
Handler during a particular period of time. (Biennial Report)
Hazardous Substance - A set of substances defined as hazardous by EPA, which
sometimes present a potential or actual danger to the environment, e.g., humans,
wildlife, and nature. Examples include: halogenated solvents, sludges, spent
catalysts, and chloroform. (OHMTADS)
Hazardous Waste - Any product or individual item that is hazardous; any substance
designated in pursuant to section 311 (b) (2) (A) of the Federal Water Pollution Act;
section 102 of CERCLA; section 3001 of the Solid Waste Disposal Act; and section 7 of
the Toxic Substances Control Act. The term does not include petroleum, including
crude oil or any fraction thereof which is not otherwise specifically listed or
designated as a hazardous substance, and the term does not include natural gas,
natural gas liquids, liquified natural gas, or synthetic gas usable for fuel (or mixtures
of natural gas and such synthetics). (FFIS)
Hazardous Waste Stream- A single waste or combination of wastes generated by or
managed by a waste process. Data typically includes the amount of hazardous waste
stream handled and unit of measure. (RCRIS, Biennial Report)
Data Modeling Practice Paper F-7
-------
OSWER Directive #9028.00c
Implementor Personnel - EPA or state personnel responsible for conducting an
evaluation of a handler or for developing enforcement actions to be taken against a
handler. May be either an inspector or compliance officer. (RCRIS)
Incident - Anything that requires further action from an investigation or evaluation
to a Superfund clean-up effort (response perspective); A substance greater than the
reportable quantity (RQ) that was not reported by the Discharger (enforcement
perspective); any verified release of a substance (general public perspective).
Release, not Spill, is a synonym. (ERNS)
Incident Location - Geographic area where an incident occurs; identified by street
address, river or highway mile post. (ERNS)
Incident Notification - Report of a release of oil or hazardous substances by an
individual, who may or may not be the Discharger, to the state and/or federal
government. (ERNS)
Incinerator - Design and capacity information such as the age, type, and number of
chambers that are operated by generators to incinerate regulated medical waste on-
site. (Medical Waste Tracking)
Incinerator Waste Feed - Quantity and source information on medical waste that is
burned by a generator using an on-site incinerator. The data reflects a six month
reporting period. (Medical Waste Tracking)
Individual - Maintains information about the "person" who receives or creates
Superfund Document Management System (SDMS) documents. (SDMS)
Industrial System - An interaction of processes and equipment at a Handler
designed to manage hazardous waste by Treatment, Disposal, and /or Recycling
(TDR). An Industrial System may also generate hazardous or non-hazardous waste.
An industrial system may be a production system (i.e., used in the manufacturing of
an item) or a clean-up process (i.e., TDR system used to handle hazardous waste).
(Biennial Report)
Industry - A class of trade (i.e., high level business function) performed by external
organizations (e.g., companies, government agencies) such as petroleum refining,
highway construction, and dry cleaning. (OHMTADS)
Instrument - The legal or driving force under which corrective actions are being
planned or undertaken. Typically, Instruments are Administrative Orders or RCRA
Permits. They may be a voluntary action. Instruments can include responsible
agency, issuance dates, type of instrument, etc. (RCRIS)
F-8 Data Modeling Practice Paper
-------
OSWER Directive #9025.00c
Laboratory - A facility designed for identifying, analyzing, and assessing the presence
of hazardous substances and their potential harmful effects due to exposure to the
environment, wildlife, and/or humans. (CARD)
Laboratory Analysis Contract - An agreement between EPA and a laboratory facility
to perform chemical substance analysis services, such as waste sample analysis from
sites of EPA interest. (CARD)
Laboratory Equipment - An apparatus used to perform chemical substance analysis
in (or as if in) a laboratory. Examples include gas chromatograph and mass
spectroscope. (CARD)
Non-RCRA Permit - Authorization that allows a Site to perform a series of non-
RCRA environmental activities. Data includes the type of permit and permit
number. (RCRIS)
Notification/Potential Responsibility - The legal communication used to inform an
External Organization or a Potentially Responsible Individual that they are a
Potentially Responsible Party (PRP) at a Site. (SETS)
NFL Site - A potentially uncontrolled hazardous waste site that has been listed on
the National Priorities List (NPL) and is included in the Federal Register. (RODS,
NFL Site Database)
Operable Unit - As defined in the National Contingency Plan (NCP), an operable
unit is a discrete action that comprises an incremental step toward comprehensively
addressing site problems. This discrete portion of a remedial response manages
migration, or eliminates or mitigates a release, threat of a release, or pathway of
exposure. The cleanup of a site can be divided into a number of operable units
depending on the complexity of the problems associated at a site. Operable units
may address geographic portions of a site, specific site problems, or initial pluses of
an action, or may consist of any set of actions that are concurrent but located in
different parts of a site. The determination of an operable unit may vary over time
as a result of a change in activity or need. (NPL Site Database, RODS, CERCUS,
SDMS)
Operator - The person responsible for the overall operation (i.e., generation, storage,
. treatment, and disposal of hazardous waste) of a facility, including the land. Data
includes name, address, phone number, etc. (Biennial Report, RCRIS, FFIS)
Organization - Maintains information about the organization or "Affiliation" of a
document user, author, or recipient. An organization itself may be the creator or
recipient of a document. (SDMS)
Data Modeling Practice Riper F-9
-------
OSWER Directive #9028.OOc
Owner - The person or organization who owns the land or facility. The data
captured may pertain to a person or organization who acts as a proxy for the owner.
Includes name and address data. (FFIS, RCRIS)
Permit/Closure Event - An activity performed by a facility or authorized permitting
authority in the review and/or final determination of a permit application. Data
Includes scheduled and actual dates, responsible agency, responsible person, type, of
event, etc. (RCRIS)
Personnel - EPA or state authorized individual assigned responsibility for the
review and/or execution of an event. (RCRIS)
Potentially Responsible Party - An individual or organization that is potentially
liable for the performance or finance of the performance of removal and/or
remedial actions at a site. In the case of an incident, it is the person who operates a
facility or vehicle where an incident occurs. (ERNS, SETS)
Project Officer - An individual responsible for the reporting of an EPA case
involving hazardous waste and it's potential harmful effects due to environmental,
wildlife, and/or human exposure. (CARD)
Quality Assurance/Quality Control Substance - A mixture of Chemical Substance(s)
forming a material for the purpose of testing (e.g., calibrating) the degree of accuracy
and precision of laboratory analysis equipment or validating a procedure. (CARD)
Quality Assurance/Quality Control Test - The application of a specific analytical
technique to specific laboratory equipment or procedure in order to measure the
degree of accuracy and precision of the equipment measurement or process.
(CARD)
Record of Decision - Legal and technical data pertaining to the type of media,
contaminants, responsiveness, and alternative remedies proposed to treat an
operable unit. This entity contains information associated with both a ROD and a
ROD amendment. (RODS)
Regulated Medical Waste - The generator type and quantity of regulated medical
waste (e.g., those medical wastes* that have been listed in 259.30 (a) of 40 CFR and
that must be managed in accordance with the requirements of 40 CFR Section 259)
generated in a covered state that was accepted for transport from a specific generator
* Medical waste is defined in 40 CFR 259 as "any solid waste which is generated in the diagnosis,
treatment (e.g., provision of medical services), or immunization of human beings or animals, in research
pertaining thereto, or in the production or testing of biologicals. The term does not include any
hazardous waste identified or listed under Part 262 of this chapter or any household waste as defined
in 261.4(b)(I) of this chapter."
F-10 Data Modeling Practice Paper
-------
OSWER Directive #902S.OOc
or delivered to a specific intermediate handler or destination facility during a six
month reporting period. (Medical Waste Tracking)
Remedial Project Manager As defined in the National Contingency Plan (NCP), the
remedial project manager is the official designated by the lead agency to coordinate,
monitor, or direct remedial or other response actions. (CERCLIS)
Request - Maintains information about the "event" that causes SDMS documents to
be retrieved. (SDMS)
Resource - An estimated amount in costs and hours to complete a single, specific
commitment, target, or planning event by a given authorized agency (RCRIS).
Response - Evacuation, evaluation, monitoring, and clean-up activities by a
Discharger, EPA, state, local, or other authorized Federal parties (e.g., U.S. Coast
Guard, Army Corps of Engineers, etc.). (ERNS)
Sample Analysis - An analytical sequence performed upon a sample to determine
chemical substances contained in the sample. (CARD)
Selected Remedy - The chosen plan of action described in the record of decision
(ROD) to address an operable unit. The plan may be a single action, multiple
actions, or a decision to perform no further action. (RODS)
Site - A physical geographic area at which EPA has some interest, usually due to the
past, present, and/or future generation and/or management of hazardous waste.
Includes temporary sites. (CARD, NPL Technical, OHMTADS, SETS)
Substance - Any substance identified as a threat to human health and the
environment (response perspective); a hazardous substance that is greater than the
amount allowed under reportable quantities (RQ) for CERCLA (section 103), SARA
(section 304), or the Clean Water Act (section 311); a reportable oil discharge as
defined in 40 CFR Part 110; or an Extremely Hazardous Substance (EHS) as identified
in Title 3 of SARA (enforcement perspective); any substance of interest, usually
identified through a FOIA request (general public perspective). (ERNS)
Surface Water Documentation/Scores - Documentation of waste characteristics,
targets, and probability of release relating to contamination of surface water and the
associated derived scores used to determine NPL status of a CERCLA site. (NPL
Technical)
Technical Qualifiers - Technical data collected at a site during the removal process
which includes, but is not limited to, chemical name, site classification, population
affected, and health threats. (CERCLIS)
Data Modeling Practice Paper F-ll
-------
OSWER Directive #902S.OOc
Toxicity Test - A specific experiment designed to determine the toxic nature of a
hazardous substance. (OHMTADS)
Transporter Facility - Location details of transporter facilities within a covered state
for which the transporter has notified the Federal government. A Transporter
Facility includes loading docks, parking areas, storage areas and other similar areas
where shipments of regulated medical waste are held (come to rest or are managed)
during the course of transportation. (Medical Waste Tracking)
Treatment, Storage, Disposal (TSD) Facility - A type of Handler who treats, stores,
and /or disposes of hazardous waste, including regulated medical waste, and who in
addition, may generate and/or transport hazardous waste. A TSD Facility may be a
destination facility or an intermediate handler; if it is an on-site incinerator, it is also
be classified as a generator. Synonyms: Facility, Receiving Facility, On Site
Incinerator, Medical Waste Facility. (FFIS, Medical Waste Tracking)
User - Maintains information about the "person" who requests and/or works with
SDMS documents. (SDMS)
Violation - An infringement of RCRA regulatory requirements discovered through
an evaluation of a Handler that may be addressed by one or more enforcement
actions. Data includes discovery date, priority, scheduled and actual return to
compliance (RTC) dates, etc. (RCRIS)
Waste Characteristics - A set of substances (i.e., listed wastes) defined as hazardous by
EPA, which sometimes presents a potential or actual danger to the environment,
e.g., humans, wildlife, and nature. Waste Characteristics also include substances
defined in the Toxic Release Inventory and characteristics of hazardous waste such
as toxic, ignitible, corrosive, and reactive. (RCRIS, Biennial Report)
Waste Description - A description of the type of waste at a Site and/or in an operable
unit, in terms of the media and contaminants. (NFL Site Database)
Waste Management Area - An area that manages or needs to be managed. Includes
spills. (FFIS)
Waste Management Process - A process that handles waste such as a landfill or
incinerator. Process codes, amount, unit of measure, and status data elements are
included in this entity. (RCRIS)
Waste Transporter - A person who accepts and hauls off-site shipments of regulated
medical waste generated in a covered state. Method of transportation may be by air,
rail, highway, or water. (Medical Waste
Tracking)
F-12 Data Modeling Practice Paper
-------
OSWER Directive #902«.00c
Waste Treatment Method - A procedure to reduce the amount and /or potential
harmful effects of waste. Examples include microfiltration and biological treatment.
(NFL Site Database)
Waste Unit Group - A single or multiple treatment, disposal, or storage mechanism,
defined by the same process and unit of measure. Events within a Waste Unit
Group apply to all units within a Waste Unit Group (i.e., permitting, closure, post-
closure, and research, development, and demonstration). (RCRIS)
Data Modeling Practice Paper F-13
-------
OSWER DIRECTIVE *3C28.0Cc
OFFICE OF SOLID WASTE
AND EMERGENCY RESPONSE
(OSWER)
SYSTEM LIFE CYCLE
MANAGEMENT GUIDANCE
Part 3: Practice Paper
Application Security Management
During the System Life Cycle
October 1991
-------
OSWER DIRECTIVE #9028.00c
4.2.3 Special Considerations for Developmental Security
Measures During the Initiation Phase 4-6
4.2.4 Initiation Phase Products and Baselines 4-6
4.3 Application Security Management During the Concept Phase 4-8
4.3.1 Overview 4-8
4.3.2 Concept Phase Activities 4-10
4.3.3 Special Considerations for Developmental Security
Measures During the Concept Phase.. 4-12
4.3.4 Concept Phase Products and Baselines 4-13
4.4 Application Security Management During the Definition
Stage :. 4-14
4.4.1 Overview : 4-14
4.4.2 Definition Stage Activities 4-16
4.4.3 Special Considerations for Developmental Security
Measures During the Definition Stage 4-19
4.4.4 Definition Stage Products and Baselines 4-19
4.5 Application Security Management During the Design Stage 4-21
4.5.1 Overview 4-21
4.5.2 Design Stage Activities 4-23
4.5.3 Special Considerations for Developmental Security
Measures During the Design Stage 4-25
4.5.4 Design Stage Products and Baselines 4-26
4,6 Application Security Management During the Development
Stage 4-28
4.6.1 Overview . 4-28
4.6.2 Development Stage Activities 4-29
4.6.3 Special Considerations for Developmental Security
Measures During the Development Stage 4-31
4.6.4 Development Stage Products and Baselines .......4-32
4.7 Application Security Management During the Implementation
Stage 4-35
4.7.1 Overview 4-35
4.7.2 Implementation Stage Activities 4-35
4.7.3 Special Considerations for Developmental Security
Measures During the Implementation Stage 4-37
4.7.4 Implementation Stage Products and Baselines 4-38
4.8 Application Security Management During the Production
Stage 4-40
4.8.1 Overview 4-40
4.8.2 Production Stage Activities 4-40
4.8.3 Production Stage Products and Baselines 4-42
4.9 Application Security Management During the Evaluation
Stage 4-42
4.9.1 Overview 4-42
4.9.2 Evaluation Stage Activities 4-44
11
-------
OSWER DIRECTIVE #9028.00c
Practice Paper: Application Security Management
During the System Life Cycle
Table of Contents
1.0 Introduction 1-1
1.1 Practice Paper Purpose 1-1
1.2 Practice Paper Topics 1-1
1.3 Application Security Management Responsibilities 1-3
1.4 Basic Principles 1-3
1.5 Why Focus Upon Application Security Management? .1-4
1.6 How to Use this Practice Paper 1-4
1.7 Topics Not Addressed in this Practice Paper. 1-5
2.0 Application Security Management: CORE Concepts 2-1
2.1 Introduction 2-1
2.2 Core Concepts 2-1
2.2.1 OSWER's Security Objectives: Availability, Integrity,
Confidentiality and Appropriate Use 2-1
2.2.2 Sensitivity/Sensitive 2-2
2.2.3 Information Resources 2-2
2.2.4 Adverse Event 2-2
2.2.5 Threat 2-3
2.2.6 Vulnerability. ..2-3
2.2.7 Risk ....2-4
2.2.8 Risk Analysis .-. 2-4
2.2.9 Security Measures... 2-4
2.2.10 Benefit-Cost Analysis 2-6
3.0 Application Security Management Approach 3-1
3.1 Introduction 3-1
3.2 What is an Application Security Management Approach? 3-1
3.3 Why Choose an Application Security Management Approach?.... 3-1
3.4 Special Considerations for Roles and Responsibilities 3-1
3.5 Determining and Documenting Your Application
Security Management Approach 3-2
4.0 Application Security Management During the System Life Cycle 4-1
4.1 Introduction 4-1
4.2 Application Security Management During the Initiation Phase.... 4-2
4.2.1 Overview 4-2
4.2.2 Initiation Phase Activities .....4-5
-------
OSWER DIRECTIVE #9028.00c
4.9.3 Evaluation Stage Products and Baselines 4-45
4.10 Application Security Management During the Archive Stage 4-47
4.10.1 Overview 4.47
4.10.2 Archive Stage Activities 4.47
4.10.3 Archive Stage Products and Baselines 4-49
Appendix A: Terms A-l
Appendix B: Reference Materials B-l
Appendix C: Security Characterization Matrices C-l
LIST OF EXHIBITS
1-1 Practice Paper Overview 1-2
4.1-1 Oversight Organization Documentation Requirements 4-3
4.2-1 Initiation Phase 4-4
4.3-1 Concept Phase 4-9
4.4-1 Definition Stage 4-15
4.5-1 Design Stage 4-22
4.6-1 Development Stage 4-30
4.6-1 Implementation Stage 4-36
4.8-1 Production Stage 4-41
4.9-1 Evaluation Stage 4-43
4.10-1 Archive Stage 4-48
-------
OSWER DIRECTIVE #9028.00c
PRACTICE PAPER:
APPUCATION SECURITY MANAGEMENT
DURING THE SYSTEM LIFE CYCLE
Chapter 1
INTRODUCTION
1.1 Practice Paper Purpose
This practice paper provides details to project managers concerning their
responsibilities for Application Security Management for both new applications and
existing applications under the Office of Solid Waste and Emergency Response
(OSWER) System Life Cycle Management Guidance. This practice paper describes
application security management throughout the application life cycle, and provides
guidance concerning objectives, key decisions, activities, products and baselines that
the project manager must address from Initiation through Archive.
This practice paper has three primary purposes:
Focus each project manager's attention on application security management
Facilitate appropriate application security management for each OSWER
application
Provide a common approach to application security management across
OSWER
This practice paper constitutes a section of Part 3 of the OSWER System Life Cycle
Management Guidance.
1.2 Practice Paper Topics
Exhibit 1-1 provides an overview of the structure of this practice paper. Topics
addressed are:
An introduction to core application security concepts
Selection of an application security management approach for both new and
existing applications
Consideration of application security management objectives, key decisions,
activities, products, and baselines at each life cycle phase and stage
1-1
-------
EXHIBIT 1-1
APPLICATION SECURITY MANAGEMENT
PRACTICE PAPER OVERVIEW
OSWER DIRECTIVE #9028.0(k
OFFICE OP SOLID WASTE
AND EMERGENCY RESPONSE
(OSWER)
PRACTICE PAPER
APPLICATION
SECURITY MANAGEMENT
DURING THE SYSTEM
LIFE CYCLE
APPENDIX C
SECURITY
CHARACTERIZATION
MATRICES
APPENDIX B
REFERENCE MATERIALS
APPENDIX A
TERMS
CHAPTER 4
APPLICATION SECURITY
MANAGEMENT DURING THE
SYSTEM LIFE CYCLE
CHAPTERS
APPLICATION SECURITY
MANAGEMENT APPROACH
CHAPTER 2
APPLICATION SECURITY
MANAGEMENT:
CORE CONCEPTS
CHAPTER 1
INTRODUCTION
-------
OSWER DIRECTIVE #9028.00c
The following notation is used:
Terms which have special meaning in relationship to the OSWER, System Life
Cycle Management Guidance appear in small italic letters. ;.>
CORE CONCEPTS, described in Chapter 2, appear in capital letter italics.
1.3 Application Security Management Responsibilities
Project Managers are responsible for implementing this guidance for new or existing
OSWER applications. Specifically, they are responsible for selecting an application
security management approach, documenting the approach in the Project
Management Plan, and ensuring that this approach is implemented throughout the
life cycle.
Application data stewards, custodians, and users are responsible for carrying out all
relevant agency security guidance and SECURITY MEASURES which are to be
implemented for the application.
1.4 Basic Principles
The following basic principles provide the foundation for all OSWER application
security management objectives, key decisions, activities, products and baselines:
Application security management is critical to the effective and efficient
accomplishment of OSWER's programmatic mission.
Application security management is an integral component of every phase and
stage of the life cycle.
All OSWER applications are SENSITIVE to some degree.
Application security management involves data stewards, custodians, and
users as well as project managers, developers and maintainers.
Application security management is a continuing and dynamic process.
Application security management involves not only the application itself, but
also the installations and facilities where the application is developed and
operated, along with the personnel who develop and operate it.
1-3
-------
OSWER DIRECTIVE #9028.00c
1.5 Why Focus Upon Application Security Management?
This practice paper focuses on application security management throughout the life
cycle for the following reasons:
Application security management is a relatively new discipline. Because of
this, it is often poorly understood by application system project managers, data
stewards, custodians and users.
Many THREATS and the VULNERABILITIES these THREATS exploit are so
subtle that they are easily overlooked.
Many ADVERSE EVENTS occur so rarely that they are seldom considered even
though the magnitude of harm or RISK is relatively great.
Computer-based application systems are often more VULNERABLE to loss of
AVA/LAB/ZJTY, INTEGRITY, CONFIDENTIALITY and to /NAPPROPR/ATE
USE than the manual systems they replace.
Retrofitting SECURITY MEASURES into an operational application is often
more costly and less effective than integrating or coordinating them with other
activities throughout the application life cycle.
A number of Federal oversight agencies, as well as EPA, have issued policies
and directives regarding application security management. OSWER needs to be
assured that their application systems comply with these policies and
directives.
1.6 How to Use this Practice Paper
Before reading Chapters 2 through 4 of this practice paper, be sure to read Part 2 of
the OSWER System Life Cycle Management Guidance. In addition, pay special
attention to the practice papers on "System Life Cycle Reviews and Approvals,"
"Benefit-Cost Analysis/' "Data Management During the System Life Cycle,"
"Configuration Management," and the "Project Management Plan" which are in
Part 3. You will also need to reference the "EPA Information Security Manual."
Use Chapter 2 to familiarize yourself with the core concepts of application security
management. You will need a thorough understanding of these concepts before you
develop your application security management approach. Chapter 3 describes the
essential components of your approach. Consult Chapter 4 as you actually develop
and refine your approach throughout the life cycle.
1 1
-------
OSWER DIRECTIVE #9028.00c-
Be sure to take advantage of the Appendices. Appendix A not only defines
important terms, but cross-references them to numerous oversight agency policies
and directives. Appendix B contains an annotated bibliography of oversight agency
policies and directives as well as other important reference material. The Security
Characterization Matrices in Appendix C provide concrete examples of material
which is discussed on a more theoretical level in Chapters 2 and 4. The "Guidelines
For Security of Computer Applications" (FIPS PUB 73) as well as the "EPA
Information Security Manual/' were used in the formulation of these matrices.
1.7 Topics Not Addressed in this Practice Paper
This practice paper is designed to complement OSWER's System Life Cycle
Management Guidance. Because of this, it is more focused than most other material
on application security management. For example, configuration management and
data quality (i.e., accuracy, precision, completeness, and consistency) are often
considered to be security issues. However, as they are covered elsewhere in the
Guidance, they are not included here.
Additionally, this practice paper does not contain guidance on how to conduct a
security RISK ANALYSIS. RISK ANALYSIS is a specialized subject on which much
excellent reference material is readily available.
Nor does this practice paper contain recommendations for the implementation of
specific SECURITY MEASURES unless they have been specifically required by
federal oversight or agency guidance. This is because SECURTTY MEASURES
should not be selected until a RISK ANALYSIS has been conducted and a
determination made of appropriateness and cost effectiveness. Again, a great deal of
good material has been written on this subject.
1-5
-------
OSWER DIRECTIVE #9028.00c
Chapter 2
APPLICATION SECURITY MANAGEMENT: CORE CONCEPTS
2.1 Introduction
The purpose of this chapter is to introduce you to a number of core application
security management concepts. You will need to understand these concepts in order
to develop your application security management approach.
2.2 Core Concepts
2.2.1 OSWER's Security Objectives: Availability, Integrity, Confidentiality and
Appropriate Use
OSWER has four APPUCATION SECURITY OBJECTIVES. The first three are
explicitly mandated by the Computer Security Act of 1987, external oversight
guidance and the agency's security policy. These three APPLICATION SECURITY
OBJECTIVES are AVAILABILITY, INTEGRITY, and CONFIDENTIALITY. OSWER
has added a fourth OBJECTIVE to this list. That OBJECTIVE, implicit, but not
directly expressed in our oversight guidance, is APPROPRIATE USE of our
INFORMATION RESOURCES.
Each of these SECURITY OBJECTIVES is defined as follows:
AVAILABILITY: OSWER develops applications to support our programmatic
mission. The loss of AVAILABILITY of any INFORMATION RESOURCE
associated with an application could affect the application's ability to support
some aspect of the mission. AVAILABILITY refers to having our applications
ready and able to support our programmatic mission at the time they are
needed.
INTEGRITY: All INFORMATION RESOURCE components of an application
must retain the functionality they were designed to have in order to support
the programmatic mission. INFORMATION RESOURCES have INTEGRITY
as long as their functionality remains uncompromised, that is, they must do no
more, no less than their intended purpose.
CONFIDENTIALITY: Some OSWER applications contain data or provide
information which during a specified period of time is not subject to the
Freedom of Information Act and must not be disclosed without authorization.
CONFIDENTIALITY refers to our need to have certain of our data and
information held in confidence.
2-1
-------
OSWER DIRECTIVE #9028.00c
APPROPRIATE USE/INAPPROPRIATE USE: While INAPPROPRIATE USE or
misuse of an application may not result in direct loss of AVAILABILITY,
INTEGRITY, or CONFIDENTIALITY, misuse of our INFORMATION
RESOURCES is dearly undesirable and sometimes unlawful. In OSWER we »
want to ensure that our applications are used for, and only for, support of our .
programmatic mission. ;;«
v
2.2.2 Sensitivity/Sensitive
All OSWER applications are SENSITIVE to some degree: this is because, to some
extent, they are VULNERABLE to loss of AVAILABILITY and/or INTEGRITY, to
INAPPROPRIATE USE and some to loss of CONFIDENTIALITY. However, there
are different degrees of SENSITIVITY depending on the relevance of OSWER's
SECURITY OBJECTIVES to the information management problem to be solved. For
example, AVAILABILITY might be very relevant to a mission critical application;
INTEGRITY to a decision support application, and CONFIDENTIALITY to an
application processing confidential business information. It follows that the greater
the relevancy, the greater the degree of SENSITIVITY.
Note that data and information can also be considered SENSITIVE, as defined in
Appendix A.
2.2.3 Information Resources
OSWER applications involve data, information, hardware, software,
documentation, facilities, telecommunications and trained staff. These components
of each application are our INFORMATION RESOURCES. All INFORMATION
RESOURCES have value in and of themselves. Equipment costs money to acquire,
replace or repair. Staff costs money to hire, retain and train. Software costs money
to develop and maintain. However, the ultimate value of our INFORMATION
RESOURCES are the support they provide to our programmatic mission.
2.2.4 Adverse Event
In the broadest sense, the loss of an application's AVAILABILITY, INTEGRITY,
CONFIDENTIALITY or INAPPROPRIATE USE are ADVERSE EVENTS. Anything
that adversely affects any application INFORMATION RESOURCE is also an
ADVERSE EVENT since this in turn results in loss of AVAILABILITY, INTEGRITY,
CONFIDENTIALITY or takes additional resources to replace or recover.
For example, malfunctioning equipment could result in loss of AVAILABILITY. A
change in an application's software could result in a loss o' INTEGRITY.
2-2
-------
OSWER DIRECTIVE #9028.00c
[nadvertent disclosure of enforcement SENSITIVE information could result in a
loss of CONFIDENTIALITY. INAPPROPRIATE USE, such as violating software
licensing agreements or copyrights, is an ADVERSE EVENT since it could expose
the agency to legal complications. Refer to the matrix on ADVERSE EVENTS in
Appendix C for more examples.
2.2.5 Threat
A THREAT is anything that can cause an ADVERSE EVENT. Every application is
faced with countless THREATS. For the sake of simplicity, however, they can be
thought of as just two basic types: people and change to the environment. People
can deliberately or inadvertently cause ADVERSE EVENTS. For exarriple, deliberate
acts by people result in ADVERSE EVENTS such as loss of AVAILABIUTY through
malicious destruction of INFORMATION RESOURCES or loss of INTEGRITY
through fraudulent manipulation of INFORMATION RESOURCES. Inadvertent
acts by people, like leaving SENSITIVE information on a screen, could result in loss
of CONFIDENTIALITY. Unexpected or unwanted change such as flood, fire, smoke,
dust, or power loss, could result in similar ADVERSE EVENTS. Even anticipated
change can be a problem: think about the last time you had to adjust to a new
operating system or to an upgrade of your PC software.
THREATS can be as obvious as an earthquake or as subtle as a virus. They can
change throughout an application's life cycle, and frequently do so. For a logically
organized matrix of common THREATS and how they relate to our SECURITY
OBJECTIVES in different processing environments see Appendix C.
2.2.6 Vulnerability
Where there is a chance that a THREAT can reach an INFORMATION RESOURCE
and cause an ADVERSE EVENT there is VULNERABILITY. Identifying and
communicating VULNERABILITY can be quite challenging. While some
VULNERABILITIES are immediately obvious (e.g., a password posted on the wall),
others may be much more technical or subtle (e.g., spaghetti code). In general, you
can assume that the more complex, distributed, and widely used your application,
the more VULNERABLE it is.
Also like THREATS, VULNERABILITIES can change throughout an application's
life cycle. See Appendix C for a matrix organized by VULNERABILITIES to each
INFORMATION RESOURCE and how they relate to our SECURITY OBJECTIVES in
different processing environments.
2-3
-------
OSWER DIRECTIVE #9028.00c
22.7 Risk
Technically, RISK, also termed "loss expectancy," is the predicted loss from an
ADVERSE EVENT during a certain period of time. Risk is often expressed in terms
of dollars and cents, but not always. The period of time is usually expressed in years,
but not necessarily so. For example, the RISK of having to reenter transactions
which were lost due to hardware failure could be $5 per update cycle. The RISK of
having to pay prompt payment penalties due to a software error in an accounts
payable program could be $25,000 per year. Non-monetary RISKS are sometimes
expressed in terms such as inconvenience, delay and loss of credibility.
Also like THREATS and VULNERABILITIES, RISKS change throughout the
application's life cycle and require frequent evaluation.
2.2.8 Risk Analysis
The methodology to determine RISK by analyzing potential ADVERSE EVENTS,
THREATS, and VULNERABILITIES against INFORMATION RESOURCES, as well
as the likelihood of occurrence, is called RISK ANALYSIS. RISK ANALYSES are
either qualitative or quantitative. They may be conducted at a very summary level,
in great detail, or somewhere in between.
A detailed quantitative RISK ANALYSIS, is a highly specialized technical task, not
to be undertaken lightly. However, there is a great deal of good reference material
on various methodologies for conducting RISK ANALYSES. See Appendix B for
citations. The "EPA Information Security Manual" and "Guideline for Automatic
Data Processing Risk Analysis" (FTPS PUB 65) also provide guidance on conducting
qualitative RISK ANALYSIS.
2.2.9 Security Measures
SECURITY MEASURES counter or control THREATS. By definition, when an
appropriate SECURITY MEASURE is in place and being used effectively,
VULNERABILITY is reduced. However, keep in mind, there is no perfect world, at
least where application security is involved. An appropriate SECURITY MEASURE
is not always available. And even when they are available, SECURITY MEASURES
are not always in place. As a result, no application is ever completely
VULNERABILITY free.
SECURITY MEASURES are often categorized by their purpose. These purposes are
prevention, detection, minimization, and recovery. For example:
Cipher locks prevent unauthorized entry
-------
OSWER DIRECTIVE #9028.00c
Audit trails detect fraud
Training minimizes user errors
Frequent data backup aids recovery.
Since every application is always VULNERABLE to some extent, minimization and
recovery SECURITY MEASURES take on added importance. For example,
separation of duties ensures that exposure is minimized even if misuse occurs.
Also, contingency planning (for applications) or continuity of operations planning
(for installations) for recovery from ADVERSE EVENTS ranging from mild
disruptions to AVAILABILITY to all-out disasters needs to be part of every
application's repertoire of SECURITY MEASURES.
SECURITY MEASURES can also be categorized by their type and subtype. For
federal government security planning purposes, the Office of Management and
Budget (OMB) has categorized SECURITY MEASURES as management controls,
development controls, operational controls, security awareness and training,
technical controls, and support system controls. These categories, and the
subcategories under them, have been based on numerous Government Accounting
Office (GAO) and National Institute of Standards and Technology (NIST) guidance.
A more traditional categorization of types of SECURITY MEASURES, and the one
used in this practice paper, is physical, technical, administrative, and managerial.
Keyboard locks are a physical SECURITY MEASURE. Implementing software access
protection, such as Resource Access Control Facility (RACF), is a technical
SECURITY MEASURE. Maintaining a list of authorized users is an administrative
SECURITY MEASURE. Developing an application security management approach
and documenting it in the Project Management Plan is a managerial SECURITY
MEASURE.
It is also important to understand that there is not always a one-to-one relationship
between THREATS and SECURITY MEASURES. One THREAT may be countered
by a number of SECURITY MEASURES. For example, bans on smoking, smoke
detectors, equipment covers, and fire extinguishers are all effective SECURITY
MEASURES for fire. On the other hand, many THREATS may be countered by one
SECURITY MEASURE. Off-site back ups are an effective SECURITY MEASURE
against numerous unwanted or unanticipated changes as well as inadvertent and
deliberate acts by people.
Another thing to keep in mind is that not all SECURITY MEASURES are perfectly
compatible. By countering one THREAT they may make another THREAT more
likely. For example, ceiling fire extinguishers may cause water damage as they
douse the fire. Labeling confidential printouts or diskettes "sensitive," to indicate
special handling, may draw unwanted attention.
2-5
-------
OSWER DIRECTIVE #9028<00c'
And finally, with just one exception, SECURITY MEASURES are never completely
free. Some SECURITY MEASURES, such as hardware encryption devices, may cost
thousands of dollars. Even SECURITY MEASURES such as passwords have cost
implications in terms of increased internal processing time and decreased user
access efficiency. Fortunately, some SECURITY MEASURES, are automatically
derived from following OSWER System Life Cycle Management Guidance for Data
Management, Configuration Management, testing, etc and reduce
VULNERABILITY at no additional cost. The same holds true for compliance with
guidance already required by agency property management and personnel
management policy. The one exception, the SECURITY MEASURE which is
completely free, and probably the ultimate in protection, is a suspicious mind!
Never, ever underestimate its value.
See Appendix C for a matrix of common SECURITY MEASURES by purpose,
SECURITY OBJECTIVE, typical processing environment, and applicable phase and
stage.
2.2.10 Benefit Cost-Analysis
Benefit-cost analysis is a systematic approach for comparing alternative ways to
satisfy an objective. Benefit-cost analyses are conducted throughout the OSWER life
cycle. The benefits to be realized through RISK reduction as well as the costs to
develop, acquire, implement, operate, periodically evaluate and eventually archive
SECURITY MEASURES need to be considered along with all other application
benefits and costs.
Be sure to reference the OSWER System Life Cycle Management Guidance practice
paper on Benefit-Cost Analysis. In addition, Appendix C of the"EPA Information
Security Manual" and "Guidance for Automatic Data Processing Risk Analysis"
(FTPS PUB 65) provide guidance on identifying RISKS and selecting appropriate
SECURITY MEASURES.
2-6
-------
OSWER DIRECTIVE #9028.00c
Chapter 3
APPLICATION SECURITY MANAGEMENT APPROACH
3.1 Introduction
This chapter provides guidance on developing and refining your application
security management approach, for either new or existing applications, throughout
the life cycle.
32 What is an Application Security Management Approach?
An application security management approach is only one facet of your overall
project management approach. It focuses on ensuring that OSWER's SECURITY
OBJECTIVES of A VAILABIUTY, INTEGRITY .CONFIDENTIALITY and
APPROPRIATE USE are met throughout an application's life cycle. An application
security management approach addresses security management specific objectives,
key decisions, activities, products and baselines at every phase and stage, The rigor
and formalism of your approach should reflect the degree of SENSITIVITY of the
application.
3.3 Why Choose An Application Security Management Approach?
An application security management approach is necessary to ensure that OSWER's
SECURITY OBJECTIVES are effectively met and that they are met in a cost efficient
manner. Too often, security is addressed as an afterthought resulting in ineffective
and inefficient retrofitted SECURITY MEASURES. In contrast, SECURITY
MEASURES, well integrated within the application, throughout the life cycle, can
greatly enhance an application's overall effectiveness and efficiency. Ultimately,
good application security management is the most important and effective
SECURITY MEASURE.
3.4 Special Considerations for Roles and Responsibilities
Because security is a specialized technical area, requiring both empirical and
theoretical knowledge, you may need to give special consideration to the
assignment of roles and responsibilities. Your project team may need to include
experts in RISK ANALYSIS, hardware and software SECURITY MEASURES,
technical writing, and security training. Some applications may require assistance in
areas such as the Freedom of Information Act and Privacy Act procedures and the
3-1
-------
OSWER DIRECTIVE #9028.OOc
agency's confidential business information (CBI) processes. In some cases you will
need to consult auditors from the Office of the Inspector General and you may want
to have them working with you from Initiation through Implementation and for
periodic Evaluations. During the Production stage, substantial 'security
responsibilities may be placed on your application data stewards, custodians, and
primary and secondary users. Users, in particular, tend not to be security oriented
and will often need special training and frequent re-enforcement in order to fulfill
their security roles and responsibilities.
The "EPA information Security Manual" contains further material on roles and
responsibilities.
3.5 Determining and Documenting Your Application Security Management:
Approach
The life cycle development and refinement of your application security
management approach is an iterative process. As you progress through each phase
and stage, your approach will become more focused and detailed.
You will summarize your overall application security management approach for
Program Management in each of the Decision Papers. You will document the
details of your approach in the Project Management Plan. At the end of each life
cycle phase and stage before entering a new one, your Project Management Plan
should document your application security management approach by describing the
objectives met, and the "why," "who," "what," "where," "when," and "costs" of
each key decision made, activity completed, product delivered and baseline added or
updated during the just completed phase or stage. At the same time, the Plan
should address your workplan for the next phase or stage.
You may choose to organize all your application security approach documentation
under a "Security Management Approach" heading in the Project Management
Plan, or to place it under other topic headings. For example, the details on
application security roles and responsibilities could appear under "Project Team
Organization." Security training and awareness could appear under "User Support
Approach" while the cost for SECURITY MEASURES could be included in the
"Project Budget."
Be sure to take advantage of the wealth of reference materials readily available to
you. Start with the EPA Headquarters Library since they have an excellent
information resources management (IRM) collection. See Appendix B for a list of
reference materials which include a selection of security videos available from the
Washington Information Center (WIC). Also, don't neglect to consider software
tools available to you for RISK ANALYSIS and benefit-cost anrlysis.
-------
OSWER DIRECTIVE #9028.00c
Chapter 4
APPLICATION SECURITY MANAGEMENT
DURING THE SYSTEM LIFE CYCLE
4.1 Introduction
The OSWER System Life Cycle Management Guidance includes some references to
application security in various products such as the System Concept, Detailed
Functional Requirements, Detailed Data Requirements, and System Design. In
contrast, the purpose of this chapter is to specifically address your dynamically
evolving application security management approach at each phase and stage of the
OSWER life cycle for both new and existing applications. It provides the
information you, as a project manager, need to develop your approach and to
document this approach in the various Decision Papers and your Project
Management Plan. It also provides information you need to comply with various
EPA and federal requirements regarding application security management.
As is described in Part 2 of the Guidance, your approach involves identifying the
project objectives and the "why," "who," "what," "where," "when," and "costs," of
key decisions, activities, products and baselines as they relate to application security
management for each phase and stage listed below:
Phases Stages
Initiation Initiation
Concept Concept
Definition and Design Definition
Design
Development and Implementation Development
Implementation
Operation Production
Evaluation
Archive
There are many issues which complicate application security management. This
chapter attempts to show the multifaceted nature of application security
management. It does not recommend or discuss specific SECURITY MEASURES
(except by way of example), but rather provides a structured methodology for
introducing SECURITY ME/ SI/RES appropriate to the application at the correct
4-1
-------
OSWER DIRECTIVE #9028.00c
phase or stage. The remainder of this chapter is divided into sections corresponding
to each life cycle phase and stage. For each phase and stage, the following is covered:
Brief description of the results of the previous phase or stage and summary of
work to be conducted during this phase or stage
Guidelines for conducting each application security management activity
Special considerations for developmental SECURITY MEASURES
Descriptions of key products and baselines, including documents required by
various oversight organizations, highlighted in Exhibit 4.1-1
Graphic summary of objectives, key decisions, activities, products and baselines
12 Application Security Management During the Initiation Phase
4.2.1 Overview
During the Initiation phase you select an overall application security management
approach which reflects the SENSITIVITY of your application.1 This approach will
be further refined throughout the remainder of the life cycle. You also develop a
detailed approach for the Initiation phase which addresses application security-
related project objectives, key decisions, activities, and products as well as the
creation of the Initiation baseline. See Exhibit 4.2-1 for an overview of these topics.
By the end of the Initiation phase, you will have:
Determined the degree of SENSITIVITY of your application
Performed an order-of-magnitude benefit-cost analysis
Determined what SECURITY MEASURES need to be in place for the Concept
phase
1The term "application" is used generically here since the decision on whether or not
automation is an appropriate solution to the information management problem will not be made
until the CONCEPT phase.
4-2
-------
OSWER DIRECTIVE #9028.00c
Exhibit 4.1-1 Oversight Organization Documentation Requirements
Document
Table for Sensitivity Evaluation
(EPA Manual, Section 4)
OSWER System Update Form
NIST/NSA Security Plan
(OMB Bulletin 90-08)
Qual. Risk Analysis Worksheet
(EPA Manual, Appendix C)
Quant. Risk Analysis Report
(EPA Manual, Appendix C)
Continuity/Contingency Plan
(EPA Manual, Appendix D)
Security Manual
(or other operational doc.)
Security Training Statement
\ppl. Certification Worksheet
(EPA Manual, Appendix B)
OSWER Life Cycle Phase/Stage
Init.
IN
IN
Con.
Def.
U
Des.
IN
IN
IN
Dev.
IN
IN
Imp).
UN
UN
IN
IN
Prod.
U1
Eval.
UN
UC
U1
US
UC
US
UC
UC
UN
IE
U3
UC
Arch.
A
A
A
A
A
A
A
A
A
Comment
Management Approval;
Submit to SIRMO for
Annual Report to OIRM
Submit to SIRMO for
OSWER Data Resource
Directory
Submit to SIRMO
Submit to SIRMO for
Annual Report to OIRM
Submit to SIRMO for
Annual Report to OIRM
Submit to SIRMO for
Annual Report to OIRM
Submit to SIRMO for
Annual Report to OIRM
Submit to SIRMO for
Annual Report to OIRM
Submit to SIRMO for
Annual Report to OIRM
Legend: IN = initial submission for new systems; IE = initial submission for existing systems
U m update; UN = update as needed
U1 = update annnually
U3 = update every three years
US = update every five years
UC = update upon significant change
X = archived
-------
EXHIBIT 4.9-1: INITIATION PHASE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
o Determination of application SENSITIVITY
o Order-of-magnitude benefit-cost analysis
o Identification of Concept phase SECURITY MEASURES
KEY
DECISIONS
ACTIVITIES
PRODUCTS
1MB milt to raaponaUa tar appflcaUon Mcurty
managamani approaon during MUadon phaaa?
Wl» win oornpMa. r«v«a«r and appro* -T*»i tar
OSinrx R
Sytlwn Updo* Form tor OSWER (M> Bwouiw
WhB otfw Kprovak « nvnunr Kid «*>
An th«* «ny «McM MMory )«quHrmnli?
Who «il (Mrform bVMA-eoa MtfyM?
Who will b* rwpomM* tar Conapi phM wptauon
Wha munodolaglH and teak iM b* UMd tor Corap
tag* apploilon iwurly nwHgcmm approaen?
PROJECT E
What ft ratovanca of aacn o) OSWER* tour SECURITY
OBJECTIVES to Mormadon managaman praUam?
What tt accMfcakxM oagraa at SENsmviTY?
What wil ba banal A at RISK raduebon?
What wil ba ordar-ol-magn«uda eoai of SECURITY
MEASURES?
Whai RISKS am
Whai SECURITY MEASURES ar* naadad tor Conoapl
through impMmairuUonT
Dow aopiicaton'i RISK (vartua ordat ol magnamn
coiti) praduda oontlnuad i,laii«*ui^«T
Will Conopl pnaa* SECURITY UEAJUAES to h
pact »y tna uri et ttw Conoapi phaaaT
Aaalgn raapemMiy tar SEHSmvtTY Daiirmrtdon.
(wtowflnd ^kpWrVl
Ra«to> and apprewa Tabla tar SamtMy E«*uaflon-
AMlgn MpenMKr tar OSWER S>MOT UpdM Fern
Ra*a« and approw OSWER Syaiam Update Form
Aatign raaponafe«y tar banantoaai araftah
appro* tonan-ooai ana***
Surmrte
InMMonOacWonPapar
Documanl appfcuton tacurfly r
m Profaa Uanagamari Pkn
Oaflna appfcaflon d^bprran
URfTY
MEASURES naMad tor Conoapi Otrougri ki^Mrwu.
PBOJECT EffifiVTr0** AcnvrrtEa.-
ComtMi TaMa tor SanalMry EMhaUorr nortaliaai
CompMa OSWER Sy«am UpdaM Farm tar OSWER
Oau Haaouraa Okaeiory
Partorm ordar-of^nagniuda banaflkogal an»>«b of
RISKS and SECURITY MEASURES
UPDATED:
MEW:
SamUvty Evatiadon Womaha«. par "EPA
Mormatton S«ur«r Manual1 Sadton 4V
OSWER Sytum UpdaM l^rrn tar C«WER Data
Raaouroa Otaoon/v
htWton Oadalon Papar*
Projaa Managamani Plari
* uvad ki Wlaaon MMIM
* tan) W OSWER SIRMCi
<:,-^ 4
-------
OSWER DIRECTIVE #9028.00c
4.2.2 Initiation Phase Activities
4.2.2.1 Sensitivity Determination
Your first activity is determining your application's relative SENSITIVITY (e.g.,
high, medium or low). This determination of SENSITIVITY is basic to the
development of your application security management approach and will come in
to play again and again in many ways throughout the life cycle. Highly SENSITIVE
applications require formal, detailed, well documented approaches, while
applications with low SENSITIVITY require only the implementation of the
minimal SECURITY MEASURES prescribed in the "EPA Information Security
Manual."
To determine SENSITIVITY you follow the three step methodology provided in
Chapter 4 of the "EPA Information Security Manual." The methodology includes
completing a worksheet called the 'Table for Sensitivity Evaluation." You should
note that you may determine your application to be more SENSITIVE than the
worksheet indicates. For example, if your application contains Confidential
Business Information (CBI), you might consider CONFIDENTIALITY to be highly
relevant to your information management problem (rather than medium as Table
4-2 suggests) and therefore your application to be highly SENSITIVE. However, you
may not determine your application to be less SENSITIVE than indicated by the
agency's methodology.
You should also note that the worksheet addresses only AVAILABILITY,
INTEGRITY, and CONFIDENTIALITY. The fourth OSWER SECURITY OBJECTIVE,
APPROPRIATE USE, must be considered also. Add your determination of relative
SENSITIVITY to APPROPRIATE USE as an addendum to the worksheet.
You also document the degree of SENSITIVITY on the OSWER System Update
Form.
4.2.2.2 Order-of-Magnirude Benefit-Cost Analysis
The OSWER System Life Cycle Management Guidance requires you to conduct an
order-of-magnirude benefit-cost analysis during the Initiation phase, as described in
the practice paper on benefit-cost analysis in Part 3 of the Guidance. Obviously, you
need to balance the benefits of RISK reduction against the costs of the SECURITY
MEASURES needed throughout the life cycle. At this early phase in the life cycle,
you will have to settle for high level assumptions. As a general rule, the higher the
SENSITIVITY, the greater the benefits from RISK reduction. On the other hand, the
greater the complexity and the larger and more dispersed the user community, the
greater the costs for SECURITY MEASURES.
4-5
-------
OSWER DIRECTIVE #9028-.QOc.
4.2.3 Special Considerations for Developmental Security Measures During the
Initiation Phase
During Initiation, you also need to consider what RISKS are associated with the
application development process itself. For example, if you were developing an
invoice payment application, you might need to implement SECURITY
MEASURES during Definition, Design, Development, and Implementation to
prevent an embezzler from altering your software as it is being defined, designed,
coded, tested, or installed. As another example, you might need SECURITY
MEASURES to prevent unauthorized disclosure of your Security Manual as it is
being written, edited, or distributed. You may need personnel screening throughout
the life cycle. Appendix C will help in identifying THREATS and SECURITY
MEASURES applicable to the development process.
4.2.4 Initiation Phase Products and Baselines
Table for Sensitivity Evaluation
You complete this worksheet as described above in Section 4.2.2.1. You must have
the 'Table for Sensitivity Evaluation" worksheet approved by the appropriate
manager as designated in the Project Management Plan. Once approved, add it to
the Initiation baseline and submit it to the OSWER Senior Information Resource
Management Officer (SIRMO) for reporting in OSWER's annual security report to
the Office of Information Resources Management (OIRM).
OSWER System Update Form
Once you have completed the SENSITIVITY determination you can complete the
SECURITY MEASURES section of the OSWER System Update form for the OSWER
Data Resource Directory. This form is initially submitted to the OSWER Senior
Information Resource Management Officer (SIRMO) at the completion of the
Initiation phase. It is also included in the Initiation baseline.
Initiation Decision Paper
At the end of the Initiation phase, you summarize your overall application security
management approach for the entire life cycle in the Initiation Decision Paper. Be
sure to address your rationale for determining the degree of SENSITIVITY and the
order-of-magnitude cost of SECURITY MEASURES over the course of the entire life
cycle.
4-6
-------
OSWER DIRECTIVE #9028.00c
Project Manaeement Plan
You document your overall application security management approach in the
Project Management Plan. Your approach should address your project objectives,
key decisions, activities, products and baselines. Be sure to include:
Any special application security requirements (e.g., Privacy Act, confidential
business information (CBD)
Identification of the elements of the project management structure that relate
to application security management activities, particularly individuals
responsible for reviewing and approving Initiation phase products and
baselines., using the "EPA Information Security Manual" for guidance as to
appropriate roles and responsibilities
Description of the methodology used for SENSITIVITY determination
Benefits to be derived from RISK reduction
Order-of-magnitude cost estimate for SECURITY MEASURES, including
developmental SECURITY MEASURES
Plans for acquiring, implementing, operating, evaluating and eventual
archiving of SECURITY MEASURES for the Concept phase through Operation
phase
You also need to develop and document an application security management
approach workplan for the Concept phase. It should cover new objectives, key
decisions, activities, products and baselines. Be sure to address:
SECURITY MEASURES needed to be in place before the Concept phase begins
Proposed methodology for Concept phase activities
Concept phase activities, as defined in Section 4.3
Refer to the topical outline for the Project Management Plan given in Part 2 of the
OSWER System Life Cycle Management Guidance for the Initiation phase.
4-7
-------
OSWER DIRECTIVE #9028.00c
4.3 Application Security Management During the Concept Phase
4.3.1 Overview
You selected your overall application security management approach during the
Initiation phase. Your approach was based on a determination of the relative
SENSITIVITY of your application. You also conducted an order-of-magnitude
benefit-cost analysis of RISK reduction benefits versus SECURITY MEASURE costs.
During the Concept phase your detailed application security management approach
addresses new application security-related project objectives, key decisions, activities
and products, as well as the updated Initiation baseline. See Exhibit 4.3-1 for an
overview of these topics.
By the end of the Concept phase you will have:
Identified the high level RISKS of each application concept alternative
Identified the appropriate types of SECURITY MEASURES for each application
concept alternative
Conducted a more detailed benefit-cost analysis than in the Initiation phase for
each application concept alternative
Developed a testing strategy for each type of SECURITY MEASURE for the
recommended application concept alternative
Determined what SECURITY MEASURES need to be in place for the Definition
stage
If you determined in the Initiation phase that your application has a low degree of
SENSITIVITY, your task in the Concept phase is simple. This is because the "EPA
Information Security Manual" spells out a set of minimal SECURITY MEASURES,
which are all that are required for low SENSITIVITY applications. In addition, the
cost of the agency's minimal SECURITY MEASURES are relatively negligible, so
their cost need not be considered in the benefit-cost analysis.
Your methodologies for conducting Concept phase activities for medium and highly
SENSITIVE applications relate to the degree of SENSITIVITY. In general, the more
SENSITIVE the application, the greater the need for detailed, formal, quantitative
methodologies; the less SENSITIVE, the more flexibility you have for summary
level, informal, qualitative methodologies.
1-8
-------
OSWER DIRECTIVE ^025.GCc
EXHIBIT 4.3-1: CONCEPT PHASE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
of Cora* ph«a» SECURmr MEASURES
High toy* RISK ANALYSES tor Mch ppKcation comet rittmrt* tar medium mi high SENSTTIV-
(TY pptkaijorw
S^ction of pproprtoaa SECURfTY MEASURE lypM and tonriMMt miytM tor Mch application
OOOOtpt wtiVfTHOM
Definition .o» Mug anagv "» SECURtTY MEASURE lypM tor recommended ipfHtfitton concept
narrative
MntHlculon of Dtflniton tag* SECURITY MEASURES
DECISIONS
PROJECT APPHOACH
Who will b» rwpontbl* tor application MOuflly
manag»mara approach during Cencapl phaaa?
Who « IMMd tor
What SECURITY MEASURES am nttoti during
Minnton. Dwgn, QjintoBmanl
tugat?
Ooa*
SECURITY MEASURE cons) praotud*
wm Dtflnllon (lag* SECURITY MEAtUPCS b* In pin
by th» i tan ot lha OatWBon nag*?
PHOJECT APPHOACM
A«lgn iMpormMn; tor Ngh IM! RISK ANALYSES
and bmrd-ooM anilyaaa
Rwtow and «prw* Ngh lw« RISK ANALYSES and
OBeurnaM rwuto of high KM! RSK ANALYSES and
Surnmarta SECURfTY MEASURES for handtng of
.SENSITIVE dau in Oala Managamant Plan
EMMth Met WMgy tor ««» SECURITY MEASURE
In Syflam Taat Oucumam and Atijapujnc* Teal
Document
Surrmartte refkiad appHcetion at
approach In Coneept OWHon Paper
Updatt appNcatton Hcuty manap*nwn approaoh In
Pnfa Managamant Plan
MEASURES nMdad tor Qanntton. Dailgn.
Kt SECURITY
PHOJECT EXECUTION ACTTVTTlEa:
Plao* SECURITY MEASURES nwMd tor Corcapl
pha*t Mo aftaet
Conduct Ngh KM! RISK ANALYSB lor madam and
Wgh SENSITIVITY I " " - -
tomtz* (rtnlmal SECURITY MEASURES lor al
Idandy typaa ol SECURITY MEASURES naadtd «(
banall-eM analy«ia tor imdMn and high SENSTDV-
OY appfcaMoni tor a«oh i
UPDATED:
Pw(acl Managcmam Plan
MEW;
SyttamConcao Documani*
Dau Managamam Plan
SytMm T«| Document
Aopapuno* T«at Oocumm
Comapt Dacston Papar
Mvad In killmon taut**
-------
OSWER DIRECTIVE :#9028.00c
4.3.2 Concept Phase Activities
4.3.2.1 High Level Risk Analyses
For medium and highly SENSITIVE applications/ your first activity is conducting a
high level RISK ANALYSIS for each application concept alternative. While RISK
ANALYSIS methodologies differ greatly, most include the identification of
applicable INFORMATION RESOURCES, ADVERSE EVENTS, THREATS,
VULNERABILITIES, and RISKS. Appendix C contains ADVERSE EVENT,
THREAT, and VULNERABILITY Characterization Matrices which should help get
your thinking started. "Guideline for Automatic Data Processing Risk Analysis"
(FIPS PUB 65) contains more detailed information. The references in Appendix B
offer other suggestions.
If the recommended application concept alternative includes the acquisition of an
application specific installation (e.g., a PC) you should refer to Appendix C,
Installation Risk Analysis, in the "EPA Information Security Manual," which
provides you with several helpful worksheets and suggestions for documenting the
results of your analysis. These worksheets will also be needed during the Design
stage.
To illustrate a common RISK ANALYSIS methodology and how each of the core
concepts relates, assume the following information management problem: you are
in charge of implementing an efficient and effective way to process and document
employee performance appraisal ratings. INTEGRITY and CONFIDENTIALITY
would obviously be relevant to this problem. You might proceed as follows:
Your first step is to identify the INFORMATION RESOURCES (e.g., employee
performance data, computer platform, software)
Second, you identify ADVERSE EVENTS that could affect the INTEGRITY and
CONFIDENTIALITY of each INFORMATION RESOURCE (e.g., unauthorized
manipulation of performance data or disclosure of performance data to other
than the employee or authorized supervisor)
Third, you identify THREATS that could cause these ADVERSE EVENTS (e.g.,
employees seeking to raise their scores, or employees seeking to find out the
scores of others)
Fourth, you identify the potential VULNERABILITIES (e.g., no user
identification and authentication via hardware or software)
Fifth, you identify the RISK for each ADVERSE EVENT (e.g., fairly low
expectancy that a given employee would raise his/her own performance
4-10
-------
OSWER DIRECTIVE #9028.00c
appraisal score because of the known integrity of staff, medium likelihood of
embarrassment over disclosure of confidential information)
Your approach needs to be forward-looking enough to anticipate future RISKS. For
example, if there is a possibility that your database may, at some future time, include
confidential business information (CBI), it might make sense to include access
protection from the start. Keep in mind that good SECURITY MEASURES are often
difficult and expensive to retrofit, so that over-designing in the short term may be a
wise decision.
4.3.2.2 Selection of Security Measure Types and Benefit-Cost Analyses
Your next activity involves the selection, at a high level, of appropriate types of
SECURITY MEASURES for each application concept alternative. The term
"appropriate" implies both of the following:
That the type of SECURITY MEASURE is effective
That the SECURITY MEASURE type would cost less to implement over the life
cycle than the RISK of not implementing it
Since selecting appropriate types of SECURITY MEASURES is a form of benefit-cost
analysis, be sure to reference that practice paper. In this context, benefits are equated
to the amount RISK is reduced as VULNERABILITIES are reduced or eliminated.
Costs are equated to the cost for development, acquisition, implementation,
operation, periodic evaluation and eventual archiving of the SECURITY
MEASURES.
There are a number of things to keep in mind as you select types of SECURITY
MEASURES:
Some of the types of SECURITY MEASURES you require may already be
planned for or in place. For example, the "EPA Information Security Manual"
requires the implementation of minimal SECURITY MEASURES for all agency
minicomputers, mainframe, PCs, LANs, and word processor installations. Of
course, you still need to coordinate with the installation custodian to make
sure that your requirements will be met.
There are also a number of types of SECURITY MEASURES that are derived
simply from following OSWER's Life Cycle Management Guidance. For
example, quality assurance, data management and configuration management
practices reduce your VULNERABILITIES to loss of AVAILABILITY and
INTEGRITY and to INAPPROPRIATE USE at no additional cost. The cost of
these SECURITY MEASURE types is accounted for under those activities.
4-11
-------
OSWER DIRECTIVE #9028,00c
Appendix C contains a Security Measure Characterization Matrix which should be
helpful to you in identifying types of SECURITY MEASURES.
4.3.2.3 Test Strategy for Security Measures
During the Concept phase, you must also decide on a test strategy which will ensure
that:
All SECURITY MEASURE types for the recommended application concept
alternative will be in place when they are needed
They are functioning effectively
They will remain effective over the entire life cycle
Your testing strategy should also reflect the relevance of the SECURITY
OBJECTIVES (i.e., more rigorous testing for highly SENSITIVE applications; less
rigorous testing for applications with medium SENSITIVITY). For example, if
CONFIDENTIALITY were highly relevant, your strategy might be to exercise every
line of code in the access control software; if AVAILABILITY were highly relevant,
your test strategy might be to hold frequent disaster recovery drills.
Your strategy should include simulation of ADVERSE EVENTS. For example, a
simulation of an ADVERSE EVENT relevant to CONFIDENTIALITY would be an
attempt to subvert access SECURITY MEASURES.
4.3.3.3 Special Considerations for Developmental Security Measures During the
Concept Phase
Your first concern, prior to conducting any of the above activities, is getting all your
Concept phase developmental SECURITY MEASURES in place. For example, you
may need to set up a process for personnel screening and selection or for controlled
document handling prior to the start of any of the Concept phase activities.
4-12
-------
OSWER DIRECTIVE #9028.00c
4.3.4 Concept Phase Products and Baselines
System Concept Document
You use the System Concept document to describe the:
SECURITY MEASURE types for each application concept alternative, as part of
the process of itemizing the high level functional requirements and high level
data requirements
Life cycle benefits and costs by SECURITY MEASURE type for each application
concept alternative
Data Management Plan
You document your application security management approach for data
AVAILABILITY, INTEGRITY, CONFIDENTIALITY, and APPROPRIATE USE in the
Data Management Plan. You should be able to identify SENSITIVE data at the entity
level at this phase. Refer to the practice paper on Data Management in Part 3 of the
OSWER System Life Cycle Management Guidance.
Data specific SECURITY MEASURES (e.g., backup/recovery, logging and auditing)
are also topics included in the Data Management Plan outline given in Part 2 of the
OSWER System Life Cycle Management Guidance.
System Test Document and Acceptance Test Document
You document your test strategy for each type of SECURITY MEASURE for the
recommended application concept in the System Test Document and the Acceptance
Test Document. Since at this point you don't know how specific SECURITY
MEASURES will be designed, this information will of necessity be quite general.
You will, however, be able to define what ADVERSE EVENTS need to be simulated
by the testing process.
Concept Decision Paper
At the end of the Concept phase you update the summary of your overall
application security management approach in the Concept Decision Paper.
Project Management Plan
Also at the end of the Concept phase, you update your overall security management
approach for the remainder of the life cycle. You also update the Project
Management Plan to reflect tht objectives accomplished as well as the key decisions
4-13
-------
OSWER DIRECTIVE #9028.00c
made, activities completed or underway, costs, products delivered, and baselines
modified. Be sure to include:
Revision of Initiation phase topics
Methodology for high level RISK ANALYSIS
Results of benefit-cost analysis
For applications with low SENSITIVITY, an explanation that only minimal
SECURITY MEASURES are required and therefore a RISK ANALYSIS arid
benefit-cost analysis were not conducted
For applications with medium or high SENSITIVITY, reference the System.
Concept Document (above) for a description of SECURITY MEASURE types
and costs
You also need to develop and document an application security management
approach workplan for the Definition stage. It should cover new objectives, key
decisions, activities, products and baselines. Be sure to address:
SECURITY MEASURES needed to be in place at the start of the Definition stage
The methodology to be used to define SECURITY MEASURE types
The methodology to be used to define SECURITY MEASURE test criteria
Definition stage activities, as defined in Section 4.4
Refer to the topical outline for the Project Management Plan given in Part 2 of the
OSWER System Life Cycle Management Guidance for the Concept phase. Note that
it includes a section specifically entitled "Security Approach."
4.4 Application Security Management During the Definition Stage
4.4.1 Overview
You refined your application security management approach during the Concept
phase after conducting RISK ANALYSES and benefit-cost analyses for each
application concept alternative.
During the Definition stage, your approach addresses new project objectives and a
number of new key decisions, activities and products along with the creation of the
Definition baseline. See Exhibit 4.4-1 for an overview of these topics.
4-14
-------
OSWER DIRECTIVE *9C23.GCc
EXHIBIT 4.4-1: DEFINITION STAGE SUMMARY
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
(mpamenufen ol OeflnHon etage SECURITY MEASURES
RISK Ar4ALY3a to aatoM application conapt
Seledtoi el aped* SECURITY MEASURES and deMad on
I appirajlon concapi
logic* daflntton of M* SECURITY MEASURE to
niwimnacaaaaryB upper! SECURITY MEASURES
:OefMton el feet onerta and metwdolooy to SECURITY MEASURES
BantlHJdcn ol Daatoi «aga SECURfTV MEASURES
KEY
DECISIONS
ACTIVITIES
PRODUCTS
PROJECT APPROACH
Wno will b* flMponttt* tar application aacuriiy
management approaon during Daflntjon eugaT
Win will conduct. writer and appro* deUUad RISK
ANALYSIS tor MfcciM appHcadon aoncad
om* OrfMOon at
tpKfle SECURITY MEASURES «M tanM-OM
«n«ly«( tor MMcwd «BeHc*ttn canc«pl iMmMM
u
Who will t«vlM OSWER Sy*Mm UpcUM form tor
OSWER DM Rwoira Owcwy?
Who will b* rMparablt tar procurarani al
SECURITY MEASURES ind wprov* Ml crtMrlc tor
Men SECURITY MEASURE?
Who wil b* fMpombto and w
toon w in* RISKS ot In*
appkcaiion concept lUrruUw?
Whu KMdlt SECURITY MEASURES w* nqulrad
and wnai ar* in* b*n*fti and COM ot **ch?
What ar* in* logical f«)ui*m*n» tor Mod
SECURITY MEASURE?
How wil aCQulr«d SECURITY MEASURES b*
precvr*d and Maud?
What SECURITY MEASURES V* WJutnjd to
Attlgn iMpontMRy to. rm**, and apprev* RISK
ANALYSIS, martan ot SECURITY MEASURES.
and banan-eoat malytli
Aatlgn iaif»»«Nlr|f to. imMao and appreo*
SeCUflrTY MEASURE bgkal datMtom
Aatlgn naponsURy to. nMaw and approval at
C4WER SyMm UpdaM Farm to OWMER DM
RMOUTO* Onjonry
Aatlgn rwponUiMy tar procuwmart ol SECURITY
MEASURES
Updaw Oau Managtman Plan. I naoaaaary
SuntiMto raftiad appHcalton tacurtn; manaoarnani
< In Oalnaton Oadalen Papar
Pfojad Managarnant
~
idSECUROY
aaitmi**?
DOAJFf T COMT1N
Do RISKS ol d*«n*d SECURITY MEASURES
pracM* tunnar iM»a«4Jinaiir?
Wil Daaign nag* SECURITY MEASURES b* ki
pun ey in* «an ot m* Oaalgn MagaT
MEASURES n*«dad to D«HBn.D* i atapmart and
Implamaraatton
PHOJECT EICECUT1QM AC! IIVII m:
Pkc* SECURITY MEASURES n**d*d to OafWBon
Partom danlad RISK ANALYSIS and banant-coB
analr**) to radium and Nghry SENSmVE
Pfwtd* logical njqulwnjnt daflnHona to aadt
SECURITY MEASURE N 0*ia**d Funatonjt
Raqutarrarw and Daiallart Oau Raqutamaraa
UpdaM O8WER Synam UpdaM Form » hdud*
SECURITY MEASURES
Dual Mat oitarla and mattwdotogta* In Sywm and
Aocacuno* TM Oocunm
UPDATED:
Prot« Managamant Plan
Syawm Taat Oocumant
Acoapune* T«i Oocumant
Oatt Managamant Plan
MEW:
Rpnaad OSWER Syaam Updau Form'.
Oatalad Funetenal Raqulramanti-
DauM Oau Ragulramanii'
Raquiramana Data Dictionary'
Oanmiton Oaefeton Papar
aaMd m CMnWon baa^m*
»aant to OSWEH SIRMO
4-15
-------
OSWER DIRECTIVE #9028.00c
By the end of the Definition stage you will have: :
Completed and documented a more rigorous RISK ANALYSIS of theiselected
application concept alternative
Selected specific SECURITY MEASURES within each type identified in the
Concept phase after performing a more detailed benefit-cost analysis
Described each SECURITY MEASURE at a logical level of detail to allow for
design of the software, logical database, external procedures, training courses,
manuals, hardware, telecommunication equipment and facility construction
Started preparation of purchase requests for physical and technical SECURITY
MEASURES and the acquisition or modification of special installations and
facilities
Established your SECURITY MEASURE test criteria and defined your test
methodology for the remainder of the life cycle
Determined what SECURITY MEASURES need to be in place for the Design
stage
4.4.2 Definition Stage Activities
4.4.2.1 Detailed Risk Analysis
If you have an application with high or medium SENSITIVITY/ your first step is to
conduct and document a RISK ANALYSIS of the selected application concept that is
more detailed than the RISK ANALYSES you did for each of the alternatives during
the Concept phase. Again, the level of formality depends on the degree of
SENSITIVITY of your application. Refer to the citations in Appendix B of this
document and the "EPA Information Security Manual" for more information on
available methodologies.
4.4.2.2 Selection of Specific Security Measures and Detailed Benefit-Cost Analysis
You follow the RISK ANALYSIS with selection of specific SECURITY MEASURES
from the types defined in the Concept phase and a much more detailed benefit-cost
analysis. While methodologies for doing this vary, they all share the following
elements:
4-i6
-------
OSWER DIRECTIVE #9028.00c
Selection of a broad range of specific SECURITY MEASURES which can
effectively counter the potential THREATS and reduce the identified
VULNERABILITIES
Determination of costs to develop or acquire, install, operate, maintain,
periodically evaluate and eventually archive these SECURITY MEASURES
Comparison of the life cycle costs of comparably effective SECURITY
MEASURES, choosing those which cost the least
Selection of those SECURITY MEASURES with benefits which outweigh the
costs (i.e., the most cost effective)
Chapter 9 of the "EPA Information Security Manual" describes a basic set of
SECURITY MEASURES derived from "Guidelines for Security of Computer
Applications" (FTPS PUB 73). Appendix C of this document also contains a Security
Measures Characterization Matrix, broken down into logical categories, which
should be helpful to you.
The selected SECURITY MEASURES should be added to the OSWER System Update
Form.
4.4.2.3 Specific Security Measure Definition
You follow the selection of each specific SECURITY MEASURE with a detailed
definition. Your definition descriptions must be at a level of detail to allow for the
design of each individual physical, technical, administrative, or managerial
SECURITY MEASURE in the next stage.
An example definition of a physical SECURITY MEASURE is:
"REPORTS A, B, and C are to be shredded as soon as they are out-of-date."
An example definition for a technical SECURITY MEASURE might be:
"No EMPLOYEE-RATE should exceed the MAX-RATE for the EMPLOYEE-
POSITION. If this occurs, the Security Officer should be notified."
or:
"Only the database administer is to have CREATE and DELETE access to the
EMPLOYEE-POSITION-RATE-TABLE."
4-17
-------
OSWER DIRECTIVE #9028.'00c
An example definition for an administrative SECURITY MEASURE is:
"An employee must be denied access to the application immediately upon
employee termination."
As shown in the above examples, SECURITY MEASURE definitions should be
expressed in a way that give the designers freedom of implementation. The
definitions can be expressed in English, as in the above examples, or in some tabular
or other structured format, such as a Decision Tree.
4.4.2.4 Security Measure Procurement
If any of your selected SECURITY MEASURES need to be purchased, leased, built,
contractor-supported, etc., now is the time to start planning your procurement
actions.
4.4.2.5 Test Criteria for Security Measures
During the Definition stage, you define test criteria and methodologies for each
specific SECURITY MEASURE.
Test criteria provide the basis for determining whether or not your SECURITY
MEASURES are in place and functioning effectively. An example SECURITY
MEASURE test criterion might be "no trivial passwords." You could measure
password control software against this criterion as well as user practices during the
Implementation and Production stages.
In your test methodology you define when each SECURITY MEASURE is to be
tested, by whom, and how. You may chose to integrate testing of your technical
software SECURITY MEASURES with all other software components during the
Design stage through peer reviews, walkthroughs, modeling, etc. Other technical as
well as physical and administrative SECURITY MEASURES may need to be tested or
evaluated periodically throughout the application life cycle to ensure that they are
in place and functioning effectively. For example, you may need to monitor user
access privileges frequently or make sure that user passwords aren't taped to
terminals.
4-i8
-------
OSWER DIRECTIVE #9028.00c
4.4.3 Special Considerations for Developmental Security Measures During the
Definition Stage
As during the Concept phase, your first concern is getting all your Definition stage
developmental SECURITY MEASURES in place and reviewing the effectiveness of
those already in place. For example:
Do you need to control access to documentation?
Have you identified who can authorize and who is authorized for each
document?
Do you have secure hardcopy storage available?
How will confidential documents be identified and marked?
4.4.4 Definition Stage Products and Baselines
Be sure to keep in mind that the following products and baselines may contain
definitions which you may need to keep confidential and that you may have to
implement SECURITY MEASURES to protect them from inadvertent or intentional
disclosure.
Revised OSWER System Update Form
You revise the OSWER System Update Form for the OSWER Data Resource
Directory to include a description of the defined SECURITY MEASURES and submit
this form to the OSWER Senior Information Resource Management Officer
(SIRMO). The revised form is also placed in the Definition baseline.
Detailed Functional Requirements
You include the definition of each selected SECURITY MEASURE in the Detailed
Functional Requirements.
Data Management Plan. Detailed Data Requirements, and Requirements Data
Dictionary
You update your application security management approach for data
AVAILABILITY, INTEGRITY, CONFIDENTIALITY, and APPROPRIATE USE in the
Data Management Plan. Don't forget to include your approach for data conversion
from hardcopy or existing databases if the data is SENSITIVE. The Detailed Data
Requirements document has specific sections for "Audit Trail Requirements" and
"Security Requirements." You describe access requirements (e.g., CREATE, READ,
4-lC
-------
OSWER DIRECTIVE #9028.00c
UPDATE, DELETE) for each entity or data element for each user category in.the
Requirements Data Dictionary.
Refer to the Practice Paper on "Data Management" in Part 3 of the OSWER System
Life Cycle Management Guidance.
System Test Document and Acceptance Test Document
You expand these two documents to include SECURITY MEASURE test criteria and
methodologies as described above.
Definition Decision Paper
At the end of the Definition stage you update the summary of your overall
application security management approach in the Definition Decision Paper.
Project Management Plan
At the end of the Definition stage, you update your overall application security
management approach for the remainder of the life cycle in the Project
Management Plan. You also update the Project Management Plan to reflect the
objectives accomplished as well as the key decisions made, activities completed or
underway, costs, products delivered, and baselines modified or added.
For applications with high or medium SENSITIVITY, be sure to include:
Revision of Concept phase topics
Results of detailed RISK ANALYSIS
Reference to the Detailed Functional Requirements for definitions of each of
the SECURITY MEASURES
Life cycle costs of each SECURITY MEASURE in the benefit-cost analysis section
Procurement approach for SECURITY MEASURES to be acquired
Resources for SECURITY MEASURE procurement
Handling of SENSITIVE data during conversion
You also need to develop and document an application security management
approach workplan for the Design stage. It should cover new objectives, key
decisions, activities, products and baselines. Be sure to address:
4-20
-------
OSWER DIRECTIVE #9028.00c
SECURITY MEASURES needed to be in place at the start of the Design stage
The methodology to be used to design each SECURITY MEASURE
The methodology to be used to design the test procedure(s) for each SECURITY
MEASURE
Design stage activities, as defined in Section 4.5
Refer to the topical outline for the Project Management Plan given in Part 2 of the
OSWER System Life Cycle Management Guidance for the Definition stage.
4.5 Application Security Management During the Design Stage
4.5.1 Overview
You planned your detailed application security management approach for the
Design stage during the Definition stage by confirming the Concept phase RISK
ANALYSIS and logically defining each needed SECURITY MEASURE. During
Design your approach addresses new project objectives and a number of new key
decisions, activities and products, as well as the creation of the Design baseline. See
Exhibit 4.5-1 for an overview of these topics.
By the end of the Design stage you will have:
Completed and submitted a Security Plan per OMB Bulletin 90-08, if required
Confirmed the RISK ANALYSIS performed earlier and submitted appropriate
worksheets and reports required for installations by the "EPA Information
Security Manual"
Specified each defined SECURITY MEASURE at a level of detail to allow for
development of software, physical database, external procedures, training
courses, user manuals, hardware, telecommunications equipment and facility
construction
Submitted funded procurement requests to the Procurement and Contracts
Management Division and requisitions for acquisition or modification of
special facilities to the appropriate organization
Completed design of each defined SECURITY MEASURE test procedure
Determined what SECURITY MEASURES need to be in place for the
Development stage
4-21
-------
EXHIBIT 4.5-1: DESIGN STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
jfc
rty PIJB. I raouM
or r«pon tor hMattna. I nqutad
a tor aacfl SECURITY MEASURE
Funded procurement fequaaa tor acquked SECURITY MEASURES
Teat procedures lor al SECURITY MEASURES
Menmc«tan el D» dupmaH tuga SECURmr MEASURES
DECISIONS
ACTIVITIES
PRODUCTS
PROJECT APPROACH
Who will be fMponaMe tor appUeaUon aeonfty
management approacft during OaaJgn tiaga?
Who will praeare. (evtew and erciiima Sacurty Plan. I
f*guir«d by OMB BulMtn KW6?
Who «Kil co
r*M«w « «pprov» MMtfon
OuaJUUve Rktk Analyte Workaneet or Quantitative
Riak Analytii Rapon. I required by EPA IntermaBon
Security Manual* Appandti C?
Who will provide, review and approve SECURITY
. MEASURE daaignt?
Who will complete, review end approve procurement
reo.u«*u lor acquired SECURITY MEASURES?
Who will provide, rovaw and approve SECURITY
MEASURE taata?
Who wil be reaponabta lor Daiietrjpinani stage
appfcjaion Mcurty mmagormn ^im
What mtthodotogw and loon «are
approach In Oatlgn Oeceiiofi Paper
1 «KU(ly TMMpwn
PfOiM MvtOOTIM PIM
iMd SECURITY
MEASURES iHdM to 0»iiHopmB> and
PHOJECJ EffCVTlON ACTlVmE3:
PMC« SECURITY MEASURES nM0«d torlh*
Daatgn aug* Mo «fl«a
Pnpm S*euty Pkjn par OM Butanln 90-08,
HraquMd
CompMi* ImaMton Ouclttlv* «ak Anon/tfe)
WorMtnMi or IrataJMton OuandMlva RWi
Apjtytk Report, N raqulrid
Produc* dwlgnt tor SECURITY MEASURES to
b* Indudcd m Sywam Deilgn, PtiyaJc*
Danhm Dwlgn «W Owlgn On* Oteflontry
CompM* SECURITY MEASURE procuramarf
ExpMKMd SECURITY MEASURE laai tmm and
proeMurw m Symiam Taat Oocumant and
Aeoapianoa Taai Oocumant
UPOATED:
Piojaa Manaojamant Plan
Oau Managamam PUn
Syatam Tail Oeamn'
Aoaapunoa Taat Ooumanf
NEW:
Inullailon OualuMwi Rhk Annyili Worujnaai or
OuantltaVv* Risk Anriyiii Rapon. par -EPA
MormaUon Sacurity Manual.' Appanda C (it
raaulrad)'*
Saoumy Plan, pw OMB BuM* 90-08 (it naiwaor*
Syitam Oaalgn*
Phytleal Oau BaM [Jaaign*
Oaogn Data Oeaonuy
Oatlgn OacWon Papar
*uvad In Oaaign baialina
anttoOSWERSIRMO
4-22
-------
OSWER DIRECTIVE #9028.00c
4.5.2 Design Stage Activities
4.5.2.1 Special Oversight Organization Requirements
The Office of Management and Budget (OMB) requires the agency to submit plans
for the "security and privacy" of "each computer system that contains sensitive
information" to the National Institute of Standards and Technology (NIST) and the
National Security Agency (NSA) for advice and comment. If you have an OSWER
Level I application (as defined in Part 3, "System Life Cycle Review and Approvals")
with medium or high SENSITIVITY, you will need to comply with OMB Bulletin
90-08. A citation is given in Appendix B. The Bulletin recommends a number of
traditional SECURITY MEASURES for various types of applications which were
compiled from other federal guidelines.
As noted in the Initiation and Concept phases, Appendix C of the "EPA Information
Security Manual" describes methodologies for conducting application and
installation RISK ANALYSES. Regardless of the RISK ANALYSIS methodology
you chose to use during the Concept phase and Definition stage, for applications
involving specific installations, you must complete a Qualitative Risk Analysis
Worksheet or an Installation Quantitative Risk Analysis Report.
4.5.2.2 Security Measure Design Specifications
Your first step is preparing design specification for your physical, technical,
administrative, and managerial SECURITY MEASURES. The following are
examples of the level of detail appropriate for design specifications:
Physical: Paper Shredder
Heavy-duty
1/3 HP motor
Paper size up to 15' x 11'
Shreds = 11/2"
Up to 6 sheets of 20 Ib paper
50' per minute
Technical: AUDIT REPORT #1A
If EMPLOYEE-RATE is greater than the MAX-RATE for the EMPLOYEE-
POSITION:
then
4-23
-------
OSWER DIRECTIVE #9028.00c
post EMPLOYEE-NAME, EMPLOYEE-RATE, MAX-RATE for the
EMPLOYEE-POSITION and VARIANCE-CODE of "13" in the
SECURITY-NOTIFICATION-FILE
Technical: Design Data Dictionary (For each data entity or element)
Create Authority = GROUP A
Delete Authority = GROUP A
Update Authority » GROUP A and B
Read Authority = All
Administrative: Access Control Procedures
Prior to actual termination, an employee's immediate supervisor must
provide the system administrator written notification of the termination
date.
At COB of the termination date, all system access privileges will be revoked by
the system administrator.
The Design stage is where you decide, along with your design team, how to actually
.implement each particular SECURITY MEASURE.
4.5.2.3 Security Measure Procurement
You also prepare design specifications for any hardware, software,
telecommunications equipment, services and facility SECURITY MEASURES you
are obtaining through procurement or requisition. Note that requests for special
locks and combination safes go to the Facilities Management and Support Services
Division. Don't forget that you may also need to incorporate SECURITY
MEASURES in the procurement or requisition packages, themselves, such as
contractor non-disclosure statements.
4.5.2.4 Security Measure Test Procedures
Based on the test criteria and methodologies you documented in the Definition
stage, you design test procedures for each SECURITY MEASURE and add these
procedures to the test documents. This includes tests for abnormal, unusual,
improbable and illegal conditions and considers the effect of not following manual
SECURITY MEASURES. In general your test procedures should include:
descriptions of your test input (e.g., data and simulated ADVERSE EVENTS)
4-24
-------
OSWER DIRECTIVE #9028.00c
expected results
steps necessary to set up the test
steps necessary to conduct the test
Keep in mind that some of your SECURITY MEASURES are tests themselves (e.g., a
variance report), so at times you are testing the effectiveness of a test.
You may need to incorporate some formal testing techniques into the Test
Documents for use in the Development stage. For example:
Static evaluation includes:
code review
penetration studies
- source code analyzers
Dynamic testing includes:
- execution of application with test data
program analyzers
- flaw hypothesis method, based on analogous flaws in other
applications
See "Guidelines for Security of Computer Applications" (FIPS PUB 73) for details.
4.5.3 Special Considerations for Developmental Security Measures During the
Design Stage
As with the previous phases and stage, your first concern is getting all your Design
stage SECURITY MEASURES in place and reviewing the effectiveness of those
already in place. For example:
Do you have technical access SECURITY MEASURES to prevent unauthorized
use of your proprietary computer-based design tools?
Do you need to have additional personnel screened and selected?
Do you need to brief Procurement and Contracts Management Division on any
SENSITIVE procurements?
4-25
-------
OSWER DIRECTIVE #9028.00c
Each member of the design team should be trained in the use of the design and
programming tools and standards and be made particularly aware of the
VULNERABILITIES of the Design stage. Typical techniques for avoiding these
VULNERABILITIES include:
Structured coding
Avoiding unnecessary programming
Isolation of user interfaces
Human engineering, which makes interfaces easy to use and understand
Avoidance of shared computer facilities, if possible
Isolation of critical code
Use of available SECURITY MEASURES provided by the Operating System
See "Guidelines for Security of Computer Applications" (FTPS PUB 73) for further
suggestions.
Your effective management of the Design stage improves application security and
reduces long-term costs: inadequate SECURITY MEASURES are difficult to improve
without major redesign, and excessive costs for administrative SECURITY
MEASURES may be needed later if the design exposes critical code or data. Also, the
design review is the last opportunity to identify VULNERABILITIES.
4.5.4 Design Stage Products and Baselines
As in the Definition stage, you should keep in mind that these products and
baselines may contain designs which may need to be kept confidential and that you
may have to implement SECURITY MEASURES to protect them from inadvertent
or intentional disclosure.
OMB Bulletin 90-08 Compliant Security Plan
If you have an OSWER Level I application (as defined in Part 3, "System Life Cycle
Review and Approvals") with medium or high SENSITIVITY, OMB Bulletin 90-08
requires that a Security Plan for the recommended.alternative be prepared and
submitted by the agency to NIST/NSA. A format for this document is given in the
Bulletin. The format highlights:
Application identification and description
'26
-------
OSWER DIRECTIVE #9Q28.00c
Design Decision Paper
At the end of the Design stage you update the summary of your overall application
security management approach in the Design Decision Paper.
Project Management Plan
At the end of the Design stage, you update your overall application security
management approach for the remainder of the life cycle in the Project
Management Plan. You also update the Project Management Plan to reflect the
objectives accomplished as well as the key decisions made/ activities completed or
underway/ costs, products delivered/ and baselines modified or added.
For applications with high or medium SENS/77WTY/ be sure to include:
Revision of Definition stage topics
Planning issues for installation of SECURITY MEASURES and application
security awareness and training
You also need to develop and document an application management approach
workplan for the Development stage. It should cover new objectives, key decisions,
activities, products and baselines. Be sure to address:
SECURITY MEASURES needed to be in place at the start of the Development
stage
The methodology to be used to develop each designed SECURITY MEASURE
The methodology to be used to perform unit and integration testing of each
SECURITY MEASURE
Development stage activities, as defined in Section 4.6
Refer to the topical outline for the Project Management Plan given in Part 2 of the
OSWER System Life Cycle Management Guidance for the Design stage
4.6 Application Security Management During the Development Stage
4.6.1 Overview
You planned your detailed application security management approach for the
Development stage during the Design stage. During development your approach
4-28
-------
OSWER DIRECTIVE #9028.00c
addresses new project objectives and a number of new key decisions, activities, and
products along with the creation of the Development baseline. See Exhibit 4.6-1 for
an overview of these topics.
By the end of the Development stage you will have:
Developed (i.e., coded) each software SECURITY MEASURE
Otherwise acquired or constructed each SECURITY MEASURE
Performed unit and integration tests of each of the SECURITY MEASURES
Drafted application security management aspects of operational documents
Complied with "EPA Information Security Manual", Appendix D, guidance in
preparation of an installation Continuity of Operations or application
Contingency Plan as one of your SECURITY MEASURES
Determined what SECURITY MEASURES need to be in place for the
Implementation stage
4.6.2 Development Stage Activities
4.6.2.1 Coding of Security Measures
Your first step is coding your software SECURITY MEASURES such as user
identification and authentication routines, audit trails, exception reporting, variance
detection, anomalies in volumes, etc.
4.6.2.2 Acquisition of Procured Security Measures
Throughout the Development stage you accept and put into place the SECURITY
MEASURES you procured or had built or modified.
4.6.2.3 Preparation of Operational Documents
You also write the SECURITY MEASURE sections of the User, Maintenance and
Operations Manuals, draft a separate Security Manual, if appropriate, and prepare all
application security awareness and training courses/modules and material.
4-29
-------
EXHIBIT 4.6-1: DEVELOPMENT STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
tnptomraton of DWWIVTW M^t XCLJRr
Cadi* ol aoMMr* S8CUWTY MEASURES
AequtoMon and MMton of Ohar SECUWTY MEASURES
Unl and Magraflon Tocong ol toltaa
ratanat SECURITY MEASURE
ConBnuty of ^kpiVtftanii nvt of AppAcBton COMk^sjnoy ^hfit V
iiMainaHMton «»aa SECURITY MEASURES
DECISIONS
SECUWTY MEASURES
ACTIVITIES
WHO nW ba raapombto tor appNcaUan aacurty
managaman approaoi duflng Qpiaajproi aug*?
QonQnucy ctf
pttm I nqukM by "EPA li«oni«u»i Scortr
Who «M ooM or HMD. rwtpw and
SECURITY MEASURES?
Who irtl p*rtonn and KOTO* unt and >mgi«luri
Ming ol SECURITY MEASURES?
Who wi onotn. iwiM and «praw epanttan
SECURITY MEASURE documantBlon and
precMuraa. MMIng a Scourty Uanuat I nquivtf?
Who <« 6* tmoant* tar ktvkvnafunon aag*
appacaion Mcurty mana9*mn appreaot?
What mairiodoiggm and MM « b* tawd tor
InDWrnnunon nag* *
managmwn acproaoi?
PROJECT EXg
Whu SECURITY MEASURES art noufed tor
Implamanuion nag* aoMMa?
PROJECT CQMT1MUATIOH OE
Oo wutt of SECURITY MEASURE WM and
in*gr>ion t«ca r*v«al unaooapuHa RISKS?
WiH invKnvnutlon nag* SECURITY MEASURES
e» >i plan By m* nan ol m* krvMmanuuon ataga?
PRODUCTS
Aaaign raapomUBy tor, rant** and
IwalaOon ConOnufyof Cpandona Plan or
Cenanganqr Plan
Aaalgn i«apon»ta% tor SECURrTY MEASURE oodhg
Aatlgn ivcenafeMy tor proouvd ISCUBnv
MEASURE k
Conoud fwto* of SECURITY MEASURE end* and
antorea ttandardi tar programing and Mdng
^
Aatlgn rwponttikr tor. i«Mav and
SECURITY MEASURE aaotona 4
Aaalgrt iwponaMly tor una and MagnBton
SECURrTY MEASURES
r SECURfTY MEASURE M caaaa a
UpdaM Om ManagamBM Pkn I naoaaaary
Sumwtn radnad an*aa»i Mcunty managonan
aacurlyn
PHOJECT rrtn
Pica SECURITY MEASURES
Coda loAMni SECURITY MEASURES
Aeguk* and kwal SECURrTY MEASURES
PrapM SECURrTY MEASURE atcdona «l
doajmam or tapanaa Saeuttir Manual. I nt
Tact SECURnY MEASURES
P(^»ara tatyartnn Contour a) CpanBtona
* Conongancy Plan
UPOATFO;
P»o)aa Managamanman
Oau Managamani Plan
SyMam Tau Oooumanc
Aocaoanc* Tad Oaeunan*
MEW;
*rr'1"'bl" ConUnganer Plan or Inaullaiion
Contfuff tt Qca>ai«na Plan, par "EPA Mvrrmon
SaourDy Manual* Aapanda 0 (t raqurM)".
OanaMpmam Syttanr
Maawnanea Manual"
UaarManuaT
OparaUon Manual"
SaouAy Manuar
Uaar Support M«an.i»~
0»«lopmani Oacakw Papar
*»«vadlnDaalgnb«Mtna
"l**6 ki Oavatopniam baMin*
aanio OSWER SIRMO
4-30
-------
OSWER DIRECTIVE #9028.00c
The "EPA Information Security Manual/' Appendix D, also requires an installation
Continuity of Operations plan or application Contingency Plan for all high or
medium SENSITIVITY applications where AVAILABILITY is a relevant SECURITY
OBJECTIVE.
One common problem with Continuity of Operations Plans is the omission of
procedures to restore operations at the original site. Don't neglect this important
part of the process.
4.6.2.4 Unit and Integration Testing of Security Measures
At the same time you prepare test data for unit and integration testing and conduct
these SECURITY MEASURE tests. This testing covers acquired (e.g., facilities,
hardware> telecommunications devices) as well as coded (i.e. software) and
procedural SECURITY MEASURES. It also includes testing of any procedural
SECURITY MEASURES described in the operational documents.
4.6.3 Special Considerations for Developmental Security Measures During the
Development Stage
As with the previous phases and stages, your first concern is getting all your
Development stage SECURITY MEASURES in place and reviewing the effectiveness
of those already in place. For example:
Have your programmers been briefed on SECURITY MEASURES?
How will you prevent or detect fraudulent changes to code?
Are all developmental computers virus free?
Do you have adequate procedures for disposing of SENSITIVE source and
object code listings?
Does the installation have a Continuity of Operations Plan for loss of your
developmental computer or you for your key programmers?
Modern information engineering methods enhance application security, since they
reduce both flaws in the implementation of SECURITY MEASURES and fraudulent
additions or changes to code. Techniques include:
Peer review
Making one other programmer equall) responsible
4-31
-------
OSWER DIRECTIVE *9028.00c
Program library that
- permits only authorized persons to access modules
- records all accesses
- associates control data (e.gv record, byte counts) with modules
- enables comparison of current version to previous versions
Special documentation of SECURITY MEASURE related code
Avoiding programmer association with operational application
Redundant computation
Program development tools such as:
. high level languages
- preprocessors
reformat source code
cross reference listings
- debugging aids
- 4GLs
"Guidelines for Security of Computer Applications" (FTPS PUB 73) provides further
details.
4.6.4 Development Stage Products and Baselines
Keep in mind that you may need to handle these documents as SENSITIVE
information, as in the Definition and Design stages.
Installation Continuity of Operations Plan or Application Contingency Plan
The Development baseline also includes the installation Continuity of Operations
Plan or application Contingency Plan, if required by the "EPA Information Security
Manual," Appendix D. A copy should be sent to the OSWER Senior Information
Resource Management Officer (SIRMO) for inclusion in the OSWER annual
security report to the Office of Information Resources Management (OERM).
4-32
-------
OSWER DIRECTIVE #9028.00c
The plan should cover: .
Maximum acceptable period of interruption
Identification of critical functions
Alternate processing installations and facilities
Backup and recovery procedures and drills
Details are available in "Guidelines for Security of Computer Applications" (FIPS
PUB 73) and the "EPA Information Security Manual/' Appendix D.
Security Manual
If necessary, write a separate Security Manual. An outline is provided in Part 2 of
the OSWER System Life Cycle Management Guidance. This is also submitted to the
OSWER Senior Information Resource Management Officer (SIRMO) for inclusion
in the annual security report for the Office of Information Resources Management
(OIRM).
Maintenance Manual. Operations Manual User Manual and User Support
Materials
Review the outlines of each of these operational documents (Part 2 of the OSWER
System Life Cycle Management Guidance) and provide input concerning SECURITY
MEASURE aspects, if not already covered by a separate Security Manual.
Source Code Comments
The OSWER System Life Cycle Management Guidance recommends that source
code comments be used in general to document the details of any module.
However, you should be aware that there is a tradeoff between good documentation
practices and introducing a potential VULNERABILITY by using detailed comments
in SECURITY MEASURE related code, because these comments could be used by
hackers to determine how to circumvent the SECURITY MEASURES.
System Test Document and Acceptance Test Document
You update your SECURITY MEASURES test procedures and document your unit
and integration test results in the System Test Document and the Acceptance Test
Document. Where applicable, you include both test data and results since these will
be used periodically throughout the life cycle for regression testing. Test results
should be reviewed for previously uncovered VULNERABILITIES.
4-33
-------
OSWER DIRECTIVE #9028.00c
Development Decision Paper
At the end of the Development stage, you update the summary of your overall
application security management approach in the Development Decision Paper, and
summarize the results of the Development stage, particularly testing, regarding
application security. Document any new VULNERABILITIES that have been
revealed by the testing process.
Project Management Plan
At the end of the Development stage, you update your overall application security
management approach for the remainder of the life cycle in the Project
Management Plan. You also update the Project Management Plan to reflect the
objectives accomplished as well as the key decisions made, activities completed or
underway, costs, products delivered, and baselines modified or added.
For applications with high or medium SENSITIVITY, be sure to include:
Revision of Design stage topics
Planning issues for installation of SECURITY MEASURES and application
security awareness and training
You also need to develop and document an application security management
approach workplan for the Implementation stage. It should cover new objectives,
key decisions, activities, products and baselines. Be sure to address:
SECURITY MEASURES needed to be in place at the start of the
Implementation stage
The methodology to be used to complete implementation of each SECURITY
MEASURE
The methodology to be used to perform system and acceptance testing for each
SECURITY MEASURE
Implementation stage activities, as defined in Section 4.7
Refer to the topical outline for the Project Management Plan given in Part 2 of the
OSWER System Life Cycle Management Guidance for the Development stage.
Data Management Plan
Revise the Data Management Plan, if necessary. Refer to the Practice Paper on "Data
Management" in Part 3 of the Guidance.
4-34
-------
OSWER DIRECTIVE #9028.00c
4.7 Application Security Management During the Implementation Stage
4.7.1 Overview
You planned your detailed application security management approach for the
Implementation stage during the Development stage. During implementation your
approach addresses new project objectives, and a number of new key decisions,
activities, and products as well as the updated Development baseline. See Exhibit
4.7-1 for an overview of these topics.
By the end of the Implementation stage you will have:
Performed system and acceptance testing of all Production stage SECURITY
MEASURES
Trained everyone who has a application security role and reported the results
of this training
Completed the Application Certification Worksheet
Updated the OMB Bulletin 90-08 compliant Security Plan drafted in the Design
stage
Determined what SECURITY MEASURES need to be in place for the
Production stage
4.7.2 Implementation Stage Activities
4.7.2.1 System and Acceptance Testing of Security Measures
You develop test inputs (e.g., data and simulated ADVERSE EVENTS) and conduct
penetration, system and acceptance testing on each SECURITY MEASURE to be
placed into production. You may choose to test your software SECURITY
MEASURES along with the testing of other software components or to test them
separately.
During system testing you ensure that all SECURITY MEASURES are compatible
with each other as well as other application requirements. For example, software
SECURITY MEASURES should not seriously degrade system response times.
Identification and authentication protocols should not significantly impede need-to-
know access.
4-35
-------
EXHIBIT 4.7-1: IMPLEMENTATION STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
^'''^^'^'^'^^^^^^^^^^^^^^^^^^^^^^aB^BMBBBB^BBBlBBiaBBBiaBBBBBBBBBBBBli
Mvtonawton ct kiMrnaruwn ataga SECUWTY MEASURES
Symm M aooapana Ming * pnduotan SECUWTY UCAJUAEI
RavMon of aaeutr Ptei par OMB tO-OS. I f
4 Pioduaton not S8CUWTY MEASURES
ACTIVITIES
PHQJECT APPROACH Pg
WHO mill M iwcontbM tor «x*fc«Jon MCuXlr
Who «« eonduct r»vt»» «*J ippnv* lytum «id
xapunot MOne * SECURITY MEA9UA6S?
Who «« (»*«. (» in« «crav» OUB 80-01
SECUflrTV
nuiarm and
u
MEASURE
Saouffl* Manual V nac«anry?
Who «M ba ivpdnibia tor aaevly aMnnaa and
tninng and prwara. fiMaw and appro** Sacun>
Ttdnlng SiaMmanT
Who and appro** AH* aDuii
Canmeauon Wonariaar?
Who «HI ba naoonabia tor Producdan nag*
yirj** 11"^** Mcurfly nanaganvnT?
PROJECT EXECUTION DEOSOH3:
PROJECT COWTINUAT1ON DfJCBlQMa:
Od SIRUO appro** Appilcaaon Cartincaaon
WorMh*ar7
Do raaula ct SECURtTY MEASURE irnam and
a rtvMl unaoaapuCM R8KS?
Wll «g Produodon BJ«* SECURrTY MEASURES M
in piaoa to* in* itan dt na Praduoton aMgaf
PRODUCTS
Mflng « «SOJBfTY MEASURES
AvJgn iweonttMy tor. rp*Mw and
o( OMB 9041 oarrvliM S
Aa^an naedntttdytar iwWon df SECURnY
MEASURE team df dpdnaanal documdM.
mcMlng Sdeunr Fhn. I raqukvd
Aaalgn iMpdmfeiiy tar daeurty i
M
Surmartarar>«d
approaeri In hpHn
ISECUROY MEASURES
knpavnanaflon aupd haj
CdndUQ ayafevn and
sccunrrr MEASURES
Ha«*j« OUB oanpM* Saourlr PHM
Rn*to SECURITY MANAGEMENT ai
Cdndua Mourty aMranaaa and nHng
P)«par* TraMng Rapon and SacutyTraMng
CompKwAppKaanC
UPPATED;
Projact Managaman nan
Oau Managamarl Plan
MaMananoa Manual'
Out Manual'
Oparatton Manual'
Saouflr* ManuaT«
U*ar Support MaMrM'
OMB KKK Cdmpllani Saeurtr Plan'.
MEW:
AppNeatbn Cartflcattoii WonanMi.
Praduoton Oau Oloionwy
IrrfilamamallBn OacU>n Papar
Trajning Rapon
Sacurity Trailing SuiwnanT*
'uvad in Odvataprnani MaaUna
aamidOSWERSlRMO
4-36
-------
OSWER DIRECTIVE #9028.00c
During acceptance testing, you make sure that your SECURITY MEASURES
adequately support each of the relevant OSWER SECURITY OBJECTIVES.
4.7.2.2 Application Security Awareness and Training
The "EPA Information Security Manual" requires that training itself be a SECURITY
MEASURE. You conduct general application security awareness and specific task
training during the Implementation stage, either in conjunction with other user
training or separately, so that all personnel with an application security role will be
in a position to fulfill their roles when the system goes into production. Be sure to
think broadly when identifying people for training: you may need to include such
diverse staff as managers, data generators, information disseminators, facility
operators, software and hardware maintainers, etc. Prepare a statement that security
awareness and training have been conducted for all appropriate personnel.
4.7.2.3 Completion of Application Certification Worksheet
If the application is of medium or high SENSITIVITY, you complete the Application
Certification Worksheet found in Appendix B of the "EPA Information Security
Manual." Note that the manual states that the worksheet be completed by the
application owner, reviewed by the owner's immediate supervisor, and approved by
the OSWER Senior Information Resource Management Officer (SIRMO).
4.7.2.4 Revision of OMB Bulletin 90-08 Compliant Security Plan
If necessary, you revise the OMB Bulletin 90-08 compliant Security Plan drafted
during the Design stage.
4.7.3 Special Considerations for Developmental Security Measures During the
Implementation Stage
As with the previous phases and stages, your first concern is getting all your
Implementation stage SECURITY MEASURES in place and reviewing the
effectiveness of those already in place. For example:
If you are converting an existing manual or automated database are you
adequately protecting the SENSITIVE data during transfer?
Have your trainers been screened?
4-37
-------
OSWER DIRECTIVE #9028.00c
Is there a procedure for reporting ADVERSE EVENTS during system and
acceptance testing?
Are you protecting your copyrighted software? .
4.7.4 Implementation Stage Products and Baselines
Updated OMB Bulletin 90-08 Compliant Security Plan
If necessary, an updated version of the Security Plan required by OMB Bulletin 90-08
is submitted to the OSWER Senior Information Resources Management Officer
(SIRMO).
Security Training Statement
Submit your Security Training Statement to the OSWER Senior Information
Resource Management Officer (SERMO) for inclusion in the annual security report
for the Office of Information Resources Management (OIRM). The Implementation
baseline includes a copy of the Security Training Statement.
Application Certification Worksheet
The Implementation baseline includes the completed and approved Application
Certification Worksheet. It is also submitted to the OSWER Senior Information
Resource Management Officer (SIRMO) for inclusion in the annual security report
to the Office of Information Resources Management (OIRM).
Security Manual
The Implementation baseline also includes the Security Manual, revised if
necessary based on the results of SECURITY MEASURE testing (i.e. failure of any
documented procedural SECURITY MEASURE). It is also sent to the OSWER
Senior Information Resource Management Officer (SIRMO) for inclusion in the
annual security report to the Office of Information Resources Management (OIRM).
Maintenance Manual. Operations Manual. Users Manual, and User Support
Materials
This is the last chance to revise the SECURITY MEASURE sections of any
operational documents before the Production stage.
Training Report
4-38
-------
OSWER DIRECTIVE #9028.00c
You document the results of the application security awareness and training (along
with any other training) in the Training Report, in addition to the Security Training
Statement mentioned above.
System Test Document and Acceptance Test Document
You document the results of system and acceptance testing of each SECURITY
MEASURE in the System Test Document and the Acceptance Test Document.
Implementation Decision Paper
At the end of the Implementation stage, you update the summary of your overall
application security management approach in the Implementation Decision Paper.
The decision to take the application into production should stress the results of
SECURITY MEASURE system and acceptance testing.
Project Management Plan
At the end of the Implementation stage, you update your overall application
security management approach for the remainder of the life cycle in the Project
Management Plan. You also update the Project Management Plan to reflect the
objectives accomplished as well as the key decisions made, activities completed or
underway, costs, products delivered, and baselines modified or added.
For applications with high or medium SENSITIVITY, be sure to include:
Revision of Development stage topics
Results of SECURITY MEASURE installation and tesh'ng and application
security awareness and training
You also need to develop and document an application management approach
workplan for the Production stage. It should cover new objectives, key decisions,
activities, products and baselines. Be sure to address:
SECURITY MEASURES needed to be in place at the start of the Production
stage
Production stage activities, as defined in Section 4.8
Refer to the topical outline for the Project Management Plan given in Part 2 of the
OSWER System Life Cycle Management Guidance for the Implementation stage.
Data Management Plan
4-39
-------
OSWER DIRECTIVE #9028.00c
Revise the Data Management Plan, if necessary. Refer to the Practice Paper on "Data
Management" in Part 3 of the Guidance.
4.8 Application Security Management During the Production Stage '
4.8.1 Overview
You completed your detailed application security management approach for the
Production stage during the Implementation stage, by completely testing and
certifying all SECURITY MEASURES. During the Production stage your approach
may alter operational project objectives, and affect a number of key decisions,
activities, and products and contribute to the Operational baseline. See Exhibit 4.8-1
for an overview of these topics.
Application security management during the Production stage involves:
Operation and monitoring of SECURITY MEASURES
Responding to ADVERSE EVENTS
Submitting modification requests
Ongoing application security awareness and training
4.8.2 Production Stage Activities
4.8.2.1 Operation and Monitoring of Security Measures
SECURITY MEASURES are now operating. Periodically, you may supplement these
routine SECURITY MEASURES by conducting informal inspections, such as spot
review of log sheets.
4.8.2.2 Responding to Adverse Events
During the Production stage, you must deal with ADVERSE EVENTS as they occur.
Your administrative SECURITY MEASURES should have detailed procedures for
handling these situations. For example, what steps would you take if an employee
intentionally introduced a virus into the application, mishandled confidential
business information, or shared a password?
In addition, application Contingency Plans or installation Continuity of Operations
Plans may be invoked by ADVERSE EVENTS. For example, a Contingency Plan
may be executed in response to the loss of a database. In response to a fire or flood or
hardware failure you will invoke a Continuity of Operations plan.
4-40
-------
UiWtK
EXHIBIT 4.S-1: OPERATION STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
Operation and periodic monitoring of SECURITY MEASURES
Responding to ADVERSE EVENTS
Modification requests
Ongoing security awareness and training
DECISIONS
ACTIVITIES
Who wli ft* fwponifeM tcr ocwaan md pvttfc
montonng « SECURITY MEASURES?
Do ADVERSE EVENTS rwwl pravtouUr
unmooemnd VULNERABLITIES m« nut b»
Mer«MO MMwur or cnMneM SECUROY
MEASURES?
WAD Ml bi rHpontbto lor ongoing Mcurtr
imiwim md ffH«ng and tor luBmong wnuM
Sccumy Tnjning Statonvir?
Hav« SECURITY MEASURES t
PROJECT CONTINUATION OCOMONt:
Hrn* ADVERSE EVENTS r»«iHd (nougn RISKS 10
pr«cM* oanunucd producngn?
Uontor SECURITY MEASURES
R«nmvid modfkalam » SCCUWTY
MEASURES. I HMMnr.»» Potarrane
AMlgn rHcovfeVy tor ongoing Mewfy I
MtraMng
Subnl SteuMy Training SMMnvt
R«on AOVERSC EVENTS
ConttniM Mcurty MMmM
Mn«03>MERSIRMO
4-41
-------
OSWER DIRECTIVE #9028.OOc
4,8.2.3 Modification Requests
You may uncover new VULNERABILITIES during the Production stage as the
result of day-to-day operation of SECURITY MEASURES. These should be handled
according to established OSWER System Life Cycle Management Guidance
Configuration Management procedures in Part 3.
4.8.2.4 Ongoing Application Security Awareness and Training
You need to repeat application security awareness and training as performed in the
Implementation stage for new employees, transferred employees, and periodically as
a refresher for existing employees. Update your Security Training Statement as
appropriate.
4.8.3 Production Stage Products and Baselines
Security Training Statement
Submit your Security Training Statement to the OSWER Senior Information
Resource Management Officer (SIRMO) for inclusion in the annual security report
for the Office of Information Resources Management (OIRM). The Implementation
baseline includes a copy of the Security Training Statement.
Performance Report
You may wish to summarize ADVERSE EVENTS and failures of SECURITY
MEASURES using the Performance Report format provided by Part 2 of the OSWER
System Life Cycle Management Guidance.
Other Life Cycle Documents
You may revise the SECURITY MEASURE sections of other documents as necessary
via OSWER System Life Cycle Management Guidance Configuration Management
procedures (Part 3).
4.9 Application Security Management During the Evaluation Stage
4.9.1 Overview .
Periodic formal evaluation under the OSWER System Life Cycle Management
Guidance monitors the operational project objectives, and addresses a number of
new key decisions, activities, and products and possibly alters the Operational
baseline. See Exhibit 4.9-1 for an overview of these topics.
' 4-42
-------
^rzw ir. t
EXHIBIT 4.0-1: EVALUATION STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
Certification of existing applications
R»-tvaJustJon of SECURITY MEASURES akxw or apart of
systam evaluation
IdentificationI of n«w VULNERABILITIES
Review and rt\ristan of oversight documents
9
Jk
KEY
DECISIONS
ACTIVITIES
PROJECT APPROACH
WTO «w b* r«ponitt* to aararyMo, »**-
Who MN b* rMpontfe* tor MruKton * SECURITY
MEASURES?
VUJ4ERA8LITIES t
WhooW
aoeurmni?
PROJECT EIECLTnOM DK3SJOMA:
MM tntn ewn
ITY?
SENStTrV-
Am SECURITY MEASURES
H OUB 90-0* eorro(*rt S«ur«r P«n du* tar imWon
(tnnuilY)?
It ln»!Jlnioo QuUUtlv* AniryU Wu>»h«a or
QuamiUiiv* An
-------
OSWER DIRECTIVE #9028.00c
Application security management during the Evaluation stage involves:
Certifying existing applications
Uncovering new VULNERABILITIES and recommending enhancements or
additions to SECURITY MEASURES as part of an overall system evaluation as
part of the life cycle
Analyzing occurrences of ADVERSE EVENTS that represents a significant
change in application security requirements and therefore re-evaluation.
Conducting appropriate evaluation and resubmitting oversight organization
documents as required
4.9.2 ' Evaluation Stage Activities
4.9.2.1 Certification of Existing Applications
All existing applications that have not yet been certified during the Implementation
stage must undergo a formal evaluation process and be certified for application
security using the process suggested in the "EPA Information Security Manual,"
Appendix B, including SENSITIVITY evaluation and RISK ANALYSIS. Poorly
designed applications may have to be upgraded through the life cycle process before
certification is possible.
Using the VLTLNEJMB/L/T/ES.uncovered in this RISK ANALYSIS, you can reduce
obvious RISKS immediately while taking the time to plan more thorough
SECURITY MEASURES and revise the application system using the life cycle
approach. This allows for integrating application security improvements with'other
purposes.
4.9.22 Security Enhancements
Enhancements to application security are handled through the life cycle as described
above, with one exception: proposed enhancements must be scrutinized for impact
on application security along with an evaluation of the INTEGRITY and motivation
of the person making the request.
4 11
-------
OSWER DIRECTIVE #9028.00c
4.9.2.3 Resubmission of Oversight Documents
Various oversight documents need to be resubmitted on a periodic basis (refer to
Exhibit 4.1-1), as follows:
The OMB Bulletin 90-08 Compliant Security Plan must be resubmitted
annually
The Installation Qualitative Risk Analysis Worksheet or Quantitative Risk
Analysis Report must be resubmitted every five years
The Application Certification Worksheet must be resubmitted every three
years
The following documents must be updated when significant changes occur or as
needed (refer to Exhibit 4.1-1):
Table for Sensitivity Evaluation
OSWER System Update Form
The Installation Qualitative Risk Analysis Worksheet or Quantitative Risk
Analysis Report, if applicable
Installation Continuity of Operations Plan or application Contingency Plan, if
applicable
Security Manual, if applicable
Application Certification Worksheet
4.9.3 Evaluation Stage Products and Baselines
Table for Sensitivity Evaluation
Use this worksheet from the "EPA Information Security Manual/' Section 4, to help
certify existing applications and also to evaluate enhancements. Submit it to the
OSWER Senior Information Resource Management Officer (SIRMO) for inclusion
in the annual security report to the Office of Information Resources Management
(OIRM).
145
-------
OSWER DIRECTIVE #9028.00c
OSWER System Update Form
Revise this form when significant changes occur. Submit it to the OSWER Senior
Information Resource Management Officer (SIRMO) for the OSWER Data Resource
Directory.
OMB Bulletin 90-08 Compliant Security Plan
Resubmit the Security Plan to the OSWER Senior Information Resource
Management Officer (SIRMO) every year for inclusion in the annual security report
to the Office of Information Resources Management (OIRM).
Installation Risk Analysis Worksheet or Report
Resubmit the appropriate Risk Analysis Worksheet or Report, if required by the
"EPA Information Security Manual/' Appendix C, to the OSWER Senior
Information Resource Management Officer (SIRMO) every five years and when
significant changes occur for inclusion in the annual security report to the Office of
Information Resources Management (OIRM).
Installation Continuity of Operations Plan or Application Contingency Plan
Resubmit the appropriate installation Continuity of Operations Plan or application
Contingency Plan, if required by the "EPA Information Security Manual/' Appendix
D, to the OSWER Senior Information Resource Management Officer (SIRMO) when
significant changes occur for inclusion in the annual security report to the Office of
Information Resources Management (OIRM).
Security Manual
Revise the Security Manual, if required, and submit it to the OSWER Senior1
Information Resource Management Officer (SIRMO) for inclusion in the annual
security report to the Office of Information Resources Management (OIRM).
Application Certification Worksheet
Submit the Application Certification Worksheet to the OSWER Senior Information
Resource Management Officer (SIRMO) for certifying existing applications and for
re-certifying every three years and when significant changes occur.
4-46
-------
OSWER DIRECTIVE #9028.00c
System Evaluation
Use the System Evaluation Report as a mechanism for periodic evaluation of the
application security aspect of the project. Its outline includes a section specifically
for security and a general section for functional and data improvements. Refer to
Part 2 of this guidance.
4.10 Application Security Management During the Archive Stage
4.10.1 Overview
SENSITIVE information and applications may remain SENSITIVE for a period of
time even after the application has been archived. During the Archive stage you
identify archive project objectives, and address a number of new key decisions,
activities, and products along with the archiving of the Operational baseline. See
Exhibit 4.10-1 for an overview of these topics.
Application security management during the Archive stage involves:
Seeing that SECURITY MEASURES for disposition of all INFORMATION
RESOURCES are carried out correctly
Certifying the disposition of archived documents and magnetic media to see
that each is destroyed and/or stored appropriately
4.10.2 Archive Stage Activities
4.10.2.1 Disposition of Security Measures
You should revisit the Sensitivity Evaluation worksheet from the Initiation phase
and RISK ANALYSIS from the Concept phase to help determine the potential
RISKS involved in archiving. The retention period for SENSITIVE information
should be considered.
Here you will carry out any SECURITY MEASURES designed during the life cycle
for the Archive phase (e.g., degaussing tapes, re-initializing memory, shredding
documents or securely storing documents, revoking accounts and passwords,
debriefing personnel).
4-47
-------
EXHIBIT 4.1O-1: ARCHIVE STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
Operation of Archive stage SECURITY MEASURES
Certification of disposition of SENSITIVE information and applications
~] PRODUCTS
MEA3UREST
Who b* mcorabl* lor atMKaOan
K iMotf «WOMIon ol SENSITIVE
PROJECT CONTINUATION OGCWOMB:
Oo« dl«eiMoo ol SENSITIVE mWMon ol
cau»* unwo«M«y RISK?
PHQJPCT f iFfflflTOti AenvmM!
OPWM ARCHIVE STAflS Mourt^ mMM
~
UPQATM-
AlOfeM MFORMATON RESOURCES.,
IWJUWO 6» SECURITY MEASURES
AftfUwdttocydidaaj,
AHWuMWMigmc
NgW;
4-48
-------
OSWER DIRECTIVE #9028.00c
4.10.^2 Certification of Archive Process
The System Disposition Report is the vehicle for certifying the disposition of
INFORMATION RESOURCES, including life cycle and oversight organization
documents.
4.10.3 Archive Stage Products and Baselines
System Disposition Report
You use the System Disposition Report to ensure and document that appropriate
SECURITY MEASURES are used during the archival process. You must secure the
archived Operational baseline appropriately. Keep in mind that stored material may
have to be reinstated at a later time along with applicable SECURITY MEASURES.
4-49
-------
OSWER DIRECTIVE #9028.00c
Appendix A: Terms
A-l
-------
OSWER DIRECTIVE #9028.00c
This appendix provides a glossary of terms that are either OSWER core concepts
(defined further/ with examples, in Chapter 2) or definitions derived from other
sources. Multiple definitions and synonyms are provided to resolve potential
discrepancies between this document and other applicable guidance documents.
Adverse Event
OSWER Core Concept:
In the broadest sense/the loss of an application's AVAILABILITY. INTEGRITY,
CONFIDENTIALITY or INAPPROPRIATE USE are ADVERSE EVENTS. Anything
that adversely affects any application INFORMATION RESOURCE is also an
ADVERSE EVENT since this in turn results in loss of AVAILABILITY, INTEGRITY,
CONFIDENTIALITY or INAPPROPRIATE USE or takes additional resources to
replace or recover.
Application Security
Other definition:
The set of controls that makes an information system perform in an accurate and
reliable manner, only those functions it was designed to perform. The set of
controls includes the following: programming, access, source document, input data,
processing storage, output and audit trail. (EPA Information Security Manual,
Appendix A, "Information Security. ")
Appropriate Use/Inappropriate Use
OSWER Core Concept
While INAPPROPRIATE use or misuse of an application may not result in direct
loss of AVAILABILITY, INTEGRITY, or CONF/DENTML/TY, misuse of our
INFORMATION RESOURCES is clearly undesirable and sometimes unlawful. In
OSWER we want to ensure that our applications are used for, and only for, support
of our programmatic mission.
A-2
-------
OSWER DIRECTIVE #9028.00c
Availability
OSWER Core Concept:
, -:*
OSWER develops applications to support our programmatic mission. The loss of
AVAILABILITY of any INFORMATION RESOURCE associated with an application
could affect the application's ability to support some aspect of the mission.
AVAILABILITY refers to our need to have our applications ready and able to
support our programmatic mission at the time they are needed.
Other definition;
Availability is associated with information where the loss of the information 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 time value. (EPA Information
Security Manual, Section I/ "General Information. ")
Benefit-cost analysis
OSWER Core Concept
Benefit-cost analysis is a systematic approach for comparing alternative ways to
satisfy an objective. Benefit-cost analyses are conducted throughout the OSWER life
cycle. The benefits to be realized through RISK reduction as well as the costs to
develop/ acquire, implement/ operate/ periodically evaluate and eventually archive
SECURITY MEASURES need to be considered along with all other application
benefits and costs.
Computer Application
Other definition:
The use for which a system is intentionally employed (NBS-500-109; page 3 quote
from FTPS 102, "Guideline for Computer Security Certification and Accreditation. ")
Svnonvm: application^)
A-3
-------
OSWER DIRECTIVE #9028.00c
Computer System
Other definition;
An assembly of elements including at least hardware and usually also software, data,
procedures, and people, so related as to behave as an interacting or interdependent
unity (NBS-500-109; page 3 quote from FTPS 102, "Guideline for Computer Security
Certification and Accreditation.")
Synonym: system(s)
Confidentiality
OSWER Core Concept:
Some OSWER applications contain data or provide information which during a
specified period of time is not subject to the Freedom of Information Act and must
not be disclosed without authorization. CONFIDENTIALITY refers to our need to
have certain of our data and information held in confidence.
Other definition:
Information where disclosure would be undesirable or unlawful. (EPA Information
Security Manual, Section 1, "General Information. ")
Information Resource
OSWER Core Concept:
Every OSWER application involves data, information, hardware, software,
documentation, facilities, telecommunications and trained staff. These components
of each application are our INFORMATION RESOURCES. All INFORMATION
RESOURCES have value in and of themselves. Equipment costs money to acquire,
replace or repair. Staff costs money to hire, retain and train. Software costs money
to develop and maintain. However, the ultimate value of our INFORMATION
RESOURCES are the support they provide to our programmatic mission.
Synonym: Asset, Information Asset
( "EPA Information Security Manual")
A-4
-------
OSWER DIRECTIVE #9028.00c
Integrity
OSWER Core Concept:
All INFORMATION RESOURCE components of an application must retain the
functionality they were designed to have in order to support the programmatic
mission. INFORMATION RESOURCES have INTEGRITY as long as their
functionality remains iincompromised; that is, they must do no more, no less than
their intended purpose.
Other definition:
Information or applications where accuracy and reliability are of particular concern.
In short, integrity is concerned with protecting information from corruption. (EPA
Information Security Manual, Section 1, "General Information. ")
Risk
OSWER Core Concept:
Technically, RISK, also termed "loss expectancy," is the predicted loss from an
ADVERSE EVENT during a certain period of time. RISK is often expressed in terms
of dollars and cents, but not always. The period of time is usually expressed in years,
but not necessarily so. For example, the RISK of having to reenter transactions
which were lost due to hardware failure could be $5 per update cycle. The RISK of
having to pay prompt payment penalties due to a software error in an accounts
payable program could be $25,000 per year. Non-monetary RISKS are sometimes
expressed in terms such as inconvenience, delay and loss of credibility.
Other definition:
Risk is the probability that an asset will be lost due to a vulnerability in dollars or
time units. (Computer and Communications Security, Strategies for the 1990s,
James Cooper.)
Risk Analysis
OSWER Core Concept:
The methodology to determine RISK by analyzing potential ADVERSE EVENTS,
THREATS, and Vl/LNEJMB/L/T/ES against INFORMATION RESOURCES, as well
as the likelihood of occurrence, is called RISK ANALYSIS. RISK ANALYSES are
A-5
-------
OSWER DIRECTIVE #9028.00c
either qualitative or quantitative. They may be conducted at a very summary level,
in great detail, or somewhere in between.
Qther definition;
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, qualitative review of microcomputer
installation to a formal, fully quantified review of a major computer center. (EPA
Information Security Manual, Appendix A, 'Information Security. ")
Security Measure
OSWER Core Concept:
SECURITY MEASURES counter or control THREATS, and are categorized by their
purpose (prevention, detection, minimization and recovery) and by general type
(physical, technical, administrative, and managerial).
Svnonvm; Safeguard, Control
( "EPA Information Security Manual")
Sensitivity/Sensitive
OSWER Core Concept:
All OSWER applications are SENSITIVE to some degree. This is because, to some
extent, they are VULNERABLE to loss of AVAILABILITY and/or INTEGRITY, to
INAPPROPRIATE USE and some to loss of CONFIDENTIALITY. However, there
are different degrees of SENSITIVITY depending on the relevance of OSWER's
SECURITY OBJECTIVES to the information management problem to be solved. For
example, AVAILABILITY might be very relevant to a mission critical application;
INTEGRITY to a decision support application, and CONFIDENTIALITY to an
application processing confidential business information. It follows that the greater
the relevancy, the greater the degree of SENSITIVITY.
Other definition;
Any information, the 'oss, misuse, or unauthorized access to or modification of
which could adversely affect the national interest or the conduct of Federal
A-6
-------
OSWER DIRECTIVE #9028.00c
programs, or the privacy to which individuals are entitled under the Privacy Act but
which has not been specifically authorized under criteria established by an executive
order or an Act of Congress to be kept secret in the interest of National Defense^ i
foreign policy. ("Computer Security Act of 1987/' PL100-235.)
Other definition;
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 sensitive or not sensitive. Because sensitivity is a matter of degree, certain
sensitive information is further defined as being "highly" sensitive. Highly
sensitive 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,
information critical to the performance of a primary agency mission, information
that is life critical and financial information related to check issuance, funds transfer
and similar asset accounting/control functions. Other sensitive 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
type includes Privacy Act information, Confidential Business Information,
enforcement confidential information, information that the Freedom of
Information Act exempts from disclosure, budgetary data prior to release by OMB
and information of high value to the agency or a particular organization. (EPA
Information Security Manual, Appendix A, "Information Security. ")
Threat
OSWER Core Concept:
A THREAT is anything that can cause an ADVERSE EVENT. Every application is
faced with countless THREATS. For the sake of simplicity, however, they can be
thought of as just two basic types: people and change to the environment. People
can deliberately or inadvertently cause ADVERSE EVENTS. THREATS can be as
obvious as an earthquake or as subtle as a virus. They can change throughout an
application's life cycle, and frequently do so.
A-7
-------
OSWER DIRECTIVE #9028..00c
OSWER Core Concept:
Where there is a chance that a THREAT can reach an INFORMATION RESOURCE
and cause an ADVERSE EVENT there is VULNERABILITY. Identifying and
communicating VULNERABILITY can be quite challenging. While some
VLJLNERAB/L/T/ES are immediately obvious (i.e., a password posted on the wall),
others may be much more technical or subtle (i.e., spaghetti code). In general, you
can assume that the more complex, distributed, and widely used your application is,
the more VULNERABLE it is.
A-8
-------
OSWER DIRECTIVE #9028.OOc
Appendix B: Reference Materials
B-l
-------
OSWER DIRECTIVE #9028.00c
The following documents and reference materials were used to prepare this practice
paper. The Information Management Staff (IMS) in the Office of Solid Waste and
Emergency Response (OSWER) would like to thank each of the authors for their
contributions toward the development of the Computer Application Security
Management Practice Paper. The EPA Headquarters Library and the Washington
Information Center were integral to the development of this paper and also deserve
recognition.
Documentation
Appendix 8 includes a summary of documents most currently applicable to the
management, security, and control of computer applications in the Federal
Government and is divided into the following categories:
Laws
« OMB Circulars and Bulletins
Special Publications and Guidelines
Federal Information Processing Standards (FIPS)
OSWER System Life Cycle Management Guidance (SLCMG)
Other Related Documents
Laws
Privacy Act of 1974 (Public Law 93-579). The Privacy Act of 1974 protects information
related to individuals that is maintained in Federal information systems. The Act
establishes specific criteria for maintaining the confidentiality of sensitive data and
guidelines for determining which data are covered by the Act. Under the Act
Federal agendes and employees are responsible for
Maintaining the confidentiality of data covered by the Act, and
taking those actions necessary to reasonable ensure that data (concerning
individuals) maintained in Federal information systems are accurate. Failure
to comply with these provisions can result in criminal and civil penalties for
both the agency and the employees of the agency found liable.
B-2
-------
OSWER DIRECTIVE #9028.00c
Electronic Communications Privacy Act of 1986 (Public Law 99-SMH. This legislation
establishes specific protections that update wiretap and privacy statutes to make
them more effective relative to advancements in technology. The legislation
protects remote computer services, electronic mail, cellular telephones
conversations, satellite transmissions, and other telecommunications technologies.
The law also establishes dear guidelines that must be met by Government officials
prior to requiring a remote processing services company to provide information
from a customer Hie.
The Computer Security Act of 1987(Public Law 100-23g). This law specifies
provisions related to the protection of computer-related assets (hardware, software,
and data) which include:
Assignment of responsibility for the development of computer security
guidelines and standards to the NIST.
Requirement that Federal agencies identify existing systems and systems under
development which contain sensitive information.
Requirement for development of a security plan for each identified sensitive
computer system within one year of enactment of the Act.
Requirement for mandatory, periodic training in computer security awareness
and accepted computer security practice of all employees who are involved
with the management, use, or operation of Federal computer systems.
OMB Circulars and Bulletins
Office of Management and Budget (OMB) Circular A-7T: Security of Federal
Automated Information Systems established that financial information should
be considered sensitive.
established that protection requirements exist for all internal control
information. Guidelines for conducting internal controls and preparing an
accreditation statement is provided.
Office of Management and Budget (OMB) Circular A-130; Management of Federal
Information Resources revises and consolidates Federal policy for the
management of Federal information resources by:
Recognizing that information itself is a valuable national asset that must by
managed and protected; and
B-3
-------
OSWER DIRECTIVE #9023.00c
Expanding the definition of security to include the appropriate functioning of
systems (i.e., systems must do exactly what they are supposed to do and nothing
more) as well as the protection of information that is within the systems.
Office of Management and Budget (OMB) Bulletin 90-08: Guidance for Preparation
of Security Plans for Federal Computer Systems that Contain Sensitive
Information established guidance for activities required by the Computer
Security Act of 1987.
Special Publications and Guidelines
U. S. Department of Commerce, National Bureau of Standards, Computer Science
and Technology, Security of Personal Computer Systems: A Manaeement Guide.
NBS Special Publication 500-120, January, 1985. Provides information on types of
security controls which can be used to ensure the security of personal computer
systems.
U. S. Department of Commerce, National Bureau of Standards, Guide on Selecting
ADP Backup Process Alternatives. NBS Special Publication 500-134,1985.
Provides managers and others responsible for developing automatic data
processing (ADP) contingency plans with an approach for selecting an alternative
data processing capability. A checklist for evaluating the suitability of the
alternative is provided.
U. S. Department of Commerce, National Bureau of Standards, Overview of
Computer Security Certification and Accreditation. NBS Special Publication 500-
109, April, 1984. Provides ADP policy managers, information resource managers,
ADP technical managers, and ADP staff with a comprehensive summary of and
guide to FTPS PUB 102, "Guideline to Computer Security Certification and
Accreditation," September 27,1983.
Federal Information Processing Standards (FTPS) Publications
The following descriptions were extracted from the "Federal Information Processing
Standards Publications Index/' February, 1988.
U. S. Department of Commerce, Guidelines for Security of Computer Applications.
NBS Standard Publication 73. Institute for Computer Sciences and Technology,
Federal Information Processing Standards Publication 73: June 1980. Describes
the different security objectives for a computer application, explains the control
-------
OSWER DIRECTIVE #9028.00c
measures that can be used, and identifies the decisions that should be made at
each stage in the life cycle of a sensitive computer application.
U. S. Department of Commerce. Guidelines for Computer Security Certification
and Accreditation. Institute for Computer Sciences and Technology, Federal
Information Processing Standards Publication 102: 1983. Presents a detailed
approach to developing a program and performing a technical process for
certifying and accrediting sensitive applications.
U. S. Department of Commerce, Guideline for Automatic Data Processing Risk
Analysis. NBS Standard Publication 65. Institute for Computer Sciences and
Technology, Federal Information Processing Standards Publications 65: August
1979. Presents a technique for conducting a risk analysis of an ADP facility and
related assets.
U. S. Department of Commerce, Guideline for ADP Contingency Planning. NBS
Standard Publication 87. Institute for Computer Sciences and Technology,
Federal Information Processing Standards Publication 87: March 1981. Describes
what should be considered when developing a contingency plan for an ADP
facility. Provides a suggested structure and format which may be used as a
starting point from which to design a plan to fit each specific operation.
OSWER System Life Cycle Management Guidance
U. S. Environmental Protection Agency, Office of Solid Waste and Emergency
Response, System Life Cycle Management Guidance. Directive #9028. 00, July,
1988. Provides EPA project managers with details concerning their
responsibilities under the OSWER System Life Cycle Management Guidance
(SLCMG).
U. S. Environmental Protection Agency, Office of Solid Waste and Emergency
Response, Practice Paper Data Management During the System Life Cycle.
Directive #9028. OOa, January, 1989. Provides EPA project managers with details
concerning their responsibilities for data management under the OSWER
System Life Cycle Management Guidance (SLCMG).
U. S. Environmental Protection Agency, Office of Solid Waste and Emergency
Response, Practice Paper Project Management Plan. Directive #9028. OOa,
January, 1989. Describes the structure and content of the Project Management
Plan, a key document of the OSWER System life Cycle Management Guidance,
and its evolution through the system life cycle.
B-5
-------
OSWER DIRECTIVE #9.028.00c
U. S. Environmental Protection Agency, Office of Solid Waste and Emergency
Response, Practice Paper; Configuration Management. Directive #9028. OOa,
January, 1989. Describes OSWER's practice of configuration management,
tailoring industry proven configuration management methods and techniques
to the OSWER environment.
U. S. Environmental Protection Agency, Office of Solid Waste and Emergency
Response, Practice Paper: Benefit- Cost Analysis. Directive #9028. OOa, January,
1989. Presents the benefit-cost analysis noted in the OSWER System Life Cycle
Management Guidance Parts 1 and 2 in the context of the OSWER program and
information management environment. This paper also complements Chapter
3: Options Anah sis, of the EPA Systems Design and Development Guidance,
Volume 8, issue by the Office of Information Resources Management.
Other Related Documents
Cooper, James Arlin, Computer & Communications Security. Strategies for the
1990's. 1989. Devotes most of its chapters to six aspects of security: physical
protection, personnel considerations, legal and regulatory aspects, hardware
security, software security, and network security. The last chapter of the book
does an excellent job of presenting a consolidated global approach with
projections for the future of computer and communications security in the
1990's.
U. S. Department of Energy, DOE Risk Assessment Guideline. A Structured
Approach. Office of ADP Management: DOE/ MA-0356 April, 1989. Provides
DOE with a 6 step approach for conducting a risk analysis with each step focusing
on a particular area of concern. Worksheets provide the necessary data sets and
an organized format to address each of the areas of concern.
U. S. Environmental Protection Agency, Automated Laboratory Standards:
Evaluation of the Standards and Procedures Used In Automated Clinical
Laboratories. Office of Information Resources Management, May, 1990. Describes
the findings of a review of standards and practices used in existing automated
systems in a limited number of laboratories in a clinical setting under the
assumption that these laboratories generate data of high integrity.
U. S. Environmental Protection Agency, Automated Laboratory Standards;
Evaluation of Good Laboratory Practices for EPA Programs. Office of Information
Resources Management, June, 1990. Describes the findings of a review of existing
Good Laboratory Practices (GLPs) as well as the impact of those standards on
automated laboratory practices. EPA's GLPs are regulations that describe
B-6
-------
OSWER DIRECTIVE #9028.00c
acceptable laboratory management practices to ensure the quality and integrity of
health, environmental/ and chemical data submitted to the Agency are met
U. S Environmental Protection Agency, Office of Information Resources
Management, EPA Information Security Manual. December, 1989. Establishes
security procedures for safeguarding Agency information resources and provides
overall guidance to EPA managers and staff in implementing those procedures.
U. S Environmental Protection Agency, Office of Information Resources
Management, EPA Information Security Manual For Personal Computers.
December, 1989. Establishes security procedures for safeguarding Agency
personal computers and provides overall guidance to EPA managers and staff in
implementing those procedures.
U. S. Executive Office of the President, Office of Management and Budget Model
Framework for Management Control Over Automated Information Systems.
January, 1988. Focuses heavily on the system life cycle as a means of
management control.
U. S. General Services Administration, Federal Systems Integration and
Management Center, Office of Technical Assistance, Information Technology
Installation Security. December, 1988. Written as guide to assist agencies in
establishing and maintaining a security program to protect unclassified
information handled at Government information technology installations.
U.S. Small Business Administration, Office of Business Development, A Small
Business Guide to Computer Security. April, 1987. Contains a detailed self-audit
checklist that is useful for smaller systems security management
Videos
The EPA Headquarters Library has the following computer/information security
video tapes available for check-out
"Data Security: BE AWARE or BEWARE"*
"Computer System Security: Access Control"
"Computer System Security: Access The Ins and Outs"
"InformaKon Security: Protecting Our Major Asset"
B-7
-------
OSWER DIRECTIVE #9028.00c
"Computer System Security: Access The Ins and Outs"
"Information Security: Protecting Our Major Asset"
* After a review within OSWER, this video will be shown in October during a series
of "brown bag" lunch sessions as part of the OSWER Security Program.
The Washington Information Center (WIC) has a selection of videos available for
check-out through their products and services contract with Applied Learning.
Applied Learning is a company in the business of providing training needs to
technology-based organizations. The following list is a sample of their selection:
"System Security Design Techniques7'
"Computer Security Techniques"
"Security Training"
"RACF Workshop Computer Security Overview"
"Security in Micro-to-Mainframe Links"
"VAX/VMS System Security"
"Controlling Information Systems"
"Corporate Computer Security Strategy"
"EDP Quality Assurance: A Management Overview"
B-8
-------
U. S. Environmental Protection Agency, C
Response/ Practice Paper Confiyuratic
January, 1989. Describes OSWER's pra
tailoring industry proven configuratio
to the OSWER environment.
U. S. Environmental Protection Agency, (
Response, Practice Paper Benefit-Cost
1989. Presents the benefit-cost analysis
Management Guidance Parts 1 and 2 ii
information management environmen
3: Options Analysis, of the EPA Systei
Volume B, issued by the Office of Infc
Other Related Documents
Cooper, James Arlin, Computer & Comm
1990's. 1989. Devotes most of its chapt
protection, personnel considerations, 1
security, software security, and netwoi
does an excellent job of presenting a o
projections for the future of compute]
1990's.
U. S. Department of Energy, DOE Risk t
Approach. Office of ADP Managemen
DOE with a 6 step approach for condu
on a particular area of concern. Works*.
an organized format to address each of t
U. S. Environmental Protection Agency, A
Evaluation of the Standards and Proced
Laboratories. Office of Information Ri
the findings of a review of standards
systems in a limited number of labor
{assumption that these laboratories ge
U. S. Environmental Protection Agency,
Evaluation of Good Laboratory Practi
Resources Management, June, 1990.
Good Laboratory Practices (GLPs) as
automated laboratory practices. EPA
-------
OSWER DIRECTIVE #9028.00c
Appendix C: Security Characterization Matrices.
C-l
-------
OSWER DIRECTIVE #9028.00c
Key to the development of an application security management approach and its
evolution through the OSWER life cycle is a thorough understanding of:
Types of INFORMATION RESOURCES
Typical ADVERSE EVENTS that may affect each type of INFORMATION
RESOURCE
Potential THREATS
Typical VULNERABILITIES that might compromise each type of
INFORMATION RESOURCE and allow a THREAT to cause an ADVERSE
EVENT
SECURITY MEASURES available to counter THREATS
This appendix provides detailed examples, in matrix format, showing how each of
these might be characterized and evaluated during the Initiation phase, Concept
phase, and Definition stage of the OSWER life cycle.
INFORMATION RESOURCES are categorized as follows:
Data
Information
Hardware
Software
Documentation
Facilities
Telecommunications
Trained Staff
The ADVERSE EVENTS (shown in Exhibit CM) and VULNERABILITIES (shown in
Exhibit C-3) are grouped according to these INFORMATION RESOURCE categories.
The THREATS (shown in Exhibit C-2) are grouped according to type, as follows:
C-2
-------
QSWER DIRECTIVE #9028.00c
THREATS from People, both deliberate and inadvertent
THREATS from Change to the Environment, both unexpected and planned
Each individual ADVERSE EVENT, THREAT, and VULNERABILITY is
characterized in three ways:
Source document
Applicability to the SECURITY OBJECTIVES of AVAILABILITY, INTEGRITY,
CONFIDENTIALITY, and APPROPRIATE USE
Applicability to each typical processing environment, as defined in the EPA
Information Security Manual. In general:
- Manual systems, or manual components of automated systems, are least
VULNERABLE.
- Stand-alone personal computers (PC) and word processors (WP) are
slightly more VULNERABLE.
- PCs involved in Local Area Networks (LAN) or remote access terminals
for larger systems are more VULNERABLE, in general, because of the
increased number of users involved and the geographic diversity of node
locations.
- Mainframe (MF) and minicomputer systems are most VULNERABLE, in
general, because of the large number of users, large number of concurrent
applications, and greater complexity of the applications.
Exhibit C-4 provides a detailed characterization for the various types of SECURITY
MEASURES that are available. The SECURITY MEASURES are grouped according
to type as follows:
Physical
Technical
Administrative
Managerial
In the first part of Exhibit C-4, each individual SECURITY MEASURE is
characterized in four ways:
C-3
-------
OSWER DIRECTIVE #9028.00c
Source document
Level (High, Medium, or LOW) of SENSITIVITY to the SECLTWTY OBJECTIVES
of AVAILABILITY, INTEGRITY, CONFIDENTIALITY, and APPROPRIATE
USE. This level is assigned according to the guidance in the "EPA Information
Security Manual. *
Purpose (Prevention, Detection, Minimization, or Recovery)
Applicability to each typical processing environment, as above
The second part of Exhibit G4 shows where and how each SECURITY MEASURE is
addressed in the OSWER life cycle, as follows:
Initiation Phase (Planning)
. _
Concept Phase (Analysis) ,
T .
Definition Stage (Requirements) rf.
» Design Stage (Design)
Development Stage (£ode/Test, Construct, or Acquire)
Implementation Stage (Implement)
Operation Stage (Use)
Evaluation Stage (Evaluate)
Archive Stage (Stop)
Further guidance on the use of these materials during the OSWER life cycle is
provided in Chapter 4. These matrices are designed to be used as a provocative tool
rather than as a comprehensive list. They are not to be considered complete or rigid,
and are intended to be tailored to fit particular projects.
G4
-------
EXHIBIT C-1: ADVERSE EVENTS CHARACTERIZATION MATRIX
Page 1
Adverse Events (by Information Resource)
Data
Loss
Damage
Inaccuracy
Information
Loss
Disclosure
Inaccuracy
FaNMficatwn
Misuse
Hardware
Failure
Malfunction (but not total failure)
Inability to restart
Loss
Misuse
Software
Failure
Invalid processing
Corruption
Loss
License Infringement
Misuse
DOfCftMUMttflft^MI
Lou
Inamtrary
Dtedocure
Misuse
SOURCE
B
E
B
F
F
F
F
E
E
F
F
OBJECTSVE
Avail.
V
V
V
V
V
V
V
V
V
Inteq.
V
V
V
V
V
V
V
V
V
V
V
V
Conlid
V
V
V
V
V
V
V
V
V
Use
V
V
V
V
V
V
TYPJCA
Mini/MF
V
V
V
V
>/
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
v
L PROCESSING ENVIRONMENT
LAN/Rem
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
PC/WP
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
Manual
V
V
V
V
V
V
V
V
v
v .
v
I
Legend for SOURCE:
E « mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
-------
EXHIBIT C-1: ADVERSE EVENTS CHARACTERIZATION MATRIX
Page 2
Adverse Events (by Information Resource)
Facilities
Loss
Damage (reduced capability)
Misuse
Telecommunications
Loss
Garbling
Misuse
Trained Staff
Loss
Productivilv Decrease
SOURCE
OBJECTIVE
Avail.
V
V
V
V
V
V
Inteo.
V
V
Conlid
V
V
V
Use
V
V
V
TYPICAL PROCESSING ENVIRONMENT
Mini/MF
V
V
V
V
V
V
V
V
LAN/Rem.
V
V
V
V
>/
V
V
V
PC/WP
^
V
V
V
V
Manual
>/
V
V
V
V
Legend toe SOURCE:
E mentioned in EPA Information Security Manual
F . mentioned in FIPS PUB 73
B » both
-------
EXHIBIT C-2: THREATS CHARACTERIZATION MATRIX
Page 1
Threats (bvTvDe)
Threats from People
DftKherale Actions
Oisgruntlemenl
Fear of computerization
Fear of performance monitoring
Fear over potential toes of job
Dismissal
Hostility
GflfMwal dissatisfaction
Maliciousness
Vandalism
Terrorism
Viruses/pranks/spoofing
Sabotage
deed
Theft
Fraud
Embezzlemenl
Influence actions (e.g.. Superfund enforcement)
Misuse of licensed software
|na/fwprtant Actions
Lack of training
Invalid data entry
Accidental modification/loss of data
Incorrect user commands
Misuse of licensed software
Carelessness
Erroneous source data
Invalid data entry
Accidental modification/toss of data
Incorrect user commands
Insufficient time to complete task
SOURCE
E
E
B
E
E
E
F
F
F
F
F
OBJECTIVE
Avail.
V
V
V
V
V
V
V
V
V
V
V
V
V
V
>/
V
V
Intea
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
Conlid.
V
V
V
V
V
V
V
V
V
V
Use
V
V
V
V
V
V
V
TYPICAL PROCESSING ENVIRONMENT
Mini/MF
V
>/
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
LAN/Rem
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
v
V
PC/WP
V
V
V
V
V
V
V
V
V
V
V
V
v
V
v
v
v
V
v
v
v
v
j
w
V
Manual
V
V
V
V
v
V
v
V
V
v
V
j
w
>|
j
n
j
V
J
Y
J
V
J
V
>/
Legend for SOURCE:
E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
-------
EXHIBIT C-2: THREATS CHARACTERIZATION MATRIX
Page 2
Threats (bv Type)
Tnreais tram cnvtronmeniai uuuiges
Unexpected Changes
Fire
Flood/water damage
Wind, earthquake, etc.
Debris
Change in humidity
Change in temperature
Oust
Smoke
Power failure/surge
Static
Planned Changes
Periodic maintenance
Packaged software upgrade
Custom software uoarade
SOURCE
OBJ
Avail.
V
V
V
V
V
V
V
V
V
V
V
V
V
Intea
V
V
V
V
ECTIVE
Contid
V
V
V
V
V
V
Use
V
TYPICAL PROCESSING ENVIRONMENT
Mini/MF
V
V
V
V
V
V
V
V
V
V
>/
V
V
LAN/Hem.
V
V
V
V
V
V
V
V
V
V
V
V
V
PC/WP
>/
>/
V
V
V
V
V
V
V
V
>/
V
V
Manual
>/
V
^
V
Legend for SOURCE:
E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
-------
EXHIBIT C-3: VULNERABILITIES CHARACTERIZATION MATRIX
Page 1
Vulnerabilities (bv Information Resource)
cna
Unprotected password
Uncontrolled access or poor authorization process
Non-erasure of temporary or deleted files
Poor backup/recovery practices
Poor media handling practices
Lack of validation
File handling utilities
Information
Unprotected password
UncontroUfKf access or poor authorization process
Information left on screen
Unsecured hardcopy
Improperly marked hardcopy
Undestroyed printer/typewriter ribbons
Hardware
Poor maintenance practices
Poor testing practices
Unprotected password
Uncontrolled access or poor authorization process
Software
Poor design practices
Poor coding practices
Poor testing practices
Poor backup/recovery practices
Lack of Configuration Management
Operating System and Utility flaws
Bugs In packaged software
Uncontrolled access or poor authorization process
Poor technical writing practices
Poor distribution/update
Lack of Confiouration Manaaemen!
SOURCE
F
E
E
E
E
F
E
E
F
F
OBJECTIVE
Avail.
V
V
V
\l
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
Intea.
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
v
V
V
V
V
V
V
V
V
Conlid
V
V
V
V
V
V
V
V
V
V
V
^
V
V
^
V
V
V
V
Use
V
V
V
V
V
v
v
V
V
V
V
V
V
V
V
V
V
V
TYPICAL PROCESSING ENVI
Mini/MF
V
V
V
V
^
V
V
^
V
V
V
V
^
^
V
V
V
^
V
V
V
V
^
V
LAN/Rem
V
V
V
V
V
V
V
v
V
V
V
V
V
V
V
V
V
V
V
v
v
V
V
V
PC/WP
V
V
V
V
V
V
V
V
V
V
V
v
V
v
v
v
v
v
v
V
J
»
J
»
J
»
-J
₯
V
v
w
J
»
ONMENT 1
Manual {
^
v
v
^
J
»
v
.
1
J
Y
V
Legend lor SOURCE:
E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-bolh t .
-------
EXHIBIT C-3: VULNERABILITIES CHARACTERIZATION MATRIX
Page 2
Vulnerabilities /
V
V
V
V
V
V
LAN/Rem.
V
V
V
V
V
V
V
V
V
V
V
PC/WP
v
>/
V
V
>/
V
Manual
V
V
V
V
V
V
Legend tor SOURCE:
E > mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-bolh
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 1
Security Measures (by type)
Physical Security Measures
Physical Access
Location:
Equipment located away from tratlic
Avoidance of ground floor, but lower than 3rd
Location away from external waUs
location in separate buiding
Location so that elevators can be monitored
Wate of brick or concrete
No windows or shatterproof windows
Avoidance of potential sources of explosions
Limited number of entrances
Equipment placed on stable secure platforms
Operations control outside/next to computer
Partition/pass through in I/O area
Locking:
Locking of equip/portables when not in use
System locks
Cover locks
Locks on doors and windows
Key/cipher/badge lock on operations area
Remote controlled locks
Closed circuit TV
Night alarm or guard
Alarm on emergency exits
High quality locks and hinges
Sensors on equipment/media
Secure area for test materials
SRC
E
E
E
E
E
E
E
E
E
B
E
E
E
OBJECTIVE
Intea. I Conl I Use
V V V V
V >/
V >/
V >/
V >/
V
V
V
V V
V
V >/
V >/
V V
V V
V >/
V V
M M M V
M M M V
M M M V
M M M V
V V V V
V V
V V V V
V V V
PURPOSE
Prv.iOei.lMin.iRec
V
V
V
V
V
V
V
V
V
V
V >/
V
V
V
V
V
V
V
V V
V V
V V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Rern! PC/WPl Manual
L L L
L V
V V V V
V V
^ V V V
^ V
V V
L V
L
V L L
V
V
V L L
* * ^
L I
* l_
L L
^ L
L L
ML v
M j
V
M v
M j I
V 1
^ V V J
w K v I
V V >/ j
* » VI
V V
1
V V V 1
Legend lor SOURCE: E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
Legend tor OBJECTIVE and ENVIRONMENT: H = High. M = Medium, L . Low. V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 2
Security Measures (by type)
Physical Security Measures (cont'd)
Physical Access (conl'd)
Evacuation:
Emergency exits open outward
. Master power switches readiy accessible
Periodic evacuation drib
Accessible exits
Inspection of exits regularly
use of existing pnysicaj secuniy 10 aovaraage
Convenient telephone wlh emergency numbers
Fnvimntnantal Controls
Heal/Humidity:
No direct sun and extremes of heat/cold
Separate air conditioner/heating controls
Multiple air conditioner units lor backup
Power:
Multistage surge protectors
Uninterruptible Power Supply
Backup generator with adequate capacity
Raised floors to protect cables
Radar shields in walls
Reoular inspection of cables
SRC
E
E
E
E
E
OBJECTIVE
Avail. 1 Intea. 1 Conl. 1 Use
V
V
V
V
V
V
V
V
V
L
M M
H H
V
V
V
J
V
PURPOSE
Prv.Tbet.lMinTlRec.
>/
V
V
V
V >/
V
V
V
V
V
>/
V
v
V
V
^
V V
PROCESSING ENVIRONMENT
Mini/MFl LAN/Rend PC/WPl Manual
V V V ^
L V V >/
V
V >/ V V
V V V V
1 V >/ >/
V V V V
V L L
V
V
V L L
M H
H
V
V V >/
V
V V V
V V V
Legend for SOURCE: E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-bolh
Legend for OBJECTIVE and ENVIRONMENT: H = High. M = Medium. L - Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 3
Security Measures fbv tree)
Physical Security Measures (cont'd)
Environmental Conirote (cont'd)
Dust/dirt/debris/slatic:
Air intakes above ground level
No food or drink In bnmedtale vicinity
No smoking in vidnky
Plastic covers over equipment
Cleaning of equipmenVfidere regularly
Antistatic floor covering, mats and sprays
Humidifiers to reduce static
No furniture thai coNects dust/static
Vacuuming ol carpeted areas frequently
Fro:
Rre resistant waJte property segmented
Rre resistant mats (floor, ceiling, furniture)
Fire dampers in ducts
Accessible fire extinguishers of correct types
Accessible handles for raising floors
Heat and smoke detectors
Audtole. resetable fire alarms
Convenient stations for manual alarm
Centralized fire suppression system
Alarm connected to fire department/agency
Master switch should turn off air conditioning
Fireproof vaults or cabinets
No storage of lammables
Paper supplies to minimum on-sile
Removal ol unused wiring
SRC
E
E
E
E
E
E
E
E
E
E
E
E
E
E
OBJECTIVE
Inteo, 1 Conf. 1 Use
V
V
V
V
V
V
V
V
^
V
V
V
V
^
V
V
V
M M
V
V
V
V
V
V
PURPOSE
Prv.lDel.lMin.lRac
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V V
V V
V V
V
V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFluVN/Reml PC/WP I Manual
V V V
L L L
L L L
V V V
V V V
w 1
L L L
1
L L
L V V
L V V
V V
V V V V
* » 'I
V V V V
» » »
L V V V
" » » V
V
L V V >/
fc » If If
V V V >/
* » w
V V V ^/
11 V
M J
v 2
v v
V H
rl
L >/
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 4
Security Measures (by type)
Physical security Measures (com o)
Environmental Controls (confd)
Fire(conrd)
Regular inspection of equipment
Regular inspection for Ira hazards
Automatic monitoring of air/heal controls
Fire extinguisher training
Periodic fire drite
Flood:
Drains and channels
Avoidance of water or steam pipes
Accessible waterproof pbstictoovers
Automatic shutoff sprinkler system
Accessible shutoH controls
Water sensors
Protected electrical outlets/function boxes
Proper facility siting
Sumo pumps
SRC
E
E
E
OBJECTIVE
Avail. 1 Intea 1 Conl. 1 Use
V
V
V
V
V
V
V
V
V
V
V
V
V
V
PURPOSE
Prv.lDet.lMin.lRec.
V
V
V
V
V
V
V
V
V
V
>/ V
V
V
>/ V
PROCESSING ENVIRONMENT
MiniMFlLANTReml PC/WPl Manual
V V V
V V V V
V
V V V V
V V V V
V V V >/
L L L L
L V V V
V V V
V V V V
L V
V V V >/
V V V V
V V V >/
Legend for SOURCE:
Legend tor OBJECTIVE and ENVIRONMENT:
E « mentioned in EPA Information Security Manual
F » mentioned in FIPS PUB 73
B-both
H High, M - Medium, L - Low, V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Pages
Security Measures (bv tvoel
Magnetic Madia Handling
Sensors to detect magnets
Avoidance of electrical and magnetic devices
Careful handling of floppies
Storage of media in jackets or original containers
No touching of surface of diskette platter
No labeling of floppies with a pencil or hard pen
Usage of disk file container when not in use
ParUng of heads before moving
Lx>ck-up of Media
Write Protection
Drives cleaned periodical^
Tapes/discs tested
EflJlinnMOJ Cara/Maintenancq
Statistical record reviews
Periodic eojuipment tests
Machine malfunction/system crash reports
Preventive maintenance
Escorting of vendor maintenance personnel
Room tidiness
Usar identity verification
Magnetic card
Kev
SRC
E
E
E
E
E
E
E
E
E
E
.E
OBJECTIVE
Intea. 1 Conf . 1 Use
V
V
V
V
V
V
V
V
M M M
M M
V
V
V
V
V
V
V
V
V V
V ^
PURPOSE
Prv.lOet.lMin.lRec
V
V
V
V
V
V
>/
V
V
V
V
V V
V
V
V
V
V
V V
V
V
PROCESSING ENVIRONMENT
MiniMFfLAN/Remi PC/WPi Manua
V
V L L
L L
V L L
V L L
L L
V L L
L L
VMM
VMM
V V >/
V V V
« »
V V V
* » »
V V V
* w
V V V
* ~
V V V
~ »
V V >/
»
V V V J
» M \
V V ^/ J
II »
v v v v
Legend tor SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
H - High. M - Medium. L - Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 6
Security Measures (by tvoe)
Technical Security Measures
Hardware Controls
User isolation
Alarm on unauthorized events
Identifiable remote terminals
Error detection during processing:
Parity and address bounds checks
Memory access control
Privileged command control
Hardware based passwords
User isolation
Hardware and software error logs
Error checking on memory access
.» .» * _
umtation to time spent on |ODs
Rfmwtim of atwAical oratifranRAS
Control of information transfers
Control of resource asocation
Control of OS utilities
Vims detection
Disconnection of idle terminals
CiMronuntcfliions
Machine readable badges for remote terminals
Dedicated lino
Host control of download and upload
Detection/correction of transmission errors
SRC
E
E
E
E
E
E
E
E
E
P
L
E
E
E
E
E
OBJECTIVE
Avail. 1 Intea 1 Conl. 1 Use
M M M V
win vn Rd »
M M M V
IW IVI nra
M M M V
M M M V
V V V
M M M V
M M M V
M M M V
° V V V V
M M M V
M M M V
M
M V V
V V
V V V V
V V V
V V V
V V V
V V V
PURPOSE
Prv.lDet.lMin.lRec.
V V
V
V
V
V
V
V
V
V
V
>/
J
»
V
V
V V V
V
V V
V >/
V V
V V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPJ Manual
M M
M
M
M
M
M
V V
M V
M V
M
V V
M V
V
V >/ V
V L M
V V
V
V V
V V
V V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E « mentioned in EPA Information Security Manual
F mentioned in FIPS PUB 73
B > both
H = High. M = Medium. L = Low. V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page?
Security Measures / V
V >/
V V
V >/
>/ >/
>/ V
V V
V V
V V
V V
V V
V V
V V
V V
V V
V V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manua
V V V
V
V V V
V V V
V V V
V V V
V V V
V V >/
V V V
V
V
V V V
V V V
V V V
V V V
w
V V >/
» V
V V V
' »
V V V
»
V V v
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-bolh
H = High. M = Medium. L - Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Paged
Security Measures (by type)
Technical Security Measures (cont'd)
Data validation fcont'dl
Validation during processing:
Dummy master records
Test transactions
Exceptions written to a He
Tracing
Sampling
Run number controls
Reconciliation of control totals
Off-line file scanning
*"* *" A I
Hounding error coraion
Data dictionary:
Security authorization information
Legal formats
Expected relationships
User identity verification
Enforce password use
Limit consecutive password failures
Voice print
Identity check upon changes to software
Identity check upon changes to auth. tables
Authorization
Authorization of people
Authorization for terminals
Authorization for use of modules
Authorization for modes of access
Authorization to data elements
SRC
B
F
F
B
B
F
F
F
F
F
F
F
B
E
F
B
OBJECTIVE
Avail. ImtealConf.l Use
V
V
V
V
V
V
V
V
V
V
V
V
V V V V
V M M V
V V V V
V V V V
V V V V
V V V V
V V V
V V V
V V
V V V
PURPOSE
Prv.lDel iMin iRec
V
V
V
V V
V V
V
V
V
V
V
V
V
V
V
V
V V
V V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
V V
>/ V V
V V V
V V
V V V
V V V
V V V
V V
V V
V V V
V V V
V V V
V M
M V
V
V >/
V V
>/ V
V V
V
V
V V
Legend for SOURCE: E « mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B = bolh
Legend for OBJECTIVE and ENVIRONMENT: H = High, M = Medium. L = Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Pages
Security Measures (bv tvoel
Technical Security Measures (cont'd)
Authorization fconl'di
Authorization to executable modules
Authorization to devices
Authorization to storage meow
Authorization to transactions
Authorization to control data
Protection of the authorization data
Label schemes tor conidentia! data
DiHerent interlaces tor different purposes
Passwords tied to authorization codes
Password protection of ties
Password protection of job runs .
Authorization related to:
Date/Time
Previous security violations
Concurrent activity
Delegation of authority to:
Interact with data
Authorize transactions
AbiMty to approve others
Ease of use to chanoe/revoke authorizations
SRC
B
B
B
F
F
F
F
F
F
F
F
F
F
F
OBJECTIVE
Avail. 1 Nea 1 Conf. 1 Use
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V ^ V
V V V
V V V
PURPOSE
Prv.lDet.lMinlRec
V
>/
>/
V
V
V V
V
V V
V
V
V
V V
V V
V V
V
V
V
V V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
V V
V V
V V
V
V
V V
V
V
V
V V V
V
V V V
V V V
* »
V V
V >/ V
* " »
V V V
" »
V V V
* * »
V V V
Legend tor SOURCE: E - mentioned in EPA Information Security Manual
F » mentioned in FIPS PUB 73
B-both
Legend tor OBJECTIVE and ENVIRONMENT: H - High, M - Medium. L - Low, V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 10
Security Measures (by type)
Technical Security Measures (cont'd)
JonmalUno
Basic logging
Recording of selected events
Inserting user identifiers into each record
Association of transactions with users
Before/alter imaging
Analysis of journal:
Dynamic analysis
Static (post-processing) analysis
Static Reports
Interactive query and report generation
Variance detection
Automated journals:
Selected activity by terminal/employee
Transactions of a given type
Events faling outside given parameters
Attempted accesses to restricted data
Excess resource usage
Changes mads to access privileges
Program detectable software errors
Abnormal terminations of jobs
Unauthorized use/mod of program/data
Dynamic monitoring:
Heal time owpiay at moraonng console
Real time alerts to management
Suspension/termination of process
Invocation of special moniiorim
SRC
E
F
F
B
F
F
F
OBJECTIVE
Avail. 1 Inteo. 1 Conf.l Use
V V V
V V V
M ^ V
V ^ V
* v
V V V
V V V
V V V
V V V
V V V
V V V
V V V
V V
V V V
V V V
V V
V V
V V
V V V
V V V
^ V V
V V V
PURPOSE
Prv 1 Del 1 Mini Rec
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
V V
V V
V M
V V
V V V
V
V V
V V
V V
V V
V V
V V
V V
V V
V V
V
V
V V
V
V
V
V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E « mentioned in EPA Information Security Manual
F » mentioned in FIPS PUB 73
B = both
H a High. M = Medium. L - Low, V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 11
Security Measures (by type)
Technical Security Measures (cont'd)
Encryption
Encrypting computer communications
Encrypting off-fine storage
Encrypting on-line files
Encrypting critical software
Hafrtpflpy RflniMts and Output
Automatic confidential markings
Continuity of Qpflf flljOflS
Automatic backuo
Use special editor to recover data
Automatic saving of working memory/files
Unities to recover deleted/reformatted data
Recreation of summary data from detail records
Designing tpf Sflfllpty
Design of audMable system
Design for exception reporting
Design to ensure rejected items are re-entered
Design of system to recover from disruptions
Restricted user interlaces
Design of easy to understand interfaces
Consideration of dedicated micro or mini
Redundant computation
High level languages
PreDfocessors
SRC
B
B
B
F
F
E
E
E
E
E
B
B
B
F
F
F
OBJECTIVE
Avail. I Intea I Conf. I Use
M
V
V V
V V
V
V
V
V
V
V
V V V V
V V V V
V V V
V
V V V V
V
V V V V
V V
V V
V V V V
PURPOSE
Prv. I Det.
V
V
V
V
V
V
V
V
V
V V
V
V V
Min. i Hec
V
V
V
V
V
V
V
V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/Mr! LAN/Rerd PC/VYP
M V
V
V V
V V
V V V
V ' V V
VMM
V
V MM
VMM
V V V
V V V
V V V
V V V
V V
V V V
»
V V V
»
V V V
V V v
» ₯
V V V
V
v
J
»
J
»
J
»
,/
V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E « mentioned in EPA Information Security Manual
F mentioned in FIPS PUB 73
B = both
H - High. M - Medium, L - Low. V » unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 12
Security Measures (bv type)
Technical Security Measures (cont'd)
pesipning lor Security (cont'd)
Isolation of code that is critical to security:
Checksums on object code
Hardware protection stales
Readonly memory
Programming for Se£mj|tf
Program library:
Limited access to modules
Recorded access to modules
Storage of previous versions of module
uooumeroeo socuniy oooe
Passwords not in logons/batch ties/keys
Tasting
Source code analyzers
Penetration analysis
SRC
B
B
E
B
B
B
B
E
E
E
OBJECTIVE
Avail. 1 Irteo 1 Conf . 1 Use
V >/ V
V >/ V
V V V
V V V
V >/ V
>/ V V
M M
V V V
V V V
PURPOSE
Prv iDel IMin IRec
V
V V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
>/ V
>/ V
V V
V >/ M
V V
V V
V M M
V V V
V V >/
Legend for SOURCE: E mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
I egend tor OBJECTIVE and ENVIRONMENT: H High, M - Medium. L - Low, V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 13
Security Measures / >/
V V
V V
1 V
V V V
^ >/ V
V V V
V-J J J
V V V
V V V
V V V V
V V V
V V
V V V
V V V
V V V V
V V V V
V V V V
V V V
V V V >/
PURPOSE
Prv.iDet.iMin.lRec
V
V
V
V >/
V
V V
V V
V V
J J 1 1
V V V V
V V
V V
V V
V
V V
V V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFiLAN/Rerd PC/WP.I Manual
L L L V
MM M M
M M M M
V V
V V >/ V
L L L L
V V V V
L L L L
^ ^ *. k.
VI ii
V V V
V V V V
* » »
V V V V
" " w
V V V V
"
V V V V
w » »
' V V V V
* ~ »
V V >| J
» K T|
L L L
* *
V V v j
» If »
L L I i/
»- L V .
L L L -J
«- L. Y
L L L V _
Legend for SOURCE:
Legend (or OBJECTIVE and ENVIRONMENT:
E = mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B - both
H = High. M = Medium. L = Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 14
Security Measures (by type)
Administrative Security Measures (cont'd)
Personnel Practices (cont'd)
Training:
Mandatory/periodic basic awareness training
Soecialized security traMno
Vf0W*WIMiW WWVMMHJ OTI|p
Training in mechanical details of equipment
Periodic driMs
Documentation:
Emergency shut-down procedures
Fire/evacuation procedures
Data handknoXnormal and emergency)
Review/distribution security plan
Posting of instructions/phone numbers
Documentation of aN job procedures
Physical Access
To equipment:
Monitoring access through single location
Tracking location of portables
Logging use of PCs/terminals
Property passes
Empl. badges with photo/signature/access
Visitor login/logout
Visitor escorts
Visitor badges
Challenging of strangers
No visitors at night
Night guard
Schedulina of two people in computer center
SRC
B
F
E
E
E
E
OBJECTIVE
Avail. 1 Irrtea. 1 Cont. 1 Use
V V V >/
V >/ V V
^ V V
V V V
V V
V
V >/ V
V V V
V V V
V V V
V V >/
V V V
V V V
V V V
V V V V
M M M V
M M M V
V V
V V V V
V V
V V V V
V V V
PURPOSE
Prv. iDet.lMin |Rec
V V
V V
V V V V
V V V V
V
V
V V V V
V V V ^
V
V V V V
V
V
V V
V >/
V V
V V
V
V
V
V
V
V V
PROCESSING ENVIRONMENT
Mini/MFlLAN/RerrJ PC/WPl Manual
L L L V
ii if
>/ >/ >/ >/
V V V
V V V V
V V
V V V V
V V V V
V V -J V
V V V ^
V V V V
V V >/
L L
V
V L L
V >/>/>/
M V
M >/
V V V V
V V V V
V V V V
V V
V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E » mentioned in EPA Information Security Manual
F = mentioned in FIPS PUB 73
B - both
H = High. M = Medium. L = Low, V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 15
Security Measures (bv tree)
Administrative Security Measures (cont'd)
Physical Access fconfdl
To equipment (cont'd):
Changing locks/badges periodically
Registered keys with number/control book
-DO NOT DUPLICATE- on keys
Procedure for tost keys/badges
Memorization of combinations
1 nn nf rtnlimirinfiflriiritiinft/nidhnrihf
To system:
List of authorized personnel
Passwords not shared
Passwords not written out or left out
Logoff PC/terminal when leaving ft
System/memory clear
Power off of unit to dear RAM
Controlled auto answer modems
Secured host telephone nosTinslructTpass.
Live data removed for maintenance
Backups
Original input in secure location
Retained copies of outputs
Backup as needed
Routine backup
More frequent backup
Labeled backup
Archive stored in accessMe separate location
Incremental bacfcuo accroach
SRC
E
E
E
E
F
E
F
E
B
E
E
E
OBJECTIVE
Avail. 1 Irtea 1 Conl 1 Use
V V V V
V V V
V V V
V V V
V V V V
V
M M M V
M M V
M M V
M M V
V V V
M M V
V V V
V V V
V V
V V V
V V V
L V
M M M
H H
V V
MM M
V
PURPOSE
Prv.iDei.iMin.iR6c
V
V
V
V V
V
V
V
V
V
V >/
V V
V
V V
V
V
V V
V V
V V
V V
>/ V
V V
V V
V V
PROCESSING ENVIRONMENT
MiniftiFiLAN/Rerd PC/Wpl Manual
V V V V
V V V V
V V V >/
V V V V
V V V V
V V V V
M M M
VMM
VMM
VMM
V
v
V V V
V
V V V
V V V V
. * *
V V V V
«
V L L M
* i- IVI
M M M
V H H
V V V
M M M H
. i °i
V V V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E - mentioned in EPA Information Security Manual
F = mentioned in FIPS PUB 73
B - both
H > High. M - Medium. L - Low. V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 16
Security Measures (by type)
Administrative Security Measures (confd)
Backups (cont'd)
Software backups
End user applications
Source
Loadable versions
Compilers or interpreters
Different forms - tape/microfiche/paper
Retention schedule for data files
Assigned responsibly tor availability
Periodic test of recovery procedure
Data Entry
Visual verification
Key veriication
Handling of Magnetic Madia
Dedicated disks for each application
Dedicated subdirectory for each application
Limited access to libraries
Prohibition of prog, access to production tapes
Library togs tor checkout/return
Only authorized users
AM media not in use
Records of sensitivity/age/use/owner
Special labeling/serial numbers
Expiration labeling
Deoaussina/erasim
SRC
E
E
E
E
E
F
F
E
E
F
B
B
B
E
E
OBJECTIVE
Avail. 1 Intea. 1 Conf 1 Use
,
M M
M M
M M
M M
M V
V V
V
V
V
V
M M V
MM V
V V
V V
M M V
M M V
M M V
V V
V
V
PURPOSE
Prv.lDel.lMin |Rec.
V V
V V
V V
V V
V V
V V
V \f
V V
V V
V V
V V
V V
V V
V
V V
V V
V V
V V
V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
V MM
V M M
V M M
VMM
M M V
V V V V
V V V V
V V V
V V V V
V V V
VMM
VMM
V V
V V
V V
V V
V V
V V
V V V V
V
Legend for SOURCE: E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-bolh
Legend for OBJECTIVE and ENVIRONMENT: H = High. M = Medium, L = Low, V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 17
Security Measures (bv type)
Administrative Security Measures (cont'd)
Software CopyrighJs/Ucenses a,nd Mastqr Copies
Adherance to licensing agreements
Use of software exclusively on EPA equipment
Agreements signed and Med with the vendor
Agreement in safe place with rogis. number
Central repository for master copies
Avoidance of shared diskettes
Unauthorised Use of Hardware arri Software
Blank forms stored in secure location
No usage for personal business
Training done with work related examples
Supervision
Pre-authorization of overtime
Instructions tor all job runs
Production scheduling responsbility
CflnHgtinttJOfl MjUVMBflMfll and Chance Control
Screening tor legitimate applications/changes
Procedure for authorizing changes
Accurate records
Library tool
Code reconciliation
Old code availability
Usage of original test data
Test runs kept as audit trail
Library system tor tape and disk storage
Auditor/users given documents and changes
CorfroMng programs moved into production
Periodic audits for completeness/authority
SRC
E
E
E
E
E
E
E
E
E
F
F
F
OBJECTIVE
Intea 1 Conf . 1 Use
V V
V V
V
V
V V
V V
V >/ V
V V V
V V V
V V V V
V V >/ V
V V V ^
V V V V
V V V V
V V V
V V V
V V V
V V V V
V V
V V >/
V V 1
V ^ V
V V V
V V V
V V V
PUf POSE
Prv.lOet. Min.JRec
V
V
V >/
V V
>/ V
V V
V
V
V
V V V
V V
v
V
V V
V
V V
V V V
V V
V
V
V
V V
V
V >/ V
PROCESSING ENVIRONMENT
Mini/MFiLAN/Rem! FC/VVP! Manual
L L L
L L L
L L L
L L L
L L L
V V
V V V V
L L L
L L L
V V V V
V V V V
" * »
V V V V
" * »
V V
V V V V
' »
V V V
L V V V
. * »
V V
V V V
" »
V V V
* »
V V V
. *
V V V
V
V V V
* " »
V V V
* ₯
V V V V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E - mentioned in EPA Information Security Manual
F = mentioned in FIPS PUB 73
B-both
H = High, M = Medium. L = Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 18
Socurilv Measures (by type)
Administrative Security Measures (confd)
User identity verification
Signature
Fingerprints
Manual login of batch job submitted
Standards for passwords:
6 character minimum
Letters and numbers
No personal information
Unique
Password changes controlled
Passwords changed quarterly at least
Authorization
Authorization of people
Memory dumps limited to user partition
Jou mailing
Operator^ob logs
Manual journals
Balancing of job loads to reduce errors
Variance detection
Review of journal
Observations (visual, electronic, photo)
Employee interviews and questionnaires
Undercover operations
Surprise visits
Scrutiny of employee reports
Audits
Breaches reported to aoorooriate EPA officials
SRC
B
F
E
E
E .
F
E
E
E
E
E
F
F
F
B
.F
E
E
OBJECTIVE
Avail I Intea I Conf. 1 Use
>/ >/ V V
V V V V
V V V V
M M V
M M V
M M V
V V V
M M M V
V M M V
V V V V
M MM V
M M M V
V V V V
V V V
V V V
V V V V
V V V V
V V V V
V V V V
V V V V
V V V
V V
PURPOSE
Prv. I Del. 1 Min. | Rec.
V
V
V V
V
V
V
V V
V
V
V
V V
V >/ V
V
V V
V
V
V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
V V >l
V
V
>/ V V
V V V
V V V
V ^ V
M V V
V M M
V V >/
M
M M M
V
V
>/ >/ V V
V V V >l
V V V V
V V >/ V
V V V >/
V V V V
V V V V
V V V V
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E = mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B = both
H = High. M = Medium. L » Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 19
Security Measures (bv tvoe)
Administrative Security Measures (cont'd)
Hardcopy Rftjp**fi ^rid Output
Separate output devices lor sensitive data
Printing of sensitive data under supervision
Controled production/dfetribution of output
Document Control and Tracking
Inventory
Sign out tog
Automated tracking
List of authorized recipients
Locked cabinet or room
Receipts
Mailing
Manual confidential markings
Photocopies
Only owner/custodian may make copies
Copies entered into tracking, own OCN
Disposal Practices
Shredding or burning of confidential reports
Erasure of magnetic tapes/disks
Erasure of disk soace
Destruction of exhausted ribbons
Inspection of wastebasket contents
Continuity Q( Qpflfflltflflfl
Restoration from backup
Replacement of software from master/vendor
Reoular preventive maintenance
SRC
F
E
E
B
E
B
B
E
E
E
E
E
E
E
E
F
OBJECTIVE
lnteo.IConf.IUse
V
V
M
M M V
M M V
V V V
V V V
M M M
M
M
V
M
M
M
M M
M M
M M
V V
V
M
V
PURPOSE
Prv.lDel.lMin.lRec
V V
V
V V
V
V >/
V V
V V
V
V
V
V
V V
V V
V
V
V
V
V
V
V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Remi PC/WPi Manual
V V
V V V
M V >/ M
M
v
V
M M M M
" IV!
M V V V
M V V V
V V V V
w » »
M V V M
* » IVI
M M M
w« nn
M M M
* iwi
V M M
* m
V V V x/
. * » V
V V V
. * * 1
V MM I
* * Wl 1
V v - V 1
Legend for SOURCE:
Legend for OBJECTIVE and ENVIRONMENT:
E « mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B = bolh
H » High, M - Medium. L - Low, V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 20
Security Measures (by type)
Managerial Security Measures
Insurance
Against physical damage to equipment
On media, programs, data and documents
For expenses in operating a backup site
Against business interruption
Third party liability
Employee bonding
Non-EPA Software and Viruses
No instalation without SIRMO permission
Management group responsible for security
Adequate supervision and scheduling
Delegation of respons. to mgrs. controlling data
Ability to change access levels
Holding employees accountable
Review of changes
Confidential data on LAN approved by OIRM
Jou mailing
Examination of log or analysis
Variance detection
Management inspection of event journal
Control of dynamic monitoring
Software Development Process
Audior review of design
Peer review of sections of code
Programming standards
Acceptance testina
SRC
E
F
B
B
F
B
OBJECTIVE
Avail. 1 Inteo. 1 Conf. 1 Use
V V
V
V
V
V V
L L L
V V V V
V V V V
V V V V
V V V V
V V V V
V V
V V V V
V V V V
V V V V
V V V
V V V
V V V
PURPOSE
Prv. iDet iMin.lRec.
V
V
V
V V
V V
V
V
V V
V
V
V
V
V
V V
V V
V
PROCESSING ENVIRONMENT
Mini/MFlLAN/Reml PC/WPl Manual
V V V
>/ V ^ ^
V V V
V V V
V V V V
V V V >/
L L L
V V V
VJ J J
V N V
v v v >r
V V
V V V V
V V V V
V
V V
V V
V V
VJ J
V V
V V >/
V V >/
V V V
Legend for SOURCE:
Legend tor OBJECTIVE and ENVIRONMENT:
E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B = both
H « High. M - Medium, L - Low. V = unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 21
Security Measures (bv type)
Managerial Security Measures (cont'd)
Continuity ot Qper alJons/Continpency Planning
Prioriiization of critical jobs
Inventory of into/procedures tor recovery
Evaluation of new systems as they come on-line
Redurtdancyincivsitespaoft/eojuipmerii
Emergency standby capability
Backup facility agreement/conditions
Formalized manual fafback procedures
Periodic review of contiraiily/corttingency plan
Periodic test of recovery program
National flflryrify Intomiatiftn
Folowing of NSI requirements
ADoroval of director OIRM
SRC
F
F
E
B
F
E
E .
OBJECTIVE
Avail. 1 Inteo. 1 Conf. 1 Use
V
V
V
V
V
M
V
V
V
H
H
PURPOSE
Prv | Del. 1 Min Rec
V V
V
V
V
V
V
^
V
V
V V V V
V V
PROCESSING ENVIRONMENT
Mini/MFiLAN/Remi PC/WPJ Manual
}
V V >/
V V V ^
V >/
V V
V V
V M M V
V H H
v v v
V V V
H H H >/
ii ^
H H H >/
Legend for SOURCE: E - mentioned in EPA Information Security Manual
F - mentioned in FIPS PUB 73
B-both
Legend tor OBJECTIVE and ENVIRONMENT: H - High, M - Medium, L - Low, V - unspecified
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 22
Security Measures (bvtvoe)
^*&_ ._._._ ^%__,.__JA__ MA^AA.. ___ _.
fnysicw aecufny MeMurea
Physical Access
Location:
Equipment located away from traffic
Avoidance of ground ftoor. but tower than 3rd
Location away from external wals
Location in separate building
Location so that elevators can be monitored
WaMs of brick or concrete
No windows or shatterproof windows
Avoidance of potential source* of explosions
Limited number of entrance!
Equipment placed on stable secure platforms
Operations control outside/next to computer
Partition/pass through in I/O area
Locking:
Locking of equip/portables when not in use
System locks
Cover locks
Locks on doors and windows
Key/cipher/badge took on operations area
Remote controlled locks
Closed circuit TV
Night alarm or guard
Alarm on emergency exits
High quatty locks and hinges
Sensors on equtoment/meola
Secure area for test materials
LIFE CYCLE PHASES/STAGES
In*.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
U
U
U
U
U
U
U
U
U
A
A
A
U
U
U
U
A
A
A
A
A
U
A
A
Del
U
U
U
U
U
U
U
U
U
R
R
R
U
U
U
U
R
R
R
R
R
U
R
R
1 Oesionl
U
U
U
U
U
U
U
U
U
O
D
U
U
U
U
U
D
O
D
D
0
U
D
D/l
Devef I
U
U
U
U
U
U
U
U
U
C
U
U
U
U
U
U
U
Impl.
U
U
U
U
U
U
U
U
U
1
1
U
U
U
U
U
U
1
U
1 Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Eval. 1
E
E
E
' E
E
- E
E
E
E
E
E .
E
E
E
E
E
E
E
E
E
E
E
E
E
Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend tor LIFE CYCLE PHASES/STAGES:
P = Plan D - Design U = Use
A = Analysis C = Code/Test .Conslucl/Acquire E = Evaluate
R = Reqts I = Implement S = Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 23
Security Measures (bv tvoe)
PbycJcal Security Measures (cont'd)
Physical Access fconfdi
Evacuation:
Emergency exits open outward
Master power switches readily accessible
Periodic evacuation drib
Accessible exits
Inspection of exits regularly
Use of existing physical security to advantage
Convenient telephone with emergency numbers
Environmental Cortmlg
Heat/Humidity:
No direct sun and extremes of heat/cold
Separate air conditioner/heating controls
Multiple air conditioner unto tor backup
Power:
Multistage surge protectors
Uninterruptfcle Power Supply
Backup generator with adequate capacity
Raised floors to protect cables
Grounded conductors
Radar shields in walls
Panels accessible only to aulh. personnel
Reoular msoection of cables
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
Cone, |
U
U
U
U
U
U
U
1
A
A
U
A
A
A
A
A
A
U
LIFE CYCLE PHASES/STAGES
Del.
U
U
U
U
U
U
U
U
R
R
U
R
R
R
R
R
R
II
iDesianl
U
U
U
U
U
U
U
U
D
0
U
0
D
0
0
0
0
U
Oevel. 1
U
U
U
U
U
U
U
U
U
C
U
Imp!
U
U
U
U
U
U
U
U
1
1
U
II
I Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
i Evai.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
i Arch.
S
S
S
S
S
S
S
S
S
S
s
S
s
s
s
s
s
g
Legend tor LIFE CYCLE PHASES/STAGES:
P-Plan O-Design U-Use
A Analysis C - Code/Test ;Constuct/Acquire E - Evaluate
R = Reqls 1= Implement S = Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 24
Security Measures (by type)
Physical Security Measures (cont'd)
Environmental Controls (oonfd)
Dust/dirt/debris/static:
Air intakes above ground level
No food or drink in immediate vicinity
No smoking in viciniry
Plastic covers over equipment
Cleaning of equipment/fillers regularly
Antistatic floor covering, mats and sprays
Humidifers to reduce static
No furniture that cotects dust/static
Vacuuming of carpeted areas frequently
Fire:
Fire resistant wafe properly segmented
Fire resistant mats (floor, ceiling, furniture)
Fire dampers in ducts
Accessible fire extinguishers of correct types
Accessible handles for raising floors
Heat and smoke detectors
Audible, resetable fire alarms
Convenient stations for manual alarm
Centralized fire suppression system
Alarm connected to ire department/agency
Master switch should turn off air conditioning
Fireproof vaults or cabinets
No storage of lammables
Paper supplies to minimum on-site
Removal of unused wiring
LIFE CYCLE PHASES/STAGES
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
U
U
U
U
U
U
U
U
A
A
A
U
A
A
A
U
A
A
A
A
U
U
U
Del.
R
U
U
U
U
U
U
U
U
R
R
R
U
R
R
R
U
R
R
R
R
U
U
U
iDeswnl
D
U
U
U
U
U
U
U
U
D
D
D
U
0
D
0
U
D
0
D
D
U
U
U
Devel 1
C
U
U
U
U
U
U
U
U
U
U
U
U
U
Imol.
1
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Prod. 1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Eval.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
| Arch.
S
S
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
Legend lor LIFE CYCLE PHASES/STAGES:
P - Plan 0 - Design U = Use
A - Analysis C = Code/Test ;Conslucl/Acquire E = Evaluate
R-Req'ls I = Implement S = Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 25
Security Measures (bv tvoe)
Physical Security Measures (cont'd)
Environmental Controls fcont'dl
Fire (confd)
Regular inspection of equipment
Regular inspection for fire hazards
Automatic monitoring of aMteat controls
Fire extinguisher training
Periodic fire drifts
Flood:
Drains and channels
Avoidance of water or steam pipes
Accesstob waterproof plastic/covers
Automatic shutoff sprinkler system
Accessible shutott controls
Water sensors
Protected electrical outlets/junction boxes
Proper facity siting
SumoDumoe
Init.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
Cone. 1
U
U
A
U
U
A
A
U
A
A
A
A
A
A
LIFE CYCLE PHASES/STAGES
Del.
U
U
R
U
U
R
R
U
R
R
R
R
R
R
iDesianl
U
U
D
U
U
D
0
U
D
D
0
D
D
D
Devel. 1
U
U
U
U
U
Imol.
U
U
1
U
U
U
1 Prod
U
U
U
U
U
U
U
U
U
U
U
U
U
U
i hvai
E
E
E
E
E
E
E
E
E.
E
E
E
E
E
! Arch
S
$
S
S
S
S
S
S
S
S
S
S
S
S
Legend tor LIFE CYCLE PHASES/STAGES:
P-Plan D- Design
A - Analysis C - Code/Test ;Constucl/Acquire
R-Reqls I- Implement
U-Use
E Evaluate
S-Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 26
Security Measures (by type)
Physical Security Measures (cont'd)
Magnetic Madia Handling
Sensors to detect magnets
Avoidance of electrical and magnetic devices
Careful handling ol Itoppiea
Storage of media in jackets or original containers
No touching of surface of diskette platter
No labeling of floppies with a pencil or hard pen
Usage of disk file container when not in use
Parking of heads before moving
Lock-up of Media
Write Protection
Drives cleaned periodically
Tapes/discs tested
EOUJPfflflnJ CafQ/Mairtenanca
Slfistical record reviews
Periodic equipment tests
Machine malfunction/system crash reports
Preventive maintenance
Escorting of vendor maintenance personnel
Room tidiness
User identity verification
Magnetic card
Key
LIFE CYCLE PHASES/STAGES
Init.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
A
A
Del.
R
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
R
R
lOesionl
0
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
D
0
Devel. I
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
C
C
Imol.
1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1
1
1 Prod. 1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Eval.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend for LIFE CYCLE PHASES/STAGES:
P - Plan O - Design U = Use
A - Analysis C « Code/Tesl;Constucl/Acquire E » Evaluate
R= Reqls I = Implement S = Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 27
Security Measures (bv tvoei
Technical Security Measures
Hardware Controls
User isolation
Alarm on unauthorized events
Identifiable remote terminals
Error detection during processing:
Parity and address bounds checks
Memory access control
Privileged command control
Hardware based passwords
Oner atifM System Controls
1 ICAT i«nlatinn
Co
.1 fe. 1
Hardware ana software error logs
Error checking on memory access
Limitation to time spent on jobs
Recording of atypical occurrences
Control of information transfers
Control of resource alocation
Control of OS utilities
Virus detection
Disconnection of idle terminals
Machine readable badges for remote terminals
Dedicated fine
Host control of download and upload
Detectton/correction of transmission errors
int.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
LIFE CYCLE PHASES/STAGES
Cone. 1 Del.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
iDesnnl
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
Devel. 1 Imol.
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
i Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Legend tor LIFE CYCLE PHASES/STAGES:
P-Plan D- Design
A -Analysis C - Code/Test ;Consluct/Acquire
R - Reqls 1 . Implement
i Evai. !
E
E .
E
E
E
E
E
E '
E
E
E
E
E
E
E
E
E
E
E
E
E
Arch.
S
S
S
S
S
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
0
U = Use
E = Evaluate
S = Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 28
Security Measures (by type)
Technical Security Measure* (cont'd)
Dala validation
Machine readable source
Validation during data entry:
tljfc>j»h. milLrJ r*lL^j* frt4kfc^0M MMW^AAC in/%
tsaicn - vauoaiion Denra processing
On-line - immediate correction
Individual field checks:
Format (legitimate characters)
Proper sequences
Reasonableness
Consistency to other Setts hi record
Ranges of valid values
Codes for valid values
Self-checking numbers
Cryptographic check digits
Record checks:
Completeness (required fields)
Completeness (related records)
Consistency against other records
Valid fiAfMiAncMt nf transact kwMt
Record group checks:
Control totals
Record/transaction counts
Batch number checks
Hem/transaction balances
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
A
A
A
A
A
A
A
A
A
A
A
A
A
f^
A
A
A
A
LIFE CYCLE PHASES/STAGES
Def.
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
D
D
0
D
0
D
D
0
D
D
D
0
D
0
0
D
0
1 Devel. 1 Imol.
C
C
C
C
C
C
C
C
C
C
C
C
C
c
w
c
c
c
c
1 Prod. 1
U
u
U
u
u
u
u
u
u
u
u
u
u
u
u
u
u
Eval.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
1»
E
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
s
\J
s
s
s
s
Legend for LIFE CYCLE PHASES/STAGES:
P«Plan 0«Design U - Use
A « Analysis C = Code/Test ;Conslucl/Acquire E = Evaluate
R-Reqts I- Implement S = Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 29
Security Measures (bv tvoe)
Technical Security Measures (cont'd)
Data vacation fconfdi
Validation during processing:
Dummy master records
Test transactions
Exceptions written to a Be
Tracing
Samplng
Run number controls
Reconciliation of control totals
Ott-ine fie scanning
Rounding error controls
Data dictionary:
Security authorization information
Legal formats
Expected relationships
User identity VMifir-atk^i
Enforce password use
Limit consecutive password failures
Voice print
Identity check upon changes to software
Identity check upon changes to auth. tables
Authorization
Authorization of people
Authorization for terminals
Authorization for use of modules
Authorization for modes of access
Authorization to data elements
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
Cone. 1
A
A
A
A
A
A
A
A
A
A/R
A/R
A/R
A
A
A
A
A
A
A
A
A
A
LIFE CYCLE PHASES/STAGES
Oef.
R
R
R
R
R
R
R
R
R
U
U
U
R
R
R
R
R
R
R
R
R
R
lOesionl
D
0
D
0
D
0
D
0
0
U
U
U
D
D
D
DC/I
DC/I
D
D
D
D
D
Devei. i
C
C
C
C
C
C
C
C
C
U
U
U
C/U
C/U
U
U
C/U
C/U
C/U
C/U
C/U
impi.
U
U
U
U
U
1
U
U
U
U
U
U
II
i Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
! Eva!
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
! Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
s
S
\j
s
3
Legend for LIFE CYCLE PHASES/STAGES:
P - Plan D - Design u»Use
A * Analysis C = Code/Tesl;Consiuct/Acquire E = Evaluate
R-Regis l~ Implement S~Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 30
Security Measures (bv type)
Technical Security Measure* (cont'd)
Authorization fconl'di
Authorization to executable modules
Authorization to devices
Authorization to storage media
Authorization to transactions
Authorization to control data
Protection of the authorization data
Label schemes lor confidential data
Different interfaces for different purposes
Pas&MKMfe liwl to MittwwizatkM cocta&
Password protection of files
Password protection of job runs
Authorization related to:
Date/Time
Previous security violations
Concurrent activity
Delegation of authority to:
Interact with data
Authorize transactions
Ability to approve others
Ease of use to chame/revoke authorizations
LIFE CYCLE PHASES/STAGES
mil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Def.
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
1 Desionl
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
Devef 1
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
C/U
Imol.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Eval.
E
E
E
E
E
E
E
E
E
E
. E
E
E
E
E
E
E
E
7 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend for LIFE CYCLE PHASES/STAGES:
P-Plan D-Design U-Use
A - Analysis C - Code/resl;Constuct/Acquire E « Evaluate
R-Reqls I- Implement S-Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 31
Security Measures (bv tvoe)
Technical Security Measures (cont'd)
Joiimallinq
Basic togging
Recording of selected events
Inserting user identifiers into each record
Association of transactions with users
Before/after imaging
Analysis of journal:
Dynamic analysis
Static (post-processing) analysis
Static Reports
Interactive query and report generation
V/4«4VW*A ^4^^^W^WM%
Automated journals:
Selected activity by terminal/employee
Transactions of a given type
Events fating outside given parameters
AliufBMljJaii AMfMMUM lA nMttriptAfi ft AtA
Excess resource usage
Changes made to access privileges
Program detectable software errors
Abnormal terminations of jobs
Unauthorized use/mod of program/data
Dynamic monitoring:
Real time display at monitoring console
Real time alerts to management
SuspensionAermination of process
Invocation of special morftorina
LIFE CYCLE PHASES/STAGES
Inn.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Def.
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
iDesianl
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
Devei. i impi:
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
! Prod.
U
U
U
U
U
U
U
U
U
U
U
U
u
u
u
u
u
u
u
u
u
i Eva!.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
i Arch
S
S
S
S
S
S
S
S
S
S
S
S
S
S
s
s
s
s
s
s
s
Legend tor LIFE CYCLE PHASES/STAGES:
P - Plan D - Design u = Use
A - Analysis C - Code/Test;Consluct/Acquire E = Evaluate
R-Reqls I- Implement S = Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 32
Security Measures (by type)
Technical Security Measures (cont'd)
Encryption
Encrypting computer communications
Encrypting off-line storage
Encrypting on-line Met
Encrypting critical software
HflfitoOPy Reports HJYJ PtMP"!
Automatic confidential markings
Continuity of Operation^
Automatic backup
Use special editor to recover data
Automatic saving of working memory/files
Utilities to recover deleted/reformatted data
Recreation of summary data from detail records
Designing tor Sqflirijy
Design of audttabte system
Design for exception reporting
Design to ensure rejected items are re-entered
Design of system to recover bom disruptions
Restricted user interfaces
Design of easy to understand interfaces
Consideration of dedicated micro or mini
Redundant computation
High level languages
Preprocessors
Init.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
LIFE CYCLE PHASES/STAGES
Del.
R
R
R
R
R
R
R
R
R
R
R/D/I
R/D/I
R/D/I
R/D/I
R/D/I
R/D/I
R/D/I
R
R/D/I
R/D/I
1 Desionl
D
0
D
D
D
D/C/I
D/C/I
D/C/I
D/C/I
D/C/I
U
U
U
U
U
U
U
D
U
U
DeveT I
C
C
C
C
C
U
U
U
U
C
U
U
U
U
U
U
U
C
U
U
Imp).
1
1
1
1
1
U
U
U
U
1
U
U
U
U
U
U
U
1
U
U
1 Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Eval.
E
E
E
E.
E-
E
E
E
E
E
. E
E
E
E
E .
E
E
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend for LIFE CYCLE PHASES/STAGES:
P Plan D - Design U - Use
A - Analysis C - Code/Test ;Consluct/Acquire £ = Evaluate
R«Reqls I - Implement S = Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 33
Security Measures (bv type)
Technical Security Measures (cont'd)
Designing tor Security {cortt'cj)
Isolation of code that is critical lo security:
Checksums on object code
Hardware protection states
Read-only memory
Pronrammino for Security
Program Itorary:
limited aowMW to modules
Recorded access to modules
Storage of previous versions of module
Documented security code
Passwords not in logons/batch ties/keys
IflSiJufl
Source code analyzers
Penetration analysis
In*
P
P
P
P
P
P
P
P
P
P
IConc
A
A
A
A
A
A
A
A
A
A
LIFE CYCLE PHASES/STAGES
Dei.
R/D/I
R/D/I
R/D/I
R
R
R
R
R
R
R
1 Desioni
U
U
U
D/l
D/l
D/l
D/l
D/l
D/l
D/l
Devei. i
U
U
U
U
U
U
U
U
U
U
irnc!.
U
U
U
U
U
U
U
U
U
U
! Prod !
U
U
U
U
U
U
U
U
U
U
Pual
E
E
E
.E
E
E
E
E
E
F
1 Arch
S
S
S
S
S
S
S
S
S
S
Legend for LIFE CYCLE PHASES/STAGES:
P Plan D Design
A Analysis C Code/Test ;Constuct/Acojuire
R-Reqls I. Implement
U-Use
E - Evaluate
S-Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 34
Security Measures (by type)
Administrative Security Measures
Personnel Practices
Screening and Clearance:
Routine screening (reference check)
Formal clearance process:
Criminal record check
Security clearance
Periodic checks of employees/contractors
Non-disclosure statements
Separation of Duties:
Separate duties to separate people
Periodic rotation of jobs (ind. supervisors)
Mandatory vacations
ResponstoilMes/supervision:
Assignment of responsibilities
Assignments in writing
Observation by supervisor
Acting in concert
Account limitations
Daily security checks
Termination/Separation:
Rotate employee to minimally sensitive area
Immediate cancellation of user IDs, etc.
Change of locks
Coiection of keys, badges
Reconciled financial accounts
Termination aoreements
Inft.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
U
LIFE CYCLE PHASES/STAGES
Del.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
U
1 Desiqn
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
\f
u
1 Devel I
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
u
Imol
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
u
1 Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
U
1 Eval.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
s
S
Legend for LIFE CYCLE PHASES/STAGES:
P-Plan D = Design U = Use
A = Analysis C = Code/Test ;Constuct/Acquire E = Evaluate
R = Reqls 1= Implement S = Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 35
Security
Measures (bv type)
Administrative Security Measures (cont'd)
Personnel Prariiras (cont'd)
£^m
Training:
Mandatory/periodic basic awareness training
Specialized security training
Training in mechanical detass of equipment
Periodic drills
Documentation:
Emergency shut-down procedures
Fire/evacuation procedures
Data handling(nonnaf and emergency)
Posting of instructions/phone numbers
Documentation of aN job procedures
cis*2ai A/y^Aftft
UMfJ^KjjIU^fifiKM
To equipment:
Monitoring access through single location
tracking location of portables
Logging use of PCs/terminals
Property passes
Empt. badges with photo/signalure/access
Visitor login/logout
Visitor escorts
Visitor badges
Chalenging of strangers
No visitors at night
Night guard
ScheduNra of two oeoote in comouter center
Inrt
p
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
Cone. 1
U
A
U
U
U
U
A
A
U
A
U
U
U
U
A
U
U
U
U
U
U
U
LIFE CYCLE PHASES/STAGES
Def.
U
R
U
U
U
U
R
R
U
R
U
U
U
U
R
U
U
U
U
U
U
u
1 Deskinl
U
D
U
U
U
U
D
D
U
D
U
U
U
U
D
U
U
U
U
U
U
U
Devei. i
u
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
imoi.
u
1
U
U
u
u
1
1
u
1
u
u
u
u
1
u
u
u
u
u
u
II
i Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
u
u
u
u
u
u
u
! Eva!
P
l_
E
E
E
E
. E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
! Arch
S
S
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
Legend tor LIFE CYCLE PHASES/STAGES:
P - Plan D - Design
A - Analysis C - Code/Test;Consluct/Acquire
R - Reqls I = Implement
U - Use
E - Evaluate
S-Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 36
Security Measures (by typo)
Administrative Security Measures (cont'd)
Physical Access (cont'd)
To equipment (conl'd):
Changing locks/badges periodically
Registered keys with number/control book
"DO NOT DUPLICATE" on keys
Procedure lor tost keys/badges
Memorization of combinations
Log of deliveries/pickups/authority
To system:
List of authorized personnel
Passwords not shared
Passwords not written out or left out
Logoff PC/terminal when leaving it
System/memory clear
Power off of unit to dear RAM
Controlled auto answer modems
Secured host telephone nos^instructypass.
Live data removed for maintenance
Backups
Original input in secure location
Retained copies of outputs
Backup as needed
Routine backup
More frequent backup
Labeled backup
Archive stored in accessible separate location
Incremental backuo accroach
LIFE CYCLE PHASES/STAGES
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
p
P
1 Cone. 1
U
U
U
U
U
U
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
r*
A
Del.
U
U
U
U
U
U
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
1 Desionl
U
U
U
U
U
U
0/1
D/l
O/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
LJVI
D/l
Devel. I
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
ij
\j
U
(mot.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Prod. 1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
n
\J
U
Eval.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend tor LIFE CYCLE PHASES/STAGES:
P - Plan D-Design U = Use
A - Analysis C - Code/Test ;Constuct/Acquire E * Evaluate
R-Req'ts I = Implement S = Stop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 37
Security Measures (bv tvoai
Administrative Security Measures (cont'd)
Software backups
£nd user applications
Source
Loadable versions
Compilers or interpreters
DHf erent forms - tape/microfiche/paper
Retention schedule for data fies
Assigned responstttty for availably
Periodfc lest of recovery procedure
Data Entry
Visual verification
Kay verification
HandfaM of Mannatir Uftriia
Dedfcated risks for each application
DfKfcatod subdirectory for each appl'catfQO
Limiled access to Ibraries
pfphMtion of Dron access to Dwxfuctk>n tarns
Library togs for checkout/return
Only authorized users
Al media not in use
Records of sensitivity/age/use/owner
Special labeling/serial numbers
Expiration labskng
Deoaussino/BrasinQ __
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
Cone. |
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
LIFE CYCLE PHASES/STAGES
Del.
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
1 Devel 1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Impl
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Eval.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
1 Arch.
S
S
S
S
S
s
S
S
S
s
s
s
s
s
s
\f
s
%^
s
\f
s
%J
Legend for LIFE CYCLE PHASES/STAGES:
P » Plan D - Design
A » Analysis C - Code/Test ;Constucl/Acquire
R-Reqls |. Implement
U = Use
E = Evaluate
S-Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 38
Security Measures (by type)
Administrative Security Measures (cont'd)
Software Cooyriohts/Licenses and Master Copies
Adherance to licensing agreements
Use of software exclusively on EPA equipment
Agreements signed and filed with the vendor
Agreement in safe place with regis. number
Central repository for master copies
Avoidance of shared diskettes
jjnairthori7fld Use of Hardware and Software
Blank forms stored in secure location
No usage for personal business
Training done with work related examples
Supervision
Pro-authorization of overtime
Instructions for aH job runs
Production scheduling responsbility
C/)rrtigt» Itjon Management and Change Control
Screening for legitimate appfcations/changes
Procedure for authorizing changes
Accurate records
Lixary tool
Code reconciliation
Old code availability
Usage of original test data
Test runs kept as audit trail
Library system tor tape and disk storage
Auditor/users given documents and changes
Controing programs moved into production
Periodic audits for comoleleness/authoritv
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
1 Cone. 1
A
A
/>
A
A
A
A
A
A
U
U
A
A
A
A
A
A
A
A
A
A
A
A
A
A
LIFE CYCLE PHASES/STAGES
Del.
R
R
R
R
R
R
R
R
R
U
U
R
R
R/D/I
R
R
R
R
R
R
R
R
R
R
R
iDesionl
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D
U
U
D/l
D
U
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/!
D.'l
D
D
Devel. 1
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Imp!.
U
U
U
U
U
U
U
U
1
w
U
U
**
U
U
U
U
U
U
U
U
U
U
1
1
1 Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1 Eval
E
E
E .".
E
E
E
E
£
E
E
E
E
E
E
E
E
E
E
E
E
E
C
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend tor LIFE CYCLE PHASES/STAGES:
P-Plan D-Design U = Use
A - Analysis C = Code/Test ;Consluct/Acquire E = Evaluate
R = Req'ts I = Implement S = Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 39
Security Measures (bvtvDe)
Administrative Security MaMuraa (cont'd)
User identify varification
Signature
Fingerprints
Manual login of batch job submitted
Standards for passwords:
6 character minimum
Letters and numbers
No personal intormalion
Unique
Passwords dunged quarterly at toast
Aj^hDJJZBliQQ
Autiiorization of people
Memory dumps Mled to user partition
ihmrn*H8ng
Operator/iob togs
Manual journals
Balancing of job toads to reduce errors
Varianoq ftotartipfl
Revtow of journal
Observations (visual, electronic, photo)
Employee interviews and questionnaires
Undercover operations
Surprise visits
Scrutiny of employee reports
Audits
Breaches raoorted to aoorooriale EPA officials
LIFE CYCLE PHASES/STAFFS
(nil.
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
IConc. 1
A/R/0
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Del.
U
3
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
IDesionl
U
0
[VI
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D
D/l
D/l
D/l
D/l
D/l
D/l
D/l
Devei. i
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
impi
U
1
U
U
U
U
U
U
U
U
U
1
U
U
1
U
U
U
U
U
U
u
i Prod.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
i Evai.
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
.E
E
i AVch.
S
s
S
S
S
S
S
S
S
S
S
S
s
s
s
Legend for LIFE CYCLE PHASES/STAGES:
P - Plan D - Design
A - Analysis C « Code/Test ;Constuct/Acquire
R-Reqls I- Implement
u
E
Use
Evaluate
Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 40
Security Measures (by type)
LIFE CYCLE PHASES/STAGES
In*. I Cone. I Def. I Design I Devel I Imp! I Prod. I Eval. I Arch.
Administrative Security Measures (cont'd)
Haidcopy Reports and Output
Separate output devices for sensitive data
Printing of sensitive data under supervision
Controled production/distributJon of output
Document Control and Tracking
Inventory
Sign out log
Automated tracing
List of authorized recipients
Locked cabinet or loom
Safeguards against misrouting
Receipts
Mailing
Manual confidential markings
Photocopies
Only owner/custodian may make copies
Copies entered into tracking, own DON
Disposal Practraa
Shredding or burning of confidential reports
Erasure of magnetic lapos/disks
Erasure of disk space
Destruction of exhausted ribbons
Inspection of wastebaskel contents
Continuiy of Operations
Restoration from backup
Replacement of software from master/vendor
Regular preventive maintenance
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
A
A
J*
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
0/1
0/1
D/l
O/l
0/1
0/1
0/1
D/l
D/l
D/l
0/1
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
P
P
£
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
Legend for LIFE CYCLE PHASES/STAGES: ' -
P - Plan D » Design
A - Analysis C - Code/Test ;Constuct/Acquire
R - Req'ts > - Implement
LT-Use .:
E - Evaluate J
S=-Slop
-------
EXHIBIT C-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 41
Security Measures (bv tvoe)
Managerial Security Measures
Insurance
Against physical damage to equipment
On media, programs, data and documents
For expenses in operating a backup site
Against business interruption
Third party liability
Employee bonding
Non-EPA Software and VJrusea
No instalaticfli without SIRMO permission
Management group responsibte for security
Adequate supervision and scheduling
Detogattkxiofrespons.tornp/s.eonedingclata
Review of changes
Confidential data on LAN approved by OIRM
JoumaHdno
Examination of tog or analysis
Variance detection
Management inspection of event journal
Cortrol d dynamic monitoring
Audsor review of design
Peer review of sections of cade
Programming standards
Init.
P
P
P
P
P
P
P
P
P
.P
P
P
P
P
P
P
P
P
P
P
P
Cone. 1 Del.
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R
A R/D/I
A R
A R
A R
Legend for LIFE CYCLE
P-Plan
A -Analysis
R-Reqts
LIFE CYCLE PHASES/STAGES
1 Desion 1 Deval. 1
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
D/l
on
D
D
D
U
D/l
on
on
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Intel.
U
U
U
U
U
U
U
U
U
U
U
U
U
U
1
1
1
U
u
u
u
1 Prod
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
PHASES/STAGES:
D - Design
C Code/Test;Consluct/Acquire
l» Implement
1 Eval 1
E
E
E
E
E
E
E
E
E
E
E.
E
E
E
E
E
E
E
E
E
E
Arch
S
S
S
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
s
U-Use
E » Evaluate
S-Slop
-------
EXHIBIT G-4: SECURITY MEASURE CHARACTERIZATION MATRIX
Page 42
Security Measures (bv type)
Managerial Security Measures (cont'd)
Contiraitty ol Operations/Contingency Planning
Prioritizatkxi of critica tos
inventory of into/proct ires lor recovery
Evaluation of new sy is as they come on-line
Redundancy in on-s'«~. , lace/equipment
Emergency standby^ ftttty
Backup facility agwj tt/condttons
Formalized manual .- xk procedures
Periodic review of o* ., jty/oonttn0~ncy plan
Periodic test of reoot .y pro-am
National Sucmilv InJonBi on
Folowing of NSI rfejuiremente
Aonoval of dkvctor OIRM
MFE CYCLE PHASES/STAGES
In* I
P
P
P
P
P
P
P
P
P
P
P
Case. 1
A
A
A
A
A
A
A
A
A
A
A
Oef.
R
R
R
R
R
R
R
R
R
R
R
1 Desion 1
D
0
0
D
D
0
D
D
0
D/l
D/l
Devel. 1 Imbl. 1 Prod. 1
U
U
U
U
U
U
U
U
U
U U U
U U U
Eva!.
E
E
E
E
E
E
E
E
E
E
E
1 Arch.
S
S
S
S
S
S
S
S
S
S
S
tor LIFE CYCLE PHASES/STAGES:
P-Pian D- Design U-Use
A-Analysis C » Code/Test ;Constuct/Acquire E-Evaluate
R-Req'Js I- Implement S«Siop
------- |