This talk focuses on various encryption technologies available to Application Developers to protect sensitive data. Encrypting data at different layers addresses different attack vectors.
This talk starts with history of encryption, and explores the following:
* Disk Encryption
* Application Level Encryption
* Transparent Data Encryption (TDE)
* DB Internals and TDE
* Secure Encryption Gateways (SEG)
* Attack Vectors for each of the above
* Best practices wrt Key Management
Unveiling Design Patterns: A Visual Guide with UML Diagrams
Encryption in the Age of Breaches
1.
2. Let’s talk numbers!
“Only 4% of the total breaches involved data that was encrypted ...”
• 888 breaches across all verticals – Healthcare, Retail, Government
• Malicious Outsider – 62%
• Malicious Insider – 12%
• 80% of the attacks were in North America
• < 1% in South America
245 million records compromised in H1 of 2015
Source: 2015 H1 SafeNet Breach Level Index Report
4. Symmetric vs Asymmetric
• One key to encrypt and decrypt
• Example: DES, AES
• Length of the key improves
security
• Example: AES-128 vs AES-
256
• Used often in Disk/File/Database
encryption scenarios
• Two Keys
• Example: RSA
• Sender encrypts with Receiver’s
Public Key
• Receiver Decrypts his Private
Key
• Length of the key improves
security
• Example: RSA-1024 vs
RSA-3072
6. Attack Vectors
Attacks against DBs
• Weak Auth.
• Injection Attacks
• MITM
• Attacks against Backups
• Attacks against DB memory
• Attacks against data at rest
Attacks against Crypto (Cryptanalysis Attacks)
• Chosen Plaintext
• Known Plaintext (Alan Turing Used this)
• Chosen Cipher text
• Known Cipher text (and some other info)
7. Data Encryption in the Enterprise
• Disk/File Level Encryption
• Application Encryption
• Database Encryption
– Transparent Data Encryption
– Column Level Encryption
– Encryption Gateways
These techniques have important differences
8. Encryption Benefits
• Reduce Attack Surface
"I love crypto. it tells me what part of the system not to bother attacking"
- Drew Gross, Forensic Scientist
• Protect Sensitive Data
“Crypto won't be broken. It will be bypassed ”
- Adi Shamir, Cryptographer
• Get to compliance Faster
• CYA
9. Disk Encryption
• Can be used to encrypt disk/partition/files
• Possible in most OSs
– Example: dm-crypt on most Linux flavors
• Cloud technologies such as AWS, Azure etc.
support native Disk Encryption.
– Key Management: KMS (AWS), Key Vault (Azure)
• Often used for DB encryption
– Simply encrypt volume containing /data dir.
10. 1. Disk Encryption: Attack Vectors
Attack Vector Disk Encryption
Stolen Disk
Corruption of data (AEAD)
× (rarely)
Attacks against Backups
×
Attacks against memory
×
Notes:
• DIY has many pain points.
• However, Cloud platforms ease away most of these pain points
• Low hanging fruit.
• Actual Security benefits are debatable
12. Application Encryption: Attack Vectors
Protection against Attack Vector App Encryption
DB Credential Compromise
Attacks against DB Backups
Attacks against DB Memory
MITM
Notes:
• Prone to error. Needs developers with expertise.
• Peer Reviews, IV & V is a must
• Constant upgrade/upkeep needed
• Reporting/Migration use cases need further thoughts
13. DB Internals
• Page Size = 8 KB (in Postgres)
• A table with 800 KB has ~100
pages
• File size in disk ~ 800 KB
• Each page has one or more
rows of data (called ‘tuples’)
14. Memory Page Structure (Postgres)
Source: Bruce Momjian (https://momjian.us/main/writings/pgsql/internalpics.pdf)
16. More on TDE
• Fully transparent to applications
• Can be implemented at database, schema,
tablespace, or table level
• No need to change data types, stored procs,
indexes etc.
• Supported by DB Vendor directly
– No need of third party solutions or products
• Performance impact:
– Between 4 – 15%, depending on use case
– Negligible for read heavy applications
17. TDE: Attack Vectors
Protection against Attack Vector Disk Encryption
Stolen Disk
Corruption of data (AEAD)
(rarely)
Attacks against Backups
Attacks against memory
×
SQL Injection
×
MITM
×
18. 4. Column Level Encryption (CLE)
• All DBs have ‘functions’ to do crypto
– Encryption
– Hashing
– Key stretching
• Queries to use these functions:
insert into demo(col1) values (encrypt('data', 'key', 'aes'));
• Key Management Support is poor
19. CLE: Attack Vectors
Protection against Attack Vector Disk Encryption
Stolen Disk
Attacks against Backups
Attacks against memory
×
Corruption of data (AEAD)
×
Notes:
• Prone to error. Needs developers with expertise.
• Peer Reviews, IV & V is a must
21. More on Encryption Gateways
• Quick way to do column level encryption
• Easy to deploy
• No changes to the applications
– But DB datatypes, stored procs may need to change
– Can’t index or query encrypted columns
• Can act as a DB firewall
– Detect attacks like ‘SQL Injection’, ‘DDoS’ before they
get to DB
• Performance Impact:
– About 15% overall
22. EG: Attack Vectors
Protection against Attack Vector Disk Encryption
Stolen Disk
Attacks against Backups
Attacks against memory
Corruption of data (AEAD)
SQL Injection Attacks
Cross Site Scripting (Stored) ….. [maybe]
MITM
23. Challenges
• Key Storage/Isolation
– Where do you store the keys?
– Impact on DevOps
– Who owns the keys
• Protecting Keys
– In memory
– At rest
• Key Rotation
• Backup/Restores
• HA, AutoScaling etc.
24. Best Practices
• Always use HSMs
• Don’t invent your crypto or crypto library
• Use tried and tested crypto libraries
• Isolate keys from data
– And from your code.
– Don’t check into GitHub
• IV & V code, and implementation
– There are only a few firms that could do this!
There was a time when …
As a result a lot of SMBs and startups are not using encryption. Because with encryption, it is cost, complexity and time-to market.