A korabeli GDPR kapcsán Könyves "CISO" Kálmán hiába mondotta a pápai auditornak:

A korábbi adatklasszifikációval foglalkozó cikkünk miatt jónéhány üzenetet kaptunk, amelyek azt taglalták, miszerint hülye az, aki a klasszifikációt és a fájlok megcímkézését a felhasználókra bízza, sokkal hülyébb, mint a felhasználó, aki egyébként is hülye.

A népi bölcselettel kezdeném a reflektálást: Olcsó húsnak, hülye felhasználónak híg az awarenesse.

Nem tudok egyetérteni az olyan kijelentéssel, hogy azért nem lehet a klasszifikációt a felhasználóra bízni, mert inkompetens, meg hogy honnan is tudná, hogy mi van abban a fájlban, és azt hova kell besorolni.

Ez a kijelentés azért nem lehet igaz, mert a felhasználó dolgozik az adatokkal, és nem az adat a felhasználóval.

Azon lehet vitatkozni, hogy 

• nem akarjuk még ezt is a felhasználó nyakába varrni,
• túlterheltek a felhasználók és emiatt hibázhatnak a címkézésnél és félrejelölnek valamit,
• bonyolítja a folyamatokat,
• azért vannak adatgazdák, hogy végezzék el a besorolást,
• Vettünk csilliárdért DLP-t, az majd megcsinálja automatikusan.

A felhasználóktól való félelem – pontosabban, a felhasználói felzúdulások generálta belső politikai csatározások valóban óvra intheti a felelőst, viszont azt is figyelembe kell venni, hogy a szervezet számára (nem csak a GDPR kapcsán, de nyilván most ez a legnagyobb drive) kiemelten fontos területről van szó.

Minden változás problémás, de a tudatossági oktatások nem véletlenül (lennének) fontosak:

• ha a felhasználó megérti, mi a szerepe ebben a folyamatban,
• hogy szemben az automatikus eszközök általa nem befolyásolható besorolással, a felhasználói címkézés sokkal több lehetőséget ad az kezébe (mondjuk nem blokkolódik el a kimenő levele azért mert az automata félreismert valamit),
• hogy ő maga hatással (saját kontroll) lehet az adattranszfer folyamatokra

 szerintem szívesebben válik kvázi irányítóvá, mint egy láthatatlan és automata folyamat és preventív kontroll tehetetlen elszenvedőjévé.

A felhasználói túlterhelésből/oda nem figyelésből fakadó rossz besorolás valóban előfordulhat, viszont mivel a rossz címkét érvényesítő felhasználó, vagy az adathoz hozzáférő, azzal dolgozó másik felhasználó képes az átcímkézésre (reklasszifikáció!) – sokkal valószínűbb, hogy a következő hozzáféréskor, megnyitáskor, stb. képes a klasszifikáción és a címkén változtatni, szemben az automatával, amely majd valamikor, talán fél évente vagy évente egyszer majd végignyalja a fájlshareket és talán módosítja a besorolást.

Kicsit úgy érdemes ezt felfogni, mint az opensource fejlesztéseket: a jogosultsággal rendelkezők közössége  képes javításokat ajánlani, vagy maguk is képesek elvégezni azokat.

Egy másik érv a manuális címkézés mellett, hogy tapasztalatom szerint a vizualizációs jegyek az adott dokumentumban óhatatlanul is arra késztetik a felhasználót, hogy gondolkozzon el azon, helyes-e a dokumentum besorolása?

Ne felejtsük el, a címkék nem csak metaadatban, de a dokumentum fejléc-lábléc részében is elhelyeződnek.

„- Vajon a Gyula mi a frászért jelölte ezt a dokumentumot GDPR-nak/Internal Only-nak, amikor CSAK ez és ez van benne?” – hangozhat el egy reklasszifikációt felvető gondolat :) - amelyet vagy követ egy Gyulához intézett kérdés, vagy nem, de megtörténhet az átcimkézés/reklasszifikáció, vagy éppen megerősítést nyerve helyben hagyódik a besorolás.

Automata eszköz esetében a következő reklasszifikációs kérdés hangzana el:

„- Mi a krva anyjáért szpat ez a bzi fs már megint?!” – majd a felhasználó a security csoportról hasonló kedves gondolattal emlékezne meg, azokról, akik a nyakába szabadították ezt a bzi fst (már megint).

Nyilván azzal is lehet segíteni a felhasználónak, illetőleg azzal is el lehet kerülni a folyamatok túlbonyolítását, ha a dokumentumsablonok már eleve a megfelelő címkével vannak ellátva. Ilyenkor, ha valaki a „Bizalmas szerződéssablon” template-ből dolgozik, abból készít új dokumentumot, nyilván már nem kell még egyszer megcímkéznie a kész dokumentumot.

Az adatgazdákkal kapcsolatban az a poénom jut csak eszembe, amit a DLP és adatklasszifikációs tréningeken mindig elsütök: A DLP projektmegbeszélésen általában azt jelölik adatgazdának, aki utolsónak ér be a meetingre.

Nyilván arra vonatkozik az axióma, hogy nagyon egyszerű egy osztályvezető/főosztályvezető/csoportvezető nyakába varrni az adatgazda szerepkört: - Ő a góré, ő felel az adatért!

Ez azonban szerintem rossz megközelítés.

Adatgazdának jelölni ugyanis csak olyan személyt lehet, aki az adatról a lehető legtöbbet tudja, és a legtöbb információval rendelkezik a sértetlenség-bizalmasság-rendelkezésreállás szentháromság vonatkozásában az adat rendeltetésszerű, üzemszerű keletkezéséről, felhasználásáról, esetleges továbbitásáról, megosztásáról.

Namost van, ahol ez a személy véletlenül az adott területi vezető, de nem minden esetben - viszont azt nehéz tagadni, hogy pl. egy új, létrehozott dokumentum esetében az adott felhasználó rendelkezik ezen információkkal. Lehet, hogy nem minddel, de hogy általában az adat/fájl létrehozójánál több információ áll rendelkezésre, mint egy "kijelölt adatgazdánál" az szinte bizonyos.

A DLP rendszerek és automatikus discovery eszközökkel kapcsolatban továbbra is az a véleményem, hogy a hosszú futásidő, a keresések által okozott többletterhelés az eszközökön, valamint a tökéletlen adatfelismerők és validátorok használata miatt nagyon javasolt alapos teszteket végezni a bevezetés előtt – szemben egy felhasználó-hajtotta címkézővel, ahol igazából nincs szükség nagyon alapos tesztekre (és amúgy is általában faék egyszerűek).

Nyilván a címkézők esetében ellenérvként ott van, hogy a bevezetés az agentek vagy Office beépülők miatt ki kell tolni az alkalmazást a munkaállomásokra, és van, ahol ez is igen fájdalmas tud lenni.

A legfontosabb azonban az, hogy ha a felhasználót hülyének, inkompetensnek tartjuk arra, hogy eldöntse egy fájl besorolását – akkor érdemes azon elgondolkodni, hogy ezek szerint hülyékre és inkompetensekre bíztuk a vállalat legnagyobb értékét: az adatvagyont.

Ez tehát nem lehet érv a felhasználói adatklasszifikáció ellen!

Egy olyan kivételes adathordozó eszköz került a Secret Junkie tesztasztalára, amelynél előny, ami más adathordozóknál hátrány: adott idő után ez a tároló ugyanis elfelejti (megsemmisíti) a rajta tárolt adatokat.

Self-destruct adattóroló? De miért?

Létezik egy speciális, légréselt (air-gaped) környezetek esetén használt fogalom, a cross-domain-data-transfer, amely a zárt és védett hálózatba befelé, vagy a zárt és védett hálózatból kifelé irányuló adatforgalmat jelenti.

Arról van szó, hogy ha van nekünk egy zárt és a normál hálózattól leválasztott/szeparált/izolált hálózatunk, akkor az abba befelé irányuló hálózati forgalmat még csak-csak tudjuk egyirányúsítani – tehát csak egyutas, befelé irányuló adatforgalmat engedélyezni a számára (erre szolgálnak az adatdiódák), nade a zárt hálózatban keletkező – és gyakran szigorúan titkos, nemzetbiztonságilak minősített vagy egyenesen „Emberek fognak meghalni, ha ez illetéktelen kézbe kerül” típusú – adatok esetében is szükséges az adat kiléptetése, kihozatala a zárt környezetből – hiszen az adat nem önmagáért jön létre, hanem hogy dolgozzanak vele.

Szóval ilyen esetekben mindig mindenki vakarja a fejét:

- Duplázzuk meg az adatdiódát, és legyen egy csak kifelé vezető szál?

- Vagy milyen adathordozón lehet ezeket az ott keletkezett dokumentumokat kihozni és biztonságosan szállítva átvinni egy másik hálózati környezetbe?

- Oké, hogy kihozzuk, de az adathordozót megfelelően le kell üríteni, nem férhet hozzá senki az adatokhoz, wipeolni kell, ledarálni?

- Vagy mit csináljuk az adathordozóval?

Az ilyen cross-domain funkciók támogatására készült a svéd Advenica speciális pendrive eszköze, amely legfontosabb tulajdonsága, hogy a felprogramozásának megfelelően bizonyos idő után megsemmisíti a rajta tárolt adatokat.

Az üzenet öt másodpercen belül megsemmisíti önmagát

A SecuriRAM esetében nem fordulhat elő, hogy az eszközön kihozott dokumentumok törlése után az adatok helyreállíthatók lennének: az eszköz ugyanis „felejtős” volatilis memóriában tárolja a rámásolt adatokat, amely memória a programozott timernek megfelelően elfelejtődik (megsemmisül), majd tuti-ami-tuti, meg felül is íródik.

Advenica SecuriRAM

A hagyományos tárolók esetében non-volatile memóriák kerülnek felhasználásra, ilyen tárolók vannak a szabvány pendrive eszközökben, de ilyen „nem felejtős” memória flash, az SD kártya, MMC, stb.

Ezeknél a hagyományos eszközöknél a normális és elvárt működés, hogy energiaforrás nélkül is megőrzik a tárolt adatokat, míg ezzel szempen a volatilis memóriák esetében az az elvárt működés, hogy tartalmukat csak addig őrzik meg, amíg „áram alatt vannak”. Gondoljunk a számítógépünk memóriájára – abban is csak addig találhatók meg az adatok, amíg nem szűnik meg a memória modul energiaellátása.

Az Advenica SecuriRAM egy pendrive formájú eszköz, de rendelkezik saját energiaellátással, egy beépített akkumulátorral, amelye az USB porthoz csatlakoztatva tölthető.

A saját áramforrásnak köszönhetően a „felejtős” memóriába másolt adatok és dokumentumok az akkumulátor töltöttségi állapotától függően egész addig megmaradnak és elérhetők, amíg az akksi le nem merül. Ha lemerül, az eszköz elfelejti a tárolt adatokat, mintha sose-lettek-volna (hiszen nem is kerültek permanens tárolásra).

Jópofa biztonsági funkciók: timer, pánik gomb

Az eszköz alapból 24 órás adatmegőrzéssel rendelhető, de extra díjért gyakorlatilag bármilyen megőrzési intervallummal rendelhető, mondjuk akár 30 percessel: a rámásolt adatok 30 perc után elfelejtődnek (mintha SLV: sose-lettek-volna).

Az eszközön található két gomb is: a két gomb bizonyos ideig tartó együttes lenyomása aktiválja a felejtés – és tuti, ami tuti a zéroizációt, azaz a sok nullával történő automatikus felülírást is.

Nem csak pánik esetén tesz a manuálisan indikált felejtés jó szolgálatot, de mennyivel egyszerűbb így helyreállíthatatlanul leüríteni az eszközt, mint több lépcsős wipe eljárással megtisztítani?

Na jó, de miért jó mindez?

Azért mert lehetőség van a zárt hálózatból „Emberek fognak meghalni, ha illetéktelen kézbe kerül” típusú dokumentumokat és adatokat úgy kihozni, hogy ezek az adatok bizonyos idő után automatikusan megsemmisülnek – és nem maradnak rajta az adathordozón, sőt nem állíthatók helyre az adathordozóról.

Nem felejtődik az eszközön, nem kell wipe-olni, nem kell azon aggódni, hogy elhagyták az eszközt (nyilván a megfelelő titkosításról érdemes gondoskodni!): az eszköz a programozásának megfelelően el fogja felejteni a tárolt adatokat és ezek az adatok nem helyreállíthatók (mivel soha nem rögzültek permanensen, sőt még felül is íródott az adatterület).

A cross-domain eszközök családjába tartozó SecuriRAM tehát kiválóan alkalmas tehát a zárt hálózatokból történő kifelé irányuló adatmozgatásra: egy magas védelmi szintű hálózatból lehet a segítségével úgy adatokat kihozni, hogy az adathordozóval nem kell törődni: helyreállíthatatlanul elfelejtődik a rajta tárolt adattartalom.

És a hátrányok

Sajnos az eszköz 64MB tárolókapacitással érhető el: ezen jó eséllyel elférnek a bizalmas dokumentumok és adatok – de azért ez az eszköz nem alkalmas arra, hogy sokszáz megányi adatot mozgassanak rajta.

Csak FAT fájlrendszert támogat, igaz, ez a 64MB tárolókapacitás mellett nem feltétlenül hátrány, de jó vele tisztába lenni.

A GDPR kapcsán számos esetben felmerült az a kérdés, hogy ha nem tudjuk meghatározni valahogy, mely adatok tartoznak a hatóköre alá – azaz, mely fájlok tartalmaznak személyes adatokat – akkor hogyan követjük nyomon ezeket az adatokat, illetve hogyan tudunk védelmi intézkedéseket biztosítani ezekkel az állományokkal kapcsolatban.

Nyilván nem csak a GDP szempontjából fontos, hogy valamilyen módon besoroljuk az a százhetvenmillió fájlt, amelyek a fájlszervereinken és a felhasználók munkaállomásain találhatók: bármilyen adatszivárgásvédelmi megoldás bevezetéséhez is erre van szükség, tehát az adatklasszifikáció kiemelt fontosságú ezekben a projektekben.

Az adatklasszifikáció ugye nem más, mint az adat valamely szempontok szerinti osztályba sorolása, annak érdekében, hogy az adott adatosztályra megfelelő védelmi (és természetesen tárolási és felhasználási) intézkedések legyenek hozhatók.

És akkor már ott is tartunk az adatvagyon leltár misztikus témakörénél...

A DLP gyártók előszeretettel hangsúlyozzák, hogy az ő rendszerükben van eDiscovery/Discovery/Crawler/stb. modul, amely automatikusan végigmegy a megadott tárterületeken (és adatbázisokban) és a felprogramozásának megfelelően megtalálja és feltárja a szenzitív adatokat, és amelyeket akkor már meg is fog tudni védeni.

Ez a kijelentés igaz, de fenntartásokkal kezelendő. 

Automatikus adatklasszifikáció

Az automatikus adatklasszifikáció során az adatfelismerő/feltáró modul valamilyen adatfelismerésen alapulva találja meg az érzékeny adatokat és jelöli meg a DLP számára, mint védendő információt.

Adatfelismerési lehetőségek:

• Kulcsszavas felismerés (ha az adott adatban/fájlban szerepel az „alma” ÉS/VAGY a „körte” LEGALÁBB háromszor, a szabály illeszkedik és az adat megfelel a kulcsszavas szabálynak)
  
  
• Reguláris (regexp) felismerés (pl. durva IP cím felismerő kifejezés: \b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b – de ez illeszkedik az 1.1.1.1-re is)
  
  
• Reguláris felismerés, algoritmusos validációval (az előző példából kiindulva, az illeszkedés pontatlan, de egy algoritmussal validálható, hogy a regexp-el felismert string valóban IP cím-e, például bankkártya-szám esetében Luhn-algoritmus a validátor),
  
  
• Gépi tanulás (ismertessük meg a rendszerrel, hogy néz ki egy árajánlat, aztán ismertessük meg a rendszerrel, hogy néz ki ami nem árajánlat, és akkor a rendszer képes lesz felismerni az árajánlatot)
• Indexelés és digitális lenyomatolás (a felismerendő adatról hash lenyomatok képződnek, és a rendszer innentől részleges egyezéseket és képes lesz majd észlelni, csak ugye előbb meg kell mondani a rendszernek, milyen fájlokat és adatokat indexeljen vagy lenyomatoljon!!)
  
  
• Illetve ezek kombinációja.

Nagytömegű adatmennyiség esetén kézenfekvő módszernek tűnik az automatikus klasszifikáció, hiszen felprogramozzuk a rendszert, elengedjük, és már meg is van az adatklasszifikáció, a DLP rendszer már tudja is milyen adatokat kell megvédeni.

Az első probléma ezzel kapcsolatban az, hogy a felismerések meglehetősen pontatlanok, illetőleg a rendszer betanítása se nem egyszerű, se nem gyors. Ráadásul, valakinek meg kell tanítania a rendszert, de ki lesz az, aki az összes szenzitív információt felméri a szervezeten belül, majd leképezi az adatfelismerő rendszer számára?

A második probléma az automatikus rendszerrel kapcsolatban, hogy naponta irdatlan tömegű új állomány és adat képződik egy nagy szervezeten belül, amelyek nem feltétlenül fognak egyezni a már felprogramozott adatfelismerésekkel, viszont arra nincs lehetőség, hogy az adatfelismerő komponens folyamatosan tunningolásra, finomításra, bővítésre kerüljön. Ennek az lesz az eredménye, hogy lesznek olyan adatok, amelyeket a rendszer nem lesz képes felismerni és emiatt majd megvédeni.

A harmadik probléma az adatklasszifikációval a reklasszifikációs folyamat maga: azaz a rendszernek periodikusan újra és újra ellenőriznie kell az adott fájlokat, tartalmaznak-e még olyan szenzitív adatokat, amelyekre valamely adatfelismerő szabály egyezik. Ez tehát egy soha véget nem érő történet, egy kedves barátom nemrégiben fejezett be egy nagyvállalatnál egy adatklasszifikációs projektet, amely csaknem 1 évig tartott, és most kezdheti előröl: 1 év alatt annyi új adat keletkezett és annyira megváltozott az adatstruktúra, hogy reklasszifikálni kell az adatvagyonleltárt.

A negyedik probléma műszaki jellegű: az adatok és fájlok feltárása nagy terhelést tesz a fájlszerverekre, el lehet képzelni, hogy amikor egy discovery fut, minden egyes fájlt a rendszer átrángat magához, szétszedi, kinyeri belőle és megpróbálja felismerni az adattartalmat. A hálózatosok rémálma különben, még akkor is, ha a jobb rendszerekben lehet paraméterezni a sebességet és a feldolgozást. (És akkor még nem is beszéltünk az irdatlan tömegű, képi formátumú adatról: szkennelt PDF és JPG állományok, amelyekhez már a rendszernek OCR komponenssel is kell rendelkeznie.)

Manuális adatklasszifikáció

Nem kell megijedni, nem arról van szó, hogy a CISO-nak kézzel, minden egyes fájlt be kell sorolnia, nem.

A manuális klasszifikáció lényege, hogy az egyes fájlok besorolását nem egy automata rendszer végzi, hanem az a személy, aki a legjobban ismeri annak a fájlnak a tartalmát – az a személy, aki létrehozta vagy dolgozik vele.

A felhasználó.

Ezek az önálló klasszifikációs (labeling, tagging) rendszerek beépülnek a felhasználók Office alkalmazásaiba és a Windowsba és segítségével a felhasználó az általa létrehozott, megnyitott, módosított dokumentumokat és akár emaileket.

Microsoft Azure Information Protection (Word komponens, címke és alcímke kategóriák)

Microsoft Azure Information Protection (Word komponens, GDPR-ra címkézve)

Boldon James Classifier (Word komponens, "Nyilvános" minősítés

Természetesen a tagging/labeling rendszerek csak fájlokkal tudnak dolgozni, adatbázisokban nincs lehetőség címkéket elhelyezni (az automata, DLP discovery rendszerek többsége képes adatbázisokból is tanulni, illetve onnan származó adatokat felismerni).

A labeling rendszereknek az előnye, hogy (elvileg) sokkal pontosabb klasszifikációt eredményeznek: maga a felhasználó - aki az adott állománnyal dolgozik – sorolja be az adatot valamely adatosztályba. A reklasszifikáció is sokkal gyorsabb és pontosabb, ha a dokumentum már nem tartalmaz szenzitív információkat, a felhasználó egyszerűen átteszi egy másik adatosztályba a dokumentumot.

Az ilyen tagging/labeling rendszerek beépülhetnek Exchange szerverbe, Officeba, Outlookba, OWA-ba, SharePointba, és persze az Explorer-be – nyilván attól függően, hogy melyik gyártóval kerül a szervezet kapcsolatba.

Boldon James Classifier (Explorer komponens)

Boldon James Classifier (Explorer komponens, ikonvizualizáció)

A labeling/tagging rendszerek összekapcsolhatók a jobb DLP megoldásokkal (nem véletlenül, a labeling vendorok és a DLP vendorok szoros barátságot ápolnak), képesek felismerni a fájlokra tett címkéket, és ezek alapján védelmi intézkedéseket foganatosítani.

A címkéző rendszerek többnyire a fájlok metaadataiba helyezik el a jelöléseket, gyártótól függően azonban van lehetőség az alternate data stream (ADS) használatára is: az olyan rendszerek, amelyek támogatják az ADS-t, bármilyen fájlt képesek megtaggelni, míg a csak metaadattal dolgozók csak olyan fájlokat tudnak megjelölni, amelyeknek van hozzáférhető metaadat blokkja – praktikusan az Office és PDF dokumentumokra korlátozódnak.

A DLP és content filter eszközök képesek tehát észlelni ezeket a címkéket, és egyszerű szabályokkal kontrolálni az ilyen fájlok mozgását (pl: az Internal Only címkéjű fájlok nem hagyhatják el a szervezetet, míg a GDRP jelölésű fájlok email vagy web továbbítása naplózásra és vizsgálatra kerül.).

Boldon James Classifier (Outlook komponens, "Titkos" minősítésű levél/csatolmány küldésének blokkolása) 

A legtöbb labeling rendszer rendelkezik valamilyen CLI-alapú komponenssel (vagy saját alkalmazás, vagy PowerShell), amely összekapcsolható a DLP rendszerekkel és automatikus adatklasszifikáló rendszerekkel.

Microsoft Azure Information Protection (PowerShell klasszifikáció)

Ilyen integráció esetén ha a DLP rendszer Discovery komponense valamely felprogramozott rutin alapján felismer szenzitív adatot egy dokumentumban, képes meghívni a labeling rendszer CLI-interfészét, amely a megfelelő címkével fogja ellátni az adott dokumentumot.

Ez az integráció a reklasszifikációt teszi manuálissá: a DLP rendszer automatikus modulja által felismert (vélt vagy valós szenzitív adat) adatot a címkéző rendszer automatikusan megtaggeli, de ha a felhasználó nem ért egyet a besorolással, a dokumentumot szerkesztés/módosítás közben átsorolhatja másik adatosztályba (amelyre a DLP rendszer más védelmi szabályt fog már foganatosítani).

Microsoft Azure Information Protection (PowerShell komponens, adatleltár készítése mappából)

Látható, hogy a labeling rendszerek nem védelmi megoldások, nem arra készültek, hogy megvédjék az adott fájlt (bár vannak gyártók, akik még védelmi funkciókat is biztosítanak), de a védelmi rendszerek keze alá dolgozva növelik a védelmi rendszerek hatékonyságát és csökkentik a pontatlan felismerésekből származó false-positive arányt.

A legnagyobb értéke azonban (szerintem) a labeling rendszereknek az, hogy NEM az IT biztonsági vagy üzemeltetési területnek kell az adatosztályozással foglalkoznia, az adatokat besorolnia vagy reklasszifikálnia: ezt a feladat (és felelősség!) átterhelhető arra a személyre aki a legpontosabban meg tudja mondani, mit tartalmaz az adott fájl: a fájlal dolgozó felhasználóra.

Hardveres vagy szoftveres titkosítás?

A „Hogyan válassz titkosított adattárolót?” sorozat első részében a biztonsági minősítéseket néztük meg kicsit alaposabban. A sorozat második részében a fizikai ellenállóképességet jellemző rövidítésekről esett szó. A harmadik részben pedig azt járjuk körül, hogy melyek a hardveres és szoftveres titkosítások előnyei és hátrányai.  

Ugyan hitvita szokott az ilyen kérdésből kialakulni, de próbáljuk meg kicsit konstruktívabban megközelíteni a témát.

Sebesség

A hardveres titkosítás (az adattároló eszközbe épített titkosító áramkör végzi a kriptográfiai műveleteket (enkriptálás, dektriptálás)) – hívei a sebességet szokták felhozni első érvként: a titkosító áramkör gyorsabb, mintha egy szoftver a számítógép processzorát terhelve végezné el a titkosítási műveleteket.

Ezt az érv az egyre erősödő processzorok világában nem minden esetben állja meg a helyét, egyszerűen már olyan nagykapacitású CPU-kkal működnek a munkaállomások, hogy ez az érv nem minden esetben igaz.

Az biztos, hogy a titkosítási műveletek erős terhelést okoznak, tehát egy terhelt processzor számára igencsak megerőltető feladat, és ezt a felhasználó is meg fogja érezni a sebességen.

Biztonság

A hardveres titkosítás mellett érvelők második főtétele, hogy mivel a titkosítási folyamat a számítógéptől függetlenül, az adattároló titkosító áramkörében megy végbe, a titkosításhoz szükséges kulcsok soha nem kerülnek ki a titkosító áramkörből, tehát nem szerezhetők meg a számítógép memóriájának elemzésével.

Touché! – Ez bizony ül, a szoftveres titkosítás legnagyobb hátránya, hogy a titkosító szoftver megkerülésével/manipulációjával, vagy a számítógép processzorának és memóriájának vizsgálatával hozzáférhetőek lehetnek a titkosító kulcsok, azokon keresztül pedig kompromittálhatók a védett adatok.

Hibrid megoldások problémája

A tisztán hardveres vagy szoftveres megoldások (AxCrypt, TrueCrypt) mellett megjelentek a vegyes módusú eszközök: azaz a titkosítás a titkosító áramkörben történik, viszont a számítógép felől szükséges valamilyen kulcs vagy jelszó, amellyel az áramkör hozzáfér az eszközben tárolt titkosításhoz szükséges kulcsot (rosszabb esetben a felhasználó által megadott jelszó feldolgozott, hashelt eredménye lesz a titkosító kulcs).

Mint látjuk, a hibrid megoldás se ilyen se olyan, de ettől nem lesz sokkal biztonságosabb: a felhasználó által az eszköz titkosítását feloldó jelszó keyloggerrel vagy a memóriából megszerezhető, onnantól kezdve pedig a védelem megkerülhető.

Átláthatóság problémája

A szoftveres megoldások – és itt konkrétan a forráskóddal elérhető, többnyire opensource/GPL/stb. szoftverekre gondolunk - mellett megemlítik érvként, hogy pontosan lehet tudni, mit és hogyan csinál a szoftver, azaz backdoor és mindenféle kiskapu nélküli megoldások – hiszen ellenőrizhető a forrás és a működés. 

A hardveres megoldások esetében viszont nem tudjuk, mit és hogyan csinálnak, azokban bármi, és annak ellenkezője is előfordulhat: nem lehet ellenőrizni az eszköz működését.

Ez bizony ül, valóban a zártság miatt nem lehet tudni, hogy van-e kiskapu, vagy nem-e találtak fel valami új titkosítást a gyártóéknál (titkosítással kapcsolatban, ha azt halljuk, hogy „Az általunk fejlesztett és teljesen egyedi titkosítás... – MENEKÜLJÜNK!”).

Viszont azt el kell mondani, hogy ezért fontosak azok a tanúsítványok, minősítések, amelyeket korábbi fejezetben kicsit megnéztünk („Mit jelentenek a FIPS, CC-EAL, BSI, stb. tanúsítványok?”), ezek bizonyítják, hogy a megoldás ellenőrzött és szabványos kriptográfiát és biztonságos környezetet valósít meg. Nyilván ez sem feltétlenül jelenti, hogy az NSA vagy a gyíkemberek nem „ülnek benne az eszközben”, de ezek ellen a halandó és főleg egy vállalat vajmi keveset tehet (és nem is feltétlen ellenük akar védekezni!).

Végső konklúzio

Számunkra a döntő érv mindenképpen az adattároló modultól való szeparált titkosító kulcs tárolás, azaz mi a hardveres titkosítás mellett tesszük le a voksunkat.

Véleményünk szerint a hardveres titkosítás és a számítógéptől független titkosítás-feloldás a legbiztonságosabb megoldás.

További jó érv a hardveres titkosítás (a hardveres titkosítás és hardveres nyitás) mellett, hogy ilyen megvalósításban az adattároló eszközünk teljesen operációs rendszer és szoftver független – hiszen semmiféle szoftverre, nyitóalkalmazásra nincsen szükség.

A sebességre pedig mi azt mondjuk, amit a Mondoshawanok, mielőtt átadják a titkosító kulcsot:

Time Not Important, Only Data Important!

(nem egészen így mondják, de majdnem!).

Szóval a titkosított adattárolók esetében a sebesség legfeljebb harmadlagos tényező tud lenni, mivel a cél a biztonságos adattárolás és biztonságos elérés, nem pedig a gyors adattárolás és elérés.

A fizikai ellenállóképességet jellemző fontosabb rövidítések

A „Hogyan válassz titkosított adattárolót?” sorozat első részében a biztonsági minősítéseket néztük meg kicsit alaposabban. A sorozat második részében pedig a fizikai ellenállóképességet jellemző rövidítéseket nézzük meg közelebbről. Szerencsére, a fizikai ellenállóképesség jelölésére egy jól dokumentált nemzetközi szabvány vonatkozik, elvileg sokkal egyszerűbb eligazodni rajta – bár mindig lehetnek kakuktojások.

Az IP-védettség (International Protection Marking) jelentése Nemzetközi Védettségjelölés.

Egy műszaki berendezés áramköreit védő tokozás (készülékház) környezeti behatások elleni védettségét jelzik vele.

Az IP-besorolást Magyarországon az MSZ EN 60529:2015 „Villamos gyártmányok burkolatai által nyújtott védettségi fokozatok (IP-kód) (IEC 60529:1989)” nemzetközileg az IEC 60529:1989 szabvány (és pl. 2013-as frissítése) írja le, amelyet gyakorlati tesztek alapján határoztak meg.

Az első számjegy a szilárd anyagok (pl: por), a második a vízzel szembeni védelemre, az esetleges harmadik jelszám a szilárdságra vonatkozik (ez a legtöbb esetben nincs feltüntetve). A magasabb szám minden esetben magasabb védelmi szintet jelent, pl. IP65. A védettségi érték hiányát (nem adják meg) gyakran X betűvel jelzik, de kiegészítő betűk is lehetségesek.

IP65:

A „6” mutatja, hogy az eszköz teljesen zárt és védett a szilárd anyagok és szennyeződések ellen, míg az „5” jelszám arra vonatkozik, hogy az eszköz kisnyomású vízsugár ellen védett.

Egy IP67-es minősítésű eszköz teljesen védett a szilárd anyagok és szennyeződések ellen (az első „6”-os jelszám), míg a második „6”-os jelszám arra vonatkozik, hogy az eszköz kibírja a vízbe merítést (3m mélységig, 30 perc időtartamig) is.

IPX8:

Csak a vízállóság jelölésére használják és a szilárd anyagokkal szembeni ellenállási képesség ilyenkor nincs megadva („X”).

A „8” a vízállósági értéket mutatja, jelen esetben azt jelenti, hogy az eszköz kibírja folyamatos víz alatti tartózkodást 1m mélységig. Ha ez az eszköz egyébként teljesen porvédett is, akkor a teljes minősítése IP68.

IP65 tesztelő labor

Nem egészen hivatalos tesztelő labor :)

Professzionális IP65/IP67 tesztelés

Fontosabb biztonsági minősítések – FIPS 197, FIPS-140-2, CC-EAL, BSI

 Következzen egy rövid összefoglaló a biztonsági minősítésekről, a teljesség igénye és főleg a nagyon részletes magyarázat nélkül. Az összefoglaló remélhetőleg segítséget nyújt abban, hogy megértsük az egyes minősítések jelentését és értékét, ezáltal pedig eldönthessük, hogy melyik mágikus varázsszó fontos a számunkra.

Az eszközökre vonatkozó biztonsági minősítéseknek komoly szerepük van: meghatározzák az adott eszköz biztonsági funkcióit, titkosításának megfelelőségét – tehát azt, hogy mennyire lehet megbízni az adott eszközben.

FIPS 197 (FIPS PUB 197)

A minősítés nem az eszközre, hanem a titkosításhoz használt Advanced Encryption Standard (AES) algoritmusra vonatkozik. Az AES algoritmus szimmetrikus kulcsú titkosítás, tehát az adatok titkosításához ugyanazt a titkosító kulcsot használja, mint az adatok kititkosításához.

A FIPS minősítés tehát csak annyit jelent, hogy az eszközben felhasznált titkosító algoritmus megfelel a NIST által megfogalmazott AES szabványnak, a szabványnak megfelelően működik, nem pedig a gyártó hozott létre egy újabb, és ellenőrizetlen titkosítási metódust.

A FIPS 197 minősítés alapvető fontosságú az eszközök választásában, ha olyan megoldást szeretnénk, amely szabványos, ellenőrzött és megbízható.

FIPS-140-2 (Level X)

 A FIPS-140-2 az USA kormányának biztonsági szabványa, és a minősítés jóval többet jelent, mint a FIPS 197, mert nem csak a titkosító algoritmus, hanem a teljes eszköz kriptográfiai működése, funkciói kerülnek ellenőrzésre.

A FIPS-140-2 Level 3 minősítés elvárja az eszköztől, hogy a felhasznált kriptográfiai áramkör és a titkosítási környezet (beleértve az algoritmust is) fizikailag és logikailag is ellenálló legyen a támadásokkal és visszaélésekkel szemben.

Alapvető elvárása a szabványnak, hogy az eszközök zártak legyenek, ne lehessen hozzáférni a titkosító áramkörökhöz, az eszköz reagáljon a bontási és behatolási kísérleteknek (tamper proof), valamint a működését befolyásoló módosítási kísérleteknek.

Csak az az eszköz kapja meg a minősítést, amelyet az erre hivatott szervezetek laboratóriumi körülmények között nagyon alaposan leteszteltek.

CC-EAL-5

A Common Criteria nemzetközi biztonsági ajánlás/szabványa a FIPS-140-hez hasonlóan, de még részletesebb elvárásokat fogalmaz meg az eszközökkel kapcsolatban, tehát egy CC-EAL-5 minősítésű eszköz magasabb biztonsági elvárásoknak kell megfeleljen, mint a FIPS-140-2 esetén, mivel nem csak a felhasznált kriptográfiai áramkör és a titkosítási környezet, de a teljes eszköz működése ellenőrzésre kerül biztonsági szempontok alapján.

A minősítés megszerzéséhez a gyártónak át kell adnia a hivatott szervezetnek az eszköz dokumentációját és terveit, majd az eszközt laboratóriumi környezetben vizsgálják és penetrációs tesztekkel (betörési, hekkelési kísérletek) ellenőrzik az eszköz megfelelő működését és ellenálló képességét.

Nemzeti/állami minősítések – BSI/NSA/NSM

Az egyes államok megfogalmazzák saját biztonsági szabványaikat, amelyet teljesítő eszközöket nemzeti minősítéssel látják el. (Végső soron a FIPS-140-2 is nemzeti minősítés, de ennek ellenére világszerte is használják és elismerik).

A nemzeti minősítések általában valamely nemzetközi ajánlásra/szabványra és minősítő eljárásra épülnek (pl. Common Criteria), de tartalmazhatnak olyan elvárásokat, amelyek az adott országra specifikusan vonatkoznak.

A BSI német állam (Bundesamt für Sicherheit in der Informationstechnik) nemzet(i)biztonsági felügyeletének neve és minősítése, az EU-ban elterjedt és nagyra becsült tanúsítvány. A BSI minősített eszközök megfelelnek a német állam nemzet(i)biztonsági felügyelete által megfogalmazott elvárásoknak és az általuk végrehajtott teszteket is sikeresen teljesítette.

Az NSM a norvég nemzet(i)biztonsági felügyelet neve és minősítése, az EU-ban elterjedt és nagyra becsült tanúsítvány. Az NSM minősített eszközök megfelelnek a norvég állam nemzet(i)biztonsági felügyelete által megfogalmazott elvárásoknak és az általuk végrehajtott teszteket is sikeresen teljesítette.

Július 14-től interneten is megvásárolhatóak a BKK napi- és hetijegyek, valamint a félhavi- és havibérletek – név, cím, és valamely okmány adatainak megadása után. Maga a díjtermék csak egy weboldalon keresztül érhető el, melyet egy okostelefonon betöltve mutathatunk fel ellenőrzésnél. 

Számos sérülékenységről adtak már hírt a szakértők, és az RTL Klub Hiradó műsora körtelefonnal igyekszik szakértőket toborozni, akik el tudják mondani a nézőknek, hogy miért rossz a BKK rendszere (nem vicc, szó szerint ez a szövege a telefonáló RTL-es kollégának). 

Mi is találtunk nagyon súlyos biztonsági rést a rendszeren, ma reggel 10.00-kor észleltük, 10.02-kor írtunk az info@bkk.hu címre, és mivel most 12.00-van és se nem javították ki, se nem válaszoltak, megosztjuk a Nagyérdeművel:

A BKK egyébként még mindíg nem válaszolt a megkeresésünkre!

Igen kiváló cikk jelent meg a Frappa Magazinban Keleti Arthurral. A téma természetesen a titkok természete, a titokvédelem illetve a kiber.

A cikket olvasva szaporán bólogattam, mert Arthur kimondta, hogy:

 Azaz a termékben gondolkodás – minden problémára van silver bullet, csak meg kell venni és eljő a szép világ – nem feltétlenül az üdvözítő út; a "mindenmentes" ételek mintájára a "mindenellen" védő piacvezető "szupertermékek" sem feltértlenül azt kínálják, amit a marketingesek és a salesek hirdetnek.

A másik, ami eszembe jutott, annak igazából az ál- és klikkvadász hírekkel és dezinformációs tartalmakkal kapcsolatos, vajon melyik hazai média milyen címmel foglalná össze Arthur gondolatait? :)

Természetesen ez csak fikció, Arthur szemléletes példái igen kiválóan alkalmasak a hatásvadász címekre és összefoglalókra:

Ripost

Keleti Arthur rettegésének oka: „megcsalom a feleségem”!

Blikk

Rájár a rúd Keleti Arthurra mostanában. A hírneves kibervédelmi stratéga és jövőkutató nyomorog, máról holnapra tengődik! „a bankszámlámon levő pár tízezer forint – amiből ebben a hónapban élek – számomra kritikus, nagyon fontos dolog.”

Bors

Őszintén kitárulkozott a neves jövőkutató: „a világ megtudja, hogy drogfüggő vagyok” – vallott Keleti Arthur a nehéz időszakról.

Detektor Plusz Magazin

Kibervédelmi kutató mutatott rá a személy- és vagyonvédelem fontosságára. Keleti Arthur a GPS-alapú személykövetés és a napjainkban egyre szaporodó betörések példáin keresztül hívja fel a figyelmet arra, hogy a vagyonvédelem és a kibervédelem ugyanazon érem két oldala.

Index

Senki nincs biztonságban. A titkaink nyitott könyvkent olvashatók a hekkerek és kiberbűnözők számára! A hekkerek beférkőztek a játékgépekbe, ott vannak minden számítógép kamerájában és mikrofonjában. A védelmi szakemberek tehetetlenek, nincs megfelelő védekezési módszer a támadók és hallgatózók ellen. A javasolt megoldás, ha a felhasználó eltüzeli a berendezéseket:  „nem bízhatsz meg benne, hogy szoftveresen meg tudod védeni” – nyiltakozta Keleti Arthur kibervédelmi szakértő. Egészségügyi eszközök is érintettek lehetnek vírustámadásokban.

444

A Szili nemigazán akarja megint megszagolni, de állítja, hogy valami bűzlik Dániában. Lehet a sajt, de lehet, hogy Keleti Arthur, aki mostanság új szenvedélyének hódol, az Egy Év egy Zokni kihívásnak: „-minden nap ugyanazt a pár zoknit veszem fel” – jelentette ki a jövőkutató.

Tök igaza van a HVG-nek, hogy megpróbál eszközöket ajánlani a felhasználóknak, csak azzal van a baj, hogy ezt úgy teszi, hogy nem hívja fel a figyelmüket arra, hogy az ajánlott alkalmazással kapcsolatban mire kellene figyelni: konkrétan adatszivárgást idézhetnek elő.

A NOBOT egyik funkciója – és amit a HVG is kiemelt, - hogy a fájlokat feltöltheti a Virus Total-ra és levizsgáltathatja a Virus Total ötven AV/AM motorjával.

Az ezzel a baj, hogy a felhasználó önként átad fájlokat egy harmadik fél részére, aki a fájl és az adattartalom megismerésére nem jogosult.

Ezt hívják adatszivárgásnak.

Nyilván nem az okoz ebben gondot, ha a felhasználó futtatható állományokat ad a Virus Total-nak, hanem az, amikor dokumentumokat is ellenőriztet, amelyek lehet, hogy házon belül keletkeztek, lehet, hogy külső féltől érkeztek, lehet, hogy valamelyik partnertől érkezett – de szenzitív és az adatvagyon leltárba tartozó adatokat tartalmazhatnak.

A VirusTotal a fájlokat tárolja, feldolgozza, elemezi – és az információt - valamint akár a fájlt is - megosztja egyrészt a fizetős partnerekkel, másrészt pedig eladja/kiadja a vírusvédelmi cégeknek.  

Ehhez elegendő csak gyanúsnak vagy furcsának találni – amelyet simán okozhat néhány jóféle marketinges által tákolt makró, vagy akár csak egy VirusTotal motor túlérzékeny heurisztikája (és lássuk be, a Yandex neve különösen rosszul cseng itthon mostanában, és a Jiangmin vagy a Qihoo neve sem az a kifejezett garancia).  

Érdemes lenne a VirusTotal adatvédelmi tájékoztatását elolvasni - itt a személyes adatok vonatkozásában tekinti át a szolgáltató, hogy mire számítson a felhasználó.

Érdemes lenne a VirusTotal felhasználási feltételeit is átolvasni, ahol ilyen gyöngyszemeket lehet találni:

(Ki itt felöltsz, hagyj fel minden reménnyel)

Frész Ferenc Cyber Services-i evangelista (ez olyan biztonsági fórum, mint a Vidám Vasárnap, csak a tagjaik hekkerek és biztonsági szakértők) mantrája, miszerint: „Ha ingyenes a szolgáltatás, az áru Te magad vagy!” tökéletesen illik a Virus Total-ra is.

A biztonság a kockázat tudatos felvállalása (OMG!!!), viszont a NOTBOT és hasonló társaik nemigazán tájékoztatják a jóhiszemű felhasználót arról, mivel jár, vagy járhat a használatuk, így azok a kockázatok és mellékhatások tekintetében legfeljebb gyógyszerészükhöz fordulhatnának – már ha tudnának róla egyáltalán.  

Mivel a Hackerfeleség és párja, Thor jelenleg BBQ hackeléssel tölti napjait (ezúton is gratula a hétvégi fényes BBQ versenyeredménynek!), így rám maradt a szomorú tájékoztatási kötelesség, és hogy posztoljam: az elektromos cigik bizony, mint malware terjesztő eszközök keseríthetik meg a gőzlér vagy az egyszeri felhasználó életét.

Hát nincs nekünk amúgy is elég bajunk a hazai e-cigaretta szabályozással?

Nem ér elegendő bosszúság a Nemzeti Trafikokban?

Most már azzal is foglalkozni kell, hogy a liquiden kívül vajon még mit hordoz az e-cigi?

A FourOctets névre hallgató ügyes kezű hacker mutatott be egy elég kényelmetlen érzéseket keltő videót, egy e-cigibe rejtett BadUSB támadóeszközről, amely a klasszikus RubberDucky/PoisonTap mintájára USB billentyűzetet emulál, és képes parancsokat beküldeni a számítógépnek, amelyhez csatlakoztatták.

Szóval most már az elektromos cigaretták is bármikor hordozhatnak a lidquiden és a gőzön kívüli, nem kívánt mellékhatást. De szuper!

Hogyan működnek ezek a cuccok?

A BadUSB eszközök keystroke injection tool elven működnek, azaz az eszközt a fogadó számítógép szabványos USB billentyűzetként érzékeli.

A csatlakoztatás után az eszköz billentyűzet leütéseket küld a számítógépnek, amelyeket – mivel szabványos USB billentyűzetként észlelte – a számítógép végre is fog hajtani.

Az eszközben előre felprogramozva billentyűzet leütésenként tárolásra kerül a támadó kód, amelyet aztán az eszköz leütésenként beküld a számítógépnek, és megtörténik az, amit nem szeretnénk: malware töltődik le a gépünkre, backdoor nyílik, adatok másolódnak az eszközbe épített tárolóra, stb.

Hogyan lehet védekezni a BadUSB-jellegű támadások ellen?

A legfontosabb, hogy ismeretlen USB eszközt szigorúan tilos a munkaállomáshoz csatlakoztatni. Még csak azért se, hogy egy kis áramot kölcsönözzünk neki.

(Itt jegyezném meg, hogy az adatszivárgásvédelmi DLP, illetve USB eszközök csatlakoztatását menedzselő port- és eszközmenedzsment rendszerek - mivel USB billentyűzet csatlakoztatását érzékelik – nem foglalkoznak az ilyen eszközökkel, szóval egy DLP által védett munkaállomás is simán áldozattá válhat!)

A második legfontosabb dolog, hogy soha, SOHA ne hagyd lezáratlanul a munkaállomásodat! Egy BadUSB eszköz csatlakoztatása, és a támadó kód beküldése csak néhány másodpercig tart, ezért mindig figyelj oda, hogy ha eltávolodsz a munkaállomásodtól, azt mindig zárold.

Ha mégis ismeretlen/vendég eszközt kell a gépedhez csatlakoztatni...

Ha mégis alkalmi viszonyba kívánunk lépni ismeretlen USB eszközökkel, csak mint az életben: védekezz!

Használj kondomot!

Az USB Condom – illetve újabb nevén SyncStop – csak az áramfelvételt engedélyezi a csatlakoztatott eszköznek, semmiféle adatkommunikáció nem tud kiépülni a csatlakoztatott eszköz és a fogadó munkaállomás között (USB firewall).

USB Condom/SyncStop

Ez fordítva is igaz, ha te szeretnéd a telefonodat, tabletedet vagy más, USB csatlakozású eszközödet csatlakoztatni idegen aljzatokhoz, az USB Condom/SyncStop megvédi az eszközödet, mert csak a töltést fogja engedélyezni az adatkapcsolatot nem.

De a legtutibb, ha nem dugod ismeretlen lukba. Vagy nem hagyod, hogy ismeretlen bedugja.