Evaluering av kritiske programmerbare systemer. Monica Kristiansen

Transkript

1 Evaluering av kritiske programmerbare systemer Monica Kristiansen 1

2 Sikkerhetsfaglig mantra Det er ikke nok å bygge et system som er sikkert. Du må også kunne overbevise andre om at det er sikkert. 2

3 Dagens temaer Hva menes med kritiske programmerbare systemer? Hvem stiller krav til kritiske programmerbare systemer? Hvilke krav stilles til kritiske programmerbare systemer? Hvordan dokumenterer man at kritiske programmerbare systemer oppfyller kravene? Risikohåndtering Pålitelighetsbasert (statistisk) testing 3

4 Hva menes med kritiske programmerbare systemer? - Systemer som ved å feile kan forårsake betydelige skader på mennesker, miljø og/eller økonomiske verdier. - Vi krever at kritiske programmerbare systemer er dependable, dvs. at de er: - Sikre - Trygge - Pålitelige 4

5 Avanserte løfteraketter (Ariane 5) 5

6 Avanserte flyegenskaper 6

7 Avanserte flyegenskaper 7

8 Hi-Tech passasjerfly 8

9 Avansert medisinsk utstyr 9

10 Bruk av programvare i kritiske systemer En spennende verden! For spennende? er det egentlig for vanskelig å utvikle sikre programmerbare systemer? er dårlige programmerbare systemer egentlig et for stort problem? 10

11 11 Avanserte løfteraketterl

12 12 Avanserte løfteraketterl

13 13 Avanserte løfteraketterl

14 Eksplosjonen av Ariane juni 1996 eksploderte en ubemannet Ariane 5 rakett på sin jomfrutur. - Kun ca 40 sekunder etter lift-off og med en høyde på 3700m, dreide raketten ut av sin flybane, brakk og eksploderte. - Årsaken var en software feil som rett og slett skyltes at programkoden var for dårlig testet. - Det ironiske var at feilen oppsto i en del av softwaren som kun har betydning før raketten tar av. 14

15 Eksplosjonen av Ariane 5 Årsak: - Klarte ikke å konvertere en 64-bit floating point til en 16 bit signed integer i en rutine som ikke hadde noen funksjon etter at raketten hadde tatt av! - Nummeret var større enn det maks en 16 bit integer kan lagre og dermed feilet konverteringen. 15

16 Avanserte flyegenskaper X-31 styrtet fordi trykkmåleren (et rør på utsiden av flyet) ble tildekket av is. Og fordi det var ingen mulighet for manuell override i programkoden ingen feiltoleranse 16 16

17 X januar 1995 gikk jetflyet bokstavlig talt rett i bakken. Årsaken var en opphopning av is på en trykkmåler som resulterte i en falsk avlesning av det totale lufttrykket resulterte i feil informasjon ang. flyets hastighet. Dette medførte videre at flyets kontrollsystem automatisk feilkonfigurerte for en lavere hastighet enn det flyet egentlig hadde. Og selv om piloten visste at alt var som det skulle, tillot ikke programkoden piloten til å ta over flyet manuelt.

18 Hi-Tech passasjerfly A320 Abu Dhabi: Flyet kjørte av rullebanen i stor fart, nesehjulet kollapset. En flight control failure tvang mannskapet til å avbryte take-off selv om de hadde nådd en hastighet som tilsa at de måtte ta av. Åsaken til problemet var en feil i en microchip i flyets Fly-By-Wire system A320 Warzawa: Flyet kjørte i stor fart av rullebanen. Årsaken var at stertk sidevind og store vannmengder på rullebanen gjorde at flyets programkode ikke forstod at det ble foretatt en landing. Resultatet var at oppbremsing av flyet ble hindret I hele 9 sekuder 2 døde

19 Avansert medisinsk utstyr: Therac-25 I perioden fra Juni 1985 til januar 1987 ble 6 pasienter gitt massive overdoser av stråling (3 personer døde av skadene). Årsaker: - Svak softwareutvikling (svakheter i spesifikasjon, dokumentasjon, lite testing mm.) - For stor tiltro til software og fjerning av hardware sikkerhetsmekanismer. - Sikkerhetsanalysen av Therac-25 inkluderte ikke software, selv om software hadde ansvar for nesten alle sikkerhetsmekanismene. 19

20 I perioden fra juni 1985 til januar 1987 ble 6 pasienter gitt massive overdoser av stråling! Tre personer døde! Feil plassering av kodelinjen kostet liv! 20

21 Hvorfor går g r det galt? MANGLER KOMPETANSE OG MOTIVASJON NÅR DET GJELDER SIKKERHET! Fokus er oftest på teknologi : Valg av språk Valg av verktøy Valg av plattformer Fancy tekniske løsninger Innfører ny teknologi for å spare penger ikke liv! Motvilje mot å gjøre det som er nødvendig! 21 21

22 Hvorfor går g r det galt? De målene som oftest anses viktige er: Time to market Cost to market Kompleks funksjonalitet ( Fancyness ) Resultatet er som oftest: Dårlig kvalitet Dårlig sikkerhet Store kostnader i senere faser av utviklingen Tap av menneskeliv, penger og miljø 22 22

23 Sitat fra risikoanalyse av kritisk system It is assumed that after the system is tuned up and tested, no errors will arise from the computer software. This may not be true, but as software error possibilities and the effects hereof are impossible to predict, this assumption is made Dette er ikke bare tullete Det er farlig! 23 23

24 Innføring av ny teknologi Se opp for mytene! SW-baserte systemer er billigere enn analoge eller elektromekaniske systemer. Det er lett å gjøre endringer i SW. SW-baserte systemer er mer pålitelige og sikre. Virkeligheten er noe annerledes! Kostnader relatert til SW vil over et systems levetid kunne bli kolossale! Det er lett å gjøre feil i SW! SW er uhyre komplekst og vi klarer knapt å anslå påliteligheten

25 Hvem stiller krav til kritiske programmerbare systemer? Hvis safety-critical systemer, samfunnskritiske systemer eller systemer som involverer håndtering av konfidensiell informasjon, så er det myndighetene gjennom diverse tilsynsorgan: Jernbanetilsynet Luftfarttilsynet Datatilsynet Etc. Hvis business-kritisk systemer, så er det de enkelte firmaer, eventuelt i henhold til bransjeordninger. 25

26 Hvilke krav stilles til kritiske programmerbare systemer? Prosesskrav Bruk anerkjente prinsipper, følge standarder. Produktkrav Akseptabel risiko (nivåer definert i standarder). Driftskrav Endringer medfører ny evaluering Viktig standard i Europa: IEC 61508: Functional safety of electrical/electronic/ programmable electronic safety-related systems Består av 7 deler. Part 3: Software requirements er av spesiell interesse 26

27 Safety integrity level Det stilles ulike krav til sikkerhetskritiske systemer dette gir opphav til safety integrity level. Prosessen med å utvikle sikkerhetskritiske systemer kan ble sett på som en prosess for risikoreduksjon. Høyrisiko systemer krever mye mer risikoreduksjon enn lavrisiko systemer. Jo større risikoreduksjon, jo høyere safety integrity level. 27

28 28 Risikoreduksjon

29 Safety Integrity Level (IEC 61508) Table 2 Safety integrity levels: target failure measures for a safety function, allocated to an E/E/PE safety-related system operating in low demand mode of operation Safety integrity level Low demand mode of operation (Average probability of failure to perform its design function on demand) to < to < to < to < 10-1 NOTE See notes 3 to 9 below for details on interpreting this table.

30 Safety lifecycle 1 2 Concept Overall scope definition 3 Hazard and risk analysis 4 Overall safety requirements 5 Safety requirements allocation Overall planning 6 OveralI 7 Overall 8 operation and maintenance planning safety validation planning OveralI 8installation and commissioning planning 9 Safety-related 10 Safety-related systems: 11 E/E/PES Realisation (see E/E/PES safety lifecycle) systems: other technology Realisation External risk reduction facilities Realisation 12 Overall installation and commissioning 13 Overall safety validation Back to appropriate overall safety lifecycle phase 14 Overall operation, 15 maintenance and repair Overall modification and retrofit 16 Decommissioning or disposal

31 Software safety lifecycle Software safety lifecycle 9.1 Software safety requirements specification E/E/PES safety lifecycle (see figure 2) Safety functions requirements specification Safety integrity requirements specification 9.2 Software safety validation planning 9.3 Software design and development 9.4 PE integration 9.5 Software operation and (hardware/software) modification procedures 9.6 Software safety validation 31 To box 12 in figure 2 of part 1 To box 14 in figure 2 of part 1

32 Development lifecycle E/E/PES safety requirements specification Software safety requirements specification Validation Validation testing Validated software E/E/PES architecture Software architecture Integration testing (components, subsystems and programmable electronics) Software system design Integration testing (module) Module design Module testing 32 Output Verification CODING

33 Prosesskrav Konkrete anbefalinger (lite utdrag) Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Formal proof C R R HR 2 Probabilistic testing C R R HR 3 Static analysis B.6.4 Table B.8 4 Dynamic analysis and testing B.6.5 Table B.2 R HR HR HR R HR HR HR 5 Software complexity metrics C.5.14 R R R R Software module testing and integration Programmable electronics integration testing See table A.5 See table A.6 Software system testing (validation) See table A.7

34 Produktkrav Utviklet i henhold til anerkjente prinsipper Standarder gir en del konkrete retningslinjer Demonstrert akseptabel risiko gjennom risikoanalyser og verifikasjon & validering (V&V) I alle faser av utviklingen! 34

35 Produktkrav - Noen konkrete retningslinjer Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Use of coding standard C HR HR HR HR 2 No dynamic objects C R HR HR HR 3a No dynamic variables C R HR HR 35 3b Online checking of the installation of dynamic variables C R HR HR 4 Limited use of interrupts C R R HR HR 5 Limited use of pointers C R HR HR 6 Limited use of recursion C R HR HR 7 No unconditional jumps in programs in higher level languages C R HR HR HR a) Measures 2 and 3a do not need to be applied if a compiler is used (1) which ensures that sufficient memory for all dynamic variables and objects will be allocated before runtime, or (2) which inserts runtime checks for the correct online allocation of memory. b) Appropriate techniques/measures shall be selected according to the safety integrity level.

36 Produktkrav Noen (flere) konkrete retningslinjer Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Fault detection and diagnosis C R HR HR 2 Error detecting and correcting codes C.3.2 R R R HR 3a Failure assertion programming C.3.3 R R R HR 3b Safety bag techniques C R R R 3c Diverse programming C.3.5 R R R HR 3d Recovery block C.3.6 R R R R 3e Backward recovery C.3.7 R R R R 3f Forward recovery C.3.8 R R R R 3g Re-try fault recovery mechanisms C.3.9 R R R HR 3h Memorising executed cases C R R HR 4 Graceful degradation C.3.11 R R HR HR 5 Artificial intelligence - fault correction C NR NR NR 6 Dynamic reconfiguration C NR NR NR 7a Structured methods including for example, JSD, MASCOT, SADT and Yourdon. C.2.1 HR HR HR HR 7b Semi-formal methods Table B.7 R R HR HR 7c Formal methods including for example, CCS, CSP, HOL, LOTOS, OBJ, temporal logic, VDM and Z C R R HR 8 Computer-aided specification tools B.2.4 R R HR HR a) Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measures has to be satisfied.

37 Hvordan dokumenterer man at kritisk programvare oppfyller kravene? Prosess QA-dokumenter Sertifisering/revisjon av organisasjon/prosess Dokumentasjon av utviklingsaktiviteter Produkt Designvalg Implementasjonsprinsipper Analyse, analyse, analyse,. Testing, testing, testing, 37

38 Risikohåndtering 38 Risikohåndtering handler, bokstavelig talt om kalkulert risiko. Formål: Grunnlag for å ta en beslutning om hvorvidt risikonivået er akseptabelt eller ikke Kontinuerlig arbeid for å oppnå akseptabel risiko Består av å: Identifisere hva som kan gå galt / uønskede hendelser (hasarder) Analysere mulige årsaker og konsekvenser av uønskede hendelser Vurdere sannsynligheten for de forskjellige uønskede hendelsene skal inntreffe Vurdere tiltak for å reduserte risikonivået til et akseptabelt nivå.

39 Hvordan starter vi? 39 Hva er target of evaluation (TOE)? Hva er kravene til systemet? Standarder? Tilsyn? Kunder, marked? Hvilken informasjon trenger vi om TOE? Modeller av det tekniske systemet, hvordan det påvirkes av andre systemer, mennesker og organisasjoner. Dokumentasjon av utviklingsprosessen. Beskrivelse av operasjonell profil. Hvilke analytiske teknikker trenger vi for å dokumentere at kravene er oppfylt? Teknikker for å identifisere hva som kan gå galt. Teknikker for å finne sannsynligheten for at noe skal gå galt. Teknikker for å finne årsaker og konsekvenser hvis noe skulle gå galt. Vi trenger å binde de analytiske teknikkene og modellene sammen

40 40 Risk Management Process: AS/NZS 4360

41 Risikohåndteringsprosessen Risikohåndteringsprosessen er delt inn i forkjellige faser: Context identification Hva, hvorfor, hvilke premisser? Risk identification Hva kan gå galt (identifikasjon av hasarder)? Hvordan kan dette skje (Årsaksanalyse)? Risk analysis Analyserer, evaluerer og dokumenterer konsekvensene til uønskede hendelser (konsekvensanalyse) Anslår sannsynligheten for uønskede hendelser Risk evaluation Bestemmer risikonivå, prioriterer risikoer og kategoriser risikoer Risk treatment Identifikasjon og evaluering av risikoreduserende tiltak for uønskede hendelser med uakseptabel risiko. 41

42 Og så..gjøres gjerne alt sammen om igjen i en iterativ prosess. Har man foreslått endringer, for eksempel i form av risikoreduserende tiltak har man et nytt system som må analyseres. Kan selvfølgelig konsentrere arbeidet om de forhold som faktisk har blitt påvirket av endringene. 42

43 Analytiske teknikker - De to mest brukte analyseteknikkene er: Failure Mode, Effect and Criticality Analysis (FMEA/FMECA): Hazard and Operability Studies (HazOp): Feiltreanalyse (FTA). Hendelsestreanalyse (ETA) 43

44 FME(C)A 44 Går systematisk igjennom alle komponenter og funksjoner. For hver komponent/funksjon identifiseres: alle mulige feilmåter (feilmodier), mulige årsaker til hver feilmåte, mulige konsekvenser, både lokalt og for systemet som helhet, av hver feilmåte, mulige risikoreduserende aksjoner. I FMECA vil man også klassifisere feilene i henhold til sannsynlighet og alvorlighet (criticality). Teknikken kan benyttes ved ulike faser i utviklingsprosjektet.

45 FMEA Eksempel 1 ID # Enhet Feil-modus Årsak Lokal effekt System effekt Tiltak 1 Bryter som registrer er om utstyr er Indikerer åpen når den skulle indikert lukket på plass 2 Indikerer lukket når den skulle indikert åpen. 1. Brudd 2. Ekstrem temperatur 1. Kortslutning i bryter 2. Høy spenning Detekterer ikke at utstyr er på plass. System indikerer feilaktig at utstyr er på plass. Umulig å bruke maskin, system er failsafe. Maskin tillates brukt selv om utstyr ikke er på plass, system er unsafe. Bruk bryter av høy kvalitet. Preventivt vedlikehold og jevnlige inspeksjoner. Legg til tilleggskontroller? 45

46 Hazard and Operability Studies (HazOp) 46 Strukturert brainstorming. Systematisk gjennomgang av systemet ved bruk av dedikerte ledeord og attributter som gir en styrt assosiasjonsprosess. En HazOp analyse blir vanligvis utført av en gruppe på 4-8 personer med detaljert kunnskap om systemet som analyseres. Gruppen: ledes av en erfaren Hazop-leder. bør til sammen dekke alle relevante aspekter (systemeiere, brukere, utviklere og eksperter). Opprinnelige ledeord/attributter: Ledeord: Ikke/ingen, mer, mindre, deler av, mer enn, motsatt, andre/annerledes. Disse må tolkes i computersammenheng. Attributter: trykk, temperatur, flyt.

47 Start Start Forklar overordnet design Litt forenklet fremgangsmåte Velg enhet Velg ledeord + attributt Nei Nei Mulige avvik? Nei Ferdig med alle ledeord/attributter? Ja Ferdig med alle enheter? Ja Undersøk årsaker, konsekvenser, mulig beskyttelse og dokumenter Ja Slutt Slutt

48 Feiltreanalyse (FTA) 48 I dag den mest brukte analysemetoden i risikoanalyse og pålitelighetsanalyse. Grafisk metode som starter med en hendelse direkte relatert til en identifisert hasard som topphendelse og som så forsøker å beskrive/illustrere de mulige årsaker til at topphendelsen inntreffer ( bakover i tid). Logiske diagrammer Deduktiv metode: Arbeider oss nedover. Finner årsakene? Knytter sammen årsaker med logiske porter (AND og OR).

49 Fault Tree Analysis (FTA) Kode If a > b then x:=f(x) else x:=10 x > p.g.a. if-statement then-part gir gir x > else-part gir gir x > a > b før før If-then-else x:=f(x) gir gir x > a <= <= b før før If-then-else x:=10 gir gir x >

50 Hendelsestreanalyse (ETA) 50 Tar utgangspunkt i hendelser som kan påvirke systemet og kartlegger de mulige videre hendelsesforløp for å bestemme deres mulige konsekvenser. Disse hendelsene inkluderer både hendelser assosiert med forventet operasjon av systemet og feiltilstander. Ser fremover i tid. Fokus på barrierer, dvs. spesielle egenskaper et system har til å stoppe en potensielt farlig utvikling.

51 System: Trykksensor Alarm relay Sirene Trykksensor ETA - Eksempel Alarm relay Sirene Fungerer Fungerer Alarm Aktiv Fungerer Feiler Feiler Fungerer Inaktiv Inaktiv For høyt trykk Fungerer Feiler Fungerer Inaktiv Inaktiv Feiler Feiler Feiler Fungerer Inaktiv Inaktiv 51 Feiler Inaktiv

52 Risikoklassifisering Alvorlighet av konsekvenser hvis hasard inntreffer Risikoklassifisering Frekvens/sannsynlighet for hasard 52

53 Risk classification - IEC Frequency Consequence Catastrophic Critical Marginal Negligible Frequent I I I II Probable I I II III Occasional I II III III Remote II III III IV Improbable III III IV IV Incredible IV IV IV IV Risk class Class I Class II Class III Class IV Interpretation Intolerable risk Undesirable risk, and tolerable only if risk reduction is impracticable or if the costs are grossly disproportionate to the improvement gained Tolerable risk if the cost of risk reduction would exceed the improvement gained Negligible risk 53

54 54 Allocation of SIL

55 Pålitelighetsbasert testing av programvare Hvordan optimalisere testing i forhold til oppnådd pålitelighet? 55

56 Problemer med testing og feilretting Testingen og feilrettingen er for dårlig, lite effektiv tar for lang tid Programmet feiler for ofte Forsinket leveranse Kostnadsoverskridelser Konsekvens : Tapte kunder/marked Pålitelighetsbasert testing medfører: at produktet oppfyller kundens krav redusert Time To Market reduserte kostnader mer tilfredse kunder 56

57 Pålitelighet som kvalitetsmål Hva menes med pålitelighet? Forventet antall feil pr. tidsenhet. Gjennomsnittlig tid til feil (MTTF). Sannsynligheten for at systemet fungerer feilfritt i en gitt tidsperiode. Programvarepålitelighet er et kvalitetsmål med brukerperspektiv! 57

58 Hovedprinsipp Kvantifisere forventet bruk, og benytte dette til å fokusere ressurser på de viktigste funksjonene. lage tester som er realistiske i forhold til faktisk bruk. Skiller mellom Failure : Observert avvik/feil under kjøring. Fault : Feil (bug) som forårsaker failure når den eksekveres. 58 Failure : Brukerperspektiv Fault : Utviklerperspektiv Fokus på dette!

59 Hvordan anslå påliteligheten til et program? Viktige momenter: Vi bør ha bestemt oss for hva som er tilstrekkelig pålitelighet. Påliteligheten er avhengig av hvordan systemet brukes. Vi må altså vite : hvilke krav som stilles av kunden, og hvordan kunden kommer til å bruke systemet. 59

60 Måling av pålitelighet p - Overordnet fremgangsmåte Definer tilstrekkelig pålitelighet (sammen med kunden). Lag bruksprofil. Lag testbeskrivelse med utgangspunkt i bruksprofil. Utfør testing. Noter tidspunkt for feil. Rett feil. Anslå påliteligheten og fortsett eventuelt testingen til påliteligheten er akseptabel. 60

61 Bruksprofil En bruksprofil er en (statistisk) modell som beskriver forventet bruk av programmet. Konsept Beskriv aktuelle operasjoner. Beskriv aktuelle operasjonelle tilstander. Identifiser initiatorer. Anslå hvor ofte hver operasjon vil bli brukt. 61

62 Eksempel : Kalkulator Bruksprofil, forts. Operasjoner Sannsynlighet Addisjon 0.4 Subtraksjon 0.3 Multiplikasjon 0.2 Divisjon 0.1 Operasjonelle tilstander Desimaltall Hexadesimale tall Initiatorer Brukeren

63 Bruksprofil, forts. Bruk av bruksprofil under testing medfører at påliteligheten til systemet på ethvert tidspunkt i testing og feilretting er optimal i forhold til medgått tid. tid som er nødvendig for å nå kundens krav om pålitelighet blir minimert. 63

64 Testing og feilretting Utfør tester med utgangspunkt i bruksprofil. Identifiser failures Noter tid til hver failure. Program debugges mellom hver feil! Feil nr. Tid til neste feil

65 Predikert pålitelighet (Tid til neste failure ) 4000 Tid mellom feil Feil nr.

66 Fremdriftskontroll - Prosjektleder kan benytte pålitelighetsprediksjonene til å: Oppdage lite effektiv testing og feilretting. Uforutsette problemer i designet. Utilsiktet videreutvikling i feilrettingsfasen. Vurdere fremdrift i forhold til tidsplan. Må man sette inn flere ressurser? Kan man prioritere ressurser til bruk i andre prosjekter? 66

67 Fordeler ved å bruke pålitelighet p som kvalitetsmål Bruk av pålitelighet som kvalitetsmål gjør at vi fokuserer på de viktigste feilene, nemlig de som oftest vil inntreffe i virkelig bruk. Det er lett å forstå og ta stilling til. Det medfører mer effektiv feilsøking. Det gir bedre kontroll med faktisk kvalitet før leveranse. Det gir bedre kontroll med tids- og ressursforbruk. 67

68 Oppsummering Utvikling av kritisk programvare krever spesielt fokus på risikohåndtering Det er ikke nok å utvikle sikker programvare DEN MÅ OGSÅ KUNNE DOKUMENTERES Å VÆRE SIKKER! Skikkelig bruk av risikoanalyser gir færre overraskelser i senere faser Risikoanalyse er etterpåklokskap på forhånd Ole Arnt Johnsen, morecom 68