5. #RSAC#RSAC
The evolution of serverless.
Not just functions.
Amazon Aurora
Azure Storage
Accounts
Google
Cloud Run
AWS Lambda
Amazon S3
bucket
AWS Fargate
AWS Serverless
Application Repository
Google Cloud
Functions
16. #RSAC#RSAC
For example: Injection
Code works the same in a function.
String query = "SELECT *
FROM accounts WHERE
custID='"
+ request.getParameter("id")
+ "'";
http://example.com/app/accou
ntView?id=' or '1'='1
String query = "SELECT *
FROM accounts WHERE
custID='"
+ ' or '1'='1 + "'";
24. #RSAC#RSAC
All the rest
Every OWASP top 10 attack applies
OWASP Top 10
Injection
Broken Authentication
Sensitive Data Exposure
XXE
Broken Access Control
Security Misconfiguration
XSS
Insecure Deserialization
CVEs
Poor logging & monitoring
42. #RSAC#RSAC
Logs
Did you know there was an error?
AWS WAF
Amazon CloudFront
AWS Lambda
Amazon API Gateway
Amazon Route 53
Amazon VPC
AWS CloudTrail
Amazon Macie
Trying to buy image on shutterstock but site is broken. Will get it later:
https://www.shutterstock.com/video/clip-1025644553-cybercrime-hacking-technology-concept---female-hacker
I
Might switch up this chart. Was from prior Verizon Data Breach Report.
I
I
I
I
I
There’s no reason why this won’t work in a serverless function the same way it would work in any other web application.
Another example I experienced on a penetration test involving lambda authentication functions.
Another example I experienced on a penetration test involving lambda authentication functions.
Another example I experienced on a penetration test involving lambda authentication functions.
Will probably change this to something more complex embedded in function code. Original presentation was for developers.
Will probably change this to something more complex embedded in function code. Original presentation was for developers.
Will probably change this to something more complex embedded in function code. Original presentation was for developers.
Will probably change this to something more complex embedded in function code. Original presentation was for developers.
I
I
Working on some POCs of unique types of persistence. Possibly include in demo.
I
CSP differences related to IAM.
Cloud environments have more places for secrets to hide. Read-only access exposes those secrets.
If someone can change the policy or has permissions specified in that policy encryption does no good. (e.g. Capital One, though wasn’t serverless, same diff.)
CSP network differences.
Applies in serverless like anywhere else. This has been the cause of a lot of recent breaches (non-serverless as far as we know, but could happen just as easily in a serverless environment).
Poor defaults, configurations.
Some issues with API gateways – improper use of keys, etc.
I
Poor auth implementation using CSP auth services.
Developers are exposing these because now they are in charge. May or may not have DBAs. These things are getting exposed right and left. Will show how to fix that problem.
Also, who can change DNS – is it split DNS or devs exposing it?
Problems with deployment systems…
ALL the logs. Cloud environments have lots of different logs – serverless can be more challenging.
ALL the logs. Cloud environments have lots of different logs – serverless can be more challenging.
How deployment systems solve some of these problems – if implemented correctly.
How deployment systems solve some of these problems – if implemented correctly.