Audyt DB2 w czasie rzeczywistym

IBM Guardium

Zbigniew Szmigiero (CTP IBM Security Systems)

Dlaczego chronimy dane w DB2?

• Ochrona przed:– Fraudami– Wyciekiem

Wyzwania w ochronie DB2

• Heterogeniczność!• Audytowalność a Identyfikacja incydentów• Spójność ochrony

Ochrona przed wyciekiem

• Wyciek poprzez zapytanie• Wyciek poprzez dostęp do plików• Wyciek poprzez dostęp do archiwów• Wyciek ze środowisk preprodukcyjnych

…as are threats from outside the enterprise…..

DECSpam

MorrisWorm

Mafiaboy

Iloveyou

TJX

Estonia

Georgia

1980 1985 1990 1995 2000 2005 2010

Aurora

Stuxnet

Co

mp

lexi

ty /

So

ph

isti

cati

on

/

Bu

sin

ess

Imp

act

/ N

ati

on

al i

mp

act

1978 – first

spam incident hits 393 users

1988 – first

Internet worm

2000 – DoS attacks on

Yahoo, eBay, CNN, Amazon

& Dell

2000 – Worm + Social Engineering. Spreads WW in 1 day. ~50M infections, $5.5B in

damage. 2005/6 – Hackers

compromise ~45M credit / debit cards

2007 – DDoS attacks during

row with Russia target

critical infrastructure

2008 – Cyber attacks

coordinated with “real” invasion

2009 – “Advanced Persistent Threat” for industrial espionage

2010 – Military grade op targets SCADA gear in

Iran

SCRIPT KIDDIES

AMATEUR GROUPS

SEMI-PROS

BLACKHATS

INDUSTRIAL ESPIONAGE ORGANIZED

CRIMENATION STATES

TERRORISTS

Misguided Individuals

X-Force raport Vulnerability disclosures up 27%.

• Web applications continue to be the largest category of disclosure.

Significant increase across the board signifies efforts that are going on throughout the software industry to improve software quality and identify and patch vulnerabilities.

X-Force raport

X-Force raport

X-Force raport

X-Force raport – 2011

X-Force raport Public exploit disclosures up 21% in 2010 versus

2009• Approximately 14.9% of the vulnerabilities

disclosed in 2010 had public exploits, which is down slightly from the 15.7% last year

• However more vulnerabilities were disclosed this year, so the total number of exploits increased.

• The vast majority of public exploits are released the same day or in conjunction with public disclosure of the vulnerability.

X-Force raport

Sony 2011

Sony 2011

Tsunami Atak0

50100150200250300350400450500

Koszty przyszłeKoszty rozliczone

Anatomia ataku

Od U238 do U235

Stuxnet – wektor ataku (Windows)

Stuxnet

• Instalacja rootkit’a mrxnet.sys – Podpisany certyfikatem Realtek– Kontrola I/O do dysków, urządzeń zewnętrznych

• Komunikacja w sieci wewnętrznej

Stuxnet - PLC

• Modyfikacja procedur– Tylko dla Siemens S7-300 i w dodatku tylko dla wirówek

wyprodukowanych przez Vacon w Finlandii i Fararo Paya z Iranu.

– Tylko te których częstotliwość jest w zakresie 807-1210 Hz.• Analiza zwracanych informacji z wirówek

Stuxnet - PLC

• Po ~13 dniach – podniesienie częstotliwości do 1410 Hz

• Po ~27 dniach – nagła zmiana częstotliwości do 2Hz a następnie do 1064 Hz

• Skutek: mechaniczne uszkodzenie wirówek• Celem wirusa było prawdopodobnie centrum

uzdatniania uranu w Natanz (Iran).• Przynajmniej 10% wirówek uległo uszkodzeniu

Stuxnet

23

Za linią Maginot’a

Outsourcing

Aplikacje Webowe

Stare aplikacje Integracja/SOA

Użytkownicy wewnętrzni (DBA, programiści, kontraktorzy, itd.)

Utracona tożsamość (np.

Zeus)

Usługi dla pracowników, Partnerów, Dostawców

24

Bezpieczeństwo baz danych – sztuka prowadzenia wojny

„Człowiek bez strategii, który lekceważy sobie przeciwnika, nieuchronnie skończy jako jeniec.”

Sun Zi

ERP

Web server App

serverLoadbalancer

Databases

Fileserver

Fir

ewa

ll Fileserver

External users

1

25

Ataki z zewnątrz • Technologie: IDS, IPS, Whitelisting, Silne uwierzytelnienie, SIEM• Problemy:

– SQL Injection, 0-Day Attack, DoS, DDoS– Identyfikacja użytkownika, Wiedza o posiadanych uprawnieniach– Szyfrowanie połączeń– SPoF

• W latach 2000-2010 85% budżetów na zakup technologii ochrony danych związanych było z wydatkami na rozwiązania kontroli dostępu użytkowników zewnętrznych!!!

• Większość ataków na bazy danych jest trudno wykrywalna• 75% ataków pochodzi z wewnątrz organizacji

26

Użytkownicy wewnętrzni

„Dobry wojownik staje tam, gdzie nie będzie można go pokonać, i nie przeoczy żadnej słabości przeciwnika.”

Sun Zi

Internal users

ERP

Web server App

serverLoadbalancer

Databases

Fileserver

Fir

ewa

ll Fileserver

External users

1

2

27

Ataki z wewnątrz

• Technologie: DLP, SIEM, IAM, IDS, IPS, analiza zachowań fradulentnych• Problemy:

– Identyfikacja użytkownika, Wiedza o posiadanych uprawnieniach– Uprawnienia nadmiarowe– Segregacja uprawnień– Analiza zachowania użytkownika– Błędy ludzkie

• 80% organizacji nie posiada planu ochrony baz danych

28

Middleware

„Aby uniknąć tego, co silne, trzeba uderzać w to, co słabe.”

Sun Zi

Internal users

ERP

Web server App

serverLoadbalancer

Databases

Fileserver

Fir

ewa

ll Fileserver

External users

1

2

3

29

Ataki na middleware

• Technologie: HIDS, HIPS, CCM• Problemy:

– Spójność, zarządzanie zmianą– Audytowalność– Identyfikacja połączeń– Analiza podatności– Błędy aplikacyjne– Pule połączeń

• 20% organizacji korzysta z zaawansowanych technik pomiaru bezpieczeństwa

30

Użytkownicy uprzywilejowani

„Zwycięska armia najpierw wygrywa, a potem dąży do walki. Pokonana armia najpierw walczy, a potem dąży do zwycięstwa.”

Sun Zi

Internal users

ERP

Web server App

serverLoadbalancer

Databases

Fileserver

Fir

ewa

ll Fileserver

External users

1

2

3

Privileged users

4

31

Ataki z poziomu tożsamości uprzywilejowanej

• Technologie: DLP, UAC, SIEM, analizator zdarzeń fradulentnych, PIM• Tożsamość uprzywilejowana

– Administratorzy, konta techniczne (w tym konta aplikacyjne), użytkownicy łamiący zasadę „Least Privilege”

• Problemy:– Separacja obowiązków (SoD)– Audytowalność– Błędy ludzkie

• DBA poświęcają mniej niż 5% swojego czasu na analizę bezpieczeństwa bazy danych

32

Silnik bazy danych

„Twoim celem musi być zdobycie wszystkiego bez zniszczenia czegokolwiek.”

Sun Zi

Internal users

ERP

Web server App

serverLoadbalancer

Databases

Fileserver

Fir

ewa

ll Fileserver

External users

1

2

3

Privileged users

4

5

33

Ataki na platformę bazodanową

• Technologie: Skaner DB, Natywny audyt bazy danych, HIDS, HIPS, CCM• Problemy:

– Heterogeniczność– Zmienność– Okno serwisowe– Koegzystencja środowisk developerskich, testowych, Q&A i

produkcyjnych

• 70% baz danych nie ma zainstalowanych najświeższych łat bezpieczeństwa

34

Rozwiązanie do ochrony baz danych wg

35

DAM czyli InfoSphere Guardium

S-TAP for VSAM

Integration with LDAP, IAM, IBM Tivoli, IBM

TSM, Remedy, …

Scalable Multi-Tier Architecture Broadening and Enhancing Support for System z

S-TAP for IMS

S-TAP for DB2/z

Guardium S-TAP for DB2 on z/OS Architecture

AdministrationRepository

AuditedTables

DB2Subsystem

Audited DB2Subsystem

S-TAP Audit Server

S-TAP Agent

z/OS

S-TAPAdministrator GUI

Windows

ASC Audit SQL Collector

IFICollection

Audit TraceAudit Data

Offload Engine

UH Offload DS

UT Offload DS

UA Offload DS

FTP GET Process

AuditedTables

TCP/IPSTREAMING

Process

IP ADDRESS & PORT #

Guardium Appliance

Option 1Report for SQL Error

Exception Domain

Option 2 – Failed Authorization (Event #140 – Statement

Type)

Failed Authorization Attempt (Type 083)

Report of Events#55 = Statement “Set current SQL ID”• Easy reporting on specific events…• In report shows all statements of changing secondary authorization in

right sequence as it was executed:

JDBC Access Creating Grant Execution

• In that report we have different ways of grant execution including remote with JDBC, butch and DB2 call.

Other Accesses for Grants

SQL Code “0” “+100 – Row Not Found”• In that report we have column “records affected” which indicates number

of rows was returned by statement. • 0 = no rows effected• Statement Type 144 = Read (Select/Fetch)

Insert with Records Affected

• Statement Type 143 (Change = insert, update, delete)

Update and Delete Records Affected

Bind Variables

Executing static sql with host variable values from “Control Center” tool:

Dynamic SQL

Control Center

DB2 Utilities

51

Three key considerations for Guardium on System z Performance

1. Data Gathering• Collecting each SQL

statement

2. Data Filtering• Determining if the SQL

matches a monitoring policy

3. Data Movement• Packaging and sending

the SQL to the Guardium collector

51

-------- -----------

--- -----------

--- ------

1

Audit Interest

2

3

No Audit Interest

52

Terms and Definitions for Performance Considerations

1. Data Gathering

• Review all the SQL to see if it is of interest• The performance overhead of the data gathering is therefore correlated to the rate

of all SQL that passes through DB2• Many optimizations have been made to ensure that the overhead per request of

this phase is kept very low

53

Terms and Definitions for Performance Considerations

2. Data Filtering

Filtering is performed at three stages• Stage 0: Connection type or plan – Most efficient

filtering in the DB2 address space• Stage 1: Users and Program - Efficient filtering in the

DB2 address space• Stage 2: Object filtering (e.g. sensitive objects such

as tables) • Performed in the S-TAP ASC address space

outside of DB2• Data needs to be moved from DB2 address space

to S-TAP ASC for evaluation

Note that Stage 2 filtering is eligible for zIIP processing should a zIIP processor be available and have capacity to have this work dispatched to the zIIP subject to the workload manager policies.

54

Terms and Definitions for Performance Considerations

Data Movement• From DB2 address space to S-TAP ASC address space after stage

0 and1 filtering• The primary benefit of stage 0 and 1 filtering is the reduction

in the number of events that qualify to move to the ASC and the resulting reduction in memory moves of the data.

• With no stage 0 and 1 filtering, each captured events will need to be moved in memory.

• From S-TAP ASC to Guardium collector after stage 2 • Streamed to the Guardium collector over TCP/IP without

writing to disk. • If the filtering is extensive, potentially few events will be

streamed, limiting the overhead of the TCP/IP transfers. • If there is no filtering (stage 0, 1 or 2), the effect is to stream

ALL the events processed through DB2 to the Guardium collector. The performance impact needs to be considered for this option.

55

Guardium S-TAP for DB2 Policy Configuration

DB2 Subsystem

Guardium z Collector

Connection Types, Plans, Users, and Objects, to audit

-------- ------

56

Guardium S-TAP for DB2 on z/OS Architecture

DB2 Subsystem

Audited DB2

Subsystem

Guardium z Collector

SQL Application

Select …

Fetch…

Fetch…

Update…

S-TAP

Stage 1

Filters

Evaluate SQL

- by user ?

All other evaluations sent to Stage2

S-TAP

Stage 2

Filters

- by object ?

DB2 IFICapture non-SQL

events

--- Gathering ------ Filtering ------- Moving ---

S-TAP

Streaming Process

S-TAP

Stage 0

Filters

Evaluate SQL

- by connection

- by plan

All other evaluations sent to Stage1

Guardium S-TAP for VSAM on z/OS Architecture

CONTROL DS

OPTIONS RULEDEFSRULEDEFB

• AuditedTables

VSAM

z/OS

AuditedVSAM

TCP/IP

CollectionPolicy

• SYSTEM EXITS

• SMF EXITS• IEFU83 IEFU84

IEFU85

AGENT

S-TAP STC

Guardium Appliance

FILTER EVENT DATA

57IBM Confidential

Reports

System Z Vulnerability Assessment

Vulnerability Assessment Tests in 8.2• Tests on a number of security related system parameter (DSNZPARM) settings• Tests for z/OS “Orphans”

– “Orphans are authorization IDs with privileges who do not appear in the RACF database

– Tests are based on contents of two optional Guardium tables• z/OS Group table• z/OS User table• Tables are appliance created, but populated by customer process• RACF sample based on IRRDBU00 utility provided

• “Patch” Tests for Security related PTFs– Over 40 different APAR test delivered GA– Quarterly updates are provided

• IBM Exclusive functionality - competitive differentiator

VA Configuration - Configure Tests.

z/OS test are under the DB2tab

62

InfoSphere Guardium Data Encryption for DB2 and IMS Databases

• Existing implementation uses DB2 EDITPROC for row level encryption– Application Transparent– Acceptable overhead when accessing any column in table– No Additional Security– Table must be dropped and reloaded to add EDITPROC– Indexes not encryptedNew Functionality User Defined Function (UDF) for column level encryption– Requires changes to SQL when accessing encrypted column– High overhead when accessing encrypted column, no overhead on non-encrypted

columns– Can secure UDF in RACF for additional security– Index Encryption– Data encrypted in place– Prototype running in 2 customers and lab – Implementation can be less disruptive that other approaches (SQL based)

63

InfoSphere Guardium – Wykrywanie baz

64

InfoSphere Guardium – Klasyfikacja danych

65

InfoSphere Guardium – Zarządzanie incydentami

What Action? Either Reject or approved…

66

InfoSphere Guardium – pełen wgląd w uprawnienia

The Choice of the Mainframe

68

InfoSphere Guardium – wybór należy do Ciebie