AWS Serverless Function Runtime Protection

You can apply CloudGuard protection to serverless functions at runtime. This protects functions from malicious inputs or attacks, while it monitors the function behavior for anomalous behavior and acts as a workload firewall for inputs from malicious sources. It does not change the source code of the function and has minimal impact on the function's runtime performance.

Before you apply Runtime Protection to the serverless functions, you must onboard the AWSClosed Amazon® Web Services. Public cloud platform that offers global compute, storage, database, application and other cloud services. environment to Serverless Protection, see Enabling Serverless Protection below.

With Serverless Function Runtime Protection, you can:

  • Apply a workload firewall on inputs to the function, which analyzes the input payloads for malicious attack patterns.

  • Detect and, optionally, prevent anomalous runtime behavior.

  • Use a function-specific profile of actual function behavior, to build an allowlist of normative activity (baseline).

  • Detect or prevent attacks based on anomalous behavior.

  • Get visibility into what the application code is doing, including monitoring process launching, network activity, and API calls.

  • Reduce the effect on function runtime performance.

How it Works

You have two options to apply Runtime Protection in your account:

  • For each serverless function individually or at the account level:

    • To detect issues with Auto Protect

    • To detect and prevent issues with Auto Protect and Block on detect

  • To AWS functions at the CI/CD stage on their deployment in your environment, with the CI/CD Plugin.

When you apply protection, CloudGuard adds a small module to your function that is loaded in runtime, along with the function. This module monitors your function, while it adds some runtime overhead. It is also fully transparent - all reporting is done with the function logs, so you can review the metadata it collects.

Runtime protection dynamically inspects different points in the flow of functions, with mechanisms such as pattern matching, flow analysis, "denylisting" and "allowlisting", and applies policies such as reporting and blocking in response to suspicious activity.

Best Practice - Check Point recommends to enable Serverless Runtime Protection gradually, in several stages.

  1. Enable Runtime Protection on your QA (staging, sandbox) environment.

    • Run your automation tools and make sure everything works properly.

    • Let Runtime Protection work for a while, based on your needs, to create an allowlist.

    • Make sure the allowlist is accurate, there is no false positive.

  2. Enable Runtime Protection on your production environment with the Detect mode. Make sure everything works properly.

  3. Enable Runtime Protection on your production environment with the Detect and Prevent mode.

Allowlist

When you enable runtime protection for a serverless function, CloudGuard uses machine learningClosed The process of using mathematical models to predict outcomes versus relying on a set of instructions. This is made possible by identifying patterns within data, building an analytical model, and using it to make predictions and decisions. Machine learning bears similarity to how humans learn, in that increased experience can increase accuracy. techniques to profile the function in runtime and to create an "Allowlist" of its normative (permitted) actions. This includes:

  • Processes

  • Files and local storage accessed

  • API functions (some calculated by a code analysis, some by runtime monitoring, which may include cases of code injection)

  • External hosts accessed

  • Network addresses communicating with the function

The Runtime Protection tab shows the Allowlist for a function. You can manually add activities to the Allowlist when you configure exclusions (Creating Serverless Functions Exclusions) or remove actions when you configure rules (Creating Serverless Functions Rules).

Rules and Exclusions

You can manually add or remove actions to the Allowlist. In this procedure, you can adjust the Allowlist that is automatically created when the function is profiled.

Rules remove actions from the allowlist, and exclusions add actions.

The Rules & Exclusions tab shows the rules and exclusions configured for a function.

Note - These rules and exclusions apply to the serverless function only. The rules and exclusions you configure on the Cloud Security Posture Management (CSPM) level apply to all functions and the environment.

Events

CloudGuard creates an event notification when it detects anomalous runtime behavior or malicious inputs. You can see these notifications for each function individually or on the Events page, together with notifications from other functions and other CloudGuard sources.

The table below lists the runtime alert messages created by Serverless Runtime Protection.

Alert Name

Description

Command Injection Attack

In Command Injection, the attacker extends the default functionality of the application, which runs system commands, without the necessity of injecting code. If successfully exploited, the effect could include loss of confidentiality, loss of integrity, loss of availability, and/or loss of accountability.

Code Injection Attack

Someone tried to run arbitrary code in the function.

A successful attack can compromise the application's confidentiality, integrity, availability, or loss of accountability.

CSV Injection Attack

A successful attack can hijack the user's computer by exploiting vulnerabilities in spreadsheet software, such as CVEClosed The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities and exposures.-2014-3524. Or it can hijack the user's computer by exploiting the tendency to ignore security warnings in spreadsheets downloaded from their website or exfiltrate contents from the spreadsheet, or other open spreadsheets.

Local File Inclusion Attack

Someone tried to access a file that the function did not initially intend to access. A successful attack usually results in sensitive data leakage. In addition, it can cause code execution through a file that contains attacker-controlled data, compromising your application confidentiality, integrity, or availability.

NoSql Injection Attack

Someone tried to change the intended logic of the query. A successful NoSQLClosed Set of nonrelational database technologies-developed with unique capabilities to handle high volumes of unstructured and changing data. NoSQL technology offers dynamic schema, horizontal scaling, and the ability to store and retrieve data as columns, graphs, key-values, or documents. injection exploit can have an effect on confidentiality, availability, and integrity by reading and changing database data.

SQL Injection Attack

Someone tried to change the initial SQL query of the function. A successful SQL injection exploit can read sensitive data from the database, change database data (Insert/Update/Delete), run administration operations on the database (such as shutdown the DBMS), recover the content of a given file that exists on the DBMS file system and in some cases issue commands to the operating system.

XSS Injection Attack

Someone tried to run malicious JavaScript code. A successful XSS attack can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site.

XML External Entity Attack

Someone tried to access a file or leak its data through a malicious XML payload. A successful attack usually results in sensitive data leakage, communication in the VPC, and more.

File Event

File access detected by CloudGuard as not approved.

Process Event

A production process detected by CloudGuard as not approved.

API Event

AWS API call detected by CloudGuard as not approved.

Host Event

Host call detected by CloudGuard as not approved.

IP Event

IP call detected by CloudGuard as not approved.

HTTP Event

HTTP call detected by CloudGuard as not approved.

Actions

With serverless protection enabled:

  • CloudGuard continuously scans your serverless functions for vulnerabilities and risks - Serverless Risk Assessment

  • You can apply runtime protection to your functions when they are invoked - AWS Serverless Function Runtime Protection

Your AWS account must already be onboarded to CloudGuard. See Unified Onboarding of AWS Environments for details on how to do this.

To enable CloudGuard protection on your serverless functions, you must grant permission to CloudGuard to access these assets in your accounts. In addition, the permissions granted to CloudGuard in the account onboarding procedure. In the procedure described below, you use an AWS CloudFormation (CFT) stack, which you run in your account. To learn more about the CFT resources deployed on your account, see AWS Resources and Permissions for Serverless Runtime Protection.

To enable Serverless Protection:

  1. Navigate to Assets > Environments.

  2. Click Enable Serverless protection for an AWS account from the list.

  3. Follow the instructions on the wizard page that opens. Click Create Cross-Account Role.

    The prompt suggests you sign in to your AWS account and then it redirects you to the CloudFormation page. You can see a CFT stack that grants CloudGuard a cross-account role in your AWS account.

  4. In the AWS console, select the option I acknowledge that AWS CloudFormation might create IAM resources with custom names.

  5. Click Create stack.

    CloudFormation starts to create the stack.

  6. In the AWS console, click the Template tab to view details for the permissions that CloudGuard obtains when the stack is created. After you create the stack, more permissions are granted to CloudGuard, and CloudGuard completes the procedure of enabling protection.

    When complete, the serverless functions appear in the CloudGuard portal in the protected assets list of the environment, on the Protected Assets page, as well as on the Workload Protection > Serverless Functions page.

To enable Runtime Protection in the CI/CD pipeline, before functions are deployed to your cloud account, see Serverless CI/CD Plugin. The pipeline plugin checks the security policy to calculate which functions are configured to have the runtime protection module inserted into them. The insertion is transparent to function behavior and execution.

You can enable Runtime Protection at the account level, so CloudGuard automatically adds the protection layer to all existing and new deployments of the functions found in the account.

To enable Account Auto Protect:

  1. Navigate to Assets > Environments.

  2. Select the environment to enable Auto Protect.

  3. Select the Serverless tab.

  4. Below Account Auto Protect, in Runtime Protection activation, click the toggle button. The Enable Auto Protect Mode window opens.

  5. Select the applicable version of the FSP.

  6. Click Enable.

To apply Runtime Protection to selected serverless functions, see Serverless Functions.

On the IAM Policies tab of the Protected Assets page, you can see the results of the function code scan. It can find different problems of different severity (critical, high, medium, or low). Click the Suggested Policy link to see the suggested policy remediation that you can copy to your clipboard.

Navigate to Assets > Protected Assets , select a function and go to its Threat & Security Events tab. It shows the table of security findings detected by Runtime protection. Click Show in alerts page below the table to see the findings on the Events (All) page (Events). This page shows the table of findings from all CloudGuard features, for all your account entities, though you can filter for the specific serverless function.

When you disable Serverless Protection for your environment, you must delete the Cross-Account role created on your account. This procedure removes the stack created with the CloudFormation Template.

  1. Navigate to Assets > Environments.

  2. Select the environment to disable serverless protection.

  3. Select the Serverless tab.

  4. Scroll down to Serverless Disabling, click Disable Serverless and then click Delete Cross Account Role.

    CloudGuard redirects you to the cloud account on AWS, where you can delete the CFT stack.