Bug bounty program a Magyar Telekomnál

"A rengeteg jól sikerült vagy jól haladó projekt miatt él az emberekben egy olyan elképzelés, hogy az IT, a fejlesztés és üzemeltetés egy viszonylag jól összefogott, jól átlátható, jól irányított terület, ahol mindenre van hatásunk és mindenről tudunk mindent" - mondja Hári Krisztián a technológiai és kiberbiztonsági vezető a Magyar Telekomnál. A valóság ehhez képest más: egyszerre élhet minden, az ősi, jól bevált, 20 éves módszereink és rendszereink, és mellettük megvannak az új technikáink, a rengeteg új felhő (és felhős kapcsolat) és ezt az egészet próbáljuk valahogyan egyben kezelni. Ez jelentős komplexitást és egyenetlen fejlettségi szinteket hoz a cégen belül.

Új módszerek

A komplexitást sok szempontból kell és lehet kezelni, de az egyik komoly kihívást a biztonság jelenti. Vannak ehhez bevált, szabványos eszközök, például minősítések alapján építeni fel az üzemeltetési folyamatokat, az eredményeket pedig auditálni lehet. És vannak a technikai vizsgálatok - például a penetrációs tesztelés (penteszt), amely az informatikai rendszer biztonságát vizsgálja szimulált támadásokkal. "A penteszt hasznos és jól lehet használni" - mondja Hári, "de komoly korlátai is vannak". A penteszt vizsgálat akkor igazán hatékony, ha pontosan tudjuk, hogy mely rendszereket szeretnénk alaposabban átnézetni, és a teljes céget érintő átfogó tesztelés helyett sokkal hasznosabb, ha szűk területre fókuszálunk. A pentesztelés megrendelésénél arra is oda kell figyelni, hogy ne elégedjünk meg az "alacsonyan lógó gyümölcsök" leszedegetésével, hogy a triviális vagy könnyen felfedezhető hibákon túl a fontosabb (és komolyabb) problémákra is fény derülhessen.

"De mit tegyünk, ha nem szeretnénk időben, költségvetésben, elérhető szaktudásban kötöttségeket?" - teszi fel a kérdést a telekomos vezető. Ilyenkor érdemes elgondolkodni egy bug bounty programon. Ezzel sokkal szélesebb kompetencia-kör érhető el, egy penteszt-cégnél sem ért minden szakember mindenhez, míg a közösségi hibavadászatban nagyobb eséllyel szerepel olyan is, aki az adott rendszereket ismeri behatóbban. Szintén előny, hogy a hibavadászok immár egymással versenyeznek időben, az kap ugyanis elismerést (pénzbelit és szakmait) aki az adott biztonségi hibát elsőként jelenti be. A bug bounty azonban önkéntes tesztelők tömegeit szabadítja a rendszereinkre - a közösség maga fog foglakozni a hibák feltárásával, ezért alapos előkészítésnek kell megelőznie a program meghirdetését. " El kell gondolkozni azon, hogy mik lesznek a játék szabályai?" - fogalmaz Hári.

Alapvető kikötés, hogy továbbra is szimulált támadásokról van szó, tehát sikeres támadás esetén sem szabad adatot lemásolni, törölni, felülírni, a beállításokat vagy a szoftvereket módosítani. Azt is érdemes kikötni, hogy pontosan mire indítjuk el a bug bounty programot, mely rendszerek számítanak támadható célpontnak, és melyeket zárunk ki a programból. Ettől függetlenül minden hibajelentést kezelni kell, de a korlátok megállapításával mégis lehet fókuszáltan folytatni a közösségi hibakeresést.

Azt is le kell szögezni, hogy milyen formai-tartalmi feltételeknek kell megfelelnie a bejelentésnek. Itt nyilván az a cél, hogy az üzemeltető és fejlesztő csapat számára hasznos, értékes bejelentések érkezzenek, amelyek könnyen feldolgozhatóak, megismételhetőek, és cselekvéssé, javítássá konvertálhatóak. Így érdemes bekérni a reprodukálás lépéseit részletesen. És végül a legfontosabb: egyértelművé kell tenni, hogy aki a játékszabályok szerint játszik, azt nem érheti semmiféle retorzió - függetlenül attól, hogy a szimulált támadása sikeres volt-e. Tehát a program résztvevőit a "megrendelő" nem fogja feljelenteni, és nem tesz egyéb jogi lépéseket sem.

Számítson a befektetett munka!

A kizárásra is érdemes nagyon odafigyelni - néhányan (nem a Telekom) már járták meg, hogy automatizált eszközökkel lefuttatott tesztekre sok tízezer dollárt kellett feleslegesen kifizetniük, mivel bizonyos rendszereket és módszereket nem zártak ki a programból. Szerintünk érdemes kizárni a DoS-támadásokat (amelyek egyébként a "ne okozz kárt" kitételen is elbuknak), az amúgy veszélytelen alapinformációkat (például szoftververziót) szolgáltató találatokat, a social engineering típusú támadásokat, vagy épp a brute force jellegű töréseket - ezeket is kezeljük persze, de nem ennek a programnak a keretében akarunk ezzel foglakozni - mondja Hári.

A kizárás mellett tegyünk közzé egy olyan listát is, amire igenis kiváncsiak vagyunk: távoli kódfuttatást lehetővé tévő hibák, XSS-jellegű hibák, SQLi és code injection hibák, bejelentkezés átlépése (authentication bypass), és a legfontosabb, a felhasználó adatok szivárgása. Ezek olyan problémák, amelyekkel valódi, komoly hatása van, amivel komoly üzleti károkat lehet okozni - és ami mögött munka van. Az automatizált eszközökkel generált jelentések ebből a szempontból a legkevésbé érdekesek, ezeket a cég hatáskörben is le tudja futtatni vagy meg tudja rendelni külső féltől, a bug bountyt így érdemes más területre fókuszálni. Ez segít a közösségnek is eligazodni, hogy ha ezekre a hibákra koncentrál, akkor szinte biztosan honorálni fogjuk az erőfeszítését.

Erre fel kell készülni

A másik oldalon pedig erre a szervezetnek fel kell készülnie a bug bounty program megfelelő kezelésére. Ki kell jelölni a megfelelő csapatot, amely a bejelentéseket kezeli, a bejelentőkkel kommunikál, a hibákat validálja, reprodukálja, szervezeten belül kiosztja a javítás feladatát és végül ellenőrzi azt. Csak így lehet ugyanis garantálni, hogy a program sikeres lesz és a felfedezett hibákért nem csak a "fejpénzt" fizetjük ki, hanem valóban biztonságosabb infrastruktúrát is üzemeltetünk végül.

Érdekelne mindez belülről? Nézd át a Magyar Telekom állásajánlatait.

[A Magyar Telekom megbízásából készített anyag]