Frågor & Svar om Programvarusäkerhet en sammanställning avsedd att utgöra underlag till ett FAQ-avsnitt för utlägg på nätet 1.

Transkript

1 Utg. nr 1.2 Sida 1 (36) Frågor & Svar om Programvarusäkerhet en sammanställning avsedd att utgöra underlag till ett FAQ-avsnitt för utlägg på nätet 1. Innehåll 1. Inledning Referenser och akronymer Begrepp Personal Processer Produkt Programvaruspecifika egenskaper Återanvändbar programvara Allmänt OS Nyutvecklad programvara System- och Programvaruarkitektur Systemsäkerhetsinriktade konstruktionsprinciper Riskreduktion Produktionsmiljö Programvaruverktyg Standarder Handböcker Dokumenthistorik Version Datum Beskrivning Kap 1-7: Frågesvit för utlägg på IG Programvarusäkerhet Uppdaterat: 2, Nytt: 3.12, 4.2, 5.5, 5.6, 5.7, 5.10, 5.17, 6.1.4, , Fyra nya referenser/akronymer under 2. Tillägg under FAQ: Frequently Asked Questions.

2 Utg. nr 1.2 Sida 2 (36) 1. Inledning Några vanligt förekommande frågeställningar inom området Programvarusäkerhet har sammanställts nedan under ett antal ämnesrubriker. En begränsning av svaren har eftersträvats genom hänvisningar till andra källor, där mer detaljerad information kan återfinnas. Avsikten är att vägleda snarare än att lämna uttömmande svar. För den som är involverad i systemsäkerhetsverksamhet m a p programvara gäller givetvis att göra egna systemsäkerhetsanalyser och avvägningar baserade på egenskaper hos det aktuella systemet, dess användningsprofil samt den avsedda systemomgivningen. 2. Referenser och akronymer [ARINC 653] Avionics Application Software Standard Interface, ASIC Application-Specific Integrated Circuit AUTOSAR Automotive Open System Architecture, BIT CCB COTS [DO178B-HProgSäk] FAA FAR FPGA [F&S Programvarusäkerhet] [GEIA0010-HProgSäk] [GuideWords] [HDriftSäk] [HProgSäk] [HSystSäk] ILS IMA [Intro] Built-In Test Change Control Board Commercial Off The Shelf Cross reference tables for H ProgSäk (E) and DO-178B, FMV, KC Ledsyst 14910:41371/04. Federal Aviation Authority (Luftfartsmyndigheten i USA) Federal Aviation Regulations (FAA:s luftfartsbestämmelser) Field-Programmable Gate Array Frågor & Svar om Programvarusäkerhet, AK Gem 14910:15483/2009. Cross reference tables for H ProgSäk (E) and GEIA-STD-0010, FMV, AK Gem 14910:20608/2009. Ledord/Nyckelord vid HAZOPanalys, IG Programvarusäkerhet: Teknik/Metodik: SESAM faktablad. Försvarsmaktens Handbok för Driftsäkerhet, M H Driftsäk. Försvarsmaktens handbok för programvara i säkerhetskritiska tillämpningar, M H ProgSäk, : Publikationer: Handböcker: H ProgSäk Försvarsmaktens handbok för Systemsäkerhet, M H SystSäk. Integrated Logistics Support Integrated Modular Avionics Programvarusäkerhet en introduktion, FMV, KC Ledstöd

3 Utg. nr 1.2 Sida 3 (36) JAR 14910: /02, Publikationer: Handböcker: H ProgSäk Joint Aviation Requirements (Europeiska luftvärdighetskrav) [Laprie] Dependability: Basic Concepts and Terminology, ISBN [Leiner] A Comparison of Partitioning Operating Systems for Integrated Systems, B Leiner et al, SAFECOMP 2007, s [Meulen] Definitions for Hardware/Software Reliability Engineers, ISBN [PHA] Preliminary Hazard Analysis, IG Programvarusäkerhet: Teknik/Metodik: SESAM faktablad. [PHL] Preliminary Hazard List, IG Programvarusäkerhet: Teknik/Metodik: SESAM faktablad. PLC, PLD Programmable Logic Controller, Programmable Logic Device [PLC-Guide] [Rushby] Guidelines for the use of Programmable Logic Controllers in Safety-Related Systems, Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance, J Rushby, NASA/CR [SEMSPLC] Safety-Related Application Software for Programmable Logic Controllers, [SS-EN 954-1] Säkerhetsrelaterade delar av styrsystem, [SS-EN 954-1:1996]. [SSPP] Systemsäkerhetsplan inkl programvara, FMV, 2000, Publikationer: Handböcker: H ProgSäk 2001: Hjälpmedel och mallar. [SOUP] Software Reuse in Safety-Critical Applications, Summary Final Report [SwHz] Checklista programvaruriskkällor, FMV, 14910:12183/2006, : IG Programvarusäkerhet: Teknik/Metodik: SESAM faktablad.

4 Utg. nr 1.2 Sida 4 (36) 3. Begrepp Ett urval frågor, som rör olika system- och programvarusäkerhetsbegrepp, finns nedan. Fler termer förklaras bl a i [HProgSäk]: 6.1, [HSystSäk]: 4.1, [Intro]:2, [Laprie], [Meulen] Programvarusäkerhet, vad är det? Programvarusäkerhet är en tillämpning av de principer och den verksamhet, som fastlagts för systemsäkerhetsarbetet på systemets programvarubaserade delar. Olika procedurer, aktiviteter och metoder används, för att redan under arkitektur- och designstadium bygga in övergripande systemsäkerhetsegenskaper i system- och programvarudelar, för att senare under själva implementeringen detaljera dessa. En beskrivning av hur detta är avsett att genomföras ges i en s k systemsäkerhetsplan, [SSPP]. Hur systemsäkerhetsverksamheten tillämpas på programvara beror av de egenskaper en realisering i programvara medför, vilket inte enbart berör programvara som produkt*, utan också de parter, som är involverade i dess framtagning, drift och underhåll samt de processer dessa använder sig av. ( * ) Jfr 6.1.6, nedan (skillnader programvara-hårdvara) Programvarusäkerhet, betecknar det en egenskap eller en verksamhet? Både och: Programvarusäkerhet som egenskap (Software Safety)* innebär, att programvaran i ett säkerhetskritiskt system är konstruerad för att möjliggöra, att den övergripande systemsäkerheten kan upprätthållas under systemets hela driftstid. Detta betyder att ingående programvara ej skall kunna bidra till att person, egendom eller miljö oavsiktligt hotas av det säkerhetskritiska systemet, givet att det används på föreskrivet sätt. Detta fordrar en medveten design tillämpad på arkitekturen från översta nivå i en systemhierarki ned till enskilda system och programkomponenter. Konstruktionsarbetet grundas därvid på en säkerhetsfilosofi sett över hela systemet. Programvarusäkerhet som disciplin (Software System Safety)* avser all den verksamhet som bedrivs för att säkerställa att programvaran i ett säkerhetskritiskt system utrustas med egenskaper som stödjer systemsäkerheten**. ( * ) I engelskan görs en distinktion mellan de egenskaper som befrämjar programvarusäkerhet och den verksamhet, som skall leda till detta. ( ** ) Se nedan under avsnitt 5 samt [HProgSäk]: 4.3.3, och [Intro]: Är det verkligen relevant att tala om Programvarusäkerhet? Systemsäkerheten kan väl inte hotas av programvara: den består ju i slutänden bara av 1:or och 0:or! Rent generellt gäller, att egenskaperna hos en programvaruprodukt inte kan utvärderas med programvaran isolerad från sitt sammanhang. En slutgiltig bedömning av dess egenskaper eller beteende fordrar kunskap om det system där programvaran är tänkt att ingå, den avsedda systemomgivningen samt systemets användningsprofil. Detta innebär, att programvara betraktad som säker i ett visst sammanhang, inte nödvändigtvis behöver vara det i ett annat.

5 Utg. nr 1.2 Sida 5 (36) Analys av olycksscenarier, där programvara varit inkorporerad i det säkerhetskritiska systemet, har visat, att denna mer eller mindre direkt kan bidra till förluster eller svåra skador på person, egendom och miljö*. Främst har detta gällt automatiserade styrsystem, olika typer av skydds- och övervakningssystem samt i vissa fall databaser med säkerhetskritisk information. ( * ) T ex Osprey, se [Intro]: Kan en enskild programvarukomponent vara (system)säker? Nej, en slutgiltig utvärdering av säkerheten hos en programvaruprodukt kan endast göras med programvaran som integrerad del av systemet i sin avsedda användningssituation (se ovan). Se t ex fallet med de extra säkerhetssystemen som installerades i den automatväxlade polisbilen eller det självdestruktiva torpedvapensystemet, {Intro]: På vilket vis har programvarukvalitet betydelse för systemsäkerheten? Är inte programvarusäkerhet en ingrediens i programvarukvaliteten? Programvarukvaliteten är en förutsättning för att uppnå system- o programvarusäkerhet och en bas på vilken dessa egenskaper vilar, [Intro]:3. Programvarusäkerhet är inte en delegenskap inom programvarukvaliteten: en programvaruprodukt av hög kvalitet kan i vissa sammanhang vara osäker och en säker produkt kan i vissa avseenden vara av dålig kvalitet. Programvarukvalitet hänger ihop med hur pass väl programvaran är utvecklad m a p olika egenskaper (t ex underhållbarhet, användarvänlighet, verifierbarhet) samt hur pass väl den uppfyller de specificerade funktionella kraven (graden av tillförlitlighet), [HProgSäk]: 5. Många kvalitetsprinciper är tillförlitlighetsinriktade och i första hand inriktade mot att i ett tidigt skede (redan under konstruktionsfasen) identifiera och eliminera felkällor. Genom att bygga in feltolerans ger man systemet möjlighet att även kunna ta sig ur ett feltillstånd som följd av att exekveringen råkat aktivera en felkälla (en i koden tidigare opåträffad felkälla eller oförutsedda indata). I detta fall gäller det att lägga in alternativa exekveringsvägar även för feltillstånd, som inte anses kunna inträffa i aktuellt system i dess avsedda användning och omgivning (jfr Ariane 5, se [Intro]: 12.2, ) Vad betyder Systemsäkerhet (Safety)? Systemsäkerhet är egenskapen hos ett system, att under föreskrivna villkor och i avsedd omgivning ej oavsiktligt orsaka skada på person, egendom eller miljö. Denna egenskap gäller från den översta nivån i en systemhierarki På vilket vis skiljer sig Systemsäkerhet från IT- säkerhet (Security)? Systemsäkerhet avser egenskapen hos ett system att inte orsaka skada på person, egendom eller miljö. Säkerhetshotet utgörs m a o av systemet självt, [HProgSäk]: IT-säkerhet är egenskapen hos ett system att kunna motstå intrång, otillbörlig insyn, förlust eller påverkan. I detta fall ligger hotet utanför systemet och är riktat mot detta, [Intro]:2.

6 Utg. nr 1.2 Sida 6 (36) 3.8. Ett säkerhetskritiskt system, vad är det? Med detta avses ett system, som på något sätt kan hota systemsäkerheten. Här är det alltså frågan om att systemet självt kan leda till att person, egendom eller miljö skadas Vilken programvara kan betraktas som säkerhetskritisk? Dit hör bl a programvara, som kan bidra till att en vådahändelse inträffar, eller vars uppgift är att förhindra detta. Typiska exempel är programvara för styrning, övervakning, skydd samt kommunikation m a p säkerhetskritisk aktivitet, utrustning eller information, [SwHZ] Vad kännetecknar ett realtidssystem? För realtidssystem gäller, att från någon typ av inmatning/information given eller hämtad från en verklig omgivning kunna leverera korrekt resultat/funktionalitet inom specificerad tid (deadline). Man brukar skilja på hård, mjuk och fast (firm) realtid. Hård realtid innebär, att resultat måste ges inom specificerad tid, för att undvika katastrofala konsekvenser. Vid mjuk realtid är ett resultat inom föreskriven tid betydelsefull, men inte kritisk för systemets fortsatta operation. Fast realtid betyder, att ett svar som ges efter specificerad tid är meningslös och därför ej önskvärt Är inte Systemsäkerhet samma sak som Tillförlitlighet eller möjligtvis en del av Tillförlitligheten? Om inte, vad skiljer? Tillförlitlighet är inriktad på vad systemet skall göra, medan systemsäkerhet fokuserar på vad systemet inte får göra. Ett system kan därför vara tillförlitligt utan därför vara säkert. Motsatsen kan också gälla. Tillförlitlighetsteknikerna tillämpas redan under konstruktion för att finna och eliminera defekter i programvaran, som kan sprida sig vidare i systemet. Tillförlitlighet byggs också in i systemet (feltolerans) genom att ge det förmåga att under exekvering identifiera och bryta ett felaktigt händelseförlopp: det från en felkälla över till ett feltillstånd inom en komponent och slutligen till en felyttring på systemnivå. Systemsäkerhet strävar mot att bryta händelsekedjan från riskkälla till osäkert tillstånd (risktillstånd) och vidare mot olycka. Även här tillämpas olika analysmetoder redan på systemet i dess konceptuella fas för att se vilka riskkällor som kan undvikas samt senare under konstruktion, för att finna var denna kan behöva ändras för att få bort kvarstående säkerhetsrisker eller få ned dem till tolerabel nivå. Speciella tekniker används även, för att ett system som trots detta hamnar i osäkert tillstånd, skall kunna ta sig därifrån (m h a redundans, degenererad funktionalitet etc), [HProgSäk]: 6.1.3, [Intro]: Hur förhåller sig driftsäkerhet till system- o programvarusäkerhet? Driftsäkerhet handlar om förmågan hos en enhet, att vid en angiven tidpunkt / tidsintervall samt under givna förhållanden kunna utföra krävd funktion under förutsättning, att externa

7 Utg. nr 1.2 Sida 7 (36) resurser / stödfunktioner finns tillgängliga. Detta är ett sammansatt begrepp (med krav både på produkt o underhållsorganisation), som inbegriper tillgänglighet (i funktionsdugligt tillstånd under givna förhållande o vid given tidpunkt), funktionssäkerhet (att inte vara otillgänglig eller gå sönder när efterfrågad), underhållsmässighet (möjlig att i tid kunna vidmakthållas / återställas i tillfredsställande skick) samt underhållssäkerhet (tillfredsställande underhållskapacitet hos en uh-organisation). Driftsäkerhet utvecklades som disciplin i en tid då datoriseringen ännu inte tagit fart, för att hålla mekaniserade system i operativt skick. Därmed kom vissa egenskaper nödvändiga i de allt mer automatiserade system som byggs idag ej att beaktas: egenskaper, vilka inte går att fixa i efterhand m h a underhållspersonal o ett välsorterat reservdelslager, utan måste byggas in i enheten/produkten redan från början. Dit hör bl a programvarusäkerhet samt IT-säkerhet. Det klassiska driftsäkerhetsbegreppet omfattar m a o ej system- o programvarusäkerhet. Däremot finns ett paraplybegrepp, pålitlighet (dependability), vilken inkluderar samtliga ovanstående begrepp. Jfr bild i [Intro]: 9 samt [HDriftSäk]. Se även ILS under Vad är risk? Ett 10-tal olika riskdefinitioner kan återfinnas i litteraturen. I vardagligt språk används termen risk, för att uttrycka det troliga att någon typ av skada kan bli följden (t ex risk för halka). I systemsäkerhetssammanhang omfattar begreppet vanligtvis rimligheten / sannolikheten att en olycka inträffar samt dess värsta möjliga konsekvens. Ytterligare faktorer kan påverka olycksrisken. En indirekt faktor är t ex systemets komplexitetsgrad, en mer explicit den riskkälleexponering person, egendom eller miljö kan utsättas för. I fall där riskkälleexponeringen utgör ett väsentligt systemsäkerhetshot inkluderas denna i riskbegreppet, vilket därmed kan betraktas som 3-dimensionellt. Se vidare [HProgSäk]: 6.1.4, [Intro]: Vad är kritikalitet? Kritikalitet är ett relativt mått på i vilken grad något i systemet (funktion/systemdel/krav etc) kan bidra till olycka. Ett 60-tal olika klassningar kan återfinnas i den säkerhetsinriktade standardfloran, vanligtvis i termer av prioritet, angelägenhetsgrad, riskindex eller safety integrity. Ofta är kritikalitet relaterad till risk i 1 eller 2 dimensioner. Riskparametrarna diskretiseras och de olika parameterkombinationerna ger upphov till olika kritikalitetsnivåer. [HProgSäk]: 1.7,

8 Utg. nr 1.2 Sida 8 (36) 4. Personal 4.1. Vad kan projektledare och medarbetare göra för att säkerställa företagets kompetens inom Programvarusäkerhet? I första hand gäller att stärka kompetensen inom programvarusäkerhetsområdet hos de, som är involverade i anskaffning, framtagning och användning av säkerhetskritiska system. Grundläggande kunskap inom applikationsområde, systemteori och systemsäkerhet är väsentlig (om än i olika grad beroende på roll), och en kompletterande utbildning kan därför bli nödvändig. Genom ett aktivt engagemang inom nationella/internationella systemsäkerhetsorganisationer fördjupas kunskaperna och kontaktnätet vidgas. En god träning inför projektarbete inom integrerade grupper (ITP) är deltagande i studiegrupper och diskussionsfora, där olika parter och kompetensområden finns representerade (det är företrädesvis inom ITPer, som den övergripande systemhierarkin och arkitekturen fastläggs och de systemgemensamma säkerhetshoten identifieras. Här gäller även att bestämma på vilken nivå och av vilka systemleverantörer dessa hot skall bemötas). Under projektets gång behövs också fortlöpande förmedling av vilka grundläggande och säkerhetsinriktade konstruktionsprinciper samt designmässiga och operationella restriktioner, som bedömts nödvändiga för säker drift av aktuellt system. Parternas systemsäkerhetsingenjörer behöver tillräcklig kunskap i programvaruteknik för att inse implikationerna av en övergång till mer programvaruinriktade systemrealiseringar. Leverantörens programvarutekniker kan behöva kompletterande utbildning i system- och programvarusäkerhet både m a p processer och produktegenskaper för att veta hur olika analysmetoder kan användas för identifiering av säkerhetshot, vilka säkerhetsegenskaper, som behöver byggas in för att systemet skall kunna bemöta dessa hot samt vilka ytterligare säkerhetsrestriktioner som behöver åläggas systemet och dess handhavande. Beställaren kan behöva en kunskapsbreddning både inom programvaruteknik och programvarusäkerhet, för att kunna specificera säkerhetskrav på rätt detaljeringsnivå ([HProgSäk]: 3.4.4) samt bedöma att dessa sedan uppfylls. Dock gäller, att överlåta åt leverantör att avgöra vilka programvarutekniska lösningar och återanvändbara programvaruprodukter som skall väljas, för att systemet skall kunna uppfylla sina åtaganden. För slutkunden är det väsentligt, att försäkra sig om, att de parter, som medverkar vid anskaffning, utveckling och drift av säkerhetskritiska programvarusystem har rätt kompetens. Av extra vikt är, att kundens systemanvändare/operatörer/driftspersonal känner till vilka säkerhetsrestriktioner som gäller vid drift av systemet. [HProgSäk]: 2.1, 3.1, 3.4.1, Varför skall en kund/beställare satsa på området Programvarusäkerhet? För intressenter, som i sin verksamhet behöver använda sig av datoriserade system, som skall operera i verklig tid och miljö, är det väsentligt att försäkra sig om att dessa system inte oavsiktligt kan skada person, egendom eller miljö. Risk för att detta skall kunna inträffa gäller speciellt s k realtidssystem och i synnerhet sådana som styr och/eller övervakar någon typ av

9 Utg. nr 1.2 Sida 9 (36) säkerhetskritisk utrustning eller aktivitet. Sådan risk kan även föreligga för s k informationssystem, där inaktuell eller felaktig information kan leda till beslut av system/operatör att vidta åtgärder, som sätter igång ett olycksförlopp. Typiska exempel är transportsystem med informationsöverföring (via datalänk, mobilnät etc) mellan ledningscentral samt pilot, operatör eller styrsystem. Ett annat exempel är NBF (det nätverksbaserade försvaret), där gemensam information av olika detaljeringsgrad görs åtkomlig på nätet för behöriga och där sensordata, beslutsstöd etc ligger till grund för olika insatser. Att satsa på Programvarusäkerhet syftar ju till att säkerställa, att programvaran i ett säkerhetskritiskt system utrustas med egenskaper, som stödjer systemsäkerheten sett från ett övergripande systemperspektiv. Dessa egenskaper måste byggas in från början, för att möjliggöra att systemsäkerheten kan upprätthållas under systemets hela drifttid (givet att systemet används på föreskrivet sätt). Konsekvenserna av att inte satsa på system- o programvarusäkerhet kan bli förödande inte enbart för person, egendom eller miljö utan även för de som är involverade i framtagning av säkerhetskritiska system, dvs kund/slutanvändare, beställare samt systemleverantör.

10 Utg. nr 1.2 Sida 10 (36) 5. Processer 5.1. Programvarusäkerhet som disciplin är inte det att tillämpa systemsäkerhetsverksamhet på programvara? Visst! Principiellt skiljer inte den säkerhetsverksamheten som programvara behöver genomgå från den som tillämpas på systemdelar realiserade i annan teknik. Programvarans inneboende egenskaper gör dock, att andra åtgärder behöver vidtas, för att försäkra sig om, att ett tillräckligt säkert totalsystem kan åstadkommas. Detta gäller inte minst aktiviteter som rör felhantering, felpredikteringar och underhåll samt olika åtgärder för att bygga in säkerhet i programvaruprodukterna (se [HProgSäk]: samt svar nedan under 6) Vad är syftet med en programvarusäkerhetsverksamhet? Programvarusäkerhet som disciplin syftar till att säkerställa att programvaran i ett säkerhetskritiskt system förses med egenskaper som stödjer systemsäkerheten*. Detta betyder, att de parter, som är involverade i utveckling, underhåll och drift av ett säkerhetskritiskt programvarusystem m h a säkerhetsinriktade processer skall bidra till, att den övergripande systemsäkerheten kan byggas in och upprätthållas under systemets hela livstid såväl i arkitektur och design av systemets programvaruprodukter som genom dokumentation och utbildning för de olika parterna. ( * ) Se vidare [HProgSäk]: 4.3.3, 6.1.1, [Intro]: Vilka tekniker skall man använda för att uppnå Programvarusäkerhet? Programvarusäkerhet baseras på tre teknikområden: i) Programvaruteknik, vilken är själva ramverket för all programvaruutveckling* (i sig ett omfattande område, som ställer krav på personal, processer och produkter), ii) Tillförlitlighetsteori, vilken är inriktad mot att identifiera och eliminera fel samt visa, att specificerad funktionalitet är uppfylld, iii) Systemsäkerhetsmetodik, vilken i stället fokuserar på att analysera, identifiera samt förhindra icke önskvärd funktionalitet (säkerhetshot snarare än fel i största allmänhet). Programvarusäkerhet kan därigenom ses som en integrering av dessa tre teknikområden**. ( * ) Se [HProgSäk]: 4.2, 4.3, 5.2.2, ( ** ) Se [HProgSäk]: 4.3.3, 6.1.1, 6.1.2, [Intro]: Vilka systemsäkerhetsanalysmetoder är speciellt lämpade för programvarusystem vid olika skeden i systemutvecklingen? På vilket vis kan dessa bidra till att identifiera de olika typer av riskkällor, som kan föreligga i ett system? Svar på dessa frågor finns redovisat under IG Programvarusäkerhet: Utbildning och kurser: Självstudiematerial: Systemsäkerhetsanalysmetoder. Ett antal faktablad som beskriver olika metoder finns under : IG Programvarusäkerhet: Teknik/Metodik: SESAM faktablad. Här återfinns även en unik checklista över programvarans allmänna riskkällor, [SwHz].

11 Utg. nr 1.2 Sida 11 (36) 5.5. Vilka systemsäkerhetsanalysmetoder är mest effektiva då det gäller att finna blottor i systemsäkerheten hos kommunikationssystem samt system baserade på bl a PLC och COTS? Detta beror till stor del på vilken typ av riskkällor, som kan vara aktuella för den applikation, som skall analyseras. Vissa metoder är inriktade mot riskkällor i komponenter (FMEA, FMECA), andra fokuserar händelsekedjor mellan riskkälla och olycka (FTA, CCA, SMHA, ETA etc), ytterligare några koncentrerar sig på gränssnitt (HAZOP, CHAZOP, FFA, SDA). En av de nyare metoderna (STAMP/STPA) analyserar olika typer av styrflöden mellan skilda objekt/ komponenter/ system: styr- o återmatningsloopar både på programvarunivå (i form av reglerloopar) samt på organisatorisk nivå (med styrning via reglementen, ordergivning samt återmatning genom bekräftelser/ acknowledgements). En vital del i kommunikationssystem är dess gränssnitt, vilka kan dölja vissa typer av riskkällor. HAZOP o STAMP/STPA blir där ett naturligt val när det gäller analysmetoder. Se vidare IG Programvarusäkerhet: Utbildning och kurser: Självstudiematerial: Systemsäkerhetsanalysmetoder för resultat från en studie över analysmetoder lämpade för programvarusystem. Faktablad över olika metoder finns under IG Programvarusäkerhet: Teknik/Metodik: SESAM faktablad. Där finns även en unik checklista över programvarans allmänna riskkällor [SwHz]. PLC är en robust, logiskt programmerbar processor med ett utbyggbart antal in- o utgångar, vilka lätt kan anslutas till givare o styrdon. Detta gör den speciellt lämpad för styrning, reglering o övervakning av maskinutrustning i realtid. Denna applikationsinriktning tyder på att det angreppssätt som tillämpas av HAZOP skulle kunna vara användbart åtminstone beträffande dess ledord för att finna riskkällor, men tekniken som sådan fordrar lednings- o kopplingsdiagram. Bättre kandidat i synnerhet för PC-baserade (dvs mjukvaru-realiserade) PLCer är då STAMP/STPA, som fokuserar brister hos interaktionsslingor. Bland de traditionella hårdvaru-baserade PLCerna finns säkerhetsinriktade varianter, vilka bl a levereras med certifierade funktionsblock. Trots detta och trots säkerhetsinriktade specialspråk går det att bygga tillämpningar behäftade med systemsäkerhetsbrister. Även om det finns en mängd standarder i maskinsäkerhet, t ex [SS-EN 954-1], och ett antal säkerhetsinriktade PLC-guider, t ex [SEMSPLC] o [PLC-Guide], verkar dessa ej gå in på vilka metoder som kan vara bäst lämpade för säkerhetsanalys. För mer info om PLCer och standarden för PLC-språk, IEC (sedan 2006 även med systemsäkerhetsaspekter), se TC5-Safety under den produkt- o tillverkaroberoende hemsidan När det gäller säkerhetsanalyser på system med COTS i dess säkerhetskritiska delar, måste analyserna utföras med COTS-produkterna som del av systemet. Valet av analysmetoder styrs därmed av systemets applikationsinriktning. Observera dock, att det för en COTS-produkt dessutom gäller bl a, att avskärma överflödig funktionalitet samt utföra speciella integrationstest, se [HProgSäk]: samt frågor nedan under Vilka programvarusäkerhetsaspekter är relevanta i samband med ILS? Integrerat logistikstöd är en systematisk o integrerad styrning av driftsäkerhets- o underhållsverksamheten för ett system* eller en produkt under hela dess livscykel. Syftet är

12 Utg. nr 1.2 Sida 12 (36) att optimera den totala livscykelkostnaden samtidigt som kvalitet eftersträvas genom krav på tillförlitlighet, tillgänglighet, underhållsmässighet samt testbarhet (jfr 3.12 ovan ). Till detta bör fogas krav på systemsäkerhet (vilka ursprungligen saknats i det klassiska ILS-begreppet). ( * ) Med system avses här all hård- o mjukvara, personal, processer, verktyg o andra resurser. En tämligen heltäckande sammanställning över olika programvarusäkerhetsaspekter finns i [HProgSäk]. Samtliga dessa är i olika grad relevanta. Följande punkter är ett starkt koncentrat av de för ILS-verksamheten mest väsentliga: [SSPP], den systemsäkerhetsplan, som tas fram för systemet och styr dess systemsäkerhetsverksamhet, skall inkludera även programvarubitarna. Upprättade planer skall säkra att involverade personer har hög kompetens inom främst applikationsområde, systemteori, system- o programvarusäkerhet samt programvaruteknik (se svar under 4 ovan). Använda programvaruprocesser för styrning, stöd och produktion av systemen skall vara väl integrerade med systemsäkerhetsmetodiken (se 5.3 ovan). Systemsäkerhetsmetodiken skall anpassas till de egenskaper som en programvarurealisering uppvisar (se nedan). Arkitektur o design skall inriktas mot system- o programvarusäkerhet: en proaktiv satsning, som möjliggör minimerade livscykelkostnader (en av ILS målsättningar). Se svar under resp I ett system med säkerhetskritisk programvara hur upptäcks fel och hur tas dessa om hand? Felupptäckt: Identifiering av defekter i en programvaruprodukt utförs under hela dess livscykel. Huruvida dessa defekter är att betrakta som logiska misstag eller beror på felaktig användning* påverkar givetvis, vilka åtgärder som är relevanta efter en felidentifiering. Felidentifiering före driftsättning är av proaktiv karaktär: Före/under designfasen analyseras systemet för att finna vilka risker, som behöver byggas bort eller reduceras till tolerabel nivå, [HProgSäk]: 4.3.3, , 6.8. Systemet designas även för att under drift själv kunna upptäcka och hantera olika feltillstånd/ felsituationer (t ex genom att växla över till en alternativ exekveringsgren). En robust design eftersträvas kapabel att hantera felaktig input, oväntad respons från omgivningen etc, [HProgSäk]: Aktuell teknik här är bl a defensiv programmering, felhantering, felåterhämtning, feltolerans, diversifiering, säkra degraderingsmod, språkval, [HProgSäk]: , , 6.7. Systemets möjligheter till självkorrigering är dock begränsade till de felsituationer, vilka konstruktören haft förmåga att förutse. Utöver detta byggs speciella test för användning av drifts- o underhållspersonal, [HProgSäk]: (BIT). Under realiseringsfasen använder programmeraren ytterligare analys- o verifieringstekniker för att upptäcka o eliminera renodlade fel, [HProgSäk]: 4.2.2, , ( * ) T ex om de förutsättningar programvaran bygger på ej är uppfyllda i aktuell omgivning/ användning (jfr fråga nedan). Felbehandling: Vilka åtgärder, som vidtas efter felidentifiering (och när) har berörts ovan (programmerarens omkonstruktion, systemets felåterhämtning, operatörsåtgärder etc ).

13 Utg. nr 1.2 Sida 13 (36) Andra, mer administrativa aktiviteter är, t ex riskkälleloggning, felrapportering samt CCBbeslut under systembygge, loggning av fel o operatörsåtgärder efter driftsättning samt av incidenter efter avslutad drift ([HProgSäk]: 2.4.1, , , [HSystSäk]: 3.15). Slutsats: För ett driftsatt system som inträtt i ett fel- eller risktillstånd är möjligheten, att kunna övergå till säkert tillstånd starkt kopplad till en säkerhetsinriktad arkitektur. [HProgSäk]: , Vilka säkerhetskrav skall man ställa på säkerhetskritisk programvara? De krav som är specifika för en viss applikation härleds genom olika systemsäkerhetsanalyser på programvaran som integrerad del av systemet i dess avsedda omgivning och användning. Därtill kommer de krav, som generellt kan ställas på programvara i säkerhetskritiska system*. Eftersom dessa finns i flera varianter (beroende på kritikaliteten hos aktuell programvarudel), måste ett urval göras av de, som är relevanta för aktuellt system. Väsentligt är, att dokumentera motiveringar till varför vissa krav uteslutits (underlättar omprövning vid framtida förändringar). ( * ) Se [HProgSäk] Hur skall den satta risktoleransen på systemets toppnivå mappas på programvarunivå? Den högsta tolererade risk som fastlagts på systemets toppnivå* fördelas ut på övergripande systemfunktioner / (del)system samt vidare ned i underliggande system och komponenter. Därmed kommer krav beträffande högsta tolererade riskbidrag från motsvarande programvarudelar att kunna specificeras. ( * ) Jfr [HSystSäk]: , [HProgSäk]: 6.1.5, fotnot 291, [Intro]: Hur hantera krav på felsannolikheter i storleksordningen 10-5 eller t o m ned mot 10-9 per drifttimme (eller antal driftstillfällen etc) för en viss programvarudel? För programvara går det rent generellt inte att få fram så låga skattningar. Andra tekniker måste tillgripas, för att tackla programvarukrav av denna storleksordning. Gäller kravet t ex positionsbestämning, kan ett sätt vara, att införa diversitet (flera oberoende sätt/tekniker att få fram begärt resultat alla inte nödvändigtvis realiserade i programvara). Krav på tillförlitligt resultat med dessa felmarginaler kan då kvarstå, samtidigt som kravet på den enskilda, programvarubaserade realiseringen kan tas ned till en nivå, där statistiska estimeringar är genomförbara. Mer om detta under nedan Hur bestämmer man programvarans kritikalitet? Enbart de delar av programvaran, som kan påverka en kritisk systemdel/-aktivitet behöver kritikalitetsbestämmas. Denna kritikalitet kan ej bedömas för programvara isolerad från sitt sammanhang. Kritikaliteten sätts i förhållande till programvarudelens värsta effekt i avsett system, systemomgivning och användning. Se vidare [HProgSäk]: 6.1.5,

14 Utg. nr 1.2 Sida 14 (36) Om en anpassning av H ProgSäk redan gjorts i ett tidigare projekt, kan jag använda detta i mitt nästa projekt? Nej, varje anpassning med sitt urval av generella säkerhetskrav och tillägg av de systemspecifika är unik för aktuellt system och går inte att använda rakt av för ett annat. Skillnaderna måste analyseras. Tidigare motiveringar till uteslutning av vissa generella säkerhetskrav måste omprövas i ljuset av förändrade förutsättningar, [HProgSäk]: 1.9, 6.4.2, [Intro]: När kan det vara svårt att anpassa H ProgSäk? Då vissa förutsättningar inte är uppfyllda, t ex vid Oklarheter beträffande högsta systemnivå i ett system-av-system. Icke fastlagd risktolerans för systemet på högsta nivå*. Avsaknad av en säkerhetsinriktad systemarkitektur från översta nivå och ned**. Återanvända delsystem baserade på COTS, som inte uppfyller krav för kritiska delar*** Otillräcklig insikt i programvaruteknik och realtidssystem****. ( * ) Risktoleransen på översta nivån ligger till grund för vilken risk som maximalt kan tillåtas för systemdelar på underliggande nivåer. En fastlagd risktolerans är nödvändig för att kunna fördela en riskbudget på dessa, [Intro]: 5. ( ** ) För identifierade systemsäkerhetshot gäller att bestämma: på vilken nivå i systemhierarkin och av vilka system skall ett specifikt hot bemötas? En berättigad frågeställning med tanke på att oupptäckta systemsäkerhetsproblem ofta döljer sig i gränssnitten mellan olika system. ( *** ) Exempel på restriktioner ges nedan under 6.2. ( **** ) En nödvändig grund för att kunna ställa rätt systemsäkerhetskrav på programvara och värdera effekterna av dessa, [HProgSäk]: 6.5, Finns sätt att underlätta återanvändning av ett säkerhetskritiskt delsystem i annat system? Bortsett från mer allmänna principer om design för återanvändning, kan det vid framtagning av ett nytt delsystem vara möjligt med en stegvis härledning av dess systemspecifika säkerhetskrav. Säkerhetsanalyserna inriktas då först mot att ta fram de domängemensamma säkerhetskraven (säkerhetskrav för delsystemet oberoende av i vilken systemtyp det skall ingå). Ett tillägg görs därefter av de domänspecifika säkerhetskraven (tillkommande säkerhetskrav dikterat av till vilken applikationsdomän delsystem skall integreras, t ex flygsystem). Slutligen görs analyser för att fastlägga de systemspecifika säkerhetskraven (tillkommande krav på delsystemet unika för aktuell systemapplikation, tex visst flygsystem). Säkerhetskraven i det sista steget beror av delsystemets roll i avsett system/applikation samt systemets omgivning och användning, [HProgSäk]: 1.6. Detta förfaringssätt kan vara av värde t ex för leverantör, där en viss typ av delsystem utgör en del av företagsprofilen. För att härleda aktuella säkerhetskrav på ett sådant delsystem i ett nytt system inom samma applikationsdomän, kan det då räcka att backa 1 steg i den tidigare utförda analysen. Vid återanvändning till ett helt annat tillämpningsområde backas i stället 2 steg. Går inte detta, är alternativet, att se över alla tidigare säkerhetsanalyser från början. Se 6.2 nedan.

15 Utg. nr 1.2 Sida 15 (36) Vilka överväganden är väsentliga inför anskaffning av delsystem till ett nytt säkerhetkritiskt system? Några frågor som bör utredas är: Kan något av delsystemen vara aktuellt att använda i ett annat system? Om ja: överväg stegvis härledning av de systemspecifika säkerhetskraven*. Är dessa system av olika kritikalitet? Om ja: utveckla delsystemet till att uppfylla de säkerhetskrav, som är förknippade med den högsta kritikaliteten hos de tilltänkta systemen. Vilka degraderingsmoder kan vara acceptabla för delsystemet i de olika systemen? Detta påverkar designen samt möjligheterna i drift att kunna lämna ett osäkert tillstånd till förmån för ett säkert om än degraderat tillstånd (för ett flygsystem: tillräcklig funktionalitet för säker flygning hem). En stående fråga för varje system är dessutom huruvida COTS eller egentillverkad programvara kan/skall användas (se nedan under 6.2). ( * ) Se föregående fråga Vilka projektgemensamma förberedelser kan en leverantör utföra, för att lättare kunna möta säkerhetskraven i framtida programvaruprojekt? Både marknadsmässiga och ekonomiska fördelar kan uppnås genom att i förväg: Inventera och komplettera personalens kompetens, befintliga regelverk, utvecklingsprocesser och programutvecklingsstöd (utvecklingsverktyg, -metodik) m a p programvarusäkerhet*. För visst delsystem: utför systemsäkerhetsanalyser, för att få fram domängemensamma säkerhetskrav (giltiga för delsystemet oberoende av applikationsområde) samt domänspecifika säkerhetskrav (giltiga för delsystemet i ett visst applikationsområde). Dessa blir en värdefull utgångspunkt i kommande projekt vid arbetet att ta fram delsystemets systemspecifika krav (se tidigare fråga i detta avsnitt). ( * ) [HProgSäk]: 6.4.2, mallar på Publikationer: Handböcker. H ProgSäk Hur bemöter man påståenden som: 1: Det spelar ingen roll vad mitt system gör, det är inte där riskerna finns. 2: a) Riskkällorna ligger utanför mitt programvarusystem alternativt: b) Det finns inga riskkällor i mitt system eller: c) Eftersom säkerhetsanalys alltid startar med PHL är det inte meningsfullt att analysera mitt system. 3: Systemsäkerhetsarbetet skall utgå från vad som händer om något går fel och inte orsaken till detta. Mitt program skall kunna göra vad som helst, det går ändå aldrig att få en felfri programvara. 4: Vi behöver inte någon lista över programvaruriskkällor eller HAZOPs ledord för att söka avvikelser i vår systemdel. Vi har redan enhetstestat 5: Vi skall alltså analysera allt?! Här är några argument:

16 Utg. nr 1.2 Sida 16 (36) 1) I de inledande systemsäkerhetsanalyserna på övergripande nivå har i stora drag de säkerhetskritiska delarna identifierats. Dessa analysresultat ligger till grund för mer detaljerade analyser hos leverantör samt dennes underleverantörer och genomförs så snart ingående delar fastställts. Det åligger (under)leverantör att visa, vilka riskkällor inom eget delsystem samt övriga säkerhetshot utanför detta, som kan vara aktuella, för att därefter se till att det egna systemet kan bemöta dessa och p s s få ned riskerna på tolerabel nivå. För att hävda att inga risker föreligger, gäller att göra troligt att inga riskkällor kunnat identifieras vid de systemsäkerhetsanalyser som genomförts samt att dessa analyser inte är bristfälligt utförda. Dokumentation och spårbarhet mellan riskkälla-olycksutfallmotsvarande systemåtgärder-vidimerande verifikationer är nödvändiga på samtliga dessa nivåer. 2 a-b) Se svar ovan. 2 c) Den preliminära riskkällelistan, [PHL], är ju resultat av den inledande riskkälleanalysen, [PHA], vilken efterföljs av mer detaljerade analyser allt eftersom systemets delar börjar ta form. Det är först då man genom dessa kunnat utesluta, att det egna systemet kan bli utsatt för systemsäkerhetshot utifrån eller inifrån systemet, som man kan avbryta vidare systemsäkerhetsanalyser. 3) Påståendet rymmer missförstånd beträffande olika begrepp: Systemsäkerhet är inriktat mot att undvika att systemet (genom olika händelser, riskkällor, yttre omständigheter etc) oavsiktligt kan orsaka skador på person egendom eller miljö. Denna typ av skador behöver inte nödvändigtvis bero på renodlade fel. Ofta kan de ha sin grund i oavsiktliga kombinationseffekter uppkomna i samband med att delsystem / komponenter (ibland från flera leverantörer) integrerats ihop till ett nytt system. Systemsäkerhet handlar om vad systemet ej får göra, tillförlitlighet vad system skall göra. Mer om Systemsäkerhet-Tillförlitlighet-Fel finns bl a under 3.11 ovan. Orsaker: Då fel av olika slag eller systemsäkerhetshot upptäcks för det system man håller på att bygga är det fundamentalt att ta reda på bakomliggande orsaker, för att kunna bygga bort eller på annat sätt gardera systemet mot dessa. Se ovan samt nedan. Vad som helst: Det väsentliga vid alla typer av säkerhetskritiska system är att man före samt under systembygge lyckas specificera och längre fram ytterligare precisera både vad system skall göra, samt vad det inte får göra. Säkerhetskritiska system skall inte kunna göra vad som helst eller något icke-avsett (det är bl a därför som överflödig funktionalitet, död kod etc måste rensas ut). Felfri programvara: En nollvision kan vara svår att uppnå / upprätthålla i synnerhet för stora, komplexa, programvaruintensiva system. Dock finns väletablerad metodik, som systematiskt tillämpad gör det möjligt att få fram system med tillfredsställande tillförlitlighet resp systemsäkerhet. Det är just detta Programvarusäkerhet handlar om. 4) Det räcker inte med tillförlitlighetsinriktade verifieringar på en isolerad komponent (vilket är fallet vid enhetstest). Systematiska verifieringar på olika nivåer behövs både m a p tillförlitlighet samt för säkerhetskritiska system m a p systemsäkerhet. Det gäller m a o att se till, att denna komponent i sitt avsedda sammanhang (som del av aktuellt system med dess användningsfall o systemomgivning) fungerar som avsett (är tillförlitlig) samt inte kan starta eller vidareförmedla en händelsekedja, som kan leda till olycka (systemsäker). Därför behöver systemsäkerhetsanalyser utföras på komponenten i sitt

17 Utg. nr 1.2 Sida 17 (36) avsedda sammanhang. Vid en inledande preliminär analys, kan man ha nytta av den ena av de checklistor som omnämns, [SwHZ], innan man övergår till andra analysmetoder för att finna de specifika riskkällorna för programvarukomponenten i aktuellt system. Den andra checklistan, [GuideWords], är en del av HAZOP-metodiken för att systematisera sökandet efter avvikelser. Ytterligare analysmetoder kan vara aktuella, t ex FMECA, FTA. Analysresultaten används sedan, för att bedöma var komponenten behöver konstrueras om eller vilka andra typer av kompletteringar, som är nödvändiga (t ex skydd) för att undvika fel och riskkällor. 5) Nej: Här gäller det att vara smart. Genom att definiera/studera aktuellt system, dess användningsprofil och systemomgivning samt de användningsfall och beroendekedjor som löper genom det egna delsystemet/komponenten, går det att begränsa analysernas omfattning. Resultat från säkerhetsanalyser m a p omgivande delar (eventuellt från andra leverantörer) är givetvis värdefull input (givet att de inte är bristfälligt utförda ). Analyserna kan begränsas ytterligare om en kritikalitetsinriktad partitionering gjorts av systemarkitekturen, vilken förhindrar delar av lägre eller ingen kritikalitet att inverka på de av högre kritikalitet. Se 6.2 samt Rekommendationen till den som ställs inför ovanstående typ av frågor är, att uppmana frågeställaren att genomgå en grundkurs i system- och programvarusäkerhet. Detta är av yttersta vikt för personer, som på något vis är involverade i framtagning, drift och underhåll av säkerhetskritiska system. Se avsnitt 4.

18 Utg. nr 1.2 Sida 18 (36) 6. Produkt 6.1. Programvaruspecifika egenskaper Vad består en programvaruprodukt av? All dokumentation i form av kravspecifikationer och andra produktbeskrivningar av programvaran i dess alla representationsformer (förutom kravspecar: design, implementation/kod, testsviter, feldatabaser från utvecklingen), beskrivningar av programvarusystemets design-, kodnings-, produktions- och driftsmiljö, installationshjälpmedel, resultat från olika typer av analyser: statisk-dynamisk/testsystemsäkerhetsinriktad, handledningar beträffande systemets användning- konfigureringdrift-underhåll, etc. För system, som skall kunna konfigureras av leverantör resp kund m h a olika systemparametrar är det väsentligt, att det i manualerna framgår om några kan påverka systemsäkerheten samt hur dessa får sättas Vilka delar av en programvaruprodukt behöver en (a) beställare inför slutleverans, (b) slutanvändare, (c) programmerare inför vidareutveckling och underhåll? Givetvis regleras i kontrakt vad som skall ingå i olika leveranser. Ansvars-, ägar- och nyttjandeförhållanden samt licenshantering är andra intrikata områden (som inte berörs här), dock behövs i stora drag följande delar: *a) Kravspecifikationer, beskrivningar över slutprodukt, driftsmiljö, analysresulat, handledningar. Speciellt viktigt för säkerhetskritiska system är att ev. kvarvarande riskkällor samt andra problem eller avvikelser m a p specificerade krav klart redovisas. *b) Handledningar för olika roller, utbildningsmaterial/-paket, exekverbart system. *c) Allt (inklusive användarsynpunkter från tidigare version, FRACAS etc) Programvarufel, vad utgörs dessa av? Fel är ett generiskt begrepp för felkälla (fault), feltillstånd (error) samt felyttring (failure). En allmän analys av de felyttringar, som programvaran kan orsaka på systemnivå, visar att programvarans felkällor kan spåras till defekter i själva programvaruprodukten (specifikation, design, implementation), i de processer eller verktyg som använts för att ta fram denna eller hos de personer som varit involverade i dess framtagning (återanvändning under förändrade förutsättningar, användningsområde/ handhavande i strid med specifikationer/instruktioner). Huruvida en programvaruprodukt levererar korrekt funktionalitet eller ej, kan ofta bero på i vilket sammanhang programvaran ingår. I stället för att karaktärisera en programvaruprodukt som rätt eller fel, kan det därför vara mer relevant att tala om graden av tillförlitlighet i olika sammanhang: Patriots misslyckade identifiering berodde på att användningsområde och handhavande det som specificerats. Se [HProgSäk]: 6.6.2, fotnot 317, [Intro]: 10, (Patriot) samt nedan.

19 Utg. nr 1.2 Sida 19 (36) Programvarusäkerheten måste väl ändå betraktas som uppfylld för en programvaruprodukt, som klarat alla sina tester? Att en programvarukomponent, som uppfyller alla sina funktionella krav, är tillförlitlig (givet använd på föreskrivet sätt) utesluter inte, att den i andra sammanhang kan uppvisa blottor m a p systemsäkerheten. En förändring av det system, den användningssituation eller den omgivning, där denna programvara är tänkt att ingå, kan leda exekveringen in på andra grenar och därmed resultera i ett annorlunda t o m säkerhetshotande beteende. Vad som behövs förutom designlösningar som befrämjar såväl testbarhet som feltolerans samt verifieringar under olika systemfaser är olika typer av systemsäkerhetsanalyser med programvaran i sitt avsedda sammanhang. Jfr fråga 3.11 (Systemsäkerhet-Tillförlitlighet) Varför kan en programvarurealisering inte betraktas som vilken komponent som helst? Se efterföljande frågor Vad skiljer en programvarukomponent från en hårdvaru-dito? Några av de egenskaper som skiljer programvara från hårdvara är: Systematiska fel (logiska missstag) snarare än slumpmässiga fel. Avrundningsfel, trunkeringar, icke-konvergenta approximationer etc kan (p g a olämpliga beräkningsmetoder) efter viss driftstid ackumuleras och ge oacceptabla resultat. Begrepp finns, som ej är applicerbara på programvara: feluppkomst (ev logiska brister finns redan från början), felintensitet (antalet felyttringar/tidsenhet: felyttringarna uppstår ej p g a slitage eller ålder). Åldrings- eller degenereringsfenomen uppstår inte vid systematiska fel (vilka är typiska för programvara) utan snarare vid slumpässiga fel. Dock skulle man kunna betrakta vissa numeriska brister i programvarurealiseringen som ett utslag av åldrande (t ex olämplig avrundningsteknik eller användning av icke-konvergenta approximationer), vilka i synnerhet för system i kontinuerlig drift med tiden ackumuleras och leder till helt missvisande resultat. Relativ tillförlitlighet (graden av tillförlitlighet) är ofta en mer relevant benämning än rätt / fel, som många gånger är alltför absolut (se föregående fråga och svar) Programvarufel drabbar alla instanser av programvaran (hårdvarans slumpmässiga fel drabbar enbart en enstaka komponent). Skattningar av programvarans felfrekvenser går inte att få fram före driftsättning vid krav på felsannolikheter under 10-4 per timme (eller annan fastlagd enhet). Högre abstraktionsnivån (abstrakt gränssnitt, som kan vara ofullständigt och som inte förhindrar att en modul kan integreras in i ett likartat system, trots avvikande förutsättningar). Uppvisade egenskaper styrs av det sammanhang i vilket programvaran infogas och används (system, systemomgivning, användningsprofil). Diskontinuerligt beteende (små förändringar i förutsättningarna kan leda till ett radikalt annorlunda beteende).

20 Utg. nr 1.2 Sida 20 (36) Säkerhetshot direkt initierade av programvaran kan härröra från programvaruprodukten (specifikations-/design-/implementationsfel), dess produktionsprocesser, produktionsverktyg eller personalens handhavande (t ex för leverantör: kod återanvänd under förändrade förutsättningar, slutanvändare: drift utanför avsett användningsområde, handhavande i strid mot specifikationer och instruktioner). Dolda säkerhetshot i systemets gränssnitt kan oavsiktligt aktiveras vid programvarans interaktion med övriga komponenter (programvara, maskinvara, operatörer), trots att varje enskild komponent uppvisat säkert beteende. Flexibilitet (realiseringsteknik med stora möjligheter att foga samman helt skilda egenskaper samt förmåga att uttrycka komplexa samband). Fysiska begränsningar ej en naturlig ingrediens i realiseringen (måste byggas in i logiken). Masskopiering ger identiska kopior (dvs inga variationer). Redundans i form av identiska kopior ej en gardering mot programvarans systematiska fel. Underhåll innebär konstruktionsändringar (snarare än utbyte mot en identisk, felfri reservdel). Möjlighet till underhåll beror av de produktionsprocesser som använts vid tillverkningen samt de egenskaper som byggts in i programvaran (t ex modularisering, information hiding, välspecificerade gränssnitt). Lättare att göra konstruktionsändringar (dvs underhåll), svårare att testa. Rättelser som består i, att en ny COTS-version plockas in, kan tvinga fram behov av annan uppgradering (t ex mot ett nyare OS). Minnesläckage. Rätten att bruka programvara styrs av komplicerade juridiska förhållanden (nyttjanderätt, äganderätt, licenser etc). Se vidare [HProgSäk]: 6.6.2, [Intro]: På vilket vis påverkar de programvaruspecifika egenskaperna de sätt varmed programvarusäkerheten kan tillgodoses? Komplexa samband i form av ostrukturerade eller vittförgrenade beroendekedjor och informationsflöden genom systemet skapar starka kopplingar och påverkan mellan olika delar. Detta försvårar möjligheten att separera delar av olika kritikalitet, vilket fördyrar och komplicerar såväl utveckling som underhåll. En realisering där delar av högre kritikalitet inte kan isoleras från de av lägre eller ingen kritikalitet är i sin helhet kritisk av dess högsta grad. Programvarans konstruktion måste grundas på en säkerhetsfilosofi för hela system i avsedd användningssituation. Programvara betraktad som säker i ett visst sammanhang behöver inte vara det i ett annat. Återanvändning av programvara som inte designats för återanvändning är vansklig och fordrar speciella säkerhetskontroller och åtgärder. Detta gäller även vid återanvändning i mycket närbesläktade system eller i oförändrat system med annan driftbild. En slutgiltig bedömning av programvarans egenskaper måste baseras på programvaran som integrerad del av systemet i den omgivning och den användning detta är avsett för. Riskreducering inriktas för programvara i första hand mot omkonstruktion (snarare än genom tillägg av skyddsfunktioner). Riskreducering i form av redundans kan enbart baseras på diversitet, ej identiska kopior.