AWS Runtime Protection Implementation

This document describes how CloudGuard Serverless Runtime Protection is implemented. It explains what permissions and resources are used by CloudGuard and the effects they have on the runtime performance of serverless functions.

In addition, it explains how the Serverless Runtime Protection is added to a serverless function as an AWSClosed Amazon® Web Services. Public cloud platform that offers global compute, storage, database, application and other cloud services. Layer, and what it does at runtime.

Serverless Implementation

CloudGuard Serverless runtime protection is implemented as an AWS layer that is added to each function that is to be protected in runtime. This can be done in the build stage with the Serverless CI/CD Tools, or after the functions are deployed to an AWS account (that is onboarded to CloudGuard). This is done with the CloudGuard portal or API.

The layer communicates with the CloudGuard backend in runtime through these procedures:

  • Use a dedicated S3 bucket to receive information from the backend. This S3 bucket is created when the Serverless Protection is enabled for an account (after the account is initially onboarded to CloudGuard). This is done through the CloudGuard portal. The bucket serves all functions in the account (each function has a different folder for communication from the backend to the layer).

  • Use the function log group, to send information to the backend. The layer writes log messages to the log group, in the same way, and to the same group, as the function itself. The layer then parses the log group for its messages and forwards them to the CloudGuard backend.

Serverless Runtime Protection Module

Serverless Runtime Protection is added to each protected function as an AWS layer.

The layer does these activities:

  • Monitors and blocks (if runtime protection policy prescribes so) function activities.

  • Reads on the CloudGuard backend the runtime protection policy from a folder in an S3 bucket created in the user's AWS account.

  • Writes information on the function log group as log strings, which is then forwarded to the CloudGuard backend.

Permissions

The Serverless Runtime Protection uses the same IAMClosed Identity and Access Management (IAM) - A web service that customers can use to manage users and user permissions within their organizations. permissions as the function to which it is added.

When the AWS account is enabled for serverless protection in CloudGuard, cross-account IAM permissions are added to all functions to let the module connect with the S3 bucket and the log group.

Instrumentation of the Serverless Runtime Protection Module

Instrumentation is the procedure of adding the Serverless Runtime Protection as a layer in the function. Instrumentation is done on each function individually. Runtime protection is enabled on each function individually with the CloudGuard portal or API.

In the instrumentation procedure, these activities are done:

  1. The function configuration is changed to include the Serverless Runtime Protection (this change depends on the language of the function).

  2. The Serverless Runtime Protection is copied from the CloudGuard AWS account and added to the function.

Function Languages and Layer Sizes

These languages and frameworks are supported for runtime serverless protection:

  • Python

  • Node.js

  • Java

  • .NET Core

The Serverless Runtime Protection layer has different sizes.

Runtime Layer Name ZIP Layer Size (MB)

Extracted Layer Size (MB)

.NET Core

cloudguard-fsp-csharp-layer

1.8

6.6

Node

cloudguard-fsp-nodejs-layer

4.1

14.6

Python

cloudguard-fsp-python-layer

3.2

10.8

Java

cloudguard-fsp-java-layer

4.3

11

Using Serverless Runtime Protection

When you complete the instrumentation stage, the Serverless Runtime Protection can be added to the function at these times:

  • In the CI/CD pipeline, with the Serverless CI/CD Runtime Protection Tool

  • When the function is deployed in the cloud account with the Enable Runtime Protection function from the CloudGuard portal (Serverless assets page) or API

These two methods invoke a Serverless Runtime Protection injector function, which is deployed in the customer AWS account when Serverless protection is enabled.

Runtime Activity

The Serverless Runtime Protection is run each time the function is invoked.

The module operates in two modes:

  • Profiling function activity

  • Monitoring/enforcing runtime protection

These modes are described below.

Profiling (allowlist)

The Serverless Runtime Protection monitors all function activities and writes this information as log group messages [3], which are then forwarded to the backend [5]. The backend analyzes this information and creates an allowlist that represents the usual, baseline activity for the function (the user can view this allowlist on the CloudGuard portal and change it by adding exclusions).

This profiling continues until the backend writes an allowlist to the S3 bucket [1] and instructs the Serverless Runtime Protection to start enforcing it [2]. The profiling period is typically when the function is first invoked after being deployed, or after it is changed.

Monitoring and Runtime Protection Enforcement

When instructed by the backend (with the use of the S3 bucket) [2], the Serverless Runtime Protection starts to enforce the allowlist.

It monitors activities done by the function and checks for actions not on the allowlist. It reports these events as log group messages [3] (which then become CloudGuard Alerts). It can be configured to block these actions. This is calculated by user settings when runtime protection is applied to the function.

The module monitors these actions of the function in runtime:

  • Inputs

  • File access

  • Host connections

  • API actions

  • Processes that the function launches

Runtime Protection Policy (Allowlist)

The module receives information from the CloudGuard backend that shows which of the above actions are usual (allowlist) actions. The module monitors the actions of the function

Users can change the allowlist by creating exclusions, which add actions to the allowlist.

Connection to CloudGuard Backend

The module communicates with the CloudGuard backend to receive profile information and to send log messages for profiled or monitored activities.

For communications from the backend, an S3 bucket is used (with a dedicated folder for each function)

For communications to the backend, the Serverless Runtime Protection sends log messages to the function log group.

Runtime Performance

Serverless Runtime Protection has a minimal effect on the runtime performance of the function. The table below summarizes the effect of different actions taken by the module in terms of time and memory.

The latency and memory overheads for the actions represent the average time for the performance of one action, for example, one file access. FSP Init represents the overhead that the module introduces on each execution regardless of the action done by the Lambda function. The overheads of File, Process, and AWS API include the FSP Init overhead.

The table below shows the average reading captured for over 1000 invocations of a Python 3.8 function with and without the Runtime Protection module.

Action

Latency (ms)

Memory Overhead (MB)

Cold Start

1

11

FSP Init

0.22

0.05

I/O

0.38

0.39

File access

0.33

0.53

Process launch

5.27

0.19

Network connection

0.05

0.01

AWS API

0.57

0.28