|
|
| For many years, the de facto standard on relia-
bility used in the United States was MIL-STD-
785. With the demise of that standard under
MIL-SPEC Reform, much more attention has
been given to commercial standards. Un-
fortunately, what many reliability managers
and practitioners have found is a confusing and
endless list of standards on reliability. In many
cases, standards not labeled "reliability" are,
nonetheless, reliability standards. This article
explores how national and international stan-
dards are developed, the proliferation (real and
perceived) of reliability standards brought
about by defense acquisition reform, and ways
for improving the development of reliability
standards.
Standardization in the United States
Within the United States, standards are devel-
oped by either the US Government or through
a voluntary process within the private sector.
Within the Government, the Department of
Defense published most reliability standards.
As already stated, these standards have either
been canceled (e.g., MIL-STD-785) or been
converted to handbooks. For all essential pur-
poses, the development of reliability standards
in the US is now done in the private sector.
The American National Standards Institute
(ANSI) has been the administrator and coordi-
nator of the United States private sector volun-
tary standardization system for 81 years. ANSI
does not develop standards but facilitates devel-
Introduction
Telecommunications and computer & infor-
mation systems are part of our daily routine for
personal and business activities. Telephone,
finance, Federal Reserve, energy, Federal elec-
tions, stock exchanges, air traffic control, as
well as critical governmental responsibilities for
public safety and law enforcement all depend
heavily on networked information systems
which are potentially vulnerable to network-
based attacks. The massive interconnection of
computerized communications and informa-
tion networks has provided infinite opportuni-
ties to our adversaries, placing our nation at
serious risk.
Private industry manages risk by protecting
their information systems assets in accordance
with their perceptions of the commercial value
of the asset, its vulnerability, and the threats to
it. However, private industry has the alternative
of writing off losses as a cost of doing business
or purchasing some form of protection through
insurance. This alternative is not possible at the
national level.
The situation will likely worsen. The factors
that contribute to increased risk, in particular
the huge growth in inter-networking and the
tremendous expansion in data handling capaci-
ties, show no signs of let-up. We continue to put
massive amounts of information in electronic
RAC is a DoD Information Analysis Center Sponsored by the Defense Technical Information Center and Operated by IIT Research Institute
INSIDE
T h e J o u r n a l o f t h e
Standardization in
Reliability
Engineering Information Assurance
into Information Systems
5
FAQ's About IEC
Dependability Standards
6
Call for Papers
14
Industry News
15
Got Data?
Let's Make a Deal
16
From the Editor
18
New from RAC
18
Panelists Sought
to Advise
19
In Memoriam
20
Calendar
22
Help from RAC
By Ned H. Criscimagna, Reliability Analysis Center
By Deborah A. Cerino, Air Force Research Laboratory
Reliability Analysis Center
Fourth Quarter--1999
continued on page 2
continued on page 8
T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r
F o u r t h Q u a r t e r 1 9 9 9
8
locations, accessible to a wide range of
foreign and internal network-based
threats. The potential for large-scale dis-
ruption of major portions of the nation-
al infrastructure is a critical problem.
A coordinated, sustained, Federal
Government response is essential to pre-
clude an information-based national dis-
aster.
What is Information Assurance?
Joint Chiefs of Staff Publication 3-13
defines
information
assurance
as:
"Information operations that protect
and defend information systems by
ensuring their availability, integrity,
authentication, confidentiality, and non-
repudiation. This includes providing for
restoration of information systems by
incorporating protection, detection, and
reaction capabilities."
The Office of the Assistant Secretary
of Defense for Command, Control, and
Communications (OASD C3) website
defines information assurance as "the
component of information operations
that assures DoD's operational readiness
by providing for the continuous avail-
ability and reliability of information sys-
tems and networks. Information assur-
ance protects the Defense Information
Infrastructure
against
exploitation,
degradation, and denial of service, while
providing the means to efficiently recon-
stitute and reestablish vital capabilities
following an attack."
More informally, information assur-
ance describes the process of protecting
America's critical infrastructure of
telecommunications and computer tech-
nology. Information has become a
strategic national asset and the mainte-
nance and protection of our information
systems has become a major national
concern for the United States. The fol-
lowing sections describe the current
information assurance deficiencies, and
a new program to develop a state-of-the-
art software development environment
to design information assurance into
information systems - getting it right the
first time around.
What is Currently Done to Provide
Information Assurance?
The Federal Government is struggling to
address solutions, to put constrained
resources towards critical aspects of the
problem, and to develop a long-range
goal to develop a robust information
infrastructure. Although there are many
points at which existing work interacts
together, the overall picture is one of
fragmentation and inadequacy. An
organized effort to broadly address all
aspects of information assurance has
been slow to materialize.
In 1997, the Defense Advanced
Research Projects Agency (DARPA) in
conjunction with the Air Force Research
Laboratory (AFRL), Rome Research
Site, teamed to attack these problems.
The
Information
Assurance
(IA)
Program was initiated to begin address-
ing some aspects of infrastructure securi-
ty issues in terms of availability, integri-
ty, and confidentiality. The work is
investigating security vulnerabilities in
distributed information systems to
develop architectures, systems, and tech-
niques for providing protection from
attack and exploitation.
Security issues addressed in the pro-
gram include guarding against and being
able to withstand attacks against the
confidentiality of the system, the integri-
ty of its data and functions, and its avail-
ability to provide needed levels of service
to support the mission. Possible attacks
include insertion of malicious code,
break-ins from other networks, and mis-
chievous unauthorized users. The securi-
ty architecture will permit the use of the
best available preventive protection
mechanisms. However, since no security
technology can completely prevent mali-
cious exploitation of vulnerabilities, it
must also provide capabilities for contin-
ually assessing the system's security pos-
ture, and for detecting and reacting to
attempted
or
successful
attacks.
Reaction may include taking further
action to track down or expel the attack-
er, raising levels of security checking, or
redirected resources to allow continued
operation of critical functions if the sys-
tem has been damaged or degraded. An
overall goal is the ability to manage secu-
rity adaptively, responding to changes in
the security situation by adjusting the
security configuration, protection mech-
anisms, and monitoring levels. An over-
all architecture is scheduled for comple-
tion late year 2000.
Assurance, in the context of the IA
Program, is the confidence that can be
established that the system operates as
intended from a security perspective and
protects what it is meant to protect.
Currently, there is no way to com-
pare, contrast, specify and/or evaluate
the information assurance levels of
information systems.
Engineering Information Assurance
continued from page 1
T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r
F o u r t h Q u a r t e r 1 9 9 9
9
What is Needed?
Careful structuring and analysis of a sys-
tem during development can assure that
a system operates as intended from a
variety of perspectives. However, proper-
ties of interest/importance must be spec-
ified up-front. Information assurance
must be designed into information sys-
tems, and continually assessed to ensure
the work product of each lifecycle devel-
opment phase maintains the appropriate
level of appropriate properties. If levels
begin to trail off as the development of
the system progresses, rework of the
product must be accomplished. In addi-
tion, there may be several different
designers and analysts over the system
lifecycle. As systems evolve and their
components are updated, the system
effectively becomes redesigned, necessi-
tating an accompanying re-analysis of
the required properties.
The associated human cognitive abil-
ities necessary to develop and effectively
employ increasingly large and complex
information systems have grown dra-
matically. Even modest information sys-
tems can require hundreds of pages of
documentation. Such systems offer rich
functionality; but it is not possible for
any single person to understand such
systems in their entirety. System users
may not be aware of existing compo-
nents and tools, may not know how to
access them or when to use them, and
may not understand the outputs of tools
and how to modify them to accommo-
date their particular objectives. Support
for all these types of software develop-
ment problems must be provided in
order to have any amount of informa-
tion assurance in the system.
An information assurance design
environment is needed to address the
development problems identified above.
The environment must incorporate
knowledge about how components fit
together and interact. Such an environ-
ment must be able to recognize sub-
optimal design choices and inefficient or
inappropriate design structures. It must
be able to facilitate trade-off analyses
and be a platform for experimentation.
It must be able to allow the comparative
analysis of alternative designs for speci-
fied information assurance properties.
Information Assurance Science
and Engineering Tools (IASET)
Program
DARPA and AFRL initiated a new
Information Assurance Science and
Engineering Tools (IASET) Program in
September 1999. This four year program
will begin to address the problems cited
above and provide a first-cut, but useful,
framework for information systems
design and assessment, yielding quantifi-
able information assurance properties.
This program will provide: a place to
combine methods, tools and experimen-
tation; a software platform for integrat-
ing diverse tools; a distributed environ-
ment that allows for distant collabora-
tion; and the ability to capture rationale
and wisdom gained for future design and
assessment. The formalization of design
and assessment will lead to consistent,
reliable and useful information.
A primary concern in the develop-
ment of an information assurance design
and assessment environment and sup-
porting toolset is support for system
evolvability. An evolutionary system
must be flexible enough to adapt and,
sometimes, be modified while it is in
use. Over a long period of time change is
inevitable and technologies are needed
to effectively and efficiently handle those
changes. It is planned that this environ-
ment will be populated with a represen-
tative set of tools for information assur-
ance purposes. The environment will be
demonstrated on real-world problems,
such as the Air Force Battlespace
Infosphere.
Technologies Needed
To create the environment, enabling
software development tools and tech-
niques are needed. The following tech-
nologies are planned to be included in
the IASET environment.
· Environment Framework
The development of an IA design and
assessment environment will be a frame-
work into which a diverse collection of
science-based assurance tools and other
necessary components can be integrated
such that tools, components, and the
users of the environment can effectively
interact across the lifecycle. The environ-
ment will not only support the iterative
design and assessment processes that are
used to create information systems, but
will also enhance these processes through
tool interoperability, data storage and
sharing, and rapid information access.
The environment will provide standard
interfaces to common services required
by information assurance tools, and the
developers of these tools, to ensure that
the syntactic and semantic properties of
tool data are consistently understood and
interrelated throughout the enterprise
(by the environment, tools, and people).
The environment will promote a com-
mon look and feel for integrated tools,
and will support varying levels of inte-
gration (loose vs. tight; fine-grained vs.
coarse) and a variety of integration mech-
anisms (process and data control, appli-
cation programming interfaces, object
referencing, import/export, message
passing, databases, etc.) to provide the
widest range of possibilities for tool
providers to integrate into the environ-
ment. The environment will be an open
system that conforms to selected integra-
tion standards (e.g., CORBA, DCOM,
HTTP, HTML, WWW, TCP/IP, XML,
UML, ODBC).
· Metrics
Software measurement enables the
evaluation of the quality of software
products and of the capabilities of orga-
nizational software processes, allowing
the specification, management, im-
provement, and acceptance of processes
and products. Metrics should enable
comparison of information assurance
properties between systems and within
systems. The IASET Program will per-
form research in this area taking into
consideration categories of existing met-
rics, new ones needed for information
assurance, how they relate to one anoth-
er, how decisions can be made from
them, the math needed to operate on
them, benchmarks needed, and methods
to be used. The solution will be an inte-
grated approach rather than an ad hoc
collection of point solutions.
· Methodologies
An important component of the suc-
cess of the program is the requirement
for a comprehensive set of methodolo-
gies for overall information assurance
specification, design, assessment, opera-
tion, and evolution of the system under
development. The challenge will be to
create usable, effective methodologies
that are general yet extensible and flexi-
T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r
F o u r t h Q u a r t e r 1 9 9 9
10
ble, repeatable and consistent, automat-
able and cost effective, and ultimately
validatable.
· Modeling
Modeling and modeling tools/tech-
niques to analyze different, interdepend-
ent characteristics of systems such as per-
formance, safety, security, and reliability
as well as models of information systems
operation, faults, and events (attacks,
adversaries, countermeasures, etc.) will
promote the effective evolution of sys-
tems with high assurance attributes.
Models can explicitly represent the
designer's understanding of an entire
system, including the information pro-
cessing architecture, the physical archi-
tecture, and the environment it operates
in. Using modeling technology one can
capture the requirements, actual archi-
tecture, and the environment of a system
in the form of high-level models.
Requirements models will allow the
explicit representation of desired func-
tionality and/or non-functional proper-
ties. Architecture models represent the
actual structure of the system to be built,
while the environment models capture
what the "outside world" of the system
looks like. Integrated modeling can be
used for the automatic synthesis of
information system software, guarantee-
ing the correctness of the resulting code
with respect to certain properties.
· Scenarios
Scenario techniques can be applied at
several levels to support the develop-
ment and assessment of information
assurance. Most system development
approaches to date have primarily
focused on system development/evolu-
tion from a pure product phase perspec-
tive, with little or no linkage to user
application context. A scenario-based
approach can describe the relationships
that exist between information system
concepts, requirements and design com-
ponents. The information assurance
metrics developed can be affiliated with
scenarios for the purpose of rating infor-
mation system design approaches.
Another key payoff area for scenario
methods and tools is reducing the
amount of time, effort and resources it
takes to design application scenarios to
test and evolve the new information
assurance paradigm. Scenario methods
and tools can be employed for testing
new information assurance doctrine,
principles and metrics.
· Design and Assessment Tools
Such As:
Fault Tolerant Techniques Fault
tolerant techniques such as error detec-
tion, assertions, replication, exception
handling, backward and forward error
recovery, state restoration and check-
pointing, and data diverse techniques
will be necessary. Data-diverse fault tol-
erance techniques can be used effective-
ly to provide a high degree of informa-
tion assurance. These techniques facili-
tate designing high data integrity into a
system by providing a flexible, coherent
structure for replicating data in diverse
forms that resist any single attempt at
corruption, managing operations on
each copy of the dataset, and identifying
which datasets are reliable and which
have been corrupted.
Wrappers A wrapper is a software
layer used to change the interface of a
component or to give new properties,
such as fault tolerance or security, to the
interaction between components. A
wrapper forms a boundary for that part
of the system. By changing wrappers
component interfaces can be changed to
allow new connections between compo-
nents. Properties can be changed to sat-
isfy new requirements. Software wrap-
pers are often used to assemble existing
subsystems into a larger system with new
properties and functions. The wrappers
know the protocols needed to make the
subsystems work together even if they
were not originally designed for a com-
mon purpose. A dependable wrapper
imparts critical properties to each com-
ponent that it wraps, for example, fault
tolerance and/or security. Wrappers for
dependable systems and wrappers with
variable sets of protocols have been
implemented. Research is needed for the
development of new adaptable wrapper
technology and the scale-up of existing
wrapper technology to become part of
the information assurance design and
assessment environment to enable the
successful development of Information
Assurance software systems.
Architecture Notations and Represent-
ations Software architecture is an area
of growing importance. Software archi-
tecture is: 1) a medium of communica-
tion among a project's various stakehold-
ers, 2) the earliest set of design decisions
in a project, and 3) a high-level abstrac-
tion of the system. The study and prac-
tice of software architecture is still
immature. Rigorous techniques need to
be developed to describe software archi-
tectures so that the architectures can
be analyzed to predict nonfunctional
system properties (such as those that
are part of information assurance).
Moreover, architecture-based activities
need to be more precisely defined and
supported with processes and tools, and
need to be smoothly incorporated into
existing development processes. Specific
areas for further research include:
Representation How to communi-
cate an architecture. This problem has
manifested itself as one of representing
architectures with linguistic facilities,
but the problem also includes selecting
the set of information to be communi-
cated (i.e., represented with a language).
In an effort to address these problems,
formal languages for representing and
reasoning about software architecture
have been developed. These languages,
called architecture description languages
(ADLs), seek to increase the understand-
ability and reusability of architectural
designs, and enable greater degrees of
analysis.
Analysis How to analyze an archi-
tecture to predict qualities about sys-
tems that manifest it, or how to evaluate
an architecture for fitness. More gener-
ally, how to compare and choose
between competing architectures to
guarantee information assurance for
certain required properties of interest.
Design Critics Software critics can
help solve development problems by
providing the system developer with
selective information at the time it is
needed. A critic is a software system that
provides a reasoned opinion about a
product or action and provides this
opinion to a human "user." Critics,
unlike passive help systems, do not
require users to ask a question. Critics
T h e J o u r n a l o f t h e R e l i a b i l i t y A n a l y s i s C e n t e r
F o u r t h Q u a r t e r 1 9 9 9
11
allow users to be in control and inter-
rupt only when user's actions could be
helped. An advantage of critics is that
learning occurs as a natural product of
the problem solving process. The critic
approach is an effective use of knowl-
edge-bases to guide developers/users in
their tasks.
Testing
Regardless of the software techniques
used to develop the software, the end
result is software code and that code
needs to be assessed. This code needs to
be thoroughly tested so that, with a high
level of confidence, the system user can
be assured the software will correctly
perform its intended function. Research
is needed to improve and scale-up exist-
ing test and analysis technologies to
support the development of information
assurance systems. This includes static
and dynamic analyzers to perform such
analyses as data flow analysis, depen-
dency tracing/checking, and test cover-
age for assessing software qualities,
demonstrating the absence of certain
classes of undesirable behaviors, and
understanding
and
predicting
the
impact of change. Hybrid processes
combining specification and modeling,
analysis and testing, and metric evalua-
tion are needed.
Ontologies
The expectation that numerous software
tools and systems can be effectively
designed to address large, complex infor-
mation assurance problems requires the
development of a well-defined shared
ontology to formally describe the nature
and substance of the problem domain.
Without such a formal description, the
continued advancement and refinement
of solutions to the problem are hindered
by difficulties in integration, communica-
tion, and consistency.
The main purpose of an ontology is
to enable communication between com-
puter systems in a way that is independ-
ent of the individual system technolo-
gies, information architectures and
application domain. The key ingredients
that make up an ontology are a vocabu-
lary of basic terms and a precise specifi-
cation of what those terms mean. The
term `ontology' has been used in this
way for a number of years by the artifi-
cial intelligence and knowledge repre-
sentation community, and is now
becoming part of the standard terminol-
ogy of a much wider community includ-
ing object modeling and XML.
In information technology, an ontol-
ogy is the working model of entities and
interactions in some particular domain
of knowledge or practices. In this usage,
an ontology is a set of concepts such as
things, events, and relations - that are
specified in some way (such as specific
natural language) in order to create an
agreed-upon vocabulary for exchanging
information. An ontology to support the
IASET problem domain is needed.
Conclusion
In spite of all efforts devoted to improv-
ing the quality of software systems, the
reality is that: 1) there may be remaining
faults in software, 2) the hardware can
fail, 3) operators can misuse systems, and
4) the outside environment can behave
badly. It is necessary to continually work
to solve these hard problems. The devel-
opment of an information assurance
design and assessment environment will
begin to solve some of these. It will pro-
vide a vehicle to quantify the properties
the software was designed for, provide a
measurement of those properties, and
allow comparison of components, sub-
systems, and systems.
It is becoming increasingly clear that
we will not be able to assert that a system
is completely assured from all possible
attacks, but that it is possible to assure a
system for certain properties and that
certain types of attacks will produce a
minimal degree (if any) of disruption
worst case. If we develop a system using
the types of technologies described in
this paper then it will be possible for
someone to assert: "This system was
designed with these information assur-
ance properties. It has been assessed with
particular system disruption goals in
mind and found to exhibit the following
flaw(s) which created the following
degree of disruption." It's not a perfect
solution, but it will be possible to know
something about what will happen when
the system is faced with the "worst" risk
from a rational adversary.
Deborah A. Cerino is a computer
engineer and has been working in
software engineering since 1981.
She can be reached at the Air Force
Research Laboratory, AFRL/IFTD,
525 Brooks Road,
Rome NY 13441-4505
(315) 330-1445
cerinod@rl.af.mil
New RAC Catalog Available
Descriptions and price data for all RAC publications, as well as information on RAC training, consulting services,
START sheets, RAC Journal subscriptions, the RAC web page and the RAC data sharing consortium, are provid-
ed in the RAC product catalog. A new issue is now available. To request your free copy, call RAC toll-free at (888)
RAC-USER (888 722-8737).
|
|
|
|
