• Michael Man

Serverless : Function as a Service

Updated: May 18

Change is continuous in the world of IT. The next wave is beginning without us knowing and a lot of us are caught out playing catch up with the next best thing.


The evolution of application deployment is a perfect example of this. The list below illustrates the different deployment approaches that I have seen:


  • The use of physical servers, installing applications from a bundle of binaries and associated libraries, as well as deploying other dependencies.

  • Doing the same but with virtual machines (on premise).

  • External providers take this virtual machine concept and start offering it as a service - The Cloud.

  • Software architecture dictates the next move and the technology of containers gains critical mass.

  • Even this is not good enough and here we are, the next best thing is Function as a Service (aka serverless).


There is always two sides of a coin, and change brings opportunities as well as risk. For the security folks, not being able to adapt and stay in tune with changes is a big risk. There is always an element of gamble when you decide which tech or gimmick is worth focusing on; is there ever a good time to start educating one self with the next concept and associate technology - you need to decide.


Food for thought ....



Matthew Joyce was interviewed in episode 3 of DSO Overflow* where he shares his experience with adopting AWS serverless (aka Lambda) technology for one of his projects.


*DSO Overflow is a podcast released as part of the award winning community meetup DevSecOps - London Gathering


In the podcast, Matthew talks about Serverless Framework: https://www.serverless.com/.


For those of you wanting to start experimenting with AWS Lamdba you can go to the developer's guide which walks you through it. For completeness, details for GCP Functions and Azure Functions are also linked here.


If Golang is your thing, then AWS and GCP are platforms you want to try, as Azure does not currently support this.



Here are some serverless references:


  1. AWS Lambda Security Overview

  2. Cloud Security Alliance: 12 Risks For Serverless Applications

  3. OWASP Top 10 (Serverless)


Listed below are some code repos for you to stand things up and play with. Alternatively, you could look at the code to see how the maintainers purposefully introduces security vulnerabilities:


  1. OWASP Serverless Goat

  2. Damn Vulnerable Serverless Application (DVSA)

  3. Damn Vulnerable Functions as a Service (DVFaaS)


A few cool presentations to watch:


  1. An Attackers View of Serverless and GraphQL Apps (AppSecCali 2019)

  2. Hacking Serverless Runtime (Blackhat USA 2017)

  3. Serverless Security Made Simple (Cloud Next '19)


Serverless Security Model: CLAD


I came across the CLAD model for serverless security and found it useful to structure my thinking.


Here's a extract from this report/book:


Code vulnerabilities

When building and deploying a function, security vulnerabilities can be introduced in the code that you write for the function.


Library vulnerabilities

Security vulnerabilities introduced by the use of third-party libraries or dependencies by a function in order to avoid “reinventing the wheel” as much as possible.


Access and permissions

Define resource permissions that the function needs to execute and access in order to work properly.


Data security

Your function might need to access data persistency resources, or transactions, which means that you need to ensure data security, as well.


*Credit to O’Reilly, Guy Podjarny and Liran Tal

AWS Lambda Golang

# Getting Started - AWS Lambda function in Golang
# https://github.com/aws/aws-lambda-go

// main.go
package main

import (
	"github.com/aws/aws-lambda-go/lambda"
)

func hello() (string, error) {
	return "Hello ƛ!", nil
}

func main() {
	// Make the handler available for Remote Procedure Call by AWS Lambda
	lambda.Start(hello)
}

16 views

©2020 by VR Security. Proudly created with Wix.com