Common Criteria alapok

1. Common Criteria alapok Krasznay Csaba kancellár.hu Kft.

2. 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.

3. 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.

4. Főbb tényezők Nemzetközi IT piaci trendek Számtalan már létező módszertan felülvizsgálata 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 Miért kell a Common Criteria?

5. Mi a CC? • 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 • Nemzetközileg elfogadott értékelési módszertan, besorolási rendszer • ISO szabvány (ISO/IEC 15408) • Elkerülhetetlen

6. CC-t egyezményesen elfogadó államok • Görögország • Finnország • Olaszország • Ausztria • Izrael • Magyarország • Törökország • Szingapúr • Csehország • India • Dánia • Malájzia • USA • Kanada • UK • Németország • Franciaország • Japán • Ausztrália • Új-Zéland • Hollandia • Norvégia • Koreai Köztársaság • Spanyolország • Svédország

7. ITSEC 1.2 ‘91 Common Criteria 2.1 ‘99 Common Criteria 2.3 ‘05 Common Criteria 3.1 ’06 Common Criteria 1.0 ‘96 US TCSEC ‘83, ‘85 Federal Criteria ‘92 A történet CTCPEC 3 ‘93 Canadian Initiatives ‘89-’93 Common Criteria Project ‘93-- NIST’s MSFR ‘90 European National & Regional Initiatives ‘89-’93 ISO/IEC 15408:2005 ‘05 ISO IS 15408 ‘99 ISO Initiatives ‘92--

8. Common Criteria–Aktuális állapot • Jelenlegi verzió: • CC version 3.1, 2006. szeptemberétől (R2 2007. szeptemberétől) • Szabványként elfogadva a CC v. 2.3: • ISO/IEC 15408:2005, 2005. szeptembere óta. • Jövő: • 2008. szeptemberben 875 tanúsított termék volt, csak 2008-ban 70 termék kapott tanúsítást, csak az USA-ban 87 termék állt tanúsítás alatt  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

9. Tanúsítványok száma

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ényeinekaz ö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

11. 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

12. 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.

13. Viszonya más biztonsági szabványokhoz CobiT Összetett IT rendszerek ISO/IEC 13335 IT Baseline Protection Manual ISO/IEC 27001 Egyszerű termékek ITSEC/CC FIPS 140 Technikai megközelítés Szervezeti megközelítés

14. 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.

15. 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.

16. 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.

17. Fogalmak • Target of Evaluation (TOE) – Értékelés Tárgya (ÉT) • Az az informatikai termék vagy rendszer, valamint a hozzá kapcsolódó adminisztrátori és használati útmutatók, amelyre az értékelés irányul • Operációs rendszer, számítógéphálózat, alkalmazás, hardver stb.

18. Fogalmak • Protection Profile (PP) – Védelmi Profil (VP) • Megvalósítástól független, olyan biztonsági követelményrendszer a TOE-k egy kategóriájára, amely adott fogyasztói igényeket elégít ki. • Egységes biztonsági követelményeknek megfelelő termékeket lehet fejleszteni a PP alapján, felfogható egyfajta „szakácskönyvnek”.

19. Fogalmak • Security Target (ST) – Biztonsági Előirányzat (BE) • Biztonsági követelmények és előírások olyan összessége, amelyet valamilyen adott TOE értékelésének alapjaként használnak. • A Biztonsági Előirányzat (ST) az a dokumentum, amely tartalmazza a termék minősítéséhez szükséges összes leírást, a TOE mellett ez szükséges az értékeléshez.

20. Fogalmak • Security Functional Requirements – Biztonsági Funkcionális Követelmények • E követelmények meghatározzák az Értékelés Tárgyától (Target of Evaluation, TOE) elvárt, megfelelő biztonsági magatartást, illetve igyekeznek megfelelni a PP-ben és az ST-ben megállapított biztonsági céloknak. • Gyakorlatilag a termék vagy rendszer azon funkciói, melyek az értékelés hatálya alá esnek.

21. Fogalmak • Assurance Requirements – Garanciális Követelmények • A CC szemlélete az, hogy a későbbiekben bizalmivá váló IT termék vagy rendszer értékelésén (aktív vizsgálatán) alapuló garanciát nyújt. A CC azt javasolja, hogy a dokumentáció, valamint az ennek alapján létrejövő IT termék vagy rendszer érvényesség-vizsgálatát olyan értékelési szakértőkkel célszerű elvégeztetni, akik hangsúlyt fektetnek annak tárgykörére, alaposságára és szigorára. • A fejlesztés során betartandó technikák és az elkészítendő dokumentációkra vonatkozó követelmények, amiket az értékelőnek a megfelelő módon ellenőriznie kell.

22. TOE célja Mi előzi meg a fejlesztést? A biztonsági célok kialakítása TOE Fizikai környezet Feltétele-zések Fenyege-tések A biztonsági környezet kialakítása Biztonsági célok Védendő vagyontárgyak Szervezet-biztonsági Szabályok 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.

23. Mi előzi meg a fejlesztést? A biztonsági követelményeken keresztül a TOE specifikációja Biztonsági célok Funkcionális követelmények Garanciális követelmények A biztonsági követelmények kialakítása TOE összefoglaló specifikáció CC Követelmény katalógus Környezeti követelmények 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..

24. Security Environment (Környezet) • Részei: • az összes releváns törvényt • szervezeti biztonságpolitikai dokumentumot • szokást, gyakorlatot és tudást • az összes veszélyt, ami jelen van, vagy várhatóan jelen lesz a környezetben • HOL akarjuk a terméket használni?

25. Security Objectives (Célok) • Részei: ellentmondásmentes célok. • A célokat csoportosítani kell aszerint, hogy azok az Értékelés Tárgyára (TOE) vonatkoznak vagy annak környezetére. • MIT akarunk csinálni a termékkel?

26. Security Requirements (Követelmények) • Részei: funkcionális, garanciális. • Számelméleti biztonsági eljárások alkalmazása esetén funkcióerősség (SOF) vizsgálata. • A megvalósításban a pontosság ellenőrzése. • A megvalósításban alkalmazott eljárás hatékonyságának ellenőrzése. • HOGYAN akarjuk megvalósítani a terméket?

27. Security Specifications (Előírások) • Részei: a biztonsági működések magas szintű leírásai (amelyek teljesítik a funkcionális követelményeket), a garanciaértékek (amelyek teljesítik a garanciális követelményeket). • MI legyen tulajdonképpen a termék?

28. A fejlesztés szemléletmódja Biztonsági követelmények A tervezés és implementálás finomítása Funkcionális specifikáció Magas-szintű terv Megfelelőségi ellenőrzés és integrációs tesztelés Forráskód / Hardver terv Megvalósítás

29. A fejlesztéstől a minősítésig Biztonsági célok Biztonsági követelm. (PP) TOE Értékelési TOE Ideiglenes Tanúsított Biztonsági Fejlesztés eredmények értékelési értékelési Értékelése specifikáció (ST) eredmény (Termék) eredmény tanúsítása TOE Megvaló-sítás Értékelési Szempontok (CC)

30. A CC minősítés sémája • Az IT biztonsági termékek kiértékelését a CC keretei között egy minősítési séma (közmegegyezésen alapuló) szerint akkreditált laboratóriumok végzik. • A laboratóriumi kiértékelő munka a Minősítő Hatóság felügyeletével történik. • A Minősítő Hatóság a kiértékelés sikeres befejezésekor adja ki a hitelesítést. • Az USA-ban a sémát „NIAP”-nak –National Information Assurance Partnership- nevezik. Magyarországon MIBÉTS a neve (Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma – KIB 25. ajánlás). • NIAP jóváhagyva az MRA –Mutual Recognition Arrangement- által

31. A Védelmi Profil felépítése

32. Biztonsági Előirányzat

33. CC leírások Csomagok Funkcionális vagy garancia követelmények újrahasználható készlete Osztályb Családk komponens Védelmi profil komponens komponens Osztálya Család1 Családj komponens komponens komponens komponens komponens komponens Biztonsági rendszerterv Családi komponens komponens Opcionális (nem CC) követelmények komponens

34. Követelmény hierarchia • Osztály Azonos terület, különböző célok • Család Azonos cél, eltérő hangsúly és szigorúság • Komponens Követelmények egy készlete, elemekből áll. Családon belül rendezések lehetnek. Elem oszthatatlan. Függőségek (komponensek között) Műveletek: iteráció, paraméterezés, kiválasztás, finomítás

35. Követelmények használata Követelmények kiválasztása: • csomag (package): néhány követelmény. Az Értékelési Garanciaszint (EAL) is az. • Védelmi Profil (PP): termékfüggetlen, tartalmaz funkcionális és garanciális követelményeket is. • Biztonsági Előirányzat (ST): adott termékhez, tartalmaz funkcionális és garanciális követelményeket is.

36. Követelmények használata • Létező Védelmi Profilok (PP), csomagok (package), összetevők (component), kiterjesztett követelmények használhatók új követelménykészlet, Védelmi Profil (PP) összeállításánál.

37. 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 CC funkcionális követelmény-osztályok

38. FAU: Biztonsági átvilágítás osztály • Biztonsági átvilágítás • automatikus válasz • adatgenerálás • analízis • átvizsgálás • eseményszűrés • eseménytárolás

39. FAU: Biztonsági átvilágítás osztály • FAU_GEN.1.1: A TSF-nek átvilágítási jegyzőkönyvet kell tudnia előállítani a következő átvilágítási eseményekből: • Az átvilágítási funkciók inicializációja és leállítása; • Az átvilágítás szintjén [választás: legkisebb, alapszintű, részletes, nem specifikált]minden átvilágítási esemény; és • [értékadás: más, külön meghatározott átvilágítási esemény].

40. Mobil Kód Elszigetelése Védelmi Profil • FAU_GEN.1.1: A TSF-nek átvilágítási jegyzőkönyvet kell tudnia előállítani a következő átvilágítási eseményekből: • Az átvilágítási funkciók inicializációja és leállítása; • Aletöltött mobil kód rendszer erőforrásaihoz való hozzáférési kísérletei; • [értékadás: más, külön meghatározott átvilágítási esemény].

41. De hogyan jutottunk el idáig? • T.BROWSER: A mobil kód végrehajtódik egy Internet alkalmazásban (pl. böngésző) a felhasználó számítógépén, ami veszélyezteti a vagyontárgyat. • O.AUDIT támogatja O.CONFIGURE-t abban, hogy az adminisztrátor azonosítani és finomhangolni tudja a biztonságosan végrehajtható műveleteket. • O.AUDIT: A TOE-nak tárolnia kell azokat a próbálkozásokat, amiket a mobil kód hajt végre, és benne rejlik a károkozás lehetősége. • FAU_GEN.1 garantálja, hogy a naplózási bejegyzések a gyanús mobil kód erőforráshoz való hozzáférésekor létrejönnek.

42. Hogyan olvassuk ki ezt a PP-ből?

43. Hogyan olvassuk ki ezt a PP-ből?

44. Hogyan olvassuk ki ezt a PP-ből?

45. Hogyan olvassuk ki ezt a PP-ből?

46. FCO: Kommunikáció osztály • Kommunikáció • adatcserében résztvevők azonosítása • forrás nem tagadhatja le a küldést • fogadó nem tagadhatja le a fogadást

47. FCS: Kriptográfiai támogatás osztály • Kulcsmenedzsment (generálás, terjesztés, hozzáférés, megsemmisítés) • Titkosítás működése

48. FDP:Felhasználói adatvédelem osztály (1) • Hozzáférés-vezérlési politika • Hozzáférési funkciók • Adathitelesség • Export • Információfolyam vezérlési politika • Információfolyam vezérlési funkciók • Import • Belső TOE átvitel

49. FDP:Felhasználói adatvédelem osztály (2) • Maradék információvédelem • Rollback • Tárolt adatok integritása • Biztonsági funkciók közötti felhasználói adatbiztonság átvitel védelme • Biztonsági funkciók közötti felhasználói adatintegritás átvitel védelme

50. FIA: Azonosítás és hitelesítés osztály • Hiteleségi hibák • Felhasználói attributumok definiálása • Titkok specifikációja • Felhasználó hitelesítése • Felhasználó azonosítása • Felhasználó - folyamat kötés