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

by Thierry de Pauw on

#cfgmgmtcamp

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