Mellékleteink: HUP | Gamekapocs
Keres

Mit várhatunk el az etikus hackerektől?

Bodnár Ádám, 2014. március 28. 08:05
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

Magyarországon is egyre több cég rendel etikus hackelés szolgáltatást, vagyis az általa fejlesztett alkalmazások vagy az üzemeltetett rendszerek biztonsági tesztelését. A terület körül azonban sok a kérdőjel továbbra is, a megrendelők nem mindig tudják, mit várjanak és mit várhatnak el a független biztonsági ellenőrzés során, derült ki a Silent Signal szerdai eseményén.

A Silent Signal szerdai szakmai délutánján elhangzottak alapján Magyarországon sok megrendelő még tapasztalatlan és felkészületlen, ha etikus hackelésről, biztonsági "önellenőrzésről" van szó. Ennek egyik oka, hogy a terület viszonylag új, nincsenek még bejáratott módszerek, évtizedes praktikák egy ilyen projekt megtervezésével és kivitelezésével kapcsolatban, másfelől viszont vannak olyan biztonsági cégek, amelyek "dobozos termékként" próbálják meg eladni az etikus hackelést, "darabáron".

Nem dobozos termék, hanem szolgáltatás

Egyre többen ismerik fel az etikus hackelés fontosságát, és látják be, miért érdemes egy elkészült alkalmazást, egy új informatikai infrastruktúrát, vagy akár a dolgozók biztonságtudatosságát független szakértővel ellenőriztetni. A Silent Signal hazai piacon szerzett több éves tapasztalatai szerint azonban a megrendelők nem mindig tudják, pontosan mit akarnak, mit várhatnak el a hackerektől és velük szemben milyen elvárásai vannak a biztonsági cégnek. Szabó Péter, a Silent Signal ügyvezetője példaként említette, amikor egy komplex, átfogó sérülékenységvizsgálatra a megrendelő egy pár soros levélben, részletek teljes mellőzésével kért árajánlatot.

A biztonsági cég szerint az ügyfelek gyakran nem specifikálják egyértelműen, pontosan milyen rendszereket szeretnének ellenőriztetni - az ajánlatkérés és -adás gyors lebonyolítását nagyban segíti, ha az ajánlatkéréskor a vevő minél több műszaki részletet megoszt, illetve az ellenőrzéssel kapcsolatos elvárásait is egyértelműen közli (pl. blackbox vagy greybox tesztelés). Gyakran a megbízó "mindennek" szeretné a külső biztonsági auditját,de olyan is előfordul, csak a webes alkalmazásokat szeretné megvizsgáltatni, arra hivatkozva, hogy máshová egy hacker kívülről úgysem tud behatolni - ez persze tévedés.

Az se ritka, hogy a vállalat nincs tisztában saját infrastruktúrájával, például megrendeli 30 szervernek a biztonsági auditálását és a projekt közben derül ki, hogy valójában ennél jóval többel rendelkezik, mondta el Szabó Péter, a Silent Signal vezetője. Mint minden projektnél, az etikus hackelésnél is fontos az alapos tervezés: a megrendelőnek legalább annyira fel kell készülnie a saját rendszereiből mint az etikus hackelést végző csapatnak, mivel az utóbbinak szinte biztosan lesz egy sor kérdése  - ezek egy része azért, mert a biztonsági vizsgálatot végző cég szakemberei "külsősök", és nem ismerhetik azokat a rövidítéseket, amelyek a cégnél használatosak és például egyes rendszerfunkciókat takarnak.

Az etikus hackelés szolgáltatást kérő csapatnál szükséges egy erős kezű projektvezető, aki keresztül tudja vinni az akaratát és meg tudja értetni a céggel, illetve a dolgozókkal, hogy az etikus hackelés miért fontos, illetve azzal is tisztában van, hogy a vizsgálat "fájni fog", hiszen fény derülhet rosszul megválasztott vagy rosszul implementált rendszerekre, fejlesztői vagy üzemeltetői hibákra, vagy akár az alkalmazottak hiszékenységére - nem is gondolnánk, mennyire egyszerű az irodai dolgozóktól munkahelyi jelszavakat kicsalni, ha egy iPadet lengetünk be nekik húsvéti ajándékként.

Persze a megrendelő ennek megfelelően támasszon elvárásokat a biztonsági csapattal szemben is. Ha az etikus hackelést végző cég nem rendelkezik referenciákkal, a szakemberei híján vannak a releváns minősítéseknek, ha a projekt előtt nem készül részletes terv a felhasznált eszközökről, módszertanokról, ütemezésről, jobb ha azonnal más biztonsági szakértőt keresünk. Azt sem árt tudni, pontosan ki végzi el a behatolási teszteket - ha a megbízott cég például alvállalkozónak ad ki egyes feladatokat, az jogi, titoktartási, bizalmi szempontból mindenképp kérdéseket vet fel, amelyeket tisztázni kell.

Ne a fióknak készüljön a jelentés!

Az etikus hackelés eredménye egy részletes dokumentáció, amely a feltárt sérülékenységeket és az azokra adott megoldási javaslatokat tartalmazza, legalábbis jó esetben - rossz esetben pedig egy szoftver által generált lista a különféle sebezhetőségekről. A jelentés tartalmát már a szolgáltatás megrendelésekor érdemes meghatározni, hogy a biztonsági ellenőrzést végző csapat ne csak egy szimpla Nessus-riportot adjon át a megrendelőnek, hanem a fejlesztők vagy üzemeltetők számára valóban alkalmazható információkat a biztonság növeléséhez.

Ehhez persze arra is szükség van, hogy a biztonsági önellenőrzést kérő cég a változtatásokat meg is rendelje, például a szoftver fejlesztőjétől vagy az üzemeltetői csapattól, és a javítás elkészülte után ellenőrizze, valóban befoltozták-e a megtalált sebezhetőségeket. "Nem a jelentés a termék, hanem annak a tartalma", fogalmazott Szabó Péter. "A hibákkal kezdeni is kell valamit, a legnagyobb hiba, ha nem kezdünk velük semmit." A javítások utólagos visszaellenőrzése ugyanolyan fontos része a projektnek mint maga az etikus hackelés, hiszen ha a megtalált hibákat mégsem sikerült javítani, az egész teszt felesleges volt.

Szabó Péter szerint érdemes elgondolkodni azon, biztos megfelelő fejlesztővel dolgozunk-e együtt, ha a kért javítás sokadszorra sem működik, vagy ha a javítás ideje irreálisan hosszú - a biztonsági cég szakemberei jó becsléssel meg tudják mondani, a talált sebezhetőséget javítani mennyi idő. Ha a kód fejlesztője csak külön díjért hajlandó kijavítani az általa készített program biztonsági sebezhetőségét, akkor is érdemes gondolkodóba esni: biztosan jó a szerződéses konstrukció?

A biztonsági önellenőrzést persze nem elég egyszer elvégezni, hanem érdemes rendszeresen ismételni - az IT gyorsan fejlődik és olyan új támadások is feltűnnek, amelyekre korábban senki sem gondolt. Önbecsapás azt hinni, hogy a 3 éve biztonságosnak talált, feltörhetetlennek bizonyult rendszer továbbra is biztonságos, mint ahogy azt is botorság hinni, hogy ha az egyik etikus hacker nem talált semmit, akkor a másik sem fog. A rendszeres biztonsági önaudit egy tanulási folyamatként is felfogható a megrendelő számára, amelynek során a fejlesztők és üzemeltetők is fejlődnek, miközben a rendszer is egyre biztonságosabbá válik.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.