A Common Criteria (CC) nemzetközileg elismert szabványkészlet ( ISO 15408), amelynek célja a számítógépes rendszerek és szoftverek biztonságának pártatlan értékelése. Ez a közös kritériumoknak is nevezett adattár Kanada, az Egyesült Államok és Európa közötti partnerségből született. A felajánlott keretrendszernek köszönhetően az informatikai felhasználók védelmi profilokat használhatnak a várható funkcionális biztonsági követelmények meghatározásához, az értékelők pedig ellenőrizhetik, hogy a termékek megfelelnek-e az előírt szintű biztonságnak.
A kölcsönös elismerési megállapodás aláírói által eldöntött közös kritériumok végrehajtása nagyban megkönnyíti az egyik aláíró ország által kiállított informatikai biztonsági tanúsítványok elfogadását. Az illetékes hatóság által elfogulatlanul hitelesített termék további értékelés nélkül használható fel.
Bár számos előnye van, ennek a szabványnak az alkalmazása költséges, nehezen érthető egy nem szakértő számára, és gyakran bonyolult a megvalósítása. Ez az oka annak, hogy számos felhasználási módszer megjelent.
1983-ban, majd 1985-ben a NIST és az NSA kiadta a Narancssárga könyvet . E dokumentum célja annak felmérése volt, hogy egy rendszer képes-e védekezni a támadások ellen.
Ugyanakkor Európát a TCSEC inspirálja, hogy 1991-ben meghatározza saját értékelési kritériumait az ITSEC számára . Ezek kitöltik a kockázatelemzés hiányosságait.
1993-ban Kanada meghatározta saját CTCPEC szabványát.
Egy országban megszerzett bizonyítványt csak a kölcsönös elismerési megállapodást aláíró országok ismerik el. Európában a SOG-IS megállapodás érvényes.
1999-ben az ISO származik a közös kritériumokból. Ez a szervezet összefogja a különböző államokat, hogy meghatározzon egy szabványt (ISO 15408), amelyet elismert az összes állam, amely 2000 májusában aláírta a CC-MRA megállapodást. A 17 aláíró ország mellett 9 nem aláíró ország is elismeri ezeket a tanúsítványokat.
A Common Criteria (CC) útmutató, amely referenciaként szolgál az információs termékek és az információkat kezelő rendszerek fejlesztéséhez és ellenőrzéséhez. A cél az illetéktelen közzététel, módosítás, felhasználás elvesztése elleni védelem. E három típusú hiba kategóriáit általában titoktartásnak, integritásnak és elérhetőségnek nevezik. A CC-k figyelembe veszik az emberi tevékenységek (rosszindulatú vagy nem) vagy nem emberi tevékenységből eredő kockázatokat.
Az ellenőrzött termékek gyűjtik, továbbítják és kezelik az ilyen információkat, nevezetesen a számítógépes hálózatokat , az operációs rendszereket az elosztott rendszerek és alkalmazások számára. A rendszert annak a felhasználásnak megfelelően értékelik, amelyre rendelték. A biztonsági követelményeknek két kategóriának kell megfelelnie: a funkcionális és a biztosítási követelményeknek.
A felhasználók biztonsági igényei a személyes adatok rendelkezésre állásának , titkosságának és hitelességének követelményei . A közös kritériumok a felhasználók három kategóriájára vonatkoznak:
Végfelhasználó A végfelhasználók az értékelési eredmény megtekintésével megállapíthatják, hogy egy termék megfelel-e igényeiknek. Fejlesztők A fejlesztők CC-k segítségével azonosítják termékük biztonsági követelményeit. Az értékelők A bírálók megtalálják azokat a kritériumokat, amelyek alapján értékelni lehet, hogy egy termék megfelel-e az értékelési célnak. A szabvány leírja a teendőket, de nem a követendő eljárásokat.A közös kritériumok három egymással összefüggő dokumentum tárgyát képezik:
Bevezetés és általános modell Ez a dokumentum általános fogalmakat határoz meg, és általános értékelési modellt mutat be. Emellett a kifejezések és kulcsszavak szószedetét is kínálja. Mint ilyen, a következő három betűszót használják rendszeresen: AZT A TI jelentése "Informatika". Az angol rövidítéssel, az " Informatika " rövidítéssel is ismerik az angolszász irodalmat. LÁBUJJ A TOE a " Target Of Assessment " rövidítése . A TOE az értékelés célja. Ez egy termék vagy informatika, amelyet a kapcsolódó dokumentációval értékeltek, egyrészt az adminisztrátor, másrészt a felhasználó számára. TSF A TSF a „ TOE biztonsági funkciók ” rövidítése . Megjelöli a TOE összes biztonsági funkcióját. Funkcionális biztonsági követelmények Ez egy funkcionális biztonsági elemek családokba és osztályokba sorolt katalógusa. Biztonsági garancia követelmények Ez a dokumentum felsorolja a fejlesztővel szemben támasztott követelményeket és az értékelő számára elvégzendő feladatokat.A biztonsági funkcionális követelmények csak a biztonsági funkciók specifikációira vonatkoznak. Tizenegy osztályba vannak csoportosítva, amelyek egy-egy tartományt fednek le. Minden osztály családokra oszlik. Minden család olyan alkatrészeket tartalmaz, amelyek biztonsági követelményt jelentenek. Minden osztályt egyedi névvel jelölünk, amelynek rövidítése három Fxx karakterből áll: F a Funkcionális követelmény osztályhoz és xx a lefedett funkció nevének azonosításához.
FAU biztonsági audit osztály 6 családra bontva, mindegyik 1-4 biztonsági alkatrészt csoportosítva:"A biztonsági audit magában foglalja a biztonsággal kapcsolatos tevékenységekhez kapcsolódó információk felismerését, rögzítését, tárolását és elemzését . "
Osztály COmmunication FCO Ez az osztály foglalkozik az adások és a vétel visszautasításával . Következésképpen 2 családra oszlik; az első az átvitelre, míg a második a vételre vonatkozik. FCS kriptográfiai támogatási osztály Magas szintű biztonságra vonatkozik, amely kriptográfiai funkciók használatát igényli . 2 családból is áll; az egyik a kulcskezelésre, a másik a kulcsok előállítására vonatkozik. FDP felhasználói adatvédelmi osztály 8 család négy csoportra osztva a felhasználói adatok manipulálására vonatkozik. FIA azonosító és hitelesítési osztály Ez az osztály 6 családból áll, hogy azonosítsa a felhasználót, hitelesítse őt és kezelje ezeket a hozzáférési jogokat. FMT biztonsági adminisztráció osztály Ez lehetővé teszi többek között a biztonsági szerepkörök meghatározását. Ezenkívül 6 családra oszlik, amelyek 1-3 komponenssel rendelkeznek. FPR adatvédelmi osztály Ennek az osztálynak a követelményei kiterjednek az egyén védelmére a személyazonosság mások általi felfedezése vagy csalárd felhasználása ellen. TOE FPT védelmi osztály Célja a TOE és már nem a felhasználó biztonsági funkcióinak védelmi követelményeinek leírása. Az azt alkotó családok az FDP osztály másolataként jelenhetnek meg. FRU erőforrás-felhasználási osztály Az erőforrások elérhetőségével kapcsolatos három követelménycsalád alkotja ezt az osztályt: hibatűrés, erőforrás-elosztás és a szolgáltatások prioritása. Hozzáférési osztály az FTA értékelési célhoz Meghatározza a felhasználói kapcsolat létrehozásának ellenőrzéséhez szükséges funkcionális követelményeket. Például szabályozhatja a munkamenetek számát, módosíthatja a hozzáférési paramétereket, megjelenítheti a kapcsolatok előzményeit. FTP elérési út osztály és megbízható csatornák a felhasználó és az informatika, de a TI között is biztonságos kommunikáció létrehozására használt útvonalakra vonatkozik.A fejlesztő képes lesz meghatározni az ebből a listából származó összetevők csomagját a termékének funkcionalitása szerint. Mivel ez a lista nem teljes, szükség szerint kiegészíthető. Így a hamis ujjak detektálására szolgáló biometrikus eszköz tanúsítása érdekében a SAFRAN felvette az SPOD családot az FPT osztályba. A termék tanúsításához a SAFRAN az alábbi családokból is választott alkatrészeket:
A biztosítási követelmények listája a Közös Feltételek második listája. Meghatározza azokat a pontokat, amelyeket ellenőrizni kell, hogy egy termék elérje-e a biztonsági rés bizonyos fokú bizalmát . Ez kiterjed a dokumentáció és a termék vagy rendszer érvényességére. A fejlesztő számára ez a bizonyítékok felsorolása, amelyeket az értékelés részeként be kell nyújtaniuk. Ami az értékelőt illeti, képes lesz meghatározni azokat a feladatokat, amelyeket a közös kritériumok alapján el kell végezni a tanúsítás megszerzéséhez.
Ez a lista szintén egy témát felölelő osztályokból áll. Ezek az osztályok családokra vannak felosztva, amelyek összetevőket csoportosítanak. Mindegyik komponens egy adott pont értékelésének többé-kevésbé fejlett szintjét képviseli. Biztosítási elemekre vannak osztva. Az osztályok elnevezését három Axx karakterrel hajtják végre: A biztosítást jelölő jelölést két betű követi a lefedett terület azonosítására.
Osztályok listája;
Biztonsági garancia követelmények| Osztály | Fedett terület |
|---|---|
| ADV | Fejlődés |
| CO | Fogalmazás |
| AGD | Dokumentáció |
| ALC | Életciklus |
| EMBERSZABÁSÚ MAJOM | Védelmi profil értékelése |
| ASE | Biztonsági célértékelés |
| ATE | Tesztek |
| AVA | A sebezhetőség becslése |
A közös kritériumok szerinti értékelést követően kiadott bármely tanúsítvány garantálja, hogy az értékelt Információs Rendszer megfelel bizonyos szintű bizonyosságnak. Ez egyenértékű az EAL 1-től az EAL7- ig terjedő pontszámmal (értékelési bizonyossági szint). Ezek a szintek egy minimális biztosíték-követelménycsomaghoz kapcsolódnak. Hét hierarchikus szint határozza meg az értékelt termék bizalmának mértékét.
Minden szint tartalmazza az előző szint követelményeit. Ezek tükrözik az egyensúlyt a megszerzett bizonyosság szintje és a szint elérésének költségei között.
1. szint a legolcsóbb és nem igényli a fejlesztő részvételét. Azt állítja, hogy az értékelés célja a dokumentációban leírtak szerint működik. Csak a nyilvánosság számára azonosított fenyegetések vonatkoznak rá. 2. szint megköveteli a fejlesztői részvételt a specifikációval kapcsolatos információk és az elvégzett teszt eredmények közléséhez. 3. szint nyilvánvaló sebezhetőségek felkutatását tanúsítja. 4. szint jó kompromisszumot jelent a biztonság és a költségek között. Nem igényel semmilyen speciális tudást vagy szakértelmet. Reagál az elemi támadásokkal kapcsolatos sebezhetőségekre. 5. szint igazolja a biztonsági funkciók elemzését. Ez az elemzés a funkcionális specifikációkon, az interfészek teljes specifikációján, az útmutatókon és a TOE tervezésén alapul. 6. szint nagy kockázatú környezetekben történő TOE fejlesztésekhez. 7. szint az eddigi maximális szint. Megköveteli a funkcionális specifikációk hivatalos bemutatását és a specifikációk magas szintjét. Védelmi profilokA védelmi profil biztonsági követelményeket határoz meg egy termékkategóriához, a megvalósítástól függetlenül. Így az ügyfélnek képesnek kell lennie arra, hogy védelmi profilt használjon a biztonsági házirendjének kifejezésére. Az ilyen dokumentum előnye, hogy újrafelhasználható. Ez az oka annak, hogy általánosnak és strukturáltnak kell lennie a következő fejezetekkel:
Csak azok az országok jogosultak tanúsítványok kiadására, amelyek a közös kritériumok alapján aláírták a kölcsönös elismerési megállapodást. Ők is elfogadják, hogy új tag csatlakozzon hozzájuk. Így India lett a 17 th aláíró 2013.
A pártatlanság érdekében az informatikai termékek értékelését független szervezetnek kell elvégeznie. Az értékelésekért felelős laboratóriumokat a CCMRA-megállapodást aláíró országokat képviselő kormányzati szervek akkreditálták.
Az USA-ban Az NSA irányítja a kormányzati NIAP programot, amely felelős az informatikai ügyfelek és tervezők biztonsági szükségleteiért. Akkreditálja a CCTL-nek nevezett szakértői laboratóriumokat, és a végleges tanúsítvány kiállításával vagy ki nem igazolásával validálja az értékelés eredményeit. Franciaországban Rendelettel a Nemzeti Információs Rendszerek Biztonsági Ügynökségét (ANSSI) nevezik ki tanúsító hatóságnak. Ennek az ügynökségnek két szerepe van:| Ország | Kormányszervezet |
|---|---|
| Ausztrália | ASD Ausztrál Jelzőigazgatóság |
| Kanada | Kanadai közös kritériumok értékelési és tanúsítási rendszere CECS |
| Franciaország | Nemzeti Információs Rendszerbiztonsági Ügynökség ANSSI |
| Németország | Bundesamt für Sicherheit in der Informationstechnik BSDI |
| India | Indiai közös kritériumok tanúsítási rendszere IC3S |
| Olaszország | Az OCSI Sicurezza Informatica tanúsítványszervezete |
| Japán | Japán informatikai biztonsági értékelési és tanúsítási rendszer JISEC |
| Malaysia | CyberSecurity Malajzia |
| Hollandia | Az NSCIB üzemeltetője |
| Új Zéland | Védelmi Jelek Igazgatósága |
| Norvégia | SERTIT |
| Koreai Köztársaság | IT biztonsági tanúsító központ (ITSCC) |
| Spanyolország | Organismo de Certificación de la Seguridad de las Tecnologías de la Información |
| Svédország | Svéd IT Biztonsági Minősítő Testület FMV / CSEC |
| pulyka | Török Szabványügyi Intézet Common Criteria Certification Scheme TSE |
| Anglia | Egyesült Királyság informatikai biztonsági értékelési és tanúsítási rendszere |
| Egyesült Államok | Nemzeti Információbiztosítási Partnerség NIAP |
A tanúsítás 3 szakaszban történik:
Értékelés iránti kérelemA szponzor értékelést kér a minősítésekért felelős kormányzati szervtől. A vállalat felelőssége:
Az értékelő beavatkozhat a termék tervezésébe. Meg kell vizsgálnia a tesztkönyv relevanciáját és a szponzor által elvégzett tesztek eredményét. Ezután kiad egy RTE műszaki értékelési jelentést, amely igazolja az elért bizonyosság szintjét.
TanúsítványA tanúsító hatóság a műszaki értékelési jelentésre támaszkodik, hogy kiállítsa vagy ki ne adja az értékelési tanúsítványt a közös kritériumok szerint.
Mellado és Taguchi szerint a biztonsági stratégia végrehajtása a fejlesztési folyamat korai szakaszában megtérül. Ez robusztusabb rendszert hoz létre azáltal, hogy csökkenti a fejlesztés későbbi szakaszaiban fellelhető biztonsági réseket. Lloyd szerint a COTS gyártásához és forgalmazásához a növekvő költségek és az időbeli korlátok arra kényszerítik sok szervezetet és az Egyesült Államok kormányát, hogy a biztonsági aggályokat integrálják alkalmazásuk fejlesztésébe. Kallberg szerint a szabvány kölcsönös elismerése elméletileg időt és pénzt takarít meg a felesleges biztosítékok megszüntetésével.
Felhasználói bizalomA Mellado esetében sok IS felhasználó nem rendelkezik ismeretekkel és erőforrásokkal a rendszerek biztonsági szintjének minősítéséhez. A CC-k használata a biztonsági értékelés alapjául a felhasználók bizalmát adja. A Sauveron szerint a tanúsítás lehetővé teszi az ügyfelek számára, hogy objektív módon hasonlítsák össze a piacon lévő különböző termékeket.
A gyártók versenyelőnyeA Sauveron jelzi, hogy bizonyos piacokon (pl. Bankokban) kötelező a tanúsítás. A gyártó ezért hozzáférhet zárt vagy speciális piacokhoz. A gyártók piaci tanúsításként piaci tanúsításként használhatják a tanúsítást.
A nemzeti támadások kockázatának ellenőrzéseA Sauveron számára a tanúsítás lehetővé teszi a kormányzati tanúsító testületek számára, hogy biztosítsák az országukban használt termékek ellenőrzését. Ezért nincs komoly kockázata a számítógépes rendszereik elleni támadásoknak.
Mellado és Razzazi szerint a szoftverprojektek többségében a biztonsággal akkor foglalkoznak, amikor a rendszereket már megtervezik és üzembe helyezik. A biztonsági követelmények meghatározása gyakran túl tömör. A fogyasztók nem képesek egyértelműen és egyértelműen megfogalmazni a termékbiztonsági követelményeket. A biztonsági követelményeket gyakran félreértik. A biztonsági követelmények kezelése összetett kérdés a fejlesztők számára. Sok fejlesztő hajlamos a tervezési megoldásokat a védelmi mechanizmusok vonatkozásában leírni, ahelyett, hogy deklaratív javaslatokat tenne a szükséges védelmi szintről.
Nehéz és drágaA Razzazi számára a CC-k túl sok teret engednek a kétértelműségeknek, és gyakran nehéz pontosan megérteni a biztonsági követelmények jelentését. Shoichi jelzi, hogy a CC kritériumai nagyon elvontak, lehetetlen átfogó áttekintést készíteni. Nehéz teljesen meghatározni a követelményeket a semmiből. Keblawi szerint a tapasztalatok azt mutatják, hogy az előírt szabványok rugalmatlanok, és figyelmen kívül hagyják a valós szempontokat. Taguchi esetében a módszerek szemantikailag nagyon összetettek, ezért a tanulás költsége nagyon magas. Preschern számára a tanúsítás szigorúságot ró a fejlesztési és karbantartási folyamatokra. Manapság a tanúsítás viseli a termékfejlesztés költségeinek nagy részét. Hearn jelzi, hogy a COTS-t használó rendszerek esetében a rendszerintegráció és a biztonsági összetétel nehéz kérdés. Mivel függenek a használt COTS biztonságtechnikai alapelveitől és más elemekkel való működésüktől. Ez a munka növeli a költségeket és a szállítási időt.
Komplex, szakértőknekWare szerint a nem biztonsági személyek számára a CC-ket nehéz megérteni. Keblawi azt állítja, hogy bár a biztonsági területen vannak analitikai módszerek, mint például a biztonsági tervezés és a kockázatelemzések, ezeket soha nem fogalmazták meg egy fejlesztési folyamat során. Taguchi számára a létező módszertanokból hiányzik egy másik kulcsfontosságú pont, hogy nincs szabvány az információs rendszerek biztonsági tulajdonságainak tömör és szisztematikus dokumentálásának módjára a rendszerfejlesztés során. Shoichi szerint értékelési mechanizmus nélkül a folyamat hosszú és drága, mert nem könnyen hozzáférhető olyan hitelesítők számára, akik nem matematikusok vagy ismerik a formális módszereket. Lloyd szerint a biztonsági követelmények meghatározása nehéz, mert a követelmények funkcionális és nem funkcionális szempontokat egyaránt felölelnek, és sok fejlesztő nem biztos, hogy ismeri az összes megoldandó biztonsági kérdést.
Nem mindig érvényesRazzazi szerint a jelenlegi rendszerek nem rendelkeznek az új informatikai biztonsági igények kielégítéséhez szükséges technológiai alapokkal. A Keblawi jelzi, hogy egyes rendszerek nem felelnek meg könnyen a Common Criteria biztonsági koncepcióinak. A Lloyd esetében az összes COTS-követelmény nem alkalmazható közvetlenül az egyes COTS-összetevőkre, mivel az informatikai rendszerekhez képest kisebb a funkcionális hatókörük.
Ipar és fogyasztói jövőképWare szerint a CC védelmi szinteket a gyakorlatban ritkán használják. A Taguchi esetében a CC-k nem könnyen alkalmazhatók az iparban a meglévő szoftverfejlesztési folyamat és a CC-módszerek közötti eltérések miatt. Hearn szerint az eladók nem tekintik a CC-ket termékfejlesztési folyamatnak. Lehetetlen felmérni azt a költség-haszon arányt, amelyet a CC használata számítógépes rendszerben elérhet. Isa szerint sok kutató és iparági képviselő jelzi, hogy a CC gyakorlata a gyorsan változó világban csak a CC „utópikus” kontextusában létezhet. Kallberg szerint az ipari háborúk növekedésével a CC-k valószínűleg nem érik el a kritikus tömeget globális tanúsítási platformként. Hearn szerint a vásárlók a tanúsításokat kisebb szempontnak tekintik a beszerzésben. Ritkán olvassák el a biztonsági vagy tanúsítási célt, és az értékelést. A fogyasztó nem foglalkozik a CC-folyamatokkal, amelyekben a biztonság és a fenyegetés modellje túl homályos ahhoz, hogy hasznos legyen.
A kormány bizalmaNéhány akadály - mondta Hearn - az országok közötti értékelések harmonizációjával kapcsolatos aggodalmakhoz kapcsolódik. A nemzetközi harmonizáció és a belföldi befektetések közötti konfliktusok különösen fontosak lehetnek, ha a nagyobb európai országok és az Egyesült Államok továbbra is egyre különbözőbb utakat követnek a nemzeti érdekek érvényesítésében. Még ha az alapító tagországok is képesek voltak a harmonizációra törekedni, a tapasztalatok azt mutatják, hogy a részletek megvalósítása eltér egymástól. Isa számára hiányzik a vevők és az eladók érdeklődése, mivel a kormányoktól érkeznek a CC-k, és emelik a megvalósítás árait. Hearn szerint az üzleti érdeklődés alacsony, mivel a tanúsítások az állami szabályozás vagy a kormányzati beszerzések eredménye.
A Taguchi által javasolt módszer felhasználási esetek diagramján alapszik, több elv alapján. Ezen elvek közül az első egy olyan diagram használata, amely részletezi a biztonsági koncepciókat a biztonsági igények bemutatására. Ezután az ábra összes fogalma egy CC meta modell elemei. Végül a biztonsági modelleket hozzáadjuk a termék gyártásának egyes szakaszaihoz tartozó biztonsági korlátok szerint.
Ez a módszer a CC-ből származó metamodellt használja, amely része a TOE biztonsági funkcionalitásának. A következő CC fogalmak maradnak fenn:
A szerző úgy dönt, hogy metamodelljéből a következő CC fogalmakat távolítja el:
A prototípus diagram három fázisban készül. Az első szakasz ( alapvető biztonsági követelmények ) elvont módon elemzi a biztonsági funkciókat és a biztonsági fenyegetéseket. A második ( Biztonsági követelmények és célkitűzés ) részletesen elemzi a biztonsági követelményeket a biztonsági célok meghatározása érdekében. Ezt a munkát az 1. fázis eredményéből hajtják végre. Végül a 3. fázist ( A funkcionális biztonsági követelmények kiválasztása ) használják azon funkcionális biztonsági követelmények kiválasztására, amelyek megfelelnek az előző szakaszban meghatározott biztonsági céloknak. Ezt a feladatot a CC 2. rész szabványos és védelmi profiljaival hajtják végre. Ezután a biztonsági követelményeket összehangolják a CC módszertan szerinti biztosítási követelményekkel.
A Ware által javasolt módszer abból áll, hogy a szereplők profiljait felhasználva felhívják a biztonsági fenyegetéseket. Ezután végezze el a fenyegetések és a biztonsági célok feltérképezését. Végül végezze el a biztonsági célok és a biztonsági követelmények feltérképezését. A leképezést egy eszköztár segítségével hajtják végre, amely tartalmazza a CC-k fenyegetéseinek, célkitűzéseinek és funkcionális követelményeinek felsorolását. A megközelítés megvalósításához nyílt forráskódú UML grafikus modellező eszközt javasolnak.
Az eszköz a „Veszélytáblázatban” egyértelműen bemutatja a konkrét fenyegetés leküzdéséhez szükséges célokat és a konkrét célkitűzés teljesítéséhez szükséges követelményeket.
Ezután az eszköz felajánlja a felhasználónak, hogy készítsen kimeneti fájlt HTML formátumban. Az eszköz két lehetséges jelentésstílust kínál:
A „CC elv” jelentés célja, hogy előállítsa a TOE biztonsági cél indoklásának egy részét. Ezenkívül a mérkőzések egyértelműen megmutatják a konkrét fenyegetés leküzdéséhez szükséges célokat és a konkrét célkitűzések teljesítéséhez szükséges követelményeket.
A Vetterling által javasolt módszer olyan folyamat, amely ötvözi a „fázisorientált” szoftverfejlesztést a CC-k által megkövetelt tevékenységekkel. Az alapelv az, hogy a KT tevékenységeit integrálják a projekt fejlesztési fázisaiba. Ez a módszer a projekt minden szakaszában egy iteratív folyamaton alapul. Minden iteráció végén értékelhető az eredmény. A következő iteráció az előző szakasz eredményével kezdődik, új követelmények hozzáadásával.
A tervezési szakaszban a konfigurációkezelési tervet (ACM osztály) írják. Az életciklus kézikönyvet (ALC osztály) szintén a kiválasztott EAL szintjének megfelelően írják. Ebben a szakaszban kell eldönteni az EAL szintjét, és a rendszer vagy a termék mely részét kell fejleszteni a CC-kkel összhangban.
Az elemzési szakaszban elkészül a biztonsági cél (ASE osztály). Ebben a fázisban kezdjük el írni a tesztdokumentum (ATE osztály) és felhasználói útmutatók (AGD osztály) első verzióit is.
A tervezési szakaszban megkezdődik a tervezés és ábrázolás (ADV osztály) megfogalmazása. Részletességi szintje a kiválasztott EAL szintjétől függ. A Vulnerability Assessment (AVA osztály) szintén ebben a szakaszban indul. Ez a szakasz információt nyújt a felhasználói kézikönyvekhez (AGD osztály).
A fejlesztési fázisban vannak olyan teszt eredményelemzési elemek, amelyek fontosak lesznek a tesztdokumentáció szempontjából (ATE osztály). A legmagasabb EAL-szintekhez a tervezési és ábrázolási dokumentumot (ADV osztály) ki kell tölteni a megvalósítás ábrázolásával. A biztonsági rés értékelése (AVA osztály) és a felhasználói útmutatók ebben a fejlesztési szakaszban véglegesülnek. A szállítás és az üzemeltetés dokumentációja (ADO osztály) szintén a fejlesztési szakaszban készül.
A szállítások dokumentumai (ADO osztály) a telepítés és az üzembe helyezés szakaszában kerülnek elkészítésre.
Esettanulmány készült egy elektronikus pénztárca alkalmazás fejlesztéséről. A projekt 3 hónapig tartott 18 fős csapattal, 630 embernapos munkaterheléssel.
Az első visszajelzés az, hogy a CC-k túl sok teret engednek a kétértelműségeknek, gyakran nehéz megtalálni a biztonsági követelmények helyes értelmét. A CC követelmények különböző értelmezése gyakran lehetséges, és értékes időt pazarol a projekt során.
A CC-k kölcsönösen függővé teszik a dokumentumokat, ami megnöveli a dokumentumterhet. Ezt a dokumentációs terhelést növeli az a tény is, hogy a CC követelmény az absztrakció különböző szintjein helyezi el a specifikációkat. A CC funkcionális követelményeinek köre elsősorban a kommunikációs hálózatok és az elektronikus kereskedelem területén található. Nem fedi megfelelően a felhasználók adatvédelmi követelményeit vagy a tisztességes kereskedelem követelményeit.
José Romero-Mariona olyan megközelítést javasol, amely megfelel a CC-k biztonsági követelményeinek az építészeti elemekkel és azok összefüggéseivel. A módszer útmutatót nyújt, amely elsősorban a CC folyamat megfigyelésein alapul: a biztonsági követelmények kidolgozása. Ennek az útmutatónak a segítségével képesnek kell lennie feltérképezni ezeket az építészeti elemekre vonatkozó követelményeket és kapcsolataikat.
Ezután ebből a leképezésből egy eszköz automatizálja az XML fájl felépítését, miután elvégezte a leképezés ellenőrzését. Az eszköz fő moduljai a következők:
A CC-k összetevőit és kapcsolataikat XML-ben 4 paraméter határozza meg:
A második modul elvégzi a felhasználó által definiált ellenőrzést, és nem szabványos XDR formátumban készít egy átírást. Ha hiba történik, az eszköz jelzi azt, és tájékoztatja a felhasználót arról, hogy mit kell tenni a probléma megoldása érdekében. A harmadik modul automatikusan létrehoz egy kimeneti fájlt XML formátumban. Ezután a felhasználó új összetevőket adhat hozzá. Az eszköz létrehoz egy új XML fájlt, amelyet vissza lehet adni a második modulba ellenőrzés céljából.
Shanai Ardi egy olyan módszert javasol, amely a biztonsági cél kiegészítéséből áll, szoftveres sebezhetőségek hozzáadásával. A biztonsági cél a következőket célozza meg: