Encryption DB2 Field Encryption for IBM i

The Need for Encryption PCI-DSS, HIPAA, FDA 21 CFR Part 11, and other regulations Use cases: Credit Card Numbers, Personal Information, Passwords, Account numbers, ID numbers, Medical info… Restricting access is sometimes sufficient, but encryption is stronger. It is the last line of defense. Segregate the way data is displayed: Clear text Masked **** **** **** 0830 No data

3 iSecurity Suite of Products Evaluation Visualizer- Business Intelligence for Security Compliance Evaluator for SOX, PCI, HIPAA… SIEM/DAM Support Syslog, SNMP Central Admin Multi LPARs Auditing Audit QAUDJRN, Status… Real-time Actions, CL scripts Capture screen activity Compliance: Users, Native, IFS Change Tracker User Provisioning Protection Firewall FTP, ODBC,… access Obtain Authority on Demand Monitor CL Commands Password Reset 2 Factor Authentication Anti-Virus protection Database AP-Journal DB Audit, Filter, Alerts, SIEM DB-Gate Native SQL to Oracle, MSSQL.. FileScope Secured file edito r Security Assessment (free) PCI, HIPAA, SOX, JSOX, FDA, Local Regulations, Auditor’s Requests… Security Breach Management Decision Encryption DB2 Field Encryption (FIELDPROC) PGP Encryption

iSecurity Encryption Part of Raz-Lee’s iSecurity suite, using the same standards, same auditing capabilities, same superior technology and same support Product was developed following IBM’s announcement of 7.1 FIELDPROC; there is no need for backward capability with outdated technology Supports both Encryption and Tokenization simultaneously 3 tier software: Data Manager- the database to be encrypted Key Manager- where keys are stored and manipulated Token Manager- required for tokenization only - the token’s vault Supports a single Key Manager / single Token Manager for multiple Data Managers Built to support also multi-site, multi-LPAR organizations

Works transparently with all kinds of applications Supports DDS and SQL defined files Supports Traditional I/O as well as SQL access Supports AES 256, 192, 128 bit encryption Adheres to NIST (National Institute of Standards and Technology) 3 Key Levels: Super Key, Master Key, Data Key Master Keys and Data Keys are segmented, requiring several people to define a single key Characteristics

Supports Multi LPAR Environments: Multiple Data Managers Using One Key Manager Token Manager on a different LPAR Several Production LPARs, files encrypted via a single Key Manager Key Manager on a different LPAR

Product Keys OS400 Master Key protects an Organization Key. Key Encrypting Keys (KEK) are used to protect the Data Key Data Keys encrypt data Organization Key is entered once on each LPAR (including HA). Master, KEK and Data keys can & should be periodically modified. There is no way to see or access any actual key value Comparison of OS400 Keys to iSecurity Keys OS400 Keys have 4 occurrences: Pending => New => Current => Old Data MUST be re-encrypted after key change. iSecurity can keep unlimited concurrent key versions, allowing: Immediate access to old backups The choice when to re-encrypt your data files

Low Performance Consumption- Stronger Encryption Product is optimized to displaying standard masked data. Note that most data accesses are READ, and show masked data. iSecurity keys are hexadecimal based, and make use of all 256 possibilities per byte. This is 10 ^ 13 times stronger. This perhaps allow considering shorter key, and gain performance. The AES encryption algorithm is 4 times faster than TDES. It is also considered by NAS suitable to encrypt “top secret” documents. The master key is not accessible even by QSECOFR or APIs. Key manager can be located on a different LPAR.

Convenience No Locks. Data is ALWAYS available No APIs. Regardless of when or how often keys are changed, the The process of ensuring that data is encrypted by the latest keys is spread to several days and may occurs at night Both Key Encrypting Keys and Data Keys can be set for automatic periodic change. The period can be specified as: Every n days On a specific day of the week On a specific day in the month

Finding Sensitive Data Fields A fully comprehensive system is provided to help you discover ALL your sensitive fields. All Database fields are considered and the product offers selection aids based on field: size, name, text, and column headings. This prevents a situation in which sensitive data is stored as clear text in a copied version of a file.

Do not worry about Traditional IO: READ, CHAIN, UPDATE, DELETE… SQL Level Check (LVLCHK) – It does not change CRTDUPOBJ DSPPFM Query DFU CHGFC (Raz-Lee’s File Editor) CPYF Reorganize Physical File Member (RGZPFM) DB Journal

Implementation Consideration If we encrypt a key field, the file is sorted by the encrypted value. E.g – Item File Original order: BATTERY, CARD, PEN After encryption: CARD, PEN, BATTERY This affects sequential access only. The following continue working properly: ‘BATTERY’ CHAIN ITEMFILE, Select * where ITEM=’BATTERY’ CHGPF SRCFILE(…) to add / remove / change fields in an encrypted file, cause the encryption to disappear. File will be decrypted. The solution is to use SQL ALTER instead. Consider converting DDS to SQL to prevent accidental CHGPF.

Products Parts Setting Encryption Keys Finding Sensitive Fields Defining Authority to See Data Encrypting First Time Setup Defining Key Officers

Entities in the Demo UserAuthoritySees JohnClear text MarkMasked **** **** **** 0830 Dave No data

Please visit us at Thank You!