8-EPA
un.rec s'.a'es -~ . rcnmenta1 -'c;ec:ion
/.'=iT ngtcn DC 20-160
OSWER Directive initiation Request
. rec:./
b Does It Supoiement Previous Directivels;9
i NO
: NO
i Yes
What directive (number, title)
i Yes What directive (number, title) 9928 00
OSWER'S System Life Cycle Mgmt. Guid.
7. Draft Level
I A - Signed by AA/DAA
i B - Signed by Office Director
u
C - For Review & Comment
D - In Development
8.
Document
to
be
distributed
to
States
by
Headquarters? ' |Yes
X
No
This Request Meets OSWER Directives System Format Standards.
9 Signature of Lead Office Directives Coordinator
Date
0 Name anO TitlexJTAppro1
(Date
EPA Form 1315-17 (Rev. 5-87) Previous edi^ns are oosolete.
OSWER OSWER OSWER O
VE DIRECTIVE DIRECTIVE DIRECTIVE
-------
OSWER Dir. rf9028.00c
UNITED STATES ENVIRONMENTAL PROTECTION AGENCY
WASHINGTON, D.C. 20460
of
SOLID WASTE AND EMERGENCY RESPONSE
MEMORANDUM
SUBJECT: Transmittal of OSWER Directive 9028.00
OSWER System Life Cycle Practice Pape
on Data Modeling and Security
FROM: Asa R. Frost, Jr., Director
OSWER Information Management
TO: Addressees
iS-110)
With a goal of continually improving the way we do business,
OSWER has developed guidance which supports better ways of
managing data and producing automated information systems. In
1988, the System Life Cycle Management (LCM) Guidance was
distributed as Directive 9028. The attached policy memorandum
states that all information systems, which are intended for use
by an OSWER organization or for use by a Regional office in
support of an OSWER program, must be developed in compliance with
OSWER's System Life Cycle Management Guidance.
The attached Practice Papers on Data Modeling during
information systems development and on Application Security
Management throughout the system life cycle have been written to
help those developing systems and managing information to produce
better products.
To support the current Agency goals of collecting good data
and making them accessible and re-usable, the Data Modeling
Practice Paper describes the standards for developing a logical
data model during the life cycle. It introduces data modeling
techniques, defines specific data standards for logical data
modeling and offers some how-to guidance. Most importantly, it
contains, in Appendix F, the results of logical data modeling
performed from the bottom-up, on a number of operational systems
critical to the RCRA and Superfund programs. When developing a
new significant system or a major enhancement of an existing
system, one must not only include data modeling in the definition
and design stages, but must also be in conformance with the
logical structure and accompanying definitions in this 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
-------
OSWEK DIRECTIVE #902S.OOc
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.OOc
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 Pgper
-------
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
APPENDIX C: DATA
APPENDIX D:
APPENDIX E: GLOSSARY
APPENDIX F: OSWER-WIDE CONCEPTUAL DATA MODEL
Data Modeling Practice Paper
-------
OSWER Directive #9028.00c
LIST OF FIGURES
Figure 1. The House Construction 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 Piper
-------
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.
w 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
-------
OS WE/? Directive #9025.00c
«• 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 Modeling Practice Paper
-------
OSWER Directive #902S.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 Paper
-------
OSWER Directive #902S.OOc
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
An wcMtoct kfofltifot wn*t
ttw buytr wflntB bunt
(Conceptual Data Modeling)
Floor pi
to reflect buyer's requirements
(Logics! Data Modelng)
ere agreed upon prior to
ornmrUng actual construction
(Oats Model Confirmation)
upottod to ifUHuoo wiring,
plumbing, inculvtfon, etc.
(Physical Database Design)
(Database Implementation)
(Completed Database)
Data Madding Practice Paper
-------
OSWER Directive #9028.00c
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
-------
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 die 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 Data 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.
23. 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.
2JL1. 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, OPPE, OECM, OARM,
ORD, OIA, OPTS, OAR, OW, OSWER, and many others.
Date Modeling Practice-Paper
-------
OSWEK 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
Normalized
data entities -
results in many
more entities
than in
Conceptual
model
Data
Relationship
All pertinent
relationships
should be
identified
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 die 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.OOc
Figure 3. Conceptual ERD Example
EPA
Overseen
by
Oversees
Occurs at
Location of
doanup
Contract
Provides for
Provided by
Activity
Counter-
measure for
Spiii
Counter-
measured by -^C
Agrees to
Agreement
with
Sourcedat
Contractor
Source of
p
A
Spill Sample
T
Contained in Contains
O
A
Chemical
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 Modeling Pnctitx Paper
-------
"
"•""•"•o™-.*.,, .
- -»•.* •— •*-•
—«poseofanERD?
req • are *o used
^ERDcanb ** m0del ** *«"
SSSggS&sr.sa-
77> L *** tw° or more
10
toper
-------
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 11
-------
This page intentionally left blank
-------
OS WER Directive #9028.QQc
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
-------
OS WE/? Directive #9028.OOc
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.2. 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 SpUl 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 denned for it, it may not be
24 D«te Maiding Prtttice Paper
-------
OSWER Directive #9028.00c
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 Purchasing
Stocfc Receiving
Data Modeling Practice Paper 15
-------
OSWER Directive *9028.00c
Order filling
Stock Reconciliation
Once we have an 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
Guetomer Sates 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 Dttt Modeling Practice Piper
-------
OS WER 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, U*Update, D^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 Madding Practice Paper
17
-------
OSWER Directive #9028.00c
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 ru actions in scope, and
identify existing systems (or organizations) i 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 axe 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 clearer, 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 Date Madding Practice Paper
-------
OSWER Directive #9025.OOc
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
-------
OSWER Directive #9028.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.
20
-------
OSWER Directive #9028.OOc
Figure 6. Progression of Data Modeling During the SLC
System Ufe Cycle Phase/Stage
Data
Modal
InftMlon
Concopt
PfMM
Itottgn
Conceptual
Data
Data
TT
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 / 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.)
Data Madding Practice Piper
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 spill simple 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 ' Dttt Madding Practice Paper
-------
OS WE* Directive *9028.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
Overseen
by
Oversees
Occurs at
T
Provides for
Provided by
Activity
Counter*
measure for
Location of
Agrees to
Agreement
Wil/i
Counter- _^
measured by -4-
Sourcedat
Has Location
H-
Location of
Source of
Contained in
Cofweptual/KemaJ | |
Associative | J
Attributive
Contained in
H-
Contains
Contains
Data Madding Prtctice 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.
24 Dftt Modetinr Pnctice Paver
-------
OSWER Directive #9028.OQc
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 Pmiice Piper 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.
• Crmmte wanes 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 Dtt* Modeling Practice Paper
-------
OS WER Directive #9028.OQc
• 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 name 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
D*t& Madding Practice Piper 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 S lists the properties used to define data
entities.
Figure 8. List of Properties for Defining Data Entities
Average Occurrences Examples
Comments Full Name
Data Collector Growth Rate
Data Custodian Identifiers
Data Oefiner 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 taJces 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 the 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 Prtctice Paper
-------
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 Rate
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
CL
CLRC
CLRC
CLRC
CLRC
ORc
CLRC
CLRC
CLRC
CLRc
CLRC
CLRC
a
CLRc
CL
a
CLRC
CL
QRc
CLRC
DESIGN STAGE
RL
RL
RL
RL
RL
RL
RL
RL
Key to Table Cc means Complete for data entities in the Conceptual data modeJ
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
^Maximum Occurrences and Growth Rate are sometimes used during the Concepe phase as a way of
estimating database size tor feasibility analysis and technical platform assessment
Data Modtiing Practice Paper
29
-------
This page intentionally left blank
-------
OSWER Directive #9028.00c
4. 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 more
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 WER Directive *9028.00c
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
i
IHl^^MKi^^Bf^h^h
•mptoyw*
Managed by
V Worteat >
\o [/
/WortcpfacecrfX
(
A
)
N
FflcMty
The new relationship can be interpreted as follows:
An Employee Manages zero or more Facilities
32
Data Modeling Practice Paper
-------
OSWER 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 manages 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.
41.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,
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. (In 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 Modeling Practice Paper ' 33
-------
OS WE/? 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
Conipns«M 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.
4JL 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
Dttf Modeling Practice Paper
-------
—6
.S^iSaSSaa*-
good
-0 - icjanonship
~«c eiiane ...«icason should be a clue for devising a goo
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 —
succinct name using an active verb would be Custom— ^-J
ir--
and
side.
-------
OSWEJ? Directive #902S.OOc
Figure 13. List of Properties for Defining Data Relationships
ERO
ERD
Average From Occurrence* ERD
Average To Occurrences ERD
Business Rule Description ERD
Comments ERD
Documentor Name ERD
Effective Date ERD
From Entity
Maximum From Occurrences
Maximum To Occurrences
Minimum From Occurrences
Minimum To Occurrences
Relation From Ni
Rotation To Name
To Entity
Version Number
36
DttM Modeling Practice Piper
-------
OSWER Directive #9028.OOc
5. DATA ELEMENTS
5.1. CREATING DATA
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
Datt Modeling Practice Paper 37
-------
OS WE/? Directive #9028.OOc
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
Oversees
Cleanup
Contract
Pn
• Site Number (PK)
• Site Name
• Site Street Description
• Site City Name
• Site State Code
• Site Zip Code
• Site Longitude/Latitude Measurement
• Site Contact Name
• Site Contact Phone
• Site Description
•etc.
She
Spill
Agrees to
Ag
wit
Contractor
Cleanup
Contract
• Contract Number (PK)
• EPA Organization Code (FK)
• Contractor Number (FK)
• Effective Date
• Termination Date
• Funding Source Name
• Provisions Description
measured by
Sourcedat
Source of
Spill Sample
Contained in
Contains
PK » Primary Key
FK * Foreign Key
Chemical
Substance
Contained in
Contains
Chemical
Substance in
Spin 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 Madding Practice Paper
-------
OSWER 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. An 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. Pulling 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 by 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
-------
OSWEK 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
VfoMJon of Rrrt NoomJ Form (INF)
CuttomrNanw
Curioimr Locatfonl
Curiomr Location 2
CuBtomr Location 3
CuMonw LocaJjoo n
Ueitfon.
VlowvOfi of Sooono NonniM Focm (2NF|
Vtototfon of ThM NorrtMl Form (3NF)
Invoio* Nunnbv
OMMrltaMI
Cuttomr Number
i^
dMffHCfll
ChwitalCod*
Ctmrical Codo
/YwfMUfMlvtfto
/MWtfWfMVD*
JVIQ £Q0f Of Of9
ctamMftiMtA
5^§SMpte
AtanminM*
ImaiovM*
VW fflWBKA
•ntity, GMfrac9L
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* Moddint Practice Paver
-------
OSWEK Directive #9028.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 mis 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 Prutiee^Peps.- 41
-------
OS WER Directive #9028.OOc
Figure 16. Primary and Foreign Keys
Employee Number (PK)
Facility ID (FK)
•mploy««
, Wbrksat
\n If
yu II
f VWxkplaceof
Facility
Facility ID (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
-------
OSWER Directive *9028.QOc
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.
5JL2. 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 *tams> + Descriptors) * Claaa Word
The Data Entity Name is simply the name of the entity that the data element
is describing; the Descriptor's) 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 is the
Data Entity Name, Estimated Cost are the Descriptors, and Amount is the Class
Word.
Data Modeling Practice Paper 43
-------
OSWER 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
Description
DSC
Characters describing something using textual
information
Flag
FLG
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.OQc
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 for
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.
5JL3. How are Abbreviated Data Element Name* 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 Modeling Practice Paper
45'
-------
OSWER Directive #9028.00c
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 Dttt Modeling Practice Paper
-------
*9Q28.00c
reachofthe
property, since it is Uus properly whiA ffl *e Description
the ™08' "*" "**"
Data Madding Practice Paper 47
-------
OSWER 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 #9028.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 Model ng Practice Paper 49
-------
This page intentionally left blank
-------
OSWEK 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, rilling
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. "MANAGE1 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
-------
OSWER Directive #9028.00c
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 #9028.00c
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 #9028.00c
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 #9028.00c
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 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 #902S.OOc
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 what 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 Bflper A-5
-------
OSWEK 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
-------
OSWER Directive #9028.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 #902S.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
-------
OSWER Directive #9028.00c
Requirement - REFERENCES 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 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 Payer 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
A.
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
• 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 #902S.00c
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
-------
OSWER Directive #902S.OOc
AVERAGE TO OCCURRENCES
Definition -The 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 not 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 #902S.OOc
Requirement - An EFFECTIVE DATE should be provided with each new version of
the relationship, as indicated by the VERSION NUMBER.
Usage - ThepPFECTTVE 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 single 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 #9028.OOc
Product ordered by a maximum of Many Customer
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 #902S.OO
-------
OSWEJ? Directive #9028.OOc
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: Product 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.00c
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
-------
OSWER 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
Configuration Management
• Documentor Name
• Version Number
m Effective Date
The properties above are presented in alphabetical order.
Data Modeling Practice Paper C-l
-------
OSWER Directive #9028.OOc
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
-------
OS WEI? 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
-------
OSWER Directive #9028.00c
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.
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"; "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).
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
j J * *
most cases).
i
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
-------
OSWEK Directive #902S.OOc
Examples - Description of Treatment Change Code:
"The Treatment Change Code represents the projected change in the use of waste
wat*»r 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"
ED IT CRITERIA
Definition - EDIT CRITERIA are the programmatic rules for the values.
Requirement - Every data element should have EDIT CRITERIA.
Data Modeling Practice Paper C-'/
-------
OSWEK Directive *9028.00c
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 *9Q28.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 in 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 SUPPORT',
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
-------
OS WE/? Directive #9028.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 Piper C-ll
-------
OS WEI? Directive #9028.OOc
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 arid
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 #902S.OOc
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 tirr*- 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
-------
OSWEJ? Directive #902S.OOc
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 Pgper D-l
-------
OSWER Directive #9028.00c
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
m 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 + descriptors) + 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 instance 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
-------
OSWER Directive #902S.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 #9028.00c
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)
Data Modeling Practice Paper F-l
-------
OSWER Directive #9028.00c
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
-------
OSWER Directive #9028.00c
Figure 21. RCRA Data Model
U n < • r
7
U i
0 • • r • t «« •«
fAl*iffl«« t*
!• iyp« «f
oV^.,.
, c»ii«ti« y
0*I < v>r• y
!• •••<§»•<
AtVI••• \•
Modeling Practice Paper
F-3
-------
OSWER Directive #9023.00c
Figure 22. CERCLA Data Model
<[
Otter .
i
o
•
•
....
e
<>•
~
.
-
f «
1*1
A
•
•
c
V
j
,
....
it
• 1
~ m
• *
• ,
• :
: ^
•
^
in
r
-o<
Oti%«'
f , •**« , •!
I«C«' •
?•«»•.*•)
*"*'
i fet* »
K>-^
•
•
'
•
•
«
•
I*
•
1
•
«
•
»
»
;
• •*
\
9
m
•
•
«•
^—
t
r
1
• i
<«
t
T
•
•:
•;
* »
•
t
•
n
•
a
SZT
• •
•
-»•«
* i ••
•
•
i
i
»
•
i •
\
II
°\
•L
•
- • ;
: u
i - •
» - *•
~ * •
m *
•
U ••'
~c~
:
•
•
CtflCLA ^^^ t
i.t. ' ' x- ;
_ 1 ?V *
I *• i «•• t |
F-4
Data Modeling Practice Paper
-------
OSWER Directive #902S.OOc
F.3. OSWER-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. (NPL 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. (CERCLIS, SDMS)
Chemical Sample - A specific portion of material at a site collected at a given time
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 Pjper F-5
-------
OSWER Directive #9028.00c
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. (CERCLIS)
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. (NFL Technical)
Document - Maintains information about the CERCLIS Site (i.e., Superfund Site) file
documents. (SDMS)
Enforcement Activity - The actions taken by EPA to compel or negotiate with
Potential Responsible Parries (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 #902S.OOc
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. (NPL
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
-------
OS WEI? Directive #9028.OOc
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
(TDK). 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 #9028.00c
Laboratoiy - 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)
r
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)
NPL 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,
NPL 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 phases 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, CERCLIS,
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 Rtper F-9
-------
OSWER Directive #9025.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, arid/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 #9028.00c
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. (CERCLJS)
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. (CERCUS)
Data Modeling Practice Paper F-ll
-------
OSWER Directive #9028.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 *9028.00c
Waste Treatment Method - A procedure to reduce the amount and /or potential
harmful effects of waste. Examples include microfiltration and biological treatment.
(NPL 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 Eeper F-13
-------
OSWER DIRECTIVE *?C28 OOc
OFFICE OF SOLED 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
-------
OSVVER 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
. i
-------
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:
APPLICATION 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
M
-------
CJ
s
06
S
UJ
I
w
i
H
Z
UJ
A > .
H b «
s S w
X
w
§e
*•* ^
H
<
U
1-2
-------
OSWER DIRECTIVE #9028.OOc
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.QGc
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
AVAILABILITY, INTEGRITY, CONFIDENTIALITY and to INAPPROPRIATE
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
-------
OSWER DIRECTIVE #9028.OOc-
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" (FTPS 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 SECURITY 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.0Cc
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 APPLICATION 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.
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 of INTEGRITY.
2-2
-------
OSWER DIRECTIVE #9028.00c
Inadvertent 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 example, deliberate
acts by people result in ADVERSE EVENTS such as loss of AVAILABILITY 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.OOc
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.
3.2 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 AVAILAB1UTY, 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.COc
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 ivorkplan 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/ SURES 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
4.2 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 genetically 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
-------
00
ra
o
UJ «
2* i
0>
o
O
o
o
c
o
Kl
'E
re
O)
52
5
6
s
2 C
*^5 Cu
E 3
A C
CO <
O
vw
I?
"i
ll
1--
5 co
* i
2i
Us
o|g ^
i
oc
CD
Is I
3 S
3 55 •-
c/5 O Q
o
£
o
OSWER System U
DC
CO
2
z
B
if)
in o
O
x
1
2
56
CO §
2 cc
11
_j c
33
Continuity/Contingency
(EPA ual, Appendix D
5 °
/$ c
CO a
si
1
ning
2
11
I
B D
0)
s.
(0
o
I
II
u
«
^» ^^J
9 Q
" ^
«• ®
i ^
S 2
2 «
ol
is
w «
il
:l I
II H
Z D
o
at
(0
2 2 =
« « jo
>• « .9
S>>s
- -- 5 §>
« € ^ f
= ^^§
c a> o o^
(0 Q) Q Z3
« O O « "O
«=! fl)
3 3 3 ="§
ii H n H a
•r- eo w O «
D D D D <
o
O)
4-3
-------
UivVtK' Ul
EZHrarr 4.3-1: INITIATION PHASE
APPUCATION SECURITYMANAGEMENT APPROACH OVERVIEW
OBJECTIVES
o Determination of application SENSITIVITY
o Order-of-magnrtude benefit-cost analysis
o Identification of Concept phase SECURITY MEASURES
KEY
DECISIONS
Who wui IM laaponaUa to appfcauon wcunty
managamant approadi durtna MMafton phaaa?
I niin irr
ACTIVITIES
PRODUCTS
WhowWeompM*
randappfOvCTabtolor
SamMvfy Evaluation- MriBhaaT?
WHo *m oompMa. ravla* and appnw* OSWER
S»»tam Upiuu Font! tor O8WER On RHOUIM
OtrMory?
Wha oihtr «previb art moMtary «nd «M
-
Ara (tiara any apodal aUMory raquaomaraa?
Who Ml partorm barwrl-a
Who will b« rHoomcM tar Coropt PIMM apploBUn
(acuity manaatmarn approach?
Whai nwho0otoglw and tooai •* ba uud tar Conoapl
flag* «pp*c«ton taoirty rramap«n*ni approaot?
PRQJI
PCT CXECLITION
DEOSIOfM:
What»ralavanc* of •«* of OSWCR* tour SECURITY
OBJECTIVES to Information manaoamant prabtom?
What K appllcanoni dagr** « SENSITMTY?
What wl tw oanalii ot RISK nMuoton?
What ml b* ordar-ot-magnltuda OM of SECURITY
MEASURES?
Whai RISKS am
What SECURITY MEASURES ara ftaadad tar Conoapl
throojn impMrnanatton?
PROJECT (
Doaa actucaionl RISK (vanma ereaf-^iayHud*
W« Coocw phaa* SECURITY MEASURES b* (I
piaca oy ma tun ol ma Conoapt phaaaT
Aaalgn raapombWy tar SEMSITrVrrY daMmMflon.
*WIMV flno v^fCMrV
Ravtov ant appnwa TaMa tar SanaaMQr E
Awlgn mpontMtf tar O8WER SyMm UpttM Form
Review and «pm« 09WEB S)M>m U^dM Form
Awlgn nvcraMty tor bmrlMDM
kiMdaden OMWon P«p*r
appfcaitan Mcurtr fflanagamam appraacri
In Pmtaa MamgwnM Pkw
Dcfln* appfcatton a»i»hp«'»«» (Oawd SECUROY
MEASURES iwadad tar Conoapt Mreuah krvfemMa-
*-
Complali T«a tar SanUMty Ev*iatlp»f oertUmi
ConpMa 06WEB Sywam Upda* Form tar 06WER
Oau Rtaeurea Dlwcionr
Parterm ortar^Mvantuda ban»*eo»» aniryMi of
RISKS and SECURITY MEASURES
UPOATED:
MPW;
tovMvly EvaUten WwtnhMl. pv tP*
WomaUon S«axty Manual* Swfen *'.
Form tar 06WER DM
Roaouroa Otaoory.
Inflation Oaotaion Papar*
Projaet Manaaamant Plan
• tavod m Wiaaon baavna
+ MM u OSWER SIRMO
-------
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 SENSmVITY on the OSWER System Update
Form.
4.2.2.2 Order-of-Magnitude Benefit-Cost Analysis
The OSWER System Life Cycle Management Guidance requires you to conduct an
order-of-magnitude 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.00c
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 Management 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 (eg., 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-magnirude 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.
-------
OSWER DIRECTIVE *?G25.CCc
EXHIBIT 4.3-1: CONCEPT PHASE
APFUCATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
ln*H«Twmutofl of Coocepc phMe SECURITY MEASURES
High I** RISK ANALYSES tor Mtfi apptettion concept eft
fTY •ppecmttons
Section of ipproQriaa SECURfTY MEASURE type* and t»
concept •iMmsthw
»tor medium end high SENSTTIV-
i lor *Mcn •pplicAOon
Definition of Means ftfttgy tor SECURITY MEASURE n/pM tor recommended •ppteelon concept
IbenoflcMoc o( Oflniton wage SECURITY MEASURES
KEY
DECISIONS
ACTIVITIES
Who will be reeponible tor appUceUon aecurky
management approach during Concept pheae?
Who wil conduct, review and approve high level RISK
ANALYSES end benefit-coat anatytoa?
Who wtl be leaponable tor SECURITY MEASURE
tacUngatnmgy?
Who wtl be leeponebto tor Dotation etege appfcetlen
PRODUCTS
U
Wha mMhodotogta and Mil •« b* uwd tor IMMton
•lag* «t4J»caluii Hcurty mraQtrm* «proB*)T
WtW v« vpllcrtoril HMFORMATON RESOURCES
lor Mch gptaflen ooropl HMmM«7
Wha v» poMntU ADVERSE EVENTS. THREATS.
VULNERABILITIES and tai turnout from Mcti
occurwtc* lor ntti m*mki\ eanctfl il
Wha art high IKM RISKS tor aacrt «Bp*aBen oonoapi
WTiat ai» lyp« rt SECURITY MEASURES nM(M tor
»aai acetation ooocapi allvnaflv* to eouriMr
THREATS and b*n*f(i and con
-------
OSWER DIRECTIVE #9028.OOc
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 and
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
EXHIBIT 4.4-1: DEFINITION STAGE SUMMARY
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
URITY MEASURES
vntattonoK
RISK ANALYSIS tar I
aHMon ot apedlte SECURITY MEASURES and OeMled baneft-caat am
Log** defMton of weft SECURITY MEASURE tar eatoeM appfcatton e
Beginning of proonrnant ramify « tupport SECURITY MEASURES
DafMton oi teat criteria and metndotogy tor SECURrTY MEASURES
KEY
DECISIONS
el Ortgn
SECURmr MEASURES
ACTIVITIES
PRODUCTS
PROJECT APPROACH
Who will b*r**pon*l* tar application tecurliy
management approach during Deflnttan MO*?
Who will conduct r*vlew and approve aaMlhd RISK
ANALYSIS tor telactad appHcaUon concept
atemath*?
Who win perform, review and approve deflnMan of
tpacllc SECURITY MEASURES and tw»rt-oo«
inilyM tor tMewd miHtMlon concvpt Mtmawv?
r
Who will r**M OSWER Syttttn Updw Form tar
OSWER Du Ftatouna Otmoory?
Who will b* ratoontbta tot proourwrwn ol
SECURITY MEASURES and icprov* MI crMrta tar
MOK SECURITY MEASURE?
Who wil t» rMContb* tnd whti nwhodotogtai «nd
took w*l M uMd tor OMion ttigi •ppMeaton wcurty
mtnigwrwn appracox?
PROJECT EXECUTION D
In d«uil. what am m* RISKS at th*
apptcaian oxxapt u»nvat)y»?
wnu tpMtic SECURITY MEASURES •!• wqulrad
and wnat ar* «)• b*n«4to and COM ol mcfit
What ar* in* logical r«ou»»m»nt« tar Men
SECURITY MEASURE?
HOW wil aoqulr*d SECURITY MEASURES 0*
procured and t*«*d?
Wh« SECURITY MEASURES ar* mqukM Mr
0*«ign. 0*»«topin»rii and tnwcrmnuoon MB*
adtvn«i'>
Do RISKS ol detned SECURITY MEASURES
praclud* tunner u»»*tuprnanT7
Wil Dwqn MO* SECURITY MEASURES be In
plan by th* (tan ol ttw Parian ataoa?
Aatlgn natpmbMty tor. reMe* and approv* RISK
ANALYSIS. MUrton df SECURITY MEASURES.
and b*neti-coM anaty**)
AMlgn njaponabOtr tor. nMemr end
SECURITY MEASURE logical '
Aaaton raapetmb«y tar. NWMM and acproval ot
OSWER SyMm Updav Form Mr OSWER Oau
Raeouree Dtrackvy
Aatlgn raepenabMy tar procurement at SECURITY
MEASURES
Updaw Oau Management Plan. I necnaary
-»
Summafta* r*ft«d appNcMon Meurtty manag«m*nl
approMi m (Mnaton Otdatan rHp«r
Updat* appHeaton «*curtry nwiao*m»m approach In
Protact Manao^rmm Ptan
H***
BBft
2s:
Rflfatw tffpf>-*i^ft dtwvtac
MEASURES p«»d«d tor Pmtgn. D»^.*jgin.wii.Mid
«ta»d SECURITY
PHOJgCT ElfPCUDOM aCTltfmO;
Ptoa* SECURITY MEASURES needed tor MnUon
Partorm d*taM RISK ANALYSIS and banM-eoH
anaryilt tar m*dk*n and Mghry SENSITIVE
i tor (Morrnwided appfcaBon oompi
Piwrtde logical ttquMmmm daMttom tor aadi
SECURITY MEASURE N OlUttt Funotanaj
R*9u»*m»ni» and D»i«*»d Data Paoiilnmanai
Updw 08WCR Syturn Updata Fern to Muda
SECURITY MEASURES
Plan
UPDATED:
Pro)*a Managarnani Plan
SyM*m T*u Oocunvnt
Aooaptanea TM Oocunam
Data Management Plan
tlSUL
R»vla«d OSWER Sy**m Updau Form-.
Oatalad Functional Raquramants'
Oatatod Oau R*quMm*na'
R*qur*m*na Data Dictionary*
Definition Deefclon Pap*r
•laved In DennWon baulln*
•unt to OSWER SlRMO
Oetal Mat crterta and nwhodotaoje* In Strftam and
Acodcunoe Teal Oocumanai
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 the selected
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" (FIPS 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.OOc
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-18
-------
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,
-------
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
-------
UlKCUIivC
EXHIBIT 4.5-1: DESIGN STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OMB »X» oompaant Sacu*/ Paw. I raoufcad
RISK ANALYStS wonfchaat or rape* tor Maaattom, I •aqufrad
Oatalad daalgn apadflcatom lor aaoh SECURITY MEASURE
Fundad premramant raquaaB tor acqutrad SECURITY MEASURES
Taat prooaduraa tor al SECURITY MEASURES
of Dai atupmau «ao» SECURITY MEASURES
KEY
DECISIONS
ACTIVITIES
PRODUCTS
PROJECT APPROACH DE
Who will ba nMpontUa tor application tacurty
managamant approach during Oaalgn ttaga?
Who will pnpara.ravlaw and approvaSacurty Plan. If
raquirao by OMB BUIatln gooa?
Who win oinjtaa. ravtaw and approwa Inataaatlon
Ouaflauva RM Analytk Workanaat orOuarxMVa
Risk Analyw Rapon. I raquirad by *EPA Intefmatton
Sacurlty Manual.' ^pandb C?
Who will provtda. raviaw and approva SECURITY
MEASURE da»«n«?
Who will cofflpfeta), rwtw tatid flppfow pfocuwown(
raquacu lor aoquirad SECURITY MEASURES?
Who will premda. tavvw and approve SECURITY
MEASURE ia§a?
ch?
Who wil M rHpombl* tor Dxa
app*smon Mcurty managaman
What mamodoegia* and toon wll ba uaad tor
D«.«IOCII»II (taga applcanon Hcurti)r managaman
PROJECT EXECUTION
What It tnott atlaetVa phytical da^gn tor each
SECURITY MEASURE?
What funding wll ba naadad tor SECURITY
MEASURE procuramant?
Mow wil aacn SECURITY MEASURE b*
unt. mlagraien, tydam and
(at
0?
What SECURITY MEASURES ara raquirad Mr
Davaioprnam and ImpiamanuaMn aaga aoMHaaT
Do RISKS 01 oafignad SECURITY MEASURES
pracluoa lurthar dawatopmanr?
Wll Owataomant itaga SECURITY MEASURES ba
m piaca by ma ttan ot tha Davatopman naga?
Aailgn napanaMy tor. ravtaw and approv* OMB
«H» oompaant Sacurty Pta
AaaJgn napomUfty to/, /avlaw and approva
inamiaflon OuaMaVa R» Ana»»l» Wonaihaal a
QuantMBVa RW Anah»» Raport. I raqulnjd
Awlgn faapomfcMry tor. tartaw and apprm*
SECURITY MEASURE OMgna
Aatlan naponaUHy tor, i»*taw and approwa
SECURITY MEASURE pracwamant njquaati and
taatdaalgna
UpdaM Oau Managarant Plan. Inacaaury
SunmaAa raflnad ap
tion aaouAy managamant
approatfi In Oailgn Oaebon Papar
UpdaM application aacurHy managanw appiDadi In
PnjfM Managamam Plan
flaflna appleation davabpr
rti
MEASURES naaead tor DavWpman and
M> SECURITY
Placa SECURITY MEASURES naadad tor tha
Prapara Sacurty Phvi par OMB Bulantm 8048.
Itmqmnjd
Comptata InMMton Ou^wtva RJck AnttyUi
Wortahaaior liaiaaailiiii OuanttalHw RWi
AnaVyW Rapon, H raqotrad
Prodoca oa*lom tor SECURITY MEASURES 10
ba mdudad m SyMwn Dacign. Phyilcal
Daiafiaai Daalgn and Daalgn Oala OteHenwy
CompMa SECURITY UEASURE procuramant
and
Expanded SECURITY MEASURE taat
prooaduraa In SyMam Taat Ooeumant and
Acoaotanoa Taat Oocmnant
UPDATED:
Projact Managaman Plan
Oau Managamant Plan
S)fMam Taat Ooeumant'
Acoapunca Tan Oocunanf
NEW;
InataHation Oualtatlva RhK Analyili Worktnaai or
OuantitatM Ri*k Analytit Raport-par -£PA
Informauon Saeunty Manual* Appandu C (*
laquirad)'.
Saeumy Plan, par OMB Bulailn 9CW8 (.1 rauunad)-.
Syltam Oatlgn*
Physical Oau Bata Oavgn*
Oawgn Oau Dteaonary'
Daalgn DacWon Papar
•uvad m Oaiign baiabna
»tant 10 OSWER SIRMO
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
SECURTTY-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 Ftocurement 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 #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
-------
OSWER DIRECTIVE #9028.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/T/WTY, 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
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 equally responsible
4-31
-------
EXHIBIT 4.6-1: DEVELOPMENT STAG!
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
•logmoni «ag* SECURITY1 MEASURES
Cod»« of taftMraSECURTTY MEASURES
ol OOMT SECURITY MEASURES
iHsW* 9O9&9t* MstfiMOjAM
SECURITY MEASURE AxuwHHn am
Conanuty at OpMtona Han or Apptoaflon CoMng
idmMlMtan ol iBtfarnonaaon «ap» SECURITY MEASURES
MCUWTY MEASURES
ACTIVITIES
PRODUCTS
who MM DC ^MOOAQOV tv fl
manaamiani annuaen awing Danotopmani MQ*T
«Mra I r«guMd by^PA MomMon SMrty
Who «M out* or mM«, rwtaw «M
SECURITY MEASUHEST
Who wff p0rfonn And
(Mtmg ot SECURITY MEASURES?
Who wif pnow,
SECURITY MEASURE
preoMurM. including t SMurty Manual nqUtad?
Who wti be rMooncMo taf
WM mMhodotogto and took «N b* UM« tar
Irnpitnwniiion oag* »>* alai Mcurtr
minagtnwnt appro**?
WM SECURITY MEASURES art ««*M tar
PROJECT COMT1MUAT1OM DtC&iOMa:
Da (Mutt et SECURITY MEASURE unl M
>n«gr«ion Mm r«««l unwadM* RISKS?
WIN imptonvnwHon ittg* SECURITV MEASURES
a* « puc* ey m* nvt ot me nvMnvnuuen
AatlonrvwnmcWytor
Conangarcy Plan
AaMon njaponatWy tor SECURfTY MEASURE oadhg
Aa^gn naponaUKy tor praew«d SECURHY
MEASURE I
Condua i»»>w * SECURfTY MEASURE cefl»
ttrdi tarproQmMng MO*
-h
SECURITY MEASURE
Awlon MpomMty tor IM and Mognttn «oln of
SECURITY MEASURES
RITY MEASURE Ml cmm and
UpdaH Oa« Manaaanv* Plan I
Sunrwtto r«fkiod vpneaogn M
Pietod Mjnaovnn Plan
4y mMQarnart appnooh In
SECURITY MEASURES noadtd tor
Cod* irtMM SECURITY MEASURES •
Aegufca and maul SECURITY MEASURES
Prapora SECURITY MEASURE mam of
docunm or MpanM Soeurty Mamat. I
T*a« SECURITY MEASURES
Pnpan twataton Candm^y
•ppkaten Cononganey Plan
UPOATEP;
Pnotoa Managtmant Plan
Daw Manaoonanl Ban
SyMom TM Ooawnanf
AceapMne* Tact Ooemnr
MEK;
AppNtatiun Contingoncy
ConUnuHy ot OpMiont Plan, par tf A Woman
Swwty Manual' Apptndoi 0 («rcquuvd)-.
OovMopmom Dau Baaat-
MaManano* ManuaT-
UtorMonuar
Cporcion Manuct-
Saeurtiy Manual" .
UMT Sucpon Mai*riak~
OoMtapmomOocwonPapar
•iav«d M Oaalgn baMtn*
>MraioOSWERSlRMO
4-30
-------
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" (FTPS
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
• Program library that
- permits only authorized persons to access modules
- records all accesses
- associates control data (e.g., 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
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
-------
OSWER DIRECTIVE #9028.00'c
Developmgnt 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
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?
-------
\~ ^ i . * C y 7,
EXHIBIT 4.7-1: IMPLEMENTATION STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
Ra«ttan«9aourtyPlanporOMe«r>OS.I
~J PRODUCTS
Who •« b* iMpomU* tor «pMaMn Mcudiy
manaojmoni appro** during knptomanUMon stag*?
Who «tf conduct nw*» and approve i/Mam and
Mttng at SECURITY MEASURES?
md «pnw« OMB 9041
Who «M I*»
and *»«»• SECUMITV
Steurtty Manual. I rwcMvy?
Who wrfM to ivapomto
twwQ afid prapara*
TraWng SlaMman?
Who «M o
v and appravo AfJiAJdoi'i
Coftttotion WonajhaarT
Who «ll to rwoorttt** lor PradMcdon (tap*
PROJECT COKTINUATIOM QgCaiOMf;
OW SIRMO wova Appneaaon CarMlcadan
Wormnaar?
Do raiub of SECURITY MEASURE lyMpm and
a rvMtf unKMpWM RISKS?
Wll an PfBduedon «ap* SECURITY MEASURES to
m piaoi 6y mo Man «t» Produoagn
Ajalgn RKporsfeMy lor. nMaai and i
I MBkig 01 SECURITY MEASURES
of OMB IMS eomplan Saorty Plan. I
Ajdgn rMpenoUky tor iwtatti at SECURITY
MEASURE Hrtona of opanoa
MeMkig Saeurty PM. I raaxMd
AM«n member tor OTpMon at
Swmwtt* raftiad mUeatton Mcuty managamM
WpnMtfi ki hptamomaoan OicMn Papar
UDdM edteanon Mcwty n
Ptopei Uanagamani Plan
nagam
ctito
piao* sECumrv MEASURE*
Condua tyoam an« i
StCURfTY MEASURES
OMB oamjlam SaeuMy Plan, I
HnatM seCURfTY MAMAOEM0IT
Conduct MBMiy aMnnaa* and MMng
T«**g Hapon and Saeuty TraMng
P«o)aa Uanagarnant Plan
OaMManagamaniPlan
MaManano* Manuar
UtarManuM*
Oparaten M«waT
SaoMy ManuaT*
UMT SUCPOTI MaMafe*
OMB tO-OS ComjM« Swurty Plan'-
MEW;
AppNGaUon CaRXlEatton WortanaM*
Pmduoton Ou OkMnaty
InVvnanuiWi OadMen Pap*r
Tracing Rapon
Security Tramng SutamtnT.
>aMloOSWERSIRMO
4-36
-------
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 testing 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
• 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 (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.
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
-------
EXHIBIT 4.S-1: OPERATION STAGE
APPLICATION 8ECURITT MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
• Operation and periodic monitoring of SECURITY MEASURES
• Responding to ADVERSE EVENTS
• Modification requests
• Ongoing security awareness and training
KEY
TC7
DECISIONS
ACTIVITIES
PRODUCTS
Who nHH t» rMporafeM tar opwoflon md pvtodfc
montoona at SECURITY MEASURES?
Do ADVERSE EVENTS r«M
unneegmxM VULNEAABR.mES Out nut b»
MOIMMO ««i rw» or whweM SECUnmr
ueASUREST
Who wl b* fMeontU* *ef ongoing Mcurtr
oiwonoH and vammg and tor lubnwng «nnuM
SMurtly Tnmng Suummi?
u
HM SECURITY MEASURES BOOT kwotad •
PROJECT CONTINUATION MCMOW:
Km* ADVERSE EVENTS mmlod nough BISKS »
prcdud* oomlnutd produeHonT
ItaMot SECURITY MEASURES
R»u.nmnd iiu»lUttji» le 88CURITY
MEASURC1I
H«pon ADVERSE EVENTS
Cextwt Mtutqr MMMnMi and tiHng
UPPATTP;
SMuntr TnMng SUMmonT»
4-41
-------
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 SECUR/TY 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 SECUR/TY 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
SECUR/TY MEASURES are now operating. Periodically, you may supplement these
routine SECUR/TY 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 SECUR/TY 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
-------
EXHIBIT 4.0-1: EVALUATION STAGE
APPLICATION SECURITY MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
: Certification of Mfeting applications
Revaluation of SECURITY MEASURES atono or as part of
system •valuation
• Identification of new VULNERABILITIES
• Review and revision of oversight documents
KEY
DECISIONS
ACTIVITIES
PRODUCTS
Who w« M mcombto tor •MMuMton d SECURtTY
MEASURES?
Hava naw VULNERABILITIES bMn
Who MM raviM. nMaw and i
ovrmghi aocurnam?
Can aiMmg agpucaflona b» eMltatfT
HM ttwra own t Owng* n IT*-" "•• SCNSfTIV-
I7YT
Am SECURITY MEASURES adMUM?
ii OMB a»0t oonviiini Swunty Ptn *• tar im%ton
(annualy)?
ii irwulatton Quiiutlv* Aivlytli Wu !•>»«• or
Quantum* An«y*i( nmon du* tor rwtton (•Mry
liv* )«M or upon lignflcM oMng*)^
if mtulWiofl Contiftut
Contnotncy Pl>n duo tor tvmlofi (upon wgnllecni
it Sccurty Manud *)• lor rcvWon (upon Ugrtncart
cnang*)?
ii Appleann Ccnikauon VMorhir** du* tar
(«v«y mm y*m or i*on tyufcan eMng*)T
PROJECT COKT1NUATION
Don •vakMton rwMt RISKS Mi
Should SECURITY MEASURE 4
Avtan fWpomMrr tor
MEASURES
«ownuattapanqr<
i and appro** ravMana of«
UPOATED-.
SMtlMy EvakMtton WorK»na«. ow -EPA
lntu«in«Ki Sccunry Manual* Sioton 4*
OSWER Sy««m UpdaM Form lor OSWER Qua
QMS 9041 ConcNant Swurty Plan. » rwcHiary.
MUMton QualUdv* RbK AnalyM WonanM or
OuantMM* Rtok AnriyM Raport. par -EP A
mtormauun Sooiitiy Manual.' Appanda C.
(rwalMton Continuty o) ODarattont Puvt or
Aflptt'MInn Contlngancy Plan, par -EPA mtormuion
SaourKy Manual* AppandB D.
Swurky Manual II raquvad*
AoDHeaUon CarttoBion WorturiMi. o* *EPA
MormaUon SaeurHy Manual* Appanda 3.
VEIL
Syuam Evaluation R«poR
»Submt 10 OSWER SIRMO
4-43
-------
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 VULNERABILITIES 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.2.2 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 4
A t
-------
OSWER DIRECTIVE #9028.00c
4.8.23 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 Cvde 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
-------
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).
445
-------
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 Senior
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 Report
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
-------
\is^ I I rf C T 7,
EXHIBIT 4.10-1: ARCHIVE ftTAOE
APPLICATION SCCURITT MANAGEMENT APPROACH OVERVIEW
OBJECTIVES
• Operation of Archive stage SECURITY MEASURES
• Certification of disposition of SENSITIVE information and applications
ACTIVITIES
PRODUCTS
Who «w t» rmeemttf la AreMw MM* S6CU*»nY
MEA3UKS?
WM «« b* iMpomM* tar
H ipml MpOMton ol SENSITIVE IBpMuUpn or
MOJECT COMTINUATION OCCWONS:
DOM ttpnlton or SENSTTIVE vcwaoon d «•»
MEASURES
AMgniMponMytorc
ODMH AUCWWS STAQE Meutr
UPOATtO:
tfCMttt MFORWATON RESOUACCS.
nqumd by SECURITY MEASURES
AfoMffd tM cycto
new-
AflCHVEO OPERATIONAL BASELINE
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 Uy
OSWER Core Concept:
While INAPPROPRIATE use or misuse of an application may not result in direct
loss of AVAILABILITY, INTEGRITY, or CONFIDENTMLTTY, 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 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 1, "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.
Cprnputer 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. ")
Synonvm: application(s)
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 FIPS 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 Cone 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 uncompromised; 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 1990's,
James Cooper.)
Risk Analysis
OSWER Core Concept:
The methodology to determine RISK by analyzing potential ADVERSE EVENTS,
THREATS, and Vl/LNERAB/ZJT/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.
Other 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 or
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
Vulnerability
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
VULNERABILITIES 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.00c
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 B 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 (FTPS)
• OSWER System Life Cycle Management Guidance (SLCMG)
• Other Related Documents „
Privacy Act of 1974 CPublic 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 agencies 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-508). 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 clear guidelines that must be met by Government officials
prior to requiring a remote processing services company to provide information
from a customer file.
The Computer Security Act of 1987(Public Law 100-235). 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-71: Security of Federal
Automated Information Systems established that financial information should
be considered sensitive.
Office of Management and Budget (OMB) Circular A-123: Internal Control "Systems
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 #9028.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 Management 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 #9028.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 Anal sis, of the EPA Systems Design and Development Guidance,
Volume B, 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"
• "Information 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 Techniques''
• "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 Configuratic
January, 1969. Describes OSWER's pra
tailoring industry proven configuratio
to the OSWER environment.
U. S. Environmental Protection Agency, C
Response. Practice Paper Benefit-Cosi
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 nerwoi
does an excellent job of presenting a o
projections for the future of compute!
1990's.
U. S. Department of Energy, DOE Risk /
Approach. Office of ADP Managemen
DOE with a 6 step approach for condu
on a particular area of concern. Work**.
an organized format to address each of t
U. S. Environmental Protection Agency, A;
Evaluation of the Standards and Proced
Laboratories. Office of Information Re
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 «ach 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 C-l) 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
-------
OSWER 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
• Uvel (High, Medium, or LOW) of SENSITIVITY to the SECURITY 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 C-4 shows where and how each SECURITY MEASURE is
addressed in the OSWER life cycle, as follows:
• Initiation Phase (Planning)
• Concept Phase (Analysis) ,
?.
• Definition Stage (Requirements)
• 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.
C-4
-------
OSWER DIRECTIVE #9028.00c
Appendix O Security Characterization Matrices
C-l
-------
fflflff
m
S'S'
Tim m
TITI TI TI o m CD
m
4V
s
m
T!
m
w
03
m
z
m
Z
-------
-------
8
m
CD Tim
• it
3m
"4 5
OD
mm m 03
mm
•c •<.
x
r>
im
1
•<
3
m
n
-------
OSWER DIRECTIVE #9028.OOc
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 C-l) 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
-------
OSWER DIRECTIVE #9028.00c
• Source document
• Level (HJgh* Medium, or Low) of SENSITIVITY to the SECURITY OBJECTIVES
of AVAILABILITY, INTEGRITY, CONFIDENTIALTTY, 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 C-4 shows where and how each SECURITY MEASURE is
addressed in the OSWER life cycle, as follows:
• Initiation Phase (planning)
• Concept Phase (Analysis) .
r.
• Definition Stage (Requirements)
• Design Stage (Design)
• Development Stage (£pde/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.
C-4
-------
CNJ
O
O)
X
DC
O
I
IT
LU
O
CO
111
LU
LU
0)
d
LU
I
eg
x
LU
LU
LU
LU
£
I
-------
0>
I
X
QC
O
GC
LU
o
co
z
LU
LU
01
CO
oc
111
Q
O
t
CD
I
X
LU
ID
u
9
CO UJ 0)
LU UJ U.
-------
CNJ
9
x
(E
o
tr
LU
o
CO
UJ
X
CVJ
6
t
m
I
x
HI
Ill
-------
X
DC
I-
£
(Q
i
£
2
o
u
-> ->
•> •>
o
w
UJ
cc
z
CVJ
6
I-
ffl
X
X
UJ
I
LU HI
COLU LULU
U. LL U.U.
8
-------
o
9
Q.
X
oc
(E
HI
o
0
LU U.
= .s
LU U. CD
LU
O
-------
-------
CNJ
o
§
£
ID
o
o
c/>
LU
CO
<
cc
HI
D
CO
6
t
CD
I
X
HI
111
ID
111
in
s s
LU LU
LU
O
-------
a
S
CL
X
cc
Q
i
QC
O
C/3
UJ
CD
UJ
_l
D
op
6
H
99
x
ai
i
1
U. UJ
UJ UJ
u. a.
lillllllllll
a
a
3
0.
w
a.
UJ
n
UJ
* n
U. CD
UJ
o
CC
§
o
-------
o
O)
s.
X
£
Q
I
QC
HI
o
UJ
QC
-------
C\J
®
ff
a.
X
CC
cc
LU
LU
CC
C/3
<
LU
6
CC
D
O
H
CD
X
LU
UJ
UJ
CO
-Jl
21
LU
03
LU
LULULU
LU
CC
i
1
LU
O
-------
(0
0.
LU
O
w
CO
X
QC
<
o
<
N
CC
OJ
O
<
QC
•<
O
UJ
CC
C/3
<
Ul
GC
D
O
UJ
C/5
H
03
I
X
UJ
a
I
•
>
;2S2^ •>->!
01 HI
LULUUJ
LUUJUJUJCDUJUJLU
.£ .S
Ill
I
3
LU
QC
I
1
UJ
l
T .
-------
!
O
1
QC
LU
UJ
GC
111
QC
§
W
O
H-
I
X
UJ
>
LU
1
i
I
UJ UJ UJ UJ UJ UJ Ul
UJ UJ UJ UJ UJ UJ UJ
LU I—
£
1
1
I
o
i
I.
-------
-------
X
LU
o
1
LU
LU
I
LU
O
LU
CO
LU LU
LU
-------
CO
I
I
o
UJ
o
UJ
QC
CO
QC
O
UJ
CO
•if
6
I-
3
x
UJ
o
1
CO
•> _J
UJ LU UJ UJ UJ UJ UJ
UJ '" "f UJ UJ UJ UJ
15
i
C/5
a
ii
!§ •
CO. ->
<£ I
LULL '•§
•fi'fi I
n
lilt
N N I) II
LULL CO X
LU
LU
QC
>
LU
LU
-------
o
QC
g
O
111
cc
QC
§
0)
• •
6
5
x
iii
I
1
LUUJUJU1UJUUUJUJ
UJUJl
s
R *
s
£_
UJE
•S.S
*
2
III
i i i i
UJU.CDX
lii H
^
1
1
I
-------
-------
CO
03
I
5
IH
o
X
o
LU
cc
w
HI
cc
a
•
-------
in
9
I
X
QC
DC
LU
5
O
LU
cc
CO
ID
CC
O
LU
CO
O
I-
5
x
LU
0
CO
1
•>*>•
111
LULU
(0
-------
Q
I
£
S
o
o
ID
CC
Ul
DC
§
6
H
5
x
Ul
U.U. 00 UL UL 00 CD U. CD U. U. U. 00 U. U. U. UL U.
1
.§
B «"
22 I
aiu. -5
SS I
i
2
$
iX
• I I B
LUU.OOX
ui H-*
S 2
i
1
LU
a
§
5
-------
00
o
X
cc
cc
p
Q
O
I
C/5
<
31
CC
§
C/5
¥
o
h-
5
x
ID
UJ
UJ
til
QC
Q.
UJ
1
CO
T 5^-^-^
-S.S
CO UL U. CD 00 U. LL U. U. U. U. U. CD UJ U.
ffi
LU
UJ
1
-------
co
I
X
cr
ac
LU
o
01
cc
CO
<
111
DC
D
O
UJ
CO
t
CD
X
X
UJ
z
UJ
CO
CO
ID
/:
r
-------
X
£
QC
e
o
Ul
cc
lit
CO
6
H
ffl
X
UJ
Ul
1
i
i
03 ffl CD LL U. U. U.
U.HU. U.U.U.U.
< v
Q. s
LU £
.S.S
if*
• i • •
(ULLCDX
Ul
8
*•*!
o
-------
-------
01
9
O>
a
QL
X
£
I
£
at
CC
o
UJ
z
i
LU
CO
I
CD CO CD U. U. U. U.
U. U. U. U.U. U. U.
LU
UJ
2
1
UJ
-------
Q
GC
B
o
o
111
CC
3
o
H.
CO
z
X
UJ
!
aa
< SP
Q. ••
uj QI
s.s
00 CD O U. LLUJ UJ UJ yj UJ CO CO CO U. U. U.
ll
UJU.CDX
IV K
1
I
-------
CJ
9
O)
s.
X
IE
o
cc
w
lil
cc
D
O
LU
S
x
tit
111
tu
1
O
cc
CO
s
3
C00UJ CQ£OCDCDUJ UJ UJ
.S.S
-------
O)
£
x
QC
O
s
QC
s
O
<
I
O
lit
en
CO
<
HI
QC
O
HI
CO
H
QQ
X
X
LU
c
>
z
q
£
Q.
~> ~r
CO m CD U. UL LU LULU LU LU CO CO CO LL LL LL
.s.s
-------
o
ff
Q.
O
o
111
GC
1
UJ
GC
O
UJ
t
CD
X
X
UJ
I
I
CD CO CO
CO LL 11. U. LL U. LL LU CO U. CD LU UJ
.s.s
UJ
cc
>
UJ
1
LU
I
UJ
-------
^t
9
LT
LU
cc
2
o
LU
GC
CO
LU
£
GC
O
LU
CO
CD
X
X
LU
2
uu
>
z
LLI
r
Q.
LU
>
1
S
OT
co u.
LU LU LULU
•S.S
» 1 It II
LULL CD I
-------
IO
o
cc
111
I
o
LU
cc
CO
<
LU
GC
§
7
o
t
m
X
LU
UJ
UJ
ci
CO
2222->
2222->2^-»
LU LU UJ LUU. UJ
LU CO LU UJ UJ
1
LU
LU
i
s
1
LU
-------
(0
n
u
n
n
1
2222
2222
22"?- •>
•^
z
cc
H^
e
«M
I
I
I
o
•••i
?!
a
CO
222
222-^
222
111 ni in in i
LL LL LULU U. CD CO CD LU LU
I
-------
o
O)
C3
Q.
X
£E
DC
ID
O
O
til
QC
<
UJ
cc
D
O
111
C/5
6
i-
5
x
ui
UJ
I
•••
!
CO
•> •>
f iff
I UJ UJ UJ UJ UJ
UI U. U. LL
JR
Is
•SO-
LD il
.S.£
c
I
K
_i
I
s.
» N I U
UJ U. CD X
UJ
UJ
1
UJ
O
UJ
-------
oo
8
O)
X
QC
1
1
cc
O
GC
<
O
111
cc
C/3
HI
QC
O
LU
CO
x
X
LU
LU
1
cc
a.
J
I
a
0)
-r-r-r 222^22
222^22 ->2 3-*->
I U. LU LU LU LL LU LU LU UJ
UJLLLLU.CQU.UJ11I
.3
.Si
ra
|R |
II 1
LU U.
s s
ifil
» » « »
LU u. O X
LU
LU
o
UJ
-------
O)
X
QC
I
en
a
QC
<
O
ID
QC
CO
HI
CO
O
h-
ffi
X
HI
111
LLJ
O
c/5
C/3
LU
lil
cc
Q.
LU
LU
1
8
O
cc
CO
22 2
2^
2^
LU LU CO LU CD CD LU LULU LU LU LU LU
LU U.
if!Illlii
5 .1
2 =5
t I
H
-^
IS •
SO. -J
-S.S |
11R «
E EJ5I
i • n i
LU u. CO I
LU
LU
gc
i
1
£
-------
UJ
LL U.
CO CO LL U, CO
CO
II I N I
LULL 03 2
-------
CM
X
£
o
QC
li)
o
LU
cc
CO
<
LU
OC
O
H
CQ
X
X
LU
LU
I
xz
XX
XX
XX
U. lil CO
UJ UJ
UJI
-------
CVJ
CM
O)
£
x
cc
GC
IH
O
o
111
GC
D
CO
UJ
cc
O
111
CO
h-
CQ
X
UJ
o
CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
LULUUJUJLULJULUUJLIJUJUJUJ UJUJUJLUUJUJUJUJLUUJUJUJ
3—3
3333333330 3 3333
3 3
333333333OO3 3333QQQOQ3Q§
333333333(raccc 3333occcacaccr3crac
333333333<« 3333««<3<<
0.0.0.0.0.0.0.0.0.0.0.0. o. o. o. o. a a. a. a. o. o. a. a.
1
ii S
sir6
.5
§
I
111!!
I
I
•s
flf!
it
(0
= «.
SIS
3 UJ CO
ii H ii
3 1X1 CO
.s
S3 =
8 | I
nit
LU Q O "~"
^ » n n
zoo-
UJ
p .a
or
n it n
0. < CC
-------
CO
CVJ
X
QC
I
o
111
GC
C/5
<
UJ
OC
D
O
H
CD
X
UJ
UJ
I
(0 (0 CO (0 CO (0 CO COCOCO CO CO CO CO CO CO CO CO
UJ UJ UJ LU LU UJ UJ UJ UJ UJ UJ UJ UJ UJ UJ UJ UJ UJ
3=3333 333 3333333 3J
3333333 3
O 31
3333333 3OQ 3 Q Q Q Q Q Q 3}
3333333 3 GC CC 3 CC CC QC (t QC QC 3
3333333 -« 3«««3
Q. Q. Q. Q. Q. Q. Q. OLO.Q. 0. Q. 0. Q. Q. Q. Q. &
i
1.
^9 fO
O >
Q H
* £<
•ti
•8
i
UJ
H
1
\s.
II
CC Q.
UJ
o
1
ssf
3 UJ CO
» i n
3LUCO
CO
UJ
-1
O
uj
bb
-'•IB
-------
OJ
X
£
o
P
GC
HI
O
O
HI
OC
05
UJ
GC
D
O
UJ
CO
H
CO
I
X
UJ
CO
UJ
LU
I
Q.
01
J
O
I
a
CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
LULULUUJUJUJUJUJUJ UJUJLULUUJIJJUJUJUJUJUJUJLULUUJ
333333333 333333333333333
-33333333 3 3 333
O33333333
333
033333333 QOQ3QQQ3QQQQ333
OC33333333 OC CC OC 3 OC QC OC 3 OC OC QC QC 3 3 3
03333333 «<3<«3««333
0.0.0.0.0.0.0.0.0. Q. O. Q. Q. 0. Q. Q. O. Q. Q. 0. 0. Q. OL Q.
fl
•1
s
g>
If
HS 1
I
a.Si
•S «
I
fill
!i
w <
I
3 LU CO
II II II
3UICO
co
O g
< 2
i Q o ~~
« H H
UJ
O .
.2
w «
uj
C£
-I I * I
-------
in
CM
9
I
X
£
Q
O
UJ
CC
CO
UJ
cc
§
CO
t
CD
X
UJ
CO COCO CO CO CO CO CO CO CO CO CO CO CO
UJ LU 111 UJ LLJ UJUJUJLUUJUJUJLUUJ
333333333
33-33
33 33
33O33 OO3OOOOOO
33C33
33<33
Q.Q.O.Q.Q. 0.0.0.0.0.0.0.0. Q.
'
sit
3 at co
i i i
3UUCO
UJ
o
• i •
-------
CD
O)
X
QC
O
CC
LU
O
O
HI
oc
CO
<
UJ
GC
D
O
LU
CO
O
i-
5
x
X
111
(0
-------
a
I
a.
x
£
<
1
5
O
ID
ac
1
LU
CC
3
LU
CO
O
I-
5
I
HI
1
111
CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
LLIUJLU 111 UJ ID HI UJUJLULIJUJUJUJUJUJUJ 111 111 HI HI
333
3333333333 3333
OOO OOOO OOOOOOOOOO OOOO
QQO QOOO QQQQQQQQQQ QOQQ
ccocoe croc ct ac oc ac ccoc cc ec ct cc ac oc occccccr
0. 0. 0. 0.0.0.0. 0.0.0.0.0.0.0.0.0.0. a.a.a.0.
1:
iii
I!
l]
,1s
52
I
N n n
3OICO
3
O O ~
I • »
-
-i i » •
£a.«r
-------
00
CNJ
X
£
o
CC
UJ
O
£
o
UJ
cc
c/3
<
111
tr
D
O
III
CO
CO
X
LU
CO
c75
LU
/)
E
O
LU
To
LU
I
co cocococococococo co co co co co co co co
LULU LULULULULULULULU LU LU LU LU LU LU LU LU
DDDD3DD3 O333
OO OOOOOOOO OOOO OOOO
OQ QQOQQQQQ QQQQ QQOQ
cccr cc oc cc en cc cc cr cc cccccccc cccccccc
0,0. 0.0.0.0.0.0.0.0. O.O.O.CL 0.0.0.0.
3LUCO
ii n ii
3 LU CO
s
I
CO o
Uj • • •
g I
CO 9 '_
LU O O
2? •
UJ
O .52
?: ^.
O cf
LU J C
-till
£o.
-------
9
O)
I
Q
I
£
UJ
I
O
UJ
QC
CO
HI
DC
§
CO
I
x
UJ
CO
m
s
J
UJ
I
CO GO CO CO CO CO CO CO CO COCOCO COCOCOCOCO COCOCOCOCO
QJUJLUUJUJLLIUJUJUJ ID LU LU LU |JJ UJ LU LU LU UJ LU LU LL
333 33333 33333
333 33—33 33333
OOOOOOOOO 333
OOQOOOOOO 333
==
OOOOQ
OC QC QC CC OC GC DC QC OC 333 CC QC CC QC OC CC CC QC CC CC
««<««
0.0.0.0.0.0.0.0.0. 0.1
<«« <««
0. O.O.O.O.Q.
2
ra
sl*
3 HI CO
n it n
3UJCO
o
CO
CO o (_
UJ Q O
w I • It
UJ
O 2
u.
-------
o
CO
o>
S.
X
CC
O
1
CC
s
o
o
LU
QC
0)
2
QC
O
111
O
H
CD
X
UJ
CO CO (0 0) CO CO 0) CO CO CO CO CO COW CO CO CO CO
LUUJUJUJUJUJIULUUJUJLU HI 111 IU HI ID HI LU
3333
33333333333 333 3333
33333333333 333
QQQOQQQOQQQ QQQ QQQO
CC OC CC tt OC DC OC OC DC CC CC CC CC (Z OC DC Z CC
0.0.0.0.0.0.0.0.0.0.0. O.O.Q. Q.O.Q.Q.
I 1
Jilllii.
sssssj
5^2
3 2
> >> >>
llfi
..
T8
ill!
IO.Q.I
M
n
LU
5
a
3UJCO
S c
Sf
01
• •
-------
CO
I
X
£
§
GC
LU
O
LU
cc
D
I
|
GC
I
T
O
H
m
x
LU
LU
111
1
COW) WWW WWWW WWWWWWWWW WWWW
111 111 111 LU LU LU 111 UJ 111 LULULULULUUIUJUJLU 111 UJ UJ LU
3333 333333333 333D
OOOOO OOOO OOOOOOOOO OOOO
QQQQO QQQQ OOOOOOOOO OOOO
CCGCCCCCCC cccrccix cr cc oc cc oc cr c cc cc cccccccc
0.0.0.0.0. 0.0.0.0. 0.0.0.0.0.0.0.0.0. Q.a.a.0.
-------
cvj
CO
X
QC
o
I
£
HI
o
lit
oc
03
HI
O
HI
CO
o
I-
5
x
X
LU
I II
s
3
8
COCOCOCO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU
3 3 3 3 "33333
- 3333- 3333333-33
OOOO O 33330 3333333033
OOOQ Q
ccacoccc ac croc croc ac
3333333033
0.0.0.0. Q. Q.Q.Q.Q.Q. 0.0.0.0.0.0.0.0.0.0.
;tsl
UJ LU LU I
i-l
5
I
31
r
2.5
li
•513
03
3LUCO
i n n
3LUCO
CO
LU
x
LU
• « »
oo-
» »
-------
I
cc
g
O
UJ
cc
UJ
cc
O
o
I-
5
x
UJ
CO
co en co co co co co co coco
LULUUI UJUJUJUILU UJUJ
333
33
333 33333 33
333 33333 33
crcccc croc cc oc
0.0.0. OL 0.0.0.0. Q.Q.
lit
3UI W
i I I
301 CO
CO
UJ
ii
;QO
-------
£
o
H
o
I
o
LU
CC
c/)
<
LU
GC
O
LU
CO
I-
5
X
LU
2
J5
55
LU
0
c
o
co co co co co wen co co co co co c/) co co co co co co cc
LU LU UJ LU LU LU LU LU UJ LU LU 111 LU LU LU LU LU LU LU UJ
3 3333 333 333333 333333
3 ZJDD3 D3D
3 3 D D
3 3333 333 333333 333333
3 3333 333 333333 333333
3 3333 333 333333 333333
a. 0.0.0.0. 0.0.0. 0.0.0.0.0.0. 00.0.0.0,0.
(
si*
3 LU CO
II II II
3 LU CO
I
O —
0.
a
t
-------
in
CO
CC
g
<
IT
X
O
UJ
(I
CO
<
111
cc
O
HI
CO
CO
X
HI
CO
UJ
UJ
UJ
O
LLJ
CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
UJ LLJ HI UJ LU LLJ UJ UJ Ul Ul UJLLJLLJLLJUJUJUJUJLLJUJLUUJ
333333333333
3-33 33 3- 3333-3333333
i3 33 3 3333 3333333
3033 330O30 3333Q3333333
3CC33 33CrQC30E 33330C3333333
<33 33«3< 3333<3333333
Q.Q.Q.O. a.Q.CLa.a.Q. 0.0.0.0.0.0.0.0.0.0.0.0.
sit
3UJC7)
Hid
3LUCO
CO
I I «
O .
M
I
i.
-------
$
I
X
Lf
Q
I
CC
LU
o
.
o
LU
OC
CO
<
LU
CC
§
CO
t
£
x
X
LU
1
LU
s
LU
CO
<
0.
1
S
CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
LU LLJ LU LU LU IU LULULULUUJUJUJUJLU UJUJLULIJUJUJUJUJ
333333 333333333 33333333
333333333 33333333
333333 333333333 33333333
333333
333333 GC OC QC OC OC
O
Lu
U.Q.
w
* i *
-------
(0
CL
CC
g
o
UJ
cc
1
UJ
cc
o
6
H
CD
X
UJ
0) (0 (0 CO (0 0) CO (0 COCO COCOCOCO COCOCOCOCOCO
til LU 111 lit LU 111 LU LU 111 UJ 111 ID 111 111 111 111 111 111 111 111
33333333 33 3333 333333
33333333 33 3333 333333
33333333 33 3=33 333333
§§§§ §§§§§§
tr cc oc oc ec oc cc oc croc ococccer ccaccrocacac
0.0.0.0.0.0.0.0. O.O. 0.0.0.0. 0.0.0.0.0.0.
i
3UJCO
HUH
3 LU CO
Uj
8 !
•
LUOO
*3 • i
£00
0 .53
>• » M
O
-------
oo
CO
cc.
Q
§
ac
o
LU
cc
CO
<
HI
5
cc
o
LU
CO
o
t
eg
X
X
111
Jj
AJ
A
I
>•
o
I
|
j
:
0
(/> CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO
UJ LU LU LU til LU LU LU LU LU LU LU LU LU LU LU LU LU LU LU 111 LU LU LU LU
333333 3333333 333333333333
333333 33-333- 3333333333
333333 33 333 3333333333
CCCrflCQCQCQC CT(XCC33aCC£ ° CC CC CC (I QC OC CC CC CC QC CC
<«33«
0.0.0.0.0.0. 0.0.0.0.0.0.0. 0.0,0.0.0.0.0.0.0.0.0.0.
*?
0>
i
a
I
lit!
Hi;
s
2
3-J
IIIII
> *^s
II
i
55
ifilg^'5
|S8M
If1
IIJI
IHs*
iiiii
II sg
0
sit
3 LU CO
II II II
3 LUCO
o
CO
UJQ O —
w , , •
UJ
O
-t * n ii
-------
cc
LU
o
o
UJ
QC
CO
<
UJ
oc
o
eg
x
UJ
(0(00) (0(0(0(0(0(0 (0(0 (O(0(0 (0 (0 (0 (0 (0 (0 (/
UJ LU LU UJ LU LU LU LU LU LU LU LU LU LU
333 333333 333333 3333333
3-3 333333 33-33- 3333333
3 3 333333 33 33 3333333
3CCCC OCCCQCQCQCflC OC C CC CC QC OC OC QC OC CC OC QC
o
*
« <«
Q.O.O. 0.0.0.0.0.0. O.O. 0.0.0. 0.0.0.0.0.0.0.
O
n
3LUCO
N « N
3LUCO
to
cVi
LU
81
LUQO
UJ
d
>• « w
I
I.
-------
CD
O)
£
X
QC
§
QC
O
O
ai
GC
CO
<
ai
cr
a
ai
O
H
03
I
X
UJ
•5
i
CO CO CO CO CO CO CO CO CO CO CO COCO CO CO CO CO CO CO CO CO
LULULU UJ UJ ID HI 111 UJ UJ UJ UILU LULULULUUJ LULULU
33333 333 33 33333 333
333 33333 333 33 33333 333
333 33333 333 33 33333 333
as
coco: GCccocGccr tracer ctcr ocacccoca: tracer
Q.Q.Q. Q.O.Q.Q.Q. 0.0. O. 0.0. 0.0.0.0.0. 0. Q. 0.
o
n
nun
3UJCO
CO
UJ
Si
UJQ<
J2 • i
IQO
LU
O .S3
"
i i
-------
«
£
£
X
£
CC
I
O
UJ
CC
CO
<
UJ
cc
D
O
UJ
CO
6
K
CD
X
UJ
(/} (0 CO (0 CO C/> CO CO CO CO CO CO CO CO CO COCO CO CO CO CO
UJUJtUUIUJLU UJ UJ |jj uj (jj uj UJ ILJ UJ lit HI UJLUUJUJ
333333 3 3333333 3 33 3333
333333 3 3333333 - 3333
333333 3 3333333
3333
-------
CM
(0
CL
X
oc
o
UJ
5
O
UJ
DC
CO
UJ
CC
o
LLJ
cn
h-
3
x
UJ
Q
UJ
CO
LU
CD
s
UJ
»
X
J
o
UJ
I
i
CO CO CO CO CO CO CO CO CO COCO
UJUJUJUJUJUJUJUJUJ UJ UJ
QOOOOOOOO
QccroccrcrQccrflccr croc
0.0,0.0.0.0.0.0.0. Q.O.
»« g-
> it
3 UJ CO
III
3UJCO
co <3
"J ¥*5
c/5 o <
UJQC
2 • I •
IQO~
UJ
------- |