Alkalmazásfejlesztés biztonsága

Az előadások a következő témára: "Alkalmazásfejlesztés biztonsága"— Előadás másolata:

1 Alkalmazásfejlesztés biztonsága
Krasznay Csaba

2 Emlékeztetőül Az információvédelem tárgya maga az információ.
Az információt három alaptulajdonságon keresztül tudjuk megvédeni: bizalmasság, sértetlenség, rendelkezésre állás. A három alaptulajdonsághoz biztonsági szabályzatok köthetők. A biztonsági szabályzatot biztonsági mechanizmusokon keresztül tartatjuk be. A biztonsági mechanizmusok lehetnek megelőzők, felderítők és javítók. Ez a PreDeCo elv.

3 Emlékeztetőül Vagyonleltár: a vagyontárgy azonosítása, értékelése
Sebezhetőségvizsgálat a lehetséges, releváns fenyegető tényezők számba vétele a sikeres támadáshoz szükséges támadható felületek (sebezhetőségek) azonosítása Kockázatértékelés: a sikeres támadás valószínűségének, és az azon keresztül a vagyontárgyban okozott kár mértékének becslése Védelmi intézkedés tervezése és bevezetése Védelmi intézkedés működtetése, ellenőrzése Kockázatok újraértékelése

4 Emlékeztetőül A hozzáférés-ellenőrzés olyan biztonsági mechanizmusok gyűjteménye, mely meghatározza, hogy a felhasználók mit tehetnek a rendszerben, azaz milyen erőforrásokhoz férhetnek hozzá, és milyen műveleteket hajthatnak végre. Azok a védelmi intézkedések tartoznak ide, melyek szabályozzák, hogy egy felhasználó milyen felhatalmazással férhet a rendszerhez, milyen alkalmazásokat futtathat, mit olvashat, hozhat létre, adhat hozzá és törölhet egy információból. Két lépésből áll: azonosítás (identification) és hitelesítés (authentication). A hozzáférés-ellenőrzés része az elszámoltathatóság.

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

6 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. Az előadás során arra koncentrálunk, hogy hogyan lehet biztonságos rendszert fejleszteni (mi alapján lehet kiválasztani) és azt értékelni.

7 Nyílt vs. zárt forrás Biztonságosabb-e a nyílt forráskódú szoftver?
Igen, mert bárki átnézheti a forráskódot, nem, mert ki nézi át a forráskódot? Ken Thompson tyúk-tojás problémája: Nem bízhatsz meg abban a kódban, amit nem saját magad készítettél! Még a forráskód ellenőrzése sem védhet meg feltétlenül a nem kívánt kódoktól. Mert mi van akkor, ha a fordítóprogramban van csalás? Vagy esetleg a mikroprocesszor hardverében?

8 Nyílt vs. zárt forrás A US-CERT kutatása szerint 2005-ben 812 Windows-os és 2328 Unixos sérülékenységet találtak. Ezek veszélyessége azonban változó, egyes számítások szerint a Windows-os hibák 50%-a kritikus. Nem lehet egyszerűen eldönteni a nyílt vs. zárt forráskód vitát!!! Az biztos, hogy a ködösítésen alapuló biztonság (security by obscurity) sosem célravezető! Csak arra támaszkodhatunk, hogy a biztonságot már a tervezés során figyelembe vették-e, és esetleg független harmadik fél tanúsította-e.

9 A szoftverkörnyezetet érintő fenyegetések
Ellenőrzés ideje/használat ideje (Time of Check/Time of Use – TOC/TOU): olyan szoftverhiba, melyet a rendszerben okozott változás okoz egy feltétel ellenőrzése, és az eredmény felhasználása között. Például egy hitelesített felhasználó éppen dolgozik egy rendszerben, amikor a rendszergazda kizárja őt, de a hiba miatt a felhasználónak joga van befejezni az immár nem jogosult módosítást. Hátsókapu (backdoor)

10 A szoftverkörnyezetet érintő fenyegetések
Helyi programozó (citizen programmers): Igen gyakori hiba, hogy a helyi felhasználók hozzáférnek bizonyos szoftverfejlesztői környezetekhez (pl. Visual Basic). Ilyenkor olyan változásokat tudnak írni a működő alkalmazásokba, melyek teljesen kívül esnek minden rendszerfejlesztési szabályon, így fenyegetést jelentenek az egész szervezetnek. Mobil kód (mobile code) Objektum újrafelhasználás (object reuse) Puffer túlcsordulás (buffer overflow) Rejtett csatorna (covert channel) Személyes ráhatás (social engineering)

11 Rosszindulatú kódok Olyan szoftverek, melyek szándékosan úgy lettek megírva, hogy működésük közben betörjenek egy rendszerbe, áthágják a biztonsági szabályzatokat vagy kárt okozzanak. Rengeteg csoportosításuk van, talán a legegyszerűbb három alapvető csoportba osztani őket: Vírusok (virus): Olyan kód, mely egy másik végrehajtható kódhoz csatlakozik. Önmagát sokszorosítja, de terjedni csak emberi segítséggel tud. Férgek (worm): Olyan kód, mely önmagában hordozza a károkozó tartalmat. Önmagát sokszorosítja, emberi beavatkozás nélkül tud terjedni (hálózaton). Trójaiak (trojan): Olyan kód, mely egy másik végrehajtható kódhoz csatlakozva hasznos funkcionalitást hitet el magáról. Önmagát nem sokszorosítja, terjedni általában más rosszindulatú kóddal szokott.

12 Rosszindulatú kódok Típus 2007 2006 Növekedés TrojWare 201958 91911
119,73% VirWare 12416 6282 97,64% MalWare 5798 4558 27,20% AdWare 14382 2583 456,79% RiskWare 2690 Összesen 237244 105334 125,23%

13 Rosszindulatú kódok Egyéb új rosszindulatú kódok száma
Új trójaiak száma Új vírusok és férgek száma Trójaiak eloszlása Vírusok és férgek eloszlása Egyéb rosszindulatú kódok száma Forrás: Kaspersky Security Bulletin 2007: Malware evolution in 2007

14 Adatbázisokra vonatkozó fenyegetések
Adatelfogás (interception of data): távoli hozzáférés esetén fennáll a veszélye annak, hogy a kapcsolatot eltérítik, és módosítják a küldendő adatot. Adatfertőzés (data contamination): az adat sértetlenségi hibáját okozó esemény, adatbeviteli hiba vagy hibás feldolgozás miatt. Adattöbbszörözés (polyinstantiation): olyankor fordul elő, amikor egy információt több helyen tárolnak. Az információ sértetlensége van veszélyben amiatt, hogy több helyen kell egyszerre frissíteni az információt. Aggregálás (aggregation): annak a lehetősége, hogy különböző forrásból lekérdezett nem érzékeny adatok kombinálásával érzékeny adatok hozhatók létre. Ellenőrzés ideje/használat ideje (Time of Check/Time of Use – TOC/TOU)

15 Adatbázisokra vonatkozó fenyegetések
Helytelen módosítás (improper modification of information): hitelesített vagy nem hitelesített felhasználók véletlenül vagy szándékosan helytelenül módosítják az információt. Holtpont (deadlocking): akkor következik be, amikor két felhasználó egyszerre próbál hozzáférni az információhoz, és emiatt az adatbázis-kezelő mindkét félnek megtagadja a válaszadást. Hozzáférés-ellenőrzéshez használt adatbázis nézetek kompromittálása (compromising database views used for access control): a felhasználó csak azokat az adatokat láthatja, amihez a nézetében hozzáfér. Fennáll a veszélye annak, hogy kitör ebből a nézetből. Konkurencia (concurrency): amikor események egyszerre futnak, fennáll a veszélye annak, hogy egy esemény régi adatot használ, és ezzel inkonzisztenciát vagy holtpontot idéz elő.

16 Adatbázisokra vonatkozó fenyegetések
Következtetés (inference): az a lehetőség, hogy a rendelkezésre álló információk vizsgálatából valamilyen más, érzékeny információra lehet következtetni. Lekérdezési támadás (query attack): a támadó olyan eszközt használ, amivel az adatbázis frontendjét kikerülve tud lekérdezést kezdeményezni. Megkerüléses támadások (bypass attacks): a felhasználó megpróbálja kikerülni a frontend védelmi intézkedéseit, hogy hozzáférjen az információkhoz. Szerver hozzáférés (server access): a támadó közvetlenül az adatbázis-szerver ellen indít (pl. fizikai) támadást. SQL injektálás (SQL injection): a támadó egy webes felületen keresztül ad ki lekérdezési utasítást, így szerezve nem jogosult hozzáférést. Túlterheléses támadás (Denial-of-Service): olyan támadás, melynek során a hitelesített felhasználók nem tudnak hozzáférni az információkhoz, az erőforrások túlterheltsége miatt.

17 Olvasnivaló Ken Thompson: Reflections on Trusting Trust. US-CERT Cyber Security Bulletin. Vírusok: Férgek: Tórjaiak:

18 Biztonságos fejlesztés
A fenti sérülékenységekre számtalan védelmi intézkedés ismert. A konkrét intézkedések ismertetése helyett azonban érdemesebb inkább azzal foglalkozni, hogy ezeket hogyan tervezzük és építsük bele a megoldásunkba. A biztonságnak minden szoftverfejlesztési modellben helye van, azt nem szabad kihagyni!!! Minden modell tipikusan tartalmazza a következő életcikluson átívelő lépéseket: Projektindítás és tervezés Funkcionális követelmények meghatározása Rendszertervezés Fejlesztés és dokumentálás Elfogadás Telepítés Működtetés és fenntartás Áttekintés és kivonás

19 Projektindítás és tervezés
A biztonsági igények felderítése: Az alkalmazásban tárolt információk kritikusságának meghatározása Alapvető biztonsági célok meghatározása Kezdeti kockázatelemzés Fenyegetések/Sérülékenységek/Kockázatok A védelmi intézkedések megvalósíthatóságának elemzése A biztonsággal kapcsolatos költség/haszon elemzés elvégzése Biztonsági keretrendszer meghatározása Lényeges biztonsági kérdések és kockázatok A szolgáltatás szint megállapodás (SLA) meghatározása

20 Funkcionális követelmények meghatározása
Biztonsági feladatok a projekttervben Konfigurációkezelés és hozzáférés-védelem a projekt végrehajtása során Nyomon követés Biztonsági követelmények meghatározása A kockázatelemzés alapján védelmi intézkedések meghatározása Előzetes biztonsági tesztelési terv Tesztelési eljárások és erőforrások Értékelési követelményrendszer meghatározása Biztonsági követelmények beépítése a pályázatokba és szerződésekbe Az SLA szerződések tartalmazzák a biztonságot Hardver és szoftver mentések, letétek A funkcionális alapkövetelmények tartalmazzák a biztonságot

21 Rendszertervezés Biztonsági specifikációk meghatározása
Rendszer/alrendszer/interfész Alkalmazás/adatbázis/hardver és firmware/hálózat A biztonsági tesztelési terv frissítése Biztonsági tesztelési eljárások kidolgozása Biztonsági tesztelés abnormális és illegális körülmények között A biztonsági terület beillesztése a formális dokumentációba és a minőségbiztosításba

22 Fejlesztés és dokumentálás
A biztonsággal kapcsolatos kód megírása és beillesztése Hozzáférés-védelem a kódhoz A kód dokumentálása A biztonsággal kapcsolatos kódok tesztelése és értékelése Annak ellenőrzése, hogy a jóváhagyott biztonsági komponensek megvalósultak-e

23 Elfogadás Biztonsági komponensek tesztelése
Biztonsági tesztelés az integrált környezetben A funkcionális működés és teljesítmény felmérése A tesztelési hibák azonosítása A teszteredmények összevetése a biztonsági követelményekkel A biztonsági kód telepítése a szükséges módosításokkal A biztonsági intézkedések dokumentálása A felhasználói útmutatóknak tartalmaznia kell a biztonságos működés feltételeit Elfogadási tesztelés Az utolsó lehetőség a sérülékenységek azonosítására A projekt biztonságosságának elfogadása/megerősítése

24 Telepítés Biztonsági minősítés megszerzése Felhasználók oktatása
A rendszer élesüzemű telepítése

25 Működtetés és fenntartás
Mentési és visszaállítási tesztelések Biztonsági eljárások megfelelőségének ellenőrzése Periodikus kockázatelemzés Újratanúsítás A környezetet érintő változások hatásainak elemzése SLA megállapodások ellenőrzése

26 Áttekintés és kivonás A változások hatásait folyamatosan monitorozni kell Ha a változások olyan hatásokat váltanak ki a rendszerből, hogy azt már nem lehet gazdaságosan/biztonságosan üzemeltetni, akkor ki kell vonni a működésből A kivonásra megfelelő stratégiát kell kidolgozni.

27 Miért kell a Common Criteria?
Biztonsági követelmény rendszer & Felülvizsgálati módszertan Főbb tényezők Nemzetközi IT piaci trendek Közös nemzetközi biztonsági követelmények Számtalan már létező felülvizsgálata IT biztonsági kihívások fokozódása

28 Mi a CC? Nemzetközileg elfogadott keretrendszer az IT biztonság területén Közös struktúra és nyelv a termékek/rendszerek IT biztonsági követelményeinek kifejezésére Szabványos IT biztonsági követelmény összetevők és csomagok gyűjteménye Nemzetközileg elfogadott értékelési módszertan, besorolási rendszer ISO szabvány (ISO/IEC 15408) Elkerülhetetlen

29 CC-t egyezményesen elfogadó államok
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

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

31 Common Criteria – Aktuális állapot
Jelenlegi verzió: CC version 3.1, szeptemberétől (R szeptemberétől) Szabványként elfogadva a CC v. 2.3: ISO/IEC 15408: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

32 Tanúsítványok száma

33 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

34 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

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

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

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

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

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

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

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

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

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

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

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

46 Mi előzi meg a fejlesztést?
A biztonsági követelményeken keresztül a TOE specifikációja Biztonsági célok Funkcionális követelmények A biztonsági követelmények kialakítása Garanciális követelmények TOE összefoglaló specifikáció CC Követelmény katalógus Környezeti követelmények TOE összefoglaló specifikáció: A TOE ST-ben adott összefoglaló specifikációja meghatározza a TOE biztonsági követelményeinek megjelenését. Felsőszintű leírást ad azokról a biztonsági funkciókról, amelyekről kijelentik, hogy teljesítik a funkcionális követelményeket, és azokról a garanciális intézkedésekről, amelyeket a garanciális követelmények teljesítéséhez meg kell hozni..

47 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?

48 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?

49 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?

50 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?

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

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

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

54 Biztonsági Előirányzat

55 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

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

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

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

59 Hogyan olvassuk ki ezt a PP-ből?

60 Hogyan olvassuk ki ezt a PP-ből?

61 Hogyan olvassuk ki ezt a PP-ből?

62 Hogyan olvassuk ki ezt a PP-ből?

63 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ó

64 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ó]) Gyakorlatilag minden olyan dokumentum, amit a biztonságos fejlesztés során felsoroltunk

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

66 Értékelési garanciaszintek

67 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…

68 Melyik garanciaszintet válasszuk?
Az igazi programozók binárisan kódolnak

69 Olvasnivalók Susan Hansche, John Berti, Chris Hare: Official (ISC)2 Guide to the CISSP Exam NIST SP , Security Considerations in the Information System Developement Life Cycle: Common Criteria Portal:

70 Folyamatos fenyegetések/
Összefoglalás Folyamatos fenyegetések/ Védelmi intézkedések Nyílt/zárt forrás Első kockázatelemzés Kockázatelemzés Common Criteria

71 A témához tartozó kérdések
A vagyontárgyak melyikén használna nyílt, és melyiken zárt forráskódú szoftvereket, és miért? Az azonosított vagyontárgyak esetében mekkora kockázatot jelentenek a rosszindulatú kódok, és miért? A szervezetnél használt adatbázisokra a felsorolt fenyegetések közül melyik jelenti a legnagyobb veszélyt, és miért? Egy interjú során tudja meg, hogy a szervezetnél használt üzletileg kritikus alkalmazás fejlesztése során mennyire vették figyelembe az információbiztonságot! Javasolja az alkalmazás változtatását vagy cseréjét? A kérdésekre indoklással legalább egy oldalnyi választ várunk!

72 Köszönöm szépen! krasznay.csaba@kancellar.hu Az előadás letölthető: