Az ellátási lánc támadások megelőzése
Nagyon érdekes és hasznos cikket jelentettet meg David A. Wheeler, a Linux Alapítvány (Linux Foundation) ellátási lánc biztonságáért felelős igazgatója, amelyben elmagyarázza a SolarWinds jellegű támadások okait, és javaslatot tesz arra, hogyan lehetne megelőzni az ilyen támadásokat. A folyamat nem egyszerű, sőt jelentős idő és anyagi ráfordításokat igényel, de David A. Wheeler abból indult ki, hogy az Orion-nál alkalmazott eljárások ma a szoftverfejlesztési iparágban bevett gyakorlatokat tartalmaznak, így bármely fejlesztőnél – akik „blackbox” termékeket forgalmaznak – előfordulhatnak.
A jelenlegi szabványok és biztonsági ajánlások ma is azt tartalmazzák, hogy a felhasználó csak a gyártó tanúsítványával aláírt terméket telepítse, frissítsen a legújabb verzióra, monitorozza a szoftvereit, ellenőrizze a forráskódot. Ezek a javaslatok mind bedőltek a SolarWinds támadás során, hiszen a kiadott patchek aláírtak voltak, a legújabb verzió alapjaiban kártékony kódot tartalmazott, a támadás során olyan eszközöket használtak, amik nem tömegesen, nagy mennyiségű adat ellopására készültek, hanem lopakodó módban dolgoztak. Végül a forráskód ellenőrzése sem hozhatott volna megfelelő eredményt, hiszen úgy készítették elő a támadást, hogy a fejlesztőknek se tűnjön fel, hogy maga a forráskód korábban módosításra került.
Ami a legfontosabb az eset tanulságai között az az, hogy az Orion nem egy nyílt forráskódú szoftver, hanem egy „dobozos” termék, aminek a forráskódját senki nem ellenőrizheti, csak a SolarWinds fejlesztői tudták ezt megtenni, minden felhasználó csak elfogadta a licensz szerződést és alkalmazta a terméket. Ma már kormányzati tisztviselők is azt javasolják, hogy a fejlesztők a szoftverek kialakítása során alkalmazzák a „zero trust” szoftverfejlesztést.
David A. Wheeler azt javasolja, hogy a fejlesztő cégek változtassanak a szoftver ”gyártási” gyakorlatukon, hiszen bebizonyosodott, hogy az Orion fejlesztése során alkalmazott rossz FTP protokoll és a gyenge jelszavak is hozzájárultak a támadók sikeréhez. A fejlesztési környezetek minden szabvány szerint a legmagasabb biztonsági osztályba tartoznak.
A fő javaslat azonban a hitelesített, megismételhető fejlesztés, amivel megvalósítható, hogy a fejlesztés eredményei ellenőrizhetők legyenek azáltal, hogy független szervezetek forráskódból készítik el a futtatható fájlokat, és egyben ellenőrizhetik az alkalmazott kódokat, forrásfájlokat. Ez ma már könnyen megvalósulhat a nyílt forráskódú termékek esetében. Azonban a nagy operációsrendszerek gyártóinak és szoftverfejlesztőinek; azaz a zárt forráskódú szoftverek fejlesztőinek további kihívásokkal kell szembenézniük: üzleti modelljük ugyanis gyakran függ a forráskód elrejtésétől. Az informatikai ipar már kezd eltávolodik a fekete dobozos (black box) termékektől – amelyeket nem lehet ellenőrizni és ellenőriztetni – a felülvizsgálható termékek felé. Ez már az ipari trend része, csak fel kell gyorsítani a meglévő folyamatot. A szoftvercégeknek ki kell adniuk a kódjaikat és auditorokra van szükségük. Amennyiben ezt nem teszik meg, egyre több olyan támadást fogunk látni, amely kártékony programokat terjeszt.
A megfelelően auditált kódok, szoftverek megakadályoznák az olyan sérülékenységek terjedését is, amit fejlesztők által újrafelhasznált kódok okoznak; olyan kódrészletek, melyek akár már ismert sérülékenységeket tartalmazhat. A leggyakrabban a LF LFX, GitHUb, GitLab tárakból beszerzett kódok függőséget okoznak és a hibákat is tovább terjesztik. Az itt tárolt, már megírt kódokat szintén ellenőrizni kell, hiszen a kereskedelmi szoftverek 99%-a tartalmaz olyan komponenst, forrást, ami az ilyen közösségi tárhelyekről származik. Egy lehetséges megoldásként javasolt olyan forrásjegyzéket (Software Bill of Materials – SBOM) készíteni, ami tartalmazza a más forrásokból beszerzett komponensek jegyzékét, így azonosíthatók az egyes “újrahasznosított” elemek, míg enélkül valóban csak a vállalti fejlesztők tudják, mit is tartalmaz a kódjuk. (Erre több javaslat is létezik, például az Egyesült Államok Nemzeti Távközlési és Információs Igazgatósága (NTIA) javaslata, vagy a Lunux alapítvány Software Package Data Exchange (SPDX) formátuma, amit ma már széles körben alkalmaznak.)