Mötesanteckningar ordf Inga-Lill Bratteby-Ribbing, FMV: KC Ledstöd (018-120263, inga-lill.bratteby-ribbing@fmv.se)

IG Programvarusäkerhet: Möte # 12, 05-09-01

Antal mötesdeltagare: 8 (se medlemslista).

1 MMI-inventeringarna: a) Koberstein: Förklaringar till OH om varningsprioriteringar vid primärfel med följdfel (se möte 11) kommer att länkas in till motsv dagordn på hemsidan. b) Nummert avser komplettera AT:s tidigare avrapportering med det som tillkommit (bl a checklistor/mallar/patterns) samt renodla filosofin för ’forcing functions’. Olika principer diskuterades: t ex i) huruvida en op skall tillåtas ta över vissa automatiserade uppgifter, ii) om systemet skall förhindra kommando i osäkert/farligt läge eller acceptera det efter motfråga/varning. c) Strandberg: Inga ensade metoder f kritiska MMI:er framtagna, dock specifika för varje tillämpning. Ola Hansson håller i nytt projekt betr gemensamma systsäk-metoder/ -verktyg med det australiensiska bolaget. d) Ordf behöver senast 14/10 skriftliga sammanställningar från de som genomfört MMI-m-projektet + en kort muntlig redovisn på SESAM:s e.m-möte (19/10). Mailkontakter utväxlas under mellantiden. Ordf slutför påbörjad sammanfattning, då deltagarnas bidrag inkommit.
2
Hur mappa programvarans kritikalitet i systemets riskmatris? a) Persson fortsatte denna diskussionspunkt från möte 11. Vilka angreppssätt är att föredra: Mappning av programvaran på en 2-dim matris (konsekvens + sannolikhet enl H ProgSäk fotnot 291)*, på 1-dim (enbart konsekvenser) etc? Kan viss funktionalitet realiseras mha flera av lägre kritikalitet (enl tabell 8 i föreg utgåva av 00-56)? Kan programvarans bidrag till olyckssannolikhet siffersättas? b) Ordf drog några utsnitt från FMV:s heldagskurs i Sw Safety (körs 16/11): fördelarna med en ’origo’-orienterad riskmatris (med högsta risk uppe till höger), vad mappning på 1-dim innebär (ineffektiv/kostsam riskreducering), standarder med 1-dim matris (IEC 61508, DO-178B: där f.ö. distinktionen incident-olycka implicit rymmer ett sannolikhetstänkande), när fördelaktigt med ett 3-dimensionellt betraktelsesätt (med riskkälleexponering som 3:e riskparameter), innebörden av begreppet ’fel’frekvens vid programvarans systematiska ’fel’ jämfört med HW:ans slumpmässiga, tekniker som kan bringa ned programvarans bidrag till olycksfrekvensen (ex diversifiering), hur detta leder till att lägre kritikalitetsgradering av programvaran kan accepteras (vilket 00-56:s tabell 8 f.ö. ger uttryck för) o därmed möjlighet att via statistisk felanalys kunna ta fram siffermässiga skattningar på programvarans bidrag till olyckssannolikheten (i fall där kvalitativa skattningar ej anses duga). Riskprocessen som ett V, vars vänstra skänkel utgör en top-down-analys för bestämning av systemdelarnas kritikalitet + fördelning av riskbudgeten på ingående delar, den högra en bottom-up-uppbyggnad av ingående komponenter med en integritet i paritet med identifierad kritikalitet. c) Ahlenius visade en oprövad ansats betr olycksfrekvensbidraget från programvaran (likelihood /rimlighet) i kvalitativa termer enl * ovan (vanlig/ trolig/ tillfällig). d) Nummert redogjorde för erfarenheter av att bedöma programvara enbart utifrån konsekvens (motiverat av att olycksfrekvensbidraget generellt skulle kunna betraktas som frekvent), en metod AT nu ifrågasätter. Därför omorientering mot en kvalitativ–resonemangs-baserad bedömning av programvarubidraget till olycksfrekvensen. Av kostnads- o effektivitetsskäl förordas flera tekniker för att hålla ned programvarans kritikalitet så långt möjligt (design baserad på partitionering, övervakning, integritetskontrollerad info/ kommunikation, COTS-skal, begränsat utrymme för mänsklig felhandling). Det kan också finnas fall där ett värsta-konsekvens-scenario är orimlig o därmed onödigt pessimistisk (ett motiv för det troligaste utfallet, jmf H ProgSäk fotnot 68). e) Strandberg: Vi tillåter ej att systemdel av högsta kritikalitet enbart realiseras i programvara. Design-by-Contract-teknik kan tillämpas vid bygge av kritisk programvara som garant för avsedd funktionalitet givet explicit angivna förutsättningar är uppfyllda. Ett annat sätt bygga upp den integritet kritikaliteten kräver är inlagda kontroller (t ex en algoritm ledsagad av en enklare snabbvariant/ tabell för överslagsberäkningar/utvärdering av algoritmresultat).
3 Kritikalitetsbegrepp i Def(Aust)5679: Denna punkt tas upp vid nästa möte (p g a tidsbrist).
4 MMI-standarder inom NATO: Koberstein har sammanställd en bild över öppna STANAG-standarder avseende kabinlayout i flygplan o helikoptrar (motsv. MIL-std noterade). De med editionsnr finns hos K, se f.ö. www.nato.int/docu/standard.htm. Gästgivar kollar om S&T:s MMI-expert kan dra ut specifika designkriterier ur 3705 (generell) samt de som berör pgmvara: 3994, 3341, 3370.
5 Organisatoriska aspekter på Systemsäkerhet–Programvarusäkerhet: Nummert inledde denna diskussionspunkt (återupptas nästa möte, bl a med bidrag från Strandberg, Persson). Då har förhoppningsvis svar hunnit inflyta från den enkät AT sänt ut internt, för att utröna hur AT:s systemsäkerhetshandbok, Safety 1st , förstås och tillämpas. Eftersom flera var intresserade, mailas enkäten ut inom gruppen som info o för feed-back.
6 Planering SESAM:s höstmöte (e.m. 19/10, hotell Birger Jarl): 5 min: Diskussionpunkter (Persson, Nummert), 60 min: MMI-uppgiften (Persson, Nummert, Koberstein, Nilsson, Strandberg), 50 min Högström+Elmqvist, 30 min: MMI-designkriterier (Börstell ?), 30 min:SafetyChip, 30 min: HW-partitionerat OS (R Johansson?), dvs totalt 3,5 h - lämplig start kl 13. Detaljer via mail.
7 Övrigt: a) Safeware har integrerat in STAMP (jfr möte 5:säkanalysteknik av infoflöden, såväl för teknisk styrning_ återmatning som organisatorisk ordergivning_bekräftelse) i SpecTRM-verktyget (nu under btest, klart nyår).
b) ’Säkerhetskritiska data, infokällor, infocentraler’ är Ordf:s förslag till seminarietema april 2006 (se möte 11). Ex på intressanta talare: Sidney Dekker (positiv), J Knight, någon från Saab Naval Systems (dialogdrivna parametersättningar/ beroendekontroller) + fler (förslag på talare eller alternativa teman efterlyses från gruppen!).
Nästa gruppmöte: 05-10-19 kl 9:15-12:00 på WTC, Saab Corporate, Kungsbron 1, Plan 6, Sthlm. Därefter förflyttning till hotell Birger Jarl för SESAM:s gruppredovisningar kl 13-kväll (buffé ingår). Anmälan till gruppmötet mailas Ingemar Johansson senast må 17/10 (cc till Ordf). Anmälan till SESAM-mötet sänds till Anna Kåsjö.
c) Tack till alla för ett intressant och givande möte!
Aktivitetslista IG Programvarusäkerhet
Nr
Klar till
Ansvarig
Mötesnotiser senaste möte (#12) 12.1 050915 Ordf
Bokning lokal nästa möte 12.2 050915 I Johansson
Inbjudan f.m. 19/10 (R Johansson:Saabs SW Safety grupp) 12.3 050915 Ordf
Inbjudan e.m. 19/10 (R Johansson: HW-partitionerat OS) 12.4 050915 Ordf
Inbjudan e.m. 19/10 (G Naeser: SafetyChip) 12.5 050915 Ordf
Inbjudan e.m. 19/10 (S Börstell/G Singer/ motsv: MMIdesign) 12.6 050915 Ordf
Undersök möjlighet extrahera designkriterier ur NATO-stder 12.7 050915 Gästgivar
AT-enkät ut till gruppmedlemmar som info 12.8 050930 Nummert
Förberedelser gruppredovisningar e.m. 19/10 12.9 051014 MP,PN,CES,BK,UN,PG,TH,Ordf
Idéer till aprilseminarium (se Övrig-punkt) 12.10 051019 Alla
Förberedelser av diskussionspunkter 11.4 050901 Persson, Eliasson, Nummert
Sammanställn av inkomna enkätsvar 8.4 041014 I Johansson+ Ordf
Kontakt med Dekker 8.6 050228 Ordf
Inventering av företagets MMI-metodik (papper till Johansson)
6.3
050331
Medl (se mikroprojektplan)