Development of information systems - Common Criteria (in Hungarian)

822 views
747 views

Published on

This presentation introduces to the basics of Common Criteria and was held in the frame of the subject "Development of information systems" for the students of Budapest University of Technology and Economics.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
822
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Development of information systems - Common Criteria (in Hungarian)

  1. 1. Common Criteria alapok Krasznay Csaba kancellár.hu Kft.
  2. 2. Napjaink kihívásai <ul><li>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. </li></ul><ul><li>A vásárlóknak dönteniük kell, hogy milyen eszközök alkalmasak informatikai rendszerük kielégítő védelmére. </li></ul><ul><li>Hatás: a termékek kiválasztása befolyásolja az egész informatikai rendszer biztonságát. </li></ul>
  3. 3. Alapok <ul><li>A biztonságos rendszerek építése tehát függ a következőktől: </li></ul><ul><li>Jól meghatározott IT biztonsági követelmények és specifikációk </li></ul><ul><ul><li>Tulajdonképpen milyen biztonsági funkciókat is akarunk? </li></ul></ul><ul><li>Minőségi biztonsági mérőszámot és megfelelő tesztelést, értékelést, felmérést kell alkalmazni </li></ul><ul><ul><li>Biztosítékot akarunk arra, hogy amit kapunk, az tényleg az, amit kértünk. </li></ul></ul>
  4. 4. Miért kell a Common Criteria ? Biztonsági követelmény rendszer & Felülvizsgálati módszertan Főbb tényezők Nemzetközi IT piaci trendek Közös nemzetközi biztonsági követelmények Számtalan már létező módszertan felülvizsgálata IT biztonsági kihívások fokozódása
  5. 5. Mi a CC? <ul><li>Nemzetközileg elfogadott keretrendszer az IT biztonság területén </li></ul><ul><ul><li>Közös struktúra és nyelv a termékek/rendszerek IT biztonsági követelményeinek kifejezésére </li></ul></ul><ul><ul><li>Szabványos IT biztonsági követelmény összetevők és csomagok gyűjteménye </li></ul></ul><ul><li>Nemzetközileg elfogadott értékelési módszertan, besorolási rendszer </li></ul><ul><li>ISO s zabvány ( ISO/IEC 15408) </li></ul><ul><li>Elkerülhetetlen </li></ul>
  6. 6. CC -t egyezményesen elfogadó államok <ul><li>USA </li></ul><ul><li>Kanada </li></ul><ul><li>UK </li></ul><ul><li>Németország </li></ul><ul><li>Franciaország </li></ul><ul><li>Japán </li></ul><ul><li>Ausztrália </li></ul><ul><li>Új-Zéland </li></ul><ul><li>Hollandia </li></ul><ul><li>Norvégia </li></ul><ul><li>Koreai Köztársaság </li></ul><ul><li>Spanyolország </li></ul><ul><li>Svédország </li></ul><ul><li>Görögország </li></ul><ul><li>Finnország </li></ul><ul><li>Olaszország </li></ul><ul><li>Ausztria </li></ul><ul><li>Izrael </li></ul><ul><li>Magyarország </li></ul><ul><li>Törökország </li></ul><ul><li>Szingapúr </li></ul><ul><li>Csehország </li></ul><ul><li>India </li></ul><ul><li>Dánia </li></ul><ul><li>Malájzia </li></ul>
  7. 7. A történet European National & Regional Initiatives ‘ 89-’93 Canadian Initiatives ‘ 89-’93 Common Criteria Project ‘ 93-- ISO IS 15408 ‘ 99 CTCPEC 3 ‘ 93 NIST’s MSFR ‘ 90 ISO Initiatives ‘ 92-- ISO /IEC 15408 :2005 ‘ 05 US TCSEC ‘ 83, ‘85 Federal Criteria ‘ 92 Common Criteria 1.0 ‘ 96 Common Criteria 2.1 ‘ 99 ITSEC 1.2 ‘ 91 Common Criteria 2. 3 ‘ 05 Common Criteria 3.1 ’ 06
  8. 8. Common Criteria – Aktuális állapot <ul><li>Jelenlegi verzió : </li></ul><ul><ul><li>CC version 3.1 , 2006. szeptemberétől (R2 2007. szeptemberétől) </li></ul></ul><ul><ul><li>Szabványként elfogadva a CC v. 2.3 : </li></ul></ul><ul><li>ISO /IEC 15408 :2005 , 2005. szeptembere óta. </li></ul><ul><li>Jövő : </li></ul><ul><ul><li>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 </li></ul></ul>
  9. 9. Tanúsítványok száma
  10. 10. Mit fed le a Common Criteria <ul><li>Olyan IT rendszerek és termékek biztonsági tulajdonságainak a specifikációja, melyek a következőket valósítják meg: </li></ul><ul><ul><li>confidentiality: bizalmasság, </li></ul></ul><ul><ul><li>integrity: sértetlenség, </li></ul></ul><ul><ul><li>availability: rendelkezésre állás. </li></ul></ul><ul><li>Független értékelések eredményeinek az összehasonlíthatósága </li></ul><ul><li>Hardverben, szoftverben és förmverben implementált védelmi intézkedésekre vonatkoztatható </li></ul><ul><ul><li>technológia-független </li></ul></ul><ul><ul><li>a fejlesztő által kívánt kombinációk határozhatók meg </li></ul></ul><ul><li>Értékelés módszertan </li></ul><ul><ul><li>ezt a Common Evaluation Methodology for Information Technology Security Evaluation (CEM) tartalmazza </li></ul></ul>
  11. 11. Mit nem fed le a Common Criteria <ul><li>A személyi és fizikai biztonsági intézkedések implementációjának vizsgálatát </li></ul><ul><li>A CC felhasználását </li></ul><ul><ul><li>adminisztratív, jogi, eljárásbeli szabályok </li></ul></ul><ul><ul><li>tanúsítási és akkreditálási eljárások </li></ul></ul><ul><ul><li>kölcsönös elfogadási megállapodások </li></ul></ul><ul><li>Kriptográfiai algoritmusok leírása </li></ul>
  12. 12. Common Evaluation Methodology (CEM) <ul><li>CEM elválaszthatatlan része a CC-nek. </li></ul><ul><li>CEM határozza meg azt a folyamatot, amit az auditornak végre kell hajtani a biztonsági kritériumok ellenőrzése során. </li></ul><ul><li>CEM felülvizsgálati sémákat ad a CC konzisztens alkalmazásához az ismétlődő auditok során. </li></ul><ul><li>Így tehát, CEM a legfontosabb komponens a kölcsönös nemzetközi elfogadáshoz. </li></ul>
  13. 13. Viszonya más biztonsági szabványokhoz Összetett IT rendszerek Egyszerű termékek Technikai megközelítés Szervezeti megközelítés FIPS 140 ITSEC/CC ISO/IEC 27001 IT Baseline Protection Manual ISO/IEC 13335 CobiT
  14. 14. Szól a felhasználóknak <ul><li>El tudják dönteni, hogy az adott termék biztonsági szintje megfelel-e számukra. </li></ul><ul><li>Össze tudják hasonlítani a különböző termékeket az értékelések alapján. </li></ul><ul><li>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. </li></ul>
  15. 15. Szól a fejlesztőknek <ul><li>Segítséget nyújt az értékelésre való felkészítéshez. </li></ul><ul><li>Megmutatja a fejlesztőknek, hogy a termék megfelelően biztonságos-e. </li></ul><ul><li>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. </li></ul>
  16. 16. Szól a értékelőknek <ul><li>Megmondja, hogy milyen vizsgálatokat és melyik biztonsági elemeken kell végrehajtaniuk az értékelőknek. </li></ul><ul><li>Nem mondja meg, hogy ezeket milyen módon kell végrehajtaniuk. </li></ul>
  17. 17. Fogalmak <ul><li>Target of Evaluation (TOE) – Értékelés Tárgya (ÉT) </li></ul><ul><li>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 </li></ul><ul><li>Operációs rendszer, számítógéphálózat, alkalmazás, hardver stb. </li></ul>
  18. 18. Fogalmak <ul><li>Protection Profile (PP) – Védelmi Profil (VP) </li></ul><ul><li>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. </li></ul><ul><li>Egységes biztonsági követelményeknek megfelelő termékeket lehet fejleszteni a PP alapján, felfogható egyfajta „szakácskönyvnek”. </li></ul>
  19. 19. Fogalmak <ul><li>Security Target (ST) – Biztonsági Előirányzat (BE) </li></ul><ul><li>Biztonsági követelmények és előírások olyan összessége, amelyet valamilyen adott TOE értékelésének alapjaként használnak. </li></ul><ul><li>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. </li></ul>
  20. 20. Fogalmak <ul><li>Security Functional Requirements – Biztonsági Funkcionális Követelmények </li></ul><ul><li>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. </li></ul><ul><li>Gyakorlatilag a termék vagy rendszer azon funkciói, melyek az értékelés hatálya alá esnek. </li></ul>
  21. 21. Fogalmak <ul><li>Assurance Requirements – Garanciális Követelmények </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  22. 22. Mi előzi meg a fejlesztést? 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. A biztonsági célok kialakítása Védendő vagyontárgyak A biztonsági környezet kialakítása Biztonsági célok TOE Fizikai környezet Feltétele-zések Fenyege-tések Szervezet-biztonsági Szabályok TOE célja
  23. 23. Mi előzi meg a fejlesztést? 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.. A biztonsági követelményeken keresztül a TOE specifikációja CC Követelmény katalógus A biztonsági követelmények kialakítása TOE összefoglaló specifikáció Biztonsági célok Funkcionális követelmények Garanciális követelmények Környezeti követelmények
  24. 24. Security Environment (Környezet) <ul><li>Részei: </li></ul><ul><ul><li>az összes releváns törvényt </li></ul></ul><ul><ul><li>szervezeti biztonságpolitikai dokumentumot </li></ul></ul><ul><ul><li>szokást, gyakorlatot és tudást </li></ul></ul><ul><ul><li>az összes veszélyt, ami jelen van, vagy várhatóan jelen lesz a környezetben </li></ul></ul><ul><li>HOL akarjuk a terméket használni? </li></ul>
  25. 25. Security Objectives (Célok) <ul><li>Részei: ellentmondásmentes célok. </li></ul><ul><li>A célokat csoportosítani kell aszerint, hogy azok az Értékelés Tárgyára (TOE) vonatkoznak vagy annak környezetére. </li></ul><ul><li>MIT akarunk csinálni a termékkel? </li></ul>
  26. 26. Security Requirements (Követelmények) <ul><li>Részei: funkcionális, garanciális. </li></ul><ul><li>Számelméleti biztonsági eljárások alkalmazása esetén funkcióerősség (SOF) vizsgálata. </li></ul><ul><li>A megvalósításban a pontosság ellenőrzése. </li></ul><ul><li>A megvalósításban alkalmazott eljárás hatékonyságának ellenőrzése. </li></ul><ul><li>HOGYAN akarjuk megvalósítani a terméket? </li></ul>
  27. 27. Security Specifications (Előírások) <ul><li>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). </li></ul><ul><li>MI legyen tulajdonképpen a termék? </li></ul>
  28. 28. A fejlesztés szemléletmódja Forráskód / Hardver terv Funkcionális specifikáció Magas-szintű terv Biztonsági követelmények Megvalósítás A tervezés és implementálás finomítása Megfelelőségi ellenőrzés és integrációs tesztelés
  29. 29. A fejlesztéstől a minősítésig Ideiglenes értékelési eredmény Biztonsági követelm. (PP) TOE Megvaló-sítás TOE Fejlesztés TOE Értékelése Értékelési eredmények tanúsítása Tanúsított értékelési eredmény Értékelési Szempontok (CC) Biztonsági célok Biztonsági specifikáció (ST) (Termék)
  30. 30. A CC minősítés sémája <ul><li>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. </li></ul><ul><li>A laboratóriumi kiértékelő munka a Minősítő Hatóság felügyeletével történik. </li></ul><ul><li>A Minősítő Hatóság a kiértékelés sikeres befejezésekor adja ki a hitelesítést. </li></ul><ul><li>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). </li></ul><ul><li>NIAP jóváhagyva az MRA –Mutual Recognition Arrangement- által </li></ul>
  31. 31. A Védelmi Profil felépítése
  32. 32. Biztonsági Előirányzat
  33. 33. CC leírások Család k komponens komponens komponens Osztály b Család 1 komponens komponens komponens Család i komponens komponens komponens Család j komponens komponens komponens Osztály a Csomagok Funkcionális vagy garancia követelmények újrahasználható készlete Opcionális (nem CC) követelmények Védelmi profil Biztonsági rendszerterv
  34. 34. Követelmény hierarchia <ul><li>Osztály </li></ul><ul><ul><ul><li>Azonos terület, különböző célok </li></ul></ul></ul><ul><li>Család </li></ul><ul><ul><ul><li>Azonos cél, eltérő hangsúly és szigorúság </li></ul></ul></ul><ul><li>Komponens </li></ul><ul><ul><ul><li>Követelmények egy készlete, elemekből áll. </li></ul></ul></ul><ul><ul><ul><li>Családon belül rendezések lehetnek. </li></ul></ul></ul><ul><ul><ul><li>Elem oszthatatlan. </li></ul></ul></ul><ul><ul><li>Függőségek (komponensek között) </li></ul></ul><ul><ul><li>Műveletek: iteráció, paraméterezés, kiválasztás, finomítás </li></ul></ul>
  35. 35. Követelmények használata <ul><li>Követelmények kiválasztása: </li></ul><ul><li>csomag (package): néhány követelmény. Az Értékelési Garanciaszint (EAL) is az. </li></ul><ul><li>Védelmi Profil (PP): termékfüggetlen, tartalmaz funkcionális és garanciális követelményeket is. </li></ul><ul><li>Biztonsági Előirányzat (ST): adott termékhez, tartalmaz funkcionális és garanciális követelményeket is. </li></ul>
  36. 36. Követelmények használata <ul><li>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. </li></ul>
  37. 37. CC funkcionális követelmény-osztályok <ul><li>Class FAU: Biztonsági átvilágítás </li></ul><ul><li>Class FCO: Kommunikáció </li></ul><ul><li>Class FCS: Kriptográfiai támogatás </li></ul><ul><li>Class FDP: Felhasználói adatvédelem </li></ul><ul><li>Class FIA: Azonosítás és hitelesítés </li></ul><ul><li>Class FMT: Biztonságirányítás </li></ul><ul><li>Class FPR: Titoktartás </li></ul><ul><li>Class FPT: A TSF védelme </li></ul><ul><li>Class FRU: Erőforrás-felhasználás </li></ul><ul><li>Class FTA: TOE-hozzáférés </li></ul><ul><li>Class FTP: Bizalmi útvonal/csatornák </li></ul>
  38. 38. FAU: Biztonsági átvilágítás osztály <ul><li>Biztonsági átvilágítás </li></ul><ul><ul><li>automatikus válasz </li></ul></ul><ul><ul><li>adatgenerálás </li></ul></ul><ul><ul><li>analízis </li></ul></ul><ul><ul><li>átvizsgálás </li></ul></ul><ul><ul><li>eseményszűrés </li></ul></ul><ul><ul><li>eseménytárolás </li></ul></ul>
  39. 39. FAU: Biztonsági átvilágítás osztály <ul><li>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: </li></ul><ul><ul><li>Az átvilágítási funkciók inicializációja és leállítása; </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>[értékadás: más, külön meghatározott átvilágítási esemény ]. </li></ul></ul>
  40. 40. Mobil Kód Elszigetelése Védelmi Profil <ul><li>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: </li></ul><ul><ul><li>Az átvilágítási funkciók inicializációja és leállítása; </li></ul></ul><ul><ul><li>A letöltött mobil kód rendszer erőforrásaihoz való hozzáférési kísérletei; </li></ul></ul><ul><ul><li>[értékadás: más, külön meghatározott átvilágítási esemény ]. </li></ul></ul>
  41. 41. De hogyan jutottunk el idáig? <ul><li>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. </li></ul><ul><li>O.AUDIT támogatja O.CONFIGURE -t abban, hogy az adminisztrátor azonosítani és finomhangolni tudja a biztonságosan végrehajtható műveleteket. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  42. 42. Hogyan olvassuk ki ezt a PP-ből?
  43. 43. Hogyan olvassuk ki ezt a PP-ből?
  44. 44. Hogyan olvassuk ki ezt a PP-ből?
  45. 45. Hogyan olvassuk ki ezt a PP-ből?
  46. 46. FCO: Kommunikáció osztály <ul><li>Kommunikáció </li></ul><ul><ul><li>adatcserében résztvevők azonosítása </li></ul></ul><ul><ul><ul><li>forrás nem tagadhatja le a küldést </li></ul></ul></ul><ul><ul><ul><li>fogadó nem tagadhatja le a fogadást </li></ul></ul></ul>
  47. 47. FCS: Kriptográfiai támogatás osztály <ul><li>Kulcsmenedzsment (generálás, terjesztés, hozzáférés, megsemmisítés) </li></ul><ul><li>Titkosítás működése </li></ul>
  48. 48. FDP: Felhasználói adatvédelem osztály (1) <ul><li>Hozzáférés-vezérlési politika </li></ul><ul><li>Hozzáférési funkciók </li></ul><ul><li>Adathitelesség </li></ul><ul><li>Export </li></ul><ul><li>Információfolyam vezérlési politika </li></ul><ul><li>Információfolyam vezérlési funkciók </li></ul><ul><li>Import </li></ul><ul><li>Belső TOE átvitel </li></ul>
  49. 49. FDP: Felhasználói adatvédelem osztály (2) <ul><li>Maradék információvédelem </li></ul><ul><li>Rollback </li></ul><ul><li>Tárolt adatok integritása </li></ul><ul><li>Biztonsági funkciók közötti felhasználói adatbiztonság átvitel védelme </li></ul><ul><li>Biztonsági funkciók közötti felhasználói adatintegritás átvitel védelme </li></ul>
  50. 50. FIA: Azonosítás és hitelesítés osztály <ul><li>Hiteleségi hibák </li></ul><ul><li>Felhasználói attributumok definiálása </li></ul><ul><li>Titkok specifikációja </li></ul><ul><li>Felhasználó hitelesítése </li></ul><ul><li>Felhasználó azonosítása </li></ul><ul><li>Felhasználó - folyamat kötés </li></ul>
  51. 51. FMT: Biztonságirányítás osztály <ul><li>TSF funkciók menedzsmentje </li></ul><ul><li>Biztonsági attribútumok menedzsmentje </li></ul><ul><li>TSF adatok menedzsmentje </li></ul><ul><li>Visszavonások </li></ul><ul><li>Lejárat </li></ul><ul><li>Szerepek </li></ul>
  52. 52. FPR: Titoktartás osztály <ul><li>Anonimitás </li></ul><ul><li>Álnevek </li></ul><ul><li>Összekapcsolhatatlanság </li></ul><ul><li>Megfigyelhetetlenség </li></ul>
  53. 53. FPT: biztonsági funkciók védelme osztály (1) <ul><li>Absztrakt gép teszt </li></ul><ul><li>Hiba-biztonság </li></ul><ul><li>Exportált TSF adatok rendelkezésre állása </li></ul><ul><li>Exportált TSF adatok biztonsága </li></ul><ul><li>Exportált TSF adatok integritása </li></ul><ul><li>Belső TOE - TSF átvitel </li></ul><ul><li>Fizikai védelem </li></ul><ul><li>Biztonságos feléledés </li></ul>
  54. 54. FPT: Biztonsági funkciók védelme osztály (2) <ul><li>Visszajátszás detektálás </li></ul><ul><li>Hivatkozás-közvetítés </li></ul><ul><li>Tartomány-szétválasztás </li></ul><ul><li>Állapotszinkron protokoll </li></ul><ul><li>Időbélyegek </li></ul><ul><li>TSF-ek közötti adatkonzisztencia </li></ul><ul><li>Replikált adatok konzisztenciája </li></ul><ul><li>TOE önteszt </li></ul>
  55. 55. FRU: Erőforrás-felhasználás osztály <ul><li>Hibatűrés </li></ul><ul><li>Szolgáltatások prioritása </li></ul><ul><li>Erőforrás kiosztás </li></ul>
  56. 56. FTA: TOE-hozzáférés osztály <ul><li>Választható attributumok hatókörének korlátozása </li></ul><ul><li>Többszörös egyidejű szekciók korlátozása </li></ul><ul><li>Szekciók zárolása </li></ul><ul><li>Hozzáférések megjelölése </li></ul><ul><li>Hozzáférési napló </li></ul><ul><li>TOE szekció létesítése </li></ul>
  57. 57. FTP: Bizalmi útvonal/csatornák osztály <ul><li>TSF-ek közötti biztonságos csatorna </li></ul><ul><li>Biztonságos útvonal </li></ul>
  58. 58. CC garanciális követelmény-osztályok <ul><li>Class ADV: Fejlesztés </li></ul><ul><li>Class AGD: Útmutató dokumentumok </li></ul><ul><li>Class ALC: Az életciklus támogatása </li></ul><ul><li>Class ATE: Vizsgálatok (tesztek) </li></ul><ul><li>Class AVA: A sebezhetőség felmérése </li></ul><ul><li>Class ACO: Kompozíció </li></ul>
  59. 59. Mik is a garanciális követelmények? <ul><li>Betartandó fejlesztési eljárásrend (ami fejlesztői tevékenységelemek néven szerepel a szabványban) </li></ul><ul><li>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) </li></ul><ul><li>Értékelői tevékenységelemek ( mit kell az értékelőnek vizsgálni, és nem hogyan [ez a CEM-ben található]) </li></ul>
  60. 60. Pl.: ATE_FUN.1: Funkcionális tesztelés <ul><li>Fejlesztői tevékenységelemek: </li></ul><ul><ul><li>ATE_FUN.1.1D: A fejlesztőnek tesztelnie kell a TSF-et, és dokumentálnia az eredményeket. </li></ul></ul><ul><ul><li>ATE_FUN.1.2D: A fejlesztőnek el kell készítenie a tesztjegyzőkönyvet. </li></ul></ul>
  61. 61. Pl.: ATE_FUN.1: Funkcionális tesztelés <ul><li>A bizonyítékelemek tartalma és megjelenésmódja: </li></ul><ul><ul><li>ATE_FUN.1.1C: A tesztdokumentációnak tartalmaznia kell a tesztterveket, az elvárt teszteredményeket, és a tapasztalt teszteredményeket. </li></ul></ul><ul><ul><li>ATE_FUN.1.2C: A tesztterveknek azonosítania kell az elvégzendő teszteket, és le kell írnia a teszt elvégzésének forgatókönyvét. A forgatókönyveknek tükrözniük kell az eredmények közötti függőségeket. </li></ul></ul><ul><ul><li>ATE_FUN.1.3C: Az elvárt teszteredményeknél be kell mutatni a sikeres teszt elvégzése után keletkezett kimenetet. </li></ul></ul><ul><ul><li>ATE_FUN.1.4C: A tapasztalt teszteredménynek meg kell egyeznie az elvárt teszteredménnyel. </li></ul></ul>
  62. 62. Pl.: ATE_FUN.1: Funkcionális tesztelés <ul><li>Értékelői tevékenységelemek: </li></ul><ul><ul><li>ATE_FUN.1.1E: Az értékelőnek kell megerősítenie, hogy a szolgáltatott információ megfelel a bizonyítékok tartalmára és megjelenésmódjára vonatkozó minden követelménynek. </li></ul></ul>
  63. 63. Értékelési garanciaszintek <ul><li>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. </li></ul>
  64. 64. Értékelési garanciaszintek
  65. 65. Értékelési garanciaszintek <ul><li>EAL1 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent egy értékeletlen IT termékhez vagy rendszerhez képest. </li></ul>
  66. 66. Értékelési garanciaszintek EAL1
  67. 67. Értékelési garanciaszintek <ul><li>EAL2 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent az EAL1 szinthez képest, megkövetelve fejlesztői vizsgálatokat, egy sebezhetőségi elemzést, és még részletesebb TOE előírásra épülő független vizsgálatot. </li></ul>
  68. 68. Értékelési garanciaszintek EAL2
  69. 69. Értékelési garanciaszintek <ul><li>EAL3 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent az EAL2 szinthez képest, megkövetelve a biztonsági funkciók és módszerek és/vagy eljárások nagyobb teljes vizsgálati érvényesülési területét, amely valamennyi bizalmat ad arra nézve, hogy a TOE nem rongálódik meg a fejlesztés alatt. </li></ul>
  70. 70. Értékelési garanciaszintek EAL3
  71. 71. Értékelési garanciaszintek <ul><li>EAL4 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent az EAL3 szinthez képest, megkövetelve több tervezői leírást, a megvalósítás egy alkészletét, továbbfejlesztett módszereket és/vagy eljárásokat, amelyek szolgáltatják a bizalmat arra nézve, hogy a TOE nem fog megrongálódni a fejlesztés vagy kiszállítás során. </li></ul>
  72. 72. Értékelési garanciaszintek EAL4
  73. 73. Értékelési garanciaszintek <ul><li>EAL5 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent az EAL4 szinthez képest, megkövetelve félformális tervleírásokat, a teljes megvalósítást, egy jobban strukturált (és ezért analizálható) felépítést, rejtett csatornaelemzést, és továbbfejlesztett módszereket és/vagyeljárásokat, amelyek szolgáltatják a bizalmat arra nézve, hogy a TOE nem fog megrongálódni a fejlesztés során. </li></ul>
  74. 74. Értékelési garanciaszintek EAL5
  75. 75. Értékelési garanciaszintek <ul><li>EAL6 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent az EAL5 szinthez képest, megkövetelve több átfogó elemzést, a megvalósítás strukturált ábrázolását, több felépítési struktúrát (pl. rétegezés), több átfogó független sebezhetőségi elemzést, szisztematikus szisztematikus rejtett csatornaazonosítást, és továbbfejlesztett konfigurációmenedzselést és fejlesztési környezet óvintézkedést. </li></ul>
  76. 76. Értékelési garanciaszintek EAL6
  77. 77. Értékelési garanciaszintek <ul><li>EAL7 </li></ul><ul><li>Ez az EAL jelentős garancianövekedést jelent az EAL6 szinthez képest, megkövetelve több formális ábrázolást és formális kölcsönös megfelelést használó átfogó elemzést, és átfogó vizsgálatot. </li></ul>
  78. 78. Értékelési garanciaszintek EAL7
  79. 79. Értékelési garanciaszintek <ul><li>Előfordulhat olyan helyzet, amikor az adott Értékelési Garanciaszinten (EAL) levő követelmények közül valamelyikben az adott termék még szigorúbb feltételeknek is meg tud felelni (megemelt garanciaszint, ami „+” jellel jelölnek). </li></ul><ul><li>Példa: </li></ul><ul><li>elektronikus aláírás-létrehozó termék teljesíti az EAL3 szintnél leírt szállítási feltételeket (ADO_DEL.1), de tudja teljesíteni a szigorúbb feltételt is (ADO_DEL.2), azaz a termék értékelési garanciaszintje EAL3+ lesz. </li></ul>
  80. 80. Értékelési garanciaszintek 875 Összesen 1 EAL7+ 1 EAL7 62 EAL5+ 7 EAL5 260 EAL4+ 84 EAL4 75 EAL3+ 105 EAL3 69 EAL2+ 161 EAL2 20 EAL1+ 30 EAL1 Összesen EAL
  81. 81. Néhány CC minősítéssel rendelkező termék <ul><li>Antivírus: Trend Micro Interscan VirusWall, EAL 4 </li></ul><ul><li>PKI: RSA Keon CA System, EAL 4 </li></ul><ul><li>Tűzfal: Cisco IOS Firewall, EAL 4+ </li></ul><ul><li>Operációs rendszer: Microsoft Windows Server 2003, Microsoft Windows XP, EAL 4+; SuSE Linux Enterprise Server v8 SP3, EAL 3+ </li></ul><ul><li>Intelligens kártya: GemXPresso Pro E64, EAL 4 </li></ul><ul><li>Adatbázis-kezelő: Oracle 10g, EAL 4+ </li></ul>
  82. 82. Melyik garanciaszintet válasszuk? <ul><li>A gyakorlatban általában EAL 3 és EAL 4 szint teljesíthető </li></ul><ul><li>Ennél magasabb szint csak nemzetbiztonsági alkalmazásokban </li></ul><ul><li>De ha valakinek van igénye az EAL 7 szintre… </li></ul>Az igazi programozók binárisan kódolnak

×