Kapittel 11 – Sikkerhet og pålitelighet
Dependability = Reliability, Availability,
Safety, Security (RASS)
Carl-Fredrik Sørensen
01.04.2014
Innhold
• Egenskaper av pålitelighet/dependability
– Systemattributtene som leder til pålitelighet.
• Tilgjengelighet (availability) og funksjonsstabilitet
(reliability)
– Systemer skal være tilgjengelig for å levere tjenester og virke
som forventet.
• Safety – Trygghet
– Systemer skal ikke opptre på en utrygg måte eller medføre fare
for liv, helse eller omgivelser.
• Security – Sikkerhet
– Systemer skal beskytte seg selv og deres data fra ekstern
innblanding/interferens.
2
Påliteligheten til et system reflekteres av hvilken tillit
en bruker har til systemet
tilgjengelighet
Sannsynlighet 0.999 betyr at
systemet kjører 99.9% av
tiden.
Chapter 11 Security and
3
Dependability
stabilitet
trygghet
sikkerhet
Sannsynlighet
katastrofe
innbrudd
3
Dependability – Når? Hvem?
Reliability
funksjonsstabilitet
innbrudd
Security
Katastrofe
Safety
• Spesifikasjon
Availability
tilgjengelighet
• Utvikling
Programvaresystem
• Validering
feil
• Evolusjon
4
Viktighet av pålitelighet (D) = RASS
• Dependability (http://www.merriam-webster.com) = Reliability,
men i programvareutvikling (SE) D = RASS
• Systemfeil kan ha vidstrakt effekt med stort antall mennesker
påvirket av dem.
• Systemer som ikke er pålitelige, og som er unreliable,
unavailable, unsafe or insecure kan bli forkastet av sine
brukere.
• Kostnader av systemfeil kan bli svært stor hvis feilen
medfører økonomiske tap eller fysisk skade
– Ariande 5
• Upålitelige systemer kan medføre tap av informasjon med en
medfølgende høy gjenskapningskostnad.
– Seismikk, boredata, helsedata, studentdata, skattedata
5
Årsaker til feil
• Maskinvarefeil
– Maskinvare feiler pga. design eller produksjonsfeil eller fordi
komponentene har nådd slutten på sine naturlige liv.
• Programvarefeil
– Programvare feiler pga. feil i spesifikasjonen, designet eller
implementeringen.
• Operasjonelle feil
– Mennesker gjør mistak eller feil. Antakelig den største
enkeltårsak til systemfeil i sosiotekniske systemer.
6
Andre egenskaper ved pålitelighet
• Reparerbarhet
– Graden av evne til et system å bli reparert hvis en feilsituasjon
• Vedlikeholdbarhet
– Graden av evne til et system å bli tilpasset nye krav
• Overlevelsesevne
– Graden av evne til et system å levere tjenester under fiendtlige
angrep
• Feiltoleranse
– Graden av evne til å unngå eller tolerere brukerfeil.
7
Kapittel 11 – Sikkerhet og pålitelighet
Reliability – Pålitelighet, funksjonstabilitet
Carl-Fredrik Sørensen
01.04.2014
Funksjonsstabilitet - Reliability
• Sannsynligheten for at systemet korrekt vil levere
tjenester som forventet av brukere.
• Funksjonsstabilitet er relatert til sannsynligheten for en
feil skal opptre i operasjonell bruk. Et system med kjente
feil kan være pålitelig.
• Sannsynligheten for feilfri systemoperasjon over et gitt
tidsrom, i et gitt miljø, for en gitt hensikt.
• Eksempel: Et studie utført i 2002 av National Institute of
Standards and Technology (NIST) fant at programvarefeil koster
økonomien I USA $59.5 milliarder hvert år. Studien estimerte at ca.
1/3, $22.2 milliarder, kunne bli eliminert av forbedret testing.
http://www.abeacha.com/NIST_press_release_bugs_cost.htm
9
Oppfatninger av funksjonstabilitet/
Reliability
• Den formelle definisjonen av “reliability” reflekterer ikke
alltid brukerens oppfatning av et systems
funksjonsstabilitet/pålitelighet
– Ukorrekte antakelser som er gjort om miljøet hvor
system skal brukes
• Bruk av et system i et kontormiljø er sannsynlig å være
ganske forskjellig fra bruk av det samme systemet i et
universitetsmiljø
– Konsekvenser av feil påvirker oppfatningen av
pålitelighet/reliability
• Upålitelige vindusviskere på en bil kan være irrelevant i et
tørt klima
• Feil som har alvorlige konsekvenser (f.eks.
motorsammenbrudd i en bil) gis større vekt av brukere en feil
som er brysomme
10
Funksjonsstabilitet/reliability og
spesifikasjoner
• Funksjonsstabilitet/reliability kan bare bli definert med
hensyn på en systemspesifikasjon, dvs. at en feil er et
avvik fra spesifikasjonen.
• Mange spesifikasjoner er ukomplett eller ukorrekt –
System som er i samsvar med sin spesifikasjon kan
“feile” fra et brukerperspektiv.
• Brukere leser sjelden spesifikasjoner og vet dermed ikke
hvordan systemet er antatt å fungere.
• Oppfattet funksjonsstabilitet/reliability er i praksis
viktigere.
11
Værstasjon
Kapittel 7
12
Terminologi for
funksjonsstabilitet/reliability
Term
Beskrivelse
Human error or
mistake
Human behavior that results in the introduction of faults into a
system. For example, in the wilderness weather system, a
programmer might decide that the way to compute the time for the
next transmission is to add 1 hour to the current time. This works
except when the transmission time is between 23.00 and midnight
(midnight is 00.00 in the 24-hour clock).
A characteristic of a software system that can lead to a system
error. The fault is the inclusion of the code to add 1 hour to the
time of the last transmission, without a check if the time is greater
than or equal to 23.00.
An erroneous system state that can lead to system behavior that
is unexpected by system users. The value of transmission time is
set incorrectly (to 24.XX rather than 00.XX) when the faulty code
is executed.
An event that occurs at some point in time when the system does
not deliver a service as expected by its users. No weather data is
transmitted because the time is invalid.
System fault or
defect
System error
System failure
13
Sant eller usant?
• Et program med kjente feil kan bli oppfattet som
pålitelig?
• Hvorfor?
14
Feil (fault) og feilsituasjoner (failures)
• Feilsituasjoner/failures er normalt et resultat av systemfeil
(error) som stammer fra statiske feil (faults) i systemet.
• Feil (faults) vil ikke nødvendigvis resultere i systemfeil (errors)
– Den feilaktige systemtilstanden som er resultat av en feil (fault) kan
være transiente og bli ‘korrigert’ før en systemfeil oppstår.
– Feilaktig kode kan f.eks. aldri bli eksekvert.
• Feil (errors) vil ikke nødvendigvis føre til
feilsituasjoner(failures)
– Feil kan bli korrigert ved innebygd feildeteksjoner og gjenoppretting
– Feilsituasjoner kan man bli beskyttet mot ved å benytte innebygde
beskyttelsesmekanismer. Disse kan, f.eks. , beskytte
systemressurser fra systemfeil.
– Exceptions i Java
– Operativsystemfunksjoner
15
developer
mistake
Source code
fault or defect….
Executable
Error
Executable
Failure
16
user
Software usage patterns
17
Funksjonsstabilitet i bruk
• Fjerning av X% av feil i et system vil ikke nødvendigvis
forbedre funksjonsstabiliteten med X%. Studie ved IBM
viser at fjerning av 60% av produktfeil resulterte i 3%
forbedring av funksjonsstabilitet (reliability).
• Programdefekter kan være i sjeldent utførte deler av
koden og blir aldri møtt av brukere. Fjerning av disse
påvirker ikke den oppfattede funksjonsstabiliteten.
• Bruker endrer oppførsel for å unngå systemfunksjoner
som kan feile.
• Et program med kjente defekter kan derfor fortsatt bli
oppfattet som pålitelig av brukere.
18
Oppnåelse av funksjonsstabilitet
(Reliability)
• Fault avoidance
– Development technique are used that either minimise the
possibility of mistakes or trap mistakes before they result in the
introduction of system faults.
• Fault detection and removal
– Verification and validation techniques that increase the
probability of detecting and correcting defects before the system
goes into service are used.
• Fault tolerance
– Run-time techniques are used to ensure that system faults do
not result in system errors and/or that system errors do not lead
to system failures.
19
Kapittel 11 – Sikkerhet og pålitelighet
Availability – Tilgjengelighet
Carl-Fredrik Sørensen
01.04.2014
Tilgjengelighet – Availability
• Sannsynligheten for at systemet vil kjøre og være I stand
til å levere nyttige tjenester til brukere.
 Sannsynligheten for at system, ved et gitt punkt i tid, vil
være operasjonell og i stand til å levere forespurte
tjenestene.
21
Oppfattelse av tilgjengelighet
• Tilgjengelighet er vanligvis uttrykt som en prosentdel av
tiden som systemet er tilgjengelig til å levere tjenester,
f.eks. 99.95%.
• Tar imidlertid ikke hensyn til to faktorer:
– Antall brukere påvirket av tjenesteavbrudd. Tjenestetap midt på
natten er mindre viktig for mange systemer, enn tap av tjenester i
rushtiden/den tiden flest benytter tjenesten.
– Eks. på systemer?
– Varigheten av tjenesteavbrudd. Jo lengre avbrudd, jo større
forstyrrelse. Flere korte avbrudd er mindre sannsynlig å være
forstyrrende enn et langt ett. Lang tid for reparasjon er et spesielt
problem.
– Eks. på systemer?
22
Availability %
Downtime per year
Downtime per month*
Downtime per week
90% ("one nine")
95%
97%
98%
99% ("two nines")
99.5%
99.8%
36.5 days
18.25 days
10.96 days
7.30 days
3.65 days
1.83 days
17.52 hours
72 hours
36 hours
21.6 hours
14.4 hours
7.20 hours
3.60 hours
86.23 minutes
16.8 hours
8.4 hours
5.04 hours
3.36 hours
1.68 hours
50.4 minutes
20.16 minutes
99.9% ("three nines")
8.76 hours
43.8 minutes
10.1 minutes
99.95%
4.38 hours
21.56 minutes
5.04 minutes
99.99% ("four nines")
52.56 minutes
4.32 minutes
1.01 minutes
99.999% ("five nines") 5.26 minutes
25.9 seconds
6.05 seconds
99.9999% ("six nines") 31.5 seconds
2.59 seconds
0.605 seconds
99.99999% ("seven
nines")
0.259 seconds
0.0605 seconds
23
3.15 seconds
Eksempler
• F.eks. gitt en tilgjengelighet på «fem niere» predikerer
nedetid for det neste året, måneden, uken.
– http://en.wikipedia.org/wiki/High_availability
– Svar: 5.26 minutter - 25.9 sekunder - 6.05 sekunder
• Hvilken påvirkning har krav om tilgjengelighet på «fem
niere» på programvarearkitekturen?
– Tilgjengelighet - Inkluder redundante komponenter og
mekanismer for feiltoleranse.
• Hvilken påvirkning har krav om tilgjengelighet på «fem
niere» på prosessen for programvareevolusjon?
– Du kan ikke ta ned systemet under vedlikehold.
24
Kapittel 11 – Sikkerhet og pålitelighet
Safety – Trygghet
Carl-Fredrik Sørensen
01.04.2014
Safety – Trygghet
• Safety er et systemattributt som reflekterer systemets
evne til å operere uten å true mennesker eller miljøet.
• Måling: En bedømmelse av hvor sannsynlig det er at
systemet vil årsake skade på mennesker eller sitt miljø.
• Eksempler (http://royal.pingdom.com/2009/03/19/10-historical-software-bugs-withextreme-consequences/)
– Therac-25: Deadly radiation therapy
– Ariane 5. More than $370 million were lost due to this error.
26
Safety – Trygghet
• Safety er en egenskap ved systemet som reflekter
systemets evne til operere, normalt eller unormalt, uten
fare for å forårsake menneskelig skade eller død og uten
å skade systemets miljø.
• Viktig å betrakte safety i programvare siden de fleste
innretninger hvor en feilsituasjon er kritisk, omfatter
programvarebaserte kontrollsystemer.
• Safety-krav er ofte utelukkende/eksklusive krav, dvs. At
utelukker uønskede situasjoner fremfor å spesifisere
påkrevde systemtjenester. Disse medfører funksjonelle
safety-krav.
27
Safety-kritikalitet
Primære sikkerhetskritiske
systemer
– Embedded software
systems whose failure can
cause the associated
hardware to fail and directly
threaten people. Example is
the insulin pump
control system.
Insulin Chapter 1
Sekundære sikkerhetskritiske
systemer
– Systems whose failure
results in faults in other
(socio-technical) systems,
which can then have safety
consequences. For example,
the MHC-PMS is safetycritical as failure may lead to
inappropriate treatment being
prescribed.
mental-healt Chapter 5
Safety og reliability er relatert
Reliability
pålitelighet
Availability
tilgjengelighet
Software
system
innbrudd
Safety
Security
feilsituasjon
• Funksjonsstabilitet og
tilgjengelighet er
nødvendige men ikke
tilstrekkelig betingelser for
trygge systemer
• Funksjonsstabilitet omfatter
overensstemmelse mellom
en gitt spesifikasjon og
tjenesteleveranse
• Safety omfatter å forsikre
at systemet ikke forårsaker
skade, uavhengig av om
det er I overensstemmelse
med sin spesifikasjon
Safety terminologi
Term
Definisjon
Accident (or mishap)
An unplanned event or sequence of events which results in human death or injury, damage to
property, or to the environment. An overdose of insulin is an example of an accident.
Hazard
A condition with the potential for causing or contributing to an accident. A failure of the sensor that
measures blood glucose is an example of a hazard.
Damage
A measure of the loss resulting from a mishap. Damage can range from many people being killed as a
result of an accident to minor injury or property damage. Damage resulting from an overdose of insulin
could be serious injury or the death of the user of the insulin pump.
Hazard severity
An assessment of the worst possible damage that could result from a particular hazard. Hazard
severity can range from catastrophic, where many people are killed, to minor, where only minor
damage results. When an individual death is a possibility, a reasonable assessment of hazard severity
is ‘very high’.
Hazard probability
The probability of the events occurring which create a hazard. Probability values tend to be arbitrary
but range from ‘probable’ (say 1/100 chance of a hazard occurring) to ‘implausible’ (no conceivable
situations are likely in which the hazard could occur). The probability of a sensor failure in the insulin
pump that results in an overdose is probably low.
Risk
This is a measure of the probability that the system will cause an accident. The risk is assessed by
considering the hazard probability, the hazard severity, and the probability that the hazard will lead to
an accident. The risk of an insulin overdose is probably medium to low.
30
Oppnåelse av safety – trygghet
• Unngåelse av fare/risiko
– Systemet er designet slik at noen klasser av risikoer ikke kan
oppstå.
• Oppdage og fjerne farer
– Systemet er designet slik at farer blir oppdaget og fjernet før de
resulterer i en ulykke.
• Skadebegrensning
– Systemet inkluderer beskyttelsesmekanismer som minimaliserer
skade som kan oppstå fra en ulykke.
Ch 6 Architecture Safety - Localise safety-critical features
in a small number of sub-systems.
31
Normale ulykker
• Ulykker i komplekse systemer har sjeldent en enkel
årsak siden slike systemer er designet til å være
motstandsdyktig mot “a single point of failure”
– Design av systemer slik at et enkelt feilpunkt ikke medfører en
ulykke, er et fundamentalt prinsipp for design av sikre systemer.
• Omtrent alle ulykker er resultat av kombinasjoner av
funksjonsfeil enn enkle feilsituasjoner.
• Antakelig umulig å forutsi alle kombinasjoner av
problemer, spesielt programvarekontrollerte systemer.
Komplett sikkerhet er derfor umulig. Ulykker er
uunngåelig.
32
Fordeler med programvaretrygghet
• Selv om feilsituasjoner i programvare kan være
sikkerhetskritisk, så bidrar programvarebaserte
kontrollsystemer til økt systemsikkerhet
– Overvåking og kontroll med programvare tillater at et større
område av betingelser kan bli overvåket og kontrollert en hva
som er mulig med elektromekaniske systemer.
– Programvarekontroll tillater adopsjon av trygghetsstrategier som
kan redusere tiden mennesker må benytte i farefulle miljøer.
– Programvare kan oppdage og korrigere sikkerhetskritiske
operatørfeil.
33
Kapittel 11 – Sikkerhet og pålitelighet
Security – Sikkerhet
Carl-Fredrik Sørensen
01.04.2014
Security – Sikkerhet
• Security er et systemattributt som reflekterer et systems
evne til å beskytte seg selv mot eksterne angrep (tilfeldig
eller tilsiktet)
• En bedømmelse av hvor sannsynlig det er at systemet
kan motstå tilfeldige eller tilsiktede innbrudd/intrusjoner.
• Security er essensiell siden de fleste systemer er koblet
til nettverk som muliggjør ekstern aksess til systemet,
f.eks. gjennom internett.
• Security er en essensiell forutsetning for tilgjengelighet,
funksjonsstabilitet og trygghet.
35
Fundamental sikkerhet
• Hvis et system er et nettverkssystem og er usikkert, så
er uttrykk om funksjonsstabilitet og trygghet til systemet
upålitelig.
• Slike uttrykk avhenger av at det kjørende og det
utviklede systemet er det samme. Inntrenging/innbrudd
kan endre både the kjørende systemet og
informasjonen/data i systemet.
• Forsikring om funksjonsstabilitet og trygghet gjøres
derfor ugyldig.
36
Security terminologi
Term
Definisjon
Asset
Something of value which has to be protected. The asset may be the software
system itself or data used by that system.
Exposure
Possible loss or harm to a computing system. This can be loss or damage to
data, or can be a loss of time and effort if recovery is necessary after a security
breach.
konsekvenser
Vulnerability
sårbarhet
Attack
An exploitation of a system’s vulnerability. Generally, this is from outside the
system and is a deliberate attempt to cause some damage.
Threats
Circumstances that have potential to cause loss or harm. You can think of these
as a system vulnerability that is subjected to an attack.
sårbarhet
Control
37
A weakness in a computer-based system that may be exploited to cause loss or
harm.
A protective measure that reduces a system’s vulnerability. Encryption is an
example of a control that reduces a vulnerability of a weak access control
system
Examples of security terminology (MHCPMS)
Term
Example
Asset
The records of each patient that is receiving or has received treatment.
Exposure
Potential financial loss from future patients who do not seek treatment
because they do not trust the clinic to maintain their data. Financial loss
from legal action by the sports star. Loss of reputation.
konsekvenser
Vulnerability
sårbarhet
Attack
An impersonation of an authorized user.
Threat
An unauthorized user will gain access to the system by guessing the
credentials (login name and password) of an authorized user.
trussel
Control
38
A weak password system which makes it easy for users to set guessable
passwords. User ids that are the same as names.
A password checking system that disallows user passwords that are
proper names or words that are normally included in a dictionary.
Threat classes
• Threats to the confidentiality of the system and its data
– Can disclose information to people or programs that do not have
authorization to access that information.
• Threats to the integrity of the system and its data
– Can damage or corrupt the software or its data.
• Threats to the availability of the system and its data
– Can restrict access to the system and data for authorized users.
• IT Sikkerhet og Informasjonssikkerhet
39
Damage from insecurity
• Denial of service
– The system is forced into a state where normal services are
unavailable or where service provision is significantly degraded
• Corruption of programs or data
– The programs or data in the system may be modified in an
unauthorised way
• Disclosure of confidential information
– Information that is managed by the system may be exposed to
people who are not authorised to read or use that information
40
Security assurance
• Vulnerability avoidance
– The system is designed so that vulnerabilities do not occur. For
example, if there is no external network connection then external
attack is impossible
• Attack detection and elimination
– The system is designed so that attacks on vulnerabilities are
detected and neutralised before they result in an exposure. For
example, virus checkers find and remove viruses before they
infect a system
• Exposure limitation and recovery
– The system is designed so that the adverse consequences of a
successful attack are minimised. For example, a backup policy
allows damaged information to be restored
41
Open Web Application Security Project
(OWASP)
• http://owasp.org – OWASP Top 10
• A1-Injection – Injection flaws, such as SQL, OS, and
LDAP injection occur when untrusted data is sent to an
interpreter as part of a command or query. The attacker’s
hostile data can trick the interpreter into executing
unintended commands or accessing data without proper
authorization.
• A2-Broken Authentication and Session Management
– Application functions related to authentication and
session management are often not implemented
correctly, allowing attackers to compromise passwords,
keys, or session tokens, or to exploit other
implementation flaws to assume other users’ identities.
42
Open Web Application Security Project
(OWASP)
• A3-Cross-Site Scripting (XSS) – XSS flaws occur
whenever an application takes untrusted data and sends
it to a web browser without proper validation or escaping.
XSS allows attackers to execute scripts in the victim’s
browser which can hijack user sessions, deface web
sites, or redirect the user to malicious sites.
• A4-Insecure Direct Object References – A direct
object reference occurs when a developer exposes a
reference to an internal implementation object, such as a
file, directory, or database key. Without an access control
check or other protection, attackers can manipulate
these references to access unauthorized data.
43
Open Web Application Security Project
(OWASP)
• A5-Security Misconfiguration – Good security requires
having a secure configuration defined and deployed for
the application, frameworks, application server, web
server, database server, and platform. Secure settings
should be defined, implemented, and maintained, as
defaults are often insecure. Additionally, software should
be kept up to date.
44
Open Web Application Security Project
(OWASP)
• A6-Sensitive Data Exposure – Many web applications do
not properly protect sensitive data, such as credit cards, tax
IDs, and authentication credentials. Attackers may steal or
modify such weakly protected data to conduct credit card
fraud, identity theft, or other crimes. Sensitive data deserves
extra protection such as encryption at rest or in transit, as well
as special precautions when exchanged with the browser.
• A7-Missing Function Level Access Control – Most web
applications verify function level access rights before making
that functionality visible in the UI. However, applications need
to perform the same access control checks on the server
when each function is accessed. If requests are not verified,
attackers will be able to forge requests in order to access
functionality without proper authorization.
45
Open Web Application Security Project
(OWASP)
• A8-Cross-Site Request Forgery (CSRF) – A CSRF
attack forces a logged-on victim’s browser to send a
forged HTTP request, including the victim’s session
cookie and any other automatically included
authentication information, to a vulnerable web
application. This allows the attacker to force the victim’s
browser to generate requests the vulnerable application
thinks are legitimate requests from the victim.
46
Open Web Application Security Project
(OWASP)
• A9-Using Components with Known Vulnerabilities –
Components, such as libraries, frameworks, and other
software modules, almost always run with full privileges. If a
vulnerable component is exploited, such an attack can
facilitate serious data loss or server takeover. Applications
using components with known vulnerabilities may undermine
application defenses and enable a range of possible attacks
and impacts.
• A10-Unvalidated Redirects and Forwards – Web
applications frequently redirect and forward users to other
pages and websites, and use untrusted data to determine the
destination pages. Without proper validation, attackers can
redirect victims to phishing or malware sites, or use forwards
to access unauthorized pages.
47
Kapittel 11 – Sikkerhet og pålitelighet
Dependability – Tilgjengelighet
Carl-Fredrik Sørensen
01.04.2014
Dependability attribute dependencies
• Safe system operation depends on the system being
available and operating reliably.
• A system may be unreliable because its data has been
corrupted by an external attack.
• Denial of service attacks on a system are intended to
make it unavailable.
• If a system is infected with a virus, you cannot be
confident in its reliability or safety.
49
Dependability achievement
• Avoid the introduction of accidental errors when
developing the system.
• Design V & V processes that are effective in discovering
residual errors in the system.
• Design protection mechanisms that guard against
external attacks.
• Configure the system correctly for its operating
environment.
• Include recovery mechanisms to help restore normal
system service after a failure.
50
Dependability costs
• Dependability costs tend to increase exponentially as
increasing levels of dependability are required.
• There are two reasons for this
– The use of more expensive development techniques and
hardware that are required to achieve the higher levels of
dependability.
– The increased testing and system validation that is required to
convince the system client and regulators that the required levels
of dependability have been achieved.
51
Det bli dyrere og dyrere å
øke dependability for et system
som allerede har høy kvalitet
Det koster relativt lite
å øke dependability for
et system som har lav kvalitet
Chapter 11 Security and
52
Dependability
52
Mer om pålitelighet
Sommerville
Availability and reliability
• It is sometimes possible to subsume system availability
under system reliability
– Obviously if a system is unavailable it is not delivering the
specified system services.
• However, it is possible to have systems with low reliability
that must be available.
– So long as system failures can be repaired quickly and does not
damage data, some system failures may not be a problem.
• Availability is therefore best considered as a separate
attribute reflecting whether or not the system can deliver
its services.
• Availability takes repair time into account, if the system
has to be taken out of service to repair faults.
54
Unsafe reliable systems
• There may be dormant faults in a system that are
undetected for many years and only rarely arise.
• Specification errors
– If the system specification is incorrect then the system can
behave as specified but still cause an accident.
• Hardware failures generating spurious inputs
– Hard to anticipate in the specification.
• Context-sensitive commands i.e. issuing the right
command at the wrong time
– Often the result of operator error.
55
Repairability
• The disruption caused by system failure can be
minimized if the system can be repaired quickly.
• This requires problem diagnosis, access to the failed
component(s) and making changes to fix the problems.
• Repairability is a judgment of how easy it is to repair the
software to correct the faults that led to a system failure.
• Repairability is affected by the operating environment so
is hard to assess before system deployment.
56
Maintainability
• A system attribute that is concerned with the ease of
repairing the system after a failure has been discovered
or changing the system to include new features.
• Repairability – short-term perspective to get the system
back into service; Maintainability – long-term
perspective.
• Very important for critical systems as faults are often
introduced into a system because of maintenance
problems. If a system is maintainable, there is a lower
probability that these faults will be introduced or
undetected.
57
Survivability
• The ability of a system to continue to deliver its services
to users in the face of deliberate or accidental attack
• This is an increasingly important attribute for distributed
systems whose security can be compromised
• Survivability subsumes the notion of resilience - the
ability of a system to continue in operation in spite of
component failures
58
Error tolerance
• Part of a more general usability property and reflects the
extent to which user errors are avoided, detected or
tolerated.
• User errors should, as far as possible, be detected and
corrected automatically and should not be passed on to
the system and cause failures.
59
Dependability economics
• Because of very high costs of dependability
achievement, it may be more cost effective to accept
untrustworthy systems and pay for failure costs
• However, this depends on social and political factors. A
reputation for products that can’t be trusted may lose
future business
• Depends on system type - for business systems in
particular, modest levels of dependability may be
adequate
60
Key points
• The dependability in a system reflects the user’s trust in
that system.
• Dependability is a term used to describe a set of related
‘non-functional’ system attributes – availability, reliability,
safety and security.
• The availability of a system is the probability that it will
be available to deliver services when requested.
• The reliability of a system is the probability that system
services will be delivered as specified.
61
Key points
• Reliability is related to the probability of an error
occurring in operational use. A system with known faults
may be reliable.
• Safety is a system attribute that reflects the system’s
ability to operate without threatening people or the
environment.
• Security is a system attribute that reflects the system’s
ability to protect itself from external attack.
• Dependability is compromised if a system is insecure as
the code or data may be corrupted.
62