One Step Closer To Making Data Breaches a Thing of the Past Ernie Mancill, IBM
Please note IBM Software Group Information Management software IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about IBM potential Software future products Group may Lotus not be incorporated software into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
Business Landscape and current Threats 3
Database Servers - The Primary Source of Breached Data All Others Laptops and Backups Desktops Database Servers Although much angst and security funding is given to offline data, mobile devices, and end-user systems, these assets are simply not a major point of compromise. up from 75% in 2009 Data Breaches - 2011 Database Servers 96% All Others 2% Laptops and Backups 1% Desktops 1% - 2009 Data Breach Investigations Report 2011 Data Breach Report from Verizon Business RISK Team Source: http://www.verizonbusiness.com/resources/security/reports/2012_databreach_rp.pdf 4
Why? Database servers contain your most valuable information Financial records Customer information Credit card and other account records Personally identifiable information High volumes of structured data Easy to access Because that s where the money is. - Willie Sutton 5
Database Danger from Within Organizations overlook the most imminent threat to their databases: authorized users. (Dark Reading) No one group seems to own database security This is not a recipe for strong database security 63% depend primarily on manual processes. (ESG) Most organizations (62%) cannot prevent super users from reading or tampering with sensitive information most are unable to even detect such incidents only 1 out of 4 believe their data assets are securely configured (Independent Oracle User Group). 6
Growing Compliance Mandates Explosion in successful breaches has resulted in growing regulation of sensitive data in North America SOX HIPAA PCI DSS 46 state-specific data privacy laws Gramm-Leach-Bliley Many EU and Asian countries have enacted similar regulations EU Data Privacy Directive and supporting local laws C-SOX FIEL PCI DSS etc. 7
Threats to DB2 Data Privileged User access to DB2 Data from outside of DB2. Access to Linear VSAM datasets Privileged User access to DB2 Data via SQL Abuse of privilege without business Need to Know External Threats SQL Injection (Hacking) Movement of data outside of DB2 Unloads Clones Test Data Replication
Defense in Depth of DB2 Data First Layer - Encryption (this forces only access to clear text data must be in the form of an SQL statement) Second Layer - Database Activity Monitoring (this ensures each SQL statement is inspected, audited, and subject to security policy control) Third Layer - Audit access to VSAM linear datasets Fourth Layer - Implement business need to know control for critical data (this reduces abuse of privilege access) Fifth Layer - Protect the use of unloads and extracts for the purpose of: Test data management and generation Unloaded data for batch processes Extracts for external uses Replicated data Backup and Recovery assets
First Layer of Defense: Encryption 10
Encryption and Data at Rest Protection Key requirement for most of the popular data protection initiatives Main requirement is to protect data at rest to ensure that only access if for business needto-know, and through mechanisms which can be controlled by the native security mechanisms (such as RACF) Consider the following scenario: DB2 Linear VSAM datasets are controlled via RACF from direct access outside of DB2 via dataset access rules DBA or Storage Administrator has RACF authority to read VSAM datasets in order to perform legitimate storage administration activities. Administration privileges can be abused to read the linear VSAM datasets directly and access clear-text data outside of DB2/RACF protections. Now consider the above scenario, but with the underlying Linear VSAM datasets encrypted 21 When DBA or Storage Administrator uses their RACF dataset authorities in a manner which is outside of business need-to-know, the data retrieved is cybertext and thus remains encrypted and protected. Only way to access and obtain clear-text data will be via SQL which can be protected via DB2/RACF interface
Example of a table without encryption - Rows accessed via SQL
External print of the tablespace container showing unencrypted table and clear text exposure of data
Example of table with encryption enabled EDITPROC name (generated by the Encryption Tool) specified by DDL
Example of a table with encryption - Rows accessed via SQL and results presented to application requestor as clear-text Each SQL request will invoke the EDITPROC and result in clear-text being presented back to any AUTHORIZED requestor
External print of the tablespace container showing encrypted table and Cyber-text data without exposure of data
ICSF Interface to the Crypto Hardware z/os Appl Program (or product) ICSF Address Space ICSF Data Space Call CSF API (parms) ICSF Routines CKDS PKDS APIs Key Storage Load Balancing Security CKDS TKDS TKDS Cache PKDS
Key Types and Algorithms Key Types Clear Key key may be in the clear, at least briefly, somewhere in the environment Secure Key key value does not exist in the clear outside of the HSM (secure, tamper-resistant boundary of the card) Protected Key key value does not exist outside of physical hardware, although the hardware may not be tamper-resistant Encryption Algorithms TDES - Triple Data Encryption Standard (up to 192 bit key support) AES - American Encryption Standard (up to 512 bit key support)
Crypto Hardware for Data Encryption Clear Key z800/z900/g6 Requires a CCF zenterprise/z10 CPACF (& PCIXCC, CEX2C for CKDS)* Secure Key z800/z900/g6 Requires a CCF z890/z990 Requires a PCIXCC or CEX2 z9 Requires a CEX2C z10 Requires a CEX2C or CEX3C zenterprise Requires a CEX3C Protected Key zenterprise/z10 Requires a CEX3C
InfoSphere Guardium Data Encryption for DB2 and IMS Databases Existing implementation uses DB2 EDITPROC for row level encryption Application Transparent No Additional Security Table must be dropped and reloaded to add EDITPROC Indexes not encrypted 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 nonencrypted columns Can secure UDF in RACF for additional security Data encrypted in place, Implementation can be less disruptive that other approaches (SQL based) DB2 Fieldproc for column level encryption Similar Characteristics to EDITPROC approach Index encryption
DB2 EDITPROC Restriction removal APAR PM07944/PTF UK71403 Support a new EDITPROC COLUMN INSENSITIVE clause on CREATE TABLE. Lift restrictions for the following column types: IDENTITY, XML, DECFLOAT, BIGINT, BINARY, VARBINARY, ROWID, and SECLABEL when using a column insensitive EDITPROC Note: LOB data type restriction remains in place. Lift restriction for >18 byte column names Allow the use of the ALTER TABLE statement to make certain changes to a table that already has a column insensitive EDITPROC defined. Altering a table to add a new column or alter an existing column data type, length, precision, or scale for a table with a column insensitive EDITPROC. Altering a table to add a new XML column or a SECLABEL column for a table with a column insensitive edit routine. Altering a table to rename a column for a table with a column insensitive edit routine. 21
DB2 Data Encryption Flow Insert / Update SQL Request Unencrypted Row Integrated Cryptographic Service Facility (ICSF) Encryption 1 SQL Insert/Update Application Storage 2 5 3 Unencrypted Row 4 Encrypted Row Unencrypted Row B Encrypted Row 1) Key Label Application Storage DB2 Buffer Pool 6 Put Encrypted Row B Encrypted Row 6 User Key Cryptographic Key Data Set Encryption EDITPROC B Encrypted Row
Second Layer of Defense: Database Activity Monitoring (Auditing) 23
Collecting Real-Time Actionable Audit Information RACF provides control for resource access, but lacks granularity in generating audit reports DB2 Audit Trace significantly improved in V10, but still requires externalization to SMF and customer provided reporting infrastructure SMF based reporting can result in latency from event capture to subsequent reporting and actionable processing Trace based auditing tends to be complex and controlled by privileged users (DBA or SYSPROGS)
IBM Infosphere Guardium Integration with LDAP, IAM, IBM Tivoli SIEM, IBM TSM, Remedy,
Address the Full Data Protection Lifecycle Discover your DBMSs Discover & classify sensitive data Continuously update security policies Cross-DBMS policies Pre-built compliance reports (SOX, PCI, etc.) Enterprise integration SIEM integration Sign-off management Centralized audit repository No database changes Discover & Classify IBM Software Group Critical Lotus software Discover Audit & Report Classify Data Infrastructure Assess & Harden Monitor Assess & & Enforce Harden DB vulnerability assessments Configuration auditing Masking and Redaction Encryption of sensitive data Archive un-needed data Preconfigured tests based on best practices and standards Monitor & block attacks Monitor privileged users Monitor changed behavior Real-time alerts Prevent cyberattacks Detect application-layer fraud Enforce change controls Forensics data mining
IBM Infosphere Guardium S-TAP for DB2 on z/os Guardium z Collector Collection Profiles TCP/IP STREAMING Process S-TAP Audit Server Administration Repository DB2 Subsystem S-TAP Agent DB2 IFI Collection Auth/.CMD/ Utilities Audited Table Audited DB2 Subsystem ASC Audit SQL Collector 27
A Typical Collection Profile
Reports - Select * from US_SALES1 29
Reports - Inserts Values can be redacted Values can be recorded 30
Reports Update 31
Unauthorized Connections
4. Alerts Processed audit data can create alerts Alert on any component within the policy In this example, US_SALES1 with DML Commands
4. Alerts Processed audit data can create alerts
Third Layer of Defense: VSAM Activity Monitoring (Auditing) 35
Product Synopsis Software component of the InfoSphere Guardium solution Captures VSAM data set events Open, Update, Delete, Rename, Create, Alter Related RACF events (Alter, Control, Update, Read) VSAM file types (ESDS, KSDS, RRDS, VRRDS, LDS) S-TAP for VSAM sends information specified by user-defined audit policies to an InfoSphere Guardium Collector for z/os appliance Release 8.2 is initial release
Guardium S-TAP for VSAM on z/os Architecture Guardium Appliance Collection Policy z/os TCP/IP CONTROL DS OPTIONS S-TAP STC RULEDEFS RULEDEFB FILTER EVENT DATA AGENT SYSTEM EXITS SMF EXITS IEFU83 IEFU84 IEFU85 Audited Tables Audited VSAM VSAM
Monitored Data File types: ESDS, KSDS, RRDS, VRRDS, and LDS Events: DATA SET OPEN DATA SET UPDATE DATA SET DELETE DATA SET RENAME DATA SET CREATE DATA SET ALTER RACF ALTER RACF CONTROL RACF UPDATE 38 RACF READ
Sample Report IBM Software Group Information Management software
Fourth Layer of Defense: Business Need to Know access control 40
New DB2 10 fine grain table controls Protect against unplanned SQL access Define additional table controls at the row and column level Security policies are defined using SQL Separate security logic from application logic Security policies based on real time session attributes Protects against SQL injection attacks Determines how column values are returned Determines which rows are returned No need to remember various view or application names No need to manage many views; no view update or audit issues Mask column values in answer set All access via SQL including privileged users, adhoc query tools, report generation tools is protected Policies can be added, modified, or removed to meet current company rules without change to applications 41
Fifth Layer of Defense: Control of Data Movement OUTSIDE of DB2 42
Limit the scope of compliance and security concerns Sensitive Data Proliferation Sensitive Data Development Sensitive Data Production Sensitive Data IBM Test Software Group Backup Lotus software Sensitive Data Sensitive Data User Acceptance Sensitive Data Disaster Recovery Risk of Breach Actual risk and compliance burden = Original production data + all derived clones 43
Effective Test Data Management Production or Production Clone 2TB 100 GB Development Environment Create targeted, right-sized test environments instead of cloning entire production environments. Development environments are then more manageable, improving agility to deploy new functionality more quickly and with improved quality. 100 GB QA Environment OPTIM Test Data Management 100 GB Test Environment 100 GB Training Environment
Sensitive Data Masking Masked or transformed data must be appropriate to the context: Consistent formatting (alpha to alpha) Context and application aware Within permissible range of values Maintain referential integrity OPTIM Data Privacy A comprehensive set of data masking techniques to transform or de-identify data, including: String literal values Character substrings Random or sequential numbers Arithmetic expressions Concatenated expressions Date aging Lookup values TRANS COL Example 1 Patient Information Example 2 IBM Software Group Personal Lotus Info software Table Patient Patient No. No. 112233 123456 SSN SSN 123-45-6789 333-22-4444 Name Name Amanda Erica Schafer Winters Address 40 12 Bayberry Murray Court Drive City City Elgin Austin State State IL TX Zip Zip 60123 78704 PersNbr FirstName LastName 08054 10000 Jeanne Alice Bennett Renoir 19101 10001 Claude Carl Davis Monet 27645 10002 Pablo Elliot Flynn Picasso Data is masked with contextually correct data to preserve integrity of test data 45 Referential integrity is maintained with key propagation Event Table PersNbr FstNEvtOwn LstNEvtOwn 27645 10002 Pablo Elliot Flynn Picasso 27645 10002 Pablo Elliot Flynn Picasso
What is IBM Infosphere Guardium Data Encryption Expert? Security for your structured and unstructured data High performance encryption, access control and auditing Data privacy for both online and backup environments Unified policy and key management for centralized administration across multiple data servers Transparency to users, databases, applications, storage No coding or changes to existing IT infrastructure Protect data in any storage environment User access to data same as before Centralized administration Policy and Key management Audit logs High Availability 46
Data Encryption Architecture Authenticated Users Applications DBMS Server server / file File server ftp server File System SSL x.509 Certificates Web Administration DE Agent https IBM DE Server Active /Active Key, Policy, Audit Log Store Online Files Data Encryption Security Server Policy and Key Management Centralized administration Separation of duties 47
IBM Encryption Facility for z/os, 1.1 Licensed Program Product MSU-based pricing Requires: z/os 1.4 or higher z/os.e 1.4 or higher Feature: Encryption Services Optional Priced Feature* Feature: DFSMSdss Encryption Encryption Facility Client Web download Optional Priced Feature* Supports encrypting and decrypting of data at rest (tapes, disk) Supports either Public Key/Private keys or passwords to create highly secure exchange between partners Java technology-based code that allows client systems to decrypt and encrypt data for exchange with z/os systems Allows encryption and compression of DUMP data sets created by DFSMSdss Supports decryption and decompression during RESTORE * Variable Workload License Charges (VWLC), Entry Workload License Charges (EWLC), zseries Entry License Charges (zelc), Parallel Sysplex License Charges (PSLC)
Wrap up 49
Review - Approach Encrypting the tablespace containers will force the use of SQL to obtain clear-text data. All SQL should be subject to security controls (DB2 and/or RACF) as well as inspected for audit collection and application of Audit Policies. VSAM activity should also be subject to monitoring, in particular, any access to the DB2 Linear VSAM dataset containers outside of DB2 For specific DB2 tables, Business Need to Know controls can be implemented. Any movement of data outside of DB2 should also be controlled: Replicated Data (z/os and Open System Targets) Unloads Test Data from Production Data Recovery Assets (Image Copy and DB2 Recovery Log Archives)
Review - Capabilities Encryption of Data at Rest with Infosphere Encryption Tool for DB2 and IMS Databases Fine-Grain Database Activity Monitoring with Infosphere Guardium for DB2 VSAM Activity Monitoring with Infosphere Guardium STAP for VSAM Business Need to Know controls on specific tables with DB2 10 and Row filters / Column masking Control of Data moved outside of DB2: Infosphere Guardium Encryption Expert for MP Optim Test Data Management and Data Privacy Solution z/os Encryption Facility Infosphere Encryption Tool for DB2 and IMS databases Infosphere Guardium Database Activity Monitoring