Threat Model Serverless API
•Download as PPTX, PDF•
0 likes•12 views
The document discusses threat modeling serverless APIs. It defines key terminology like vulnerabilities, threats, and risks. It also outlines an example threat modeling process involving understanding system components, documenting trust zones, workshoping vulnerabilities and threats, assessing risks, and having risk owners accept, transfer, or mitigate risks. The goal of threat modeling is for security to be a shared responsibility and to design everything with least privilege to avoid relying on any single control.
Recommended
Recommended
More Related Content
Similar to Threat Model Serverless API
Similar to Threat Model Serverless API (20)
Recently uploaded
Recently uploaded (20)
Threat Model Serverless API
- 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.
- 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!
- 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
- 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%20are%20eight%20main%20methodologies,threats%20faci ng%20your%20IT%20assets. AWS Serverless Lens - Security Pillar https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications- lens/security-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
Editor's Notes
- I wouldn't call myself a daily commentator on all things security breaches, however I am an expert in common sense. What we have seen over “years” is not necessarily surprising to those of us in the industry, but the last couple of months has really put a focus in the spotlight how important security is. With the move to cloud computing - orgs are moving quickly, but forgetting steps along the way. We are constantly told security is the #1 priority, but i propose to you that the silo’ing of cyber away within the org is doing a lot of damage to the perceived security (or not) of cloud. The companies that are in the news are mostly there because of deliberate decisions they made in the past. Many of the breaches or “”disclosures” were avoidable. A lack of corporate leadership caused this mess and they have to do better. Today I want to make the case that building these public facing services with a cloud native serverless mindset would be easier to secure than the alternatives.
- Commenced Feb 2018
- App teams - own it! Ops teams - own it! Make cyber teams job easier.
- Vulnerability is a weakness. Threat is something/someone exploiting a vulnerability Risk is the probability of that threat eventuating (also described via an IMPACT rating as well)
- When deleting data - what about long term backups? How can that data be deleted?
- Lateral network access Vulnerability is unprotected Elastic IP Unauthorised access to API Vulnerability is Library misconfiguration or authorisation/authentication bug Unauthorised access to ec2 Vulnerability is unpatched system or 0 day security bug
- Unauthorised lambda execution Fat lambda (handles GET/POST) Blast radius large Mitigated by IAM principal API gateway
- Unauthorised API access Vulnerability no authentication or authorization Unauthorized access to database IAM least priv Threat of data exfiltration Vulnerability is unencrypted PII data Unauthorised lambda execution (LOW) Separate lambdas for each verb Blast radius small Mitigated by IAM principal API gateway (or more granular if required eg: REST path locked per user) CI/CD pipeline needs to be shown on the diagram! Maybe that has a backdoor vulnerability?
- Dont allow humans to see the data! Single Encryption key for all customer data ? Sure data is encrypted but then if you get the key you can read everyones data (think misconfig) Encryption key per customer ? Much better - then you can delete the key when done and instantly any user data is inaccessible Still have the issue of all data being potentially accessible to all microservices Solve the last issue by having a “service key” Delegate access to the key with a fine grained key policy Combine this with least privilege role IAM controls and you have a fairly good system
- Dont allow humans to see the data! Separate lambda’s for reading and writing data Could have separate lambdas for highly sensitive fields such as passport or drivers license number with scoped down permissions Make use of key policies! Stops humans from ever reading any data
- This might mean pivoting your solution if a risk is not acceptable
- This might mean pivoting your solution if a risk is not acceptable
- This might mean pivoting your solution if a risk is not acceptable