Threat_Modelling_Serverless_APIs.pdf

Current events have put the unauthorised access of customer personal information in the spotlight like never before. A lot of these breaches should never have happened if basic security best practices are implemented.
In this session we will run through an overview of how to threat model a fictitious organisations API and describe ways to mitigate risk to stop unintentional access by third parties. While the title mentions Serverless, the techniques apply for Serverful architectures as well. The talk will use AWS as the cloud of choice, but the choice of cloud is just an implementation detail.

Transcript

1. Threat Modelling your Serverless API Matt Gillard Technical Principal
2. Under the Notifiable Data Breaches (NDB) scheme any organisation or agency the Privacy Act 1988 covers must notify affected individuals and the OAIC when a data breach is likely to result in serious harm to an individual whose personal information is involved. https://www.oaic.gov.au/privacy/notifiable-data-breaches/about-the-notifiable-data-breaches-scheme#:~:text=Under%20the%20Notifiable%20Data% 20Breaches,whose%20personal%20information%20is%20involved.
3. https://www.oaic.gov.au/privacy/notifiable-data-breaches/notifiable-data-breaches-statistics/notifiable-data-breaches-report-july-december-2021
4. https://www.oaic.gov.au/privacy/notifiable-data-breaches/notifiable-data-breaches-statistics/notifiable-data-breaches-report-july-december-2021
5. Source: https://www.splunk.com/en_us/blog/learn/vulnerability-vs-threat-vs-risk.html#:~:text=A%20threat%20is%20a %20malicious,depth%20at%20each%20of%20these.
6. Problems with Enterprise Security Culture • Security by checkbox ◦ CSPM tools implemented without context ◦ Treating all threats equally • Application teams want the app to “just work” • Cloud guardrails deployed inconsistently
7. Security is Everyone’s responsibility!
8. Threat Modelling
9. Terminology • Vulnerability • Threat • Risk
10. Requirements • Internet accessible API • User signs up and provides Name/Address/Identification information • Keep PII secure from unauthorized access • Delete data when no longer needed
11. - Lateral network movement - Unintended external access from Internet - Unauthorised access to Database - Threat of data exfiltration - Unauthorised access to ec2 - Unauthorised access to api HIGH HIGH HIGH HIGH
12. - Unauthorised API access - Unauthorised Lambda function execution - Unauthorised access to Database - Threat of data exfiltration LOW MEDIUM MEDIUM
13. - Unauthorised API access - Unauthorised Lambda function execution - Unauthorised access to Database - Threat of data exfiltration MED LOW LOW LOW LOW (with field encryption)
14. Example - Mitigate unauthorized data exfiltration with application encryption • A single encryption key for all data? • A single encryption key per customer? ❌ ✅ • Encrypt again with a service key! ✅
15. Example - Mitigate unauthorized data exfiltration with application encryption
16. Function Policy Definition Read Only Database permissions Read Only Secrets Manager permissions Decrypt Only KMS with RequestAlias condition key
17. If the secrets manager key is deleted - not possible to decrypt field Otherwise pass in field to decrypt, KMS alias and secrets mgr key Store ciphertext in the DB as base64, so decode first First decrypt with KMS service key Second decrypt with unique user key
18. Demo
19. Microsoft STRIDE Model https://learn.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20) https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats Spoofing Identity Tampering with data Repudiation Information Disclosure Denial of Service Elevation of privilege
20. https://github.com/OWASP/threat-model-cookbook/blob/master/Template/BLANK/BLANK-dr aw.io.onepager.xml.pdf
21. Summary • Security is everyone’s responsibility • Everything should be least privilege ◦ This means you are not relying on any one control for protection • Complexity adds threats • Workshop threat modelling on your next project!
22. References https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html Different methodologies: https://www.exabeam.com/information-security/threat-modeling/#:~:text=There%20 are%20eight%20main%20methodologies,threats%20facing%20your%20IT%20assets. AWS Serverless Lens - Security Pillar https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/se curity-pillar.html https://github.com/OWASP/threat-model-cookbook
23. Threat Modelling 1 Understand all the things
24. Threat Modelling 2 Document trust zones
25. Threat Modelling 3 Workshop all potential vulnerabilities and corresponding threats
26. Threat Modelling 4 Risk assess each threat and allocate owner Probability Impact High High Medium Medium Low Low
27. Threat Modelling 5 Owner of risk to Accept/Transfer/Mitigate
28. Thank You contino.io continohq contino London london@contino.io New York newyork@contino.io Melbourne melbourne@contino.io Sydney sydney@contino.io Atlanta atlanta@contino.io Brisbane brisbane@contino.io