Verifisere og styrke sikkerheten i militære systemer - Elektronikknett
LDRA-RQ-170_Sentinel
Denne RQ-170 Sentinel dronen ble angivelig tatt av Iran gjennom at man lyktes å få tilgang til dens interne styrings- og navigasjonsprogramvare.

Verifisere og styrke sikkerheten i militære systemer

Fag_vignett

Sikker kodepraksis – ordentlig testet og verifisert – bidrar til å sikre påliteligheten og trygg bruk av militære systemer. Start fra bunnen av, med en kombinasjon av statisk og dynamisk analyse, enhets- og integrasjonstesting, samt kravsporbarhet.

Sikkerhetsbrister i militære systemer kan bli ødeleggende. Ett eksempel der dette fikk alvorlige konsekvenser var da en amerikansk UAV av typen RQ-170 ble fanget inn under en CIA-ledet operasjon i Iran i 2011. Ifølge Iran ble farkosten landet trygt av iranske cyberkrigsenheter som klarte å ta kontroll over den (se bildet over).

Overstyrte dronen
Det ble påstått at UAVen ble tatt ved å jamme dens satellitt- og landbaserte styresignaler, fulgt opp med et GPS ”Spoofing” angrep som fôret UAVen med falske GPS-data, slik at den til slutt landet i Iran – på det stedet dronen trodde var hjemmebasen i Afghanistan. Vi kommer kanskje aldri til å få vite alle detaljene i denne saken, men det virker som dronen ble villedet i en slik grad at den kunne landes trygt på iransk territorium og overlevert i hendene på fienden for mulig konstruksjonsgransking. Ett eller annet i programvaren til denne dronen kunne tillate et sikkerhetsbrudd i minst én del av systemet, hvilket tilsynelatende  åpnet tilgang til dens vitale komponenter.

Innvevde systemer
Innvevde systemer gjennomsyrer nå militæret i alt fra kjøretøystyring, kommunikasjon, våpenstyring og veiledningssystemer, til autonome og halvautonome systemer, inkludert UAV og andre ting. Disse enhetene er nå forbundet med hverandre for styrings- og koordineringsformål. Med tanke på sikkerhet for personellet, evne til å fullføre oppdraget, og ofte med hensyn til nasjonal sikkerhet, må disse enhetene være trygge for brukerne og pålitelige i bruk. I tillegg er det essensielt at det er sikre mot uautorisert tilgang og –angrep. Dersom de ikke er sikre, kan de betraktes verken som trygge eller pålitelige. Derfor er kravene til trygghet, pålitelighet og sikkerhet uatskillelige og gjensidig avhengige.  

Start fra bunnen
Slike krav kan ikke stilles i ettertid, men må bygges opp fra grunnen av. De krever også ofte at programvaren forholder seg til gitte retningslinjer, slik som MISRA eller CERT C, så vel som at de følger industrielle eller myndighetssatte standarder, som DO-178C. Ettersom disse systemene i økende grad blir gjenstand for sertifiseringskrav,  må korrekt koding og funksjonalitet etterprøves og dokumenteres. 

Korrekt koding
Til tross for det faktum at det fins mange metoder for å implementere sikkerhet, vil det fortsatt være nødvendig å sikre at disse også er korrekt kodet – både når det gjelder kodestandarder og korrekt funksjonalitet i hele applikasjonen. 

Kritisk kommunikasjon

LDRA-Figure4 Kostnadene ved å fikse feil øker dramatisk jo senere i utviklingssyklusen de blir håndtert.

Overføringsprotokoller som transport layer security (TSL) – som er en forbedring i forhold til secure sockets layer (SSL), secure file transfer protocol (SFTP) og andre protokoller – er i utstrakt bruk, men ofte kjøpt inn utenfra organisasjonen. Andre strategier omfatter bruk av sikre enhetsdrivere. Dette er metoder for fjernstyrt implementering av sikre og krypterte fastvareoppgraderinger, og personlige verifiseringsmetoder som et passord, retinaskanning og RFID-brikker for å sikre tilgangen. Andre lagvise sikkerhetsmetoder tillater kun utvalgt tilgang til deler av systemet. Men bruk av disse – enten ved å importere dem eller skrive dem fra scratch – kan også introdusere feil som kan utnyttes dersom de ikke blir detektert. Du må være sikker på at din smarte sikkerhetsstrategi faktisk virker som planlagt.

Umulig manuell oppgave
Tidligere kunne mange virksomheter ha muligheten for å sjekke koden med manuelle koderevisjoner og gjennomganger av programvare. Men størrelsen og kompleksiteten på dagens kritiske programmer gjør det umulig å sikre fullstendig analyse med slike metoder og midler. Vi må støtte oss til automatiserte verktøy for å teste for så mange forventede og uventede tilstander som mulig, og fange opp underliggende kodefeil som kan forårsake feilfunksjon eller åpne for usikker tilgang. Dette går langt utover evnene til selv de beste debuggerne eller koderevisjonskomitéene. Det trengs et helt nytt arsenal av test- og analyseverktøy og –metoder for å møte dagens sikkerhetskrav.

Etablere og styrke sikkerhet
Dagens omfattende verktøysett integrerer verktøy for testing, analyse og verifikasjon i ett, enkelt utviklingsmiljø. Bruk av dette verktøymiljøet kan også bidra til å etablere en disiplinert metode innen en organisasjon, som kan hjelpe teamene å koordinere seg, uavhengig av om de arbeider på forskjellige steder. Eksempelvis kan implementeringen av en kodestandard spores og verifiseres med statiske analyseverktøy, for å sikre en enhetlig kodemetodikk gjennom hele virksomheten.

Sporing av krav
For å kunne møte sertifiserings- eller kvalifiseringskrav,  kan verktøy som tillater toveis kravsporbarhet – fra kravspesifikasjon til design, implementering og verifikasjonsaktiviteter og –gjenstander – differensiere en organisasjon fra konkurrentene, og sikre den raskeste veien til godkjenning av enheten. Selv om din prosess og resulterende kode ikke nødvendigvis trenger å møte strenge sertifiseringskrav, vil kravsporbarhet og –håndtering forbedre kodekvaliteten og samlet trygghet, sikkerhet og effektivitet for applikasjonen. Et kravhåndteringsverktøy lar teamene arbeide med individuelle aktiviteter, linkkode og verifikasjonsartifakter, tilbake til høyere mål. 

Kommentarer