Prémium
Internetes veszélyforrások: van megoldás! (x)
Cikk mentése
Megosztás
Veszélyforrások, támadások.
Portfolio.hu: Milyen típusú veszélyforrások vannak? 
P.: Mi volt ennek a fordulatnak az oka?
A. L.: Szerepet játszhat ebben az internet kapcsolatok számának, a web-tartalomnak és e-mail forgalomnak a növekedése. A web körülbelül 10 éves múltra tekint vissza, az internet alapjait azonban már a 70-es években fejlesztették - így például a TCP/IP protokollt. Ma az internet használat hazánkban is elterjedőben van, lényegesen több ember használja, lényegesen több számítógép van a hálón és több szolgáltatás érhető el. E-mail és a web-forgalomban óriási növekedés volt tapasztalható az elmúlt pár évben. Ha a támadók szemszögéből nézzük, akkor láthatjuk, hogy ha valaki tényleg rosszindulatú cselekményt akar végrehajtani, akkor egy belső támadáshoz minimum ott kell lennie, ahol a bűntényt elköveti. Jellemzője az ilyen támadásnak, hogyha nincsen hozzáférése a támadónak az épülethez, akkor valahogy be kell jutnia, ami egy fizikai támadást jelent. Ez magára a bűnözőre nézve is egy veszélyforrás: elkaphatják, letartóztathatják, nyomot hagyhat. Ha mondjuk a cselekményt egy belső dolgozó hajtja végre - például bűncselekményt követ el a számítógépes rendszert felhasználva - akkor, amíg az objektumon belül tartózkodik, ez kiderülhet és kérdőre vonhatják. Vannak olyan védelmi mechanizmusok, melyek segítik az ilyen cselekmények hatékony felfedését. Ha azonban valaki távolról támad, különösen ha egy másik országból, a támadó megpróbálhatja megakadályozni azt, hogy a személye kiderüljön. Itt már jogi problémák is felvetődnek és az idő is fontos szerepet kaphat. Az idő fontos paraméter a támadásoknál. A felmérések tehát azt mutatják, hogy a külső támadások aránya a fent említett okok miatt megnőtt.
P.: Ti milyen támadások elleni védelemre szakosodtatok?
A. L.: Mi a Biztonság és Technológia Megoldások csoportján belül elsődlegesen biztonsági tesztekkel foglalkozunk. Azt mutatjuk meg ügyfeleinknek, hogy egy adott rendszer, egy infrastruktúra, egy alkalmazás mennyire védett, azaz egy információ, amit védeni szeretnének, mennyire "érezheti magát" biztonságban. Alapvetően három teszt-típust ölel fel ez a terület. Az első kategóriába a diagnosztikai tesztek tartoznak. Ez a klasszikus értelemben vett technológiai informatikai auditot jelenti. Ebben a megközelítésben operációs rendszereknek, adatbázis kiszolgálóknak, tűzfalaknak nézzük a biztonságát. Úgy kell ezt elképzelni, hogy a hálózati infrastruktúrában objektumonként, hálózati elemenként, illetve számítógépekre lebontva vizsgáljuk a biztonságot. Vannak érvek a diagnosztikai vizsgálatok mellett is és ellen is. A diagnosztikai vizsgálatok klasszikusan nagy mélységben fednek le egy kiszolgálót vagy egy hálózati elemet, éppen ezért több időt igényelnek és nagyobb költséggel járnak. Hátránya, hogy nem mutat képet egy teljes infrastruktúráról, a jelentés esetenként feltételezésekre épül, ezért előfordulhat, hogy nem teljesen valós képet mutat.
A második teszttípus a biztonsági betörési tesztek, amelyek infrastruktúrák elleni támadások, gyakorlatilag hasonló módszereket alkalmaznak, mint amivel egy hacker is él. Persze azzal a különbséggel, hogy ezeket a teszteket olyan szakértők végzik, akik kockázatkezelési és technológiai szempontból cégünknél igen magasan képzettek. Tehát egy éles rendszeren tudunk úgy betörési tesztet végrehajtani, hogy az adott rendszer ne sérüljön, ne szenvedjen kárt, a szolgáltatás ne maradjon ki, viszont teljes mélységben megismerje az ügyfél azt, hogy milyen a biztonság szintje a cégnél. Az infrastruktúra teszteknek két válfaja van, a külső és a belső. Azt lehet mondani, hogy a kettő között szerepel a vezeték nélküli hálózatok tesztje, amit szintén végzünk. Továbbá az infrastruktúra tesztek körébe soroljuk a social engineering (humán tényezők tesztje) és a telefonos hálózatok biztonsági tesztjeit.
A harmadik nagy terület a webes alkalmazásoknak a biztonsága, ami önmagában egy nagyon nagy terület. Arról van szó, hogy működik egy webes alkalmazás az interneten, akkor betörési teszttel nem elegendő megnézni azt, hogy infrastruktúra szinten a webszerver - értem ez alatt magának a webszerver programnak a funkcióit - mennyire biztonságos, hanem azt is vizsgálni kell, hogy maga az alkalmazás réteg mennyire biztonságosan működik. Olyasmire kell gondolni itt, hogy egy ilyen alkalmazás szintű támadás le kell hogy fedje például a következő eseményt: egy banki portálnál lehetséges-e mondjuk az, hogy az egyik felhasználó hozzáfér egy másik banki felhasználó adataihoz, tranzakciót végezhet egy másik felhasználó nevében. Egy kereskedelmi portálnál klasszikus probléma lehet, ha valaki meg tudja változtatni az árakat a vásárlás során. Egy ilyen típusú hiányosság vagy gyengeség nem jön elő egy infrastruktúra teszt során, az nem ezt célozza meg, hanem azt, hogy maga a webszerver mennyire működik biztonságosan. Az alkalmazás rétegben azt nézzük meg, hogy ha valaki egy böngésző (browser) előtt ül, és egyéb eszközöket is használ, akkor végezhet-e olyan tranzakciót, vagy kommunikálhat úgy az alkalmazás réteggel, hogy azt kimozdítja a "normális" állapotából és valami olyasmire kényszeríti, amire egyébként az alkalmazás tulajdonosa nem - de maga a programtervező sem - gondolt. Ez a három nagy fő terület tehát: a diagnosztikai vizsgálat, a betörési tesztek, illetve annak egy válfaja, a webes alkalmazásoknak a tesztje.
P.: Melyik a legköltségesebb a három közül?
A.L.: Az infrastruktúra és a webes alkalmazások tesztje nehezen összehasonlítható a költségek tekintetében. A diagnosztikai tesztek arányaiban sokkal drágábbak, mint a betörési tesztek. Mondok példát. Vegyünk egy iroda-épületet, ahol van mondjuk 600 gép, amiből 50 darab szerver és 550 asztali PC. Ennek a rendszernek a biztonságáról kell meggyőződnöm, akkor diagnosztikai vizsgálatok során tipikusan kiválasztanak szervereket és elemzik, hogy azok mennyire biztonságosak, mivel ott van a védeni óhajtott információ. A probléma ott kezdődik, hogy nagyon sok esetben a biztonsági rés nem a kiszolgálón van, hanem valamelyik asztali számítógépen, egy távolban lévő útvonalválasztón (router), egy tűzfalon, vagy "rejtett" modemen. Ahhoz hogy az összes gépet diagnosztikai vizsgálattal lefedjük, gyakran hónapok kellenek, míg egy infrastruktúra teszttel az egészet egyben, tehát a több száz gépes rendszert gyakran 2-3 hetes munkával lehet tesztelni biztonsági szempontból. Itt két ág válik megint szét. Az egyik a sebezhetőségi vizsgálatok, a másik pedig az, amikor betörést is végrehajtunk (ezek a klasszikus betörési tesztek). Van amikor az ügyfél nem akarja a betörés prezentálását (exploit), csak arra kér fel minket, hogy addig menjünk el, hogy meg tudjuk állapítani, milyen gyengeségek vannak a rendszerben. A betörési tesztek teljesebb és valós képet adnak, mert nem teoretikus állapotokra építenek. Hatékonyabbak, de fontos tudni, hogy kockázattal is járnak.
Az alkalmazás-teszteket az infrastruktúra-tesztekkel nehéz összehasonlítani. Egy infrastruktúra-teszt tipikusan 2 hétbe telik, de végeztünk több mint két hónapos betörési tesztet is. Egy webes alkalmazás tesztje rendszerint 1-2 hét, de ez függ az alkalmazás funkcióitól is.
