Om en bil som byggdes 1978 underhålls med stor kärlek och stort kunnande finns det all anledning att tro att den kommer att förbli lika säker som den var när den rullade av tillverkningsbandet, men naturligtvis är en helt ny bil, utrustad med sofistikerade säkerhetsfunktioner som avancerade system för förarassistans (ADAS) och automatisk krockreaktion, mycket säkrare än den 40 år gamla klassikern. Detta gäller åtminstone i början. För till skillnad från den klassiska bilen kommer dagens modell inte att automatiskt bibehålla sina beundransvärda säkerhetsfunktioner med mindre än att dess mjukvara förblir okänslig för attacker. Mark Pitchford från LDRA beskriver här hur detta kan åstadkommas.

Dagens uppkopplade bilar ger en ny betydelse till begreppet säkerhet. Naturligtvis är applikationskod bara en komponent i säkra embeddedsystem. Men vid utvecklandet av denna kod kan många av de metoder, som de som utvecklar säkerhetskritisk kod känner till väl, utnyttjas med ett starkare säkerhetsperspektiv. Visserligen behandlar fordonsstandarden ISO 26262:2012 ”Road vehicles – Functional safety” inte uttalat mjukvarusäkerhet. Men det finns en tydlig skyldighet för fordonsutvecklarna att garantera att osäker mjukvara inte kan äventyra säkerheten.

En del av denna skyldighet är att förstå att inget uppkopplat system i fordonet någonsin kommer att kunna vara både användbart och absolut ogenomträngligt, liksom att ingen försvarsåtgärd av detta system kan garantera ogenomtränglighet. Därför är det viktigt att skydda systemet i proportion till den risknivå som kan uppkomma om det attackeras. Det betyder att det måste finnas flera nivåer av säkerhet, så att om en nivå misslyckas så finns det andra som håller vakt.

Några exempel på sådana nivåer är:
* Säker bootning för att garantera att korrekt mjukvara laddas in
* Separering av domäner för att försvara kritiska delar av systemet
* MILS-designprinciper (lägsta privilegium) för att minimera sårbarheten
* Minimering av attackytor
* Säkra kodningsmetoder
* Säkerhetsfokuserad testning

Men måste varenda en av dessa försiktighetsåtgärder implementeras vid varje tillfälle? Och om inte, hur skall besluten fattas om vad som gäller, och när? För att besvara den frågan skall vi se på sambanden mellan två kritiska lager: domänseparering och säker kodning.

För det första: sök rätt på områden med hög risk
Det är inte kommersiellt rimligt att sätta in varje möjlig säkerhetsåtgärd för varje möjlig mjukvaruarkitektur och applikation. Detta gäller speciellt om t ex en viktig enhets Linux-baserade operativsystem är inblandat, komplett med en rejäl storlek och mjukvara av okänt ursprung. Frågan är, vad skall man då rikta in sin uppmärksamhet på?

Även om de flesta studier inom detta område handlar of datorsystem i storföretag är en lämplig första och grundläggande åtgärd att söka rätt på och fokusera inriktningen på de komponenter i systemet som är utsatta för störst risk. Enligt processen ”Hotanalys och riskvärdering”, som beskrivs i SAE J3061 ”Surface Vehicle Recommendation Practice: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems”, är detta exempel på högriskområden som troligen ingår:
* Filer som kommer in i nätet utifrån
* Bakåtkompatibla gränssnitt mot äldre system, som gamla protokoll, gammal kod och gamla bibliotek, samt multipla versioner som är svåra att underhålla och testa
* Kundspecifika APIer, protokoll och liknande, som kan innehålla fel avseende konstruktion och implementering
* Säkerhetskod, t ex allt som har att göra med kryptografi, autentisering (accesskontroll) och sessionshantering

Separering av domäner
Låt oss se på ett system som använder en teknologi med domänseparering – i detta fall en separationskärna eller hypervisor (Fig 1). Det är enkelt att hitta exempel på högriskområden som är specifika för detta scenario. Tänk t ex på den virtuella maskin som fungerar som gateway. Hur säker är dess krypteringsalgoritmer? Hur väl validerar den inkommande data från molnet? Hur väl validerar den utgående data från de olika domänerna?

Fig 1. Med hjälp av separationsteknologi kan säkerheten optimeras (klicka för större bild)

Sedan har vi data-ändpunkterna (Fig 2). Finns det möjligheter att mata in ”smutsiga” data? Hur har applikationskoden konfigurerats för att garantera att detta inte sker?

Fig 2. Attackytor och opålitliga datakällor inom fordonsområdet

En annan potentiell sårbarhet uppstår när systemet behöver kommunicera mellan olika domäner. Ett exempel är centrallåset i ett fordon, som vanligen tillhör en relativt godartad domän. Men i en nödsituation efter en olycka är det ytterst viktigt att dörrarna låses upp, vilket medför kommunikation med en mer kritisk domän. Så hur kommunikationen mellan dessa domäner än implementeras måste denna lösning vara säker.

Säker kodning
När de mjukvarukomponenter som har hög risk har identifierats är det dags att rikta uppmärksamheten mot den kod som kan associeras med dessa. Här kan vi ha ett system där säker kod inte bara ger en extra försvarslinje, utan också aktivt bidrar till effektiviteten hos den underliggande arkitekturen genom att förstärka dennas svaga punkter.

För att optimera säkerheten hos denna applikationskod krävs det medverkan av ett antal faktorer som återspeglar den mångfacetterade ansatsen till säkerheten för systemet, betraktat som en helhet. Denna ansats minimerar attackytan, maximerar separationen av den utåtriktade attackvektorn från den säkerhetsapplikation som den betjänar samt garanterar att applikationskoden och operativsystemet har utvecklats med säkerhet som en av prioriteterna.

Att införa en säker kodningsstandard är ett kritiskt första steg, och det finns ett antal olika källor att välja från. CERT C är en kodningsstandard som utformats för utveckling av trygga, tillförlitliga och säkra system som använder en applikationscentrerad ansats för att upptäcka problem. MISRA C:2012 är ett annat alternativ, trots ett vanligt missförstånd att det har utvecklats för projekt relaterade till trygghet (safety), snarare än till säkerhet (security). Standardens lämplighet för säkerhetskodning förstärktes ytterligare genom introduktionen av MISRA C:2012 Amendment 1 och dess fjorton extra riktlinjer.

Verktyg för statisk analys varierar stort i förmågan att upptäcka subtila nyanser av brott mot standarden, men sofistikerade implementeringar kan verka långsammare på grund av den extra databearbetning som krävs för att uppnå detta. En finkänslig ansats är att välja verktyg som ger möjlighet att till en början använda ett ”lättviktsläge”, och sedan gå över till mer komplett analys i takt med att utvecklingsarbetet fortskrider.

CERT-divisionen (Computer Emergency Readiness Team) hos Software Engineering Institute (SEI) har pekat ut tolv viktiga metoder för säker kodning. Här skall vi se närmare på hur fyra exempel relaterar till koden för det fordonssystem som visas i Fig 2.

1. Lyssna på kompilatorvarningar
”Kompileringskoden använder den högsta varningsnivån som finns för din kompilator … använd statiska och dynamiska analysverktyg!

Många utvecklare har en tendens att bara bry sig om kompilatorfel under utvecklingsarbetet, och ignorera varningarna. CERTs rekommendation är att ställa in varningarna på den högsta tillgängliga nivån, och se till att alla varningar efterföljs. Verktyg för statisk analys har konstruerats för att kunna hitta ytterligare och mer subtila problem.

2. Konstruera och utveckla med hänsyn tagen till säkerhetsprinciper
”Skapa en mjukvaruarkitektur och konstruera din mjukvara för att implementera och förstärka säkerhetsprinciper”
De som känner sig hemmastadda med de utvecklingsprocesser som föreslås av ISO 26262 kommer att känna sig hemmastadda med uppfattningen att krav måste ställas upp, och att det krävs en spårbarhet i båda riktningarna mellan dessa krav, artefakter i mjukvarukonstruktionen, källkoden samt testerna. Att konstruera för säkerhet innebär att utöka dessa principer att även omfatta krav på säkerhet (security) vid sidan av kraven på trygghet (safety). Det finns också verktyg som kan hjälpa till att förenkla den administrativa huvudvärk som hör ihop med spårbarhet (Fig 3).

Fig 3. Automatisering av kravspårbarheten med komponenten TBmanager i verktygssviten LDRA (klicka för större bild)

3. Krångla inte till det
”Håll konstruktionen så enkel och liten som möjligt”

Det finns många utvärderingsmått på komplexiteten som kan hjälpa utvecklaren att utvärdera sin kod, och automatiserade verktyg för statisk analys hjälper till att utvärdera dessa mått (Fig 4).

Fig 4. Komponenten TBvision i verktygssviten LDRA här använd för att analysera kodkomplexiteten (klicka för större bild)

4. Använd effektiva metoder för kvalitetssäkring
”Goda metoder för kvalitetssäkring kan vara effektiva vid sökandet efter och borttagandet av sårbarheter”

Den traditionella ansatsen vid testning på säkerhetsmarknaden är i hög grad reaktiv. Koden utvecklas med relativt lösa riktlinjer, och testas därefter med avseende på prestanda, genomträngning, belastning och funktionell testning för att hitta och åtgärda eventuella sårbarheter. Visserligen är det helt klart lämpligare att se till att koden är säker ”by design” genom att använda de processer som förespråkas av ISO 26262. Men de verktyg som används i den traditionella, reaktiva modellen – som penetrationstest – har fortfarande sin plats, helt enkelt för att bekräfta att systemet är säkert.

Verktyg för test av enheter ger möjligheter att utföra ett riktat ”robusthetstest” genom att automatiskt generera testfall som undersöker applikationskoden avseende sådant som nollpekare samt övre och undre gränsvärden (Fig 5). Statiska analysverktyg är helt klart användbara för granskning av säkerhetskod.

Fig 5. Komponenten TBeXtreme i verktygssviten LDRA här använd för att testa kodens robusthet (klicka för större bild)

Välj en Multi-Layer-ansats i det ändlösa slaget om säkerheten
Inget uppkopplat system kommer någonsin att kunna vara både användbart och fullständigt ogenomträngligt. Därför är det lämpligt att skydda systemet i proportion till den risknivå som finns om det angrips, och det betyder att man bör använda flera nivåer av säkerhet så att om en nivå misslyckas så finns det andra som håller vakt.

Separering av domäner och säker applikationskod är två exempel på sådana nivåer. De insatser som krävs för att skapa ett system som är tillräckligt säkert kan optimeras genom att man söker rätt på arkitekturens högriskelement, och sedan använder säkra och beprövade kodningsmetoder för den applikationskod som är kopplad till dessa element.

Det skulle bli mycket kostsamt att använda de mest avancerade säkerhetsmetoderna för varje enskilt element i varje embeddedsystem. Men det är viktigt att specificera säkerhetskrav, och sedan konstruera och implementera dessa så att de passar för vart och ett av elementen i systemet – och detta är kanske den viktigaste lärdomen vi kan hämta ur CERTs ”Secure Coding Practices”. Vad gäller själva kodningen kommer riskvärderingen att skapa viktiga pekare mot var systemet som helhet har mest att tjäna på användandet av statiska och dynamiska analysmetoder.

Lyckligtvis – som MISRAs analys har bevisat – är många av de mest lämpade metoderna för kvalitetssäkring väl beprövade inom området funktionell säkerhet. Bland dessa metoder finns statisk analys för att söka efter alltför mycket ”ful kod”, liksom spårning av krav genom hela utvecklingsprocessen.

Med tanke på den dynamiska natur som det ändlösa slaget mellan hackare och utvecklare uppvisar är optimering av säkerheten inte bara en god idé. Skulle det otänkbara inträffa, och det därigenom skulle bli nödvändigt att försvara ett uppkopplat system i en rättssal. Då skulle det vara en mycket stor fördel att kunna lägga fram bevis på att de bästa tillgängliga metoderna har använts.
Mark Pitchford, LDRA Software Technology

Mark Pitchford has over 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
Mark earned his Bachelor of Science degree at Trent University, Nottingham, and he has been a Chartered Engineer for over 20 years. He now works as Technical Specialist with LDRA Software Technology.

Filed under: Fordonselektronik