Az autóipar biztonsága végtelen számú szoftverfejlesztési élettartamot igényel

Moskvich 412 (Москвич) - Soviet Car Review (Július 2019).

$config[ads_text] not found
Anonim

A gépjármű-fejlesztők számára világos kötelezettség áll fenn annak biztosítására, hogy a nem biztonságos alkalmazások szoftverek ne veszélyeztethessék a biztonságot, amíg egy termék a területen tartózkodik

BY MARK PITCHFORD, műszaki szakember
LDRA szoftver technológia
www.ldra.com

Az autóipari beágyazott alkalmazások hagyományosan elszigeteltek, statikusak, rögzített funkciójú, eszköz-specifikus implementációk, és a gyakorlatok és folyamatok támaszkodtak erre a státusra. Az autók külső világhoz történő csatlakoztatása drámai módon megváltoztatja a dolgokat, mivel lehetővé teszi a távoli hozzáférést, miközben nem igényel fizikai módosítást az autó rendszereihez. A gépjárműfejlesztők számára világos kötelezettség áll, hogy biztosítsák, hogy a nem biztonságos alkalmazási szoftverek ne veszélyeztethessék a biztonságot, nem csak a gyártási élettartam alatt, hanem olyan ideig is, ameddig egy termék a területen tartózkodik.

Bár a jól ismert ISO 26262: 2012 "Közúti járművek - funkcionális biztonság" szabvány segíti a formalizált szoftverfejlesztési folyamatok biztosítását, nem említi kifejezetten a szoftverbiztonságot. Ez azt jelenti, hogy ahol a biztonsági rések veszélyeztethetik a biztonságot, az ISO 26262 biztonsági követelményeket és követelményeket követel meg ezek kezelésére. Az egyes biztonsági szempontokat veszélyeztető biztonsági kérdések kezeléséhez szükséges lépéseknek arányosnak kell lenniük a kockázattal az ISO 26262 Automotive Safety Integrity Level (ASIL) kockázati besorolási rendszere alapján.

A biztonság biztosítása érdekében azonban a beágyazott rendszerek fejlesztőinek fontolóra kell venniük, hogy az alkalmazáskód csak egy létfontosságú összetevője, és hogy a kód fejlesztésében a biztonság szempontjából kritikus kódfejlesztők számára ismert számos technika biztonságosabb perspektívával bővíthető.

A fejlesztésen túl azonban a kapcsolatrendszer új jelentőséggel bír a rendszer karbantartásával minden újonnan felfedezett sérülékenységgel szemben, mivel a szoftverkövetelmények és a biztonsági rések a fejlesztés után változhatnak, és mindaddig, amíg egy terméket a területen használnak. Gépkocsik esetében ez legfeljebb 10 év lehet.

Alkalmazáskód biztosítása
A biztonságos beágyazott rendszer sokkal több, mint az alkalmazáskód biztonságos biztosítása. Az olyan technológiák, mint a biztonsági edzésű operációs rendszerek, a hypervisorok, a szétválasztó rendszermagok és a rendszerindító képintegritás-ellenőrzés mind alapvető fontosságú részei. Ezek a technológiák nemcsak többszintű védelmet kínálnak az agresszorokkal szemben, de kölcsönösen támogathatók is.

Példaként említhetõ, ha egy autórendszert egy többdomaines architektúrával telepítenek elkülönítési kernel vagy hypervisor segítségével. A domain-szeparációs megközelítés, amely rendkívül kritikus alkalmazásokat tart fenn a rendszer több világi részéből, vonzó alapot nyújt a biztonságos rendszer számára. De az alapul szolgáló építészetben erősségek és gyengeségek lesznek.

A kockázatelemzés használata segíthet a gyenge pontok rendszeres feltárásában, amelyek valószínűleg olyan területeken találhatók meg, mint:

  • Interfészek a különböző területek között
  • Interfészek a hálózaton kívüli fájlokhoz
  • Visszafelé kompatibilis interfészek

    • Régi protokollok, néha régi kódok és könyvtárak, és nehezen kezelhető és nehezen tesztelhető több verzió
  • Egyéni alkalmazások programozási interfészei (API-k)
  • Biztonsági kód

    • Kriptográfia, hitelesítés és engedélyezési munkamenet-kezelés

Ennek a koncentrált megközelítésnek köszönhetően biztos lehet benne, hogy ha létező kódot alkalmaznak, ha a magas kockázatú területeket egy biztonságos architektúra támogatásával kezelik, akkor a rendszer egésze megfelelő módon biztonságossá tehető anélkül, hogy igénybe vehetné az összes komponens átírását .

Biztonságos és biztonságos alkalmazáskód fejlesztés
A szoftverfejlesztés hagyományos megközelítése általában reaktív: Fejlesztse a szoftvert, majd használjon penetrációt, fuzz-ot és funkcionális tesztet a gyengeségek felfedéséhez. Hasznos azonban, hogy ez önmagában nem elegendő ahhoz, hogy megfeleljen egy olyan funkcionális biztonsági szabványnak, mint például az ISO 26262 szabványnak. Ez a szabvány implicit módon előírja, hogy a biztonsági vonatkozású biztonsági tényezőket kezdettől fogva figyelembe kell venni, mert egy biztonsági kritikus rendszer nem lehet biztonságos ha nem biztonságos.

A közös V-modell hasznos ebben a tekintetben. Ez a modell mind az ISO 26262 szabványt, mind a szerszámokat az egyes fázisban valószínűleg alkalmazza a mai kifinomult és komplex autóipari szoftverek fejlesztésében ( 1 . E cikk alkalmazásában ez a modell hivatkozik arra, hogy miként befolyásolja a biztonsági szempontok bevezetése az egyes fázisokat. Ne feledje, hogy más folyamatmodellek, mint az agilis és a vízesés is egyformán jól támogatható.

1. ábra: Szoftverfejlesztés V-modell az ISO 26262-re és szabványos fejlesztőeszközökkel.

A rendszertervezés fázisának (balra fent) termékei a technikai biztonsági követelményeket finomították és hardverekre és szoftverekre osztották fel. Egy kapcsolódó rendszerben ezek számos biztonsági követelményt tartalmaznak, mivel az egyes biztonsági szempontokat veszélyeztető biztonsági kérdések kezeléséhez szükséges intézkedéseknek arányosnak kell lenniük a kockázattal. A követelések és a későbbi fázisok termékei közötti nyomon követés fenntartása általában egy projektmenedzsment fejfájást okoz.

A szoftverbiztonsági követelmények meghatározása magában foglalja a rendszertervezésből való kivezetést, a szoftverspecifikus elemek elkülönítését és az alsóbb szintű, szoftverrel kapcsolatos követelmények evolúciós folyamatának részletezését, beleértve a biztonsági elemekkel rendelkezőket is.

Következő lesz a szoftver építészeti tervezési fázis, talán UML grafikus ábrázolás. A statikus elemzési eszközök segítenek a kódkomponensek kapcsolatának grafikus ábrázolásával a tervezett tervezéshez képest ( 2 .

2. ábra: A statikus elemzési eszközök grafikai ábrázolást nyújtanak a kódkomponensek közötti kapcsolatnak a tervezett tervezéssel való összehasonlításhoz - ebben az esetben a Control és az adatáramlás között.

Az ISO 26262-6: 2011-es tábláról a szoftveregység tervezésével és kivitelezésével kapcsolatos táblázat jellemző példája látható ( 3 . Megmutatja a végrehajtás során végrehajtandó kódolási és modellezési iránymutatásokat, és feltünteti, hogy a megfelelés megerősíthető-e automatizált eszközök segítségével.

3. ábra: ISO 26262 kódolási és modellezési irányelvek.

A "nyelvi alcsoport használata" (a táblázat 1b. Témája) példázza a biztonsági szempontok hatását a folyamatra. A nyelvi alosztályokat hagyományosan a biztonság támogatásaként tekintették, de a MISRA C: 2012 szabvány és a biztonsággal kapcsolatos szabványok - például a közös gyengeségfelmérés (CWE) - biztonsági fejlesztései egyre nagyobb érdeklődést mutatnak a biztonsági kérdések elleni küzdelemben betöltött szerep iránt . Ezeket statikus elemzéssel is lehet ellenőrizni ( 4 .

4. ábra: A MISRA C: 2012 szabvány és biztonsági specifikus szabványok, például a közös gyengeségfelmérés (CWE) biztonsági javításainak kódolási szabványainak megsértése statikus elemzéssel ellenőrizhető.

Dinamikus elemzési technikák (amelyek magukban foglalják a kód egy részének vagy egészének végrehajtását) alkalmazhatók az elemek integrációjára és tesztelésére . Az elemek tesztelését úgy tervezték, hogy külön szoftveres eljárásokra vagy funkciókra fókuszáljon, miközben az integrációs tesztelés biztosítja a biztonsági, a biztonsági és a funkcionális követelményeket, amikor az egységek a szoftver építészeti tervével összhangban dolgoznak ( 5 .

5. ábra: Tesztvizsgálati interfész, amely bemutatja, hogy a szoftver interfész mennyiben jelenik meg a funkciókörben, így a felhasználó bemeneti és várt kimeneteket adhat a tesztháló alapjainak.

Egy jó teszteszköz-készletben a szoftver interfész a funkciókörben látható, lehetővé téve a felhasználó számára bemeneti és várt kimenetek bevitelét. Ezt a kábelköteget azután összeállítják és végrehajtják a cél hardveren, és összehasonlítják a tényleges és várható kimeneteket. Az ilyen technika nemcsak a funkcionális, biztonsági és biztonsági követelményeknek megfelelő funkcionális korrektúrát, hanem a határállapotok, a nullmutatók és az alapértelmezett átkapcsolási esetek - az összes fontos biztonsági szempont - rugalmasságát is szolgálja.

Amellett, hogy kimutatja, hogy a szoftver megfelelően működik, dinamikus elemzést használnak a strukturális lefedettségi mutatók létrehozásához. A CWE biztonsági szabvány megköveteli, hogy a kódfedés-elemzést használják annak biztosítására, hogy ne legyen rejtett funkció, amely potenciálisan növeli az alkalmazás támadó felületét és gyengítéseket.

A végtelen fejlesztési életciklus kezelése
A kétirányú nyomon követés elve az egész ISO26262 V-modellen fut, minden fejlesztési fázisban ahhoz, hogy pontosan tükrözze az előtte álló egységet. Elméletileg, ha a szabvány pontos sorrendjét betartják, akkor a követelmények soha nem változnak, és a tesztek soha nem okoznak problémát. De az élet nem olyan.

Például könnyű elképzelni ezeket a folyamatokat, mivel ezek egy "zöldmezős" projekthez kapcsolódnak. De mi van, ha szükség van sok különböző alrendszer integrálására? Mi van, ha ezek közül néhány már létezik, és a követelmények igen eltérő formában vannak meghatározva? Mi lenne, ha ezeknek a rendszereknek egy része elszigetelt rendszert feltételezve nem biztonságos? És mi van, ha a különböző alrendszerek különböző fejlesztési fázisokban vannak?

Aztán ott van a követelményváltozások kérdése. Mi van, ha az ügyfél szíve megváltozik? Világos ötlet? Tanácsadás az ügyvédtől, hogy a meglévő megközelítések problémásak lehetnek?

Amennyiben változások válnak szükségessé, a felülvizsgált kódot statikusan újra kell elemezni, és minden hatással lévő egység- és integrációs tesztet újra kell indítani (regresszió tesztelés). Bár ez egy projektmenedzsment rémálmát eredményezhet abban az időben, egy elszigetelt alkalmazásban, addig hosszabb ideig tart, mint a termék fejlesztése.

A kapcsolat megváltoztatja mindezt. Amikor új sérülékenységet fedeznek fel, akkor az ennek eredményeképpen megváltozik a követelmény, hogy biztosítsák, és ezzel párhuzamosan tudni kell, hogy a gyors reagálás kritikus fontosságú lehet, ha a termékek nem lesznek veszélyeztetve a területen.

Az automatizált kétirányú nyomonkövethetőség összeköti a különböző forrásokból származó gazdagság követelményeit a tervezés, a kód és a tesztelésig. A követelményváltozások - vagy valójában a sikertelen vizsgálati esetek - hatása hatáselemzéssel értékelhető és ennek megfelelően foglalkozik. A műtárgyak pedig automatikusan regenerálódhatnak az ISO 26262 szerinti folyamatos megfelelés bizonyítékául ( 6 .

Egy hagyományos, elszigetelt rendszer kifejlesztése során, amely egyértelműen elég hasznos. De a kapcsolat igényli a biztonsági rések megválaszolásának képességét, mivel az újonnan felfedezett sebezhetőségek egy megváltozott vagy új követelményt jelentenek, és azonnali válaszra van szükség - annak ellenére, hogy a fejlesztői mérnökök egy ideig nem érintik a rendszert. Ilyen körülmények között, hogy képesek elszigetelni a szükséges adatokat, és automatikusan csak a végrehajtott funkciókat tesztelni, sokkal fontosabbá válik.

6. ábra: Az automatizált kétirányú nyomon követhetőség összeköti a különböző forrásokból származó gazdagság követelményeit a tervezésig, a kódolásig és a tesztelésig.

Következtetés
A beágyazott autóipari rendszer olyan technológiáktól függ, mint a biztonsági edzett operációs rendszerek, a hypervisorok, az elválasztó kernelek és a rendszerindító képintegritás-ellenőrzés. Ezek a technológiák nemcsak többszintű védelmet kínálnak az agresszorokkal szemben, de kölcsönösen támogató módon is használhatók fel, hogy bemutathassák a veszélynek megfelelő védelmi szintet.

Az ilyen fejlesztés során létező eszközök és technikák alkalmazhatók olykor, például biztonságos kódolási szabályok esetén, amelyek kiegészítik azokat, amelyek biztonsági hangsúlyt helyeznek. Egyes technikák, például a lefedettségi elemzés, pontosan hasonló megközelítést alkalmaznak, és ennél lényegesen eltérő célt szolgálnak - ideértve a további "hátsó ajtók" kód hiányát is.

A követelmények, tervek, kódok és tesztek közötti kétirányú nyomon követés az ISO 26262 alapkövetelménye, és automatizálása jelentősen megóvhatja a projektmenedzsmentet. Az ilyen automatizált nyomon követhetőség jelentősége fokozódik, ha a biztonság megsértése hatással lehet a projektekre vonatkozó új követelményeknek a termékbevezetést követően. Ilyen körülmények között a gyors reagálás a követelmények változásaira képes mind az élet megmentésére, mind pedig a hírnév javítására.