Szabványok, ajánlások, modellek
Krasznay Csaba HP Magyarország Kft.
1
©2010 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 – 1998. évi VI. törvény az egyének védelméről a személyes adatok gépi feldolgozása során, Strasbourgban, 1981. 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 – 2000. é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 – 2009. évi CLV. Törvény a minősített adat védelméről – 1996. é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
Footer Goes Here
Jogszabályok a teljesség igénye nélkül – 2003. évi LX. törvény a biztosítókról és a biztosítási tevékenységről – 1997. évi LXXXII. törvény a magánnyugdíjról és a magánnyugdíjpénztárakról – 1993. évi XCVI. törvény az Önkéntes Kölcsönös Biztosító Pénztárakról – 2009. é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
Footer Goes Here
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:
4
•
ISO 27000-es család
•
COBIT
•
Common Criteria
•
Bónuszként pedig a PCI DSS
Footer Goes Here
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
Footer Goes Here
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:
6
•
Az információs rendszerek egyszerűbb kezelése
•
Csökkenő költségek (bár ez elsőre nehezen hihető)
Footer Goes Here
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
7
•
nem alkot összefüggő rendszert,
•
hiányos lehet
•
nem lehet tanúsítványt szerezni rá, ami bizonyos esetekben fontos lehet.
Footer Goes Here
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
Footer Goes Here
A szabvány rövid története Útmutató
Követelmény
BS 7799-1:1995
BS 7799-2:1998
BS 7799-1:1999
BS 7799-2:1999
ISO/IEC 17799:2000
BS 7799-2:2002
ISO/IEC 17799:2005
ISO/IEC 27001:2005
ISO/IEC 27002:2005 MSZ ISO/IEC 17799:2006
9
MSZ ISO/IEC 27001:2006
Footer Goes Here
ISO 27001 – 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
Footer Goes Here
ISO 27001 – A Plan-Do-Check-Act modellt használja
11
Footer Goes Here
ISO 27001 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)
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.
Beavatkozás (az ISMS fenntartása és fejlesztése)
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
Footer Goes Here
ISO 27002 – 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 •
13
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.
Footer Goes Here
A védelem területei (ISO 27002 szerint) – – – – – – – – – – – – 14
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 Footer Goes Here
Az ISO 27000-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:
15
•
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)
Footer Goes Here
Magyar vonatkozású hírek – Az ISO 27000-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 27002 és ISO 27006 követelményeit is. – A készítők szándéka szerint sokkal gyakorlatiasabb, mint a szabványszöveg.
16
Footer Goes Here
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
Footer Goes Here
Az informatikai irányítás központi területei
18
Footer Goes Here
COBIT tartalom diagram
19
Footer Goes Here
COBIT elemek összefüggései
20
Footer Goes Here
Példa a célok kapcsolatára
21
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
COBIT kocka
24
Footer Goes Here
A COBIT folyamatai – 4 alapfolyamat határozza meg az informatika irányítását:
25
•
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.
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
Példa egy folyamatra
31
Footer Goes Here
Példa egy folyamatra
32
Footer Goes Here
Példa egy folyamatra
33
Footer Goes Here
Példa egy folyamatra
34
Footer Goes Here
Példa egy folyamatra
35
Footer Goes Here
Példa egy folyamatra
36
Footer Goes Here
Példa egy folyamatra
37
Footer Goes Here
Példa egy folyamatra
38
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
Miért kell a Common Criteria? Főbb tényezők Nemzetközi IT piaci trendek
Számtalan már létező módszertan felülvizsgálata
Biztonsá Biztonsági követelmé vetelmény rendszer & Felü Felülvizsgá lvizsgálati módszertan Közös nemzetközi biztonsági követelmények
41
IT biztonsági kihívások fokozódása
Footer Goes Here
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
Footer Goes Here
Története CTCPEC 3
Canadian Initiatives ‘89-’93
US TCSEC ‘83, ‘85
‘93
NIST’s MSFR
Federal Criteria
‘90
‘92
European National & Regional Initiatives ‘89-’93
43
ITSEC 1.2 ‘91
ISO Initiatives ‘92--
Common Criteria Project ‘93--
Common Criteria 1.0
Common Criteria 2.1
‘96
‘99
Common Criteria 2.3
Common Criteria 3.1
‘05
’06
ISO IS 15408 ‘99
ISO/IEC 15408: 2005
ISO/IEC 15408: 2008
Footer Goes Here
Common Criteria – Aktuális állapot – Jelenlegi verzió: •
CC version 3.1, 2006. szeptemberétől (R3 2009. júliustól)
•
ISO/IEC 15408:2008, 2008. augusztus óta.
– Jövő: •
44
2010. 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
Footer Goes Here
Tanúsítványok száma
45
Footer Goes Here
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, sértetlenség, • availability: rendelkezésre állás. • integrity:
– 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
Footer Goes Here
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 és akkreditálási eljárások • kölcsönös elfogadási megállapodások • tanúsítási
– Kriptográfiai algoritmusok leírása
47
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
Mi előzi meg a fejlesztést? A biztonsági célok kialakítása TOE Fizikai környezet
Védendő vagyontárgyak
Feltételezések
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
Footer Goes Here
Mi előzi meg a fejlesztést? Biztonsági célok
CC Követelmény katalógus
A biztonsági követelményeken keresztül a TOE specifikációja Funkcionális követelmények
A biztonsági követelmények kialakítása
Garanciális követelmények TOE Környezeti követelménye k
ö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
Footer Goes Here
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
54
Footer Goes Here
– 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
CC garanciális követelmény-osztályok – Class ADV: Fejlesztés – Class AGD: Útmutató dokumentumok – Class ALC: Az életciklus támogatása
55
– Class ATE: Vizsgálatok (tesztek) – Class AVA: A sebezhetőség felmérése – Class ACO: Kompozíció
Footer Goes Here
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
Footer Goes Here
É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
Footer Goes Here
Értékelési garanciaszintek
58
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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 2004. végére együtt dolgozták ki a PCI DSS szabványt, amihez más gyártók is csatlakoztak.
61
Footer Goes Here
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
Footer Goes Here
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
Footer Goes Here
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: •
64
12. követelmény: Információbiztonsági szabályzatot kell fenntartani.
Footer Goes Here
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
Footer Goes Here
A PCI DSS tartalma
66
•
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.
Footer Goes Here
A kártyabirtokos adatai
67
Footer Goes Here
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:
68
•
Akik több e-boltot üzemeltetnek,
•
Bankkártya adatokat gyűjtenek a kibocsátók nevében.
Footer Goes Here
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
Footer Goes Here
Köszönöm a figyelmet! –
[email protected] – www.krasznay.hu
70
Footer Goes Here
