Alkalmazásfejlesztés biztonsága

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. http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use • 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

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. http://en.wikipedia.org/wiki/Polyinstantiation • 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. http://en.wikipedia.org/wiki/Deadlock • 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. http://en.wikipedia.org/wiki/Database_view • 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ő. http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29

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. http://en.wikipedia.org/wiki/Sql_injection • 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. http://en.wikipedia.org/wiki/Denial_of_service

17. Olvasnivaló • Ken Thompson: Reflections on Trusting Trust. http://www.acm.org/classics/sep95/ • US-CERT Cyber Security Bulletin. http://www.us-cert.gov/cas/bulletins/SB2005.html#UnixLinux • Vírusok: http://en.wikipedia.org/wiki/Computer_virus • Férgek: http://en.wikipedia.org/wiki/Computer_worm • Tórjaiak: http://en.wikipedia.org/wiki/Trojan_Horse_%28Computing%29

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

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 • 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 • 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

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

31. Common Criteria–Aktuális állapot • Jelenlegi verzió: • CC version 3.1, 2006. szeptemberétől (R2 2007. szeptemberétől) • Szabványként elfogadva a CC v. 2.3: • ISO/IEC 15408:2005, 2005. szeptembere óta. • Jövő: • 2008. szeptemberben 875 tanúsított termék volt, csak 2008-ban 70 termék kapott tanúsítást, csak az USA-ban 87 termék állt tanúsítás alatt  egyre nagyobb a vásárlói igény a biztonságos termékekre, ezért egyre több termék pályázik a CC minősítésre

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ényeinekaz ö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. TOE célja 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 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 Garanciális követelmények A biztonsági követelmények kialakítása 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?