Az információvédelem menedzselése
17 perc olvasás
Új helyszínen, a Tulip Inn Budapest Millenium Hotelben került sor a Hétpecsét Információbiztonsági Egyesület 64. fórumára 2015. január 21-én, a címben jelzett témáról.
Új helyszínen, a Tulip Inn Budapest Millenium Hotelben került sor a Hétpecsét Információbiztonsági Egyesület 64. fórumára 2015. január 21-én, a címben jelzett témáról.
Gasparetz András egyesületi elnök bevezetőjében ismertette a fórum látogatottsági adatait, ami 2013-2014 vonatkozásában 10%-os növekedést mutat, a céges pártolók száma is növekedett, a Hétpecsétes történetek c.kiadvány iránt pedig növekvő érdeklődés tapasztalható.
Az egyesület idén már 10. alkalommal hirdeti meg pályázatát az „Év információbiztonsági újságírója – 2015" cím elnyerésére. A beadási határidő 2015. február 27. 15 óra. A pályázat beadható személyesen az egyesület székhelyén; 1102 Budapest, Szent László tér 20., elektronikusan a titkar@hetpecset.hu e-mail címen, vagy postán. Követelmény: legalább 5 darab, 2014. január 1. utáni referencia publikáció, ill. nyilvánosan elérhető link. Eredményhirdetés a 65. fórumon, 2015. március 18-án.
Keringer Zsolt, Szombathely Megyei Jogú Város Polgármesteri Hivatalának Informatikai és Infokommunikációs irodavezetője a témát érintő helyi gyakorlati tapasztalatokról szóló esettanulmányt ismertetett az állami és önkormányzati szervek elektronikus információbiztonságáról szóló 2013. évi L. törvény vonatkozásában, ITB törvényi megfelelőség címmel.
A törvény hatálya alá tartozó elektronikus információs rendszerek teljes életciklusában meg kell valósítani:
a vonatkozó rendszerben kezelt adatok és információk bizalmasságát, sértetlenségét, rendelkezésre állását,
magának a rendszernek és a hozzá tartozó elemeknek a sértetlenségét, rendelkezésre állását, valamint zárt, teljes körű, folytonos és kockázatokkal arányos védelmét.
Mindezek figyelembe vételével készítette el a Hivatal az adatvagyon-leltárt, amely tartalmazza a kezelt adatok körét, az EIR-eket, valamint a kockázatelemzést.
Szombathely Megyei Jogú Város Polgármesteri Hivatalában rendelkezésre áll a fejlett IT infrastruktúra és alkalmazáskörnyezet. A számtalan belső és központi alkalmazás egymástól erősen eltérő felhasználói jogosultságokkal bír. A belső alkalmazásoknál biztosított az egységes kezelés, a központi alkalmazások pedig önmagukban biztosítják a felhasználói jogosultságot. Nagyszámú, többszörösen kapcsolódó ügyviteli folyamat jöhet létre a működés során, a 80 ezer főnyi lakos adatkezelési igénye is nagyon változatos lehet.
A szakterületek meghallgatásával határozták meg a belső folyamatokat, azok folyamatgazdáit, a folyamatok elemi lépéseit, a folyamatokban megjelenő elektronikus információs rendszereket, a bennük kezelt adatokat és az adatgazdákat.
Az adatvagyon felmérése és kár-értékelése során az adatgazdákkal és a szakterületekkel egyeztetve, a tanácsadókat is bevonva, a kárérték táblázat segítségével elvégezték az adatok biztonsági szintenkénti
kár-értékelését. A bizalmassági kárértéket az adatok esetleges nyilvánosságra kerülésére vonatkoztatva, a sértetlenségi kárértéket az adatok módosulására vonatkoztatva, a rendelkezésre állási kárértéket pedig az adatok elérhetetlenségekor várható kár-következmények meghatározására vonatkoztatva állapították meg.
Az átláthatóság, kezelhetőség és törvényi megfelelőség, s az IBIR (Információbiztonsági Irányító Rendszer) támogatására a BMC Software uWe! szoftver megoldást vezették be, tanácsadóként pedig bevonták a kancellar.hu Zrt-t.
A folyamatok ismeretében meghatározták
a környezeti infrastruktúrát,
a hálózatot,
a hardvert,
a szoftvert,
az emberi erőforrásokat, és
az adathordozót támogató erőforrásokat.
A kockázatok elemzésére a Central Computer and Telecommunication Agency (CCTA, UK) által kidolgozott kockázatelemzési és kezelési módszertant, a CRAMM (CCTA Risk Analisys and Management Method) módszert alkalmazták.
A kancellar.hu segítségével meghatározták:
A szervezetet érintő kockázatokat; a feltárt sérülékenységek és valós fenyegetések ismeretében kiterjesztve ezeket a korábban kialakított logikai modell elemeire, a fizikai környezetre, EIR-re, a szervezetre, stb.
Az elektronikus információs rendszereket és az azokat érintő kockázatokat, figyelembe véve a modell érintett objektumait, s a szoftveres környezetet (a szoftveres támogatást).
A besoroláshoz a kockázatelemzés a biztonsági követelmények figyelembe vételével történt, követve a
77/2013. (XII.19.) számú NFM rendeletben leírtakat. A releváns kockázatok ismeretében megállapították az elektronikus információs rendszerek védelmének elvárt erősségét, a Hivatal elvárt biztonsági szintjét, kidolgozták a cselekvési tervet.
https://www.vincotte.hu/Tanusitas/ISO_27001
Hargitai Zsolt, a NetIQ Novell SUSE Magyarországi Képviseletének üzletfejlesztési vezetője A belső védelmi rendszer megerősítése – SIEM megoldások kiegészítése jogosultsági információkkal, konfigurációkezeléssel és változásfigyeléssel címmel tartotta előadását.
Az előadó utalt a Vanson Bourne tanulmányára, eszerint; az elmúlt 12 hónapban a cégek több mint 60%-ának volt legalább egy biztonsági eseménye. Jellemző a túlzott magabiztosság, az IT vezetők szerint cégük átlagosan 10 órán belül észleli a biztonsági eseményeket, 35%-uk szerint perceken belül, 22%-uk szerint egy napon belül, 5%-uk szerint egy héten belül. 42% védettnek érzi cégét. http://www.vansonbourne.com
A Verizon Data Breach Investigations Report szerint, a támadást elszenvedett szervezetek között egy sem volt, amely perceken vagy órákon belül észlelte volna a támadást. A cégek 27%-a néhány napon belül, 24%-a heteken belül, 39%-a hónapok elteltével, 9%-a pedig egy év múltán fedezte fel a támadást.
Két fő veszélyességi trend okoz gondot az információ-biztonság számára; a felhő alapú rendszerek és a cégen kívüli technológiák használata a céges munkamenetben, ill. a magánéletben, emellett a hozzáférés is egyre mobilisabb, egyre több céges információ érhető el kívülről is.
A felhasználók ma már maguk kezdeményezik, igénylik a gyors reagálást a felhő, a mobilitás, a BYOD, a közösségi hálózatok, az otthon és a munkahely gyorsan változó követelményei közepette. A hagyományos megközelítés nem eléggé hatékony, a kiberbűnözők az elmúlt években új, fejlettebb módszerekkel jelentkeztek. Ez magában foglalja a peremvédelem feltörését, a rossz biztonsági megoldások és beállítások kihasználását, az egyre fejlettebb adathalászatot, a szolgáltatók támadását, a kiemelt felhasználók jogosultságainak kihasználását.
A gondokat nem az eseményekről szóló adatok hiánya, vagy alacsony száma jelenti, hanem az, hogy azok kezelésekor túl sok a lényegtelen „zaj", közöttük kell a szokatlan tevékenységet okosan azonosítani, a támadásra utaló információkat összerakni. A naplóállományokat olyan információkkal kell ellátni, melyek segítségével a biztonsági esemény felismerhető.
A SIEM (Security Information and Event Management – biztonsági eseménykezelő rendszer) megoldásokat ki kell egészíteni;
a jogosultságok, és a személyazonossági információk kezelésével,
a konfiguráció kezelésével, s
tevékenység figyeléssel, kezeléssel.
A jogosultságot illetően:
A Ponemon Research Third Annual Benchmark Study on Patient Privacy Data Security tanulmánya szerint a felhasználó a leggyengébb láncszem. Őket érinti az adathalászat, a fájlmegosztókkal kapcsolatos gondok, a hordozható eszközök problémái, a konfigurációs hibák. Az alkalmazottak jellemző attitüdje; elégedetlenek, naivak, s vannak közöttük szabotőrök, felbérelt elemek is. Külsős, vagy szerződéses, az informatikai rendszerhez hozzáféréssel bíró munkatársak is okozhatnak gondot biztonsági eseményeknél. Az informatikai rendszerben magában is, ill. alkalmazásainkhoz való hozzáférésben is egyre több külsős felhasználó jelenhet meg, pl. az üzemeltetésre külső cégekkel való szerződéskor, vagy a beszállítói körből.
http://en.wikipedia.org/wiki/Security_information_and_event_management
A személyazonossági információk felhasználása során megoldandó:
a felesleges jogosultságok megszüntetése, csökkentése (pl. külsősőknél)
a rendszergazdai, üzemeltetői jogosultságok menedzselése, nevesítése, figyelése
a SIEM eszközök IDM (Identity Management – azonosság-kezelő) rendszerekkel való integrációja
http://www.openidm.hu/mi_az_idm
https://www.cdsys.hu/megoldasok/identity_management/?article_hid=6
a SIEM rendszerek hálózati eszközökkel való integrációja (gyanús pl., ha egy felhasználó ugyanazon időben két különböző helyről jelentkezik be…)
A tevékenységfigyelés során felvetődő legfontosabb kérdések:
Milyen változások történtek az állományokban?
Mikor történtek a változások?
Ki működött közre a változások során?
Honnan, milyen eszközről végezték ezeket a változtatásokat?
Jóváhagyott változtatások voltak-e ezek?
A speciális kiegészítőkkel, loggyűjtőkkel ellátott logkezelő rendszerek képesek ezen feladatok ellátására is. Az így kapott plusz-információkkal (pl. rendszerfájlok módosulása, adatmegosztás, regisztrációs kulcsok kezelése, médiafájlok kezelése, adatmásolás, új sw-telepítés, stb.) hatékonyabban kezelhetjük a biztonsági eseményeket.
A konfigurációkezelés szempontjai:
A konfigurációk és a felhasználói jogosultságok felmérése
Ajánlott konfigurációk; ajánlások:
CIS – Configuration Management System,
NIST – The US National Institute of Standards and Technology,
https://www.netiq.com/communities/cool-solutions/netiq-views/approaches_to_risk_management ;
SANS – http://www.sans.org/ , http://www.securingthehuman.org
https://www.netiq.com/documentation/noc55/cms/data/bookinfo.html,
csak a legszükségesebb, biztonságos beállítások legyenek jelen!
A biztonsági rések felderítése, összevetése az optimális konfigurációhoz, riasztási szintek hozzárendelése
Peremfeltételek meghatározása és változás-jelentések
Dellei László vezető IT biztonsági tanácsadó, az IT biztonsággal és távközléssel foglalkozó Profexec Services Kft. képviseletében a tapasztalatokon alapuló alkalmazás-biztonságról szólt, az ISO 27034-1 szabvány tükrében. (http://profexec.com/hu )
A tárgyalt téma:
Application Security Maturity Model (OWASP)
Gond:
Tudatos, előre tervezett, szabványosított alkalmazás-biztonság, biztonságos alkalmazás-tervezés a gyakorlatban Magyarországon alig található, ill. ahol van, ott sincs dokumentálva minden funkcionalitása
Minden ilyen (biztonsági) megoldás járulékos költséget jelent a projekt számára, nyűgnek tekintik
Felmerülő kérdések;
miért is van rá szükség, ha az alkalmazás úgysem kerül publikálásra?
a rosszfiúkat biztosan nem fogja érdekelni az alkalmazásom…
elvégeztük a kockázat-, és sérülékenység elemzést minden egyes új alkalmazás bevezetésekor?
dokumentáltuk-e az esetlegesen feltárt sérülékenységeket?
készült-e ezekre intézkedési terv? (a válaszok nagy része nemleges lenne…)
elvégeztük ugyanezt verzióváltáskor, patch implementáláskor?
Leszögezhető;
A biztonság (realizálása) olyan opcionális tevékenység, amely az összes funkció kifejlesztése után kerülhet sorra, a fejlesztési tervekbe ált. nem kerül be különálló fejlesztési sorként
A legtöbb fejlesztői tanfolyam nem, vagy csak csekély mértékben érinti a biztonságos kódolás kérdéskörét
A legtöbb fejlesztői kézikönyvben a biztonsági fejezet a könyv végére kerül (a biztonság az utolsó…)
Az alkalmazás-biztonságot kísérő rossz tapasztalatok:
a legtöbb (mobil)alkalmazás tele van hibával, sérülékenységgel (konfigurációs és tervezési hibák sokasága – authentikáció, authorizáció, session lifetime, stb.)
az elmúlt 10 év alatt nem változott semmi, ugyanazok a gyakori, ismert hibák találhatók meg az egyes web-alkalmazásokban, csak a sorrend változik (OWASP Top10 2004 és OWASP Top10 2013)
A Web Application Hackers Handbook 2. kiadásában szereplő statisztika alapján a web alkalmazások
94%-a érzékeny cross site scripting támadásra (http://www.cert.hu/content/cross-site-scripting-xss )
92% Cross site request forgery-re (http://hu.wikipedia.org/wiki/Cross-site_request_forgery )
71%-nál támadható a jogosultsági rendszer (olyan funkcióhoz lehet hozzáférni, amihez elvileg nincs jogunk)
62%-nál pedig az authentikációban van a hiba
A hibák oka:
folyamatos az időtényezőből eredő nyomás; az új terméknek a meghatározott időben ki kell jönnie, a tesztelésre gyakran nem jut elegendő idő
az élesítés előtti tesztek nem terjednek ki a biztonsági sérülékenységek tesztelésére, brute force tesztre,
(http://www.tankonyvtar.hu/hu/tartalom/tamop425/0046_szoftverteszteles/ch06s08.html ), vagy
elárasztásos tesztre (http://hu.wikipedia.org/wiki/SYN_flood )
folyamatos a pénzügyi nyomás, hogy a termék a lehető legolcsóbban jöjjön ki, ezért a hozzáértő, tapasztalt programozók helyett sokszor bízzák a munkát gyengén képzett emberekre, ez eredményezi a silány minőségű szoftvert
Általános tanácsok a védekezéshez:
A felhasználói becsatlakozás megfelelő ellenőrzése (user input sanitization), ami lehetőleg fehér-listás megközelítést alkalmazzon, mert a fekete-listás megközelítés mindig csak a már ismertté vált támadások után kullog.
Adatbázisokhoz való csatlakozásnál használjunk alkalmazás-kiszolgálókat (application proxy), amelyek lehetőséget biztosítanak a hozzáférés korlátozására, SQL injection elleni filtereket is tartalmaznak (http://pezia.hu/content/2009/03/08/weboldalak_biztons%C3%A1ga_1_sql_injection ), ill. „megtanulja" az alkalmazás működését, és riaszt, esetleg blokkol, ha rendellenességet tapasztal. Ez, ha nem is akadályozza meg a támadást, de jelentősen csökkenti a kihatásokat.
Soha ne használjuk a user oldalt „adatok ideiglenes tárolására", mindent, amit a user küld nekünk, azt potenciális támadásként kell kezelni.
OWASP kapcsolódások:
Initial (ICP, Initial Connection Protocol, kezdeti kapcsolati protokoll)
Managed (menedzselt)
Defined (előre meghatározott)
Quantitatively Managed (méretében meghatározott)
Optimizing (optimalizált)
OWASP ISO/IEC 27034 Application Security Controls Project
Az ISO 27034-1 áttekintése:
Az ISO/IEC 27034-1 szabvány 2011 novemberében került publikálásra, további részei (Part 2-6) ezen időt követően. Az ISO/IEC Joint Technical Committee 1/Sub-committee 27 (az 1. számú technikai bizottság 27. jelzésű albizottsága) keretén belül a WG4-es (Security and Services, biztonság és szolgáltatások) munkacsoport foglalkozik ezzel a szabvánnyal.
A szabvány útmutatót ad a szervezeteknek arról, hogy miképp implementálják a biztonságot az alkalmazás-menedzsment folyamataikba.
Explicit módon, folyamat-alapú megközelítést javasol, határoz meg az alkalmazás-rendszerek biztonsági funkcióinak és kontrolljainak specifikálására, tervezésére, kifejlesztésére, tesztelésére, implementálására és fenntartására.
A szabvány az alkalmazás-biztonságot nem állapotként, hanem folyamatként definiálja, amelyet a szervezet végre tud hajtani a kontrollok és intézkedések végrehajtására. Az ISO 27000 szabványcsalád többi elemével való használatra tervezték.
Mi nem kapcsolható az ISO/IEC 27034-hez?
Nem a szoftver-alkalmazások fejlesztési szabványa
Nem alkalmazás projekt-menedzsment szabvány
Nem SDLC szabvány (Software Development Lifecycle)
Nem nyújt útmutatót a fizikai és hálózat-biztonsághoz
Nem határoz meg kontrollokat és intézkedéseket (metrikák)
Nem javasol biztonságos kódolási stratégiákat program nyelvekre
Az ISO/IEC 27024 szabvány információbiztonsági útmutatóul szolgál
rendszertervezőknek,
üzleti oldal szervezőknek,
fejlesztőknek,
beszerzőknek,
üzleti és IT menedzsereknek,
auditoroknak,
az alkalmazás-rendszerek végfelhasználóinak.
Az ISO 27034 fő koncepciója:
A szabvány legyen stratégiai hozzájárulás az iparág tudásanyagához, elősegítve két, az alkalmazásbiztonsághoz és annak folyamataihoz kapcsolódó alábbi keretrendszerek bevezetését:
ONF (Organizational Normative Framework) – a gyakorlatban legjobban bevált alkalmazás-biztonsági komponensek „konténereit" tartalmazó keretrendszer.
ANF (Application Normative Framework) – az ONF továbbgondolása egy-egy különleges alkalmazásra.
Ezen rugalmas keretrendszerek implementálásával a vállalatok csaknem észrevétlenül vezethetik be az alkalmazás-biztonságot fejlesztési folyamataikba.
A témához kapcsolódó szabvány-hivatkozások:
PCI DSS Requirement 6. – biztonsági rendszerek és alkalmazások fejlesztése, karbantartása
FISMA System and Services Acquisition (SA1-SA19)
COBIT AI2
ISO 27002 12. pont
ISO 27001:2013
Ajánlott lépések a bevezetéskor:
A lépések:
Hatókör meghatározása
Folyamatok meghatározása
Alkalmazás-biztonsági szabályzat kidolgozása:
ISO 27034-1 és ISO 27001:2013
a folyamatba épített kontrollok meghatározása
Tesztelés
Célszerű felméréssel, egyfajta elemzéssel kezdeni, ehhez segítséget adhatnak a szabvány környezetébe tartozó, ill. a szabvány kapcsán elérhető toolkitek, check-listek, érettségi modellek. Utóbbinak célszerű az OWASP érettségi modelljét használni. Ezek alapján fel tudjuk mérni, hogy milyen érettségi szinten van jelenlegi szervezeti struktúránk és technológiai adottságunk. Amennyiben egy konkrét alkalmazás továbbfejlesztéséről van szó, akkor, hogy az milyen szinten van. Ezzel tudunk továbblépni, folyamatokat tudunk definiálni. Meg kell határozni a hatókört, s célszerű szabályzatot alkotni a felelősségi körök tisztázására, hogy egy alkalmazás-fejlesztési projektben biztonság tekintetében kinek mi a feladata, felelőssége és mikor mit kell lépni. Az egész fejlesztési folyamatot tesztelni kell.
Előnyök:
Vezetők, fejlesztők, auditorok és végfelhasználók egyaránt megtapasztalják.
A vezetők konstatálják a biztonságos alkalmazás meglétét, ami vélhetően támadás esetén is meggátolja az adatszivárgást, adatvesztést, vagy legalábbis minimalizálja.
Az auditorok biztosak lehetnek afelől, hogy az egyéb felügyeleti és minden tulajdonosi érdek védelmet élvez, mindazon kontrollok implementálásra kerülnek, amelyet ők egyéb megfontolások alapján is javasolnának.
A fejlesztők nyugodtak lesznek, mert nem őket okolják a felmerülő hibákért.
A végfelhasználók pedig az egészből nem vesznek észre semmit, csak használják a jól működő rendszert.
Otti Csaba mérnök-közgazdász, az Óbudai Egyetem Alkalmazott Biometria Intézet oktatója a fizikai biztonsági rendszerek IT biztonsági problémáiról és azok okairól szólt. Az intézetben kutatják a felhasználói attitüd vonatkozásait, az emberek fejében létező elgondolást, pl. azon biológiai megoldásokról, amelyekkel együtt kell élnünk.
Biztonságos IT környezetünkbe eszközeinkbe bekerülnek nem-biztonságos elektronikai eszközök, pl. IP kamera, ezzel együtt IT megoldások, pl. egy webszerver. Kérdés, elhisszük-e, hogy egy elektronikai rendszereket gyártó cég képes biztonságos IT alkalmazásokat applikálni? Nem. Mintegy 10 évvel vannak lemaradva, bár dolgoznak rajta.
Elvileg, ha tényleg biztonságos rendszert akarunk venni, örülhetünk, ha az common cryteria minősítéssel rendelkezik, fizikai biztonsági eszközökből van benne 3 darab, s ezek sem biometrikus eszközök. Ez nem túl sok…
A fizikai biztonsági rendszerekben jelentkező problémák:
első és legfontosabb: megszűnt a védett tér fogalma.
A húsz évvel ezelőtt kifejlesztett beléptető, vagy biztonsági rendszert bezártuk a falak közé, az objektumba. Mára ez a fogalom megszűnt, a valóságban kiterjedtek a támadók. Azáltal, hogy távolról is hozzá kell férni a rendszerekhez, ezért időben és térben is eltávolodtunk a biztonsági gondolatmenettől. A fizikai biztonsági gyártók gondolkodásába ez ma még nem fér be.
A szabványosítás problémája: ha egy fizikai biztonsági rendszereket gyártó cég saját protokollt fejleszt saját eszközei (kártyaolvasó és vezérlő) közé, s abban találunk biztonsági gondot, az azonnal kompromittálja rendszereinket.
A nulladik napi sérülékenység sem volt értelmezhető fizikai biztonsági környezetben, ha volt is ilyen, a fizikailag bezárt körben ez senkit sem érdekelt. Kijavításának időtartama is mellékes volt. Ezek a rendszerek nincsenek felkészítve a Windows update jellegű folyamatokra, valamifajta frissítési poliszra. A következő néhány évnek ez lesz a legnagyobb problémája.
Tervezés és gyártás: nagyon kevés fizikai biztonsági gyártó engedheti meg magának, hogy megvásárolja magának a szükséges informatikai tudást, ami szükséges.
Implementációs gond, pl. a biztonsági szenzor köré nem implementálják a biztonsági funkciókat.
https://www.commoncriteriaportal.org
A fórumról további információk, valamint az Egyesület életével és az információbiztonsággal kapcsolatos érdekességek a Hétpecsét Egyesület LinkedIn oldalán találhatók.
