common criteria alapok

Common Criteria alapok

Krasznay Csabakancellár.hu Kft.

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.

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.

BiztonságiBiztonságikövetelmény követelmény

rendszerrendszer&&

FelülvizsgálatiFelülvizsgálatimódszertanmódszertan

Főbb tényezőkFőbb tényezőkNemzetkö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ágikihívások

fokozódása

Miért kell 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 Nemzetközileg elfogadott értékelési módszertan,

besorolási rendszer ISO szabvány (ISO/IEC 15408) Elkerülhetetlen

Mi a CC?

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

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

CC-t egyezményesen elfogadó államok

A történet

EuropeanNational

& RegionalInitiatives

‘89-’93

CanadianInitiatives

‘89-’93

CommonCriteriaProject

‘93--

ISOIS 15408

‘99

USTCSEC

‘83, ‘85

CTCPEC3

‘93

FederalCriteria

‘92

CommonCriteria

1.0

‘96

CommonCriteria

2.1

‘99NIST’sMSFR

‘90

ITSEC1.2

‘91ISO

Initiatives‘92--

CommonCriteria

2.3

‘05

CommonCriteria

3.1

’06

ISO/IEC15408:2005

‘05

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

Tanúsítványok száma

Kiadott CC tanúsítványok száma

1 2 12 22 2753 57

92

147169

223

70

0

50

100

150

200

250

1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008

Év

Tan

úsí

tván

yok

szám

a

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

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

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.

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

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.

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.

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.

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

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.

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.

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.

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

TOE célja

A biztonságikörnyezetkialakítása

Biztonsági célok

TOE Fizikai környezet

Feltétele-zések

Fenyege-tések

Szervezet-biztonsági Szabályok

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ágikövetelményekkialakí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

Mi előzi meg a fejlesztést?

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?

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?

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?

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?

A fejlesztés szemléletmódja

Forráskód / Hardver terv

Forráskód / Hardver terv

Funkcionális specifikáció

Funkcionális specifikáció

Magas-szintű terv

Magas-szintű terv

Biztonsági követelmények

Biztonsági követelmények

MegvalósításMegvaló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

Ideiglenesértékelésieredmény

Biztonságikövetelm.

(PP)

TOEMegvaló-sítás

TOEFejlesztés

TOEÉrtékelése

Értékelésieredményektanúsítása

Tanúsítottértékelésieredmény

ÉrtékelésiSzempontok

(CC)

Biztonságicélok

Biztonságispecifikáció

(ST)(Termék)

A fejlesztéstől a minősítésig

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

A CC minősítés sémája

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

Biztonsági Előirányzat

Családkkomponens

komponens

komponens

Osztályb

CC leírások

Család1komponens

komponens

komponens

Családikomponens

komponens

komponens

Családjkomponens

komponens

komponens

Osztálya

CsomagokFunkcionális vagygarancia követelményekújrahasználható készlete

CsomagokFunkcionális vagygarancia követelményekújrahasználható készlete

Opcionális (nem CC)követelmények

Opcionális (nem CC)követelmények

Véd

elm

ipr

ofil

Biz

tons

ági

rend

szer

terv

Követelmény hierarchia

OsztályAzonos terület, különböző célok

CsaládAzonos cél, eltérő hangsúly és szigorúság

KomponensKö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

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.

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.

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

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

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:

a) Az átvilágítási funkciók inicializációja és leállítása;

b) 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

c) [értékadás: más, külön meghatározott átvilágítási esemény].

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:

a) Az átvilágítási funkciók inicializációja és leállítása;

b) A letöltött mobil kód rendszer erőforrásaihoz való hozzáférési kísérletei;

c) [értékadás: más, külön meghatározott átvilágítási esemény].

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.

Hogyan olvassuk ki ezt a PP-ből?

FCO: Kommunikáció osztály

Kommunikációadatcserében résztvevők azonosítása

forrás nem tagadhatja le a küldéstfogadó nem tagadhatja le a fogadást

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

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

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

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

FMT: Biztonságirányítás osztály

•TSF funkciók menedzsmentje•Biztonsági attribútumok menedzsmentje•TSF adatok menedzsmentje•Visszavonások•Lejárat•Szerepek

FPR: Titoktartás osztály

•Anonimitás•Álnevek•Összekapcsolhatatlanság•Megfigyelhetetlenség

FPT: biztonsági funkciók védelme osztály (1)

•Absztrakt gép teszt•Hiba-biztonság•Exportált TSF adatok rendelkezésre állása•Exportált TSF adatok biztonsága•Exportált TSF adatok integritása•Belső TOE - TSF átvitel•Fizikai védelem•Biztonságos feléledés

FPT: Biztonsági

funkciók védelme osztály (2)

•Visszajátszás detektálás •Hivatkozás-közvetítés•Tartomány-szétválasztás•Állapotszinkron protokoll•Időbélyegek•TSF-ek közötti adatkonzisztencia•Replikált adatok konzisztenciája•TOE önteszt

FRU: Erőforrás-felhasználás osztály

•Hibatűrés•Szolgáltatások prioritása•Erőforrás kiosztás

FTA: TOE-hozzáférés osztály

•Választható attributumok hatókörének korlátozása•Többszörös egyidejű szekciók korlátozása•Szekciók zárolása•Hozzáférések megjelölése•Hozzáférési napló•TOE szekció létesítése

FTP: Bizalmi útvonal/csatornák osztály

•TSF-ek közötti biztonságos csatorna•Biztonságos útvonal

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ó

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ó])

Pl.: ATE_FUN.1: Funkcionális tesztelés

Fejlesztői tevékenységelemek: ATE_FUN.1.1D: A fejlesztőnek tesztelnie kell

a TSF-et, és dokumentálnia az eredményeket. ATE_FUN.1.2D: A fejlesztőnek el kell

készítenie a tesztjegyzőkönyvet.


A bizonyítékelemek tartalma és megjelenésmódja: ATE_FUN.1.1C: A tesztdokumentációnak tartalmaznia

kell a tesztterveket, az elvárt teszteredményeket, és a tapasztalt teszteredményeket.

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.

ATE_FUN.1.3C: Az elvárt teszteredményeknél be kell mutatni a sikeres teszt elvégzése után keletkezett kimenetet.

ATE_FUN.1.4C: A tapasztalt teszteredménynek meg kell egyeznie az elvárt teszteredménnyel.


Értékelői tevékenységelemek: 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.

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


EAL1 Ez az EAL jelentős garancianövekedést

jelent egy értékeletlen IT termékhez vagy rendszerhez képest.


EAL1



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.


EAL2



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.


EAL3



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.


EAL4


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


EAL5


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


EAL6



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.


EAL7


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

Példa: 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.


EAL Összesen

EAL1 30

EAL1+ 20

EAL2 161

EAL2+ 69

EAL3 105

EAL3+ 75

EAL4 84

EAL4+ 260

EAL5 7

EAL5+ 62

EAL7 1

EAL7+ 1

Összesen 875

Néhány CC minősítéssel rendelkező termék

Antivírus: Trend Micro Interscan VirusWall, EAL 4 PKI: RSA Keon CA System, EAL 4 Tűzfal: Cisco IOS Firewall, EAL 4+ Operációs rendszer: Microsoft Windows Server 2003,

Microsoft Windows XP, EAL 4+; SuSE Linux Enterprise Server v8 SP3, EAL 3+

Intelligens kártya: GemXPresso Pro E64, EAL 4 Adatbázis-kezelő: Oracle 10g, EAL 4+

Melyik garanciaszintet válasszuk?

A gyakorlatban általában EAL 3 és EAL 4 szint teljesíthető

Ennél magasabb szint csak nemzetbiztonsági alkalmazásokban

De ha valakinek van igénye az EAL 7 szintre…

Az igazi programozók binárisan kódolnak

common criteria alapok

Documents