Security Workshop pro AV ČR Stanislav Bíža, 10.6.2009

1. Security Workshop pro AV ČRStanislav Bíža, 10.6.2009

2. Agenda - Důvody pro budování informační bezpečnosti - Sled bezpečnostních projektů: - Vypracování strategie řízení bezpečnosti IT - Analýza rizik - Bezpečnostní politika - Bezpečnotní směrnice pro administrátory a uživatele - Havarijní plány a plány obnovy - Bezpečnostní audit; příprava na akreditaci ISMS - Návrh a implementace ucelených bezpečnostních řešení: - Infrastruktura veřejných klíčů - PKI - Identity & Access Management - Single Sign-On

3. Resilient Solutions Bezpečnost informačních systémů Strategie Vypracování strategie řízení bezpečnosti IT Vypracování bezpečnostních politik a standardů Vypracování analýzy rizik Bezpečnostní audit IT/certifikace podle ISO 27000 Návrh bezpečnostní architektury IT systémů Vybudování infrastruktury veřejných klíčů (PKI) Identity management / Access Management Systémy detekce útoků IDS/IPS Bezpečné připojení k Internetu – DMZ, FW, VPN ... Řízení přístupu k interním sítím - LAN, WLAN Penetrační testy – interní & externí Zabezpečení datových center Organizace Procesy Data / Aplikace Technologie Fyzická zařízení / Prostory

4. Dopady bezpečnostního incidentu Finanční dopad incidentu Obnova funkčnosti Řešení bezpečnosti Poškození pověsti Bezp. incident

5. Informační aktiva a bezpečnost • Informace je nehmotné aktivum, které má svoji hodnotu (např. vyčíslitelnou finančně) • Ztráta informace = ztráta této hodnotyOhodnocení informace (přiřazení ceny ke každé konkrétní informaci) musí pořídit vlastník = majitel • Vlastník = majitel - zodpovídá za bezpečnost a rozhoduje o nakládání s informací • Bezpečnost IT musí zajistit: • důvěrnost informací, • integritu (celistvost), • dostupnost (dosažitelnost), • auditovatelnost (kdo a kdy s informací manipuloval, prokazatelnost) • neodmítnutelnost odpovědnosti

6. Vnější požadavky na řešení bezpečnosti • Legislativní tlaky (ochrana dat klientů a obchodních partnerů) • Zákon č. 101/2000 Sb. o ochraně osobních údajů • Zákoník obchodní (obchodní tajemství) • Zákon č. 148/1998 Sb. O ochraně utajovaných skutečností • Zákon č. 227/2000 Sb. (366/2001 Sb.) o elektronickém podpisu • Vyhlášky ÚOOÚ • Vyhlášky NBÚ

7. Vnější požadavky na řešení bezpečnosti • Standardy: • ISO27000 (ISO 17799) – Code of Practice for Information Security Mngmnt • ČSN ISO/IEC 13335 – Management of information and communications technology security • ČSN ISO/IEC 15408 – Evaluation Criteria for IT Security • Standardy ISMS („INFORMATION SECURITY MANAGEMENT SYSTEM“) • Požadavky vyplývající z přijímání mezinár. standardů a legislativy: • Basel II. • Sarbanes-Oxley

8. Standardy ISO 27000 • 27001 ISMS - Requirements (BS7799-2) • 27002 Code of practice for information security management (ISO/IEC17799) • 27003 ISMS Risk Management • 27004 ISMS Metrics & measurements • 27005 ISMS Implementation guidance • 27006 Guidelines in ISMS Accreditation • 27007 Guidelines for ISMS Auditing 27001 Requirements 27002 Code of Practice 27003 Risk Management 27004 Metrics & measurements 27005 Implementation Guidance

9. Hrozby Aktiva Rizika Bezpečnostní standardy Celková bezp. politika Cíle a strategie bezpečnosti Úvodní bezp. audit Managerské rozhodnutí Postup projektů bezpečnosti Analytické fáze Zranitelnosti Analýza rizik Realizační fáze Bezpečnostní projekt(y) Bezpečnostní Konzultace

10. Cíle a strategie řešení bezpečnosti IS Obecný cíl: Eliminovat přímé i nepřímé ztráty způsobené zneužitím, poškozením, zničením, nedostupností informací…vytvoření uceleného, nákladově akceptovatelného systému řízení bezpečnosti informací…. Definice cílů by měla zahrnovat i: • Vymezení hranic řešení • Investiční možnosti • Omezení z pohledu dislokace atd. • Řešení aktuálních problémů (priority praxe) • atd.

11. Zranitelnosti Analýza rizik Hrozby Aktiva Rizika Analýza rizik Analáza rizik zahrnuje: • identifikaci aktiv • identifikaci hrozeb • ohodnocení aktiv • určení pravděpodobnosti uplatnění hrozby • určení zranitelnosti každého aktiva hrozbou • výpočet hodnoty Riziko pro každou dvojici aktiva a hrozby

12. Bezpečnostní politika • Základní dokument (resp. jeho aplikace) řešení informační bezpečnosti • Závazná pro celou společnost • Většinou součást dokumentace ISO900x či jiných systémů řízení kvality, součást požadavků NBÚ • Rozdílný rozsah • Předmětem dokumentu je: • Definovat hlavní cíle při ochraně informací • Stanovit způsob, jak bezpečnost řešit • Určit pravomoci a zodpovědnosti • Nezávislost na technologiích Může nastat konflikt bezpečnostních a obchodních cílů

13. Bezpečnostní provozní směrnice • Příklad struktury směrnic: • BPS pro správu - Směrnice popisuje pravidla pro správu IS, řízení změn a řízení přístupu v rámci IS. Definuje základní společná pravidla pro centralizované řízení přístupu uživatelů k informačním aktivům, aplikacím, službám a datům. • BPS pro klasifikaci informací a dat - Směrnice upravuje základní odpovědnosti pro zajištění adekvátní ochrany informací a stanovuje pravidla pro určení klasifikačního stupně, pravidla pro označování a další nakládání s informacemi, které jsou zpracovávány a uchovávány v rámci IS. • BPS pro zvládání bezpečnostních incidentů • BPS pro použití síťových služeb - Směrnice definuje pravidla pro použití sítí a síťových služeb, ke kterým je uživatelům povolen přístup. Určuje autorizační postupy pro přístup, stanovuje řídící kontrolní mechanizmy a postupy určené k ochraně přístupu k síťovým připojením a službám; • BPS pro zálohování a kontrolu médií - Směrnice popisuje základní pravidla pro bezpečné ukládání, manipulaci, zálohování a archivaci dat, která jsou zpracovávána a uchovávána v rámci provozu všech subsystémů a aplikací IS.

14. Havarijní plánování Proces havarijního plánování systému IS sleduje následující cíle: • zajištění stability provozu systému IS; • zajištění dostupnosti všech zdrojů potřebných pro obnovu činností a procesů systému IS v požadovaném čase a na požadovanou úroveň (konkrétní požadavky identifikuje analýza dopadů); • zajištění korektních postupů při obnově obnovy funkčnosti činností a procesů systému IS; • minimalizace rizik pro případ nedostupnosti systému IS; • zajištění spolehlivosti záložních systémů; • minimalizace rozhodovacích časů v průběhu havárie IS; • zajištění zvýšeného bezpečnostního povědomí všech pracovníků podílejících se na provozu IS.

15. Certifikace systémů Předcertifikační audit (volitelný, dobrovolný) Fáze 1 (Přezkoumání dokumentace) Fáze 2 (Audit na místě) Významné neshody Re-certifikace Doporučení Vydání certifikátu Uzavření Dohledový audit 1 Dohledový audit 5 Dohledový audit 2 Kombinovaný audit Dohledový audit 3 Dohledový audit 4

16. Certifikační audit – 1 fáze Fáze 1 (Přezkoumání dokumentace) • Cca. 1 měsíc před druhou fází • Zahrnuje: • Revize rozsah ISMS • Kompletnost požadované dokumentace • Revize Statement of Applicability • Existence a úplnost bezpečnostní politiky a bezpečnostních standardů • Existence záznamů ISMS

17. Certifikační audit – 2 fáze Fáze 2 (Audit na místě) • Zahrnuje: • Interview s managementem • Interview s vlastníky a uživateli ISMS • Revize shody dokumentace s implementovaným systémem • Revize jednotlivých částí systému • Report jednotlivých zjištění • Vypracování zprávy včetně doporučení

18. PKI- Symetrická vs. asymetrická krypt. • V současné době jsou rozšířeny dva typy kryptografických algoritmů: šifrování symetrickými a asymetrickými klíči • Šifrování symetrickým klíčem • Stejný klíč pro šifrování a dešifrování • Rychlejší, než asymetrické šifrování • Problematické zajištění distribuce klíčů • nejčastěji používané: DES (3DDES), AES, RC4 • Šifrování asymetrickými klíči • Pár klíčů: Veřejný a Privátní • Pomalejší, než symetrické šifrování • Veřejný klíč může být posílán bez nebezpečí ohrožení privátního klíče • Základní algoritmus PKI • nejčastěji používané: RSA, DSA

19. Bezpečnostní funkce, které je možno implementovat použitím PKI • Autentizace • pomocí digitálního certifikátu, vydaného důvěryhodnou třetí stranou (CA), prokazuje uživatel svoji totožnost při el. komunikaci s jiným uživatelem nebo aplikací (serverem) • Důvěrnost (šifrování) • autentizace certifikátem zamezuje průniku útočníka („man in the middle“) do šifrované komunikace • použití certifikátu (resp. veřejného klíče) příjemce umožňuje šifrovat zprávu pouze pro příjemce (vlastníka privátního klíče)

20. Bezpečnostní funkce, které je možno implementovat použitím PKI • Integrita (elektronický podpis) • použití výtahu (hash) zprávy spolu s elektronickým podpisem odesilatele umožňuje ověřit, zda zpráva nebyla po provedení el. podpisu změněna • Neodmítnutelnost odpovědnosti (elektronický podpis) • jako jediná technologie umožňuje elektronický podpis zpětně prokázat původce (držitele privátního klíče) el. podepsaného dokumentu a zajistit tak neodmítnutelnost pravosti dokumentu, resp. neodmítnutelnost provedené operace (např. v aplikaci)

21. Elektronický podpis hash

22. Účastníci PKI

24. Hlavní rolí Certifikační autority je stanovení politik a vydávání digitálních certifikátů.Certifikační autorita může delegovat odpovědnost za ověřování žádostí o certifikát a/nebo revokaci na RA

26. Autentizační předmět – čipová karta • Karta obsahuje digitální certifikát uživatele dle stand. X.509 • Karta obsahuje privátní klíč • Klíč a celá karta chráněny heslem • Karta může provést digitální podpis privátním klíčem, ale klíč nevydá • Přístup do aplikací je pro konkrétní certifikát - certifikát má pracovník jen jeden, ale může používat více aplikací

27. Důvody pro zavedení Identity managementu Obvyklé problémy • 30%-50% všech volání na podporu se týkají hesla • V průměru25% uživatelských účtů jsou sirotci • 95% uživatelů má příliš mnoho přístupových práv nebo zcela zbytečná práva • Noví zaměstnanci a externí subjekty nemají uživatelské účty první pracovní den • Bývalí zaměstnanci neztratí nikdy přístup

28. Identity Management a podpora procesů Identity Management řeší následující úkoly: • Přidělení přístupových práv ke službám (zdrojům) • Je každý uživatelský přístup k danému zdroji oprávněný? • Jsou přístupy uživatele ke všem zdrojům nastaveny korektně? • Jsou v souladu politiky se skutečným stavem? • Produktivita • Je způsob přidělování a změn přístupových práv uživatelům efektivní? • Přístupy • Jsou politiky přístupových oprávnění a ochrany senzitivních informací implementovány konzistentně v každém operačním systému, aplikaci, a datovém úložišti? • Audit • Je možno efektivním způsobem dokladovat plnění politik přístupových oprávnění a ochrany senzitivních informací?

29. Politiky přístupových oprávnění Služba (Zdroj) Uživatel Role Přiřazení přístupových oprávnění na základě role attr Uživateli jsou přiřazeny role na základě jeho pracovního zařazení Rolím jsou přiřazeny zdroje na základě Politik přístupových oprávnění (Provisioning policy) Politiky přístupových oprávněnímohou přiřazovat uživatelům další atributy

30. Politiky přístupových oprávnění Služba (Zdroj) Uživatel Role Potvrzení souladu (Rekonciliace)porovnává “Jak to je” s tím “Jak to má být” attr Rekonciliace • Na základě rekonciliace jsou prosazovány Politiky přístupových oprávnění (oprávnění ke zdroji) • Např. zjištění neoprávněných změn provedených lokálním administrátorem a jejich náprava. • Rekonciliace zjišťuje „sirotčí účty“ • Např. testovací účty nebo účty uživatelů, kteří již nejsou v organizaci

31. Přidělování přístupů bez Identity Managementu - - - Obvykle manuální proces - - - Požadavek na aplikaci X Admin X Zpráva o dokončení Koncový uživatel přistupuje k aplikacím Požadavek na aplikaci Y Manažer uživatele určí, ke kterým aplikacím potřebuje uživatel přístup a ke každé aplikaci zvlášť požádá o nastavení přístupových oprávnění Admin Y Manažer zkontroluje dokončení požadovaných operací a uvědomí uživatele Požadavek na aplikaci Z User Provisioning Admin Z Audit Record Audit Record Audit Record Systémoví administrátoři vytvoří uživatelské účty, nastaví oprávnění a pošlou zprávu o dokončení

32. Přidělování přístupů s použitím IM - - - Automatizovaný proces - - - Požadavek na aplikaci X Admin X Completion Notification Automatizovaný Identity Life Cycle Management Automatizované přidělení přístupů na základě rolí Automatizované schvalování, Workflow, and notifikace Centralizovaný audit a reportovací nástroje Koncový uživatel přistupuje k aplikacím Požadavek na aplikaci Y Uživatelé jsou členy předdefinovaných rolí Admin Y Požadavek na aplikaci Z User Provisioning Admin Z Audit Record Audit Record Audit Record Trvání – řádově minuty až desítky minut (pro systémy offline)

33. Přínosy zavedení Identity Managementu a RBAC • Jednotný administrativní proces napříč organizací /aplikacemi / platformami • Jednotné prosazování bezpečnostních politik napříč organizací • Jednodušší a lépe dokladovatelný audit (centralizované vytváření auditních záznamů o přidělování přístupových oprávnění) • Změna postavení IT auditu: Reaktivní -> Proaktivní (rekonciliace) • Jednodušší implementace organizačních změn • Automatizace rutinních úloh • Redukce celkových nákladů na administraci uživatelů • Přehlednější systém přístupových oprávnění znamená méně bezpečnostních rizik -> uživatelé mají pouze taková oprávnění ke službám a datovým zdrojům, které potřebují ke své práci • Řešení problémů se „sirotčími“ účty, tzn. účty, které kdysi byly pro uživatele zavedeny a v současné době je již žádný oprávněný uživatel nepoužívá

34. Network OS SSO (Kerberos) Web-based SSO • Provided by certain NOS environments • SSO functionality only for applications enabled to use it. • Applications which do not support Kerberos have to rewrite authentication mechanism in order to support it • Provided by web access management • Only supports web-based resources • Requires modification of servers or proxies in order to support it. May require changes to application code as well Enterprise Single Sign-On • Provided by Desktop/Server software • Based on authentication and leveraging a protected credential bank • Can support any application – web, terminal host, client/server • Does not modify the original application • New applications supported through scripts to automate the login process, customized for specific situations and requirements Způsoby řešení Single Sign-On (SSO)

35. Active Directory Network Domains Printers File Shares SAP Web App Web App Stávající přístup k IT systémům a aplikacím – bez SSO Manuálníspráva hesel Podnikové aplikace Network Login Username A Password A Active Directory Username B Password B User Username C Password C Username D Password D

36. Přihlašování se Single Sign-On

37. SSO - Proces přihlašování do aplikací 5) SSO Receives Secret (ID/PWD) from Dir, then authenticates to Application 4)SSORequests Secret from Dir 3) Credential Challenge Application Server Directory nebo lokální úložiště (off-line) 1) Authenticate to Dir 2) Launch Application Client Workstation

38. SSO – Zvýšení bezpečnosti a komfortu uživatelů (!) • Řešení umožňuje aplikovatsilnou politiku přístupových heselpro každou aplikaci • Umožňuje zavést i pro aplikace, které nemají politiku přístupových hesel implementovánu ! • Uživatelé si musí pamatovat pouzejedno heslo,což znamená, že můžete implementovat silnou politiku pro přihlašovací hesla • SSO může být nakonfigurováno tak, že implementujesilnou autentizaci do všech využívaných aplikací • SSO může být nakonfigurováno tak, žeuživatelé neznají jejich UserID a heslodo aplikací

39. Děkuji za pozornost Ing. Stanislav Bíža Senior IT Architekt, CISA stanislav_biza@cz.ibm.com

40. Komponenty bezpečnostní architektury

41. Příklad bezpečnostní architektury