Deploy Serverless Defender as a Lambda Layer
Table of Contents
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Deploy Serverless Defender as a Lambda Layer
Prisma Cloud Serverless Defenders protect serverless functions at runtime.
Currently, Prisma Cloud supports AWS Lambda functions.
Lambda layers are ZIP archives that contain libraries, custom runtimes, or other dependencies.
Layers let you add reusable components to your functions, and focus deployment packages on business logic.
They are extracted to the /opt directory in the function execution environment.
For more information, see the AWS Lambda layers documentation.
Prisma Cloud delivers Serverless Defender as a Lambda layer.
Deploy Serverless Defender to your function by wrapping the handler and setting an environment variable.
Secure the Serverless Functions
To secure an AWS Lambda function with the Serverless Defender layer:
- Download the Serverless Defender Lambda layer ZIP file.
- Upload the layer to AWS.
- Define a serverless protection runtime policy.
- Define a serverless WAAS policy.
- Add the layer to your function, update the handler, and set an environment variable. After completing this integration, Serverless Defender runs when your function is invoked.
Download the Serverless Defender Layer
Download the Serverless Defender layer from Compute Console.
- Open Console, then go toManage > Defenders > Deploy> Defenders > Single Defender.
- Choose the DNS name or IP address that Serverless Defender uses to connect to Console.
- Set the Defender type toServerless Defender.
- Select a runtime.Prisma Cloud supports Lambda layers forNode.js,Python,Ruby,C#, andJava. See system requirements for the runtimes that are supported for Serverless Defender as a Lambda layer.
- ForDeployment Type, selectLayer.
- Download the Serverless Defender layer. A ZIP file is downloaded to your host.
Upload the Serverless Defender layer to AWS
Add the layer to the AWS Lambda service as a resource available to all functions.
- In the AWS Management Console, go to the Lambda service.
- SelectLayers > Create Layer.
- InName, entertwistlock.
- ClickUpload, and select the file you just downloaded, twistlock_defender_layer.zip
- Select the compatible runtimes:Python,Node.js,*Ruby,C#, orJava.
- ClickCreate.
Define your Runtime Protection Policy
By default, Prisma Cloud ships with an empty serverless runtime policy.
An empty policy disables runtime defense entirely.
You can enable runtime defense by creating a rule.
By default, new rules:
- Apply to all functions (*), but you can target them to specific functions by function name.
- Block all processes from running except the main process. This protects against command injection attacks.
When functions are invoked, they connect to Compute Console and retrieve the latest policy.
To ensure that functions start executing at time=0 with your custom policy, you must predefine the policy.
Predefined policy is embedded into your function along with the Serverless Defender by way of the TW_POLICY environment variable.
- Log into Prisma Cloud Console.
- Go toDefend > Runtime > Serverless Policy.
- ClickAdd rule.
- In theGeneraltab, enter a rule name.
- (Optional) Target the rule to specific functions.
- Set the rule parameters in theProcesses,Networking, andFile Systemtabs.
- ClickSave.
Define your Serverless WAAS Policy
Prisma Cloud lets you protect your serverless functions against application layer attacks by utilizing the serverless Web Application and API Security (WAAS).
By default, the serverless WAAS is disabled.
To enable it, add a new serverless WAAS rule.
- Log into Prisma Cloud Console.
- Go toDefend > WAAS > Serverless.
- ClickAdd rule.
- In theGeneraltab, enter a rule name.
- (Optional) Target the rule to specific functions.
- Set the protections you want to apply (SQLi,CMDi,Code injection,XSS,LFI).
- ClickSave.
Embed the Serverless Defender
Embed the Serverless Defender as a layer, and run it when your function is invoked.
If you are using a deployment framework such as SAM or Serverless Framework you can reference the layer from within the configuration file.
Prerequisites:
- You already have a Lambda function.
- Your Lambda function is written for Node.js, Python, or Ruby.
- Your function’s execution role grants it permission to write to CloudWatch Logs. Note that theAWSLambdaBasicExecutionRolegrants permission to write to CloudWatch Logs.
- Go to the function designer in the AWS Management Console.
- Click on theLayersicon.
- In theReferenced Layerspanel, clickAdd a layer.
- In theSelect from list of runtime compatible layers, selecttwistlock.
- In theVersiondrop-down list, select1.
- ClickAdd.When you return to the function designer, you’ll see that your function now uses one layer.
- Update the handler for your function to be twistlock.handler.
- Set the TW_POLICY and ORIGINAL_HANDLER environment variable, which specifies how your function connects to Compute Console to retrieve policy and send audits.
- In Compute Console, go toManage > Defenders > Deploy > Single Defender.
- ForDefender type, selectServerless.
- InSet the Twistlock environment variable, enter the function name and region.
- Copy the generatedValue.
- In AWS Console, open your function in the designer, and scroll down to theEnvironment variablespanel.
- ForKey, enter TW_POLICY.
- ForValue, paste the rule you copied from Compute Console.
- For ORIGINAL_HANDLER, this is the original value of handler for your function before your modification.
- ClickSaveto preserve all your changes.