Szabványok, ajánlások, modellek

Átírás

1 Szabványok, ajánlások, modellek Krasznay Csaba HP Magyarország Kft Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Jogszabályok a teljesség igénye nélkül évi VI. törvény az egyének védelméről a személyes adatok gépi feldolgozása során, Strasbourgban, január 28. napján kelt Egyezmény kihirdetéséről 114/2007. (XII. 29.) GKM rendelet a digitális archiválás szabályairól évi C. törvény a számvitelről 34/2004. (XI. 19.) IM rendelet az elektronikus dokumentumok közjegyzői archiválásának szabályairól és az elektronikus levéltárról 3/2005. (III. 18.) IHM rendelet az elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó részletes követelményekről évi CLV. Törvény a minősített adat védelméről évi CXII. törvény a hitelintézetekről és a pénzügyi vállalkozásokról 284/2001. (XII. 26.) Korm. rendelet a dematerializált értékpapír előállításának és továbbításának módjáról és biztonsági szabályairól, valamint az értékpapírszámla, központi értékpapírszámla és az ügyfélszámla megnyitásának és vezetésének szabályairól 2

2 Jogszabályok a teljesség igénye nélkül évi LX. törvény a biztosítókról és a biztosítási tevékenységről évi LXXXII. törvény a magánnyugdíjról és a magánnyugdíjpénztárakról évi XCVI. törvény az Önkéntes Kölcsönös Biztosító Pénztárakról évi LX. törvény az elektronikus közszolgáltatásról 223/2009. (X. 14.) Korm. rendelet az elektronikus közszolgáltatás biztonságáról 78/2010. (III. 25.) Korm. Rendelet az elektronikus aláírás közigazgatási használatához kapcsolódó követelményekről és az elektronikus kapcsolattartás egyes szabályairól 335/2005. (XII. 29.) Korm. rendelet a közfeladatot ellátó szervek iratkezelésének általános követelményeiről 24/2006. (IV. 29.) BM-IHM-NKÖM együttes rendelet a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekről 305/2005. (XII. 25.) Korm. rendelet a közérdekű adatok elektronikus közzétételére, az egységes közadatkereső rendszerre, valamint a központi jegyzék adattartalmára, az adatintegrációra vonatkozó részletes szabályokról 3 A való élet Ahhoz, hogy teljesítsük a jogszabályi kötelezettségeket, nem kell mást tenni, mint használni az ipari szabványokat. Ezek: ISO es család COBIT Common Criteria Bónuszként pedig a PCI DSS 4

3 Mi az IBIR? Az átfogó irányítási rendszernek az a része, amely egy, a működési kockázatokat figyelembe vevő megközelítésen alapulva kialakítja, bevezeti, működteti, figyeli, átvizsgálja, fenntartja és fejleszti az információvédelmet. Az irányítási rendszer magában foglalja a szervezeti felépítést, a szabályzatot, a tervezési tevékenységeket, a felelősségi köröket, a gyakorlatot, az eljárásokat, a folyamatokat és az erőforrásokat. 5 Mi az IBIR? Az IBIR létrehozásának számos oka lehet: Törvénynek vagy szabályozásnak való megfelelés Az információ értéke olyan nagy, hogy nem lehet védtelenül hagyni Külső nyomás (tulajdonosok, partnerek, vásárlók) Ennél kevésbé nyilvánvaló okok is vannak: Az információs rendszerek egyszerűbb kezelése Csökkenő költségek (bár ez elsőre nehezen hihető) 6

4 Mi az IBIR? IBIR-t bevezetni nem egyszerű, mert viszonylag sok idő kell ahhoz, hogy gördülékenyen működjön (ld. ISO 9000) a bevezetés megakadhat a vállalaton belül szervezeti változások miatt a támogatás, az anyagiak vagy az emberek kiesése miatt A tapasztalat azt mutatja, hogy a nagyobb szervezeteknél szokott lenni IBIR-szerű szabályozás, ami viszont nem alkot összefüggő rendszert, hiányos lehet nem lehet tanúsítványt szerezni rá, ami bizonyos esetekben fontos lehet. 7 A szabványról Két részre bontható 1. rész : A Code of Practice for Information Security Managementet (magyarul: Az informatikai biztonság menedzsmentjének gyakorlati kódexe) 2. rész: Specification for Information Security Management Systems. (Az informatikai biztonsági menedzsment rendszerének specifikációja) Nemzetközileg elfogadott és széles körben elismert biztonsági szabvány Definíció szerint a legszéleskörűbb eljárások, melyek az információs biztonság legjobb gyakorlati megvalósítását szolgálják. 8

5 A szabvány rövid története Útmutató Követelmény BS :1995 BS :1998 BS :1999 BS :1999 ISO/IEC 17799:2000 BS :2002 ISO/IEC 17799:2005 ISO/IEC 27001:2005 ISO/IEC 27002:2005 MSZ ISO/IEC 17799:2006 MSZ ISO/IEC 27001: ISO Nagyon rövid, mindössze 8 oldal a szabvány, a többi melléklet és szómagyarázat. Leír egy olyan modellt az IBIR-re, amivel azt elő lehet készíteni, meg lehet valósítani, működtetni lehet, ellenőrizni lehet, át lehet tekinteni, karban lehet tartani, és fejleszteni lehet. Ez alapján tanúsítják az IBIR rendszereket. 10

6 ISO A Plan-Do-Check-Act modellt használja 11 ISO Tervezés (az ISMS kialakítása) Olyan IBIR-politika, -célok, -folyamatok és -eljárások kialakítása, amelyek lényegesek annak érdekében, hogy a kockázat kezelése és az információbiztonság fejlesztése a szervezet általános politikájával és céljaival összhangban lévő eredményeket tudjon felmutatni. Végrehajtás (az ISMS bevezetése és működtetése) Az IBIR-politika, -intézkedések, -folyamatok és - eljárások bevezetése és működtetése. Ellenőrzés (az ISMS figyelemmel kísérése és átvizsgálása) Beavatkozás (az ISMS fenntartása és fejlesztése) A folyamatok teljesítményének értékelése, és ahol lehetséges, mérése az IBIR-politikával, -célokkal és a gyakorlati tapasztalatokkal összevetve, továbbá az eredmények jelentése a vezetésnek átvizsgálás céljából. Helyesbítő és megelőző tevékenységek végrehajtása a belső IBIR-átvizsgálás (audit) és vezetőségi átvizsgálás eredményei, illetve egyéb lényeges információk alapján az ISMS folyamatos fejlesztése érdekében. 12

7 ISO Jelentős változások történtek a szabvány megközelítésében Korábban a CIA követelmények biztosítása volt a fókuszban Az új szabvány az üzleti igényeket helyezi előtérbe Az információbiztonság az információ védelme a széleskörű fenyegetésektől, hogy biztosítsák az üzleti folyamatok működésének folytonosságát, a lehető legkisebbre csökkentsék a kockázatot, és legnagyobbra növeljék a befektetési megtérülést és a működési lehetőségeket. 13 A védelem területei (ISO szerint) Az IBIR kialakítása kockázatelemzéssel kezdődik!!! Szabályzati rendszer Biztonsági szervezet Vagyontárgyak kezelése Személyi biztonság Fizikai és környezeti biztonság Kommunikáció és üzemeltetés biztonsága Hozzáférés-ellenőrzés Információs rendszerek beszerzése, fejlesztése és karbantartása Incidenskezelés Üzletmenet-folytonosság Megfelelőség 14

8 Az ISO es család további szabványai A tervek szerint rövid időn belül kialakítják a szabvány teljes rendszerét Ennek elemei a következők: 27000: IBIR alapok és szótár 27003: IBIR megvalósítási útmutató 27004: Az információbiztonság irányításának mérése 27005: IBIR kockázatmenedzsment 27006: Az IBIR tanúsítást végző szervezetre vonatkozó követelmények 27007: Útmutató az IBIR auditáláshoz (készül) 27008: Útmutató auditoroknak az IBIR kontrollokhoz (készül) 15 Magyar vonatkozású hírek Az ISO es család és a Common Criteria alapján készült a közigazgatás számára a Magyar Informatikai Biztonsági Ajánlás. Ez a közigazgatás bizonyos részein kötelező. Tartalmazza az ISO 27001, ISO és ISO követelményeit is. A készítők szándéka szerint sokkal gyakorlatiasabb, mint a szabványszöveg. 16

9 Mi a COBIT? "Információra és a kapcsolatos technológiára vonatkozó kontroll célkitűzések Egy szakterületre és folyamat keretrendszerre vonatkozóan bevált gyakorlatokat ad, és a tevékenységeket egy kezelhető és logikus struktúrában jeleníti meg Annak érdekében, hogy az informatika az üzleti követelményeknek megfelelően szolgáltasson, a vezetőségnek egy belső irányítási és ellenőrzési rendszert, vagy keretrendszert kell üzemeltetnie. A COBIT kontroll keretrendszer ezen igények teljesítéséhez az alábbiakkal járul hozzá: Kapcsolatot teremt az üzleti követelményekkel, Általánosan elfogadott folyamat modellbe szervezi az informatikai tevékenységeket, Beazonosítja a kiaknázandó jelentősebb informatikai erőforrásokat, Meghatározza a figyelembe veendő vezetési kontroll célkitűzéseket. 17 Az informatikai irányítás központi területei 18

10 COBIT tartalom diagram 19 COBIT elemek összefüggései 20

11 Példa a célok kapcsolatára 21 A COBIT információ kritériumai Eredményesség azzal foglalkozik, hogy az információk az üzleti folyamat szempontjából jelentőséggel bírnak, és hogy az információkat időben, helyes, ellentmondásmentes és használható módon biztosítják. Hatékonyság arra vonatkozik, hogy az információk az erőforrások optimális (legtermelékenyebb és leggazdaságosabb) felhasználásán keresztül kerüljenek biztosításra. Bizalmasság arra vonatkozik, hogy megakadályozza, a bizalmas információk engedély nélküli nyilvánosságra hozatalát. Sértetlenség az információknak a vállalati értékek és elvárások szerinti pontosságára, és teljességére, valamint az információk érvényességére vonatkozik. Rendelkezésre állás azzal foglalkozik, hogy az információk akkor álljanak rendelkezésre, amikor azokra az üzleti folyamatnak szüksége van most, és a jövőben. A szükséges erőforrások, és az erőforrások szolgáltatási képességeinek védelmére is vonatkozik. Megfelelőség azon törvények, jogszabályok, szabályozások és szerződéses megállapodások - azaz kívülről előírt üzleti követelmények és belső irányelvek betartásával kapcsolatos, amelyeknek az üzleti folyamat a tárgyát képezi. Megbízhatóság a szükséges információk vezetés számára történő biztosítására vonatkozik, a vállalkozás működtetése és a pénzügyi megbízhatósági, és irányítási kötelezettségek teljesítése érdekében. 22

12 Informatikai erőforrások Az alkalmazások automatizált felhasználói rendszerek és manuális eljárások, amelyek feldolgozzák az információkat. Az információk azok az adatok, összes formájukban, amelyeket az információrendszerek, mint bemeneti, feldolgozott és kimeneti adatot kezelnek, bármilyen formában használja is azt fel az üzleti tevékenység. Az infrastruktúra az a technológia és azok az eszközök (azaz hardver, operációs rendszerek, adatbázis-kezelő rendszerek, hálózatok, multimédia, és az azokat befogadó és támogatást biztosító környezet), amelyek lehetővé teszik az alkalmazások működését. Az emberek az információrendszerek és szolgáltatások tervezéséhez, szervezéséhez, beszerzéséhez, megvalósításához, szolgáltatásához, támogatásához, figyelemmel kíséréséhez és értékeléséhez szükséges munkatársak. Lehetnek belső, kiszervezet, illetve szerződéses személyek, az igényeknek megfelelően. 23 COBIT kocka 24

13 A COBIT folyamatai 4 alapfolyamat határozza meg az informatika irányítását: Tervezés és Szervezés (PO) A megoldásszállításra (AI) és a szolgáltatásnyújtásra (DS) vonatkozóan megadja az irányvonalat Beszerzés és megvalósítás (AI) Gondoskodik a megoldásokról és továbbadja azokat, hogy szolgáltatások váljanak belőlük Szolgáltatás és támogatás (DS) Megkapja a megoldásokat, és használhatóvá teszi azokat a végfelhasználók számára Figyelemmel kísérés és értékelés (ME) Figyelemmel kíséri az összes folyamatot, hogy gondoskodjon a kijelölt irány követéséről. 25 Tervezés és szervezés PO1 Az informatikai stratégiai terv meghatározása PO2 Az információ-architektúra meghatározása PO3 A technológiai irány kijelölése PO4 Az informatikai folyamatok, szervezet és a kapcsolatok meghatározása PO5 Az informatikai beruházások irányítása PO6 Tájékoztatás a vezetői célokról es irányról PO7 Az informatikai humán erőforrások kezelése PO8 Minőségirányítás PO9 Az informatikai kockázatok felmérése és kezelése PO10 A projektek irányítása 26

14 Beszerzés és megvalósítás AI1 Az automatizált megoldások meghatározása AI2 Az alkalmazási szoftverek beszerzése és karbantartása AI3 A technológiai infrastruktúra beszerzése és karbantartása AI4 Az üzemeltetés és a használat támogatása AI5 Az informatikai erőforrások beszerzése AI6 A változtatások kezelése AI7 A megoldások és változtatások üzembe helyezése és bevizsgálása 27 Szolgáltatás és támogatás DS1 A szolgáltatási szintek meghatározása és betartása DS2 Külső szolgáltatások igénybevételének irányítása DS3 Teljesítmény- és kapacitáskezelés DS4 A szolgáltatás folyamatosságának biztosítása DS5 A rendszerek biztonságának megvalósítása DS6 A költségek azonosítása és felosztása DS7 A felhasználók oktatása és képzése DS8 A rendkívüli események kezelése és a felhasználói támogatás működtetése DS9 Konfigurációkezelés DS10 Problémakezelés DS11 Az adatok kezelése DS12 A fizikai környezet biztosítása DS13 Az üzemeltetés irányítása 28

15 Figyelemmel kísérés és értékelés ME1 Az informatika teljesítményének figyelemmel kísérése és értékelése ME2 A belső irányítási és ellenőrzési rendszer figyelemmel kísérése és értékelése ME3 Külső követelményeknek való megfelelőség biztosítása ME4 Az informatikai irányítás megteremtése 29 Példa egy folyamatra DS5 A rendszerek biztonságának megvalósítása Az információk sértetlenségének megőrzésének és az informatikai eszközök védelmének igénye biztonságirányítás folyamat megvalósítását követeli meg. E folyamat kiterjed az informatikai biztonsági szerepkörök és felelősségek, irányelvek, szabványok és eljárások bevezetésére és karbantartására. A biztonságirányítás kiterjed a biztonsági kérdések figyelemmel kísérésére, valamint a rendszeres tesztelésre és a beazonosított biztonsági gyengeségek, illetve rendkívüli helyzetekre vonatkozó helyesbítő intézkedések megvalósítására is. Az eredményes biztonságirányítás megvéd minden informatikai eszközt azért, hogy a biztonsági sebezhetőségek és rendkívüli helyzetek üzleti hatásait minimalizálja. 30

16 Példa egy folyamatra 31 Példa egy folyamatra 32

17 Példa egy folyamatra 33 Példa egy folyamatra 34

18 Példa egy folyamatra 35 Példa egy folyamatra 36

19 Példa egy folyamatra 37 Példa egy folyamatra 38

20 Napjaink kihívásai A vásárlók egyre több, IT biztonsághoz szükséges eszközhöz férnek hozzá, melyek különböző képességekkel rendelkeznek. A vásárlóknak dönteniük kell, hogy milyen eszközök alkalmasak informatikai rendszerük kielégítő védelmére. Hatás: a termékek kiválasztása befolyásolja az egész informatikai rendszer biztonságát. 39 Alapok A biztonságos rendszerek építése tehát függ a következőktől: Jól meghatározott IT biztonsági követelmények és specifikációk Tulajdonképpen milyen biztonsági funkciókat is akarunk? Minőségi biztonsági mérőszámot és megfelelő tesztelést, értékelést, felmérést kell alkalmazni Biztosítékot akarunk arra, hogy amit kapunk, az tényleg az, amit kértünk. 40

21 Miért kell a Common Criteria? Nemzetközi IT piaci trendek Közös nemzetközi biztonsági követelmények Főbb tényezt nyezők Biztonsági követelmény rendszer & Felülvizsg lvizsgálatilati módszertan Számtalan már létező módszertan felülvizsgálata IT biztonsági kihívások fokozódása 41 Mi a Common Criteria? Nemzetközileg elfogadott keretrendszer az IT biztonság területén Közös struktúra és nyelv a termékek/rendszerek IT biztonsági követelményeinek kifejezésére Szabványos IT biztonsági követelmény összetevők és csomagok gyűjteménye a fejlesztési folyamatokra Nemzetközileg elfogadott értékelési módszertan, besorolási rendszer ISO szabvány (ISO/IEC 15408) A szoftverfejlesztés biztonságának elfogadott módszertana (annak minden kritikájával együtt) 42

22 Története US TCSEC 83, 85 Canadian Initiatives NIST s MSFR 90 Federal Criteria 92 CTCPEC 3 93 Common Criteria Project 93-- Common Criteria Common Criteria 2.3 Common Criteria Common Criteria European National & Regional Initiatives ITSEC ISO Initiatives 92-- ISO IS ISO/IEC 15408: 2005 ISO/IEC 15408: Common Criteria Aktuális állapot Jelenlegi verzió: CC version 3.1, szeptemberétől (R júliustól) ISO/IEC 15408:2008, augusztus óta. Jövő: májusban 1251 tanúsított termék volt, csak 2009-ben 200 termék kapott tanúsítást egyre nagyobb a vásárlói igény a biztonságos termékekre, ezért egyre több termék pályázik a CC minősítésre 44

23 Tanúsítványok száma 45 Mit fed le a Common Criteria Olyan IT rendszerek és termékek biztonsági tulajdonságainak a specifikációja, melyek a következőket valósítják meg: confidentiality: bizalmasság, integrity: sértetlenség, availability: rendelkezésre állás. Független értékelések eredményeinek az összehasonlíthatósága Hardverben, szoftverben és förmverben implementált védelmi intézkedésekre vonatkoztatható technológia-független a fejlesztő által kívánt kombinációk határozhatók meg Értékelés módszertan ezt a Common Evaluation Methodology for Information Technology Security Evaluation (CEM) tartalmazza (ISO/IEC 18045) 46

24 Mit nem fed le a Common Criteria A személyi és fizikai biztonsági intézkedések implementációjának vizsgálatát A CC felhasználását adminisztratív, jogi, eljárásbeli szabályok tanúsítási és akkreditálási eljárások kölcsönös elfogadási megállapodások Kriptográfiai algoritmusok leírása 47 Common Evaluation Methodology (CEM) CEM elválaszthatatlan része a CC-nek. CEM határozza meg azt a folyamatot, amit az auditornak végre kell hajtani a biztonsági kritériumok ellenőrzése során. CEM felülvizsgálati sémákat ad a CC konzisztens alkalmazásához az ismétlődő auditok során. Így tehát, CEM a legfontosabb komponens a kölcsönös nemzetközi elfogadáshoz. 48

25 Szól a felhasználóknak El tudják dönteni, hogy az adott termék biztonsági szintje megfelel-e számukra. Össze tudják hasonlítani a különböző termékeket az értékelések alapján. Megvalósítástól független struktúra, a Védelmi Profil (PP) alapján láthatják az adott fajta termékkel szemben támasztott általános biztonsági követelményeket. 49 Szól a fejlesztőknek Segítséget nyújt az értékelésre való felkészítéshez. Megmutatja a fejlesztőknek, hogy a termék megfelelően biztonságose. Akár több, különböző követelményeket tartalmazó Védelmi Profilból (PP) egy megvalósítástól függő, az adott termékre vonatkozó Biztonsági Előirányzatot (ST) lehet létrehozni. 50

26 Szól a értékelőknek Megmondja, hogy milyen vizsgálatokat és melyik biztonsági elemeken kell végrehajtaniuk az értékelőknek. Nem mondja meg, hogy ezeket milyen módon kell végrehajtaniuk. 51 Mi előzi meg a fejlesztést? A biztonsági célok kialakítása TOE Fizikai környezet Feltételezések Védendő vagyontárgyak A biztonsági környezet kialakítása Fenyege -tések Szervezetbiztonsági Szabályok Biztonsági célok TOE célja Biztonsági cél: Szándéknyilatkozat azonosított fenyegetések elleni fellépésről és/vagy meghatározott szervezeti biztonsági szabályzatoknak és feltételezéseknek való megfelelésről. 52

27 Mi előzi meg a fejlesztést? Biztonsági célok A biztonsági követelményeken keresztül a TOE specifikációja Funkcionális követelmények CC Követelmény katalógus A biztonsági követelmények kialakítása Garanciális követelmények Környezeti követelménye k TOE összefoglaló specifikáció TOE összefoglaló specifikáció: A TOE ST-ben adott összefoglaló specifikációja meghatározza a TOE biztonsági követelményeinek megjelenését. Felsőszintű leírást ad azokról a biztonsági funkciókról, amelyekről kijelentik, hogy teljesítik a funkcionális követelményeket, és azokról a garanciális intézkedésekről, amelyeket a garanciális követelmények teljesítéséhez meg kell hozni.. 53 CC funkcionális követelmény-osztályok Class FAU: Biztonsági átvilágítás Class FCO: Kommunikáció Class FCS: Kriptográfiai támogatás Class FDP: Felhasználói adatvédelem Class FIA: Azonosítás és hitelesítés Class FMT: Biztonságirányítás Class FPR: Titoktartás Class FPT: A TSF védelme Class FRU: Erőforrás-felhasználás Class FTA: TOE-hozzáférés Class FTP: Bizalmi útvonal/csatornák 54

28 CC garanciális követelmény-osztályok Class ADV: Fejlesztés Class AGD: Útmutató dokumentumok Class ALC: Az életciklus támogatása Class ATE: Vizsgálatok (tesztek) Class AVA: A sebezhetőség felmérése Class ACO: Kompozíció 55 Mik is a garanciális követelmények? Betartandó fejlesztési eljárásrend (ami fejlesztői tevékenységelemek néven szerepel a szabványban) A termékhez elkészítendő számtalan dokumentáció (ami bizonyítéka annak, hogy a fejlesztői tevékenységelemek rendben végre lettek hajtva) Értékelői tevékenységelemek (mit kell az értékelőnek vizsgálni, és nem hogyan [ez a CEM-ben található]) 56

29 Értékelési garanciaszintek Az egyre magasabb Értékelési Garanciaszinteken (EAL) egyre több osztály és család által megfogalmazott követelmény jelenik meg, illetve az adott családokon belül az összetevők egyre magasabb szintű feltételeket szabnak. 57 Értékelési garanciaszintek 58

30 Mi az a PCI DSS szabvány? A Payment Card Industry (PCI) Data Security Standard (DSS) szabványt a Visa és a Mastercard alkotta meg. Hozzájuk csatlakozott később az American Express, a Discover Financial Services és a JCB. Elsődleges céljuk a bankkártyákkal való nagyarányú visszaélések csökkentése az elektronikus kereskedelemben, a kártyaelfogadóknál és a kereskedőknél. Mindenkire vonatkozik, aki bankkártya adatokat tárol, dolgozol fel, vagy továbbít. 59 Mi az a PCI DSS szabvány? Tulajdonképpen egy olyan szabvány, ami a bankkártya adatokat feldolgozó cégek biztonsági menedzsmentjével, szabályzati rendszerével, hálózati architektúrájával, szoftvereivel és más védelmi megoldásaival kapcsolatos követelményeket támaszt. Más szabványokkal szemben a követelményeket nem egy bizottság, hanem az élet alkotta. 60

31 Előzmények Elsőként (2001-ben) a VISA jelentetett meg követelményeket, melyek a bankkártyákkal dolgozó e-boltokra vonatkoztak. Ezt Cardholder Information Security Programnak (CISP) hívták. A MasterCard ez idő alatt egy Site Data Protection (SDP) nevű programot dolgozott ki. A két cég 2004-ben kezdett együttműködni, és végére együtt dolgozták ki a PCI DSS szabványt, amihez más gyártók is csatlakoztak. 61 A PCI DSS tartalma Biztonságos hálózat építése és üzemeltetése: 1. követelmény: A kártyabirtokos adatainak védelméért tűzfalat kell telepíteni és üzemeltetni. 2. követelmény: Nem szabad a gyártók által használt alapbeállítású rendszerjelszavakat és biztonsági paramétereket használni. A kártyabirtokos adatainak védelme: 3. követelmény: Védeni kell a kártyabirtokosok tárolt adatait. 4. követelmény: A nyílt hálózatokon történő adatátvitel során titkosítani kell a kártyabirtokos adatait. 62

32 A PCI DSS tartalma Sérülékenység-kezelési program fenntartása: 5. követelmény: Vírusvédelmi megoldásokat kell használni, és rendszeresen frissíteni. 6. követelmény: Biztonságos rendszereket és alkalmazásokat kell fejleszteni és üzemeltetni. Erős hozzáférés-védelmi megoldások alkalmazása: 7. követelmény: A kártyabirtokos adataihoz csak az férhessen hozzá, akire az tartozik. 8. követelmény: Minden olyan ember, aki hozzáférhet a rendszerhez, rendelkezzen egyedi azonosítóval. 9. követelmény: A kártyabirtokos adataihoz való fizikai hozzáférést meg kell akadályozni. 63 A PCI DSS tartalma A hálózatok rendszeres monitorozása és tesztelése: 10. követelmény: A hálózati erőforrásokhoz és a kártyabirtokos adataihoz való minden hozzáférést követni és monitorozni kell. 11. követelmény: A biztonsági rendszereket és folyamatokat rendszeresen tesztelni kell. Információbiztonsági szabályzat fenntartása: 12. követelmény: Információbiztonsági szabályzatot kell fenntartani. 64

33 A PCI DSS tartalma A követelménylista nagyon konkrét. Példának álljon itt a 6.5-ös pont, ami a webes alkalmazásokra vonatkozik. Minden webes alkalmazást olyan biztonságos kódolási útmutatók alapján kell fejleszteni, mint az Open Web Application Security Project (OWASP) útmutatói. A kész kódot ellenőrizni kell a sérülékenységek megtalálása érdekében. Az általános kódolási sérülékenységeket el kell kerülni a szoftverfejlesztési folyamatban, figyelembe véve a következőket: Nem validált input, Feltört hozzáférés-vezérlés (pl. visszaélés az azonosítókkal), 65 A PCI DSS tartalma Feltört hitelesítés és session kezelés (visszaélés a cookie-kal), Cross-site scripting támadás, Puffer túlcsordulás, Injektálásos támadások (pl. SQL injection), Nem megfelelő hibakezelés, Nem biztonságos tárolás, Túlterheléses támadás, Nem biztonságos konfigurációmenedzsment. 66

34 A kártyabirtokos adatai 67 Kire vonatkozik az előírás? A kereskedőkre: E-boltok, Hagyományos boltok, Az elfogadókra: Bankok, Kártyafeldolgozók, akik kapcsolatban állnak a kibocsátókkal A szolgáltatókra: Akik több e-boltot üzemeltetnek, Bankkártya adatokat gyűjtenek a kibocsátók nevében. 68

35 Kire nem vonatkozik az előírás? A bankkártya kibocsátó bankokra A tranzakciók jóváhagyóira, akik nem befogadói a tranzakcióknak Azokra a kereskedőkre, akik nem kezelnek bankkártya adatokat. A kereskedők és más entitások megfelelőségéről az elfogadónak kell gondoskodnia! 69 Köszönöm a figyelmet! csaba.krasznay@hp.com 70