PSE Prisma Cloud Professional key terms

The central web interface where administrators configure policies, view alerts, manage cloud accounts, and run investigations. It aggregates findings from posture, runtime, and application security modules into one tenant.

A REST interface that lets teams automate onboarding, policy export, alert retrieval, and reporting. Scripts authenticate with access keys and call versioned endpoints, which is how most integrations with ticketing and SIEM tools are built.

Credential pair used to authenticate programmatic calls to the Prisma Cloud API. Access keys carry the permissions of the role assigned to them, so they should be scoped narrowly and rotated regularly.

Permission model that assigns users roles such as account group admin, auditor, or viewer, limiting what each person can see or change. Roles can be scoped to specific account groups and collections.

A logical container of cloud accounts, often organized by business unit, environment, or geography. Policies, roles, and reports can be scoped to an account group so teams only manage their own scope.

The process of connecting a cloud provider subscription or project to Prisma Cloud, typically through a read-only role or service principal. Onboarding enables inventory discovery, posture checks, and optionally runtime sensors.

The practice of granting Prisma Cloud a limited identity that can list and describe resources but not modify them. This least-privilege approach is the default recommendation for posture scanning.

The set of modules, cloud providers, and resource limits available to an organization based on its purchased subscription. Some features, such as runtime defense or code security, require explicit enablement.

The discipline of continuously checking cloud configurations against security benchmarks and organizational policy. It surfaces misconfigurations such as public storage buckets or overly permissive security groups before attackers exploit them.

A rule that evaluates a cloud resource's configuration, such as requiring encryption at rest or blocking public IP addresses. Each policy defines a severity, a resource type, and a logical condition.

A label such as critical, high, medium, or low that indicates the risk level of a policy violation. Severity drives alert routing, dashboards, and prioritization during triage.

A published standard such as CIS, PCI DSS, or HIPAA translated into a set of checks. Prisma Cloud maps its policies to benchmark controls so teams can report compliance posture per framework.

A generated summary showing pass or fail status against a chosen benchmark, often broken down by account or control. These reports are frequently used for audits and executive reviews.

Expressing security rules in a machine-readable format so they can be versioned, reviewed, and reused across teams. It supports custom policies and consistent enforcement across cloud environments.

Analyzing Terraform, CloudFormation, or Kubernetes manifests before deployment to catch misconfigurations early. Findings appear in pull requests so engineers can fix issues before resources are created.

Protection applied to workloads while they execute, including process monitoring, file integrity checks, and network behavior analysis. It detects threats such as reverse shells or crypto miners that static configuration checks cannot see.

A lightweight agent deployed on hosts or containers that collects runtime telemetry and enforces runtime policies. It reports process, file, and network events to the console for detection and investigation.

A rule evaluated against live workload behavior, such as blocking a suspicious process or alerting on unexpected outbound connections. Runtime policies complement posture policies that only inspect configuration.

Identifying malicious activity by comparing observed runtime actions against known-good patterns or learned baselines. It can flag anomalies like a web server spawning a shell without relying on signatures.

Inspecting container images for vulnerable packages, secrets, and malware before or after they are pushed to a registry. Results help teams block risky images from reaching production.

Continuous scanning of images stored in registries such as Docker Hub, ECR, or ACR. It catches newly disclosed vulnerabilities in images that were already built and deployed.

Identifying open-source libraries and their known vulnerabilities in application dependencies. It produces a software bill of materials and highlights which packages need upgrading.

A structured inventory of components and dependencies in a software artifact. Security teams use it to trace which applications are affected when a new library vulnerability is announced.

The ongoing process of discovering, prioritizing, remediating, and verifying security weaknesses across images, hosts, and code. Prioritization typically weighs severity, exploitability, and exposure.

Ranking findings by factors such as severity, exploit availability, internet exposure, and business criticality. Effective prioritization prevents teams from drowning in low-impact alerts.

Moving security checks earlier in the development lifecycle, such as into code review and CI pipelines. The goal is to fix issues when remediation is cheaper and faster.

Wiring security scanning into build and deployment pipelines so results gate releases. Common patterns include failing a build on critical findings or posting results as pull request comments.

Detecting hardcoded credentials such as API keys or passwords in source code, images, and configuration files. Exposed secrets should be rotated immediately because they may already be compromised.

Graph-based reasoning that links individual misconfigurations and identities to show how an attacker could reach a sensitive resource. It turns isolated findings into explainable, high-impact risk stories.

Exposure created by overly permissive identities, unused credentials, or risky trust relationships. Examples include roles that can escalate privileges or cross-account trusts open to external parties.

Granting only the permissions required for a task and no more. In cloud environments this means scoping IAM policies, avoiding wildcard actions, and removing unused roles.

A recorded policy violation or runtime event generated when a resource or workload matches a rule. Alerts carry context such as resource, account, policy, and severity for investigation.

Configuration that controls which findings generate alerts and how they are routed or suppressed. It can include notification targets, grouping rules, and auto-remediation triggers.

The SOC process of reviewing alerts, validating whether they represent real risk, and deciding on escalation or closure. Good triage uses severity, asset context, and known exceptions.

The structured process of containing, eradicating, and recovering from a confirmed security event. In cloud contexts it often includes isolating workloads, revoking credentials, and preserving forensic evidence.

Automatically correcting a misconfiguration or containing a threat when a policy triggers, such as disabling a public bucket or killing a malicious process. It reduces response time but requires careful safeguards.

Forwarding Prisma Cloud alerts and audit events to a security information and event management platform for correlation with other telemetry. This supports centralized monitoring and long-term retention.

Creating or updating work items in tools such as Jira or ServiceNow when alerts are raised. It assigns ownership and tracks remediation status outside the security console.