2013. november 20-án 58. szakmai fórumát tartotta a Hétpecsét Információbiztonsági Egyesület, a vezető téma az információvédelem menedzselése volt. Gasparetz András egyesületi elnök röviden ismertette az egyesületi közönség közösségi-média használati szokásaira irányuló felmérés eredményét. Kiderült, az információ védelemmel foglalkozók is a facebook-ot használják, elsősorban magán- és családi célokra, a LinkedIn-t pedig szakmai kapcsolattartásra. A szakmai közönség körében az utóbbi használata kb. 50%-os, a teljes magyar népességnek viszont alig 1%-a használja. Az egyesület, a felmérést értékelve úgy döntött, a közös szakmai munka színtere legyen a LinkedIn, így Hétpecsét csoportot hozott létre ezen a közösségi médián, amelyhez lehet csatlakozni.

2013. november 20-án 58. szakmai fórumát tartotta a Hétpecsét Információbiztonsági Egyesület, a vezető téma az információvédelem menedzselése volt. Gasparetz András egyesületi elnök röviden ismertette az egyesületi közönség közösségi-média használati szokásaira irányuló felmérés eredményét. Kiderült, az információ védelemmel foglalkozók is a facebook-ot használják, elsősorban magán- és családi célokra, a LinkedIn-t pedig szakmai kapcsolattartásra. A szakmai közönség körében az utóbbi használata kb. 50%-os, a teljes magyar népességnek viszont alig 1%-a használja. Az egyesület, a felmérést értékelve úgy döntött, a közös szakmai munka színtere legyen a LinkedIn, így Hétpecsét csoportot hozott létre ezen a közösségi médián, amelyhez lehet csatlakozni.  

Megújulás előtt áll az egyesület honlapja is, tartalmi bővülése várható, multikulturális megoldásokkal.

 

Dr. Félegyházi Márk, a Budapesti Műszaki és Gazdaságtudományi Egyetem HIT adjunktusa az egyetemen működő

CrySyS Lab-ot mutatta be.  http://www.crysys.hu  ;   http://hu.wikipedia.org/wiki/CrySyS_Lab      

A laborban négy professzor és hasonló számú Phd diák tevékenykedik az információ-biztonság területén, erős, elszánt és kreatív csapatként. Az egyetem területén túl, nemzetközi szinten is jó eredményeket értek el hacker versenyeken. http://ictf.cs.ucsb.edu ; http://www.acronymfinder.com/International-Capture-the-Flag-(information-security-competition%3B-University-of-California,-Santa-Barbara)-(iCTF).html  

Az iCTF versenyeken induló minden csapatnak van egy saját rendszere, amit meg kell védenie, s a másik rendszert megpróbálja feltörni. Ez egyfajta csapatjáték az informatikai biztonság területén. A következő verseny ez év december elején lesz. A másik megmérettetésen, a CSoft Open versenyén pedig az 1.400 résztvevő közül a csapat a 12. helyet szerezte meg.  

A csapat három fő tevékenysége:

Kutatás, kutatólaboratóriumi felállásban

Egyetemi oktatás

Megbízás alapján szerződéses munkák végzése az információ biztonság területén; etikus hackelés, információ biztonsági értékelés, rendszerek tervezése

 

Korábbi, a tevékenységet megalapozó, ma már kifutó tevékenységi körükbe tartozik a beágyazott rendszerek, szenzor hálózatok biztonsága. Több európai projektben vettek részt, ezek főleg kutatás-orientált feladatok voltak, ipari és céges munkákban. Foglalkoztak az információ biztonság menedzsmentjével, elsősorban elméleti szinten, ezen belül az információ biztonsági befektetési döntésekkel, az IT biztonság és biztosítás kérdéseivel, kockázatok felderítésével egy adott biztosításra, játékelmélet alkalmazásával elméleti eszközökben, stratégiai döntések problémakörével komoly stratégiai játékokban. Ezekben a témákban a csoport nagyon sok nemzetközi (európai, amerikai) kapcsolatra is szert tett.  

 

A labor jelenlegi tevékenységének témája; a kártékony kódok, malwarek elemzése, detektálása, az ellenük való védekezés, a cégeknél a detektálás utáni válaszlépések meghozatala, a folyamatos helyreállítás. A témakörben jól ismert fogalom a stuxnet károkozó. http://hu.wikipedia.org/wiki/Stuxnet  Ez volt az első olyan bizonyított malware, amely komoly fizikai károkat okozott a megtámadott rendszerben. A korábbi károkozók lemezeket töröltek, megakadályoztak bizonyos informatikai tevékenységeket, de fizikai rombolást nem végeztek. A stuxnet az iráni atomlétesítmények ultra-centrifugáinak nagy részét tönkretette.

 

A CrySyS Lab munkatársai követték az eseményeket, igyekeztek megérteni a stuxnet működését. Ezt követően,  szakértői felkérés során a csoport egy európai cég rendszerében tapasztalt működési zavarok forrásaként a  stuxnethez hasonló, kódrészleteiben sokban egyező malware tevékenységét tudta detektálni. A kórokozó szoftver itt más céllal működött, elsősorban információkat gyűjtött. A labor munkatársai felfedték a kórokozót, elnevezték Duqu-nak, és a szakmai gyakorlattól eltérően, részletekbe menő, kiterjedt, 60 oldalas leírást adtak róla. Ez az alapos elemzés az antivírus cégeket is meglepte. Nagyon pozitív visszajelzést, elismerést jelent a csoport számára, hogy azóta a Kaspersky 120 oldalas riportokat ad ki a felfedezett fenyegetettségekről. A CrySyS Lab részletekbe menő riportja a további részletes elemzések számára megfelelő kiindulási alapot nyújt. Egy-egy komplex malware részletes, technikai elemzése hónapokat, vagy éveket is igénybe vehet.   

 

A labornak sikerült megtalálnia a Duqu-hoz tartozó dropper-t is.  

http://www.symantec.com/security_response/writeup.jsp?docid=2002-082718-3007-99

A dropper olyan fájl komponens, amely elsőnek érkezik a rendszerbe. Jellemző módon, ez lehet egy MS world fájl, amelyet ha egy vállalati hálózaton valaki megnyit, akkor erről települ a malware a rendszerre és onnan próbál az egész céges hálózatra rátelepedni.

Ez a dropper többnyire azonnal törli magát, és megpróbál minden nyomot eltüntetni. Általában a droppert nem sikerül megtalálni, a labornak nagy sikert jelentett fellelése; a fertőzött céges hálózat kezelőit sikerült rávenni, hogy csináljanak mentést az érintett diszkekről, de semmilyen más tevékenységet (pl. takarékossági törléseket) ne végezzenek rajtuk. Így sikerült elcsípni a dropper fájlt. Informálták erről a Microsoft-ot, ahol ez a komoly, a MS kódbázis gyökerét érintő sérülékenység még nem volt ismeretes.    

A hiba kijavítása sokáig váratott magára, ezért a labor munkatársai maguk írtak rá egy nyílt forráskódú detektort, kitették honlapjukra, sokan le is töltötték. A sikeres szoftver magát a valódi stuxnetet is detektálni tudta. A labor nemzetközi elismertsége ettől kezdve pályán volt.

 

A következőkben egy nemzetközi együttműködés keretében felkérést kaptak, hogy segítsenek egy másik malware elemzésében, amely végül a Flame nevet kapta. http://www.crysys.hu/targeted-attacks.html

Erről is részletes technikai analízist tett közzé a labor. Ez a malware is, akár csak a stuxnet és a Duqu,  zero-day hibákat tartalmazott.  http://hu.wikipedia.org/wiki/Nulladik_napi_t%C3%A1mad%C3%A1s

A nulladik napi sérülékenységre jellemző, hogy akkor is bekövetkezhet, a támadás akkor is eredményes, ha a számítógép szoftvere tökéletesen frissítve van. A fekete-piacon egy ilyen hiba ismerete 50 ezer és 250 ezer dollár közötti értéket képvisel. A stuxnet-ben 4 ilyen hiba-támadó volt, komoly erőforrásokra volt szükség létrehozásához. 

A Duqu-ban egy ilyen zero-day volt. A Flame is hasonlóan kifinomult trükköt alkalmazott; legitim, windows-aláírással rendelkező update-ként érkezett a megcélzott számítógépre. A támadók óriási erőforrású támadást hajtottak végre, a biztonsági rendszerben ütközést generáltak, így érték el, hogy az általuk küldött anyagon az aláírás-hitelesítés teljesen úgy nézett ki, mint a legitim frissítésen. Ehhez miliszekundum pontossággal el kellett találniuk azt az időt, amikor a windows updatet a Microsoft eredetileg aláírja. A Kaspersky szerint 4-10 millió dollárnyi az az erőforrás igény, amellyel ezt az ütközést elő lehet állítani. A Frame érdekessége még a malwarek körében szokatlanul nagy mérete, 6 Mbyte.

 

A labor foglalkozott Gauss malware-el is, melynek különlegessége, hogy modulja visszafejthetetlen, mert a visszafejtéshez szükséges kulcs csak a célpont számítógépéről állítható vissza. Ehhez viszont meg kell támadni a célpont számítógépet… Így a mai napig nem ismert, hogy mi lehet a Gauss titkosított moduljában. 

 

A labor foglalkozott a Miniduke-al, amely kormányzati számítógépeket támadott világszerte, magyar érintettsége is volt, a TeamSpy pedig egyértelműen magyar érintettségű volt, ennek kezelésében a Nemzeti Biztonsági Felügyelettel működött együtt a labor.  (www.nbf.hu ) A TeamSpy a legitim TeamView alkalmazásba illesztett be egy kisméretű modult, a Windows a TeamView legitim voltát ellenőrzi, de a beinjektált modulokat nem… Így tudták a rosszfiúk beilleszteni azt a rosszindulatú részletet, ami átment az egész ellenőrzésen. A TemSpy vonatkozásai kelet felé mutatnak…  

 

A fenti munkák jelentős figyelmet keltettek kül-, és belföldön egyaránt. Sok olyan érdekes dolgot tudtak bevezetni, amely hiányzott az információ biztonság palettájáról. Ilyen pl. az az újszerű trend, hogy kétségbe kell vonnunk a program jóságát akkor is, ha létezik annak aláírása, hitelesítése. A malware írók egyre gyakrabban írják alá az elküldésre szánt rosszindulatú kódot, tehát a program hitelesítése, s publikus kulccsal való aláírása önmagában csak a tömeg-termelésű malwareket zárja ki.  

Az antivírus termékek és a bekapcsolt tűzfalak nagyon jók, a támadások többségét kivédik, de nem jelentenek tökéletes védelmet. A célzott támadásoknál a támadók precízen felmérik a rendszert, volt olyan támadás is, amelynél a rendszergazdai jelszó bele volt fordítva a támadó kódba.   

 

Az informatikai támadások jelzésében a globális kommunikációnál nehézségeket okoz a különböző szervezetek közötti kapcsolattartás. A labor ma már elismert partnernek számít a Microsoft számára is… A nagy szervezetek is felismerték, egyre inkább kell számítaniuk azokra a kis szervezetekre, „szemekre", amelyek a világon figyelik az IT gondokat. A nagyon célzott, nagyon kritikus támadások nagy értékű célpontok ellen indulnak. Kisvállalatok valószínűleg nem lesznek ilyennek kitéve, de az értékes kormányzati, banki, stb. célpontoknak fel kell készülniük nemzetállamok, versenytársak, vagy idegen szervezetek támadására. Mindig fel kell mérnünk, mi az az érték, amit védünk. Az odafigyelés, a jobb monitoring, egy ügyes rendszergazda a fenti károkozók tevékenységét megakadályozhatta volna. Mindegyík produkált olyan jeleket, amiket egy szemfüles rendszergazda elkaphatott volna. Érdemes őket kicsit tehermentesíteni… Az elektronikus kulcsokat gyártó LSH cég elleni támadást is egy rendszergazda fülelte le.   

 

A labor munkája során számos hazai és külföldi céggel került kapcsolatba, a továbbiakban főleg projektorientált tevékenységet végeznek; egy-egy fellépő rendellenességre kívánnak projektet létrehozni ipari partnerekkel, vagy támogató szervezettel. A fenti esetek kezelésére elnyerték a Nemzeti Fejlesztési Ügynökség (www.nfu.hu ) projektjét. Az egyik ilyen projekt a felhő alapú célzott támadás és malware észlelés; a megoldás során a partner feltölti gépének virtuális változatát, imidzsét s ezt ellenőrzi a labor. A vizsgálatra a labor meglévő eszközöket, és saját fejlesztésű eszközöket használ. A másik projekt az aláírt kódrészletekre, aláírt szoftverek adattárára irányul. Sokféle, sok forrásból származó szoftvert gyűjtenek össze, s ezek aláírását próbálják ellenőrizni, különböző célokra használni, ezt a munkát az US Haditengerészeti Intézet támogatásával végzik. http://en.wikipedia.org/wiki/United_States_Naval_Institute 

A labor bizonyos tevékenységeit az egyetem keretein kívül intézi, erre két céget hoztak létre, az IT-SEC Expert-et és a Tresorit-ot. Utóbbi munkatársa az a három diák, akik titkosított drop-box szerű fájl-megosztási rendszert fejlesztenek. (400 millió Ft-ot kaptak rá befektetőktől.)  

 

 Tari Róbert, a Grayteq Data Loss Prevention Solution adatvédelmi megoldásokat gyártó cég ügyvezető igazgatója előadásában a BYOD és a BYOA biztonságról szólt. A Bring Your Own Device és a Bring Your Own Apps(applications) fogalmak többnyire együtt járnak a gyakorlatban. Ezek mögött a kifejezések mögött az a tartalom áll, hogy azt az eszközt, alkalmazás szoftvert, amelyet adott alkalmazott jobban szeret használni, hogyan tudjuk beengedni céges környezetünkbe, anélkül, hogy annak összeomlása fenyegetne.  

 

A BYOD menedzsmentek már 2012-ben is 35%-os súllyal szerepeltek a céges probléma-körökben. A 2013-as adatok szerint, az alkalmazottak tulajdonában lévő eszközök bejutása a céges környezetekbe 82%-os szinten mérhető.  

Az informatikai biztonság zsarnoki szigorúsága és a kollégák munkaköri hatékonyságát szolgáló kényelmi eszközök között kell megtalálni a köztes megoldást, az élhető biztonságot.  

 

A BYOD-ban való részvétel, erre vonatkozó projekt eldöntendő kérdései:  

 

Hálózatunk készen áll-e rá, informatikai infrastrukturánk biztonsági felállása elegendő-e kezelésére, gyenge IT biztonságú mobil eszközöket be tudunk-e engedni hálózatunkba veszélyes kapuk megnyitása nélkül?  

 

A saját infrastruktúra kialakításakor általában törekszünk szabványos, illeszkedő eszközök alkalmazására. Ilyen környezetben viszont mire számíthatunk, ahol a nem szabványos eszközök a megszokottól eltérő típusú forgalmát kell kezelni, s szokatlan fennakadások, hibák léphetnek fel?  A helpdesket fel kell készíteni az ugrásszerűen megnövő segítség-kérések kezelésére. Munkatársainak az összes beengedett eszköz kezelését, a vonatkozó gondokat teljeskörűen ismerniük kell.   

 

A fentiek átgondolása után el kell döntenünk, melyek azok az eszközök, operációs rendszerek, amiket kellően biztonságosnak ítélünk a beengedéshez. Az operációs rendszerek mellé alkalmazások is társulnak, amelyeket az átlagos kollégák általában (netes) hivatalos forrásokból gyűjtenek be, de előfordulnak másfajta begyűjtések is…

Ilyenkor választhatjuk, hogy egyenként létrehozzuk azokat a listákat, amelynél megadjuk, hogy az adott oprendszer adott verziója, adott beállítású eszközökkel, adott alkalmazásokkal bejöhet, más nem.  

 

Amerikai megoldás, hogy cégen belül elhatárolt területeket hoznak létre, ahol a biztonsági kollégák által meghatározott eszközök és oprendszerek megfeleltetése után egy belső alkalmazás-market van a cégen belüli hálózaton és ott lehet mondani, hogy amennyiben a telefonom, tabletem megfelel az adott hálózat biztonsági előírásainak, akkor bejut, s onnantól a cégen belül használt alkalmazásokat töltse le a cégtől. Ezek nem feltétlenül a cég saját alkalmazásai, az ilyen jellegű mobil eszközök belső alkalmazás-piacát általában a nagy gyártók különböző alkalmazás-marketjei támogatni szokták.

 

Végig kell gondolni, szükségünk van-e olyan új szolgáltatásokra, amelyek ezen eszközök céges alkalmazását lehetővé teszik? Ilyen szolgáltatás, amikor megszabjuk, hogy egy androidos eszköznél a legalacsonyabb számú verzió a 3.0-ás lehet. Előállhat olyan szituáció, amikor ezt vállalatilag 3.2-re kell emelni, s gondok támadnak. Vannak olyan eszközök, amelyekre az adott verzió nem is létezik. Hasonló helyzetekben ki kell találni, hogy azokkal a kollégákkal mi legyen, akik eddig használták az alacsonyabb változatú eszközöket és most a megemelt biztonsági szint miatt kiestek a körből. Mondhatnánk, vegyenek új eszközt, de ez kicsit költséges… Amennyiben a cégnek érdeke, hogy ők a tabletjükön a világ túloldalán el tudják olvasni a céges levelet, akkor adjon a cég nekik tabletet. 

Meg lehet kerülni a kérdést, ha megpróbálunk olyan szolgáltatásokat kiajánlani, ill. létrehozni cégen belül, ami az ő támogatás nélkül maradt eszközükről is segít a célfeladatot működtetni. Ez nagyon sok erőforrást igényel, s nagy költséggel járhat.  

 

Gondot jelent, hogy biztonság-felügyeleti politikát és eljárásrendet kell kidolgozni azon esetekre, amikor valaki tudatosan, egyszerű hozzá-nem értésből, vagy tudomásán kívül megsérti a cég biztonsági politikáját. Mindenképpen szem előtt tartandó, csak akkor kérhetjük számon a kollégán, hogy mit tett, ha előtte kioktattuk jogosultsági határairól.  

 

Biztonsági rendszer bevezetésének sarkalatos pontja lehet a döntés, beavatjuk-e a kollégákat, hogy felügyeleti rendszert telepítettünk. Sokszor nem akarják ezt tudatni, tartva a munkatársak ellenállásától. Amennyiben a tudatosítás elmarad és a munkatárs elköveti azt a „kihágást", amely tevékenységhez az előző nap még legálisan joga volt, akkor azonnal megnő a helpdesk igénye, ahol tömegesen kell magyarázni az újonnan bevezetett szabályokat. Egyesével kezelve a helpdesk és magunk megőrülünk… A követendő felállás; egy-egy bevezetéskor azt mondjuk; a következő biztonsági szabályok lépnek életbe ekkor és ekkor, s részletesen elmagyarázzuk a jogok változását.  

 

Tudatosítani kell a munkatársak körében azt is, hogy mihez van egyáltalán hozzáférési jogosultságuk, milyen információk milyen szintig juthatnak el mobil eszközeikre, s az ettől való eltérés, vagy az eszközök elvesztése, ellopása, sérülése mit okozhat.  

 

A céges rendszerekhez, ill. adatokhoz való BYOD hozzáférés négyféle lehetősége:

1.A céges rendszerekhez és adatokhoz való korlátlan hozzáférés – erősen ellenjavallt

2.A nem érzékeny céges rendszerekhez és adatokhoz való hozzáférés – általunk eldöntött mértékben nem okozhatnak jelentős pénzügyi veszteséget, piaci veszteséget, vállalati imidzs veszteséget.

Ezzel az a gond, hogy munkatársaink beosztásától függően, lehetnek olyan kollégák, akiknek napi elvégzendő feladatai miatt elengedhetetlenül szükséges hozzáférni az érzékeny adatokhoz. 

3.A céges informatikát bízzuk meg azzal, hogy a tárolt adatokhoz, rendszerekhez felügyelt távoli hozzáférést biztosítson – ez a hozzáférést biztosító alkalmazások kiválasztásának felelősségével jár együtt. Sokféle módon tudjuk megakadályozni, hogy adatok jussanak ki a cégről, de az adott alkalmazásokon belül ismert, vagy nem ismert hibák felügyeletének kérdése számos gonddal jár.  

4.Valamennyi céges adathoz, ill. rendszerhez megadjuk a hozzáférést a személyes eszközöknek, a személyes alkalmazásoknak, de az adat tárolását, azt, hogy az adat fizikailag ki tudjon-e jutni a személyes eszközökre, azt szabályozzuk – ez a legcélravezetőbb megoldás. Amennyiben egy adat fizikailag nincs jelen egy eszközön, akkor nem veszhet el.  

 

Az asztali operációs rendszerek nagy előnnyel bírnak a mobil rendszerekkel szemben; felhasználó személyekhez tudunk jogosultságokat rendelni. Normálisan működő céges környezetbe a felhasználói név + jelszó kitöltése nélkül nem tudunk belépni. Bejutáskor autentikáltuk magunkat a rendszer felé, s a jól működő biztonsági rendszer hozzánk, mint az adott felhasználói jog tulajdonosához, hozzáad egyéni szabályokat, egyedi biztonsági beállításokat, s azt mondhatja; az én felhasználóm azon a gépen azt az alkalmazást úgy indíthatja el, ahhoz a fájlhoz azon a gépen azon a módon férhet hozzá, ezen a gépen én kinyomtathatom ezt a fájlt, x valaki csak beletekinthet, y valaki bele sem nézhet, viszont, ha az egészet valakinek el kell küldenem beadásra, akkor y felhasználó az egyetlen, aki erős titkosítással kiírhatja egy USB-re.  

Az asztali operációs rendszereknél tehát elég tág a tevékenységi lista, szabályozhatunk alkalmazásokat, felállíthatunk fekete listát, szürke listát, fehér listát, stb.  

 

Nagyon fontos a titkosított adattárolás és továbbítás. Minél egyszerűbben, a felhasználók felé minél átláthatóbban kell megoldani a titkosítás-visszafejtést. Amennyiben egy átlag felhasználónak a kezébe adunk egy visszafejtő kulcsot, akkor ő ezt vagy elfelejti, vagy megosztja a szomszédjával is. Ha nem kérünk tőle semmit, és nem adunk neki semmit, s a háttérben mindent elvégzünk, visszafejtünk, titkosítunk, törlünk, és ő csak azt látja, amit az előző nap is látott, hogy rákattint egy word fájlra és az megnyílik, akkor az ő életét is megkönnyítettük. 

Ugyanez vonatkozik az adattovábbításra is, az adat A pontból B pontba való eljuttatása alap-elvárás. Az, hogy az én oldalamon titkosítva van tárolva, rendben, a túloldalon titkosítva van tárolva, rendben, de a kettő kommunikációja, amíg úton van az adott fájl, adott információ, addig is biztosítanunk kell a megfelelő védettséget neki. Elrettentő példa a gyakorlatból az a külföldi pénzintézet, amelynek nagy nyilvánosságot kapott, otthoni átutaló alkalmazását kellett tesztelnie a Grayteq-nek. A telepített alkalmazásba a felhasználó beütötte a pénzügyi adatokat, saját nevét, felhasználói nevét, jelszavát, s utasítást adott egy összeg átutalására egy megadott számlaszámra. Az alkalmazás előállított ebből az adathalmazból egy txt fájlt, amit mindennemű titkosítás nélkül az internetre küldött. A Grayteq felhívta a pénzintézet figyelmét, hogy erről az adatról egyáltalán nem állapítható meg, mennyire valós. Ha az adott információt menet közben elkapja, s csak a pénz célállomását átírja valaki, akkor a bank oldalán ez úgy értelmezhető, hogy ezt az összeget utalja át egy másik címre. A bank válasza ez volt az észrevételekre; „hiszen mi ezt az üzenetet titkosítjuk"…  

 

A titkosított adattovábbítás kulcskérdés jelen világunkban. Valójában, minden titkosítást fel lehet törni, csak idő, energia és erőforrás kérdése. Az azonban, hogy az illető adat mennyit ér, a ráfordítandó visszafejtési idő és energia mennyibe kerül, az jelentősen lecsökkenti akár egy teljesen hétköznapi, 256 bites titkosítású fájl visszafejtésének az igényét is.

 

Az asztali operációs rendszereken létrehozhatunk tevékenység-felügyeleti szabályokat, meg tudjuk mondani adott gépeknek, adott alkalmazásoknak, adott felhasználóknak, mivel mit csinálhatnak.  

 

A behatolás-megelőzés is érdekes témakör, lévén, hogy az összes mobil eszköz esetében egy nyilvános hozzáférésnél automatikusan mennek fel az eszközök. Ha meg kell akadályozni egy behatolást, akkor annak nem csak a bent a cégen belül kell működnie, s az nem csak a céges infrastruktúrát védő tűzfalakról és védelmi eszközökről szól…Ugyanez vonatkozik a végpont védelemre és a hálózati riasztásokra is. A három téma ott kapcsolódik, hogy végpontnak tekinthetünk bármilyen eszközt, bármilyen portot, amiről az adat elhagyhatja a gépünket. A hordozható tároló eszközök (pendrive, stb.) óriási veszélyt jelenthetnek, amíg nem gondoljuk végig, ki használhat egy egyszerű USB-t. Ki az, aki felteheti a smartphone-ját és használhatja tárolóként. Ezt policyval is befolyásolhatjuk, ill. olyan szoftvereket, védelmi megoldásokat alkalmazunk, ahol ha az illető nem a neki rendelt gyári számú, nem a neki rendelt gyártójú, előre titkosított pendrive-ot  használja a saját gépén, akkor pl. nem mountol az adott operációs rendszer. Ezt legegyszerűbben a végpontvédelmi és az információs karanténok alkalmazásával tudjuk megoldani. Az információs karantén viszonylag egyszerű; bemehetsz, ha megfelelsz a szabályoknak, bent azt tehetsz, ami megfelel a szabályoknak, adatot úgy hozhatsz ki, ahogy én azt előírtam. Ez a legkeményebb hozzáállás. 

 

Ez a rendszer szép, de ha a riasztásokat és jelentéseket nem csatoljuk mögé, akkor kerítünk kell egy olyan helpdeskest, aki 0-tól 24 óráig ott ül az éppen aktuális logoló rendszerünk előtt és próbálja az emberi szem számára felfoghatatlan sebességgel érkező adatokból kihámozni, hogy milyen probléma adódik. Ez nem járható, sem emberileg, sem erőforrásilag, s a hatékonyság is kérdéses. Választhatunk ellenben olyan védelmi megoldást, ami ezt az egészet automatizálja; ha bizonyos paraméterek, bizonyos együttállások létrejönnek, akkor ő küld valósidejű riasztást e-mailben, sms-el telefont csipogtat, naplózza az adott tevékenységet, időbélyeget tesz mellé. Rengeteg olyan dolgot tudunk létrehozni, amivel bizonyíthatóvá válik az adott cselekmény. A lényeg; tudjunk róla.  

 

A mobil operációs rendszereknél mindez nem áll rendelkezésünkre, a fenti dolgok közel sem alkalmazhatók. 

Egy mobil operációs rendszernél ki is a felhasználó? Az, aki a kezébe veszi az adott eszközt. Így, ha a legális felhasználónak megtiltok egy adott tevékenységet, akkor a rosszindulatúnak is meg tudtam tiltani, de ilyenkor a legális nem tudja végezni feladatát. Viszont, ha a legális felhasználónak megengedtem, akkor a rosszindulatúnak is.

A készülék csak bizonyos szintig tud közöttük különbséget tenni. Ilyenkor jön közbe a mobil device management  és az eszköz management; előírunk bizonyos technikai és biztonsági minimumot. Legyen az adott eszközön bekapcsolva a saját, gyárilag beépített, operációs rendszer-szintű belső titkosítása. Léteznek olyan megoldások, ahol, amikor beengedjük a mobil eszközt a rendszerünkbe, akkor az kierőszakolja, gyakorlatilag bekapcsolja a mobil rendszernek a saját titkosítását. Legyen bekapcsolva a képernyő feloldásához szükséges jelszó védelem, ennek is legyen meg az olyan jelszó kódleszívója, hogy négy beütött szám nem elég.  

 

Mielőtt beengednénk az eszközöket, a minimum feltételek tudatosítása után, ellenőríznünk kell azt. A BYOD-nál vannak olyan megoldások, hogy a munkatárs ezt saját maga tudja elvégezni, bevonva őt az eljárásba, be tudjuk engedni egy olyan önkiszolgáló portálra, ahol eszközét maga ellenőrizheti, be tudja regisztrálni, be tudja léptetni. Ezek a megoldások kellően egyszerűek ahhoz, hogy egy átlagos felhasználót ne rettentsenek el.  

Addig, amíg hivatalosan zárt mobil eszközöket engedünk be, addig az aláírás nélküli eszközöket ezek az alkalmazások elég hatékonyan távol tartják. A policy betartását szoftveresen ki lehet és ki kell erőszakolni.  

 

Miért van szükség minderre? Az otthon alkalmazott mobil gép valószínűleg technikailag fejlettebb, vele gyorsabb, erősebb eszközök jönnek be a hálózatunkba, mint amilyenre egyébként költenénk.

Az alkalmazotti elégedettség növelhető, ha megengedjük, hogy azt használja amit megszokott.  

Megtakarítások is adódnak, de alapvetően ne ezek vezéreljék az egész hozzáállásunkat, ugyanis sikerült kimutatni, hogy hardver és szoftver beszerzés terén nincs kimutatható pénzügyi előnye.   

 

Az alkalmazotti befektetés az eszköz megvételét jelenti. Mondhatjuk, hogy ezt maga tegye meg, vagy céges befektetésként is kezelhetjük a beszerzést. Még így is lényegesen kisebb a céges befektetés volumene, mert az eszközök illeszkedési szintjét meg lehet úgy határozni, hogy mindenki kedve szerint hozhat be, s abból próbálunk egy általunk elfogadható, technikailag és biztonságilag még működő illeszkedési szintet kialakítani, és nem mi kezdjük diktálni, hogy csak ilyen és ilyen jöhet be.  

 

A céges ellenőrzés jogosultsága; előfordulhat az a helyzet, hogy az adott munkatárs elveszti a teljes fennhatóságot a saját eszköze felett. Léteznek olyan céges posztok, amelyekben olyan érzékeny információkkal kell az illetőnek dolgozni, hogy ha beengedjük az ő saját eszközét, akkor ezt csak úgy tehetjük, ha az ő local admin jogait, domain jogait passzívan csorbítjuk. Ezt az érintettnek el kell fogadnia.  

 

A tervezésnél meg kell határoznunk az összes létező körülményt, hozzáféréseket, alkalmazás engedélyezéseket, operációs rendszer engedélyezéseket, támogatási erőforrásokat. Meg kell határoznunk biztonsági szempontból a lokális tárolás körülményeit, lehetőségeit, kinek engedjük, kinek nem, titkosításokat, védelmeket, megfelelőséget.

Előre le kell fektetni az egyértelmű szabályokat, nem fordulhat elő, hogy nem magyarázzuk el, mit lehet és mit nem.    

 

 

 www.hetpecset.hu   

 

 

 

Harmat Lajos