Security Workshop pro AV ČR Stanislav Bíža, 10.6.2009 Good morning/afternoon. Thanks for joining me today as we talk about a topic that is critical to the success of every IT organization: an effective data mobility approach. With the addition of Softek offerings to our portfolio, IBM is even more strongly positioned to help you address your needs for moving data within your storage infrastructure. Throughout this presentation, you’ll hear me refer to data mobility and data migration. While migration is typically thought about in the context of moving to new hardware environments (technology refresh), we think of mobility in a wider view. It includes migration as well as moving data within an existing infrastructure, such as for operational improvements or to support other IT initiatives. With that as a background, let’s begin

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

Bezpečnost informačních systémů 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

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

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 hodnoty Ohodnocení 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

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Ú

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

Metrics & measurements 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

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

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.

Analýza rizik Analýza rizik Analáza rizik zahrnuje: identifikaci aktiv Hrozby Aktiva Zranitelnosti 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

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ů

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.

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.

Kombinovaný audit 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 4 Dohledový audit 3

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

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í

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

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)

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)

Elektronický podpis hash

Účastníci PKI

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

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í

Důvody pro zavedení Identity managementu Obvyklé problémy 30%-50% všech volání na podporu se týkají hesla V průměru 25% 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

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

Přiřazení přístupových oprávnění na základě role attr Uživatel Role Služba (Zdroj) Politiky přístupových oprávnění 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

Potvrzení souladu (Rekonciliace) porovnává “Jak to je” s tím “Jak to má být” attr Uživatel Role Služba (Zdroj) Politiky přístupových oprávnění 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

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í Požadavek na aplikaci Y Koncový uživatel přistupuje k aplikacím 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í

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 Uživatelé jsou členy předdefinovaných rolí Požadavek na aplikaci Y 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)

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á

Způsoby řešení Single Sign-On (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 Network OS SSO (Kerberos) 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 Web-based SSO 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 Enterprise Single Sign-On Since there are many forms of SSO, let’s take a look at them so that the differences are clear. Start the positioning to what SSO does (use this slide in conjunction with the Flexible Architecture slide later in the presentation) Network OS SSO, such as Kerberos in Windows 2000, provides some SSO functionality, but it depends on having applications that know how to handle the SSO protocol. Kerberos has been largely confined to some client applications on the Windows desktop, without much support for reusing the same infrastructure to work with other applications. If an application does not support Kerberos, it usually is not a trivial matter to add support, due to modifications required to the application’s authentication code. Web-based SSO is a system for providing SSO functionality to web-based resources using a web access management software package. Web-based SSO requires modifying the web servers with a plugin, or inserting a proxy to change how web resources are accessed. Since only web-based resources can be SSO enabled, the achievable benefits of SSO are limited. Enterprise SSO provides the benefits of SSO to all applications, whether it’s web based, legacy host based, or client/server. It achieves the benefits of SSO without intrusively modifying the original application. Rather, it works by integrating with the user’s desktop login, and supporting applications through a scripting system designed to detect authentication requests.

Stávající přístup k IT systémům a aplikacím – bez SSO Manuální správa hesel Podnikové aplikace Network Login Active Directory Username A Password A Active Directory Username B Password B Printers User Network Domains SAP Purpose: Architect’s perspective – Talk to the issue from the IT Architect/CIO’s perspective Problem: The password problem sneaks up on enterprises, and once it’s manifested, it’s not easy to fix. Solution (introduced on a later slide): desktop-client based Enterprise (as opposed to web-based) SSO Each resource and application is put into production as its own entity, each with its own security domain and administration (as shown by the blue cloud). The local administrators for each system create a set of user names and passwords. That’s the standard way to deploy applications – companies want the software best suited to solve a business need, without necessarily considering how it integrates with other username/password configurations. When you take a look at just how many applications users access, it becomes apparent that there’s a tremendous burden on users just to do their daily job. Each of the applications may have different ownership too. HR may have total ownership over the Peoplesoft deployment. IT may own e-mail and network login, etc, etc. So even making a strategic decision to fix the problem on behalf of users introduces a major technical and political hurdle. Getting political buy-in from each department owner to modify password/authentication system on production systems is nearly impossible, even if the result would save users a lot of aggravation. What is needed is a new way to look at how to simplify the user experience, provide single sign on across all enterprise applications, centrally enforce stronger security and password policies, yet avoid disrupting the working elements yet without disturbing the security policies of existing systems. Username C Password C File Shares Web App Web App Username D Password D

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

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) 2) Launch Application 1) Authenticate to Dir Client Workstation

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

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

Komponenty bezpečnostní architektury As mentioned previously, the Security Subsystems and Components within Security Subsystems have been mapped to the e-business reference architecture, and are included in the OPS 316 Security Architecture sample workproduct.

Příklad bezpečnostní architektury