Szirtes István
[email protected]
Szirtes Technologies www.szirtes.com
… a szervezeti kultúrához és informatikai környezethet alkalmazkodó egyedi szabályrendszer
nincs univerzális biztonsági házirend A világban a cégek fele/harmada nem rendelkezik biztonsági házirenddel, és ahol igen, ott is nagy számban nem ismerik vagy értik az alkalmazottak.
Defense in depth A védelem mindig több komponensből áll, ezért mindegyikre figyelnünk kell!
Éppen elégséges jogosultságok elve Mindenkinek és mindenhová csak annyi jogot állítsunk be, ami a folyamatokhoz szükséges!
Minimálisra kell szorítani a támadási felületeket Tökéletes biztonság nincs, de törekedjünk rá!
A megelőzés olcsóbb a kezelésnél! Kezdjük helyzetelemzéssel! Csak a feltárt kockázatokat lehet ellensúlyozni! A kockázatelemzés lényege: számszerűsítsük a veszélyek lehetséges hatásait. Meg kel próbálni a kockázatokat elfogadható szintre csökkenteni Szakemberek <-> Döntéshozók Két világot kell összehozni egymással
A védendő erőforrások köre folyamatosan változik, ahogy egy cég is! Erőforrás típus
Példa
Hardver
Asztali és hordozható számítógépek Router-ek és switch-ek Mentési médiák
Szoftver
Szoftver telepítő készletek OS image-ek Egyedileg fejlesztett szoftver kód
Dokumentáció
Biztonsági szabályok és eljárások Hálózati- és épület tervrajzok
Adat
Vállalati titkok Dolgozói információk Ügyfél adatbázisok
Miért fontos a győzelem? Mert nem mindenki képes rá! Minden támadót más motivál Azonosítsuk az ellenségeinket!
Külső támadó
Belső támadó
Vállalati erőforrások Vírus
Rossz jogosultságrendszer
Bosszú; Kémkedés; Hírnév; Saját szórakoztatására; Terrorizmus
1
2
Azonosítás
Elemzés
Kockázati állítás
5
3
Aktualizálás
Tervezés 4
Követés
A kockázatelemzés legnehezebb fázisa! Vajon mennyit ér a cég jó híre? Mennyivel csökken a fogyasztók bizalma a cég weboldalával szemben indított támadás során? Mekkora kárt okoz titkos adataink kiszivárogtatása? Mennyibe kerül a védekezés? Mekkora a veszteség vagy a betörés valószínűsége?
Minősítő (Qualitative) elemzés, pl.: magas Mennyiségi (Quantitative) elemzés, pl.: mennyibe kerül Relatív besorolási szám = valószínűség x hatás Meghatározás 1. Single loss expectancy (SLE)
Definíció Az esemény egyszeri bekövetkezésének költsége
Az esemény 2. Annual rate of occurrence bekövetkezésének éves átlag (ARO) valószínűsége Várható éves veszteség, ha 3. Annual loss expectancy nem teszünk semmit a (ALE) kockázat csökkentésére
Példa Pénzügyi hatás: $12,000 + Üzleti hatás: $27,520 = $39,520
Kétszer egy évben Veszteség összesen:
$39,520 x 2 = $79,040
Priorizálni kell a kockázatokat, hogy megfelelő erőforrást rendeljük hozzájuk Meg kell találni egy egészséges középutat, hogy mely kockázatokkal kell foglalkozni és mivel nem Indokolni kell a kiadásokat a személyzet, hardver és szoftver beruházások tekintetében Rögzítsünk minden lehetséges kockázati tényezőt, amelyből látható, hogy mikkel foglalkoztunk és mikkel nem Végezzünk méréseket egy bevezetett rendszernél, hogy alátámasszuk a kockázati tervünket
Fizikai védelem védett épületek, lopás, betörés, tűz, víz, földrengés, illetéktelen hozzáférés…
Számítógépek nem megfelelő konfiguráció következtében sebezhetőség, kémprogramok és vírusok…
Felhasználók gyenge jelszavak, nem megfelelő jogosultságok, bejelentkezve maradt felhasználók…
Hitelesítés gyenge titkosítás, nem kompatibilis protokollok használata…
Adat sérülés, hardver sérülés, jogosultság…
Hálózati kommunikáció lehallgatás, átvitt adatok meghamisítása, Denial of Service támadás…
Egyéb hálózati elemek nem felügyelt hozzáférés a hálózathoz, kiszivárogtatott infók, Man-in-the-middle támadás…
Ha a támadó fizikailag is hozzáfér a megtámadandó rendszerhez, akkor már sokkal könnyebb dolga van A fizikai védelem nem csak a külső támadóknak szól, hanem a belső kísérletezőknek is Nem minden információ elektronikus Táblán hagyott adatok; kinyomtatott szerződések…
Mobil eszközök védelme sokkal nehezebb, mint a PC-ké (védelem pl.: Syskey, BitLocker…) Természeti katasztrófák ellen is védekezzünk
Telepítés alatt megszerzett admin jelszó Vírus fertőzés történik még a vírusirtó telepítése előtt Az alap biztonsági beállításokat nem terítjük egységesen Az adott gép nincs a szerepkörének megfelelően biztonságilag beállítva A biztonsági beállítások nem követik le a gépet, amikor a szerepköre megváltozik SP-k és hotfix-ek hiánya Védett adatok maradnak a merevlemezen a gép leselejtezése után
A rendszer legnagyobb sebezhetőségét a felhasználói fiókok adják! A leggyakoribb támadás típusok: Jelszóproblémák Fiókjogosultságok kihasználása Social Engineering
Nagyon fontos folyamat a napi üzemeltetés során az események auditálása (naplózott folyamatok ellenőrzése) Fontos, hogy a különböző rendszerek és számítógépek naplóállományait összefüggéseiben vizsgáljuk javasolt a SCOM Audit Collection Services bevezetése Dolgozzunk ki eljárást arra vonatkozóan, ha bekövetkezett a baj, hogyan analizáljuk azt
Spoofing Cél: A felhasználó hitelesítési adatainak megszerzése Pl.: Man-in-the-Middle
Tampering Cél: adatkommunikáció közben az átvitt adatok meghamisítása (pl.: adatbázis-, weboldal átírása) Pl.: Session Hijacking
Repudiation Cél: a kért tartalom megtagadása (pl.: fizetős oldalon a regisztráció után a támadó megakadályozza a tartalom letöltését)
Information Disclosure Cél: Információk felfedése és ellopása Pl.: Network Sniffing
Denial of Service Cél: a szolgáltatás extrém nagy terhelésével előidézett instabilitása, leállása (pl.: zombi gépek bevonásával) Pl.: Code Red, Nimda, Slammer féreg vírusok
Elevation of Privilege Cél: gyenge felhasználói jogokkal erős jogokat szerezve támadásokat végrehajtani
hálózat teljesítménye csökken a felhasználói fiókot nem szokványos időben használják a naplózott események száma megugrik a rendszer teljesítménye csökken a számítógépek gyakran lefagynak vagy újraindulnak a felhasználók szólnak, hogy valami nincs rendben új vírus jelenik meg a behatolás detektáló jelez
Cél: Ha a támadás mégis megtörténik, akkor arról minél előbb értesüljünk és a megfelelő válaszlépéseket gyorsan megtegyük Legyen cselekvési tervünk! Gyakran a válaszlépések ad hoc jelleggel történnek
Az incidens válaszkezelési folyamat is fontos, hiszen ha nincs retorzió, akkor nincs is visszatartó erő!
Ami nincs kikényszerítve, azt nem tartják be az emberek Köze sincs a valósághoz Olvashatatlan technikai kifejezésekkel teletűzdelt szakmai anyag Nem elég könnyen hozzáférhető Elhanyagolt dokumentáció (rég nem aktuális szabályok) Nagyon sok mindenben korlátozó szabályrendszer (akadályozza az üzleti folyamatokat) Vezetői példamutatás hiánya Terjengős dokumentáció
Tiszta és tömör szabályok Az irányelveknek és az eljárásoknak külön-külön dokumentumot hozzunk létre az irányelvek ritkábban változnak, mint a végrehajtási eljárások
Vezetői példamutatás Legyen könnyen hozzáférhető és naprakész Az üzleti folyamatokhoz illeszkedő rendszert hozzunk létre Próbáljuk meg a rendelkezésre álló technológiával kikényszeríteni a szabályok betartását, de nem ez az egyetlen eszköz Legyen következménye a biztonsági szabályok be nem tartásának
Dolgozzunk ki jutalmazási rendszert, ha valaki biztonsági incidenst észlel és azt jelenti Figyeljük a szabályok hatását, vonjuk le a megfelelő konzekvenciákat, és ha szükséges módosítsunk rajtuk Próbáljuk meg ösztönözni és érdekelté tenni a felhasználókat a szabályok betartására (bekövetkezhető események hatása a munkájára nézve)
Érezzék hogy ők és a cég egy oldalon állnak, és ne a szabályok kikerülésére törekedjenek!
