Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Kapittel 11 – Sikkerhet og pålitelighet Dependability = Reliability, Availability, Safety, Security (RASS) Carl-Fredrik Sørensen 01.04.2014.

Liknende presentasjoner


Presentasjon om: "Kapittel 11 – Sikkerhet og pålitelighet Dependability = Reliability, Availability, Safety, Security (RASS) Carl-Fredrik Sørensen 01.04.2014."— Utskrift av presentasjonen:

1 Kapittel 11 – Sikkerhet og pålitelighet Dependability = Reliability, Availability, Safety, Security (RASS) Carl-Fredrik Sørensen

2 2 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.

3 3 3Chapter 11 Security and Dependability tilgjengelighetstabilitet trygghetsikkerhet Påliteligheten til et system reflekteres av hvilken tillit en bruker har til systemet Sannsynlighet betyr at systemet kjører 99.9% av tiden. Sannsynlighetkatastrofe innbrudd

4 4 Dependability – Når? Hvem? Spesifikasjon Utvikling Validering Evolusjon Program- vare- system Availability tilgjengelighet Reliability funksjonsstabilitet Security feil innbrudd Katastrofe Safety

5 5 Viktighet av pålitelighet (D) = RASS Dependability (http://www.merriam-webster.com) = Reliability, men i programvareutvikling (SE) D = RASShttp://www.merriam-webster.com 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

6 6 Å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.

7 7 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.

8 Kapittel 11 – Sikkerhet og pålitelighet Reliability – Pålitelighet, funksjonstabilitet Carl-Fredrik Sørensen

9 9 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.

10 10 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

11 11 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.

12 12 Værstasjon Kapittel 7

13 13 Terminologi for funksjonsstabilitet/reliability TermBeskrivelse 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 and midnight (midnight is in the 24-hour clock). System fault or defect 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 System errorAn 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. System failureAn 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.

14 14 Sant eller usant? Et program med kjente feil kan bli oppfattet som pålitelig? Hvorfor?

15 15 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

16 16 Source code fault or defect…. Executable Error Executable Failure user developer mistake

17 17 Software usage patterns

18 18 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.

19 19 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.

20 Kapittel 11 – Sikkerhet og pålitelighet Availability – Tilgjengelighet Carl-Fredrik Sørensen

21 21 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.

22 22 Oppfattelse av tilgjengelighet Tilgjengelighet er vanligvis uttrykt som en prosentdel av tiden som systemet er tilgjengelig til å levere tjenester, f.eks %. 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?

23 23 Availability %Downtime per yearDowntime per month*Downtime per week 90% ("one nine")36.5 days72 hours16.8 hours 95%18.25 days36 hours8.4 hours 97%10.96 days21.6 hours5.04 hours 98%7.30 days14.4 hours3.36 hours 99% ("two nines")3.65 days7.20 hours1.68 hours 99.5%1.83 days3.60 hours50.4 minutes 99.8%17.52 hours86.23 minutes20.16 minutes 99.9% ("three nines")8.76 hours43.8 minutes10.1 minutes 99.95%4.38 hours21.56 minutes5.04 minutes 99.99% ("four nines")52.56 minutes4.32 minutes1.01 minutes % ("five nines")5.26 minutes25.9 seconds6.05 seconds % ("six nines")31.5 seconds2.59 seconds0.605 seconds % ("seven nines") 3.15 seconds0.259 seconds seconds

24 24 Eksempler F.eks. gitt en tilgjengelighet på «fem niere» predikerer nedetid for det neste året, måneden, uken. – –Svar: 5.26 minutter sekunder 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.

25 Kapittel 11 – Sikkerhet og pålitelighet Safety – Trygghet Carl-Fredrik Sørensen

26 26 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 ( extreme-consequences/ ) extreme-consequences/ –Therac-25: Deadly radiation therapy –Ariane 5. More than $370 million were lost due to this error.

27 27 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.

28 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. 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 safety- critical as failure may lead to inappropriate treatment being prescribed. Insulin Chapter 1 mental-healt Chapter 5

29 Safety og reliability er relatert 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 Software system Availability tilgjengelighet Reliability pålitelighet Safety Security feilsituasjon innbrudd

30 30 Safety terminologi TermDefinisjon 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. HazardA 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. DamageA 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 severityAn 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 probabilityThe 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. RiskThis 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.

31 31 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.

32 32 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.

33 33 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.

34 Kapittel 11 – Sikkerhet og pålitelighet Security – Sikkerhet Carl-Fredrik Sørensen

35 35 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.

36 36 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.

37 37 Security terminologi TermDefinisjon AssetSomething of value which has to be protected. The asset may be the software system itself or data used by that system. ExposurePossible 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. VulnerabilityA weakness in a computer-based system that may be exploited to cause loss or harm. AttackAn exploitation of a system’s vulnerability. Generally, this is from outside the system and is a deliberate attempt to cause some damage. ThreatsCircumstances that have potential to cause loss or harm. You can think of these as a system vulnerability that is subjected to an attack. ControlA 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 konsekvenser sårbarhet

38 38 Examples of security terminology (MHC- PMS) TermExample AssetThe records of each patient that is receiving or has received treatment. ExposurePotential 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. VulnerabilityA weak password system which makes it easy for users to set guessable passwords. User ids that are the same as names. AttackAn impersonation of an authorized user. ThreatAn unauthorized user will gain access to the system by guessing the credentials (login name and password) of an authorized user. ControlA password checking system that disallows user passwords that are proper names or words that are normally included in a dictionary. konsekvenser sårbarhet trussel

39 39 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

40 40 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

41 41 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

42 42 Open Web Application Security Project (OWASP) – OWASP Top 10http://owasp.org 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.

43 43 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.

44 44 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.

45 45 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.

46 46 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.

47 47 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.

48 Kapittel 11 – Sikkerhet og pålitelighet Dependability – Tilgjengelighet Carl-Fredrik Sørensen

49 49 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.

50 50 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.

51 51 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.

52 52 Chapter 11 Security and Dependability Det koster relativt lite å øke dependability for et system som har lav kvalitet Det bli dyrere og dyrere å øke dependability for et system som allerede har høy kvalitet

53 Mer om pålitelighet Sommerville

54 54 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.

55 55 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.

56 56 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.

57 57 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.

58 58 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

59 59 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.

60 60 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

61 61 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.

62 62 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.


Laste ned ppt "Kapittel 11 – Sikkerhet og pålitelighet Dependability = Reliability, Availability, Safety, Security (RASS) Carl-Fredrik Sørensen 01.04.2014."

Liknende presentasjoner


Annonser fra Google