Post on 21-Jan-2017
transcript
© 2012 IBM Corporation
IBM Security Systems
IBM Guardium Data Encryption for IMS and DB2
Presented by:Thomas J. HubbardProduct SpecialistRocket Software
© 2012 IBM Corporation
IBM Security Systems
Agenda• Overview• Why encrypt the database?• IBM Guardium Data Encryption• DB2 database encryption• IMS database encryption• Q & A
© 2014 IBM Corporation
IBM Security Systems
OVERVIEW
© 2014 IBM Corporation
IBM Security Systems
Why Should All Data at Rest be Encrypted? Why do you care?
• Keeps sensitive information confidential
- Insider threat- Lost/stolen tape or disk - Disk being repaired (Solid-state disks fail in a read-only state)
• Simplifies end-of-life-of-media scenarios - Destroy the key and the data is unusable
- Cryptographic Erasure (NIST SP800-88)- Reducing media disposal costs
• Addresses Standards
- and others
- Privacy breach disclosure laws (e.g. EU Privacy Disclosure Directive)- Protection of financial data
© 2014 IBM Corporation
IBM Security Systems
Cryptography has Many Applications
SSL/TLS
Link encryptionTape encryption
Database encryption
Application level encryption
PIN processing
File encryption
SAN Switch encryption
Protecting Data at Rest Protecting Data
in Motion
Digital rights management
Tokenization Protecting Data in Use
IPsec
Disk encryption
Email encryption
Data
© 2014 IBM Corporation
IBM Security Systems
Cryptography is a Fundamental Security Technology
• Key exchange for communication session keys• Data is transit is protected using single-use keys• Data at rest – Keys are long lived
Establishes Privacy of Data in Motion and
Data at Rest
• Being able to encrypt or decrypt proves you are in possession of or authorized to use the key
• Certificates provide additional identity informationEstablishes Identity
• Data Integrity is provided through keyed-hashes• Hashes provide integrity checking for data in transit
Protects against Unauthorized
Changes
• Digital signatures create undeniable authorshipAssigns Ownership to the Data or Message
© 2014 IBM Corporation
IBM Security Systems
Disk and Tape options in IBM Self-Encrypting Storage
DS8870
DS3500
XIVN series
TS3500 library
TS1140 drive
LTO6 drive
TS3310 libraryGPFS
Self-encrypting solutions that protect
Data-at-Rest
© 2014 IBM Corporation
IBM Security Systems
WHY DATABASE ENCRYPTION?
© 2014 IBM Corporation
IBM Security Systems
Security Cost/Risk
0
2
4
6
8
10
12
Security Cost vs. Risk
Cost Risk
© 2014 IBM Corporation
IBM Security Systems
Encryption and “Data at Rest” Protection Key requirement for most of the “current” data protection initiatives Main requirement is to protect “data at rest” to ensure that only access is for
business need-to-know, and through mechanisms which can be controlled by the native security mechanisms (such as RACF) Consider the following scenario:
– Database datasets are controlled via RACF from direct access outside of the DBMS via dataset access rules
– DBA or Storage Administrator has RACF authority to read database datasets in order to perform legitimate storage administration activities.
– Administration privileges can be abused to read the database datasets directly and access clear-text data outside of DBMS/RACF protections.
Now consider the above scenario, but with the underlying database datasets encrypted
– 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 DBMS services which can be protected via RACF
21
© 2014 IBM Corporation
IBM Security Systems
What value does database encryption add?
Protects sensitive data that can reside on various storage media Another layer of security For DB2, log records, image copies, and data buffers are encrypted For IMS, image copies, data buffers, and log records that log changes to
database records are encrypted IMS data that is decrypted is also logged Prevent access to decrypted data outside the control of the DBMS
– DFDSS – FDR – IDCAMS Repro– Volume reassign
© 2014 IBM Corporation
IBM Security Systems
ENCRYPTION ON ZSERIES
© 2014 IBM Corporation
IBM Security Systems
Integrated Cryptographic Service Facility (ICSF)
Provides: z/OS integrated software support for data encryption
Operating System S/W API Interface to Cryptographic Hardware − CEX2/3C hardware feature for z114, z10 and z196− CEX4S hardware feature for z12BC and z12EC− CEX5S hardware feature for z13 (2x faster over CEX4S)
Enhanced Key Management for key creation and distribution− Public and private keys− Secure and clear keys− Master keys
Created keys are stored/accessed in the Cryptographic Key Data Set (CKDS) with unique key label− CKDS itself is secured via Security Access Facility
© 2014 IBM Corporation
IBM Security Systems
CKDS – Cryptographic Key Dataset
Key element of the IBM encryption solution on z/OS VSAM Key Sequenced Dataset Contents are ICSF generated data encrypted keys Accessed by ICSF API and Services
– Key Label (known by application requestor) used to find key record in the CKDS
Copy of CKDS cached in operating system storage at first ICSF invocation for performance– Refreshable
CKDS administration performed using ICSF services and ISPF interfaces.
Use of specific individual keys can be controlled via RACF profiles and permissions
CEX2/3C/4C/5C hardware feature required for use– Unless with a combination of HCR7751 or greater and clear key only,
then “crypto cards” are optional
© 2014 IBM Corporation
IBM Security Systems
What are Keys? (From an ICSF Perspective)
Master Keys– Loaded into the “crypto cards” hardware, and stored NO WHERE else
• Pass Phrase Utility• ISPF Panels• TKE Workstation (optional hardware feature)
– Used to generate, encrypt, and store user keys into the CKDS (Cryptographic Key Data Set)
User Keys (Data Encrypting keys)– Generated via ICSF services – Stored inside the CKDS– Clear or Secure– Used by the IBM “Encryption Tool” in conjunction with the encryption
algorithm to convert user data to “cipher text”
© 2014 IBM Corporation
IBM Security Systems
Clear Key / Protected Key / Secure Key
Clear Key – key may be in the clear, at least briefly, somewhere in the environment
Protected Key – key value does not exist outside of physical hardware, although the hardware may not be tamper-resistant. Requires the use of a master key.
Secure Key – key value does not exist in the clear outside of the HSM (secure, tamper-resistant boundary of the card)
© 2014 IBM Corporation
IBM Security Systems
Some general comments on using secure or clear key Clear Key vs. Secure Key Performance
– Clear key elapsed time performance is MUCH superior than secure key– Secure key (performed inside the “crypto card”) is generally viewed as more
secure from a cryptographic perspective– Clear key uses special instructions that run on the z9 – z10 general purpose
processors, so performance is measured in milliseconds– Secure key encryption is dispatched to run on the cryptographic
coprocessors on the “crypto card” feature. This tends to be measured in microseconds as this is essentially an I/O operation.
– Secure key elapsed time measurements (depending on workload and SQL type) can be from 10x to 40x more than clear key
– Secure key is probably NOT appropriate for most (to date all) OLTP workloads, but each customer needs to make this encryption decision based on their security requirements and performance expectations
© 2014 IBM Corporation
IBM Security Systems
DB2 BUILT IN ENCRYPTION
© 2014 IBM Corporation
IBM Security Systems
DB2 Built-In Functions
Under application control – you encrypt the fields that need to be secure– ‘Password for Encryption’ is hashed to generate a unique key– Hint can be used as a prompt for remembering the key– Encrypted field must be defined as VARCHAR (since it will contain binary data once its
encrypted)– The encrypted field will be longer (next multiple of 8 bytes + 24 bytes of MetaData + 32
bytes for optional hint field)– TDES Only!
Encrypt (StringDataToEncrypt, PasswordOrPhrase, PasswordHint) Decrypt_Char(EncryptedData, PasswordOrPhrase
© 2014 IBM Corporation
IBM Security Systems©
DB2 BIFs - HardwareRequirements• zEC12/zBC12, z196/z114, z10 (CPACF)
• Uses MSA instructions, not the ICSF APIs, but ICSF must be started to provide hashing support
• TDES only
© 2014 IBM Corporation
IBM Security Systems
IBM GUARDIUM DATA ENCRYPTION
© 2014 IBM Corporation
IBM Security Systems
Overview
A Single tool for both DB2 and IMS Data Encryption addresses the increased demand for data privacy and security Performs encryption and decryption through the use of exit routines. Leverages the System z®, zSeries®, and S/390® Crypto Hardware to encrypt data Protects sensitive data that can reside on various storage media
– For DB2, log records, image copies, and data buffers are encrypted– For IMS, image copies, data buffers, and log records that log changes to database
records are encrypted– IMS data that is decrypted is also logged
© 2014 IBM Corporation
IBM Security Systems
Features and Benefits
Enables compliance with privacy and security regulations Customization down to DB2 column level and at the IMS segment level Straightforward implementation using RACF key labels Ensures data privacy by encrypting and decrypting data Uses the following encryption algorithms:
– Triple Data Encryption Algorithm (TDEA), also known as the Triple Data Encryption Standard (Triple DES)
– ANSI Data Encryption Algorithm (DEA), also known as the Data Encryption Standard (DES)
– Advanced Encryption Standard (AES)
© 2014 IBM Corporation
IBM Security Systems
Features and Benefits (continued)
Requires no changes to your applications Conforms to the existing z/OS and OS/390® security model Provides an ISPF front end to create and customize encryption exit routines Enables you to leverage the power of Storage Area Networks (SANs) safely while
complying with privacy and security regulations
© 2014 IBM Corporation
IBM Security Systems
Data Encryption Tool – HardwareRequirements• Clear Key
• zEC12/zBC12 /z196/z114/z10
• Secure Key• zEC12/zBC12 /z196/z114/z10
• Protected Key
CPACF & crypto card for CKDS*
Requires a crypto card
• z196/z114/z10• zEC12/zBC12
Requires a CEX3CRequires a CEX4SC or CEX3C
*Prior to HCR7750 a crypto card is required to create and use a CKDS, beginning with HCR7751 ICSF supports a clear key only CKDS**Protected Key support requires HCR7770 or higher
© 2014 IBM Corporation
IBM Security Systems
DB2 DATABASE ENCRYPTION
© 2014 IBM Corporation
IBM Security Systems
Properties Self Encrypting Devices DB2 Builtin EDITPROC UDF
Satisfies PCI Yes for data at rest audit requirement App Dependent Yes . For data at rest andin flight to/fromapplication.
Yes . For data at restandin flight to/fromapplication.
Complexity No Application Changes. Complex ApplicationChanges No Application Changes Application Transparent
Implementation Mount encryptable volume onappropriately configureddrive.
ALTER and reLOAD DROP and reLOAD SQL UPDATE
Clear Passwords No Yes No No
Access Control No application securityprovided App Managed Table Level RACF secured UDF
AdditionalHardware Yes,. Major investment. No No No
Key Control Tivoli managed App Managed ICSF Managed ICSF Managed
Maintainability Transparent Transparent Easy Centralized
Performance Best App Dependent Acceptable Overhead forencryptedcolumn
Index Encryption Yes Yes No Yes
Data Protection Only protect on media Clear Key Unload Data in clear Always Protected
Data TypeIndependence Yes Yes Most data types Yes
DB2 Data Encryption
© 2014 IBM Corporation
IBM Security Systems
DB2 Data Encryption Flow – Insert / Update
1)
Application Storage
Encryption EDITPROC
Integrated Cryptographic Service Facility
(ICSF)
Cryptographic KeyData Set
DB2 Buffer Pool
1 SQL Insert/Update
2 5
3 Unencrypted Row
4 Encrypted Row
6
6
Encryption Put EncryptedRow
Unencrypted Row B Encrypted Row
EncryptedRow
EncryptedRow
SQL Request
Application Storage
Unencrypted Row
KeyLabel
User Key
B
B
© 2014 IBM Corporation
IBM Security Systems
Cryptographic Keys
• Data Encryption Tool• Key must be stored in the CKDS• When the table with an EDITPROC/FIELDPROC is in use,
the key is available in the DB2 address space
• DB2 BIF• Clear key only (it’s calculated by hashing the password
for encryption) – so it’s available in the DB2 address space
• Keys are not stored in a dataset, but the password for encryption is stored in the table
© 2014 IBM Corporation
IBM Security Systems
Implementing/Changing Cryptographic Data Keys
• Data Encryption Tool• Unload, change EDITPROC/FIELDPROC to reference
new key, reload• Unload, change current key, DB2 restart, reload
• DB2 BIF• Under application control
© 2014 IBM Corporation
IBM Security Systems
• Index not encrypted• Encryption Tool EDITPROC – index is not encrypted (EDITPROC encrypts the
entire row, so the data is encrypted, but the index is not)• Bad for security, good for performance
• Index encrypted• FIELDPROC - index can be encrypted• DB2 BIF - Application encrypts the field, if that field is an index, then the
index is encrypted• Good for security, but may impact performance
Database Indexes
INDEX SSN NAME ADDRESS
223491398 F{(œ(•´ú— GÿÞ# ¥†‰jÍiÑÆ
INDEX SSN NAME ADDRESS
F{(œ(•´ú F{(œ(•´ú— GÿÞ# ¥†‰jÍiÑÆ
© 2014 IBM Corporation
IBM Security Systems
Comparison of Supported DB2 Encryption Methods
Function EDITPROC FIELDPROC UDFRow based encryption
Column based encryption
Application impact during implementation (Drop/CREATE) 1
maybe
SQL based implementation
“Clear Key” AES, TDES/DES
“Protected Key” AES, TDES/DES
AES AES
“Secure Key” AES, TDES/DES
1. New encrypted columns can be added using FIELDPROC encryption by ALTER ADD COMUNN SQL. Encrypting an existing column requires DROP/CREATE.
© 2014 IBM Corporation
IBM Security Systems
Edit procedure DECENA00
Advantages DisadvantagesNo application code or SQL changes Cannot encrypt indexes
Is column data-type independent Uses an ICSF feature that moves the encryption key into program storage. This disadvantage is deemed an acceptable risk by some users.
Excellent performance Must drop and reload databases to implement encryption that is affecting database availability
Uses RACF and SYSADM or SECADM access control
Decrypts rows for users and applications for each access
Key may be in the clear at least briefly somewhere in the environment
Key type: ICSF Key Retrieve (Clear Key) You can use an edit procedure to transform values on a row
© 2014 IBM Corporation
IBM Security Systems
Edit procedure DECENB00
Advantages DisadvantagesNo application code or SQL changes Cannot encrypt indexes
Is column data-type independent Must drop and reload databases to implement encryption that is affecting database availability
Uses ICSF release HCR7770 or newer technology on the latest z/OS hardware
Decrypts rows for users and applications for each access
Uses acceptable RACF and SYSADM or SECADM access control
The key does not exist outside of the physical hardware however, the hardware may not be tamper resistant
Key type: ICSF CPACF Protected Key You can use an edit procedure to transform values on a row
© 2014 IBM Corporation
IBM Security Systems
Edit procedure DECENC00
Advantages DisadvantagesNo application code or SQL changes Performs poorly because of the secure, but
restrictive, processor ICSF architectureIs column data-type independent Is recommended only for small databases
Is the most secure technology available. The key does not exist outside of the tamper resistant card.
Cannot encrypt indexes
Uses RACF and SYSADM or SECADM access control
Must drop and reload databases to implement encryption that is affecting database availabilityDecrypts rows for users and applications for each access
Key type: Secure Key You can use an edit procedure to transform values on a row
© 2014 IBM Corporation
IBM Security Systems
FIELDPROC DECENF00
Advantages DisadvantagesPerforms well for single column Can degrade performance if more than 2
columns are encrypted
Uses ICSF release HCR7770 or newer technology on the latest z/OS hardware.
Has column data type restrictions
Uses RACF and SYSADM or SECADM access control
Cannot use column lengths that exceed 254 bytes in length
Can encrypt indexes Cannot use column names that exceed 18 characters in length
Can be implemented by using ALTER ADD NEW COLUMN, thus maintaining database availability
Decrypts columns for users and applications even when it is not necessary for the application or user
Can be implemented by using UPDATE, thus maintaining database availability
Does not decrypt unloaded columns
Key type: ICSF CPACF Protected Key You can use a field procedure to transform values in a single, short string column.
© 2014 IBM Corporation
IBM Security Systems
UDF DECENU00
Advantages DisadvantagesIs data-type independent Can slow down performance during mass
updates and predicate processing. Ensure that the DB2 WLM started task is set to the maximum velocity to help performance
Uses ICSF release HCR7770 or newer technology on the latest z/OS hardware.
Does not decrypt unload columns
Can use DB2 MASK, VIEW, and TRIGGER features, RACF® SYSADM or SECADM to provide comprehensive granular access control
Can encrypt indexes
Can avoid performance issues for non-authorized users (by using DB2 MASK, VIEW, and TRIGGER features)
Can be implemented by using UPDATE, thus maintaining database availability
Does not decrypt unloaded columns
Key type: ICSF CPACF Protected Key You can use the UDF to manage access control of encrypted data.
© 2014 IBM Corporation
IBM Security Systems
IMS DATABASE ENCRYPTION
IBM Guardium Data Encryption
© 2014 IBM Corporation
IBM Security Systems
IMS Encryption Flow
Encryption
1. IMS application program passes a segment REPL, ISRT, or LOAD request to the IMS control region. IMS uses the DBD to determine that a Segment Edit/Compression exit is required, so IMS loads the exit.
2. Exit invokes ICSF services, passing user-defined data encryption key label (provided by exit) and unencrypted segment.
3. When the segment has been successfully encrypted, the exit passes the segment back to IMS.
4. IMS then puts the encrypted segment into the database
© 2014 IBM Corporation
IBM Security Systems
IMS Decryption Flow
Decryption
1. IMS application program passes segment GET request to IMS control region. IMS determines, from DBD, that a Segment Edit/Compression exit is required, so IMS loads the exit.
2. IMS retrieves encrypted segment from the database.
3. IMS then calls the exit and passes it the encrypted segment. The exit invokes ICSF services, which passes the user-defined data encryption key label (provided by exit) and the encrypted segment.
4. When the segment has been successfully decrypted, the exit passes the segment back to IMS.
5. IMS passes the decrypted segment back to the application.
© 2014 IBM Corporation
IBM Security Systems
Comparison of Supported IMS Encryption Methods
Function DECENA01 DECENB01 DECENC01Segment based encryption (Key and or Data)
“Clear Key” TDES/DES
“Protected Key” AES
“Secure Key” AES, TDES/DES
1. New encrypted columns can be added using FIELDPROC encryption by ALTER ADD COMUNN SQL. Encrypting an existing column requires DROP/CREATE.
© 2014 IBM Corporation
IBM Security Systems
ICSF Services For IMS Encryption
Function DECENA01 DECENB01 DECENC01Segment based encryption (Key and or Data)
“Clear Key” CSNBSYE and
CSNBSYD
“Protected Key” CSNBSYE and
CSNBSYD
“Secure Key” CSNBENC and
CSNBDEC
1. New encrypted columns can be added using FIELDPROC encryption by ALTER ADD COMUNN SQL. Encrypting an existing column requires DROP/CREATE.
© 2014 IBM Corporation
IBM Security Systems
ICSF ‘to do’s”:• Configure the Integrated Cryptographic Service Facility (ICSF)• Enable CP Assist for Cryptographic Functions (CPACF)• Install and enable Crypto Express feature (Crypto card)• Generate and store in the Cryptographic Key Data Set (CKDS) Key Labels
DB2 encryption “to do’s”:• Build the DB2 EDITPROC• Generate Data Encryption Key with ICSF ISPF• Obtain Key Label from ICSF Administrator• Use the Sample JCL Provided or the ISPF Panels to generate EDITPROC• Back - Up and Unload Databases• Create EDITPROCS for DB2• Reload the Databases: Data Bases will be Encrypted• Validate your Output
IBM Data Encryption for IMS and DB2 DatabasesImplementation Summary
© 2014 IBM Corporation
IBM Security Systems
IBM Data Encryption for IMS and DB2 DatabasesImplementation Summary
Implementing IMS Encryption with the Data Encryption Tool– Generate Key using ICSF KGUP (Key Generation Update Program)– Prepare your exit using Data Encryption Tool providing ICSF Keylabel– Generate the DBD and ACB(s) to include the COMPRTN value– Unload target database– Activate the ACB to your IMS systems– LOAD the target database– /STA db– Encryption is now operational
© 2014 IBM Corporation
IBM Security Systems
Summary
Encryption is an integral part of a total security package Database encryption provides an additional layer of data security Database encryption adds protection for “data in use”
© 2014 IBM Corporation
IBM Security Systems
IBM Security Guardium family
SC18-9549 IBM Data Encryption Tool for IMS and DB2 Databases User Guide
Includes an appendix on activating crypto on your hardware
ICSF Manuals
SA22-7520 ICSF System Programmer’s Guide
SA22-7521 ICSF Administrator’s Guide
Redbooks
DB2 UDB for z/OS Version 8 Performance Topics – SG24-6465
Articles
IMS Newsletter article: “Encrypt your IMS and DB2 data on z/OS”
ftp://ftp.software.ibm.com/software/data/ims/shelf/quarterly/fall2005.pdf
For more information
© 2012 IBM Corporation
IBM Security Systems
© 2012 IBM Corporation
IBM Security Systems