ENPM 808s
Information Systems Survivability:
4. Requirements for Survivability
- - - - - - - - - - - - - - - - - - -
Requirements for systems survivability and their relationship with subtended requirements for security, reliability, performance, et al.
Security Requirements Must Consider
- - - - - - - - - - - - - - - - - - -
Protection against realistic security threatsProtection against malice and accidents
Protection against insiders and outsiders
System security and information security, tamperproofing, hindering reverse-engineering
Integrity, confidentiality, authentication, authorization, monitoring, accountability, prevention and detection of misuse including Trojan horses and denial-of-service attacks
Note: Existing security criteria cover only a small fraction of a loaf.
Reliability Requirements Must Consider
- - - - - - - - - - - - - - - - - - -
Protection against realistic reliability threatsSystem reliability and availability
Process reliability and availability
Information reliability and availability
Different degrees of fault tolerance and guaranteed availability, including fault detection, fault avoidance, dynamic fault elimination, fault tolerance (e.g., fail-safe, fail-soft, fail-fast, fail-secure), fault recovery (forward or backward), ...
High-Performance Computing
- - - - - - - - - - - - - - - - - - -
Performance in the past has dominated other requirements, often to the exclusion of survivability-related issues. Unfortunately, its tradeoffs with other requirements are often severe, and have led to those other requirements being seriously neglected.John Hennessy (a long-time HPCC leader) recently noted that performance needs to share the spotlight with "availability, maintainability, and other qualities." (IEEE Computer 32, 8, pp. 27-33, August 1999).
Other Survivability-Related Requirements
- - - - - - - - - - - - - - - - - - -
Functional correctness where necessaryInteroperability of (sub)systems
Reconfigurability under duress
Ease of use
Predictability of behavior
Many of these requirements interact with one another, often interfering or creating undesirable tradeoffs. All of the requirements and their interactions need to be considered in advance.
Other Issues
- - - - - - - - - - - - - - - - - - -
Assurance of required performanceSystem and information access
Acceptable alternatives in crisis, with static and dynamic priorities
Prevention of malicious and accidental denials of service; failures due to faults that exceed the coverage of fault tolerance; ensuring adequate performance despite intentional acts, unintentional acts, system malfunctions, and acts of God
Interrelationships Among Requirements
- - - - - - - - - - - - - - - - - - -
Survivability depends on security, reliability, performance, availability, etc. It requires a total-system view over all functional layers.Availability depends on security, reliability, performance, ...
Security, reliability, and performance can depend on each other.
Some commonality would be beneficial in implementation, but it is not common!
It is an emergent property of the system as a whole,
and is not generally meaningful in terms of components.
It depends on security, reliability, performance, and
other system attributes, and indeed may depend on
system survivability!
Here is a topic that is worthy of some discussion:
Contrast system safety with system survivability, with
respect to risks, threats, requirements, and the
implications on design and implementation.
A good reference on system safety is Nancy Leveson's
book, Safeware: System Safety and Computers,
Addison-Wesley, 1995.
What might we do to ensure that we have the
proper requirements from the outset?
Survivability [An overarching
/|\ requirement: a
/ | \ collection of
/ | \ emergent properties]
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
Major / | \
sub- Security Reliability Performance
requirements /|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
/ | \ / | \ / | \
Inte- Conf- Avail FT Fail RT NRT Avail
grity id'ity * |\ modes /\ /|\ *
/| |\ |\ | \ /| \/ /|\
/ | | \ | \ | \ / | Prior- / | \
/ # | \ | \ # ities / | \
MLI No MLS Dis- MLA \ No / [More detailed
/ change | cret- | \ change / requirements]
/ /| | ion- | \ /
/ / | | ary | * Unified * FT=fault tolerance
/ / | | | | availability RT=real-time
X Sys Data X X requirements NRT=non-real-time
/| |\ [X = Shared components of MLX!!]
/ | | \ [* = Reconvergence of availability]
/ | | \ [# = Reconvergence of data integrity]
Survivability Attributes at Different Logical Layers (1)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Funct Security Reliability Performance
layer concepts concepts concepts
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
User Human integrity, Human reliability Responsiveness,
admin educ/training, educ/training, ease of use,
...user identity human interfaces educ/training
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Apps Application Funct'l correct- App availability,
integrity and ness, redundancy, real-time perf.,
confidentiality robustness funct'l timeliness
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mid App integrity + Funct'l correct- Funct'l timeliness
dle confidentiality ness, redundancy, DB of Web, remote
ware in DCE, Webware, backup, recovery, DBs, file servers
DB access control robustness
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Net Net integrity, Net integrity, Netware throughput,
confidentiality, error correction, service nondenial,
availability, fault tolerance alternative routing,
nontamperability, in transmission+ other infrastructure
peer authentic'n, routing, espec. factors, especially
esp. wireless wireless roving bandwidth
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Survivability Attributes at Different Logical Layers (2)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Funct Security Reliability Performance
layer concepts concepts concepts
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OS OS integrity, OS integrity, OS integrity,
data confid'ity, fault tolerance, service nondenial,
service nondenial, sound asynchrony, deadlock avoidance,
OS nontamperability, archiving/backup perf. optimization,
OS development and OS development + OS development and
maintenance, OS maintenance maintenance
user authentication
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HW Access protection Fault tolerance, Proc./memory speed,
domains, HW instruct'n retry, comm. bandwidths,
nontamperability, error-corr codes, contention control,
config. control, HW correctness, HW configuration,
protection against protection vs protection against
interference, interference, all interference,
HW development HW development HW development
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Discussion Topic: System Safety vs Survivability
- - - - - - - - - - - - - - - - - - -
System safety is in some ways very similar to system
survivability.
Discussion Topic: Role of Requirements
- - - - - - - - - - - - - - - - - - -
What are the potential benefits of having
requirements well-defined in advance?
Reading for the Next Class Period
- - - - - - - - - - - - - - - - - - -
Chapter 4 of arl-one (systemic inadequacies):
http://www.csl.sri.com/neumann/arl-one.html.
Also, reflect on Chapters 1 through 4 of
Computer-Related Risks to see where
you think the most important inadequacies lie.
Pick some examples of design flaws and
implementation bugs that you consider particularly
survivability relevant, and be prepared to discuss
them. You may find the Illustrative Risks
summary list useful, with its descriptors.