"Defense in depth": trench warfare principles for building secure distributed applications

It comes to no surprise, that any microservices, any security controls you use to build applications – will eventually be broken (or fail). Under certain pressure, some components will fail together.

The question is – how do you build your systems in a way that security incidents won't happen even if some components fail. And the data leaks won't occur even if penetration tests are successful.

"Defense in depth" is a security engineering pattern, that suggests building an independent set of security controls aimed at mitigating more risks even if the attacker crosses the outer perimeter.

https://www.cossacklabs.com/blog/defense-in-depth-with-acra.html

Other talks and videos:
https://github.com/vixentael/my-talks

Transcript

1. "Defense in Depth" @vixentael trench warfare principles for building secure distributed applications
2. @vixentael product engineer in security and cryptography OSS maintainer: Themis, Acra cryptographic tools, security engineering, datasec training
3. Bespoke data security solutions and security engineering.
4. speakerdeck.com/vixentael/ defense-in-depth-trench-warfare- principles-for-building-secure- distributed-applications @vixentael
5. Plan for next 40 mins: 1. Intro (OWASP, GDPR, US department of defense) @vixentael 2. Threats in common distributed architectures 3. Defense in Depth for data: why, when, how 4. Acra as example of DiD approach 5. Existing tools and solutions 6. Outro and links
6. @vixentael
7. users (upset, angry) regulations (fines, GDPR, HIPAA, PCI DSS, DPB) @vixentael Why care anyway? business continuity (fines, competitors, legal) service providers are pushing (Google, Apple)
8. GDPR @vixentael Article 32/35: responsibly store and process data according to risks
 
 Article 33/34: detecting data leakage and alert users & controller https://gdpr-info.eu/
9. @vixentael https://gdpr-info.eu/ Article 32
10. @vixentael US Department of Defense
11. @vixentael US Department of Defense https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/ DEFENSEINNOVATIONBOARD_TEN_COMMANDMENTS_OF_SOFT WARE_2018.04.20.PDF
12. @vixentael Google https://support.google.com/cloud/answer/9110914
13. OWASP Top-10 web risks https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project @vixentael • Injection • Broken Authentication and Session Management • Sensitive Data Exposure • XML External Entity • Broken Access Control • Security Misconfiguration • Cross-Site Scripting • Insecure deserialization • Using Components With Known Vulnerabilities • Insufficient Logging and Monitoring
14. @vixentael Data & risks PII User data Service data likes, preferences purchase history logs keys, accesses, API tokens backups configurations locations
15. @vixentael Data & risks compliance risks legal risks reputational risks continuity risks User data Service data reputational risks https://medium.com/@cossacklabs/trick-or-threat- security-losses-for-business-f5b44243d89c
16. Most users trust sensitive data to your app regardless of how well you protect it.
17. @vixentael Typical web architecture
18. @vixentael
19. @vixentael Potential attacks
20. @vixentael
21. @vixentael But we know many security controls!
22. @vixentael encryption & key mngmt AAA WAF honey pots IDS infra mngmt compartmentalization authenticated crypto &
 integrity checks access logging jailbans monitoring data firewall SIEM HIDS DAST SAST KMS HSM PKI TPM honey tokens RTFM dep mngmt UEBA IAM TLS TDE
23. @vixentael Band-aid security model
24. Band-aid security model == Perimeter security @vixentael
25. Band-aid security model == Perimeter security @vixentael
26. @vixentael
27. @vixentael Band-aid security model
28. @vixentael Band-aid security model: risks
29. Defense in Depth – independent, yet interconnected, set of security controls aimed at mitigating multiple risks during the whole application flow
30. @vixentael 1. Security controls do protect data globally 
 (during the whole data flow / app lifecycle). 2. Whatever is the attack vector, there is a defense layer. 3. For most popular attack vectors, we want as many independent defenses as possible. Align security controls
31. use cryptography as global protection layer
32. @vixentael Decryption proxy — web, mobile E2EE – mobile, IoT
33. @vixentael Decryption proxy
34. @vixentael Predictable data flow 2. Write encrypted data to the database. 3. Read data from the database via decryption proxy. 1. Separated encryption and decryption.
35. @vixentael Show me real things!
36. @vixentael Writing data flow
37. @vixentael Reading data flow
38. @vixentael Key model unique per user/app public key
39. @vixentael Key model unique per user/app public key private keys 
 (KMS, HSM)
40. @vixentael Key model unique per user/app public key private keys 
 (KMS, HSM) can’t decrypt can’t decrypt
41. @vixentael Key model IRL
42. @vixentael 1. DB doesn’t know the nature of data. 2. App doesn’t have a way to decrypt data. System compromise
43. @vixentael Encryption itself is not enough
44. @vixentael encryption & key mngmt AAA WAF honey pots IDS infra mngmt compartmentalization authenticated crypto &
 integrity checks access logging jailbans monitoring data firewall SIEM HIDS DAST SAST KMS HSM PKI TPM honey tokens RTFM dep mngmt UEBA IAM TLS TDE
45. @vixentael Encryption itself is not enough github.com/cossacklabs/acra/
46. @vixentael 1. DB doesn’t know the nature of data. 2. App doesn’t have a way to decrypt data. 3. Data is being watched: key management, SQL firewall, monitoring, access control, audit logs. System compromise
47. @vixentael System compromise The only way to attain plaintext from DB – 
 to request it through decryption proxy.
48. @vixentael System compromise Or: compromise the backend app 
 & compromise SQL firewall & compromise proxy and key store & get around logs, SIEM, honey pots The only way to attain plaintext from DB – 
 to request it through decryption proxy.
49. @vixentael Lines of defense
50. @vixentael
51. Defense in Depth = global security controls 
 + band aid security tools.
52. @vixentael
53. @vixentael How to build? 1. Build on your own (start from design).
54. @vixentael How to build? 1. Build on your own (start from design). 2. Use boxed solutions (Oracle).
55. @vixentael How to build? 1. Build on your own (start from design). 2. Use boxed solutions (Oracle). 3. Build using existing tools:
 DB + Acra + SIEM + WAF
 DB + GreenSQL + libsodium + own decryption proxy + IDS + SIEM + WAF
 DB + Acra + AWS + SIEM
56. @vixentael Acra Community Edition cossacklabs.com/acra/ github.com/cossacklabs/acra/ marketplace.digitalocean.com/apps/acra
57. Covered Top-10 web risks https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project @vixentael • Injection • Broken Authentication and Session Management • Sensitive Data Exposure • XML External Entity • Broken Access Control • Security Misconfiguration • Cross-Site Scripting • Insecure deserialization • Using Components With Known Vulnerabilities • Insufficient Logging and Monitoring
58. Key points
59. @vixentael 1. Security == 2. Defense in Depth == independent, yet interconnected controls. 3. Cryptography == good core level for DiD. 4. Ready-to-use tools exist. Use them.
60. Reading, watching
61. https://medium.com/@cossacklabs/12-and-1-ideas-how-to-enhance-backend-data- security-4b8ceb5ccb88 12 and 1 ideas how to enhance backend data security https://medium.freecodecamp.org/preventing-leaks-and-injections-in-your-database- be3743af7614 How to prevent database leaks and injections https://www.cossacklabs.com/blog/defense-in-depth-with-acra.html Building Defence in Depth for your data using Acra https://samnewman.io/talks/insecure-transit-microservice-security/ Insecure Transit - Microservice Security
62. @vixentael cryptographic tools, security consulting, training github.com/vixentael/ my-talks