Erfarenheter från Hazop användning på programvara i Arte740. Presentation för SESAM Claes Norelöv 4Real AB

Transkript

1 Erfarenheter från Hazop användning på programvara i Arte740 Presentation för SESAM Claes Norelöv 4Real AB 1

2 Innehåll 1. Bakgrund 2. Hazops plats i systemsäkerhetsarbetet 3. Vad-Hur gör man. Jämförelse med andra metoder. Bakgrund till Guide words 4. Hazop tillämpning på programvara Exempel på tolkning av Guide words i ett visst context (IAD) 5. Planering och genomförande av Hazop arbetet 6. Sammanfattning - Erfarenheter 2

3 Systemsäkerhetsåtagandet i Arte740 H SystSäk (Försvarsmaktens handbok för systemsäkerhet) Ställer krav på en verksamhet för systemsäkerhet H ProgSäk (Handbok för Programvara i säkerhetskritiska tillämpningar) Ställer systemsäkerhetskrav på utvecklingsprocessen för programvara Ställer systemsäkerhetskrav på planering ledning o uppföljning Ställer generella systemsäkerhetskrav på produkt 3

4 RUP-anpassning och Systemsäkerhet RUP Processen: VAD, NÄR Systemsäkerhetsflöde (H SystSäk) H ProgSäk krav på RUP WFD Anpassad RUP (Development Case) Metod: HUR HAZOP FTA FMEA Dokumentmallar SaabTechspecifikt Guidelines Instruktioner Dokumentmallar 4

6 Hazops plats i Systemsäkerhetsarbetet Planering Fastlägg koncept och policy för Systemsäkerhetsarbetet Värdering av risker Identifiera risker System Safety Program Plan (SSPP) Värdering av risker Bedöm riskens rimlighet Identifiera existerande skydd och säkerhetsbarriärer What If Interaction Analysis Planering Risk Identifiering Identifiera olycka Zonal Analysis Riskbedömning Åtgärdande av risker Allokera säkerhetskrav till Säkerhetsrelaterade delar Värdera olyckans konsekvenser Beräkna programvarans kritikalitet Checklists FMEA HAZOP Management av Systemsäkerhet Systemimplementering Säkerhetsverifiering (SV) Stängning av risker Från riskidentifiering till kritikalitet Tekniker för Riskidentifiering Säkerhetsutlåtande (SCA) Säkerhetsgodkännande (SS) 6 Systemsäkerhetsarbetets livscykel

8 FMEA Start with Single Cause Direction of working Possible Consequences 8

9 FTA Possible Causes Direction of working Start with Single Consequence 9

10 HAZOP Direction of working Vad Start with Single Design Deviation (Fault) Direction of working Hur Utgående från representationer av systemets design, som väl beskriver systemet, postuleras avvikelser från designens intention, som kan innebära risker. Possible Causes Possible Consequences 10

11 Hazop Guide words Guide word No More Less As well as Part of Reverse Other than Early Late Before After Generic meaning NoThis is the complete negation of the design intention - No part of the intention is achieved, but nothing else happens This is a quantitative increase This is a quantitative decrease This is a qualitative increase, where all of the design intentionis achieved together with additional activity This is a qualitative decrease, where only part of the design intention is achieved This is the logical opposite of the intention This is a complete substitution, where no part of the original intention is achieved but something quite different happens Something happens earlier in time than intended Something happens later in time than intended Something happens earlier in sequence than intended Something happens later in sequence than intended 11

13 Hazop tillämpning på programvara Det erfordras representationer av systemets design, som väl beskriver systemet och från vilka man kan utgå när man vill postulera avvikelser (d v s tillämpa Guide words) från designens intention, som kan innebära risker Vilka systemrepresentationer finns när man arbetar med UML? 13

14 Hazop för UML Interaction Diagrams Invisning : A ProtectedObjects_MMI ProtectedObject : ProtectedObject : A ProtectedObjectSto... : A FireUnitObject_MMI 1: ReceiveProtectedObject( ) 2: CreateObject( ) : A FireUnit : FireUnitObject TargetDesignationCo... 3: ReceiveFireUnit( ) FireUnit : FireUnitObject 4: CreateObject( ) : A TrackPresentation_MMI 7: DisplayTrack( ) Track : Track ProtectedObject : ProtectedObject Track : Track 5: BlockDesignation( ) 13: DisplayTrack( ) AutomaticMode : DesignationCommand Designation : DesignationOrder 12: UpdateTrack( ) 10: GetTrack( ) 9: DisplayDesiMode( ) 6: UpdateTrack( ) 8: SetAutoMode( ) 14: RemoveDesignation( ) 11: Designate( ) : A TargetDesignation_MMI : A FireUnit_IF Studerad entitet (Objekt, meddelande) Entiteten har attribut (t.ex Designation Order) Attribut har attributtyp som beskriver (innehåll, periodicitet, svarstid, synkronisering etc) Varje attribut kan anlyseras med hjälp av 11 Hazop Guidewords (No, More, Less, As well as, Part of, Reverse, Other than, Early, Late, Before, After) Guidewords måste tolkas med hänsyn till Context (tex UML-Interaction Diagram) och attributtyp (tex Arrival Pattern, periodicitet) Periodicitet More (för hög frekvens) Periodicitet Less (för låg frekvens) : A FireUnitObjectStorage : A TrackStorage 14

15 Slutsats För kombinationen Context-Attributtyp avgörs vilka Guide words som är tillämpliga och hur de skall tolkas! 15

16 Tolkade Guide words för UML-IAD AttributeTypeName AttributeTypeDescr Guideword InterpretedMeaning GenericMeaning Meddelande i IAD Meddelande innehåll i IAD Meddelande i IAD (Arrival Pattern, periodicitet) Meddelande i IAD (Synch Pattern) Meddelande i IAD (Constraint - svarstid) Meddelande i Interaction Diagram Meddelande innehåll i Interaction Diagram Meddelande i Interaction Diagram (Arrival Pattern, periodicitet) Meddelande i Interaction Diagram (Synch Pattern) Meddelande i Interaction Diagram (Constraint - svarstid) No Inget meddelande This is the complete negation of the design intention - No part of the intention is achieved, but nothing else happens; Before After More Less Meddelandet inträffar för tidigt i sekvensen Meddelandet inträffar för sent i sekvensen Parametervärde för högt (såväl inom som utanför gränser) Parametervärde för lågt (såväl inom som utanför gränser) Something happens earlier in sequence than intended Something happens later in sequence than intended This is a quantitative increase; This is a quantitative decrease; Part of Informationen är ofullständig This is a qualitative decrease, where only part of the design intention is achieved Other than Informationen är fullständig, men felaktig This is a complete substitution, where no part of the original intention is achieved but something quite different happens. More Periodiciteten är för hög This is a quantitative increase; Less Periodiciteten är för låg This is a quantitative decrease; As well as Synkroniseringsproblem This is a qualitative increase, where all of the design intentionis achieved together with additional activity Early Inträffar för tidigt, enligt systemklockan Something happens earlier in time than intended Late Inträffar för sent, enligt systemklockan Something happens later in time than intended No Inträffar aldrig (oändlig tid) This is the complete negation of the design intention - No part of the intention is achieved, but nothing else happens; More Tiden längre än kravet anger This is a quantitative increase; Less Tiden kortare än kravet anger This is a quantitative decrease; Other than Tiden varierar This is a complete substitution, where no part of the original intention is achieved but something quite different happens. 16

18 Hazop - Arbetsgång Initiera Hazop arbetet Planera Hazop arbetet Genomför arbetsmöten (SSWG) Uppföljning 18

19 Initiera Hazop arbetet Ange omfattning och syftet med arbetet (Görs av Stakeholder, projektledare) Utse ansvarig (kan vara SSM) Den som initierar studien skall underlätta för ansvarig för Hazop arbetet att sätta sig in i systemet tillgång till rätt personer (användare, designers etc) 19

20 Planera arbetet Säkerställ tillgänglighet till lämplig design representation Identifiera egenskaper hos den designrepresentation som skall studeras Välj guide words och tolka dessa med hänsyn till designrepresentation (tillsammans med designansvarig) Bestäm mötestillfällen, inriktning, deltagare, lokaler etc Orientera utsedda SSWG-deltagare 20

21 Förutsättningar för Hazop Olika representationer av systemets design, som väl beskriver systemet och från vilka man kan utgå när man vill postulera avvikelser från designens intention, som kan innebära risker Designer(s) som utgående från representationer kan förklara systemets beteende Ett analysteam, med ledare, designer, användare, sekreterare som har förmåga att förstå dels representationen, dels metoden/processen och kan postulera avvikelser och förstå om dessa innebär en risk. Utgående från detta göra rekommendationer eller framföra frågor som måste besvaras. Uppgiften i Hazop arbetet är i första hand att identifiera risker, ej att hitta lösningar. 21

22 Genomför Hazop möte (SSWG) Start Inledning, Planer Presentation av deltagare, Säkerställ kännedom om Guidewords (Startmöte) Förklara avsikten med aktuell design (Designer presenterar) Undersök Designrepresentationen metodiskt Är avvikelse trolig? Nej Dokumentera resultat Ja Undersök/dokumentera orsaker och konsekvenser Ja Definiera uppföljningsarbete Nej Tiden slut? Ja Överens om dokumentation Avsluta 22

23 Hazop möte arbetsgång Start Välj entitet Genomför Startmöte Välj attribut Förklara avsikten med aktuell design Välj Guide Word Är avvikelse trolig? Ja Nej Nej Nej Nej Har alla Guide Words tillämpats på attributet? Ja Har alla attribut för entiteten undersökts? Ja Har alla entiteter för Designrepresentationen undersökts? Undersök/dokumentera orsaker och konsekvenser 23 Ja Stopp

24 Uppföljning Hazop arbetet måste sluta i slutsatser och rekommendationer och inte i frågor Frågor som uppkommit är ofta nödvändigt att hantera mellan möten och är en del av uppföljningsarbetet Om utestående frågor existerar vid det planerade arbetets slut, bör dessa omvandlas till rekommendationer till fortsatt arbete Observera att affärsuppgörelsen kan innebära att slutsatser, rekommendationer och frågor kan transfereras till annan ansvarig 24

26 Erfarenheter Underskatta inte behovet av planering, förberedelser (tolka guide words) och metodutbildning av deltagarna Lätt för deltagarna att förstå och delta i resonemang kring kända vyer av systemet (avvikelser mot avsedd design) Metoden lämpar sig för arbete i team. Lätt att identifiera avvikelser som inte har att göra med systemsäkerhet utan funktionssäkerhet. Bra eller dåligt? Metoden är systematisk, strukturerad, uttömmande Kan å ena sidan medföra mycket arbete, men arbetet blir å andra sidan lätt att stötta med verktyg Metoden fungerar på såväl system som är operativa, som för ny design Metoden kan tillämpas under alla steg i ett systems livscykel (olika representationer av systemet ) 26

27 This document was created with Win2PDF available at The unregistered version of Win2PDF is for evaluation or non-commercial use only.