Internetes veszélyforrások: van megoldás! (x)

Portfolio

2003. január 16. 09:19

Mi a legjelentősebb probléma?.

P.: Az ügyfélnél hajtjátok végre a teszteket, vagy innen a PwC Biztonsági Laborjából?

A. L.: Az, hogy honnan végezzük a tesztet, az ügyfél igényeitől illetve a teszt jellegétől függ. Kihasználjuk az internet adta lehetőséget és az internet felőli teszteket a budapesti Technológiai Laborunkból végezzük. Vannak olyan tesztek, amiket belülről, azaz az adott cégnél végzünk, ezek tipikusan a belső infrastruktúra tesztek. A diagnosztikai teszteknél ez változó; lehet kívülről és lehet belülről is végezni, ahogy a szükség diktálja. Végrehajtottunk diagnosztikai tesztet tőlünk 2000 km-re lévő rendszeren. Költséghatékony kívülről végezni a teszt jelentős részét. A webes alkalmazások tesztjeit klasszikusan kívülről hajtjuk végre. Ha mondjuk az alkalmazás teszt környezetben van, és az ügyfél nem szándékozik "kinyitni" az internet felé - még akkor sem, ha védett és nem bárki által elérhető terület - elvárhatja, hogy a hálózaton belül teszteljük az alkalmazást. Ilyen célokra vannak dedikált számítógépeink: gyakorlatilag van a Labornak egy mobil része, ami könnyen kitelepíthető és van egy külön rendszer a külső tesztekre.

P.: Külső vagy belső tesztek a gyakoribbak?

A. L.: Ha egy webes alkalmazásról van szó, akkor a támadás majdnem biztos, hogy kívülről érkezik, bár teszteltünk már belső webtartalom-kezelő rendszert. Ha egy bankot kell védenem akkor mindig úgy állunk neki egy tesztnek, hogy vagy az ügyfél meghatározza, honnan mit kell tesztelnünk, vagy kéri a segítségünket, hogy állapítsuk meg, melyek a veszélyforrásai. Történelmileg esetleg az elmúlt időkből tudja, hogy mik voltak a problémák, lehet, hogy magas veszélyforrásnak tartja azt, hogy nagyon kiterjedt fiókhálózata van és a belső veszélyforrás nagy. Lehet, hogy azt tartja nagyobbnak, hogy internetes banki alkalmazást működtet. Ebből kiindulva mondjuk meg azt, hogy mi milyen teszteket javasolunk. Sokszor kérnek fel minket "blind testing"-re, azaz arra, amikor a tesztet minden előzetes információ nélkül kell végrehajtanunk. A kérdésre is válaszolok: többségében külső tesztekre kérnek fel minket.

P.: Mi számít a jelentősebbnek a problémák között, a vírusveszély, a rendszergazdák felkészültsége vagy inkább a hacker támadások?

A. L.: Az Information Security Breaches Survey szerint Nagy-Brittaniában a legkiemeltebb biztonsági incidens az elmúlt 12 hónapban úgy nézett ki, hogy 33%-ukat vírusok okozták. Ez a legmagasabb rész, melyet 19%-kal követ a jogosulatlan hozzáférés bizalmas adathoz, ami már egy belső támadás. Ezután jön 14%-kal a rendszer meghibásodás, adatvesztés és követik 11%-kal a webes hacker támadások, majd 7%-kal az alkalmazott nem megfelelő rendszer használata, ami belső hacker támadásnak minősül. 4% a lopás, adattörlés, és 4% az egyéb kategória. Az okok között jelentős részt tesz ki a vírus és hacker támadások. Megjegyzem a vírusokat is emberek készítik.

Volt olyan esetünk, hogy az ügyfélnek a vírusvédelmi rendszerét kellett emulálnunk, tesztlaborban megfigyelni, hogy egy adott vírusra hogyan reagál a rendszer, de ez nem tipikus. Jelentős gondot jelentenek a weben keresztül terjedő vírusok, trójai programok és ezek egyéb változatai.

P.: Ami engem meglepett az a rendszer meghibásodás. Ez miért ilyen magas (14%)?
Egyáltalán foglalkoztok ezzel a problémával?

A. L.: Rendszer meghibásodások kezelése nem tartozik részlegünk fő profiljába. Előfordult azonban olyan eset, amikor felkértek, hogy segítsek elemezni egy technológiai problémát, ami nem kötődött a biztonsághoz. Az ügyfél problémája az volt, hogy lassan, mintegy 15 perces várakozás után tudtak csak belépni a felhasználók egy rendszerbe, és nem tudták visszanyomozni, hogy mi okozza a problémát. Abban az esetben kifejezetten jól jött egy szakértő, akinek ismeretei voltak a hálózatokban, operációs rendszerekben és a TCP/IP-ben egyszerre. Egy olyan szakértő volt, aki tiszta aggyal rá tudott tekinteni egy ilyen rendszerre, tudta elemezni a problémát és nem utolsó sorban pontosan tudta, hogy a belépés folyamata adott rendszeren hogyan zajlik. Nem tipikus, hogy egy rendszerhiba, vagy abnormális működés esetén a biztonsági szakértőket hívják ki elsőnek. Ez inkább abból adódott, hogy az ügyféllel már olyan kapcsolatot építettünk ki más területen, ami miatt bízott szakértelmünkben. A rendszerhiba egyébként kapcsolódhat támadáshoz is, hiszen egy hacker- vagy vírustámadás nagyon könnyen okozója lehet. A szolgáltatás kiiktatását, adatvesztést vagy adattörlést célzó támadások sajnos gyakoriak.

Alapvetően három hacker típust különítenek el a szakirodalomban. Az első az úgynevezett "recreational" hacker, azaz amikor valaki "sportból" tör be. Ez a hacker általában nem megy messzire, tipikus célja például egy honlap megváltoztatása, ami jelentős üzleti károkat is okozhat. Ezzel a jelenséggel az a probléma, hogy amikor megváltozik egy weblap, akkor nem magától értetődő, hogy az volt a kizárólagos cél vagy esetleg csak az utolsó lépés volt. Amennyiben ez az utolsó lépés, esetleg előtte már az egész belső hálózatot kontrollja alá vonta és utoljára "kitette a lobogót", hogy itt jártam.

A második kategóriája a "criminal minded" hackerek kategóriája. Ők azért törnek be, mert el akarnak követni egy bűncselekményt. Tehát célzott a támadás, például valamilyen érték eltulajdonítását tűzi ki célul. A harmadik pedig a "political minded" hacker, akinek politikai alapú motivációi vannak.

P.: Van valamilyen fajta folyamatos újratesztelés az ügyfeleknél?

A. L.: Most voltam egy konferencián, ahol elhangzott, hogy 100%-os biztonság nincsen. Elévülési ideje van a teszteknek. Tehát ha végrehajtunk egy tesztet, akkor tapasztalatból úgy látjuk hogy kb. 6 hónap alatt majdnem biztosan elévül a teszteredmény. Ez abból adódik, hogy fél év alatt két dolog nagy eséllyel megváltozik. Az egyik maga az infrastruktúra és az alkalmazás - átkódolnak részeket, változtatnak, upgrade-elik a szervert, konfigurációt módosítanak, tehát változik maga a környezet. A másik ami változik, a rendszert körülvevő világ, azaz a rendszerről esetleg kiderül olyan információ, ami azt megelőzően nem volt publikus. Naponta publikálnak új hiányosságokat. Ha mindenki által olvasható egy olyan biztonsági rés, ami azelőtt nem ismert, akkor megváltozik a kép az adott rendszerről. Ez a két tényező azt eredményezi, hogy 6 hónap alatt majdnem biztos, hogy elévülnek a teszteredmények. Egy biztonsági teszt vagy vizsgálat adott időpontra vonatkozik vagy egy rövid időtartamra. Ezek a tesztek a problémák alap okát kell felfedjék. Mi jelentjük azt, hogy milyen hiányosságok vannak az alkalmazásban vagy infrastruktúrában (kódolási probléma, tervezési probléma, stb.), ezeknek az elhárításával a rendszer biztonságosabb lesz. A lényeg az, hogy megértsék az ügyfelek azt, hogy ezeket hogyan lehet elkerülni, tehát hogyan működjenek úgy, hogy ezek a problémák ne ismétlődjenek. Mondok egy példát: ha kódolási hiba van, és kijavítják az adott problematikus programkódot, de legközelebb egy másik személy ugyanazt a kódolási hibát elköveti ugyanazon a rendszeren, akkor nem sokat javult a helyzet. Amennyiben az ügyfél az első hiba alapján meg tudja fogalmazni az elvárásait, például, hogy a kódolásnál vagy rendszerkonfigurációnál bizonyos standardok vannak, akkor elkerülhető, hogy a probléma ismétlődjön. Éppen ezért nagyon fontos, hogy a teszt végén több szinten tartsunk találkozókat. Az üzleti döntéshozókat az érdekli leginkább, hogy mekkora kockázata van az adott hiányosságoknak és mekkora befektetést igényel a probléma elhárítása, a rendszer biztonságossá tétele, honnan adódott ez a probléma. De technikai találkozókat is tartunk, ahol az IT részleg tanulja meg azt, hogy ezeket a problémákat hogyan lehet elhárítani és megelőzni.

P.: Ezek szerint végeztek oktatást is?

A. L.: Igen. De a teszt végén magát a jelentést is úgy kell megírjuk, hogy az oktató anyag is legyen egyben. Egy jó jelentés magas szakmaisága mellett nem árt, ha olvasmányos is. A lényeg nem az, hogy elvégezzünk egy tesztet, hanem, hogy tudást tudjuk átadni. Fontos, hogy minden információ a hiányosságokról, a megoldásról, a megelőzésről átkerüljön az ügyfél oldalára. Egy professzionális betörési teszt nem attól professzionális, mert teszem azt sikerült betörni, hanem attól, hogy valamennyi potenciális rést sikerült felfedni és a megrendelő a teszt végén érti a problémákat.

P.: És ez meg is történik?

A. L.: Mi minden esetben biztosítjuk, hogy a kommunikáció köztünk addig tartson, amíg biztosan megismerik a hibákat és azok hátterét. Nagyon változó, hogy mi segíti legjobban az ügyfelet a probléma megértésében.