Download Field Encryption Presentation - Raz-Lee

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 5201 1234 5554 0830
• Masked
**** **** **** 0830
• No data
-------------------
iSecurity Suite of Products
PCI, HIPAA,
SOX, JSOX,
FDA, Local
Regulations,
Auditor’s
Requests…
Security
Breach
Management
Decision
Security
Assessment
(free)
Auditing
Protection
•
•
•
•
•
•
•
•
•
•
•
•
Encryption •
Database
Audit QAUDJRN, Status…
Real-time Actions, CL scripts
Capture screen activity
Compliance: Users, Native, IFS
Change Tracker
User Provisioning
Firewall FTP, ODBC,… access
Obtain Authority on Demand
Monitor CL Commands
Password Reset
2 Factor Authentication
Anti-Virus protection
•
DB2 Field Encryption (FIELDPROC)
PGP Encryption
•
•
AP-Journal DB Audit, Filter, Alerts, SIEM
DB-Gate Native SQL to Oracle, MSSQL..
•
FileScope Secured file editor
3
Evaluation
VisualizerBusiness
Intelligence for
Security
Compliance
Evaluator
for SOX, PCI,
HIPAA…
SIEM/DAM
Support
Syslog, SNMP
Central Admin
Multi LPARs
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
Characteristics
• 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
Supports Multi LPAR Environments:
Multiple Data Managers Using One Key Manager
Several Production
LPARs, files encrypted via a single Key
Manager
Key Manager
on a different LPAR
Token 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 ConsumptionStronger 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:
After encryption:
BATTERY, CARD, PEN
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
User
Authority
Sees
John
Clear text
5201 1234 5554 0830
Mark
Masked
**** **** **** 0830
Dave
No data
-------------------
Thank You!
Please visit us at
www.razlee.com
[email protected]