Ohjelmistoturvallisuusargumentin rakentaminen MIL-STD-882:n mukaisesti

Järjestelmä, joka toimii ilman ohjelmistoturvallisuusargumenttia, toimii luottamuksen varassa — luottamuksen siihen, että riskianalyysi oli kattava, että suunnittelun hallintakeinot ovat oikein ja että verifiointitodisteet ovat riittävät. Kaupalliselle tuotteelle tämä luottamus on puolustettavissa. Sotilaalliselle järjestelmälle, jonka vikatiloihin kuuluu energian vapautumista, aluksen menetystä tai oma-iskuja, se ei ole. MIL-STD-882E, puolustusministeriön järjestelmäturvallisuusstandardi, tarjoaa strukturoidun prosessin, jolla tämä luottamus korvataan dokumentoiduilla, katselmoiduilla ja hyväksytyillä todisteilla. Ohjelmistoturvallisuusargumentti on tuote, joka kokoaa nämä todisteet ja muodostaa väitteen siitä, että jäännösriskejä on hyväksyttävä.

Tämä artikkeli on käytännön opas ohjelmistoturvallisuusargumentin rakentamiseen MIL-STD-882E:n mukaisesti. Se kattaa standardin tehtävärakenteen ja sen ohjelmistokohtaiset määräykset, riskianalyysiketjun alkuvaiheen tunnistamisesta ohjelmistoriskianalyysiin (SwHA), ohjelmistoturvallisuusvaatimusten (SSR) johtamisen vaaransyistä, suunnittelun hallintakeinot, jotka toteuttavat nämä vaatimukset, verifiointitodisteet, jotka osoittavat niiden oikean toteutuksen, sekä riskinhyväksyntäprosessin, joka päättää argumentin. Insinöörit, jotka ovat uusia puolustuksen turvallisuusohjelmille, löytävät siitä kartan alueesta; kokeneet käytännön ammattilaiset löytävät siitä viitekehyksen niille konkreettisille tuotoksille ja jäljitettävyydelle, joita valtion katselmoijat odottavat.

MIL-STD-882E-yleiskatsaus: järjestelmäturvallisuus konseptista poistoon

MIL-STD-882E määrittelee järjestelmäturvallisuuden suunnitelluksi, kurinalaiseksi lähestymistavaksi vaarojen tunnistamiseen ja hallintaan järjestelmän koko elinkaaren ajan — konseptin tutkimuksesta poistoon. Standardi järjestää vaatimuksensa tehtäviksi, jotka on jaoteltu viiteen kategoriaan: ohjelmiston hallinta ja ohjaus, suunnitteluvaatimukset, ylläpidettävyys, koulutus ja arvioinnit. Sopimusyksikkö valitsee ohjelman riskiprofiiliin sopivat tehtävät ja määrittää ne työnkuvauksessa. Urakoitsija suorittaa nämä tehtävät ja toimittaa tulokset sopimustietovaatimuslistan kohteina.

Ohjelmistopainotteisille sotilasjärjestelmille viisi tehtävää hallitsee insinööripanosta:

• Tehtävä 205 — ohjelmistoturvallisuusvaatimusten analyysi: kaikkien turvallisuuskriittisten ohjelmistotoimintojen tunnistaminen ja ohjelmistoturvallisuusvaatimusten johtaminen tunnistettujen vaaransyiden hallitsemiseksi.
• Tehtävä 206 — ohjelmistoturvallisuuden suunnitteluanalyysi: ohjelmistosuunnittelun analyysi sen varmistamiseksi, että turvallisuusvaatimukset on kohdennettu oikein ja että suunnittelupäätökset eivät tuo mukanaan uusia vaaransyitä.
• Tehtävä 301 — turvallisuusarviointi: virstanpylväälähtöinen arviointi siitä, onko jäännösriskejä hyväksyttävä, dokumentoitu turvallisuusarviointiraporttiin (SAR).
• Tehtävä 302 — testauksen ja arvioinnin turvallisuus: sen varmistaminen, että turvallisuuden hallintakeinot ovat voimassa ennen mitään testaustoimintaa, joka liittyy vaaralliseen energiaan tai operatiivisiin tiloihin.
• Tehtävä 303 — järjestelmäturvallisuusohjelman katselmoinnit: muodolliset katselmoinnit, joissa System Safety Working Group (SSWG) esittää vaarojen tilan, avoimet riskikohteet ja hallintakeinojen tehokkuuden todisteet ohjelmistotoimistolle.

MIL-STD-882E:n keskiössä oleva riskimatriisi kuvaa vakavuutta suhteessa todennäköisyyteen. Vakavuus ulottuu katastrofaalisesta (luokka I: kuolema, järjestelmän menetys, vakava ympäristövahinko) kriittisen (luokka II: vakava vamma, merkittävä järjestelmävahinko) ja marginaalisen (luokka III: lievä vamma, pieni järjestelmävahinko) kautta merkityksettömään (luokka IV: vähemmän kuin lievä vamma tai vahinko). Todennäköisyys ulottuu usein tapahtuvasta (todennäköistä, että usein järjestelmän elinkaaren aikana) todennäköisen, satunnaisen, harvinaisen ja epätodennäköisen kautta. Jokainen tuloksena syntyneen 4×5-matriisin ruutu kantaa vaarariskiindeksiä (HRI), joka määrittää, kenen on hyväksyttävä jäännösriskejä hallintakeinojen jälkeen.

HRI ei ole matemaattinen tulo — se on järjestyksellinen sijoitus, jonka määrittelee ohjelman riskimatriisi, jonka SSPP vahvistaa. Katastrofaalinen/usein tapahtuva vaara (HRI 1) vaatii Milestone Decision Authorityn hyväksynnän; merkityksetön/epätodennäköinen vaara (HRI 20) on hyväksyttävissä työryhmätasolla. Käytännön seuraus ohjelmistoinsinööreille on, että heidän tuottamansa analyysituotteet — vaaralomakkeet, SwHA-rivit, SSR:t, verifiointipöytäkirjat — syöttyvät suoraan riskinhallintaprosessiin, jossa on määritellyt valtatasot. Aukot analyysissä jättävät riskin epämääräiselle tasolle, jota mikään auktoriteetti ei voi hyväksyä.

Alkuvaiheen riskianalyysi: turvallisuuskriittisten ohjelmistotoimintojen löytäminen

Alkuvaiheen riskianalyysi (PHA) suoritetaan varhain järjestelmäkehityksessä, tyypillisesti ennen kuin yksityiskohtaiset vaatimukset on vahvistettu, käyttäen järjestelmän toimintapureutumista ja operatiivisen konseptin dokumentointia. Sen tarkoitus on tunnistaa vaarat järjestelmätasolla, antaa alustavat vakavuus- ja todennäköisyysarviot ja tunnistaa, mitkä järjestelmän toiminnot — laitteisto, ohjelmisto, ihminen tai menettely — vaikuttavat kunkin vaaran. PHA ei vaadi yksityiskohtaista suunnittelutietoa; se toimii tasolla ”mitä tämä järjestelmä voi tehdä, mikä voi vahingoittaa ihmisiä, kalustoa tai ympäristöä?”

PHA-syötteisiin kuuluvat tyypillisesti:

• Järjestelmän toimintakonsepti (CONOPS) ja operatiiviset skenaariot
• Järjestelmän toiminnalliset vaatimukset ja ylätason arkkitehtuuri
• Energialähteiden ja vaarallisten aineiden inventaari
• Rajapintamäärittelyt (viereisiin järjestelmiin, operaattoreihin, ympäristöön)
• Historialliset vaaratiedot vastaavista järjestelmistä

PHA-tuloksiin sisältyy täytetty vaaraloki, jossa on yksilölliset vaaratunnisteet, luonnollisen kielen vaarakuvaukset, alustavat HRI-arviot ja luettelo vaikuttavista toiminnoista. Tulenhallintajärjestelmälle PHA voisi tunnistaa ”tahattoman aseiden laukaisun” katastrofaalisena vaarana (luokka I) ja luetella vaikuttaviksi toiminnoiksi: käsittelyvaltuutuksen ohjelmiston, aseiden laukaisukomennon kanavan, lukituslogiikan ja operaattorin käyttöliittymän. Tämä luettelo vaikuttavista toiminnoista on lähtökohta kaikelle myöhemmälle ohjelmistoturvallisuusanalyysille.

Vaaran ja vikatilan ero on tässä merkityksellinen. Vaara on tilanne, jolla on potentiaalia vahingolle — ”tahaton aseiden laukaisu” on vaara. Vikatila on mekanismi, jolla komponentti voi toimia virheellisesti — ”FIRE_COMMAND-ulosteen virheellinen asetus” on vikatila. PHA tunnistaa vaarat; myöhemmät analyysit tunnistavat vikatilat, jotka edesauttavat niitä. Näiden sekoittaminen vaaralokissa on yleisin rakenteellinen virhe varhaisen vaiheen turvallisuusanalyysissä, ja se leviää eteenpäin SwHA-taulukoihin, joita on vaikea jäljittää.

Ohjelmiston osuus järjestelmävaaroista on laadullisesti erilaista kuin laitteiston. Laitteistokomponentilla on fyysinen vikasuhde, joka voidaan arvioida kenttätiedoista tai kiihdytetystä testauksesta. Ohjelmistovirheet ovat deterministisiä: tietyillä syötteillä virheellinen toiminto tuottaa aina väärän tuloksen. Ohjelmisto ei kulu eikä sillä ole merkityksellistä keskimääräistä vikaväliä samassa mielessä kuin releellä tai venttiilillä. Ohjelmistoon liittyvälle osuudelle vaarasta annettu todennäköisyys on siis arvio todennäköisyydestä, että ohjelmisto sisältää kyseiseen vaaraan liittyvän virheen, painotettuna todennäköisyydellä, että käynnistävät syöteolosuhteet esiintyvät käytössä. Tämä arvio perustuu ohjelmiston monimutkaisuuteen, kehitysprosessin tinkimättömyyteen ja testauksen syvyyteen — ei empiirisiin virhetietoihin.

Ohjelmistoriskianalyysi: ohjelmiston kartoittaminen vaaroihin

Ohjelmistoriskianalyysi (SwHA) on tehtävä, joka yhdistää järjestelmätason vaaralokin tiettyihin ohjelmiston käyttäytymistapoihin. Jokaiselle PHA:n vaaralle, joka luettee ohjelmistotoimintoa vaikuttajana, SwHA kysyy: mitä ohjelmiston on tehtävä virheellisesti (tai jätettävä tekemättä), jotta tämä vaara tapahtuisi? Vastaus luettelee ohjelmiston vikatilat, joista tulee syyketjut, joita SSR:ien on käsiteltävä.

Ohjelmiston vikatilat jakautuvat viiteen kanoniseen kategoriaan:

• Virheellinen ulostulo: toiminto suorittuu ja tuottaa ulostulon, mutta ulostuloarvo on väärä — komento kelvollisen alueen ulkopuolella, tilalippu asetettuna kun sen pitäisi olla nollattuna tai laskentatulos aritmeettisella virheellä.
• Ei ulostetta (poisjäänti): toiminto ei tuota ulostetta, johon järjestelmä nojaa — valvontakello, joka lakkaa nollaamasta, kunnonvalvoja, joka ei raportoi vikaa, turvallisuuslukitus, joka ei aseta estosignaalia.
• Myöhäinen ulostulo: toiminto tuottaa oikean ulostulon, mutta ei vaaditun aikaikkunan puitteissa — reaaliaikarajoitteen rikkominen, joka saa järjestelmän etenemään vanhentuneella tai puuttuvalla syötteellä.
• Virheellinen ulostulo: toiminto tuottaa ulostulon, jota ei ole pyydetty tai joka tapahtuu aikana, jolloin se ei ole kelvollinen — pyytämätön komento, joka käynnistää toimilaitteen tilassa, jossa tämä komento on vaarallinen.
• Ulostulo väärään kohteeseen: toiminto reitittää kelvollisen ulostulon virheelliseen rajapintaan — yhdelle alijärjestelmälle tarkoitettu komento toimitetaan toiselle reititys- tai osoitusvirheen takia.

SwHA-lomaken rakenne noudattaa vakiomallia. Jokainen rivi vastaa yhtä (vaara, ohjelmistotoiminto, vikatila) -kolmikkoa. Sarakkeet kirjaavat vaaratunnuksen, vaarakuvauksen, ohjelmistotoiminnon nimen, vikatilakategorian, vikatilan vaikutuksen järjestelmävaaraan, aiheutuvan vahingon vakavuuden, todennäköisyyden (kvalitatiivisena arviona), HRI:n ja tämän rivin käsittelevän SSR-tunnuksen. Lentohallintajärjestelmän SwHA-taulussa voi olla useita satoja rivejä; yksinkertaisemmalla komento- ja ohjausjärjestelmällä ehkä kolmestakymmenestä kuuteenkymmeneen.

Jäljitettävyys on SwHA-laadun operatiivinen mittari. Jokaisen PHA:n vaaran, jolla on ohjelmisto-osuus, on oltava SwHA:ssa. Jokaisella PHA:ssa luetellulla ohjelmistotoiminnolla on oltava vähintään yksi SwHA-rivi. Jokaisen SwHA-rivin on linkittävä vähintään yhteen SRS:ään. Ja jokainen SRS on jäljitettävä takaisin vähintään yhteen SwHA-riviin. Valtion turvallisuuskatselmoinneissa löydetyt jäljitettävyysaukot ovat yleisin syy SwHA:n uudelleentyöstöön katselmointisyklissä.

SwHA tunnistaa myös ohjelmistovaatimuksia, jotka palvelevat turvallisuustoimintoja ei siksi, että ne estävät vaaran suoraan, vaan siksi, että ne mahdollistavat turvallisuusvalvojan tunnistaa vaaran edeltäjän. Nämä valvontavaatimukset ovat yhtä tärkeitä kuin suorat hallintavaatimukset — valvoja, joka pettää hiljaa, riistää järjestelmältä kyvyn siirtyä turvalliseen tilaan ennen vaaran tapahtumista. Ne vaativat saman SSR-muotoilun ja verifioinnin tinkimättömyyden kuin suorat estovaatimukset. Katso myös: formal verification for defense software tekniikoista, jotka voivat matemaattisesti osoittaa tiettyjen vikatilojen poissaolon turvallisuuskriittisissä moduuleissa.

Turvallisuuskriittisten toimintojen tunnistaminen ja ohjelmistoturvallisuusvaatimukset

Turvallisuuskriittinen ohjelmistotoiminto on mikä tahansa toiminto, jonka vikatila esiintyy SwHA:ssa katastrofaalisen tai kriittisen vaaran vaikuttajana. Turvallisuuskriittisten toimintojen tunnistaminen on edellytys lisäsuunnittelun tinkimättömyydelle: korkeammat koodin kattavuustavoitteet, pakollinen vertaisarviointi, itsenäinen verifiointi ja muodollinen analyysi.

Ohjelmiston kriittisyysindeksi (SCI) formalisoi tämän. Jokaiselle turvallisuuskriittiselle toiminnolle annetaan kriittisyyskategoria sen pahimman seurauksen perusteella: luokka I (katastrofaalinen), luokka II (kriittinen), luokka III (marginaalinen), luokka IV (merkityksetön). SCI ohjaa ohjelmistoturvallisuusvaatimusten valintaa ja jokaiseen toimintoon sovellettavan verifioinnin syvyyttä. Luokan I toiminto — esimerkiksi viimeinen valmistarkastus ennen aseiden laukaisukomentoa — ansaitsee tinkimättömimmän kohtelun, jonka ohjelma voi soveltaa. Luokan IV toiminto — diagnostiikkalokin kirjoittaja — ei ansaitse lainkaan lisätinkimättömyyttä.

Ohjelmistoturvallisuusvaatimukset (SSR) johdetaan suoraan SwHA-riveistä. Jokaiselle tunnistetulle vikatilalle SSR määrittää ohjelmiston käyttäytymisen, joka estää, tunnistaa tai lieventää tämän vikatilan. Kanoniset SSR-muodot ovat:

• Positiivinen rajoite: ”Ohjelmiston on asetettava SAFE_STATE-ulostulo 50 ms kuluessa päätutkan kelvollisen sykkeen menettämisen havaitsemisesta.” (Käsittelee: myöhäistä/puuttuvaa ulostetta sensorin valvontatoiminnossa.)
• Negatiivinen rajoite: ”Ohjelmisto ei saa asettaa WEAPONS_RELEASE_COMMAND-komentoa, ellei ARM_CONFIRMED, TARGET_VALIDATED ja OPERATOR_AUTHORIZED ole kaikki asetettuina jatkuvasti vähintään 500 ms.” (Käsittelee: virheellistä ulostetta laukaisun valmistelutoiminnossa.)
• Aluerajoite: ”Käsketyn atsimutin ulostulon on oltava ±180 asteen sisällä. Mikä tahansa tämän alueen ulkopuolella oleva laskettu arvo aiheuttaa, että ohjelmisto siirtyy FAULT_HOLD-tilaan ilman komennon antamista.” (Käsittelee: virheellistä ulostetta tulenhallinnan laskentatoiminnossa.)
• Valvontavaatimus: ”Ohjelmiston on verrattava käskettyä työntövoimaa mitattuun työntövoimaan jokaisella 10 ms syklillä ja asetettava THRUST_FAULT_FLAG, jos ero ylittää 15 % kolmena peräkkäisenä syklinä.” (Mahdollistaa vaaran edeltäjän tunnistamisen.)

Jokaiseen SRS:ään liitetään yksilöllinen tunniste (esim. SSR-FC-007), se kohdennetaan tiettyyn ohjelmistokomponenttiin arkkitehtuurissa ja se syötetään jäljitettävyysmatriisiin, joka yhdistää sen vanhempiinsa SwHA-riveihin. Yksityiskohtaisen suunnittelun aikana jokainen SRS on kohdennettava edelleen tiettyyn vaatimukseen ohjelmistovaatimusmäärityksessä (SRS) tai ohjelmistosuunnitteluasiakirjassa (SDD). SRS/SDD-vaatimus periä SRS-tunnuksen, mikä mahdollistaa, että automatisoidut jäljitystyökalut levittävät turvallisuusmerkinnän vaatimushierarkian läpi ja testitapausten valintaan.

SSR:t, joita ei voida verifioida testillä tai analyysillä, ovat merkkejä arkkitehtuuriongelmasta. Jos turvallisuuskäyttäytymistä ei voida vahvistaa itsenäisesti, joko ohjelmistoarkkitehtuuri ei paljasta asiaankuuluvaa tilaa havainnointiin tai SRS on muotoiltu termein, jotka eivät ole mitattavissa. Molemmat ongelmat on ratkaistava ennen kuin suunnittelu etenee toteutukseen. SRS ilman toteuttamiskelpoista verifiointimenetelmää ei ole turvallisuuden hallintakeino — se on aikomuksen ilmoitus.

Ohjelmiston suunnittelun hallintakeinot turvallisuudelle

Suunnittelun hallintakeinot ovat arkkitehtuuri- ja toteutusmalleja, jotka tekevät SSR:ien vaatimasta ohjelmiston käyttäytymisestä luotettavaa vikojen läsnä ollessa. Jokainen suunnittelun hallintakeino valitaan sen käsittelemän vikatilan ja tämän vikatilan seurauksen vakavuuden perusteella. Ei ole olemassa yleispätevää mallia — asianmukainen hallintakeino riippuu järjestelmän arkkitehtuurista ja käsiteltävästä vaaransyystä.

Laajimmin sovellettavat mallit sotilasohjelmistoissa ovat:

Valvontakellon valvonta. Laitteisto- tai itsenäinen ohjelmistokello vaatii turvallisuuskriittisen sovelluksen asettamaan nollaussignaalin aktiivisesti jokaisella käsittelysyklillä. Nollauksen asettamatta jättäminen — johtuen sovelluksen kaatumisesta, äärettömästä silmukasta tai muusta vastaamattomuudesta — saa kellon aikakatkaisemaan ja pakottamaan siirtymän turvalliseen tilaan. Turvallinen tila määritellään laitteistolla: energia pois ulostuloilta, estot asetettuina, venttiilit suljettuina. Kellon ei tarvitse ymmärtää, miksi sovellus petti; sen tarvitsee tietää vain, että normaali toiminta on lakannut.

Positiiviset lukitusjärjestykset. Vaaralliset komennot vaativat useita itsenäisiä sallimisehtoja, jotka on tyydytettävä samanaikaisesti ennen kuin komento voidaan antaa. Yksittäinen ohjelmistovika, yksittäinen sensorivika tai yksittäinen operaattorin virhe ei voi täyttää kaikkia ehtoja samanaikaisesti. Klassinen esimerkki on aseiden lukitus- ja laukaisujärjestys: lukitus vaatii erillisen laitteistolukituspiirin, ohjelmiston valmistelutilan, etäisyyden- tai maalitusehdon ja operaattorin vahvistuksen, kaikki aikaikkunan sisällä. Minkä tahansa näistä poistaminen riistää kyvyn ampua.

Vikaturvalliset tilakoneet. Turvallisuuskriittinen ohjauslogiikka toteutetaan nimenomaisena äärellisenä tilakoneena, jossa on määritelty turvallinen oletustila. Jokainen syöte, joka aiheuttaisi kelvottoman tilamuutoksen, kohdistetaan turvalliseen tilaan määrittelemättömän käyttäytymisen sijaan. Tilakone on suunniteltu niin, että sähkökatkos, viestintäkatkos tai sensorin kelvottomuus johtavat kaikki turvalliseen tilaan — vikatilanteesta ei ole polkua vaaralliseen komentoon. Tarkastele yksinkertaistettua esimerkkiä lukitusohjaimelle:

Uskottavuuden valvonta. Itsenäinen valvontaprosessi vertaa ulostulokomentoja fyysisiin rajoituksiin. Käsketty kiihtyvyys, joka ylittää aluksen dokumentoidun maksimikyvyn, on epäuskottava ja voi merkitä laskentavirhettä tai vaurioitunutta syötettä. Valvoja sieppaa ja estää epäuskottavan komennon, kirjaa tapahtuman ja hälyttää kunnonhallintajärjestelmän. Valvontalogiikan on oltava riippumaton laskentalogiikasta — jos molemmat käyttävät samaa algoritmia, systemaattinen virhe vaikuttaa molempiin identtisesti eikä valvoja tarjoa suojaa.

Puolustava syötetarkistus. Jokainen turvallisuuskriittinen toiminto vahvistaa syötteensä määritellyille kelvollisille alueille ennen niiden käsittelyä. Syötteet, jotka ovat kelvollisen alueen ulkopuolella, eivät aiheuta laskentaa virheellisillä vaan ne saavat toiminnon asettamaan vikatilan ja siirtymään määrättyyn virheenkäsittelypolkuun. Tarkistuslogiikan on katettava aluetarkistusten lisäksi ajallinen kelvollisuus (onko tämä viimeisin näyte vai vanhentunut luku?), lähteen kelvollisuus (tuleeko tämä arvo odotetulta lähettäjältä?) ja yhteensopivuus (sopiiko tämä arvo vahvistavien sensorien kanssa toleranssin puitteissa?).

Jokainen suunnittelun hallintakeino dokumentoidaan ohjelmistosuunnitteluasiakirjaan nimenomaisella ristiviittauksella toteuttamaansa SRS:ään. Suunnittelukatselmointiprosessi sisältää sen varmistuksen, että jokaiselle SRS:lle on tunnistettu suunnittelun hallintakeino ja että jokainen hallintakeino on perusteltu riittäväksi käsittelemälleen vikatilalle. Hallintakeinot, jotka ovat riittäviä marginaalisille vaaroille, eivät välttämättä ole riittäviä kriittisille — riittävyysväitteen on oltava seurausvakavuuteen sidottu.

Turvallisuuden verifiointitodisteet

Turvallisuuden verifiointitodisteet ovat joukko pöytäkirjoja, jotka osoittavat, että jokainen SRS on toteutettu oikein toimitetussa ohjelmistossa. Todisteperustan on oltava riittävä pätevälle katselmoijalle — valtion turvallisuusinsinöörille, turvallisuuskatselmoilautakunnalle tai riskinhyväksyntävallalle — päätellä, että ohjelmisto käyttäytyy kuten turvallisuusargumentti väittää. Todisteet, jotka ovat olemassa mutta eivät jäljitettävissä SRS:ään, tai jotka jäljittyvät SRS:ään mutta eivät ole riittäviä niiden toteutuksen osoittamiseen, eivät sulje turvallisuusargumenttia.

Ensisijaiset todistetyypit ohjelmistoturvallisuuden verifiointiin ovat:

Turvallisuuskohtaiset testitapaukset. Jokaiselle SRS:lle johdetaan yksi tai useampi testitapaus, joka testaa suoraan vaadittua käyttäytymistä. Testitapaukset rakennetaan SwHA-vikatiloista: jos SwHA-rivi tunnistaa ”FIRE_COMMAND-virheellisen asettamisen SAFE-tilassa” vaaransyyn, vastaava testitapaus soveltaa juuri niitä syöteolosuhteita, joita tarvittaisiin tämän käyttäytymisen laukaisemiseen, ja varmistaa, ettei ulostuloa aseteta. Vaarallisen käyttäytymisen poissaolon testaaminen on vaativampaa kuin oikean käyttäytymisen läsnäolon testaaminen — testi-insinöörin on pohdittava kaikkia syötepolkuja, jotka voivat saavuttaa turvallisuustoiminnon, ja vahvistettava, ettei yksikään tuota vaarallista ulostuloa.

Koodin kattavuus turvallisuuskriittisille moduuleille. Kattavuusmittarit tarjoavat luottamusta siihen, että testisarja harjoittelee SSR:t toteuttavia koodipolkuja. Turvallisuuskriittisten moduulien kattavuustavoite (SCI:n luokkien I ja II toiminnot) on tyypillisesti vähintään 100 % haarakattavuus, ja Modified Condition/Decision Coverage (MC/DC) vaaditaan toiminnoille, jotka toteuttavat moniehtoista valmistelulogiikkaa. Haarakattavuusraportti, joka näyttää testaamattomia haaroja turvallisuuskriittisessä moduulissa, on avoin havainto — joko testaamaton haara on kuollutta koodia, joka on poistettava, tai testitapaus puuttuu. Kattavuustiedot ilman vastaavaa SRS-jäljitettävyyskarttaa eivät muodosta turvallisuuden verifiointitodisteita — todiste on kytkennässä kattavan koodin ja sen toteuttamien SRS:ien välillä. Katso myös: software testing military systems testausmenetelmien täyteen käsittelyyn puolustusohjelmille.

Ohjelmiston FMEA. Ohjelmiston vikatila- ja vaikutusanalyysi (FMEA) soveltaa FMEA-menetelmää ohjelmistomoduleihin laitekomponenttien sijaan. Jokaiselle turvallisuuskriittisen moduulin toiminnolle FMEA kirjaa: toiminnon tarkoituksen, vikatilat (käyttäen SwHA:n viittä kanonista kategoriaa), kunkin vikatilan vaikutuksen ohjelmiston ulostuloon, vaikutuksen järjestelmävaaraan, tunnistusmekanismin (valvontakello, valvoja, testi, operaattorin havainto) ja korvaavan hallintakeinon suunnittelussa. Ohjelmiston FMEA on arvokkain ristitarkistuksena SwHA:lle — jos FMEA tunnistaa vikatilan, jolla on vaarallisia seurauksia ja joka ei esiinny SwHA:ssa, joko SwHA:ssa on aukko tai FMEA:ssa on virheellinen positiivinen, joka on ratkaistava. Molemmat tulokset parantavat turvallisuusargumenttia.

Koodikatselmointipöytäkirjat. Turvallisuuskriittisen koodin vertaisarviointi turvallisuuskohtaisella tarkistuslistalla tuottaa todisteita siitä, että pätevät insinöörit ovat tarkastelleet toteutusta SRS:ien ja suunnittelun hallintakeinojen suhteen. Tarkistuslistan kohteiden olisi vastattava suoraan vaadittuja suunnittelumalleja — ”valvontakellon nollaus kutsutaan jokaisella syklillä”, ”kaikki syötteet tarkistetaan ennen käyttöä”, ”tilakoneessa ei ole määrittelemättömiä siirtymiä”. Katselmointipöytäkirjat tunnistavat löydetyt virheet ja niiden käsittelytavat; katselmointi, jossa on nolla havaintoa monimutkaisesta turvallisuuskriittisestä moduulista, on joko merkki poikkeuksellisen puhtaasta toteutuksesta tai riittämättömän tinkimättömästä katselmointiprosessista, ja ohjelman turvallisuusinsinöörin pystytävä erottamaan nämä toisistaan.

Näiden todistetyyppien integroiminen DevSecOps for defense pipelines -putkiin vaatii, että turvallisuuskriittiset testitapaukset, kattavuustyökalut ja FMEA-lomakkeet ovat konfiguraatiohallittuja yhdessä niiden vahvistaman lähdekoodin kanssa. Testitulos ilman konfiguraatioperustaa, joka tunnistaa täsmällisesti testatun ohjelmistoversion, ei ole toistettava todiste eikä sitä voida toimittaa Safety Data Packageessa. Jokainen todistetarvitsee asiakirjanumeron, version, päivämäärän ja linkin siihen ohjelmistokonfiguraatiokohteen perustaan, jonka se kattaa.

Turvallisuusargumentin kokoaminen ja jäännösriskien hyväksyntä

Turvallisuusargumentti on strukturoitu väite siitä, että toimitettu ohjelmistojärjestelmä on hyväksyttävän turvallinen tarkoitettuun käyttöönsä. Se ei väitä, että ohjelmisto olisi virheetön tai että kaikki riskit olisi poistettu — tällaiset väitteet eivät ole saavutettavissa eivätkä ne ole sitä, mitä MIL-STD-882E vaatii. Se väittää, että: kaikki kohtuudella ennakoitavat vaarat on tunnistettu; hallintakeinoja on sovellettu, jotka vähentävät jokaisen vaaran hyväksyttävälle riskitasolle; hallintakeinot on verifioitu oikein toteutetuiksi; ja jäännösriskejä, jotka jäävät jäljelle hallintakeinojen jälkeen, on katselmoitu ja asianmukainen auktoriteetti on ne hyväksynyt.

Turvallisuusargumentin asiakirjarakenne noudattaa väite-argumentti-todiste-hierarkiaa. Goal Structuring Notation (GSN) -notaatiota käytetään usein tämän hierarkian visualisointiin, vaikka notaatio ei ole pakollinen — rakenteen on oltava olemassa riippumatta siitä, ilmaistaanko se GSN-muodossa. Tyypillinen ylätason rakenne tulenhallintajärjestelmän ohjelmistoturvallisuusargumentille:

Safety Data Package (SDP) on kokoelma tuotteita, jotka toimitetaan ohjelmistotoimistolle turvallisuusargumentin todisteiksi. Sen sisältö määritellään järjestelmäturvallisuusohjelmasuunnitelmassa CDRL-luettelona, jonka toimituspäivämäärät liittyvät ohjelman virstanpylväisiin. Tyypillinen SDP:n sisältö:

• Järjestelmäturvallisuusohjelmasuunnitelma (SSPP)
• Alkuvaiheen riskianalyysin (PHA) raportti
• Alijärjestelmän riskianalyysin (SSHA) raportit
• Ohjelmistoriskianalyysin (SwHA) lomakkeet
• Ohjelmistoturvallisuusvaatimusten (SSR) luettelo ja jäljitettävyysmatriisi
• Ohjelmistoturvallisuuden suunnitteluanalyysin (tehtävä 206) raportit
• Ohjelmiston FMEA-lomakkeet
• Turvallisuuskriittisten ohjelmistojen testitapaukset ja testitulokset
• Koodin kattavuusraportit turvallisuuskriittisille moduuleille
• Koodikatselmointipöytäkirjat turvallisuuskriittisille moduuleille
• Hazard Risk Decision Reportit (HRDR) hyväksytyistä jäännöksistä
• Turvallisuusarviointiraportti (SAR)

Jäännösriskien hyväksyntä on muodollinen toimi, jolla riskinhyväksyntävalta tunnustaa, että vaara on hallittu tasolle, joka ylittää edelleen ohjelman hyväksyttävän kynnyksen, katselmoi todisteet siitä, että hallintakeinot ovat riittäviä ja oikein toteutettuja, ja ottaa vastuun jäljelle jäävästä riskistä. Hazard Risk Decision Report on väline tähän toimiiin. HRDR kuvaa vaaran, sovelletut hallintakeinot, jäljelle jääneen HRI:n hallintakeinojen jälkeen, todisteet, jotka tukevat jäännös-HRI-arviota, ja suosituksen. Asianmukainen auktoriteetti allekirjoittaa HRDR:n ja muuntaa sen suosituksesta muodolliseksi riskinhyväksyntäkirjaksi.

Turvallisuusargumentti on elävä asiakirja. Joka kerta kun ohjelmistoa muutetaan — vaatimuksia muutetaan, virheitä korjataan, rajapintoja kehitetään — turvallisuusargumentti on katselmoitava sen selvittämiseksi, vaikuttaako muutos mihinkään vaaraan, SRS:ään, suunnittelun hallintakeinoon tai todistekohtaan. Muutos, joka nostaa hyväksytyn jäännösriskin todennäköisyyttä tai vakavuutta, vaatii uuden HRDR:n, jonka asianmukainen auktoriteetti allekirjoittaa. Muutos, joka tuo mukanaan uuden vaaransyyyn, vaatii SwHA-päivityksen ja mahdollisesti uuden SRS:n. Turvallisuusargumentin tuotteiden konfiguraatiohallinta on siksi yhtä tärkeää kuin lähdekoodin konfiguraatiohallinta — vanhentunut turvallisuusargumentti, joka ei heijasta nykyistä ohjelmistoperustaa, ei ole lainkaan turvallisuusargumentti.

Yleisin ohjelmistoturvallisuusohjelmien vikatila ei ole riittämätön analyysi — vaan riittämätön seuranta. SwHA suoritetaan, SSR:t kirjoitetaan, suunnittelun hallintakeinot toteutetaan, ja sitten testaussuunnittelu etenee ilman systemaattista yhteyttä SSR:ien ja testitapausten välillä. Kattavuustiedot kerätään ilman karttaa turvallisuuskriittisistä moduleista. FMEA kirjoitetaan koodikatselmoinnin jälkeen eikä ennen sitä. Tuloksena on kokoelma yksittäin uskottavia tuotteita, jotka eivät muodosta johdonmukaista argumenttia. Turvallisuusargumentin kokoamistehtävä on kohta, jossa nämä yhteyden katkeamat tulevat näkyviin — ja niiden ratkaiseminen ennen ohjelmakatselmointeja eikä niiden aikana eroaa puolustettavasta turvallisuusohjelmasta ja kalliista uudelleentyöstösyklistä.