Upgrade to Pro — share decks privately, control downloads, hide ads and more …

"Defense in depth": trench warfare principles f...

"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

vixentael

April 05, 2019
Tweet

More Decks by vixentael

Other Decks in Programming

Transcript

  1. @vixentael product engineer in security and cryptography OSS maintainer: Themis,

    Acra cryptographic tools, security engineering, datasec training
  2. 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
  3. 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)
  4. 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/
  5. 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
  6. @vixentael Data & risks PII User data Service data likes,

    preferences purchase history logs keys, accesses, API tokens backups configurations locations
  7. @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
  8. @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
  9. Defense in Depth – independent, yet interconnected, set of security

    controls aimed at mitigating multiple risks during the whole application flow
  10. @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
  11. @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.
  12. @vixentael Key model unique per user/app public key private keys

    
 (KMS, HSM) can’t decrypt can’t decrypt
  13. @vixentael 1. DB doesn’t know the nature of data. 2.

    App doesn’t have a way to decrypt data. System compromise
  14. @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
  15. @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
  16. @vixentael System compromise The only way to attain plaintext from

    DB – 
 to request it through decryption proxy.
  17. @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.
  18. @vixentael How to build? 1. Build on your own (start

    from design). 2. Use boxed solutions (Oracle).
  19. @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
  20. 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
  21. @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.
  22. 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