20200203 - CfgMgmtCamp 2020 - Automating Security Response with Serverless, Michael Ducy

Automating Security Response with Serverless, Michael Ducy @mfdii

• serverless overview
• security response with serverless
  • MLGuard
  • Falco and security playbooks
• takeaways

Serverless Benefits

• faster time to production: only deploy your code
• no servers to manage
• fine-grained metering: control the flow of requests, control the load, ...
• continuous scaling
• easily integrate with cloud infra: via IAM roles

two types:
- event-driven
- triggers a function based on an event
- message queues, pub/sub, HTTP webhook
- periodic execution: based on time (hourly, daily, etc.)
example: unused environment reaper to reduce cloud costs

Open Source serverless: fragmented

Most popular:
- Knative: Kubernetes Native Serverless - heavy focus on deployment versioning, blue/green, scaling
- Kubeless: Simple Functions as a Service - very easy, stupid simple
- Apache OpenWhisk: package your code as a container

MLGuard

• overcomes the limitations of Web Application Firewalls WAFs are static and easy to evade: they are signature-based => zero-day exploits, can be easily bypassed metaphor: adding a motion detector in case the front door gets broken open
• provides anomaly detection: serverless-based machine learning system to detect malicious web requests

Profile an IP based on the HTTP requests that are send in:
- 40x: 1 - that looks good vs 40x: 35 - that looks suspicious

Requires training.

MLGuard in one month at Frame.io:
- 527 IPs reported by MLGuard
- 229 IPs blocked by MLGuard

Falco

• a behavioural activity monitor
  • detects suspicious activity defined by a set of rules
• open source

Anomaly detection:
- containers are isolated processes: when you run ps you don't expect to see unknown processes as is sometimes the case with VMs
- processes are scoped as to what's expected
- container images are immutable, but container runtime environments often aren't => hacker try to get a shell inside the container
- how do you detect abnormal behaviour?

=> kernel instrumentation

all kernel calls done by separate containers are send back to Falco, Falco analyses these calls

Falco rules: YAML file containing Macros, Lists and Rules
- Macro: define conditions that are reused over again in Rules

Falco + CloudWatch + Lambda
- Falco: detects abnormal events, publishes alert to stdout
- Cloudwatch logs collect events
- Lambda functions augment events with metadata

Takeaways

• easily write simple functions to react to operational events
• your infrastructure is now available via an API (if it runs in a public cloud)
• multiple subscribers can take multiple actions
  • one function to delete a pod
  • one function to notify teams
  • one function to log events
  • one function to block traffic
• small, reusable components