ITBN2020
It's getting personal!
Idei évben a pandémia következményeként minden nagy rendezvény a virtuális térbe - vagy ahogyan a workshop-on fogalmaztam - a kibertérbe helyeződött át. Volt idén virtual Cisco Live, Techtorial, HPE vTSS stb... és végül az ITBN esetében is úgy döntöttek Keleti Arthurék, hogy ennek az eseménynek egy online platformot biztosítanak október 28-29-én.
Workshop
Idén abban megtiszteltetésben volt részem, hogy ne csak résztvevőként jelenjek meg a platformon, hanem előadóként is tevékenykedhettem. Az én témám nem más volt mit az, hogy egy kis API hívás, kis programozás hatására, mennyire hatékonyan is tudunk beavatkozni az IT infrastruktúrába, ha nem kívánt forgalom, esetleg egy támadás indikátorai jelennek meg a hálózaton.
Az előadásról aki lemaradt, annak röviden összefoglalom a témát:
- Folyamatos a fenyegetettség!
- Csapataink harcban állnak!
- Hatékony fegyverekre van szükség!
Komolyra fordítva a szót, a lényeg, hogy a COVID19 következtében, a cégek - amelyek megtehették - mindent hátrahagyva notebook vásárlásba kezdtek és hazaküldtek mindenkit, akit csak lehetett, hogy ezzel csökkentsék a kontaktusok számát amellett, hogy folyamatos üzletmenetet biztosítanak. A kérdés az, hogy biztonsági szempontból mennyire tudtak felkészülni, arra ami ez után következett, hiszem, hogy nem elég jól!
Néhány számadat a COVID-ról a kibertérben:
COVID-dal kapcsolatos:
SPAM: 907k
Új Malware 737
Veszélyes URL szám: 48k
SPAM növekedés február és március között 220x-ra növekedett
Veszélyes URL száma február és március között 260%-kal nőtt.
Ezek a számadatok az első negyedévről származnak, mostanra egy 5-6 vagy 10x-es szorzót rakhatunk eléjük. A kérdés az, hogy mit tudunk tenni, hogy a home-office-ból visszatérő kollégák notebook-ja ne okozzon pandémiát az IT infrastruktúrában?
Első lépés, hogy hatékony védelmi vonalakat alakítunk ki:
- - NGFW alapú határvédelem
- - Viselkedés analízisen alapuló végpont védelem
- - Hálózat analizálás
- - Cloud Security
- -Többfaktoros azonosítás
- -Hálózat biztonság
Az, hogyha minden fronton felturbózzuk az IT Security-t, vajon 100% védelmet biztosít?
Nem!
100% védelem nem létezik, de lehet törekedni a legtöbb 9-esre akár 99999-re is, de 100%-kot akkor sem érhetünk el ha műszakilag kivitelezhető lenne, ugyanis mindig lesz egy tényező ami nem lehet 100%-kosan biztonságossá tenni, ez pedig az ember.
Ezért úgy gondolom, hogy az emberi tényező csökkentésével lehet növelni biztonságon, és most nem arra gondolok, hogy akkor építsük le az IT-t teljesen, mert ezen a területen lepkehálóval sem találni erőforrást, hanem inkább azt, hogy az egyetlen Józsit a Bélák között tehermentesítsük a sok feladat alól, hogy ő is hatékonyabban tudja végezni az amúgy sem kevés munkát, így ő is kevesebbet fog hibázni, hatékonyabb lesz.
Az IT automatizálás, már rég nem science fiction, ugyanis kb 10 éve folyamatban olyan rendszerek kifejlesztése amelyek kifejezetten az infrastruktúra programozhatóságát teszik lehetővé. Mik ezek a rendszerek... paramaparam: S D N , hálózat-virtualizáció , és az API...
Az előadásom demo része leginkább REST API-ra volt kihegyezve, amiről egy korábbi bejegyzésem során írtam:
https://www.telecommer.hu/2019/09/halozat-virtualizacio-episode-v-part-i.html
Egészen egyszerűen azért REST API alapú API hívásokat használtam, mert a rendszerek, amiket integráltam ezt a protokollt támogatják.
Térjünk rá a demo környezetre!
3 demo-t szerettem volna megmutatni a közönségnek, de úgy el repült az az 1 óra, hogy végül csak 2-re maradt idő, de ezen platformon az idő nem fontos (csak az élet számít :D), szóval egyfajta bónuszként is értékelhetitek részemről az ezt követő írásokat.
Az első demo-nak a lényege, hogy python scipt segítségével, amennyiben a hálózat analitikai rendszerünkben egy adott típusú forgalomra riasztás keletkezik, akkor a végpont védelmi rendszer kizárja a kommunikációból a felhasználót.
Mit jelent ez IT biztonsági nyelvre lefordítva.
Ha a hálózaton észrevettünk egy lehetséges támadási vektort, vagy egy dayzero malware lehetséges indikátorát, akkor ez alapján automatikusan tudunk beavatkozni a végponton, és megakadályozhatjuk, hogy tovább fertőzze az infrastruktúrát.
Hogy is néz ki ez a script?
Figyelem a következő sorok a nyugalom megzavarására, a figyelem elvesztésre, az oldal elhagyására adhatnak okot, kérem ebben az esetben tekerj az aljára és olvasd el az összefoglalót.
Köszönöm
Azonosítási módszerek
Szóval elsősorban, meg kell találni az egyes komponensek API hívásának módját, és ez alatt az autentikációban van különbség. Ugyanis az AMP4E console, a Stealthwatch, vagy Threat Grid is más típusú autentikációt használhat, mint egy TM Apex Central. De pontosan milyen API azonosítási módszerek is léteznek?
Basic
Bearer
O2Auth
JWD
stb...
Szóval van egy jó pár lehetőség, ami meg tudja nehezíteni az életünket, de ha szerencsénk van akkor adott gyártó adott termékénél ezek le vannak dokumentálva, és/vagy példa kódot is kaphatunk bizonyos esetekben (általában python-ban). Ha összegyűjtöttük és teszteltük az egyes API hívásokhoz szükséges azonosítási módszereket, akkor jöhet feladat specifikáció.
DEMO 1
Az első demo feladat lényege az volt, hogy a stealthwatch-ban keletkezett riasztások ellenőrzését követően, a riasztásban szereplő forrás címeket, amelyek a hálózatunkon belüli host-ok, kizárjuk a hálózati kommunikációból a Trend Miro Apex One végpontvédelmi ágens segítségével.
Ehhez szükség lenne a Apex Central API reference guide-ra és a Stealthwatch API reference guide-ra, és postman próbálkozások tömkelege után talán neki is tudtam volna a script írásnak, de ettől szerencsésebb voltam, mert a TM Apex Central-hoz Trend Micro által készített példa script tartalmazta a megfelelő sorokat, így csak code reusing-ot kellett alkalmazni ebben az esetben, és stealthwatch-hoz is elérhető a developer.cisco.com-on az elkészített python code.
Ezek a alapos elemzése és tesztelését követően, a feladathoz kellett illeszteni függvényként az egyes elemeket.
Script első fele a feladat szempontjából szükséges python könyvtárak összegyűjtését tartalmazza.
Ez az a rész, ami a fejlesztés közben organikusan változik, nyilván egy igazi python coder lehet előre tudja, hogy mit szeretne pontosan használni, de én még csak bontogatom a szárnyaim ebben a témában.
Ami szintén fontos, hogy az egyes rendszerek eléréséhez szükséges paramétereket kigyűjtsük változókba, hiszen így könnyűszerrel univerzálisan használhatóvá tehetjük az alkalmazást.
Stealthwatch esetében ezek a paraméterek egy conf fájl-ban míg a TM esetében a script-ben foglaltak helyet, és ennek gyakorlati jelentősége nem nagyon van. Szimplán nem írtam meg ezt a részt máshogy, mert a demo szempontjából nem volt releváns.
Produktív script esetében ezt javasolt egységesen kezelni.
Most jöjjön a Very important magic 1
A fenti script a bemeneti változó értékek alapján autentikálja az API felhasználót az Apex Central-ban és a visszatérési értéke egy token, amit a további API hívások során felhasználhatunk.
Az API reference guide-ok egész pontosan leírják, hogy az adott token meddig érvényes, illetve az alkalmazáson belül ezeket a paramétereket általában lehet módosítani is, ha az alkalmazásunk működése szempontjából ez fontos.
Very important magic 2
A feladat végeredménye a végpont izoláció, amihez szükség van a Central adatbázisában található egyedi azonosítóra is, ezért a fenti függvény begyűjti a hostnév, vagy IP cím alapján a végpont entity_id-ját.
Very important magic 3
A harmadik függvény az izoláció maga, aminek két bemeneti paramétert kell átadni:
1. IP cím vagy hostnév
2. A korábban begyűjtött entity_id
A függvénynek nem lesz visszatérési értéke hiszen alapvetően itt megáll a feladat, nem szükséges paramétereket átadnunk további függvényeknek.
Eddig csak a TM releváns függvényeket mutattam be, de mi a helyzet az intelligencia résszel a SW-vel?
SW-t használtam fel a scipt főfüggvényeként, mert alapvetően a feladat információ begyűjtéssel kezdődik.
API használat itt is autentikációhoz kötött, ezen nincs mit magyarázni, itt talán kicsit egyszerűbb a hozzáférés.
Az API hívás lekérdezi alerts-eket és abból az információ halmazból kell kimazsolázni az IP címet és/vagy hostnevet. Ezt a visszakapott json válaszból legegyszerűbben a source_name értékből tudtam kiszedni.
A feladat végrehajtása szempontjából egy hibát ejtettem, de ezt most nem árulom el a felfedezés örömét meghagyom az Olvasók számára.
....
A további DEMO feladatok bemutatására készítetek még post-ot, most már elértük azt a karakterszámot amely a befogadhatóságot nagyban csökkentik már, úgyhogy folyt. köv.