©2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice ©2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice AZ ALKALMAZÁSBIZTONSÁG SZABÁLYAI Előírások az IT biztonsági szabványokban Krasznay Csaba CISA, CISM, CISSP, CEH

• Az alkalmazások biztonságos fejlesztése egy méltatlanul háttérbe szorított terület az információbiztonságon belül • Ennek ellenére minden jelentősebb biztonsági szabványban, jogszabályban szerepel, mint követelmény • Előadásomban bemutatom a szabályozó követelményeket az alábbi szabványokban: – PCI DSS – FISMA (csak azért, hogy lássuk, milyen követelményeket kéne a közigazgatásnak szabnia) – CObIT – ISO • A magyar jogszabályi környezet a Common Criteria-ra épít ezen a területen, így erről is beszélni kell pár szót! Bevezetés 2HP Confidential

Pénzintézetek •PSZÁF •PCI DSS •COBIT Közigazgatás •KIB 25. és 28. ajánlás •Új rendeletek? Tanúsításkötelezett területek (CC) •Elektronikus aláírás •Nyerőautomaták Appsec követelmények hazánkban 3HP Confidential

Projektindítás és tervezés Funkcionális követelmények meghatározása Rendszertervezés Fejlesztés és dokumentálás ElfogadásTelepítés Üzemeltetés és fenntartás Átvizsgálás és kivonás Biztonságos alkalmazásfejlesztés folyamata 4HP Confidential Nincs konkrét követelmény Általában kiolvasható Nincs konkrét követelmény Tanúsítás Nincs konkrét követelmény LEGYEN!

• Requirement 6: Develop and maintain secure systems and applications – 6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release. -> Üzemeltetési fázis – 6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. -> Projektindítási és tervezési fázis, üzemeltetési fázis – 6.3 Develop software applications (internal and external, and including web-based administrative access to applications) in accordance with PCI DSS (for example, secure authentication and logging), and based on industry best practices. Incorporate information security throughout the software development life cycle. -> Funkcionális követelmények meghatározásának fázisa – 6.4 Follow change control processes and procedures for all changes to system components. -> Fejlesztés és dokumentálás fázisa – 6.5 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes. -> Fejlesztés és dokumentálás fázisa – 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks -> Elfogadási fázis PCI DSS 5HP Confidential

FISMA 6HP Confidential

CObIT 7HP Confidential

ISO HP Confidential

Sebezhetőség-vizsgálati módszerek 9HP Confidential

• PCI DSS – 6.5 követelmény, OWASP útmutatói alapján kell fejleszteni és ezeket mintavételes módszerrel kell ellenőrizni (biztonsági funkcionális tesztelés) – 6.6 követelmény, manuális vagy automatikus módszerrel (sérülékenység-vizsgálat) legalább évente vagy minden változás után, egy erre specializálódott szervezettel (belső vagy külső) teszteltetni kell • FISMA – RA-5 követelmény, az automatikus eszközökkel végrehajtott tesztelést preferálja, melynek eredményeit egységes formájú jelentésben kell bemutatni – A külső értékelő által végzett, akár komplex vizsgálat (behatolás-tesztelés) nem kötelező elem, de ajánlott teszteljárásként fel van tűntetve • CObIT – DS5.5 Security Testing, Surveillance and Monitoring részben javasolja az informatikai rendszerek rendszeres biztonsági tesztelését, ám ennek módját nem jelzi • ISO – 12.6 követelmény, a szervezetnek bizonyos időközönként fel kell mérnie rendszerének technikai sebezhetőségeit, és megfelelő védelmi intézkedésekkel csökkenteni kell az ezekből eredő kockázatokat, de ennek módját nem adja meg Sebezhetőség-vizsgálat a szabványokban 10HP Confidential

• 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 a fejlesztési folyamatokra • Nemzetközileg elfogadott értékelési módszertan, besorolási rendszer • ISO szabvány (ISO/IEC 15408) • A szoftverfejlesztés biztonságának elfogadott módszertana (annak minden kritikájával együtt) Mi 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 (ISO/IEC 18045) Mit 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 Mit nem fed le a Common Criteria

• 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. Common Evaluation Methodology (CEM )

Biztonsági cél: Szándéknyilatkozat azonosított fenyegetések elleni fellépésről és/vagy meghatározott szervezeti biztonsági szabályzatoknak és feltételezéseknek való megfelelésről. A biztonsági célok kialakítása Védendő vagyontárgyak TOE célja A biztonsági környezet kialakítása Biztonsági célok TOE Fizikai környezet Feltétele-zések Fenyege- tések Szervezet- biztonsági Szabályok Mi előzi meg a fejlesztést?

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

• 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 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 ADV: Fejlesztés • Class AGD: Útmutató dokumentumok • Class ALC: Az életciklus támogatása CC garanciális követelmény-osztályok • Class ATE: Vizsgálatok (tesztek) • Class AVA: A sebezhetőség felmérése • Class ACO: Kompozíció

• 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ó]) Mik is a garanciális követelmények?

• 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. Értékelési garanciaszintek

• Bármelyik megfelelőségi követelményt nézzük, a biztonságos alkalmazásfejlesztés alapvető követelmény. • A gyakorlatban az általánosan elfogadott szoftverfejlesztési elvek betartása mellett a biztonságot megvalósítani nem rendkívüli követelmény. • Jelenleg a sikeres informatikai támadások túlnyomó többsége még mindig a hanyag üzemeltetés miatt következik be, de az elmúlt években feltörekvő trend lett az alkalmazáshibák kihasználása. • De a nem megfelelően biztonságos alkalmazás is alapvetően hanyagságnak minősül!!! Összefoglalás 22HP Confidential

KÖSZÖNÖM A FIGYELMET! Telefon: Web: