Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JS Fest 2019. Анастасия Войтова. "Defense in depth": trench warfare principles for building secure web applications

37 views

Published on

It comes to no surprise, that any micro-services, 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 we build our 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. During the talk, we will model threats and risks for the modern web application, and improve it by building multiple lines of defense. We will overview high-level patterns and exact tools from the security engineering world and explain them to the modern web devs ;)

Published in: Education
  • Be the first to comment

  • Be the first to like this

JS Fest 2019. Анастасия Войтова. "Defense in depth": trench warfare principles for building secure web applications

  1. 1. "Defense in Depth" @vixentael trench warfare principles for building secure distributed applications
  2. 2. @vixentael product engineer in security and cryptography OSS maintainer: Themis, Acra cryptographic tools, security consulting, training
  3. 3. Data protection tools to prevent leakage and comply with regulations.
  4. 4. speakerdeck.com/vixentael/ defense-in-depth-trench-warfare- principles-for-building-secure- distributed-applications @vixentael
  5. 5. Plan for next 45 mins: 1. Intro (OWASP, leaks, GDPR) @vixentael 2. Threats in common web architectures 3. Defence in Depth for data: why, when, how 4. Acra as example of DiD approach 5. Existing tools and solutions 6. Outro and links
  6. 6. @vixentael
  7. 7. users (upset, angry) regulations (fines, GDPR, HIPPA, PCI DSS, DPB) @vixentael Why care anyway? business continuity (fines, competitors, legal) Google, Apple
  8. 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. 9. @vixentaelhttps://gdpr-info.eu/ Article 32
  10. 10. @vixentael Google https://support.google.com/cloud/answer/9110914
  11. 11. 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
  12. 12. @vixentael Data & risks PII User data Service data likes, preferences purchase history logs keys, accesses, API tokens backups configurationslocations
  13. 13. @vixentael Data & risks compliance risks legal risks reputational risks continuity risks User data Service data
  14. 14. Most users trust sensitive data to your app regardless of how well you protect it.
  15. 15. @vixentael Typical web architecture
  16. 16. @vixentael
  17. 17. @vixentael
  18. 18. @vixentael Potential attacks
  19. 19. @vixentael
  20. 20. @vixentael 🤔But we know many security controls!
  21. 21. @vixentael Band-aid security model
  22. 22. Band-aid security model == Perimeter security 🏆 @vixentael
  23. 23. Band-aid security model == Perimeter security 🏆 @vixentael
  24. 24. @vixentael
  25. 25. @vixentael
  26. 26. @vixentael Band-aid security model
  27. 27. @vixentael Band-aid security model: risks
  28. 28. Defense in Depth – independent, yet interconnected, set of security controls aimed at mitigating multiple risks during the whole application flow
  29. 29. @vixentael 1. Security controls protect data globally 
 (during the whole data flow / app lifecycle). 2. Whatever is the attack vector, there is a defense layer. Defense in Depth 3. For most popular attack vectors, we want as many independent defenses as possible.
  30. 30. use cryptography as global protection layer
  31. 31. @vixentael Decryption proxy
  32. 32. @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.
  33. 33. @vixentael Writing data flow
  34. 34. @vixentael Reading data flow
  35. 35. @vixentael Key model unique per user/app public key
  36. 36. @vixentael Key model unique per user/app public key private keys 
 (KMS, HSM)
  37. 37. @vixentael Key model unique per user/app public key private keys 
 (KMS, HSM) can’t decrypt can’t decrypt
  38. 38. @vixentael DiD in real life github.com/cossacklabs/acra/
  39. 39. @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
  40. 40. @vixentael System compromise The only way to attain plaintext from DB – 
 to request it through Acra.
  41. 41. @vixentael System compromise Or: - compromise the backend app 
 & compromise SQL firewall & compromise Acra and key store & get around logs, SIEM, honey pots The only way to attain plaintext from DB – 
 to request it through Acra.
  42. 42. @vixentael Lines of defense
  43. 43. Defense in Depth = global security controls 
 + band aid security tools.
  44. 44. @vixentael How to build? 1. Build on your own (start from design).
  45. 45. @vixentael How to build? 1. Build on your own (start from design). 2. Use boxed solutions (Oracle).
  46. 46. @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
  47. 47. @vixentael cossacklabs.com/acra/ Acra Community Edition github.com/cossacklabs/acra/ marketplace.digitalocean.com/apps/acra
  48. 48. 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
  49. 49. Key points
  50. 50. @vixentael 1. Security == 💰💰💰 2. Defense in Depth == independent interconnected controls. 3. Cryptography == good core level for DiD. 4. Ready-to-use tools exist. Use ‘em.
  51. 51. Reading, watching
  52. 52. 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
  53. 53. Talks & training github.com/vixentael/ my-talks training.cossacklabs.com
  54. 54. @vixentael product engineer in security and cryptography OSS maintainer: Themis, Acra cryptographic tools, security consulting, training

×