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

IBM Global Technology Services

© Copyright IBM Corporation 2009

Security Workshop pro AV ČR Stanislav 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



Bezpečnost informačních systémů

Technologie

Procesy

Data / Aplikace

Fyzická zařízení / Prostory

Organizace

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

Resilient Solutions

4



Dopady bezpečnostního incidentu

Bezp. incident

Finanční dopad incidentu

Obnova funkčnosti

Řešení bezpečnosti Poškození

pověsti

5



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 = majitelVlastní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

Informační aktiva a bezpečnost

6



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

7



Vnější požadavky na řešení bezpečnosti

o 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“)

o 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)27001 ISMS - Requirements (BS7799-2) 27002 Code of practice for information security management 27002 Code of practice for information security management

(ISO/IEC17799)(ISO/IEC17799) 27003 ISMS Risk Management27003 ISMS Risk Management 27004 ISMS Metrics & measurements27004 ISMS Metrics & measurements 27005 ISMS Implementation guidance27005 ISMS Implementation guidance 27006 Guidelines in ISMS Accreditation27006 Guidelines in ISMS Accreditation 27007 Guidelines for ISMS Auditing27007 Guidelines for ISMS Auditing

27001Requirements

27002Code of Practice

27003Risk

Management

27005Implementation

Guidance

27004Metrics &

measurements

9



Postup projektů bezpečnosti

Bezpečnostní standardyHrozby Aktiva Zranitelnost

i

RizikaAnalýza rizik

Analytické

fázeR

ealizační fázeBezpečnostní projekt(y)

Bezpečnostní Konzultace

Managerskérozhodnutí

Celková bezp. politika

Cíle a strategie bezpečnosti

Úvodní bezp. audit

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



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

Hrozby Aktiva Zranitelnosti

RizikaAnalýza rizik

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ěrniceo 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:

o zajištění stability provozu systému IS;

o 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ů);

o zajištění korektních postupů při obnově obnovy funkčnosti činností a procesů systému IS;

o minimalizace rizik pro případ nedostupnosti systému IS;

o zajištění spolehlivosti záložních systémů;

o minimalizace rozhodovacích časů v průběhu havárie IS;

o 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ě)

Vydání certifikátu

Kombinovaný audit

Dohledový audit 1Dohledový audit 2

Dohledový audit 3Dohledový audit 4

Dohledový audit 5

Re-certifikace

UzavřeníDoporučení

Významné neshody

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.

o V současné době jsou rozšířeny dva typy kryptografických algoritmů: šifrování symetrickými a asymetrickými klíči

o Š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

o Š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

o 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)

o 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



o 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

o 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)

Bezpečnostní funkce, které je možno implementovat použitím PKI

21



Elektronický podpis

1. Šifruje "výtah" (hash) zprávy svým privátním klíčem a přikládá jej ke zprávě.

2.Dekryptuje "výtah" zprávy veřejným klíčem Alice, ověřuje platnost elektronického podpisu.

HonzaAlice

Veřejný klíč Alice (obsažen v certifikátu)

Veřejný klíč Alice

Privátní klíč Alice

"Ahoj Honzo..."

Elektronický podpis

Umožňuje ověření integrity dokumentuImplementace "neodmítnutelnosti odpovědnosti"Při dodržení podmínek dle zákona č. 227/2000 Sb. právně platný

hash

22



Účastníci PKI

Bezpečnostní službyDůvěrnostIntegritaSilná autentizaceNeodmítnutelnost odpovědnosti

Koncové entity (uživatelé, aplikace)dodržují politikyvyužívají kryptografické služby

Adresářové službyDistribuce certifikátůDistribuce Seznamu zneplatněných certifikátů (CRL)

Certifikační AutoritaStanoví politiky, procesy a jejich kontroluVydává certifikátyUdržuje záznamy

Certificate Status Responder (opt)Distribuce aktuálního statusu certifikátů

23



S/MIMEDvoustranná autentizacePodepsané dokumenty

Secure Sockets Layer (SSL)Klient & server autentizaceŠifrování komunikace

webbrowser

mailer

mailer

webserver

webserver

webbrowser

Podepsané apletyZabezpečený SW pro download

klient vzdáleného

přístupu

IPSecZabezpečená IP komunikace

firewall

firewall

IPSecZabezpečená IP

komunikace

wordprocessor

časová razítkaDatabase

Elektronicky podepsané dokumenty

Zákaznické aplikaceVyvíjeny za pomoci PKI toolkitů

Každá aplikace, která má PKI využívat, musí integrovat kryptografické Každá aplikace, která má PKI využívat, musí integrovat kryptografické algoritmy pro ověřování digitálních certifikátů, šifrování a operace algoritmy pro ověřování digitálních certifikátů, šifrování a operace elektronického podpisu.elektronického podpisu.

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

Subjekt

Certifikační autoritaCertifikát subjektu

Subject

Subject Public Key

GenerateDigital

SignatureGenerateHash

Certification Authority'sPrivate Key

Signed certificate

Issuer

Issuer'sSignature Algorithm

Žádost o vydání certifikátu

Subject

Subject Public Key

Politiky Operace s certifikáty

Registrační autoritaOvěřuje požadavky na vydání certifikátuPostupuje ověřené žádosti k CA

25



Adresářová služba

PKI zpravidla umožňuje ověření, zda certifikát nebyl revokován, PKI zpravidla umožňuje ověření, zda certifikát nebyl revokován, distribucí CRL (Certificate Revocation List)distribucí CRL (Certificate Revocation List)

Třetí stranaObdrží CRLOdmítne certifikát, jestliže je na CRL

Certifikační autorita

Držitel certifikátu

Subjekt požaduje revokaci certifikátu

certificaterevocationlist

Certificate Revocation List (CRL)Sériová čísla revokovaných certifikátůDatum+čas revokaceDůvod revokace (volitelný)ID vydavatele CRL (CA)Datum+čas vydání CRLDatum+čas vydání následujícího CRL

Požadavky na dostupnost CA:

24×7

Typy CRL:Úplný CRLDelta CRLČástečný CRL/ Distribuční body

On-line Certificate Status Responder

26



Autentizační předmět – čipová kartao Karta obsahuje digitální certifikát

uživatele dle stand. X.509

o 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á

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

čipová kartačipová karta

CPU

ROM

Sériový I/O

RAM

EEPROM

Kryptoprocesor

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

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



Přiřazení přístupových oprávnění na základě role

Politikypřístupových

oprávněníSlužba(Zdroj)Uživatel Role

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

attr

30



Potvrzení souladu (Rekonciliace) porovnává “Jak to je” s tím “Jak to má být”

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

Politikypřístupových

oprávněníSlužba(Zdroj)Uživatel Role

attr

Rekonciliace

31



Přidělování přístupů bez Identity Managementu

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í

Manažer zkontroluje dokončení požadovaných operací a uvědomí uživatele

Systémoví administrátoři vytvoří uživatelské účty, nastaví oprávnění a pošlou zprávu o dokončení

Koncový uživatel přistupuje k aplikacím

Požadavek na aplikaci X

Požadavek na aplikaci Y

Požadavek na aplikaci Z

AuditRecord

AuditRecord

AuditRecord

Admin X

Admin Y

Admin Z User Provisioning

Zpráva o dokončení

- - - Obvykle manuální proces - - -

32



Přidělování přístupů s použitím IM

Požadavek na aplikaci X

Požadavek na aplikaci Y

Požadavek na aplikaci Z

AuditRecord

AuditRecord

AuditRecord

Admin X

Admin Y

Admin Z User Provisioning

CompletionNotificationAutomatizovaný 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

Uživatelé jsou členy

předdefinovaných rolí

Trvání – řádově minuty až desítky minut (pro systémy offline)

- - - Automatizovaný proces - - -

Koncový uživatel přistupuje k aplikacím

33



Přínosy zavedení Identity Managementu a RBAC

o Jednotný administrativní proces napříč organizací /aplikacemi / platformami

o Jednotné prosazování bezpečnostních politik napříč organizací

o Jednodušší a lépe dokladovatelný audit (centralizované vytváření auditních záznamů o přidělování přístupových oprávnění)

o Změna postavení IT auditu: Reaktivní -> Proaktivní (rekonciliace)

o Jednodušší implementace organizačních změn

o Automatizace rutinních úloh

o Redukce celkových nákladů na administraci uživatelů

o 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

o Ř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



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

35



Stávající přístup k IT systémům a aplikacím – bez SSONetwork Login

Podnikové aplikace

WebApp Web

App

UserSAP

ActiveDirectory

Active Directory

Username APassword A

Manuální správa hesel

Username BPassword B

Username CPassword C

Username DPassword D

File Shares

Printers

Network Domains

36



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

uživatel

Client- Single Sign-On- Password Mgmnt

Synchronization- Policy- Configuration- SSO data- User Data

LDAPDirectory

- Identity Storage- Credential Bank- Policy Storage

SSO service

Desktop

Server

Nástroje na administraci

- User Mgmnt- Policy Mgmnt- Configuration Mg.- Customization

Aplikace

- Windows appl.- Client-Server- Terminal Emulator- Enterpise SW- Web Browser- Email Client

37



SSO - Proces přihlašování do aplikací

ApplicationApplicationServerServer

DirectoryDirectorynebo nebo

lokální úložiště (off-line)lokální úložiště (off-line)

ClientClientWorkstationWorkstation

4) SSORequest

s Secret from Dir

2) Launch Application

3) Credential Challenge

1) Authenticate to Dir

5) SSO Receives Secret (ID/PWD) from

Dir, then authenticates to

Application

38



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

[email protected]

40



Komponenty bezpečnostní architektury

Credential

Ent

erpr

ise

secu

rity

arch

itect

ure

Trusted

FlowControl

SecurityAudit

Subsystem

AccessControl

SolutionIntegrity

ControlleddomainBoundary Intra-domain

transferfunctions

ClosedCommunity

VPNGateway

VPNGateway

Intra-domaintransferfunction(s)

ExternaldomainBoundary

RestricteddomainBoundary

Secure domainBoundary

Privacy

???Attachment

???Community

external controlled controlled restricted secureduncontrolled

RemoteAccessGateway

RemoteService

RemoteClient

Special Purposegateway(s)

Systemenvironment

SecuredClient(s)

RestrictedClient(s)

RestrictedService(s)

Apps

SecuredService(s)

AppsApps

IntranetSingle

Sign-On

AppsPublic services

Apps

to SolutionIntegrity componentsand management processes

Intra-domaintransfer function(s)

Privacy

Portal SingleSignon

Apps

Static Attachment

ManagedCommunity

ManagedCommunity

Static Attachment

Managed Attachment

OtherPKI

userid / pswdSSO

Security tokenSecure email

Digital Sig

Persistent credentials Transient credentials

AuthorizationsCredentialCreation

AuthorizationsCredentialDistribution

AuthorizationsCredentialStorage

User/Groupenrollment

User/GroupData

validation

AuthorizationsCredentialCreation

AuthorizationsCredentialDistribution

AuthorizationsCredentialStorage

User/Groupenrollment

User/GroupData

validation

Event Log Analysis

Event Reporting

Event Alerting

FirewallEvent

LoggingSystemLogging

WebLogging

ApplicationLogging

VoiceEvent

Logging

PhysicalEvent

LoggingPrivacyLogging

NetworkMonitoringSensors

WorkstationMonitoring

Agents

Real-TimeSecurity

Monitoring

SystemMonitoringSensors

User / systemAdmin

Service Management

Fault Management

Continuity measures

Trusted Time

TestsPhysicalprotections

Recovery measures

Logical Protections

Subsystem

Subsystem

Subsystem

Subsystem

41



Příklad bezpečnostní architektury

Documents

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