Jelenlegi hely

ISACA

Feliratkozás ISACA hírcsatorna csatornájára
Az ISACA Magyarországi Egyesület a nemzetközi ISACA magyarországi szakmai szervezete.
Frissítve: 2 óra 12 perc

Közgyűlés 2018

2018, január 5 - 11:25
Tisztelt Tagtársak!

Az ISACA Magyarországi Egyesület 2018. február 14-én 17.00-kor tartja éves közgyűlését a szokásos helyen, az MNB 1013 Budapest, Krisztina krt. 39. alatti épületében (korábban PSZÁF), melyre tisztelettel meghívunk. 

Amennyiben a meghirdetett időpontra nem jelenik meg a szavazásra jogosultak min. 50,1%-os részaránya, úgy a közgyűlés eredménytelen lesz. Erre az esetre a meghirdetett közgyűlés megismételt közgyűlési időpontját 2018. február 14-én 17.30-kor tartja az MNB 1013 Budapest, Krisztina krt. 39. alatti épületében. A megismételt közgyűlés a megjelentek számától függetlenül határozatképes lesz.

A Közgyűléssel kapcsolatos dokumentumok hamarosan elérhetők lesznek a weboldalon.

Minden tag megjelenésére feltétlenül számítunk!
 

Üdvözlettel:
 
Biró Gergely
elnök

Információvédelem menedzselése LXXIX. Szakmai Fórum

2018, január 3 - 14:13

A Hétpecsét Információbiztonsági Egyesület meghívja Önt, a 2018. január 17-én tartandó, "Információvédelem menedzselése LXXIX. Szakmai Fórum"rendezvényére.

A Rendezvényünk ÚJ Helyszíne a

Lurdy Konferencia-és Rendezvényközpont

(1097 Budapest, Könyves Kálmán krt. 12-14.)

 

A rendezvény programja:

09.30 – 10.00 Érkezés, regisztráció

10.00 – 11.30 Köszöntő és bevezető gondolatok - Aktualitások az információvédelem területén

Tarján Gábor(Hétpecsét Egyesület) alelnök

Tudásmenedzsment és kockázat paradoxona
Prof. dr. habil Bencsik Andrea (Széchenyi István Egyetem) egyetemi tanár

Hogyan érinti a GDPR a munkahelyi adatkezeléseket?
Dr. Pók László (Szecskay Ügyvédi Iroda) partner

11.30 – 11.50 Kávé szünet (kávé, üdítő, pogácsa, aprósütemény)

11.50 – 13.00 Mobile Device Management és biztonsági kihívásai egy igazán nagy cég életében

Balázs András (GE Digital) Director - Digital Operations

Nyilt (Permissionless) Blocklánc alapú rendszerek információbiztonsági kihívásai

Csabai Csaba Független crypto-blogger, Bitcoin evangelista

 

A Szakmai fórum az ISACA Hungarian Chapter által támogatott rendezvény.

CPE pontszerzési lehetőség.

Kérjük részvételi szándékát jelezze legkésőbb 2018. január 14-ig elektronikus regisztrációval a honlapon keresztül.

A részvételt technikai okok miatt kizárólag az időben beérkezett regisztráció alapján tudjuk biztosítani.

Felhívjuk a résztvevők figyelmét, hogy az előadások nyomtatott változatát csak a Hétpecsét Információbiztonsági Egyesület tagjainak tudjuk biztosítani.

A fórumról szóló információkat, valamint az Egyesület életéről és az információbiztonsággal kapcsolatos érdekességekről a Hétpecsét Egyesület LinkedIn oldalán olvashatnak!

Budapest, 2017. december 12.

Regisztráció a Fórumra

Tagsági státusz megújítás 2018. évre

2017, december 23 - 10:32

Kedves Tagtársunk!

Örülök, hogy idén tagjaink között voltál az ISACA Budapest Chapterben és remélem, hogy te is megtaláltad a számításaidat, megkaptad a számodra fontos értékeket és igénybe vetted a Chapter által kínált szolgáltatásokat. Mint a nemzetközi ISACA hírekben olvashattad, december végével lejár az éves tagsági státusz és már megkezdődött a megújítási ciklus a 2018-as évre. Javaslom, hogy ne hagyd az utolsó pillanatra a megújítást, mert így lemaradsz az első 100 megújító tagunknak küldendő ajándékról is!

Fontosnak tartjuk, hogy erősödjön a Budapest Chapter, jövőre még több kollégát segíthessünk hozzá a tagsággal járó előnyökhöz és lehetőségekhez és azt is szeretnénk, ha minél több tagtársunk választaná ismét Egyesületünket. 

Szeretnénk neked segíteni néhány tanáccsal és javaslattal a sikeres megújításod érdekében:

  • A megújítást a www.ISACA.org/renew oldalról közvetlenül indíthatod, és elérheted a My ISACA / MyCertifications oldalról is.
  • Ne felejtsd el a 2017-es évre vonatkozó CPE pontjaidat ellenőrizni és feltölteni a minősítéseidhez. A Budapest Chapter által kiadott CPE kártyával látogatott események pontjainak feltöltését a HQ felé automatikusan végrehajtjuk.
  • A CPE pontokkal kapcsolatos részletes feltételekről tájékozódhatsz a minősítésedhez tartozó CPE Policy oldalon. Mintaként itt a CISA CPE Policy.
  • Remélem, hogy sok ingyenes rendezvényünkön (mert vannak szép számmal) találkozunk a jövőben és elégedett tagunk leszel.

Ha kérdésed lenne, akkor szívesen állunk rendelkezésedre az alábbi elérhetőségeinken:

 

Horváth Pál,

Membership Director

     

SecOps Europe 2018 Konferencia

2017, december 6 - 10:02
Kedves Kolléga!


Az ISACA Budapest Chapter és a konferencia szervezői szeretettel várnak Téged Magyarország egyik leginnovatívabb nemzetközi IT biztonsági konferenciájára, a SecOps Europe-ra!

A két napos rendezvényen a szakmai előadásokat, kiberbiztonsági gyakorlatok fogják színesíteni, így a résztvevők nemcsak elméleti, hanem gyakorlati információkkal gazdagothatnak az IT biztonság offenzív és defenzív területein. 
Az előadások listája folyamatosan bővül, a részleges lineup már elérhető az oldalon.

Időpont: 2018. január 24-25. (szerda-csütörtök)
Helyszín: Budapest Kongresszusi Center


REGISZTRÁLJ INGYENESEN, VAGY VÁSÁROLJ LIMITÁLT VIP JEGYET >>>

 


Mire számíthatsz az előadásokon kívül?

 
1. NAP
A SecOps Europe első napján a kiberbiztonsággal kapcsolatos TTX (Tabletop Exercise) játékoké lesz a főszerep: délelőtt egyetemi csapatok, délután pedig IT biztonsági szakértők mérik össze tudásukat és tapasztalataikat. 
 
Mi a TTX?
A Tabletop Exercise egy olyan stratégiai döntéshozó szimuláció, amely során döntéshozatali, vezetői és diplomáciai szinten lehet tesztelni egy vállalat, szervezet, vagy kritikus infrastruktúra incidenskezelési tervét különböző - valós élet tapasztalatain alapuló - kibertámadásokra. 
A játék során a résztvevők folyamatosan jutnak hozzá az eszkalálódó  szcenáriókhoz és a hozzájuk kapcsolódó részletes információkhoz, amelyek alapján a lehető leghatékonyabb stratégiai döntéseket kell meghozniuk. A profi zsűri ezután egy előre meghatározott szempontrendszernek megfelelően értékeli a csapatok munkáját.
 
Miért hasznos?
Mert a TTX gyakorlatok során gyorsan, hatékonyan és non-destruktív módon lehet információkhoz jutni az adott szervezet incidenskezeléséről, valamint eredményesen lehet azonosítani azokat a kritikus pontokat, amelyek egy valós kibertámadás során problémát okozhatnak. Tehát a Tabletop Exercise kiértékelése segít a szervezetnek az incidenskezelés fejlesztésében.

 
2. NAP
A második napon egy valódi Cyber Range versenynek lehetnek tanúi az érdeklődők, amely során nemzeti CERT csapatok fognak szembeszállni egymással. A cél, hogy megvédjék a kritikus infrastruktúrákat a támadó Red Teamtől. 
 
Mi a Cyber Range?
A Cyber Range, vagy másnéven kiber hadgyakorlat, egy szimuláció, amely különböző valós életből vett infrastruktúrák miniatürizált változatait használja az incidenskezelési tervek tesztelésének alapjául. Az eseménykezelő, CERT csapatok munkáját folyamatosan támadja a kifejezetten erre felállított Red Team, vagy hacker csapat. A Secops Europe infrastruktúrája létfontosságú rendszert testesít meg, egy PLC eszközzel. Tudj meg többet a Cyber Range-ről!
 
Miért hasznos?
Mert a szimuláció nemcsak teszteli, hanem fejleszti is a szervezet incidens reagáló és detektációs képességeit egy valós tapasztalatok alapján felépített környezetben.
 
 
REGISZTRÁCIÓ A RENDEZVÉNYRE >>>
 


A VIP jegyek limitált számban elérhetőek!

A VIP jegyek az alábbi plusz szolgáltatásokat tartalmazzák:
- elsőbbségi belépés
- VIP lounge
- kávé és ebéd
- VIP party networking lehetőséggel
 

JEGYVÁSÁRLÁS >>>

A felhasználói azonosítás jövője - paradigmák és technikák

2017, november 22 - 11:29

Amekkora közhely, akkora igazság: a jelszó már nem elég. Ahogy egy korábbi cikkben volt róla szó, bizonyos esetekben még a többlépcsős hitelesítés sem, ha nincs meg hozzá a megfelelő biztonságtudatosság. Mivel fokozható a biztonság? Az elmúlt években egyre többet lehetett hallani a viselkedés elemzésen alapuló behatolásérzékelő, azaz user behavor analytics alapú megoldásokról, viszont az ismert termékek közül több is a gyakorlatban egyenlőre még nem eléggé kiforrott.

Az UBA és hasonló megoldások ugyan elegánsak, vannak hasonlóan elegáns, a felhasználói viselkedést kevésbé figyelő, ugyanakkor napjainkban még hatékonyabb megoldások a felhasználói azonosítók, főként jelszavak ellopásán alapuló breachek azonosítására és megfékezésére. A következő cikkben ezzel fogok foglalkozni bevezető szinten, a webes vagy weben keresztül is elérhető szolgáltatások példáin keresztül.

Mindegy, hogy csoportmunkát támogató nagyvállalati megoldásokról, a Twitterről, a Facebookról, a munka világába betörni próbáló Workplace by Facebookról, a Google-ről, G Suite-ról vagy éppen a Zoho Suite-ról van szó, mind egyre kifinomultabb megoldásokat vezettek be, amivel a jelszólopáson alapuló betörési kísérleteket próbálják sokkal nehezebbé tenni. A tesztek alapján érdemes végigvenni, hogy mik azok a tényezők, amiket egy-egy belépésnél ezek a rendszerek figyelnek, ha úgy tetszik, ha valaki bombabiztos intranetet, collaboration suite-ot, ERP-t, intranetet tervezne, ezeket mindenképp érdemes beépíteni a szolgáltatásba még akkor is, ha az implementálása nem tűnik rutin feladatnak, másrészt költségesebbé teszi a működtetést olyan szempontból is, hogy külső szolgáltatók szolgáltatásait, például külső GeoIP-szolgáltatókat kell igénybe venni.

Tekintsük az alábbi hipotetikus esetet: adott egy potenciális áldozat, aki tipikusan Budapestről, vagy ha nem is Budapestről, de Magyarországról szokott belépni az adott szolgáltatásba, mobilról mindig iOS-en, mobilappon keresztül, asztali gépen pedig böngészővel Windows 10-es oprendszerrel és az aktuálisan legújabbra frissített Firefox böngészővel, amin nagyjából ugyanazok az addonok vannak telepítve a munkahelyi vagy otthoni gépén. A jólnevelt, alapos azonosítást végző webszolgáltatások lényegében a mi biztonságunk érdekében szeretik lekérdezni és naplózni az ún. browser fingerprintet, ami többek közt a következőket foglalja magába:

- képernyő felbontása és színmélysége

- a felhasználó által használt böngésző típusa, verziója és az általa használt pluginek

- a gép által használt időzóna

- a böngésző engedélyezi-e a DNT-headert, amiről érdemes tudni, hogy a webhelyek vagy figyelembe veszik vagy sem, de nincs kötelező érvénye

- a HTTP_ACCEPT , válaszban fogadható adatok típusa

- az egyedi  WebGL hash

- a böngésző és persze az operációs rendszer nyelve

- azok a rendszerben telepített betűtípusok, amiket a böngésző használhat a webhelyek megjelenítéséhez

- természetesen a jó öreg user-agent

Már ennyiből belátható, hogy itt valóban egy ujjlenyomatról van szó, hiszen alighanem nincs két ugyanolyan eszköz a világon, aminek ezek az értékek azonosak lennének, ami érthetőbbé válik a következő ábra alapján:

 

 

A saját böngésző ujjlenyomatunkat a legegyszerűbbben a https://panopticlick.eff.org/  oldalon nézhetjük meg, a teszt lefutása után csak a Show full results for fingerprinting lehetőségre kell kattintani. Az ujjlenyomatban látható bits of identifying information valamint one in x browsers have this value oszlopban látható értékek értelemszerűen azt mutatják, hogy az összes korábban mért böngésző-ujjlenyomathoz képest a sajátunk mennyire egyedi.

Ezen kívül van még több finomság, amire rendszerint nem gondolnak azok, akiknek rendszerint az a rögeszméjük, hogy ők aztán tényleg anonim módon szörföznek, saját tapasztalataim szerint akik úgy gondolják, hogy a legnagyobb avatott szakértői az anonimizálásnak, nehezebben edukálhatók, mint a teljesen fogalmatlan felhasználók, senkinek sem ajánlanám, hogy bárki is megpróbálja meggyőzni őket arról, hogy nem tévedhetetlenek.

De vannak más információk is, amiket a böngésző kikotyoghat, például a WebRTC-technológia miatt. A WebRTC ötletét az adta, hogy a VoIP és a böngészőben elérhető videótelefonálós szolgáltatások zökkenőmentesebben működjenek, alapértelmezés szerint máig az összes böngészőben alapértelmezés szerint engedélyezett a WebRTC, ami a következő információkat árulja el a felhasználóról, amiről aztán nem gondolná, hogy kívülről is látható:

- LAN IP - nem nehéz belátni, hogy a használt routerben beállított DHCP lease timetól függően a publikus IP-LAN IP együttesen nézve már alkalmas lehet a konkrét eszköz és felhasználó azonosítására. Viszont azt, hogy például egy felhasználó a  5.62.39.247 publikus IP-t használja, amihez a hozzá tartozó LAN IP 192.168.1.88, elvben természetesen nem csak olyan szolgáltatás kérdezheti le, amelyiknek ténylegesen szüksége van erre az információra, azaz nem csak videócsetes szolgáltatás. Egy 5.62.39.247 cím önmagában nem túl egyedi, de egy 192.168.1.88-192.168.1.88 már eléggé, egy 5.62.39.247-172.16.231.122 pedig annál inkább, több irodaépületben esetleg a LAN IP sosem változik.

- A felhasználó által használt DNS-szerverek, amik akár az alapértelmezés szerint az internetszolgáltató által automatikusan beállított DNS1, DNS2 címek, akár a kézileg beállított OpenDNS, akár a Google DNS1, DNS2 címei, egyaránt árulkodóak, hiszen ugyancsak lekérdezhetőek.

Hogy a gépünk érintett-e a DNS leaking szempontjából, a legegyszerűbben a  https://ipleak.net/ oldalon ellenőrizhetjük.  

Természetesen a böngésző ujjlenyomata és a WebRTC is megmókolható illetve lecsapható, viszont nem feltétlenül bölcs dolog, hiszen ezeket az információkat alapvetően azért árulja el a böngészőnk, hogy a webhelyek megfelelően legyenek megjeleníthetőek.

Egy-egy gyanús belépési kísérletnél a hitelesítés ellenőrzésének része lehet a böngésző ujjlenyomat és a WebRTC miatt lekérdezhető információk összevetése azokkal, amiket korábban naplózott a rendszer az adott felhasználóra vonatkozóan.

Ennél sokkal kevesebb információ is elegendő ahhoz, hogy valamilyen anomáliát szúrjon ki egy-egy szolgáltatás egy gyanus belépés esetén, ezért extra, az azonosításhoz szükséges adatokat kérjen majd a felhasználótól. Tételezzük fel, hogy a felhasználó 13:00-kor belép vagy éppenséggel aktívan használ egy korábban indított munkamenetet Budapestről, mondjuk a UPC lakossági hálózatán keresztül, ahol ráadásul igen ritkán változnak az elvben dinamikus IP-címek, közben pedig egy másik eszközön 13:10-kor valaki elsőre megadja a helyes felhasználói nevet és jelszót olyan eszközön, ami a hozzárendelt IP-cím alapján Bécsben van és mondjuk az A1 IP-tartományából kapott publikus IP-t mutatja. Ezen kívül tételezzük fel, hogy a felhasználó ritkán utazgat, nem szokott VPN-t használni, valamint azt, hogy 10 perc alatt nem teleportálta magát Budapestről Bécsbe. A szolgáltatás joggal fog riasztani azzal kapcsolatban, hogy egy támadó egy szimpla jelszólopással próbál hozzáférni a felhasználó fiókjához és függően attól, hogy a korábbiakhoz képest mennyire szokatlan a belépési kísérlet, annál komolyabb extra lépéseket kérhet a felhasználótól az azonosításhoz. Persze ha valaki rendszeresen ugrál akár céges VPN-en keresztül, akár anonimizáló VPN-szolgáltatáson, akár TOR-on keresztül, az okos beléptetés ezt is meg fogja jegyezni és a későbbiekben már nem tekinti szokatlan belépési kísérletnek az előzőhöz hasonló esetet. Ráadásul a legnagyobb webes szolgáltatások azt is nagyon jól tudják, hogy milyen címtartományok tartoznak anonimizáló VPN szolgáltatásokhoz valamint egész precíz listája van a TOR exit node-okról.

Az ilyen típusú ellenőrzésnek ugye semmi köze pl. az UBA-hoz, viszont mégis nagyon hatékony. Kísérletező kedvűek kipróbálhatják, hogy egy USA-beli VPN-re csatlakoznak, nyitnak egy privát böngészőablakot, majd megpróbálnak belépni a Twitter-, Google- vagy Facebook-fiókjukba, közel 100%, hogy mindegyik sikítani fog és további információt kér az azonosításához. A szolgáltatás a felhasználót kötelezheti új jelszó megadására, arra is, hogy végigmenjen egy security checkupon, ami magába foglalja korábbi belépések áttekintését, a megbízhatónak megjelölt eszközök áttekintését, az utolsó felhasználói aktivitások áttekintését, de ha csak a Google- vagy Facebook accountra gondolunk, előfordulhat olyan forgatókönyv is, hogy a szolgáltatás az accountot átmenetileg lezárja, amíg egy moderátor át nem nézi, hogy mennyire is gyanus egy-egy belépési kísérlet, ennek megfelelően a Facebook kérheti, hogy a felhasználó küldjön arcképes személyi igazolvány scant, amin valóban az ő arca van. Persze olyan arc, ami összevethető a korábbi feltöltött képek alapján. Ezen kívül az is lehetséges, hogy a helyreállítást csak akkor hajtják végre, ha a felhasználó engedi, hogy a saját nevén lévő bankkártyán keresztül zároljanak egy jelképes összeget, a bankkártyán lévő névnek pedig egyeznie kell a szolgáltatásban használt névvel.

Ilyesmit alighanem többen láttak már, ideális esetben nem túl sokszor:

A Google-t és a Facebookot két szempontból emelem ki. Az egyik, hogy a Google a G Suite-tal már rég meghódította hatalmas szervezetek szinte teljes kommunikációját már akkor, amikor a mostani szabványok szerinti megfelelőséggel nem is rendelkezett, amiről itt olvashatunk bővebben: https://gsuite.google.com/security/?secure-by-design_activeEl=data-centers   

 

 

Amivel most a Facebook is próbálkozik, a Workplace by Facebook, amivel kapcsolatban amúgy a cég esküszik rá, hogy sokkal komolyabban veszik az abban tárolt, elvben Facebooktól teljesen elválasztva kezelt információkat és ezt szintén igyekeznek külső audit reportokkal alátámasztani

A második, ami miatt ezt a kettőt emeltem ki, hogy ha alapvetően tömegszolgáltatás esetén be lehetett vezetni a fent vázolt, felhasználók biztonságát fokozó módszereket, ebből lenne mit tanulniuk például a céges intranet rendszerek fejlesztőinek.

Előbb írtam, hogy ezek a szolgáltatások nem figyelik a felhasználói magatartást, ami azért nem teljesen igaz, használják, de nem elsődlegesen. A Facebook például sikít, ha egy teljesen friss belépést követően valakinek az első dolga a figyelmeztetések vagy a kétlépcsős hitelesítés kikapcsolása, a fiókhelyreállításra alkalmas email-cím vagy mobilszám megváltoztatása, míg a Google drákói szigorral ideiglenesen jegeli azt a Google-accountot, amelyiknél egy friss belépést követően a felhasználó olyan szűrőszabályt állít be az emailekre, amik éppen a biztonsági figyelmeztetéseket tartalmazó emaileket dobálná kukába, ha pedig a támadó átirányítást állított be egy külső email címre, webes felületen az ezzel kapcsolatos figyelmeztetés egy hétig fog a felső sávban virítani.

Ha egy-egy fontos, akár minősített adatokat is tároló rendszerben eléggé kifinomultan van kialakítva a védelem, ami, mint lájuk, nagyobb részt nem perimeter-based védelemi mechanizmusokra támaszkodik, az igencsak megnehezítheti még a felkészültebb támadó dolgát is.

Nos, mindezt figyelembe kell venni a pentesternek is, akár pusztán no-tech hacking, akár technikaibb módszerekkel próbálkozik. Tételezzük fel, hogy a pentester vagy a rosszindulatú támadó tisztában van azokkal, amiket leírtam, éppen ezért virtuális gépet használ, természetesen a virtuális gépen használt böngészővel. Ekkor a virtuális gépnek minél inkább sikeresen el kell hitetnie a támadott szolgáltatással, hogy hagyományos gép, ami pedig a böngészőt illeti, azt is úgy kell kialakítania, hogy az minél jobban hasonlítson egy mezei böngészőhöz. És tételezzük fel, hogy nem használ TOR-t vagy hasonló csodát, amivel gyanusabbá nem is tehetné önmagát. Persze a portable browser sem megoldás, egyszerűen azért, mert kellően bravúros védelmi megoldás esetén a szolgáltatás észleli, hogy valószínűleg portable browserről van szó. Azaz OPSEC szempontból még az sem a legjobb megoldás, ami egyébként annak tűnik. Akár a pentester, akár a rosszindulatú támadó egy támadásnál annál inkább számíthat sikerre, minél inkább úgy kezeli a virtuális gépet és a böngészőt, mintha az valódi lenne. Például rendkívül gyanus az olyan böngésző, aminek az ujjlenyomata alapján semmilyen addon nincs telepítve, ahogy természetesen az is, ha ugyancsak a fingerprint alapján kiderül, hogy az oprendszer és a böngésző orosz nyelvű, holott a támadott felhasználó angol vagy magyar nyelvűtől eltérő oprendszert és böngészőt sosem szokott használni, orosz nyelvűt sosem használt. Az pedig már szinte biztos, hogy bekapcsolja a vészcsengőt, ha valaki a TOR hordozható böngészőjével próbálkozik, amiben éppen az a gyanus, hogy semmilyen addonja nincs, de NoScript mindig, csak a legszükségesebb betűtípusokat használja és így tovább.

A böngészőnk és a viselkedésünk nem csak valamilyen szolgáltatásba való belépésnél lehet nagyon árulkodó. Néhány hónappal ezelőtt, miután a nagyon sokadik emailt kaptam egy szépnevű USA-beli hoszting szolgáltatótól, hogy költöztessek hozzájuk ezt, azt, amazt, gyanusan olcsón, egy idő után a szolgáltató oldalán kértem egy pre-sales csetes supportot. A beszélgetésből kiderült, hogy a felkínált ár tényleg annyi, amennyit feltüntettek, de csak az első számlázási ciklusban és csak akkor, ha három évre előre fizetek elő, de ha mindez nem lenne elég, az is kiderült, hogy ha az ügyfél európai vagy sejthetően az adatforgalmat jórészt Európa felé kellene biztosítani, ami ennek megfelelően sokkal drágább a szolgáltatónak, akkor háromszoros áron tudják csak biztosítani a szolgáltatást. Gondoltam, magamban, nesze neked net neutrality, puding próbája az éves, ennyire pofátlan szolgáltató esetén nem éreztem különösebb bűntudatot, amikor szűz böngészővel egy USA-beli VPN-szerveren keresztül elindítottam szolgáltatás megrendelését, USA-beli számlázási címet megadva. Ahogy pedig ez jobb helyeken bevett gyakorlat, ellenőrzik a szolgáltatás élesítése előtt, hogy a megrendelő nem spambáró, terrorista vagy hasonszőrű arc-e esetleg. Paypal-lel fizettem volna, azaz a fizetési eszköz alapján nem lehetett következtetni a kilétemre. A szolgáltatást mégsem élesítették a csalásmegelőző rendszer riasztása miatt. Az adott szolgáltató a MaxMind MinFraud szolgáltatását használta, az pedig alighanem abból következtetett rá, hogy valószínűleg nem USA-beli vásároló vagyok, hogy a megrendeléskor használt böngésző nyelve magyar volt a fingerprint alapján, ami meglehetősen ritka lehet a megrendelőik körében. Vagy olyan tényező alapján, amiről nem tudok.

Összefoglalásként elmondható, hogy a felkészült támadó dolgát - persze nem csak webes környezetben - igencsak meg lehet nehezíteni, ha a védelem teljesen különböző technikáit kombináltan használják. A perimeter-based védelem nem elég, a felhasználói viselkedést elemző rendszerek önmagukban még biztosan nem eléggé kiforrottak, ugyanakkor több elegáns, alapvetően a kliensre jellemző technikai sajátosságok lekérdezése, azok összehasonlítgatása korábbi mintákkal, az ahhoz kapcsolódó valószínűségi változókkal már igen hatékony lehet.

Amit még megjegyeznék, hogy nagyon sokszor nem is szükséges olyan, diszkrét, kevésbé diszkrét, de drasztikus módszerek bevetése, mint supercookie-k és hasonló okosságok küldése az ügyfél felé ahhoz, hogy egy felhasználó nagy pontossággal azonosítható legyen. Persze, van, amikor igen, ugyan ez kevésbé tárgya a cikknek. Mire is gondolok? Az FBI a Wikipedia szerint legalább 2002. óta használja a semmitmondó nevű Network Investigative Technique toolkitet, ami nem tűnik túl privacy-barát dolognak. Az is tudvalevő, hogy a nyomozóhatóságok nem ritkán a feketepiacra járnak 0-day exploitokat vásárolni. Természetesen 100%-ig nem zárható ki, hogy ezzel nem élnek vissza, viszont rendszeresen felröppen olyan hír, amikor éppen valamilyen 0-day sebezhetőséget kihasználva sikerült egy-egy pedofilhálózatot leleplezniük a dark weben, ekkor senki sem ítéli el a módszert különösebben. Az egyik ilyen pedofil ügyben a vádemelést követően egy bíró próbálta kötelezni a FBI-t az általuk használt technikák és az összes többi technika felfedésére, amit lehet indokolni mondjuk azzal, hogy csak törvényesen szerzett bizonyíték használható fel, ahogyan Európában is, csak éppen józan ésszel nem. Személy szerint azért nem értek egyet azokkal, akik szerint a privacy mindenek fölött álló és bűnüldöző szervek se használjanak néha etikai szempontból  megkérdőjelezhető módszereket, mert ha lebuktatnak 1000 pedofilt, embercsempészt, bérgyilkost, nagy tételben utazó drogbárót, na meg olyan arcot, akikkel nem szivesen találkoznánk személyesen, emellett 1 ártatlan személy magánszférájába a feltétlenül szükségesnél jobban beletúrnak akár véletlenül, akár szándékosan, ép ésszel belátható, hogy szerencsésebb eset, mintha senkinek a magánszférája nem sérült volna minimális mértékben sem, de tovább ténykedhet 1000 bűnöző a net legsötétebb bugyraiban.

Tökéletes OPSEC nincs. Az pedig a kriminalisztika dogmaként kezelt megállapítása, hogy elkövetés sem létezik nyom nélkül.

Cikkem lényegi mondandója, hogy a felhasználó eszközeiről és viselkedéséről szerzett és naplózott információk nélkül pedig nyilván esélytelen lenne a jelenleg leghatékonyabbnak tűnő biztonsági megoldásokat megvalósítani. Ahogy a Snowden-botrányt követően készült South Park epizódban Cartman anyukája megjegyzi Carmannek: „Tudom, hogy az NSA kínozza a Mikulást, Szivem, de ez a biztonság ára.” Nemrég jegyeztem meg egy ismerősömnek, hogy meg nem tudnám mondani, hogy mennyi könyvet és cikket olvastam el a Snowden-sztorival kapcsolatban, de egyszerűen nem találtam olyat, ami a lényeget jobban összefoglalná, mint a Let Go, Let Gov South Park-epizód, aminek a mondandója van akinek úgymond átmegy, megint másoknak nem, magyar szinkronnal is nagyon jó lett. 

Szabadulószoba a biztonságtudatosságért

2017, november 22 - 11:14

A májusi szerdai előadáson Oroszi Eszter előadását hallhattuk.  Az előadáson keresztül a felhasználók biztonságtudatosságának fejlesztésének egy új, kevésbé emlegetett módszerét ismerhettük meg, aminek a lényegi részét egy, a célnak megfelelően kialakított szabadulószoba jelenti.

Az előadó gyorsan összefoglalta, hogy a hagyományos IT security awareness tréningekkel a legnagyobb probléma, hogy a résztvevők alapvetően túlságosan passzívak, holott az interaktivitás fontossága olyan képesség kialakításában, mint az éberség, elengedhetetlen. Világos, hogy a hagyományos biztonságtudatosságot fokozó tréningek alapvetően unalmasak, mivel már ismert dolgokat mutatnak be, ami ugye kódoltan azt is jelenti, hogy hiába ismer elvben valaki egy bizonyos típusú kockázatot, közel sem biztos, hogy eléggé éber lesz, amikor valaki egy tényleges social engineering támadással próbálkozik.

Eszterék olyan szabadulószobát alakítottak ki, ahol a tréning résztvevői egy időre a támadó bőrébe bújhatnak, az irodaként kialakított szabadulószobában lényegében meg kell találniuk a továbblépéshez szükséges információkat, ami lehet akár egy aktatáskát nyitó kulcs megkeresése a fiókokban vagy éppen egy emlékeztetőt tartalmazó postit-cetli, amit a szoba hipotetikus alkalmazottja, esetleg megpróbált elrejteni. Egyszóval a játékosoknak minél ötletesebben kell turkálniuk használható információk után kutatva, amíg meg nem találják végül a zárolt munkaállomás feloldásához szükséges jelszót.

Szóba került, hogy a többség egész egyszerűen nem szeret turkálni, ami teljesen érthető, hiszen nem ahhoz szokott hozzá, hogy idegen helyen turkáljon. A szabadulószobát a játék közben persze felügyelni kell, így a játékosnak segítséget lehet nyújtani, ha esetleg elakadna az ötletelésben. Több apró siker pedig természetesen fokozza az egész játék élményszerűségét, emellett a játékosok amellett, hogy korábban tudtak róla, valóban tudatosul is bennük, hogy bárki lehet célpont, másrészt hiba vakon bízni a fizikai biztonságban. Azaz akár érzékeny információkat tartalmazó dokumentumokat elzáratlanul hagyni vagy egy munkaállomást lezáratlanul hagyni még akkor is rizikós, ha elvben az irodákba csak a cég alkalmazottjai léphetnek be.

Persze csak elvben, mivel sok-sok helyen mindegy, hogy beléptető kártyával lehet csak bemenni illetve átmenni egy-egy irodába, sok esetben még ez sem zárja ki a tailgating  és a piggybacking  módszerével kivitelezett bejutást. Emellett ahogy az minden, azonosítást igénylő helyen lenni szokott, több munkahelyen az alkalmazottak esetleg kölcsönadják a saját beléptetőkártyájukat. Ahogyan az sem zárható ki, hogy egy támadó új alkalmazottnak adja ki magát és azzal téveszt meg egy alkalmazottat, hogy a beléptetőkártyája valami miatt nem működik, így a feljogosított felhasználó inkább beengedi a sajátjával. A social engineering támadásoknál gyakran visszatérő elem, hogy a támadó az áldozat segítőkészségét használja ki, lévén, hogy alighanem gyakrabban fordul elő, hogy egy arra feljogosított alkalmazott nem tud bejutni valahova, mint annak, hogy kifinomult csalással jusson be valaki egy irodaépület valamelyik részébe. Hirtelen a Deloitte két reklámfilmje jutott eszembe, mindkét esetben a social engineering teremti meg a lehetőségét annak, hogy később a támadók sikeresen férhessenek hozzá egy, amúgy jól őrzött cég hálózatához.

Így könnyítheti meg a támadó dolgát a többlépcsős hitelesítés

2017, november 2 - 15:04

Az olyan, tömegigényt kiszolgáló szolgáltatók, mint a Google vagy a Facebook valamivel több, mint 5 évvel ezelőtt vezették be azt, ami az ebanking környezetekben már gyakorlatilag standard volt: az azonosítón és a jelszón kívül a szolgáltatás a beléptetésnél a felhasználó azonosítása érdekében még valamilyen információt kérnek, aminek a leggyakoribb megvalósítási módja volt a múltban az egyszer használatos SMS-ben érkező token illetve persze a tokengenerátor. Ma persze már sokkal gyakoribb megoldás, hogy egy mobilapp generálja a tokeneket, aminek két-három különböző megvalósítása uralta le a piacot.

A Google Authenticator a TOTP-ra és a HOTP-ra alapuló kódgenerálást egyaránt támogatja. Aki esetleg allergiás lenne mindenre, ami Google, az használhat Duo Mobile-t ami ugyanez a kettő, legjobban elterjedt idő-alapú tokengeneráló algoritmust használja. Ami jelentősen eltérő, de szintén elterjedt app, az Authy, ezen kívül az olcsósága miatt érdemes lehet Yubikey-t használni az azonosítás második lépésében, amit egyre több és több rendszer támogat, emellett lehetőség van arra is, hogy valaki egyszerűen beszerezze a Yubikey API-ját és beépítse a saját rendszerébe. Továbbra is gyakori megoldás a második lépést telefonhívással vagy SMS-sel megoldani.

Főleg ott, ahol tömegigényt kell kielégíteni, nyilván a fejlesztőknek úgy kellett implementálniuk a kétlépcsős hitelesítést, hogy a fiók tulajdonosa számára az se jelentsen fennakadást, ha a tokenek generálásához használt mobil elveszik vagy éppen a mobil nem hívható, esetleg nem tud SMS-t fogadni bármilyen okból. Éppen ezért a 2FA beállításakor a minden ilyen rendszer felhívja a felhasználó figyelmét, hogy mentse le valahova azt a 10 kódot, ami abban az esetben is alkalmas az azonosítás második lépésekor, ha a mobil sehogy sem érhető el, amiben már önmagában van fantázia támadói oldalról.

Mielőtt úgy gondolnánk, hogy legalább a web legnagyobbjai komolyan is veszik a 2FA-t, érdemes tudni, hogy a Facebook esetén a support egyszerűen kikapcsolja a kétlépcsős hitelesítést pusztán azzal, hogy a támadó a fiókhelyreállításnál behazudja, hogy nem tud hozzáférni az áldozat fiókjához, mi több, ezt követően hitelesebben tudja kiadni magát, mint a fiók valódi tulajdonosa. A Google és persze a G Suite esetében azért sokkal jobb a helyzet, mivel egy algoritmus ellenőrzi a fiókhelyreállítási kísérletkor, hogy a felhasználó valóban nem tud-e belépni és persze, ha azt látja, hogy rendszeresen problémamentesen bejelentkezik, mint korábban bármikor, a támadó el sem jut a supportig. Viszont sem a Facebooknak, sem pedig a Googlenek nincs sem kapacitása, sem pedig lehetősége egy-egy bejelentés jogosságát kivizsgálni, ezért nem csoda, hogy inkább lazábbra fogják a figurát a biztonság terén, minthogy felhasználót veszítsenek. Céges környezetben a G Suite adminja lehet rázós célpont, ne felejtsük el, hogy a Facebook is elkezdett nyomulni a Workplace by Facebook-kal, ami később szintén okozhat izgalmas pillanatokat céges környezetben.

Több multifaktoros megoldás összehasonlítását a Wikipedián erre találjuk.

Van viszont egy sokkal, de sokkal húzósabb kockázat az egész kétlépcsős hitelesítéssel kapcsolatban, ami hát persze, hogy az emberi természetet, mint a permanens módon leggyengébb láncszemet célozza.

Azt szoktam mondani, hogy a totális tudatlanságtól már csak a hamis biztonságérzet a veszélyesebb, és tényleg. Amint az egyszeri felhasználó vagy akár egy privilegizált felhasználó beállította a kétlépcsős hitelesítést, onnantól kezdve nyugodtan alhat, hiszen még egy jelszólopás esetén is a támadó nem tud majd továbblépni a 2FA miatt, nemde? Elvben igen. Viszont nem eléggé tudatos felhasználónál éppen ez a hatás tovább feszíti a hamis biztonságérzet és az effektív biztonság közti szakadékot!

Aki használ 2FA-t gyakrabban vagy kevésbé gyakran találkozik olyan, mobiljára érkező SMS-sel, amiben egy-egy szolgáltatás küldi az SMS-t, csak annyit jelez, hogy a belépés sikeres, sikertelen, de ideális esetben be vannak állítva olyan triggerek, amik szokatlan tevékenységkor is SMS-ben figyelmeztetik a felhasználót abban az esetben is, ha egyébként a 2FA-t általában nem SMS-en keresztül használja, hanem valamelyik okosmobil-appal.

Na most képzeljük el, hogy biztonságtudatos, azaz még csak nem is totálisan paranoid felhasználónk kap egy SMS-t az alábbi sablon szövegek valamelyikével:

  • "Your account was logged into from a new browser or device. Review the login: https://oldal.tld/token_helye"
  • "Your account was recently logged into from Safari on Windows."
  • "Password reset code: [öt-hat számjegyű szám] Or reset your password here: http://oldal.tld/token_helye"
  • "Access data for your account has been ordered by you personally or by someone else. Your temporary password: [jelszó helye]"

Az első scenario: szóval landolt egy SMS, amiben kedvesen tudatja velünk a szolgáltatás, hogy mi a belépési tokenünk, amiről tudjuk, hogy csak a helyes felhasználói név és jelszó megadása után szokta kérni a rendszer, aztán esetleg ott egy adathalász oldalra mutató link, az SMS-t pedig egy az egyben a támadó küldte. Az adathalász oldalon már kedvesen elkérhető az áldozat felhasználói neve, jelszava, amit ugye lehet, hogy még kismillió helyen használ.. Mire pedig rájön, hogy adathalász támadás áldozata lett, már lehet, hogy késő. A támadás megspékelhető a második scenarioval kombinálva. 

A második forgatókönyv, alighanem sokkal régebben ismert volt, minthogy figyelmeztetést adott volna ki ezzel kapcsolatban több IT biztonsági cég is, a Symantec a Gmail példáján keresztül mutatja be a támadást az alábbi videóban: https://www.youtube.com/watch?v=_dj_90TnVbo

Tehát a támadó indít egy jelszóhelyreállítást, tokent kér az áldozat mobiljára, majd küld a mobilra egy SMS-t azzal a szöveggel, hogy valaki illetéktelenül belépett a fiójába, a kapott tokent küldje vissza SMS-ben válaszként, ha nem ő volt, a felhasználóban pedig megáll az ütő, nem gondolkozik, nem nézi a mobilszámot, küldi is vissza a támadónak a jelszóhelyreállító tokent, amivel a támadó új jelszót állít be.

Megjegyzem, éppen ez a támadás ma már a Google és G Suite accountoknál nem használható ebben a formában, mivel a fiókhelyreállítás megkezdése előtt a Google korábbi viselkedési adatokat elemez,  további adatokat kér, mint például azt, hogy mikor jelentkeztünk be sikeresen utoljára, honnan, milyen platformról, melyik szolgáltatásba, és így tovább, viszont a Facebook továbbra is sérülékeny! És persze ki tudja, hogy hány és hány vállalati rendszer úgyszintén.

Lehetne elemezni a támadást step-by-step bőven, ami itt a kulcselem, az ijedtség és az azonnaliság kényszere, amik persze hasonlóan kiirthatatlan sajátosságok, mint a tudatlanság. A módszer alighanem annyira hatékony, hogy alighanem még akkor is működik, ha a felhasználó arra a mobiljára kapja ezt a riasztást, amelyiken ilyet fogadni sosem szokott.

Korábban egy ISACA Második Szerdai előadáson volt róla szó, hogy a breachek több, mint fele azonosítók ellopásával van összefüggésben, aminek sejthetően a legnagyobb része nettó jelszólopások. Mint látható, a többlépcsős hitelesítés sem silver bullet, bájos, hogy az illetéktelen hozzáférést látszólag nagyon komolyan megnehezítő megoldás újabb lehetséges, hatékony támadási formák lehetőségét teremtették meg.

Az viszonylag világosan látható, hogy mi nem jelent megoldást. Például a fiókhoz tartozó mobilszám titokban tartása, hiszen a mai világban egész egyszerűen nem lehet mobilszámot titokban tartani, de még ha lehetne, akkor sem lenne túl életszerű, hogy a felhasználó arra rendszeresítsen egy mobilt, aminek a számát titokban tartja, hogy azt csak belépésekhez használja.

Ha többlépcsős azonosításról van szó, eljátszhatunk azzal a gondolattal, hogy egy nagyobb szervezetnél a főadmin gondol egyet, aztán teljesen saját tokengeneráló alkalmazást fejleszt, majd vezet be. Ott meg aztán nagyon-nagyon sok ponton homokszem kerülhet a gépezetbe például akkor, ha azok a véletlen számok mégsem annyira véletlenszerűek, ami az egyik leggyakoribb hiba ilyen alkalmazások implementációjakor. Viszont a támadó miért is bíbelődne ilyennel, amikor ott a fent vázolt, sokkal egyszerűbb módszer? 

Meghívó: Második szerdai előadás / november

2017, november 2 - 11:46
Felhő és a biztonság - trendek, kockázatok

Szeretettel meghívjuk soron következő, 2. szerdai előadásunkra:

Dátum: 2017. november 8., szerda 17:00 óra

Helyszín: MNB - Budapest I. kerület, Krisztina krt. 39., Google térkép >>>

 

REGISZTRÁCIÓ >>>

Előadás leírása:

Jelenleg kétféle cég létezik: akik használnak felhőt és ahol tiltott a felhő, de mégis használják. A felhő teret hódít minden cégnél, nem tudjuk elkerülni, hogy a dolgozók trendi alkalmazásokat, vagy weboldalakat kezdjenek használni. Vajon a Facebook felhőszolgáltatás? Mi az a CloudSOC, CASB és UBA? Mi a trend és az IT biztonság oldaláról milyen esélyeink vannak a céges adatok védelmére? Az előadásból többek között ezek is ki fognak derülni.   Meghívott előadó

Makay Kálmán, mySec

Makay Kálmán 17 éve az IT szakma aktív tagja, 2000-2009 között külsős munkatársként nagyvállalati rendszerek biztonságos üzemeltetéséért felelt és projektek vezetését látta el (Thysenkrupp Presta, MÁV Start). 2010-től a Wizz Air-nél dolgozott és elsődlegesen a PCI-DSS megfelelőség bevezetéséért és folyamatos auditálhatóságáért felelt. 2010-ben megalapítja a mySec-et és igyekszik a szakma számára értékadó információkat átadni. 2014-ben a Symantec-nél kezd el dolgozni IT biztonsági konzulensként, ugyanebben az évben megkapta az ITBN Év Útmutató Szakember díjat.

REGISZTRÁCIÓ >>>

Ransomwarek – már megint, még mindig

2017, október 30 - 14:09

Még januárban az ISACA második szerdai előadásán Balázs Zoltán tartott előadást a ransomware-ek kevésbé ismert tulajdonságait kiemelve. Az eredeti prezentáció ezen a linken érhető el.

Ugyan a ransomware-ek világában sokmindent történt január óta, a lényeg semmit sem változott olyan szempontból, hogy az IT-üzemeltetők mintha nem is tanulnának a korábbi esetekből, az AV-gyártók pedig globálisan tekintve leszerepeltek.

Az előadásban elhangzott, hogy gyakorlatilag nincs olyan platform, ami valamilyen módon ne lett volna érintett eddig valamilyen ransomware-fertőzésben, tényleg semmi sincs biztonságban. Az elhíresült Locky malware-t például újraírták magyar nyelvűre, a zsarolóvírusok nem kímélték az androidos eszközöket sem, míg az iOS-re /*máig*/ csak olyan kódot találtak, ami az ijesztgetésen kívül mást nem csinál.

Az egyre elterjedtebb NAS-okat a SynoLocker küldte kómába, megint más kártékony kódok régről ismert módon CMS-sebezhetőségeket kihasználva fertőztek webhelyeket avagy a webhelyet meglátogató felhasználókat, de gyakran nem aktiválódtak azonnal.

Megint más kártékony kódok linuxot futtató szervereket vagy éppen MongoDB adatbázismotorokat támadtak meg, ezeket az eléggé baljós leakware és doxware nevekkel illették a kutatók.

Az első komolyabb zsarolóvírus-támadás 2013-ban történt, ugyan technikailag megjelenhetett volna korábban is, adja magát a kérdés, hogy miért éppen 2013-ban bukkantak fel. Az előadó szerint a magyarázat, hogy ekkorra vált eléggé elterjedtté a TOR és maga a bitcoin, még a tudatlanabb felhasználóknak sem jelent különösebb nehézséget bitcoinban váltságdíjat fizetni. Megint más esetben maguk a malware-ek loptak bitcoint.

A fejlett ransomware-ekkel kapcsolatban érdekesség a korábban ismert kártékony kódokhoz képest, hogy közülük több szelektív olyan értelemben, hogy nem csak azt ellenőrzi, hogy nem virtuális gépen fut-e, de még azt is, hogy melyik országban és csak olyan országokban kér váltságdíjat, amelyik esetében feltételezhető, hogy a felhasználó fizetőképes. Céges környezetben a főként szignatúra-alapú felismeréssel működő módszerek leszerepeltek. Míg korábban több napig is fertőzött maradhatott egy céges gép anélkül, hogy különösebb kár keletkezett volna, egy ramsomware-fertőzés esetén már 15 perc is túl sok. Sajátosság továbbá, hogy a ransomware-készítők figyelnek a saját reputációjukra olyan értelemben, hogy valóban biztosítják a felhasználóknak a feloldáshoz szükséges kulcsot a váltságdíj megfizetését követően az esetek többségében, mi több, a váltságdíjat követelő üzenetben még telefonos supportot is kínálnak arra az esetre, ha a felhasználó nem lenne technikailag eléggé felkészült a fizetésre.

Céges környezetben gyakorlatilag máig nincs jobb megoldás, mint a rendszeres biztonsági mentés készítése mégpedig olyan hordozóra, ami csak a biztonsági mentés idejére írható, egyébként air gapped.

Otthoni védekezésnél egy jobb antivírus termék mellett érdemes lehet a böngészőben valamilyen szkriptblokkolót is használni, amilyen az Adblock vagy éppen a NoScript, mivel a ransomware-ek akár olyan oldalak hirdetésein keresztül is fertőzhetnek, ami alapvetően megbízhatóak.

Trükkös megoldás, de hatékony a Hitman Pro alkalmazása, ami képes akár virtuális gépnek álcázza a valódi gépünket, így csökkentve egy bekerült malware aktiválódásának kockázatát. A valódi gép virtuális géppé való álcázásával kapcsolatban az EvilBit posztjában már évekkel korábban olvashattunk.

Érdemes megjegyezni, hogy a ransomware-ek több kutató szerint meglepően bénák, ahogy arra azóta többen is felhívták a figyelmet például ebben a posztban

A legnagyobb kárt okozó malware-ek is sok esetben néhány egyszerű hardening trükkel egyszerűen megfékezhetőek lennének, mint amilyen a PowerShell lelövése, az Office-makrók tiltása vagy az UAC kényszerítése, ezekhez már automatizált eszköz is készült

A cikk ugyan több, mint fél évvel ezelőtt íródott, de alapvetően nem veszette aktualitását, hirtelen két gondolattal egészíteném ki. A Kaspersky egy friss kutatásából kiderül, hogy ugyan valóban az iOS van kitéve legkevésbé bármilyen típusú malware támadásnak, mindössze 600 kártékony kódot azonosítottak, határozottan egy olyan tendencia látszik kirajzolódni, hogy az iOS és az OSX a célzott támadásoknak egyre inkább ki lesz téve, viszont továbbra sem várható, valamiféle iOS és OSX rendszereket érintő malware robbanás. 

A mai értelembe vett első ransomware-ek valóban 2013. óta léteznek, Csizmazia István egy nemrég tartott előadásában igazi kultúrtörténeti unikumot hozott szóba. Még 1989-ben egy feketekalapos több, mint húszezer floppyt postázott szét, ami a címzettek gépét lefertőzte és váltságdíjat kért. Alighanem minden idők egyik leginkább elbénázott víruskampánya volt, ugyanis a zsaroló olyan helyre kérte a válságdíjat, ami alapján a nyomozók már kényelmesen tudták azonosítani az elkövetőt.

Második szerdai előadás a WITSEC Szakmai Napon

2017, október 5 - 10:58
Az I. Nemzeti Kiberversenytől Genfig
a Cyber 9/12 tapasztalatai és hatásai egy magyar csapat szemszögéből

 

FIGYELEM! RENDHAGYÓ HELYSZÍN ÉS KEZDÉSI IDŐPONT! ANGOL NYELVŰ BESZÉLGETÉS!

Dátum: 2017. október 11., szerda 16:00 óra

Helyszín: PwC - Budapest VI. kerület, Bajcsy-Zsilinszky út 78., Eiffel Palace

 

Az ISACA Második Szerdai előadás a WITSEC Szakmai Napon belül kerül megrendezésre. A részvétel az egész szakmai napon díjmentes, de regisztrációhoz kötött!

REGISZTRÁCIÓ >>> https://www.eventbrite.com/e/witsec-pro-day-szakmai-nap-tickets-35920319643

 

A kerekasztal beszélgetés leírása:

"Az áprilisi Cyber 9/12 versenyre csapatunknak első ízben volt lehetősége kijutni azáltal, hogy a Pro Day-en megrendezésre került, I. Nemzeti Kiberversenyen, első helyezést értünk el. Bár mind a négy versenyző az NKE Rendészettudományi Karának civil szakirányos hallgatója volt, mind a négyen eltérő ismeretekkel rendelkeztünk, amelyeket Dr. Gyaraki Réka rendőrőrnagy asszony fogott össze. Bártfai Fanni másodéves nappali munkarendű hallgatóként, Margitics József elsőévesként, Molnár Tibor végzős, Mészáros István pedig másodéves levelezős hallgatóként mérhette össze a tudását más csapatokkal.

A svájci megmérettetés során – a magyar fordulóhoz hasonlóan – egy fiktív, kórházakat érintő támadássorozatra kellett 4, külön álló alternatívát kidolgoznunk hiányos információcsomag alapján. Bár sajnos helyezést a csapatunk nem ért el, a kapott kritikák és észrevételek alapján egy megújult csapattal a következő évben is tervezzük a versenyen való indulást.

Az ISACA Második Szerdai előadásán a fentiek alapján, eddigi tapasztalatainkról és élményeinkről fogunk beszélgetni."

  • A beszélgetés moderátora: Rónaszéki Péter
  • A program angol nyelvű! 

REGISZTRÁCIÓ >>> https://www.eventbrite.com/e/witsec-pro-day-szakmai-nap-tickets-35920319643

 

 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer