Common Criteria (CC): az IT biztonsági szabvány célja és jelentősége

A Common Criteria (CC) alapvető célja és szükségessége

Az információtechnológia (IT) exponenciális fejlődése az elmúlt évtizedekben soha nem látott mértékben növelte a digitális rendszerekbe vetett bizalom fontosságát. A szoftverek és hardverek, amelyekre mindennapi életünk, gazdaságunk és nemzetbiztonságunk épül, kritikus infrastruktúrák részét képezik. Ezen rendszerek biztonsága nem csupán technikai kérdés, hanem alapvető feltétele a stabilitásnak és a működőképességnek. Azonban a biztonsági termékek, mint például tűzfalak, operációs rendszerek, adatbázisok vagy kriptográfiai modulok, komplexitása és a bennük rejlő potenciális sebezhetőségek felvetik a kérdést: hogyan győződhetünk meg arról, hogy ezek a termékek valóban megfelelnek a deklarált biztonsági elvárásoknak?

A válasz erre a kérdésre a Common Criteria (CC), hivatalos nevén az ISO/IEC 15408 szabvány. Ez a nemzetközi szabvány egy egységes keretrendszert biztosít az IT biztonsági termékek és rendszerek értékelésére. Célja, hogy egyértelmű és megismételhető módon lehessen vizsgálni, hogy egy adott termék képes-e ellenállni a meghatározott fenyegetéseknek, és képes-e a specifikált biztonsági funkciók ellátására. A CC lényege, hogy független és objektív értékelést tesz lehetővé, ami növeli a bizalmat a tanúsított termékek iránt.

A szabvány bevezetése előtt számos ország saját nemzeti értékelési módszertannal rendelkezett, mint például az Egyesült Államok TCSEC (Trusted Computer System Evaluation Criteria, azaz az „Orange Book”), az európai ITSEC (Information Technology Security Evaluation Criteria) vagy a kanadai CTCPEC (Canadian Trusted Computer Product Evaluation Criteria). Ezek a különböző megközelítések azonban akadályozták a nemzetközi kereskedelmet és a kölcsönös elismerést. Egy termék, amelyet az egyik országban tanúsítottak, nem feltétlenül volt elfogadott egy másikban anélkül, hogy újra ne értékeljék. Ez a helyzet indokolta egy globálisan elfogadott, harmonizált szabvány létrehozását, amely kiküszöböli ezeket a korlátokat és elősegíti a nemzetközi együttműködést a kiberbiztonság területén.

A Common Criteria tehát egy válasz a piaci és nemzetközi együttműködési igényekre. Nem csupán egy technikai dokumentum, hanem egy bizalomépítő eszköz, amely lehetővé teszi a felhasználók számára, hogy megalapozott döntéseket hozzanak a biztonsági termékek kiválasztásakor. Emellett iránymutatást ad a fejlesztőknek is, segítve őket abban, hogy a biztonságot már a tervezési fázisban beépítsék termékeikbe, nem pedig utólag próbálják hozzáadni azt.

A Common Criteria történeti gyökerei és fejlődése

A Common Criteria nem a semmiből született meg, hanem évtizedes tapasztalatok és a különböző nemzeti szabványok evolúciójának eredménye. Az 1980-as évek elején, amikor a számítógépes rendszerek elterjedése felgyorsult, az Egyesült Államok Védelmi Minisztériuma felismerte a megbízható rendszerek iránti igényt. Ennek eredményeként adták ki 1983-ban a Trusted Computer System Evaluation Criteria (TCSEC) című dokumentumot, közismertebb nevén az „Orange Book”-ot a borítójának színe miatt. Ez volt az első átfogó keretrendszer a számítógépes rendszerek biztonsági értékelésére. A TCSEC hierarchikus értékelési szinteket (D, C1, C2, B1, B2, B3, A1) határozott meg, amelyek a biztonsági mechanizmusok komplexitását és az értékelés szigorúságát tükrözték.

Az 1990-es évek elején Európában is megjelentek hasonló kezdeményezések. Az Egyesült Királyság, Németország, Franciaország és Hollandia közösen fejlesztette ki az Information Technology Security Evaluation Criteria (ITSEC) szabványt. Az ITSEC eltért a TCSEC-től abban, hogy különválasztotta a funkcionális biztonsági követelményeket (mit tesz a termék) és a megbízhatósági követelményeket (hogyan készült a termék és mennyire bízhatunk benne). Ez a szétválasztás rugalmasabbá tette az értékelést, és lehetővé tette a különböző biztonsági profilok kialakítását. Kanadában eközben a Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) jött létre, amely szintén hasonló célokat szolgált.

Ahogy a globális kereskedelem és az információcsere egyre intenzívebbé vált, nyilvánvalóvá vált, hogy a nemzeti szabványok sokasága gátat szab a nemzetközi együttműködésnek és a termékek szabad áramlásának. Egy termék, amelyet az USA-ban az „Orange Book” szerint tanúsítottak, nem volt automatikusan elfogadott Európában az ITSEC alapján, és fordítva. Ez jelentős költségeket és időveszteséget jelentett a fejlesztők és a gyártók számára, akiknek minden piacra külön értékelési folyamaton kellett átesniük.

Ezen kihívásokra válaszul az Egyesült Államok, az Egyesült Királyság, Franciaország, Németország és Kanada 1993-ban kezdeményezte egy közös szabvány kidolgozását. A cél egy olyan egységes keretrendszer létrehozása volt, amely ötvözi a korábbi szabványok legjobb gyakorlatait, és nemzetközileg elfogadottá válik. Hosszú és intenzív tárgyalások, valamint számos konzultáció után 1996-ban adták ki a Common Criteria első verzióját. Ezt követően az ISO (Nemzetközi Szabványügyi Szervezet) és az IEC (Nemzetközi Elektrotechnikai Bizottság) 1999-ben hivatalosan is elfogadta az ISO/IEC 15408 szabványként, ezzel nemzetközi rangra emelve azt.

A Common Criteria létrejötte egy mérföldkövet jelentett az IT biztonsági iparágban. Nemcsak egy egységes értékelési módszertant biztosított, hanem lefektette a Common Criteria Recognition Arrangement (CCRA) alapjait is, amely a tanúsítványok kölcsönös elismerését célozza a résztvevő országok között. Ezáltal a CC hozzájárult a globális kiberbiztonsági ökoszisztéma érettségéhez és a bizalom növeléséhez a digitális termékek iránt.

A Common Criteria alapfogalmai és kulcskomponensei

A Common Criteria megértéséhez elengedhetetlen néhány kulcsfontosságú fogalom tisztázása, amelyek a szabvány magját képezik. Ezek a fogalmak alkotják azt a nyelvezetet és keretrendszert, amelyen keresztül az IT biztonsági termékek értékelése zajlik.

Target of Evaluation (TOE) – Az Értékelt Célpont

A Target of Evaluation (TOE) az a konkrét IT termék vagy rendszer, amelyet Common Criteria értékelés alá vetnek. Ez lehet egy szoftveres alkalmazás, egy hardvereszköz, egy operációs rendszer, egy hálózati komponens (pl. tűzfal, router), egy kriptográfiai modul, vagy akár egy komplett információs rendszer. Fontos, hogy a TOE pontosan definiált legyen, beleértve annak verzióját, konfigurációját és a működési környezetét is. Az értékelés csak a specifikusan megjelölt TOE-ra vonatkozik, nem pedig a gyártó teljes termékpalettájára.

Protection Profile (PP) – Védelmi Profil

A Protection Profile (PP) egy implementáció-független dokumentum, amely egy adott termékkategóriára (pl. operációs rendszerek, tűzfalak, intelligens kártyák) vonatkozó biztonsági követelményeket és fenyegetéseket írja le. A PP-t általában felhasználói vagy felhasználói csoportok írják, akiknek közös biztonsági igényeik vannak. A PP célja, hogy általános, de részletes specifikációt nyújtson arról, hogy egy adott kategóriájú terméknek milyen biztonsági funkciókkal kell rendelkeznie, és milyen fenyegetésekkel szemben kell ellenállnia. A PP-k elősegítik a termékek összehasonlíthatóságát és a piaci átláthatóságot, mivel a gyártók termékeiket egy vagy több releváns PP-hez igazíthatják.

• Alkalmazása: A PP-k iránymutatásul szolgálnak a fejlesztőknek és a beszerzőknek. A fejlesztők megérthetik, milyen biztonsági funkciókat vár el a piac, a beszerzők pedig olyan termékeket kereshetnek, amelyek megfelelnek egy adott PP-nek.
• Tartalma: Egy PP tartalmazza a biztonsági funkcionális követelményeket (SFRs) és a biztonsági megbízhatósági követelményeket (SARs), valamint a biztonsági célokat, fenyegetéseket, feltételezéseket és az IT környezet leírását.

Security Target (ST) – Biztonsági Cél

A Security Target (ST) egy TOE-specifikus dokumentum, amely részletesen leírja az értékelés alatt álló termék (TOE) biztonsági funkcióit és mechanizmusait, valamint a környezetet, amelyben az működni fog. Az ST lényegében a gyártó biztonsági állítása a termékéről. Azt mutatja be, hogy a TOE milyen biztonsági funkciókat valósít meg, és hogyan kezeli a specifikus fenyegetéseket. Az ST-nek vagy egy adott PP-hez kell illeszkednie (azaz a PP követelményeit teljesítenie kell), vagy önállóan kell definiálnia a biztonsági célokat és követelményeket. Az értékelés során a laboratórium az ST-ben leírtakhoz képest vizsgálja a TOE-t.

• Kapcsolat a PP-vel: Egy ST gyakran „PP-konform” vagy „PP-alapú”, ami azt jelenti, hogy a PP-ben meghatározott követelményeket teljesíti. Előfordulhat azonban, hogy egy ST egyedi követelményeket is tartalmaz, amelyek túlmutatnak egy adott PP-n.
• Részletesség: Az ST sokkal részletesebb, mint egy PP, mivel a konkrét TOE architektúráját, funkcióit és a fejlesztési folyamat részleteit is tartalmazza.

Evaluation Assurance Level (EAL) – Értékelési Megbízhatósági Szint

Az Evaluation Assurance Level (EAL) egy numerikus skála (EAL1-től EAL7-ig), amely az értékelés mélységét és szigorúságát jelzi. Fontos megérteni, hogy az EAL nem a termék biztonsági funkcióinak minőségét méri, hanem az értékelés szigorúságát és az ahhoz szükséges bizonyítékok mennyiségét és minőségét. Minél magasabb az EAL szint, annál alaposabb és átfogóbb az értékelési folyamat, és annál nagyobb a bizalom abban, hogy a termék valóban megfelel a specifikált biztonsági követelményeknek.

Az EAL szintek a következőképpen alakulnak:

• EAL1: Funkcionálisan tesztelt – A legalacsonyabb szint, amely alapvető funkcionális tesztelésen alapul. Kevés bizonyítékot igényel a fejlesztő részéről.
• EAL2: Szerkezetileg tesztelt – A fejlesztő dokumentációja alapján történő elemzés, valamint független tesztelés.
• EAL3: Módszeresen tesztelt és ellenőrzött – Részletesebb dokumentáció, fejlesztési környezet ellenőrzése, sebezhetőségi elemzés.
• EAL4: Módszeresen megtervezett, tesztelt és felülvizsgált – A legmagasabb szint, amelyet a legtöbb kereskedelmi termék elér. Átfogó tervezési dokumentációt, szigorúbb konfigurációkezelést és a fejlesztési folyamat független auditálását igényli.
• EAL5: Félig formálisan megtervezett és tesztelt – Erősebb garanciát nyújt a biztonsági követelmények teljesítésére, félig formális módszereket alkalmazva a tervezés és a tesztelés során.
• EAL6: Félig formálisan ellenőrzött tervezés és tesztelés – Magas biztonsági integritású környezetekhez, ahol a hibák elfogadhatatlanok. Kiterjedt elemzést és formális vagy félig formális módszereket igényel.
• EAL7: Formálisan ellenőrzött tervezés és tesztelés – A legmagasabb szint, rendkívül magas kockázatú környezetekhez. Teljesen formális tervezési és ellenőrzési módszereket alkalmaz, beleértve a matematikai bizonyításokat is. Ritkán alkalmazzák, csak a legkritikusabb rendszerek esetében.

Security Functional Requirements (SFRs) – Biztonsági Funkcionális Követelmények

Az SFRs írják le, hogy a TOE-nak milyen biztonsági funkciókat kell ellátnia. Ezek a követelmények a felhasználók vagy a rendszergazdák szemszögéből fogalmazzák meg a biztonsági viselkedést. A Common Criteria szabvány egy kiterjedt katalógust biztosít az SFR-ekről, amelyek modulárisan épülnek fel, és különböző kategóriákba sorolhatók. Példák az SFR-ekre:

• FIA (Identification and Authentication): Azonosítás és hitelesítés (pl. felhasználónevek és jelszavak kezelése, többfaktoros hitelesítés).
• FDP (User Data Protection): Felhasználói adatok védelme (pl. hozzáférés-vezérlés, adatintegritás, adatbizalmasság).
• FCS (Cryptographic Support): Kriptográfiai támogatás (pl. titkosítási algoritmusok, kulcskezelés).
• FAU (Security Audit): Biztonsági auditálás (pl. eseménynaplózás, naplók védelme).
• FPT (Protection of the TSF): A TSF (TOE Security Functions) védelme (pl. öntesztelés, biztonsági mechanizmusok integritása).

Az ST-ben ezeket az SFR-eket specifikusan a TOE-ra vonatkozóan kell megfogalmazni, kiegészítve az adott TOE egyedi funkcióival.

Security Assurance Requirements (SARs) – Biztonsági Megbízhatósági Követelmények

A SARs írják le, hogy milyen bizonyítékokat kell benyújtania a fejlesztőnek ahhoz, hogy igazolja a TOE biztonsági funkcióinak helyes működését és a fejlesztési folyamat integritását. Ezek a követelmények az értékelési folyamatra és a fejlesztési környezetre vonatkoznak. A SAR-ok biztosítják, hogy a termék nemcsak a deklarált funkciókat látja el, hanem megbízhatóan, biztonságos folyamatok során készült. A SAR-ok szintén kategóriákba sorolhatók, és közvetlenül kapcsolódnak az EAL szintekhez. Példák a SAR-okra:

• ADO (Development): Fejlesztés (pl. fejlesztési dokumentáció, forráskód elemzés).
• AVA (Vulnerability Analysis): Sebezhetőségi elemzés (pl. penetrációs tesztelés, kódellenőrzés).
• AGD (Guidance Documentation): Útmutató dokumentáció (pl. felhasználói és adminisztrátori kézikönyvek).
• ATE (Tests): Tesztek (pl. teszttervek, teszteredmények).
• ALC (Life-cycle Support): Életciklus-támogatás (pl. konfigurációkezelés, kézbesítési eljárások).

Az EAL szint emelkedésével a hozzá tartozó SAR-ok száma és szigorúsága is növekszik, ezzel biztosítva a mélyebb és átfogóbb értékelést.

A Common Criteria lényege abban rejlik, hogy egy strukturált és ellenőrizhető módszertant biztosít az IT biztonsági termékek független értékelésére, lehetővé téve a nemzetközi bizalom építését és a kiberbiztonsági kockázatok minimalizálását.

A Common Criteria értékelési folyamata: lépések és szereplők

A Common Criteria tanúsítási folyamat egy szigorúan szabályozott eljárás, amely több fázisból és számos szereplő összehangolt munkájából áll. Célja, hogy objektív és megbízható eredményt nyújtson a TOE biztonsági jellemzőiről. A folyamat általában a következő főbb lépésekre osztható:

1. Előkészítés és Tervezés

Ez a fázis a tanúsítási folyamat alapjait fekteti le. A termék fejlesztője vagy szponzora (aki a tanúsítást kezdeményezi) dönt arról, hogy melyik termékét (TOE) kívánja értékelni, és milyen biztonsági követelményeknek kell megfelelnie. Ennek keretében elkészíti vagy frissíti a Security Target (ST) dokumentumot. Az ST-nek pontosan meg kell határoznia a TOE biztonsági funkcióit, a fenyegetéseket, amelyekkel szemben védelmet nyújt, a feltételezéseket a működési környezetre vonatkozóan, és az elérni kívánt EAL szintet. Gyakran egy vagy több Protection Profile (PP)-hoz igazodva készül el az ST.

Ezen a ponton a szponzor kiválaszt egy akkreditált Common Criteria értékelő laboratóriumot. A laboratórium feladata, hogy függetlenül és objektíven vizsgálja a TOE-t az ST-ben leírtak alapján. A laboratórium és a szponzor közötti megállapodás rögzíti az értékelés terjedelmét, a határidőket és a költségeket. Ezt követően a laboratórium elkészíti az értékelési tervet, amely részletezi a vizsgálati módszereket, a szükséges erőforrásokat és a dokumentáció áttekintésének ütemezését.

2. Értékelés és Vizsgálat

Ez a fázis az értékelési folyamat érdemi része. Az értékelő laboratórium szakértői alaposan átvizsgálják a TOE-t és a hozzá tartozó dokumentációt. A vizsgálat a Security Assurance Requirements (SARs) és a Security Functional Requirements (SFRs) alapján történik, az ST-ben rögzített EAL szintnek megfelelően. A tipikus tevékenységek a következők:

• Dokumentáció elemzése: A fejlesztési dokumentáció (tervrajzok, specifikációk, kódolási szabványok, tesztelési tervek és eredmények, felhasználói és adminisztrátori útmutatók) átfogó elemzése. A laboratórium ellenőrzi a dokumentáció teljességét, pontosságát és konzisztenciáját.
• Architektúra és tervezés felülvizsgálata: A TOE belső felépítésének, biztonsági architektúrájának és tervezési döntéseinek mélyreható vizsgálata annak megállapítására, hogy azok alkalmasak-e a deklarált biztonsági célok elérésére.
• Forráskód elemzése: Magasabb EAL szinteken a forráskód részletes elemzésére is sor kerülhet, manuálisan és automatizált eszközökkel egyaránt, a potenciális sebezhetőségek és a biztonsági funkciók helyes implementációjának ellenőrzésére.
• Független tesztelés: A laboratórium saját teszteket végez a TOE-n. Ez magában foglalhatja a funkcionális teszteket a deklarált biztonsági funkciók ellenőrzésére, regressziós teszteket, teljesítményteszteket, és ami a legfontosabb, sebezhetőségi teszteket (pl. penetrációs tesztelés, fuzzing, kódellenőrzés) a potenciális gyenge pontok azonosítására.
• Fejlesztési környezet auditálása: Magasabb EAL szinteken a laboratórium felméri a fejlesztő biztonságos fejlesztési gyakorlatait, konfigurációkezelési eljárásait, minőségbiztosítási folyamatait és a fizikai biztonságot is.

Az értékelés során a laboratórium folyamatosan kommunikál a fejlesztővel, kérdéseket tesz fel, és tisztázza a felmerülő problémákat. Amennyiben hiányosságokat vagy sebezhetőségeket találnak, a fejlesztőnek lehetősége van ezeket kijavítani. A laboratórium dokumentálja az összes vizsgálati eredményt és a talált eltéréseket.

3. Tanúsítás és Jelentéskészítés

Miután az értékelő laboratórium befejezte a vizsgálatot és megállapította, hogy a TOE megfelel az ST-ben leírt követelményeknek az adott EAL szinten, elkészíti az Értékelési Jelentést (Evaluation Report). Ez a jelentés részletezi a vizsgálati folyamatot, a talált eredményeket, a kijavított hibákat, és tartalmazza a laboratórium ajánlását a tanúsító hatóság felé.

Az Értékelési Jelentést ezután a Tanúsító Hatóság (Certification Body) felé továbbítják. A Tanúsító Hatóság egy független állami szerv (pl. az Egyesült Államokban a NIST, Németországban a BSI, az Egyesült Királyságban a NCSC), amely felülvizsgálja a laboratórium jelentését, és ellenőrzi az értékelési folyamat megfelelőségét. Ők a végső döntéshozók a tanúsítás odaítélésében. Ha a Tanúsító Hatóság is mindent rendben talál, kiadja a Common Criteria Tanúsítványt a TOE-ra vonatkozóan. Ez a tanúsítvány hivatalosan is igazolja, hogy a TOE sikeresen átesett az értékelésen, és megfelel a deklarált biztonsági követelményeknek az adott EAL szinten.

A tanúsítványt általában közzéteszik a Tanúsító Hatóság weboldalán, valamint a Common Criteria Portalon, ezzel biztosítva az átláthatóságot és a nyilvános hozzáférést a tanúsított termékek listájához.

A főbb szereplők összefoglalása:

1. Szponzor/Fejlesztő: Az a vállalat vagy szervezet, amely a terméket fejleszti és tanúsíttatni kívánja. Felelős az ST elkészítéséért és a szükséges dokumentáció, valamint a TOE biztosításáért.
2. Értékelő Laboratórium (Evaluation Laboratory): Akkreditált, független szervezet, amely elvégzi a tényleges értékelést a CC szabvány és az ST alapján. Szakértői a biztonsági elemzésekben és tesztelésben.
3. Tanúsító Hatóság (Certification Body): Független állami szerv, amely felügyeli az értékelő laboratóriumok munkáját, felülvizsgálja az értékelési jelentéseket, és kiadja a Common Criteria tanúsítványokat. Ők biztosítják a folyamat integritását és a tanúsítványok hitelességét.

Ez a többlépcsős, független ellenőrzési rendszer biztosítja, hogy a Common Criteria tanúsítványok magas szintű megbízhatósággal rendelkezzenek, és széles körben elfogadottak legyenek a globális piacon.

Protection Profile (PP) részletesen: A piaci igények szabványa

A Protection Profile (PP) a Common Criteria egyik legfontosabb alapköve, amely hidat képez a felhasználói igények és a technikai specifikációk között. Ahogy korábban említettük, ez egy implementáció-független dokumentum, amely egy adott IT-termékkategóriára vonatkozó biztonsági követelményeket és fenyegetéseket írja le. De miért olyan fontosak a PP-k, és hogyan épülnek fel részletesen?

A PP célja és jelentősége

A PP alapvető célja, hogy egységes és összehasonlítható módon definiálja a biztonsági igényeket egy meghatározott termékkör számára. Ez több szempontból is kritikus:

• Piaci átláthatóság: A PP-k lehetővé teszik a beszerzők számára, hogy pontosan megértsék, milyen biztonsági funkciókat várhatnak el egy adott típusú terméktől. Ez megkönnyíti a termékek összehasonlítását és a megalapozott beszerzési döntések meghozatalát.
• Fejlesztői iránymutatás: A gyártók számára a PP-k egyértelmű iránymutatást nyújtanak arról, hogy milyen biztonsági funkciókat kell beépíteniük termékeikbe ahhoz, hogy azok megfeleljenek a piaci elvárásoknak és a CC tanúsítás követelményeinek. Ez segít a tervezési fázisban a biztonság beépítésében (security by design).
• Értékelési hatékonyság: Ha több termék ugyanarra a PP-re hivatkozik, az értékelő laboratóriumoknak már van egy előre definiált alapjuk, ami felgyorsíthatja és standardizálhatja az értékelési folyamatot.
• Kölcsönös elismerés támogatása: A Common Criteria Recognition Arrangement (CCRA) keretében a PP-k kulcsszerepet játszanak a tanúsítványok kölcsönös elfogadásában. Ha két ország ugyanazon PP alapján tanúsít egy terméket, a tanúsítványok könnyebben elismerhetők egymás között.

A PP felépítése és tartalma

Egy tipikus Protection Profile a következő főbb fejezeteket tartalmazza:

1. Bevezetés:
   • A PP azonosítása és verziószáma.
   • A PP célja és hatóköre.
   • A dokumentum felépítése.
2. TOE leírása:
   • A TOE kategóriájának általános leírása (pl. „Általános célú operációs rendszer”).
   • A TOE biztonsági funkcióinak általános áttekintése.
   • A TOE környezeti feltételezései (pl. milyen hálózaton, milyen felhasználókkal működik).
3. Biztonsági környezet definíciója:
   • Fenyegetések (Threats): Részletes leírása azoknak a biztonsági fenyegetéseknek, amelyekkel a TOE-nak szembe kell néznie (pl. jogosulatlan hozzáférés, adatszivárgás, szolgáltatásmegtagadás). Minden fenyegetéshez pontosan meg kell határozni a támadó motivációját, képességeit és a támadás lehetséges következményeit.
   • Szervezeti biztonsági politikák (Organizational Security Policies – OSPs): Azok a szabályok és előírások, amelyeket a TOE-nak be kell tartania a működési környezetében (pl. adatok titkosítása, naplózási követelmények).
   • Feltételezések (Assumptions): Azok a feltételezések, amelyek a TOE környezetére vonatkoznak, és amelyek szükségesek a TOE biztonságos működéséhez (pl. megbízható rendszergazdák, fizikai biztonság).
4. Biztonsági célok (Security Objectives):
   • TOE biztonsági céljai: A TOE-nak elérendő biztonsági célok a fenyegetések, OSP-k és feltételezések figyelembevételével (pl. „A TOE-nak meg kell akadályoznia a jogosulatlan hozzáférést a felhasználói adatokhoz”).
   • Környezeti biztonsági célok: Azok a biztonsági célok, amelyeket a TOE működési környezetének kell biztosítania, és amelyek kívül esnek a TOE hatókörén (pl. „A felhasználókat megfelelően kell kiképezni a biztonsági szabályok betartására”).
5. Biztonsági követelmények (Security Requirements):
   • Biztonsági Funkcionális Követelmények (SFRs): A Common Criteria szabványban található modulokból kiválasztott és specifikusan a PP-hez igazított funkcionális követelmények (pl. FIA_UAU.1 – Felhasználói azonosítás és hitelesítés).
   • Biztonsági Megbízhatósági Követelmények (SARs): Azok a megbízhatósági követelmények, amelyek a fejlesztési és értékelési folyamatra vonatkoznak, általában egy EAL szinthez rendelve. Ezek határozzák meg, hogy milyen bizonyítékokra van szükség a funkciók megbízhatóságának igazolásához.
6. Követelmény-összefüggések: A PP-n belüli különböző elemek (fenyegetések, célok, követelmények) közötti kapcsolatok leírása, biztosítva a koherenciát és teljességet.
7. Racionálék: Magyarázatok és indoklások a PP-ben hozott döntésekhez, segítenek a megértésben.

Példák Protection Profile-okra

Számos, széles körben elfogadott PP létezik, amelyek különböző termékkategóriákra vonatkoznak:

• OSPP (Operating System Protection Profile): Operációs rendszerekre vonatkozó általános biztonsági követelmények.
• FPP (Firewall Protection Profile): Tűzfalak biztonsági funkciói és megbízhatósági elvárásai.
• iC PP (Integrated Circuit Protection Profile): Intelligens kártyák és beágyazott chipek biztonsági követelményei.
• HSM PP (Hardware Security Module Protection Profile): Hardveres biztonsági modulok (HSM) biztonsági elvárásai, amelyek kriptográfiai kulcsokat és műveleteket védenek.
• MDM PP (Mobile Device Management Protection Profile): Mobil eszközkezelő rendszerek biztonsági követelményei.

A PP fejlesztésének kihívásai

Egy PP létrehozása komplex feladat, amely szakértelmet és konszenzust igényel. A kihívások közé tartozik:

• Általánosítás és specifikusság egyensúlya: Elég általánosnak kell lennie ahhoz, hogy több termékre is alkalmazható legyen, de elég specifikusnak ahhoz, hogy releváns biztonsági garanciákat nyújtson.
• Fenyegetésmodellezés: A fenyegetések pontos és átfogó azonosítása kulcsfontosságú, ami folyamatosan változó kiberbiztonsági környezetben nehéz lehet.
• Technológiai fejlődés: A PP-knek lépést kell tartaniuk a gyorsan fejlődő technológiákkal és a változó támadási felületekkel. Ez folyamatos frissítéseket tesz szükségessé.
• Nemzetközi konszenzus: Mivel a PP-k célja a nemzetközi elfogadás, a különböző országok és érdekelt felek igényeinek összehangolása jelentős kihívást jelent.

Összességében a Protection Profile-ok a Common Criteria ökoszisztéma motorjai. Lehetővé teszik a standardizációt, a piaci átláthatóságot és a hatékonyabb biztonsági értékeléseket, miközben biztosítják, hogy a fejlesztők és a felhasználók közös nyelvet beszéljenek a biztonsági követelményekről.

Security Target (ST) részletesen: A termék biztonsági állítása

A Security Target (ST) a Common Criteria értékelési folyamatának központi dokumentuma, amely a konkrét értékelés alatt álló termékre (TOE) fókuszál. Míg a Protection Profile (PP) egy termékkategória általános biztonsági követelményeit írja le, addig az ST a gyártó specifikus nyilatkozata arról, hogy az ő terméke milyen biztonsági funkciókat valósít meg, milyen környezetben működik, és milyen fenyegetésekkel szemben nyújt védelmet. Ez a dokumentum az értékelés alapja, és az értékelő laboratórium ehhez méri a TOE-t.

Az ST célja és felépítése

Az ST elsődleges célja, hogy pontosan és egyértelműen meghatározza a TOE biztonsági jellemzőit az értékelési folyamat számára. Ez egy szerződés a gyártó és az értékelő között, amely rögzíti, mi kerül értékelésre. Az ST részletessége és pontossága alapvető fontosságú, mivel minden teszt és ellenőrzés az ebben a dokumentumban foglaltakra épül. Egy tipikus Security Target a következő főbb szakaszokból áll:

1. ST azonosítása:
   • Az ST neve, verziószáma és dátuma.
   • A TOE pontos azonosítása (terméknév, verziószám, gyártó, konfiguráció).
   • A hivatkozott PP-k listája, ha van ilyen.
   • Az EAL szint, amelyet a TOE-nak el kell érnie.
2. TOE leírása:
   • A TOE funkcionális leírása: Mit csinál a termék? Milyen szolgáltatásokat nyújt?
   • A TOE fizikai és logikai határai.
   • A TOE biztonsági funkcióinak (TSF) magas szintű áttekintése.
   • A TOE környezete: Milyen hardveren, szoftveren és hálózaton fog működni? Kik a felhasználók és a rendszergazdák?
3. Biztonsági környezet definíciója:
   • Fenyegetések (Threats): A specifikus fenyegetések, amelyekkel a TOE-nak szembe kell néznie a deklarált környezetben. Ezek gyakran a hivatkozott PP-kből származnak, de kiegészíthetők a TOE egyedi jellemzőihez igazodva.
   • Szervezeti biztonsági politikák (OSPs): Azok a biztonsági szabályok, amelyeket a TOE-nak be kell tartania.
   • Feltételezések (Assumptions): A TOE biztonságos működéséhez szükséges környezeti feltételezések.

   Ezek a részek biztosítják, hogy az értékelés a valós kockázatokra és működési körülményekre fókuszáljon.

4. Biztonsági célok (Security Objectives):
   • TOE biztonsági céljai: Konkrét célkitűzések, amelyeket a TOE-nak el kell érnie a fenyegetések elhárítása és az OSP-k betartása érdekében. Ezek a célok közvetlenül a TOE funkcionális képességeihez kapcsolódnak.
   • Környezeti biztonsági célok: Azok a célok, amelyeket a TOE működési környezetének kell biztosítania a TOE biztonságának támogatásához (pl. a rendszergazdák képzése, fizikai biztonság).
5. Biztonsági követelmények (Security Requirements):
   • TOE biztonsági funkcionális követelmények (SFRs): A Common Criteria által definiált SFR-ek kiválasztott halmaza, amelyeket a TOE-nak meg kell valósítania. Ezeket a követelményeket részletesen specifikálni kell a TOE-ra vonatkozóan, beleértve az SFR komponensek konkrét beállításait és paramétereit (pl. egy titkosítási algoritmus erőssége, egy jelszó minimális hossza).
   • TOE biztonsági megbízhatósági követelmények (SARs): Azok a megbízhatósági követelmények, amelyek az ST-ben deklarált EAL szintnek felelnek meg. Ezek írják le, hogy milyen bizonyítékokat (dokumentáció, tesztek, elemzések) kell benyújtania a gyártónak a TOE biztonságának igazolására.
6. TOE biztonsági funkciók (TSF) specifikációja:

   Ez a rész részletesen leírja, hogy a TOE hogyan valósítja meg a deklarált SFR-eket. Magában foglalja a TOE architektúrájának és belső mechanizmusainak leírását, amelyek a biztonsági funkciókat biztosítják. Ez a rész kulcsfontosságú az értékelő laboratórium számára, mivel ebből érti meg, hogyan működik a TOE, és hogyan ellenőrizheti a biztonsági állításokat.

7. Követelmény-összefüggések és Racionálék:

   Ez a szakasz biztosítja a koherenciát az ST különböző elemei között (pl. miért felel meg egy adott SFR egy bizonyos fenyegetésnek), és racionálékat ad a választott követelményekhez.

Az ST és a PP kapcsolata

Az ST gyakran „PP-alapú” vagy „PP-konform”. Ez azt jelenti, hogy az ST a hivatkozott PP-ben meghatározott összes biztonsági követelményt teljesíti. Azonban az ST lehetőséget ad arra, hogy kiegészítő, TOE-specifikus követelményeket is tartalmazzon, amelyek túlmutatnak a PP-n. Például, ha egy tűzfalra vonatkozó PP-hez képest a gyártó tűzfala speciális mesterséges intelligencia alapú fenyegetésészlelési funkcióval is rendelkezik, akkor az ST-ben ezt a további képességet is deklarálni kell, és az értékelés során azt is vizsgálni fogják.

Az ST elkészítése a gyártó felelőssége, és ez a dokumentum adja meg az értékelés kereteit. A minőségi ST elengedhetetlen a sikeres és hatékony értékelési folyamathoz. Egy rosszul megírt vagy hiányos ST jelentősen lelassíthatja az értékelést, és extra költségeket generálhat.

Az ST fejlesztésének komplexitása

Az ST megírása és karbantartása jelentős erőforrásokat igényel a gyártótól. Nem csupán technikai leírást jelent, hanem egy jogi dokumentumot is, amelyhez a gyártó köti magát. A komplexitást növeli:

• Részletesség: Az ST-nek rendkívül részletesnek kell lennie, minden apró biztonsági funkciót és mechanizmust leírva.
• Pontosság: Minden állításnak pontosnak és ellenőrizhetőnek kell lennie. Kétértelműségek vagy ellentmondások az értékelés során problémát okozhatnak.
• Konzisztencia: Az ST-n belüli összes elemnek (fenyegetések, célok, funkcionális és megbízhatósági követelmények) konzisztensnek kell lennie egymással.
• Szabványismeret: A Common Criteria szabvány mélyreható ismerete szükséges az SFR-ek és SAR-ok helyes alkalmazásához.

Az ST tehát nem csak egy leírás, hanem egy stratégiai dokumentum is, amely bemutatja, hogy a gyártó mennyire érti a terméke biztonsági aspektusait, és mennyire elkötelezett a biztonságos fejlesztési gyakorlatok iránt. Az értékelő laboratórium számára ez a dokumentum a térkép, amely alapján navigál a TOE biztonsági képességeinek labirintusában.

Evaluation Assurance Levels (EAL) részletesen: Az értékelés mélysége

Az Evaluation Assurance Level (EAL) a Common Criteria egyik leggyakrabban emlegetett, de talán leggyakrabban félreértett aspektusa. Ahogy korábban is hangsúlyoztuk, az EAL nem a termék biztonsági képességeinek minőségét, hanem az értékelés mélységét és szigorúságát jelzi. Egy magasabb EAL szint azt jelenti, hogy az értékelési folyamat alaposabb volt, több bizonyítékot vizsgáltak meg, és nagyobb bizalommal fogadhatjuk el, hogy a termék valóban megfelel a deklarált biztonsági állításoknak.

Az EAL szintek hierarchiája és jelentése

A Common Criteria hét EAL szintet definiál, EAL1-től EAL7-ig, növekvő szigorúsági sorrendben. Minden szint a Common Criteria által definiált Security Assurance Requirements (SARs) egy előre meghatározott halmazát foglalja magában, amelyek a fejlesztési folyamatra, a dokumentációra, a tesztelésre és az elemzésre vonatkoznak.

EAL1: Funkcionálisan Tesztelt (Functionally Tested)

• Fókusz: A termék alapvető funkcionális tesztelése és a nyilvánosan hozzáférhető útmutatók áttekintése.
• Igény: Minimális bizonyítékot igényel a fejlesztőtől.
• Alkalmazás: Alacsony kockázatú környezetekben, ahol a biztonsági fenyegetések korlátozottak, és a termék már korábban is bizonyított. Például egy egyszerű irodai alkalmazás.
• Jelentése: Biztosítja, hogy a termék alapvető biztonsági funkciói működnek, és a dokumentáció érthető.

EAL2: Szerkezetileg Tesztelt (Structurally Tested)

• Fókusz: A fejlesztő részletesebb dokumentációjának áttekintése, valamint a TOE architektúrájának és tervezésének ellenőrzése. Független tesztelés.
• Igény: A fejlesztési folyamat bizonyos mértékű átláthatósága.
• Alkalmazás: Kevésbé kritikus rendszerek, ahol a biztonsági kockázatok mérsékeltek. Például egy kereskedelmi operációs rendszer vagy egy hálózati eszköz.
• Jelentése: Ad némi bizalmat abban, hogy a termék a tervezés szerint működik, és a fejlesztési folyamat is ellenőrzött.

EAL3: Módszeresen Tesztelt és Ellenőrzött (Methodically Tested and Checked)

• Fókusz: Részletesebb elemzés a tervezési dokumentációról, a konfigurációkezelésről és a sebezhetőségi elemzésről.
• Igény: Szigorúbb fejlesztési és tesztelési gyakorlatok.
• Alkalmazás: Általános kereskedelmi termékek, amelyeknél a bizalom fontosabb, de a költségek és az időkorlátok még mindig szempontok. Például egy közepes méretű vállalat tűzfala.
• Jelentése: Erősebb garanciát nyújt a termék integritására és működésére.

EAL4: Módszeresen Megtervezett, Tesztelt és Felülvizsgált (Methodically Designed, Tested and Reviewed)

• Fókusz: A legmagasabb EAL szint, amelyet a legtöbb kereskedelmi termék elér. Átfogó tervezési dokumentáció, szigorú konfigurációkezelés, a fejlesztési folyamat független auditálása, és kiterjedt sebezhetőségi elemzés.
• Igény: Jól definiált és dokumentált fejlesztési életciklus.
• Alkalmazás: Magasabb kockázatú környezetek, ahol a biztonság kritikus fontosságú, és a termékek széles körben elterjedtek. Például operációs rendszerek, hálózati infrastruktúra elemek, chipkártya operációs rendszerek.
• Jelentése: Jelentős bizalmat ad a termék biztonsági képességeiben és a fejlesztési folyamat integritásában. Gyakran ez a minimum követelmény a kormányzati és kritikus infrastruktúra beszerzéseknél.

EAL5: Félig Formálisan Megtervezett és Tesztelt (Semi-formally Designed and Tested)

• Fókusz: Félig formális módszerek alkalmazása a tervezés és a tesztelés során. Több bizonyítékot igényel a fejlesztő részéről a biztonsági mechanizmusok helyes működéséről.
• Igény: Magas szintű mérnöki pontosság és a biztonsági funkciók részletes elemzése.
• Alkalmazás: Magas biztonsági integritású környezetek, ahol a hibák elfogadhatatlanok. Például szigorúan ellenőrzött hozzáférés-vezérlő rendszerek, kriptográfiai modulok.
• Jelentése: Nagyon erős garanciát nyújt arra, hogy a termék megfelel a biztonsági követelményeknek.

EAL6: Félig Formálisan Ellenőrzött Tervezés és Tesztelés (Semi-formally Verified Design and Tested)

• Fókusz: Kiterjedt elemzés és formális vagy félig formális módszerek alkalmazása a tervezési és implementációs fázisokban. A sebezhetőségi elemzés rendkívül alapos.
• Igény: Nagyon szigorú fejlesztési és minőségbiztosítási folyamatok.
• Alkalmazás: Rendkívül magas kockázatú környezetek, ahol a hibák következményei katasztrofálisak lehetnek. Például katonai rendszerek, atomenergia-ipari vezérlőrendszerek.
• Jelentése: Kiemelkedően magas bizalmat ad a termék biztonságában.

EAL7: Formálisan Ellenőrzött Tervezés és Tesztelés (Formally Verified Design and Tested)

• Fókusz: A legmagasabb szint, amely teljes mértékben formális tervezési és ellenőrzési módszereket alkalmaz, beleértve a matematikai bizonyításokat is a biztonsági tulajdonságokról.
• Igény: Rendkívül speciális szaktudás és jelentős erőforrások.
• Alkalmazás: A legkritikusabb, legérzékenyebb rendszerek, ahol a biztonsági hibák a legkisebb esélye is elfogadhatatlan. Ritkán alkalmazzák, például bizonyos kriptográfiai algoritmusok hardveres implementációjánál.
• Jelentése: Maximális bizalmat nyújt, de rendkívül költséges és időigényes.

Az EAL kiválasztásának szempontjai

Az EAL szint kiválasztása kritikus döntés a tanúsítási folyamat elején. Nem mindig a legmagasabb EAL szint a legjobb választás. A döntést a következő tényezők befolyásolják:

• Kockázatkezelés: Milyen magas a kockázat a TOE használatával kapcsolatban? Milyen súlyosak lehetnek a biztonsági incidensek következményei?
• Költség és idő: A magasabb EAL szintek jelentősen növelik az értékelés költségeit és időtartamát.
• Piaci elvárások: Milyen EAL szintet vár el a célpiac vagy a szabályozó hatóság?
• Fejlesztői képességek: A fejlesztő rendelkezik-e a szükséges folyamatokkal, dokumentációval és szaktudással a magasabb EAL szintekhez szükséges bizonyítékok előállításához?

Egy EAL4 tanúsítvány például széles körben elfogadott és elegendő a legtöbb kereskedelmi és kormányzati alkalmazáshoz. A magasabb EAL5, EAL6 és EAL7 szintek csak speciális, rendkívül érzékeny környezetekben indokoltak, ahol a biztonsági integritás a legfőbb prioritás.

Az EAL tehát egy fontos mutatója az értékelés alaposságának, de sosem szabad önmagában értelmezni. Mindig a TOE funkcionális képességeivel, a Security Target-ben deklarált biztonsági célokkal és a működési környezet kockázataival együtt kell vizsgálni.

Security Functional Requirements (SFRs) és Security Assurance Requirements (SARs) részletesen

A Common Criteria szabvány két alapvető típust különböztet meg a biztonsági követelmények között: a funkcionális követelményeket (SFRs) és a megbízhatósági követelményeket (SARs). Ezek együtt biztosítják, hogy egy IT termék ne csak azt tegye, amit állít magáról, hanem azt megbízhatóan és ellenőrizhető módon tegye.

Security Functional Requirements (SFRs) – Biztonsági Funkcionális Követelmények

Az SFR-ek leírják, hogy a Target of Evaluation (TOE) milyen biztonsági funkciókat kell, hogy biztosítson. Ezek a követelmények a felhasználó vagy a rendszergazda szemszögéből fogalmazzák meg a TOE elvárt biztonsági viselkedését. A Common Criteria egy moduláris felépítésű, kiterjedt SFR katalógust biztosít, amely lehetővé teszi a specifikus igényekhez való rugalmas alkalmazkodást. Minden SFR egy osztályból, családból és komponensből áll, ami hierarchikus és strukturált megközelítést tesz lehetővé.

SFR kategóriák és példák:

A Common Criteria számos SFR osztályt definiál, mindegyik egy specifikus biztonsági területre fókuszál. Néhány főbb kategória:

1. FCS (Cryptographic Support) – Kriptográfiai Támogatás:
   • FCS_CKM (Cryptographic Key Management): Kulcskezelés (pl. kulcsgenerálás, kulcselosztás, kulcsarchiválás, kulcsmegsemmisítés).
     • Példa: FCS_CKM.1 – Kriptográfiai kulcsgenerálás: „A TOE-nak képesnek kell lennie 256 bites AES kulcsok generálására.”
   • FCS_COP (Cryptographic Operations): Kriptográfiai műveletek (pl. titkosítás, digitális aláírás, hash funkciók).
     • Példa: FCS_COP.1 – Kriptográfiai műveletek: „A TOE-nak támogatnia kell az AES-256 CBC titkosítási algoritmust.”
2. FIA (Identification and Authentication) – Azonosítás és Hitelesítés:
   • FIA_UAU (User Authentication): Felhasználói hitelesítés (pl. jelszó, biometria, tanúsítványok).
     • Példa: FIA_UAU.1 – Sikeres hitelesítés: „A TOE-nak meg kell követelnie a felhasználók hitelesítését, mielőtt hozzáférhetnek a védett erőforrásokhoz.”
   • FIA_UID (User Identification): Felhasználói azonosítás.
     • Példa: FIA_UID.1 – Azonosítás kezdeményezése: „A TOE-nak azonosítania kell minden felhasználót, mielőtt engedélyezi a hozzáférést.”
3. FDP (User Data Protection) – Felhasználói Adatvédelem:
   • FDP_ACC (Access Control): Hozzáférés-vezérlés (pl. diszkrecionális, kötelező hozzáférés-vezérlés).
     • Példa: FDP_ACC.1 – Hozzáférés-vezérlési politika: „A TOE-nak végre kell hajtania egy szerepalapú hozzáférés-vezérlési politikát a fájlokhoz való hozzáférésre vonatkozóan.”
   • FDP_IFC (Information Flow Control): Információáramlás-vezérlés.
   • FDP_ITC (Import of User Data): Felhasználói adatok importálása.
4. FAU (Security Audit) – Biztonsági Auditálás:
   • FAU_GEN (Security Audit Data Generation): Audit adatok generálása (pl. naplózandó események).
     • Példa: FAU_GEN.1 – Audit események generálása: „A TOE-nak naplóznia kell az összes sikertelen bejelentkezési kísérletet.”
   • FAU_SAR (Security Audit Review): Audit adatok áttekintése.
5. FPT (Protection of the TSF) – A TSF Védelme:
   • FPT_STM (TOE Security Functions Time Stamps): Időbélyegzők.
   • FPT_TST (TSF Self Test): TSF önteszt (pl. indításkori vagy periodikus tesztek).
     • Példa: FPT_TST.1 – TSF önteszt: „A TOE-nak minden indításkor automatikusan tesztelnie kell a kriptográfiai moduljait.”

Az ST-ben a gyártónak minden kiválasztott SFR-t részletesen specifikálnia kell a TOE-ra vonatkozóan. Ez gyakran magában foglalja az SFR komponensek finomítását (pl. konkrét algoritmusok, paraméterek megadása) és a TOE egyedi viselkedésének leírását.

Security Assurance Requirements (SARs) – Biztonsági Megbízhatósági Követelmények

A SAR-ok leírják, hogy milyen bizonyítékokat kell benyújtania a fejlesztőnek ahhoz, hogy igazolja a TOE biztonsági funkcióinak helyes működését és a fejlesztési folyamat integritását. Ezek a követelmények az értékelési folyamatra és a fejlesztési környezetre vonatkoznak. A SAR-ok közvetlenül kapcsolódnak az EAL szintekhez; minden EAL szint egy előre meghatározott SAR halmazt tartalmaz.

SAR kategóriák és példák:

A Common Criteria SAR osztályai a fejlesztési életciklus különböző aspektusait fedik le:

1. ADO (Development) – Fejlesztés:
   • ADO_DEL (Delivery Procedures): Kézbesítési eljárások (pl. a termék biztonságos szállítása).
   • ADO_IGS (Integrity of TOE Security Functions): A TOE biztonsági funkcióinak integritása.
2. AVA (Vulnerability Analysis) – Sebezhetőségi Elemzés:
   • AVA_VAN (Vulnerability Analysis): Sebezhetőségi elemzés (pl. penetrációs tesztelés, statikus és dinamikus kódanalízis).
     • Példa: AVA_VAN.3 – Független sebezhetőségi elemzés: „Az értékelőnek részletes sebezhetőségi elemzést kell végeznie a TOE-n, beleértve a penetrációs tesztelést.” (EAL3-tól magasabb szinteken)
3. AGD (Guidance Documentation) – Útmutató Dokumentáció:
   • AGD_ADM (Administrator Guidance): Rendszergazdai útmutató.
     • Példa: AGD_ADM.1 – Rendszergazdai útmutató: „A TOE-hoz egy részletes rendszergazdai kézikönyvet kell mellékelni, amely leírja a biztonságos konfigurálást és kezelést.”
   • AGD_USR (User Guidance): Felhasználói útmutató.
4. ATE (Tests) – Tesztek:
   • ATE_DPT (Depth of Testing): Tesztelés mélysége.
   • ATE_FUN (Functional Testing): Funkcionális tesztelés.
     • Példa: ATE_FUN.1 – Funkcionális tesztelés: „A fejlesztőnek tesztelnie kell a TOE összes deklarált biztonsági funkcióját.”
5. ALC (Life-cycle Support) – Életciklus-támogatás:
   • ALC_CMC (Configuration Management Capabilities): Konfigurációkezelési képességek.
     • Példa: ALC_CMC.1 – Konfigurációkezelés: „A fejlesztőnek szigorú konfigurációkezelési rendszert kell alkalmaznia a TOE összes összetevőjére.”
   • ALC_DEL (Delivery Procedures): Kézbesítési eljárások.

Az EAL szint emelkedésével a hozzá tartozó SAR-ok száma és szigorúsága is növekszik. Például, míg EAL1-nél csak az alapvető dokumentáció és funkcionális tesztelés szükséges, addig EAL7-nél már formális tervezési módszerek, matematikai bizonyítások és rendkívül mélyreható sebezhetőségi elemzések is elengedhetetlenek.

Az SFR-ek és SAR-ok kapcsolata a PP-vel és az ST-vel

A PP-k és az ST-k az SFR-eket és SAR-okat használják a biztonsági követelmények definiálására. A PP egy adott termékkategóriára vonatkozó SFR és SAR halmazt határoz meg, gyakran egy alap EAL szinttel együtt. Az ST ezután vagy hivatkozik egy PP-re, és átveszi annak SFR és SAR követelményeit, vagy önállóan definiálja azokat. Az ST-ben az SFR-eket specifikusan a TOE-ra kell szabni, míg a SAR-ok a választott EAL szintnek megfelelően kerülnek kiválasztásra és alkalmazásra.

Ez a moduláris és strukturált megközelítés teszi lehetővé a Common Criteria rugalmasságát és alkalmazkodóképességét a különböző IT biztonsági termékek és rendszerek értékeléséhez.

A Common Criteria előnyei és hátrányai

Mint minden komplex szabvány, a Common Criteria is rendelkezik számos előnnyel, amelyek indokolják széles körű alkalmazását, de vannak hátrányai és korlátai is, amelyeket figyelembe kell venni.

A Common Criteria előnyei

1. Nemzetközi Elismertség és Kölcsönös Elfogadás (CCRA):

   A Common Criteria egyik legnagyobb előnye a nemzetközi elfogadottsága. A Common Criteria Recognition Arrangement (CCRA) keretében a résztvevő országok (jelenleg 31 ország) elismerik egymás Common Criteria tanúsítványait. Ez azt jelenti, hogy egy termék, amelyet az egyik tagországban tanúsítottak, elfogadottnak tekinthető a többi tagországban is, csökkentve ezzel a többszörös értékelés szükségességét és a piacra jutás költségeit. Ez kulcsfontosságú a globális IT biztonsági termékek kereskedelmében.

2. Független és Objektív Értékelés:

   A Common Criteria értékelési folyamata független értékelő laboratóriumok és állami tanúsító hatóságok bevonásával történik. Ez biztosítja, hogy az értékelés objektív és pártatlan legyen, nem a gyártó önbevallásán alapul. Ez növeli a bizalmat a tanúsított termékek iránt.

3. Átláthatóság és Összehasonlíthatóság:

   A szabványosított terminológia, a Protection Profile-ok és a Security Target-ek részletes leírása rendkívüli átláthatóságot biztosít. A felhasználók pontosan megérthetik, milyen biztonsági funkciókat vizsgáltak, milyen fenyegetésekkel szemben nyújt védelmet a termék, és milyen mélységű volt az értékelés (EAL szint). Ez lehetővé teszi a különböző termékek biztonsági képességeinek összehasonlítását.

4. Bizalom Növelése a Termékek Iránt:

   A CC tanúsítvány egyfajta „minőségi pecsét” a biztonsági termékeken. A felhasználók, különösen a kormányzati szervek és a kritikus infrastruktúrák üzemeltetői, gyakran megkövetelik a CC tanúsítványt a beszerzéseik során, mivel ez garanciát nyújt a termék biztonsági integritására.

5. A Fejlesztési Folyamat Javítása (Security by Design):

   A Common Criteria értékelés nem csak a végterméket vizsgálja, hanem a fejlesztési folyamatot is (SARs). Ez arra ösztönzi a gyártókat, hogy már a tervezési fázisban (design) beépítsék a biztonságot, szigorú konfigurációkezelési, tesztelési és minőségbiztosítási gyakorlatokat alkalmazzanak. Ezáltal a termékek alapvetően biztonságosabbá válnak.

6. Jogi Megfelelés és Szabályozási Támogatás:

   Számos országban és iparágban a CC tanúsítvány jogi vagy szabályozási követelmény. A tanúsítás segíthet a szervezeteknek megfelelni olyan előírásoknak, mint a NIS2 irányelv, a GDPR (bizonyos szempontból), vagy más nemzeti kiberbiztonsági törvényeknek, amelyek a kritikus rendszerek biztonságát írják elő.

A Common Criteria hátrányai és kihívásai

1. Költséges és Időigényes:

   A Common Criteria tanúsítási folyamat rendkívül költséges és időigényes lehet. A magasabb EAL szintek elérése jelentős befektetést igényel a gyártótól a dokumentáció, a tesztelés és a fejlesztési folyamatok terén. Az értékelő laboratóriumok díjai is magasak lehetnek, és a teljes folyamat hónapokig, sőt akár évekig is eltarthat, ami akadályt jelenthet a kisebb vállalatok számára.

2. Komplexitás és Szakértelem Igénye:

   A Common Criteria szabvány maga is rendkívül komplex, és mélyreható szakértelmet igényel mind a gyártó, mind az értékelő részéről. Az SFR-ek és SAR-ok pontos értelmezése és alkalmazása kihívást jelenthet.

3. Az EAL nem a Termék Biztonságát Jelzi:

   Ez a leggyakoribb félreértés. Az EAL szint az értékelés szigorúságát mutatja, nem pedig a termék biztonsági képességeinek abszolút minőségét. Egy EAL7 termék elméletileg kevesebb funkcionális biztonságot nyújthat, mint egy EAL2 termék, ha az EAL7 termék Security Target-je kevesebb funkcionális követelményt tartalmazott. Egy magas EAL szintű termék is tartalmazhat sebezhetőségeket, amelyek az értékelés során nem kerültek felfedezésre, vagy a tanúsítás után jelentek meg.

4. A Tanúsítás Pillanatfelvétel:

   A CC tanúsítvány a termék egy adott verziójának biztonsági állapotát tükrözi az értékelés befejezésének időpontjában. A szoftverek és fenyegetések folyamatosan fejlődnek. Egy tanúsított termék a tanúsítás után is tartalmazhat vagy fejleszthet új sebezhetőségeket. A tanúsítás fenntartása (pl. frissítések, javítások értékelése) további erőforrásokat igényel.

5. Piaci Dinamika és Gyorsan Változó Fenyegetések:

   A kiberbiztonsági fenyegetések rendkívül gyorsan változnak. A hosszú értékelési ciklusok miatt a tanúsított termékek már elavultak lehetnek a legújabb fenyegetésekkel szemben, mire a tanúsítványt megkapják. Ez a tényező különösen a gyorsan fejlődő területeken (pl. felhő, IoT) jelent kihívást.

6. Korlátozott Hatókör:

   A CC elsősorban a termékekre és rendszerekre fókuszál. Bár a fejlesztési folyamatot is vizsgálja, nem terjed ki a teljes szervezeti biztonsági menedzsmentre vagy az emberi tényezőre, ami a biztonsági incidensek jelentős részéért felelős. Más szabványok (pl. ISO/IEC 27001) kiegészítik ezt a hiányosságot.

Összefoglalva, a Common Criteria egy erőteljes eszköz a bizalom építésére az IT biztonsági termékek iránt, különösen a magasabb kockázatú környezetekben. Azonban nem csodaszer, és a korlátait is meg kell érteni. Egy CC tanúsítvány önmagában nem elegendő a teljes biztonság garantálásához; a szervezeteknek továbbra is átfogó biztonsági stratégiát kell alkalmazniuk, amely magában foglalja a kockázatkezelést, a folyamatos ellenőrzést és a személyzet képzését.

A Common Criteria és más szabványok, szabályozások kapcsolata

A Common Criteria nem egy elszigetelt szabvány, hanem egy szélesebb kiberbiztonsági ökoszisztéma része. Számos más szabvány és szabályozás létezik, amelyek a Common Criteria-val együtt vagy kiegészítve segítik a szervezetek biztonságának megerősítését. Fontos megérteni, hogyan illeszkedik a CC ebbe a komplex környezetbe.

ISO/IEC 27001 – Információbiztonsági Irányítási Rendszer (ISMS)

Az ISO/IEC 27001 az információbiztonsági irányítási rendszerek (ISMS) globálisan elismert szabványa. Míg a Common Criteria egy termék vagy rendszer biztonsági értékelésére fókuszál, addig az ISO 27001 egy szervezet egészének információbiztonsági menedzsmentjét célozza. Az ISO 27001 arról szól, hogyan kell egy szervezetnek azonosítania, értékelnie és kezelnie az információbiztonsági kockázatait, és hogyan kell folyamatosan javítania a biztonsági gyakorlatát.

• Különbség: CC = termékbiztonság; ISO 27001 = szervezeti információbiztonság.
• Kapcsolat: Egy ISO 27001 tanúsítvánnyal rendelkező szervezet, amely biztonsági termékeket fejleszt, előnyben részesítheti a Common Criteria tanúsítást termékei számára. A CC tanúsított termékek használata hozzájárulhat ahhoz, hogy egy szervezet megfeleljen az ISO 27001 követelményeinek, különösen a technikai kontrollok (A.12) és a beszerzési biztonság (A.15) terén. A CC által megkövetelt szigorú fejlesztési folyamatok (SARs) jól illeszkednek az ISO 27001 kockázatkezelési és folyamatellenőrzési elveihez.

NIST (National Institute of Standards and Technology) szabványok és útmutatók

Az Egyesült Államok Nemzeti Szabványügyi és Technológiai Intézete (NIST) számos fontos kiberbiztonsági szabványt és útmutatót ad ki, mint például a NIST Cybersecurity Framework, a SP 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations) vagy a FIPS 140-2/3 (Security Requirements for Cryptographic Modules).

• FIPS 140-2/3: Ez a szabvány kifejezetten a kriptográfiai modulokra vonatkozik, és gyakran együtt említik a Common Criteria-val. Míg a FIPS 140 a kriptográfiai modul fizikai és logikai biztonságát, valamint a kriptográfiai algoritmusok megfelelő implementációját vizsgálja, addig a CC az egész termék (amely tartalmazhat FIPS 140 tanúsított modult) átfogó biztonsági funkcióit és megbízhatóságát értékeli. Sok esetben egy Common Criteria értékelés során hivatkoznak egy FIPS 140 tanúsított kriptográfiai modulra.
• NIST Cybersecurity Framework: Ez egy önkéntes keretrendszer, amely segíti a szervezeteket a kiberbiztonsági kockázatok kezelésében. A CC tanúsított termékek felhasználása hozzájárulhat a Keretrendszerben leírt „Védelme” funkcióhoz.

GDPR (General Data Protection Regulation) – Általános Adatvédelmi Rendelet

Az Európai Unió Általános Adatvédelmi Rendelete (GDPR) az egyéni adatok védelmét szabályozza. Bár a GDPR nem ír elő specifikus technikai szabványokat, hangsúlyozza az „adatvédelem beépített megközelítését” (privacy by design) és a megfelelő technikai és szervezeti intézkedések (TOMs) alkalmazását az adatok védelmére. A Common Criteria tanúsítás közvetlenül nem feleltethető meg a GDPR-nak, de a CC tanúsított termékek használata támogathatja a GDPR megfelelőséget.

• Kapcsolat: Egy CC tanúsított termék (pl. egy biztonságos adatbázis vagy titkosítási megoldás) segíthet a szervezeteknek abban, hogy biztosítsák az adatok bizalmasságát, integritását és rendelkezésre állását, ami alapvető fontosságú a GDPR megfelelése szempontjából. A CC által megkövetelt szigorú értékelés bizonyítékot szolgáltat a termék biztonsági garanciáiról, ami hozzájárulhat a GDPR által elvárt „megfelelő biztonság” szintjének eléréséhez.

NIS2 irányelv (Network and Information Systems Security Directive)

Az EU NIS2 irányelve a kritikus infrastruktúrák és digitális szolgáltatások kiberbiztonsági szintjének emelését célozza. Az irányelv számos követelményt támaszt a tagállamok és a kulcsfontosságú szektorok szereplői felé, beleértve a kockázatkezelési intézkedéseket és a biztonsági incidensek jelentését. A Common Criteria tanúsítás közvetlenül releváns lehet a NIS2 irányelv technikai biztonsági követelményeinek teljesítéséhez, különösen azokban az esetekben, ahol a kritikus rendszerekbe beépített IT termékekről van szó.

• Kapcsolat: A NIS2 előírhatja bizonyos biztonsági termékek vagy komponensek tanúsítását. A CC tanúsítványok, különösen a magasabb EAL szintek, bizonyítékul szolgálhatnak a termékek megbízhatóságáról és biztonsági integritásáról, segítve a NIS2 által megkövetelt ellenálló képesség elérését.

Egyéb iparági és nemzeti szabványok

Számos iparág (pl. pénzügy, egészségügy, autóipar) saját biztonsági szabványokat és előírásokat dolgozott ki. Ezek a szabványok gyakran hivatkoznak a Common Criteria-ra, vagy annak alapelveit építik be saját követelményrendszerükbe. Nemzeti szinten is léteznek olyan szabályozások, amelyek előírhatják a CC tanúsítványt bizonyos termékek vagy rendszerek esetében, különösen a kormányzati vagy védelmi beszerzéseknél.

Összességében a Common Criteria egy technikai értékelési szabvány, amely a termékek és rendszerek biztonsági integritására fókuszál. Nem helyettesíti a szervezeti szintű biztonsági menedzsmentet (mint az ISO 27001), sem az adatvédelmi szabályozásokat (mint a GDPR), de erős alapot biztosít a technikai biztonsági garanciákhoz. A CC tanúsított termékek felhasználása jelentősen hozzájárulhat a szervezetek átfogó kiberbiztonsági stratégiájához és a különböző szabályozási megfelelőségi követelmények teljesítéséhez.

A Common Criteria jövője és kihívásai

A Common Criteria, mint egy kiforrott és széles körben elfogadott szabvány, jelentős múlttal rendelkezik, de a digitális világ gyors változása folyamatosan új kihívásokat és alkalmazkodási igényeket támaszt elé. Ahhoz, hogy továbbra is releváns és hatékony maradjon, a CC-nek képesnek kell lennie a fejlődő technológiák és fenyegetések kezelésére.

Kihívások a modern IT környezetben

1. Felhőalapú Szolgáltatások Értékelése:

   A felhőalapú szolgáltatások (IaaS, PaaS, SaaS) egyre dominánsabbá válnak, de ezek értékelése Common Criteria szerint rendkívül komplex. A hagyományos CC értékelés fizikai termékekre és jól definiált határokra fókuszál. A felhő dinamikus, elosztott és gyakran változó architektúrája, valamint a „megosztott felelősség” modellje (ahol a szolgáltató és az ügyfél is felelős a biztonságért) új megközelítéseket igényel. Jelenleg léteznek kezdeményezések, mint például a Cloud Protection Profile (cPP), amelyek a felhőalapú környezetekre szabott követelményeket definiálnak, de ez még egy fejlődő terület.

2. IoT Eszközök és Edge Computing:

   A dolgok internete (IoT) robbanásszerűen terjed, de az IoT eszközök gyakran korlátozott erőforrásokkal rendelkeznek, egyszerűsített szoftverrel futnak, és hatalmas számban vannak jelen. Ezeknek az eszközöknek a CC szerinti értékelése a hagyományos módon aránytalanul költséges és időigényes lenne. Szükség van könnyített, de mégis megbízható értékelési módszerekre az IoT szegmens számára, amelyek figyelembe veszik az egyedi fenyegetéseket és erőforrás-korlátokat.

3. Mesterséges Intelligencia (AI) és Gépi Tanulás (ML):

   Az AI/ML rendszerek egyre inkább beépülnek a biztonsági termékekbe (pl. fenyegetésészlelés, anomáliafelismerés). Azonban az AI rendszerek „fekete doboz” jellege, az adathalmazok minősége és a modellek sebezhetőségei (pl. ellenséges támadások) új kihívásokat jelentenek az értékelés szempontjából. Hogyan lehet Common Criteria keretek között értékelni egy AI alapú biztonsági funkciót, ha a működése nem teljesen determinisztikus és nehezen magyarázható?

4. Gyorsabb Értékelési Ciklusok Szükségessége:

   A szoftverfejlesztési ciklusok felgyorsultak (Agile, DevOps), míg a Common Criteria tanúsítási folyamat jellemzően lassú. Ez a sebességkülönbség azt eredményezheti, hogy a tanúsított termékek már elavultak, mire a tanúsítványt megkapják. Szükség van az értékelési folyamat agilisabbá tételére, például inkrementális tanúsítási modellek vagy automatizált eszközök nagyobb mértékű bevezetésével.

5. Post-Quantum Kriptográfia:

   A kvantumszámítógépek fejlődése potenciálisan veszélyezteti a jelenlegi kriptográfiai algoritmusokat. A Common Criteria-nak fel kell készülnie a post-quantum kriptográfiai algoritmusok értékelésére, amint azok szabványosítottá válnak, és meg kell vizsgálnia a meglévő rendszerek átállásának biztonsági vonatkozásait.

A Common Criteria alkalmazkodása és jövőbeli irányai

A Common Criteria közösség aktívan dolgozik ezeknek a kihívásoknak a kezelésén. Néhány kulcsfontosságú irány:

• A Protection Profile-ok (PP) szerepének megerősítése: A PP-k fejlesztése és karbantartása egyre inkább kulcsfontosságúvá válik. A PP-k lehetővé teszik az iparág és a felhasználók számára, hogy gyorsabban reagáljanak az új technológiákra és fenyegetésekre, anélkül, hogy minden egyes termékhez egyedi Security Target-et kellene kidolgozni. Az „általános PP-k” (cPP – collaborative Protection Profiles) fejlesztése, amelyeket több ország szakértői közösen dolgoznak ki, felgyorsítja a folyamatot és növeli a konszenzust.
• Modulárisabb és rugalmasabb értékelési módszerek: A szabvány folyamatosan finomodik, hogy rugalmasabbá váljon a különböző technológiák és fejlesztési módszertanok értékelésére. Ez magában foglalhatja a modulárisabb értékelési csomagokat, amelyek lehetővé teszik a célzottabb vizsgálatokat.
• Automatizált eszközök bevezetése: A manuális tesztelés és elemzés mellett az automatizált tesztelő és kódellenőrző eszközök nagyobb mértékű bevezetése segíthet felgyorsítani az értékelési folyamatot, különösen az alacsonyabb EAL szinteken.
• A Common Criteria Recognition Arrangement (CCRA) bővítése: A CCRA folyamatos bővítése új tagországokkal erősíti a tanúsítványok nemzetközi elfogadottságát és a globális kiberbiztonsági együttműködést.
• Kiegészítő szabványokkal való együttműködés: A CC nem áll egyedül. A jövőben még inkább kulcsfontosságú lesz a szinergia más szabványokkal (pl. ISO 27001, NIST, ETSI) és szabályozásokkal (GDPR, NIS2), hogy egy átfogó és koherens biztonsági keretrendszert biztosítson.

A Common Criteria továbbra is alapvető szerepet játszik az IT biztonsági termékek megbízhatóságának biztosításában. Bár kihívásokkal néz szembe a gyorsan változó technológiai környezetben, a szabvány folyamatos fejlesztése és a nemzetközi együttműködés biztosítja, hogy továbbra is releváns és hatékony eszköz maradjon a digitális bizalom építésében.