A biztonsági ipar összességében elveszti az eszét, amikor új biztonsági réseket fedeznek fel a szoftverekben. Az OpenSSL sem kivétel, és 2022 október végén és november elején két új sebezhetőség borította el a hírfolyamokat. A felfedezés és a nyilvánosságra hozatal csak a kezdete ennek a véget nem érő sebezhetőségi ciklusnak. Az érintett szervezetek kármentesítéssel néznek szembe, ami különösen fájdalmas az informatika frontvonalában lévők számára. A biztonsági vezetőknek hatékony kiberbiztonsági stratégiát kell fenntartaniuk, hogy segítsenek kiszűrni az új sérülékenységek okozta zaj egy részét, felismerni az ellátási láncokra gyakorolt hatásokat, és ennek megfelelően biztosítaniuk kell eszközeiket.
Az ellátási lánc támadásai nem szűnnek meg
Nagyjából egy év alatt súlyos sérülékenységeket szenvedtünk el az összetevők terén, többek között log4j, Tavaszi keretés OpenSSL. A régebbi sérülékenységek kihasználása sem szűnik meg a rosszul konfigurált vagy ismert sebezhető függőségeket használó megvalósításoknál. 2022 novemberében a közvélemény tudomást szerzett egy támadási kampány a Szövetségi Polgári Végrehajtó Hivatal ellen (FCEB), amely egy államilag támogatott iráni fenyegetésnek tulajdonítható. Ez az egyesült államokbeli szövetségi szervezet a VMware Horizon infrastruktúrát futtatta, amely tartalmazta a Log4Shell sebezhetőségét, amely a kezdeti támadási vektorként szolgált. Az FCEB-t egy összetett támadási lánc érte, amely magában foglalta az oldalirányú mozgást, a hitelesítő adatok kompromisszumát, a rendszer kompromittálását, a hálózat fennmaradását, a végpontok védelmének megkerülését és a kriptojackelést.
A szervezetek feltehetik a kérdést: „Miért kell egyáltalán használni az OSS-t?” a sebezhető csomagokból, például az OpenSSL-ből vagy a Log4j-ből származó biztonsági incidensek után. Az ellátási lánc támadásai továbbra is felfelé ívelnek, mert az alkatrészek újrafelhasználása „jó üzleti értelmet” jelent a partnerek és a beszállítók számára. A rendszereket úgy tervezzük, hogy a meglévő kódot újrahasznosítjuk, ahelyett, hogy a nulláról építenénk. Ennek célja a mérnöki erőfeszítések csökkentése, a működési méretezés és a gyors szállítás. A nyílt forráskódú szoftvereket (OSS) általában megbízhatónak tekintik az általuk kapott nyilvános ellenőrzés alapján. A szoftver azonban folyamatosan változik, és problémák merülnek fel a kódolási hibák vagy a kapcsolódó függőségek miatt. A tesztelési és hasznosítási technikák fejlődése révén új problémák is feltárulnak.
Az ellátási lánc sebezhetőségeinek kezelése
A szervezeteknek megfelelő eszközökre és folyamatokra van szükségük a modern tervek biztosításához. A hagyományos megközelítések, mint például a sebezhetőség-kezelés vagy a pont-időben végzett értékelések önmagukban nem képesek lépést tartani. A szabályozás továbbra is lehetővé teheti ezeket a megközelítéseket, ami állandósítja a „biztonságos” és a „megfelelő” közötti különbséget. A legtöbb szervezet arra törekszik, hogy valamilyen szintű DevOps érettséget szerezzen. A „folyamatos” és az „automatizált” a DevOps gyakorlatok gyakori jellemzői. A biztonsági folyamatoknak nem szabad különbözniük. A biztonsági vezetőknek a biztonsági stratégiájuk részeként összpontosítaniuk kell a felépítés, a szállítás és a futási fázisok során:
- Folyamatos beolvasás CI/CD-ben: Törekedjen a felépítési folyamatok biztonságossá tételére (azaz a shift-balra), de vegye figyelembe, hogy nem tudja majd beolvasni az összes kódot és a beágyazott kódot. A balra eltolásos megközelítések sikerét korlátozza a szkenner hatékonysága, a szkenner kimenetének korrelációja, a kiadási döntések automatizálása és a lapolvasó befejezése a kiadási ablakokon belül. Az eszközöknek segíteniük kell a leletek kockázatának rangsorolását. Nem minden felfedezés használható fel, és előfordulhat, hogy a sebezhetőségek nem használhatók ki az architektúrában.
- Folyamatos szkennelés szállítás közben: Alkatrész-kompromisszum és környezeti sodródás történik. Az alkalmazásokat, az infrastruktúrát és a munkaterheléseket a kézbesítés során meg kell vizsgálni, ha a digitális ellátási láncban valami kompromittálódott a nyilvántartásokból vagy adattárakból való beszerzéskor és a rendszerindításkor.
- Folyamatos keresés futás közben: A futásidejű biztonság számos biztonsági program kiindulópontja, és a biztonsági megfigyelés a legtöbb kiberbiztonsági erőfeszítés alapja. Olyan mechanizmusokra van szükség, amelyek képesek összegyűjteni és korrelálni a telemetriát minden típusú környezetben, beleértve a felhő-, konténer- és Kubernetes-környezeteket is. A futásidőben összegyűjtött betekintések visszajelzést kapnak a korábbi összeállítási és szállítási szakaszokról. Identitás és szolgáltatási interakciók
- A futás közben feltárt sebezhetőségek rangsorolása: Minden szervezet küzd azzal, hogy elegendő ideje és erőforrása legyen minden átvizsgálására és javítására. A kockázatalapú rangsorolás alapvető fontosságú a biztonsági programok munkájában. Az internetes megjelenés csak az egyik tényező. A másik a sebezhetőség súlyossága, és a szervezetek gyakran a magas és kritikus súlyosságú problémákra összpontosítanak, mivel úgy ítélik meg, hogy ezek gyakorolják a legnagyobb hatást. Ez a megközelítés továbbra is elpazarolhatja a mérnöki és biztonsági csapatok ciklusait, mert előfordulhat, hogy olyan sebezhetőségeket kergetnek, amelyek soha nem töltődnek be futás közben, és amelyek nem kihasználhatók. A futásidejű intelligencia segítségével ellenőrizze, hogy ténylegesen milyen csomagok töltődnek be a futó alkalmazásokba és infrastruktúrába, hogy megismerje a szervezetet fenyegető tényleges biztonsági kockázatokat.
Mi alkottunk termékspecifikus útmutatás hogy átterelje az ügyfeleket a legutóbbi OpenSSL-őrületen.
A legújabb OpenSSL sebezhetőség és a Log4Shell emlékeztet bennünket a kiberbiztonsági felkészültség és a hatékony biztonsági stratégia szükségességére. Emlékeznünk kell arra, hogy a CVE-azonosítók csak azok az ismert problémák a nyilvános szoftverekben vagy hardverekben. Sok sebezhetőséget nem jelentenek be, különösen a saját fejlesztésű kód gyengeségeit vagy a környezeti hibás konfigurációkat. Kiberbiztonsági stratégiájának figyelembe kell vennie a modern tervezésű, elosztott és változatos technológiát. Korszerűsített sebezhetőség-kezelő programra van szüksége, amely futásidejű betekintést használ a mérnöki csapatok javítási munkáinak prioritása érdekében. Szüksége van fenyegetésészlelési és válaszadási képességekre is, amelyek a jeleket a környezetek között korrelálják a meglepetések elkerülése érdekében.
A szerzőről
.png?width=690&quality=80&format=webply&disable=upscale "Az ellátási lánc kockázatai levertek? Maradjon nyugodt és váljon stratégiaivá!")
Michael Isbitski, a Sysdig kiberbiztonsági stratégiáért felelős igazgatója több mint öt éve kutatott és tanácsot ad a kiberbiztonsággal kapcsolatban. Ismeri a felhőbiztonságot, a konténerbiztonságot, a Kubernetes biztonságot, az API biztonságot, a biztonsági tesztelést, a mobilbiztonságot, az alkalmazások védelmét és a biztonságos folyamatos szállítást. Számtalan szervezetet irányított világszerte biztonsági kezdeményezéseikben és vállalkozásuk támogatásában.
Kutatási és tanácsadói tapasztalata előtt Mike sok kemény leckét tanult meg az IT frontvonalain, több mint 20 éves gyakorlati és vezetői tapasztalatával az alkalmazásbiztonság, a sebezhetőségkezelés, a vállalati architektúra és a rendszertervezés területén.
