Szabványok, ajánlások Dr. Krasznay Csaba
Néhány szó a compliance-ről
1
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. • Néhány ezek közül – ISO 27000-es család – Common Criteria – Bónuszként pedig a PCI DSS
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.
2
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ő)
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.
3
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”.
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 27002:2005
ISO/IEC 27001:2005
ISO/IEC 27002:2013
ISO/IEC 27001:2013
4
ISO 27001 • Nagyon rövid 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.
ISO 27001 • A Plan-Do-Check-Act modellt használja
5
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.
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 – 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.
6
A védelem területei (ISO 27002 szerint)
Az ISO 27000-es család további szabványai •
•
• • • • • •
• •
•
•
ISO/IEC 27000 — Information technology - Security Techniques • Information security management systems — Overview and vocabulary [1] • ISO/IEC 27001 — Information technology - Security Techniques Information security management systems — Requirements. The older • ISO/IEC 27001:2005 standard relied on the Plan-Do-Check-Act cycle; the newer ISO/IEC 27001:2013 does not, but has been updated in other ways to reflect changes in technologies and in how organisations manage • information. ISO/IEC 27002 — Information technology - Security Techniques - Code of • practice for information security management ISO/IEC 27003 — Information technology - Security Techniques • Information security management system implementation guidance ISO/IEC 27004 — Information technology - Security Techniques Information security management — Measurement • ISO/IEC 27005 — Information technology - Security Techniques Information security risk management ISO/IEC 27006 — Requirements for bodies providing audit and • certification of information security management systems ISO/IEC 27007 — Information technology - Security Techniques Guidelines for information security management systems auditing • (focused on the management system) ISO/IEC TR 27008 — Guidance for auditors on ISMS controls (focused • on the information security controls) ISO/IEC 27010 — Information technology — Security techniques — • Information security management for inter-sector and inter-organizational communications ISO/IEC 27011 — Information technology - Security Techniques • Information security management guidelines for telecommunications organizations based on ISO/IEC 27002 ISO/IEC 27013 — Information technology - Security Techniques • Guideline on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1
ISO/IEC 27014 — Information technology - Security Techniques Information security governance ISO/IEC TR 27015 — Information security management guidelines for financial services ISO/IEC 27031 — Information technology - Security Techniques Guidelines for information and communication technology readiness for business continuity ISO/IEC 27032 — Information technology - Security Techniques Guideline for cybersecurity ISO/IEC 27033-1 — Information technology - Security Techniques Network security - Part 1: Overview and concepts ISO/IEC 27033-2 — Information technology - Security Techniques Network security - Part 2: Guidelines for the design and implementation of network security ISO/IEC 27033-3 — Information technology - Security Techniques Network security - Part 3: Reference networking scenarios - Threats, design techniques and control issues ISO/IEC 27033-5 — Information technology - Security Techniques Network security - Part 5: Securing communications across networks using Virtual Private Networks (VPNs) ISO/IEC 27034-1 — Information technology - Security Techniques Application security - Part 1: Guideline for application security ISO/IEC 27035 — Information technology - Security Techniques Information security incident management ISO/IEC 27036-3 — Information technology - Security Techniques Information security for supplier relationships - Part 3: Guidelines for information and communication technology supply chain security ISO/IEC 27037 — Information technology - Security Techniques Guidelines for identification, collection, acquisition and preservation of digital evidence ISO 27799 — Information security management in health using ISO/IEC 2700
7
Készülőben • • • • • • • • • • •
ISO/IEC 27017 — Information security management for cloud systems ISO/IEC 27018 — Data protection for cloud systems ISO/IEC 27019 — Information security management guidelines based on ISO/IEC 27002 for process control systems specific to the energy utility industry ISO/IEC 27033 — IT network security, a multi-part standard based on ISO/IEC 18028:2006 (parts 1-3 are published already) ISO/IEC 27036 — Guidelines for security in supplier relationships ISO/IEC 27038 — Specification for redaction of digital documents ISO/IEC 27039 — Intrusion detection and protection systems ISO/IEC 27040 — Guideline on storage security ISO/IEC 27041 — Assurance for digital evidence investigation methods ISO/IEC 27042 — Analysis and interpretation of digital evidence ISO/IEC 27043 — Digital evidence investigation principles and processes
A termékbiztonság 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. • Egyre komolyabban veszik az informatikai termékek nemzetbiztonsági vonatkozásait. • Hatás: a termékek kiválasztása befolyásolja az egész informatikai rendszer biztonságát.
8
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.
Miért kell a Common Criteria? Főbb tényezők Számtalan már létező módszertan felülvizsgálata
Nemzetközi IT piaci trendek
Biztonsági követelmény rendszer & Felülvizsgálati módszertan Közös nemzetközi biztonsági követelmények
IT biztonsági kihívások fokozódása
9
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)
Common Criteria – Aktuális állapot • Jelenlegi verzió: – CC version 3.1, 2006. szeptemberétől (R4 2012. szeptemberétől) – ISO/IEC 15408:2009
• Jövő? • https://www.commoncriteriaportal.org/prod ucts/stats/
10
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)
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
11
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.
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.
12
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ágos-e. • 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.
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.
13
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.
Mi előzi meg a fejlesztést? A biztonsági követelményeken keresztül a TOE specifikációja Biztonsági célok
CC Követelmény katalógus
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..
14
CC funkcionális követelményosztályok • 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
• 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
CC garanciális követelményosztá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ó
15
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ó])
É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.
16
Értékelési garanciaszintek
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.
17
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.
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.
18
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.
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.
19
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.
[email protected]
KÖSZÖNÖM A FIGYELMET!
20
