Serverless Radar
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
Serverless Radar
Serverless Radar helps you to visualize and inspect the attack surface of the serverless functions in your environment.
Although Prisma Cloud supports multiple serverless environments, currently serverless radar supports AWS Lambda only.
Serverless functions use different interconnect patterns than containers.
Serverless apps are highly decomposed and interact with services using cloud provider-specific gateways, rather than directly with each other or through service meshes.
Security teams can have difficulty conceptualizing these interactions, identifying which functions interface with which high value assets, and pinpointing unacceptable exposure.
Even though cloud providers secure the underlying infrastructure that enables Functions as a Service (including isolating functions from each other), it’s still easy to deploy functions with vulnerabilities, insecure configurations, and overly permissive roles.
The underlying platform might be secure, but sensitive data can still be lost when an insecure function with read access to an S3 bucket is compromised.
Prisma Cloud offers a serverless-specific view in Radar.
Serverless Radar uses a three panel view to show the invocation methods for each function, the services they use, and the permissions granted to access those services.
Layout
Serverless Radar shows you how functions interface with other services in their environment.

The left-most column shows how functions are invoked.
This is known as the trigger or event source.
Triggers publish events, and Lambda functions are the custom code that process those events.
The middle column shows all the functions in your environment.
Functions are colored maroon, red, orange, yellow, or green to let you quickly assess their security posture.
By default, functions are colored by their most severe vulnerabilities, but you can view functions by highest severity compliance issue or runtime events.
For vulnerability results, you must configure Prisma Cloud to scan your functions.
For runtime issues, you must embed Serverless Defender into your functions.
The right-most column shows the services with which each function interfaces.
Drilling into the function data reveals the permissions each function has been granted to access those services.
Lines connect triggers to functions to services, letting security teams to visualize the entire connectivity flow and access rights.
Clicking on individual functions highlights their interconnects in the radar, and opens a pop-up that lets you drill into the details.
Exploring the data
Prisma Cloud finds, scans, and displays the $LATEST version and all published versions of your functions.
Clicking a node in Serverless Radar lets you inspect a function’s configuration and explore all the security-related data that Prisma Cloud has indexed about it.
For example, clicking on the or-test2:$LATEST function opens a popup with summary findings.
This particular function has two high risk compliance issues.
Clicking on the compliance link takes you to a list of compliance issues for the function.

Compliance issue 437 indicates overly permissive access to one or more services.
Expanding the issue reveals the reason why this compliance issue was raised, with a list of non-compliant service access configurations.
One of the misconfigured access policy is for S3.

Returning to the first pop-up window, and clicking into the S3 service, you can see that all the actions for the function’s execution role are tightly scoped, except for the last one.
It allows all actions on all resources, and could easily be an erroneous configuration overlooked when it was pushed into production.

Icons and colors
Nodes are color coded based on the highest severity vulnerability or compliance issue they contain, and reflect the currently defined vulnerability and compliance policies.
Color coding lets you quickly spot trouble areas in your deployment.
Use the drop-down list at the top of the view to choose how you want nodes colored.
- Maroon -- High risk. One or more critical severity issues detected.
- Red -- High severity issues detected.
- Orange -- Medium severity issues detected.
- Yellow — Low severity issues detected.
- Green -- Denotes no issues detected.
- Gray — Prisma Cloud hasn’t been configured to scan this function for vulnerability and compliance issues.To configure Prisma Cloud to scan the function, click on the node, and then clickProtectin the pop-up.
- Alias annotation — AWS lets you create aliases to manage the process of promoting new function versions into production. They’re conceptually similar to symbolic links in the UNIX file system. Prisma Cloud uses a marker to indicate that an alias points to a specific version of a function.Clicking on the node reveals the aliases that point to the function.
Notes
There can be a discrepancy between what the AWS Lambda designer shows your function can do and its effective permissions when IAM permission boundaries are considered.
For example, if a role is set with permission boundary for DynamoDB, then even though the function’s execution role has permission to access DynamoDB, it still might be blocked by the permission boundary.
The function designer in AWS’s console shows that the function has permission to DyanmoDB, but it might not be accurate.

Setting up Serverless Radar
Serverless Radar uses the AWS APIs to discover and inspect the functions in your environment.
Create an IAM user or role for Prisma Cloud, provide the credentials to Console, and then enable Serverless Radar.
With this basic setup, Prisma Cloud will show the triggers, services, and permissions for each function.
Prerequisites:
- Prisma Cloud needs an AWS service account to scan your serverless functions. In AWS, you’ve created an IAM user or role with the following permission policy:{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrismaCloudComputeServerlessRadar", "Effect": "Allow", "Action": [ "apigateway:GET", "cloudfront:ListDistributions", "cloudwatch:GetMetricData", "cloudwatch:DescribeAlarms", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListenerCertificates", "events:ListRules", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListRolePolicies", "lambda:GetFunction", "lambda:GetPolicy", "lambda:ListAliases", "lambda:ListEventSourceMappings", "lambda:ListFunctions", "logs:DescribeSubscriptionFilters", "s3:GetBucketNotification", "kms:Decrypt" ], "Resource": "*" } ] }
- Open Console.
- Go toManage > Cloud accounts.
- ClickAdd account, and configure an xref:~/authentication/credentials-store/AWS-credentials.adoc[AWS account].
- Select the checkbox for the credential.
- ClickAdd.
- For the account just added, select theServerless Radarcheckbox.
- Click the "Add account" button.After Prisma Cloud finishes scanning your environment, you should see your functions in Serverless Radar.
What’s next?
To see vulnerability and compliance information in Serverless Radar, configure Prisma Cloud to scan the contents of each function.