Megakadályozza a szoftver sebezhetőségét a kereskedelmi alkalmazásokban?

Ahogy a vállalatok előrehaladnak az agilis fejlesztés világában, egyre inkább saját alkalmazásokat készítenek. Ezek az alkalmazások egy sereg sebezhetőséget tartalmazhatnak, amelyek ha nem foglalkoznak velük, összeomolhatják az üzletet. De mi a helyzet a kereskedelmi alkalmazásokkal – ERP- vagy CRM-rendszerekkel, adatbázisokkal, irodai hatékonyságnövelő csomagokkal vagy számlázószoftverekkel? Noha megnyugtató belegondolni, hogy ezek a bevált gyártók a szoftveres sebezhetőségek megelőzésére összpontosítanak, sérülékenységek előfordulnak. Egyes esetekben az ügyfelek fizethetik az árat.

Mik azok a szoftver sérülékenységek?

Magas szinten a szoftversérülékenység olyan hiba vagy gyengeség, amelyet a rosszindulatú felek kihasználhatnak. Ezek a támadók a biztonsági rés segítségével hozzáférhetnek egy szervezet érzékeny adataihoz, vagy jogosulatlan műveleteket hajthatnak végre. Egyetlen szoftver sem védett a sebezhetőségekkel szemben; a kulcs az, hogy a lehető leghamarabb megtaláljuk és helyreállítsuk őket.

A Microsoft tökéletes példa erre. Hatalmas szoftver ökoszisztémával rendelkezik, amelyet a legtöbb vállalat használ világszerte. A Microsoft szoftvertermékeinek széles skálája azt jelenti, hogy a sebezhetőségek elkerülhetetlenek. Egy friss a BeyondTrust kutatása megállapította, hogy a Microsoft 1212 sebezhetőséget jelentett az elmúlt évben, ami valójában teljesen normális a tanfolyam szempontjából.

A Microsoft-szoftverek mindenütt jelenléte is elsődleges célponttá teszi. “Ha támadó vagyok, és a legjobb esélyt akarom elérni a sikerre anélkül, hogy sokat tudnék a szervezetről, akkor feltételezem, hogy a Microsoft technológiáit használja” – mondta. John Fung, a MorganFranklin Consulting kiberbiztonsági műveletekért felelős igazgatója. “Ha ki tudsz használni valamit a Microsofton, akkor a támadási felületed vagy a lehetséges célpontok listája exponenciálisan megnő.”

Hogyan keletkeznek szoftveres sebezhetőségek?

A sérülékenységek számos módon bejuthatnak a szoftverbe, egyesek a szoftvergyártó, mások pedig a felhasználó hibája.

A gyártói oldalon az új funkciók bevezetése integrációs hibákhoz, valamint általános hibákhoz és hibákhoz vezethet, míg a frissítések konfigurációs hibákat, valamint engedélyeket és hozzáférési sebezhetőségeket okozhatnak. Ezen hibák bármelyike ​​biztonsági kockázatokhoz vezethet, a jogosultságok kiszélesítésétől és a biztonsági funkciók megkerülésétől az információ nyilvánosságra hozataláig, szolgáltatás megtagadása, hamisítás, hamisítás vagy harmadik fél kódjának végrehajtása. A BeyondTrust vizsgálat számos távoli kódfuttatási biztonsági rést talált a Microsoft Exchange Server, a Windows DNS Server és a Microsoft Defender for IoT rendszerben.

De mi a helyzet az olyan következetes frissítésekkel és eseményekkel, mint a Patch Tuesday, minden hónapban egy meghatározott nap, amikor a Microsoft kiadja biztonsági megoldásait? Ezek fontosak, de csak a helyszíni szoftverekre vagy a privát felhőkben futó szoftverekre vonatkoznak. Nem vonatkoznak az egyre elterjedtebb szoftver, mint szolgáltatás modellre.

Kevesebb útmutatás van a szoftver használatára vonatkozóan foltozva vagy a felhőben kijavított sebezhetőségeket, és nem szabványos jelentési módszert a felhőalapú szoftverek sebezhetőségére vonatkozóan – mondta Morey Haber, a BeyondTrust biztonsági igazgatója.

„A felhőben a szoftvereket folyamatosan javítják, és gyakran kénytelenek ragaszkodni az aktuális kiadáshoz” – mondja Haber.

Egyes szállítók, például a ServiceNow, lehetővé teszik a szervezetek számára, hogy a régebbi verziókon maradjanak az integrációval vagy speciális API-kkal kapcsolatos problémák miatt, de ez más problémákat is okozhat. Haber megjegyezte, hogy a szervezetek például elveszíthetik a sebezhetőségek nyomát, ha elkerülik a frissítést.

Bízzon, de ellenőrizze

A felhőalapú környezetben sok más felelősséghez hasonlóan a kereskedelmi szoftverek szoftveres sebezhetőségei is megosztott felelősséggé válnak. Természetesen magának a szoftverszállítónak van az elsődleges felelőssége, de a felhasználói szervezetek bevonása nélkül a potenciális kockázatok megnőnek.

„Sok olyan cég van megteheti” – mondta Elizabeth Butwin Mann, az EY Americas kiberbiztonsági tanácsadó vezetője. „A kiberfenyegetéseket és a sebezhetőséget annak az üzleti modellnek a részének kell tekinteni, amelyben ma mindannyian működünk. A környezet természete, amelyben vagyunk, sebezhető pontokhoz vezet.”

Egy fontos lépés, amelyet az IT-szakemberek megtehetnek a sebezhetőségek kiküszöbölése érdekében, az ellenőrzés potenciális szállítók és szoftverek, mielőtt megnyomná a “vásárlás” gombot. Fung azt javasolta, hogy kérdezzék meg a beszállítókat, hogy rendelkeznek-e biztonságos szoftverfejlesztési életciklus (SSDLC) programmal. Az SSDLC programokban a kódot tesztelik, mielőtt véglegesítik.

Az is nagyon fontos, hogy mindent tudjunk a szállító jelentéskészítésre és javításra vonatkozó szolgáltatási szintű szerződéseiről (SLA), arról, hogy mit használnak a háttérkód integritásának biztosítására, használnak-e egyszeri bejelentkezést, és használnak-e SOC 2.-t. tanúsítvány. Ezek az alapok. “CISO-ként nem fogok felhőmegoldást használni, kivéve, ha az alap a helyén van, és egy független könyvvizsgáló nem ellenőrzi” – mondta Fung.

SLA-jukban a szoftvergyártók általában kötelezettséget vállalnak arra, hogy a sérülékenység felfedését követő 30, 60 vagy 90 napon belül kijavítják a biztonsági rést. Ugyanakkor számos szoftverszerződésben szerepel a korlátozott felelősség, ami alapvetően azt jelenti, hogy a beszállítók mindent megtesznek a problémák megoldása érdekében, de nem vonhatók felelősségre, ha kellő gondossággal jártak el.

Az ügyfeleknek azt is tudniuk kell, hogy egy szoftvergyártó hány sebezhetőséget tárt fel az elmúlt években. Ha az eladó sok sebezhetőséget tárt fel, az rendben van – mondta Haber. Ez jobb, mint semmit sem nyilvánosságra hozni, ami lehet piros zászló.

De a legnagyobb gyártók közül néhány, köztük a Microsoft, szűkszavúan beszél a sebezhetőségekről. A piaci tapadásuk miatt keveset tehetsz ellene.

A nagyobb beszállítóknak azonban minden érdekükben áll, hogy ez megfelelő legyen. Fung az Atlassian példájára mutatott rá, aki májusban tapasztalta a Confluence Server és az adatközponti szoftverek nyilvános kihasználását. A sebezhetőséget felfedező kutatók jelentették az Atlassiannak, aki megpróbálta gyorsan orvosolni a problémát. „Tudták, hogy mielőbb meg kell oldaniuk a problémát, mert ha nem teszik, az emberek nem bíznának abban, hogy információ- és tudástáraik nagyobb biztonságban vannak” – jegyezte meg Fung.

Vizsgálja meg, értékelje és kezelje a szoftver sebezhetőségeit

Tehát hogyan kerülheti el a vállalat a szoftverek sebezhetőségét, amikor kereskedelmi szoftverekkel foglalkozik? Adjon hozzá néhány saját eszközt és óvintézkedést, mondták a szakértők.

Használjon legalább egy hatékony sebezhetőség-ellenőrző, -felmérő és -kezelő eszközt a sérülékenységek megtalálásához, rangsorolásához és kijavításához. Termék a funkcióknak tartalmazniuk kell a következőket:

  • Dinamikus felfedezés és leltár
  • Eszköz láthatósága
  • A biztonsági intézkedések prioritása
  • A támadási vektorok széles körű lefedettsége
  • Valós idejű megfigyelés
  • A gazdagép erőforrások rendszerezésének képessége
  • A kontextus és az üzleti kockázat megértésének módja

A sebezhetőség megelőzésére szolgáló eszközök közé tartozik a CrowdStrike Falcon, a ManageEngine Vulnerability Manager Plus, a Nessus Professional és Paessler PRTG hálózati monitor.

“Azt várjuk ügyfeleinktől, hogy saját sebezhetőségi felmérést szeretnének végezni, mert ha azt mondják, hogy ez a probléma vagy az eladó felelőssége, az nem segít, ha Önt feltörik” – mondta Mann, az EY America munkatársa. – Folyamatosan számos új eszköz kerül bevezetésre, amelyek segíthetnek.

Egy másik hasznos eszköztípus a felhőalapú hálózati alkalmazásvédelmi platformok (CNAPP). A CNAPP-ok biztosítják, hogy ne lehessen privilegizált fiókokat létrehozni, ne legyenek rosszindulatú API-hívások, és a postafiókok ne kapjanak külön engedélyt a letöltésekhez. Ezek az olyan gyártók termékei, mint a Zscaler, Orca, Aqua Security és Lacework, jó munkát végeznek a szoftverek sebezhetőségeinek, engedélyeinek és hibás konfigurációinak ellenőrzésében. Ezenkívül a CNAPP-ok megtalálhatják az elavult könyvtárakat, amelyek sebezhetőek lehetnek. Haber a CNAPP-ot a ma elérhető egyik leginkább feltörekvő felhőalapú munkaterhelés-védelmi lehetőségnek nevezte.

Végül ott van a Cloud Infrastructure Rights Management (CIEM). A CIEM megvizsgálja a jogosultságokat és engedélyeket annak biztosítására, hogy a rendszerek ne legyenek túlzsúfolva, vagy hogy a rosszindulatú felek útvonalat vagy rendszergazdai fiókot hozzanak létre a rendszer kihasználásához.

További módszerek a szoftversérülékenységek megelőzésére

Az informatikai szakemberek számos egyéb lépést is megtehetnek a sebezhetőségek csökkentése érdekében.

Szánjon időt a frissítésre és javításra – és tegye meg azonnal.

Még ha ez csekély leállást is jelent, megéri – mondta Haber.

Futtassa saját eszközleltárát, beleértve az integrációkat is.

“Sok cég azt sem tudja, milyen szoftverrel rendelkezik, és nem érti a különböző alkalmazások üzleti stratégiában betöltött fontosságát” – mondta Mann.

A helyzet még bonyolultabbá válik, ha alkalmazkodással, bővítéssel és integrációval állunk elő, de az ökoszisztémákban mindezek a kapcsolatok törékenyek – tette hozzá.

Korlátozza a felhasználói hozzáférést és funkciókat.

Minél kevesebb hozzáférést engedélyez, annál kevesebb hiba történhet. Az Active Directory jó példa erre. “Ha tudja, mit akar elérni, és elég jól ismeri az eszközt, vagy professzionális szolgáltatásokat vesz igénybe, hogy csak ezt a funkciót tegye lehetővé, akkor drasztikusan korlátozza a támadási felületet” – mondta Fung.

Ez magában foglalja az adminisztrátori jogosultságok eltávolítását és a legkevesebb jogosultság érvényesítését, amelyek mindkettő kritikus fontosságú a támadási felület csökkentése szempontjából. Az adminisztratív jogok eltávolítása ma már gyakran követelmény a kiberbiztosítási szolgáltatók számára, és ez a zéró bizalom elveinek megfelelő ellenőrzés.

Törölje a root fiókokat.

Például a root fiókja az AWS-ben az egyetlen olyan fiók, amely kritikus funkciókat hajt végre. Még az AWS is azt javasolja, hogy hozzon létre egy másik rendszergazdai fiókot, és távolítsa el a root fiókot. “Ha egy fenyegetett szereplő root vagy privilegizált rendszergazdai fiókot kap, akkor a játéknak vége” – mondta Haber.

A szoftversebezhetőség-megelőzés jövője

Idővel az iparág valószínűleg szabványokat fog kidolgozni a felhőalapú szoftverek sebezhetőségeinek azonosítására és orvoslására, amelyek hasonlóak a helyszíni szoftverekhez. És még éppen időben lesz: szoftverként bonyolultabbá és kölcsönösen függővé válik a különböző könyvtárakban, valószínűleg több sebezhetőség jelenik meg.

Az informatikai szakembereknek egyelőre még a legnagyobb szoftvergyártókat is jobban meg kell vizsgálniuk, és alkalmazniuk kell a saját fékeiket és ellensúlyaikat.

A szerzőről

Karen D. Schwartz technológiai és üzleti író, több mint 20 éves tapasztalattal. Számos technológiai témában írt publikációkhoz, beleértve a CIO-t, az InformationWeeket, a GCN-t, az FCW-t, a FedTech-et, a BizTech-et, az eWeek-et és a kormányzati vezetőt.

Leave a Comment

%d bloggers like this: