4.5 Enterprise SaaS Security: Discovered Apps, Data Security & SSPM

4.5 Enterprise SaaS Security: Discovered Apps, Data Security & SSPM

Why the Blueprint Lists SaaS Security Twice

Task 3.2.3 requires you to explain SaaS Security as a Cloud-Delivered Security Service component, and task 5.3 asks about "data encryption, access control, and monitoring and logging in the configuration and maintenance of Enterprise DLP and Enterprise SaaS Security." Section 6.3 covered Enterprise DLP. This section covers the SaaS half, and the distinction the exam cares about is which of the three SaaS Security capabilities solves which problem.

Palo Alto Networks SaaS Security is an integrated CASB (Cloud Access Security Broker) solution. Candidates routinely lose marks by treating "CASB" as a single feature; it is three architecturally different things sold under one umbrella.

---

The Three Capabilities

Exam Trap Alert: Two of these names changed in Strata Cloud Manager. SaaS Security API is now Data Security and SaaS Security Inline is now Discovered Apps. Exam items and documentation may use either the legacy or the current label, so learn the function, not just the name.

1. SaaS Security Inline — the shadow IT problem

SaaS Security Inline discovers and manages the risk posed by unsanctioned SaaS applications. It is built into Prisma Access managed by Strata Cloud Manager, and it natively integrates with NGFW and Prisma Access tenants managed by either Panorama or Strata Cloud Manager.

Mechanically, it does not add a new inline component. After activation it automatically discovers all SaaS applications and users and analyses SaaS activity and usage data from your Prisma Access or NGFW logs stored in the Strata Logging Service. From those logs it builds an application dictionary with risk attributes, ranks risky applications and risky users, and produces policy recommendations that a firewall administrator converts into Security policy rules.

Typical output an administrator acts on:

• Hundreds of discovered file-sharing, collaboration, and generative-AI applications nobody procured.
• Per-application risk scoring covering hosting country, compliance certifications, breach history, and data-handling terms.
• Per-user risk ranking that surfaces the small number of accounts responsible for most unsanctioned uploads.

2. Data Security (SaaS Security API) — the sanctioned-app problem

Data Security connects to sanctioned applications through their vendor APIs rather than through the traffic path. Because it is out of band, it can retroactively scan content that was uploaded years before the firewall ever existed.

It performs at-rest detection, inspection, and remediation across all user, folder, and file activity within sanctioned apps, and it provides User Activity Monitoring using a combination of machine learning, predefined and user-defined data patterns, security configuration controls, and access to event logs auditing user access and activity on each cloud app.

The practical difference from inline: if an employee shared a folder of customer records publicly in 2023, only the API-based scan will ever find it. Inline inspection only sees traffic that crosses the firewall today.

3. SSPM — the misconfiguration problem

SaaS Security Posture Management detects and remediates misconfigured security settings in sanctioned SaaS apps through continuous monitoring. You onboard each application instance under Configuration > SaaS Security > Posture Security > Applications > Add Application, choosing the vendor tile and connecting either with administrator credentials or with an admin API token that has read access to the vendor's API. SSPM then scans the instance against best practice and suggests a remediation for every misconfigured setting it finds.

This is the only one of the three that never looks at content. It looks at whether MFA enforcement is on, whether external sharing defaults are permissive, whether legacy authentication protocols are still enabled, and so on.

---

Where SaaS Security Meets Enterprise DLP

The three capabilities share the Enterprise DLP (E-DLP) data profiles described in section 6.3. You define a data profile once — for example, a profile combining a credit-card pattern with a customer-name dictionary — and it can be evaluated by inline inspection in the traffic path and by API-based scanning of data at rest. That shared definition is why the blueprint pairs Enterprise DLP and Enterprise SaaS Security in the same task.

                +--------------------------+
                |  Enterprise DLP          |
                |  data profiles/patterns  |
                +-----------+--------------+
                            |
        +-------------------+-------------------+
        v                                       v
  SaaS Security Inline                    Data Security (API)
  (data in motion, via                    (data at rest, via
   NGFW / Prisma Access logs)              SaaS vendor APIs)

---

Licensing

The documented entitlements are:

• A Data Security license plus an NGFW or Prisma Access license, or
• A SaaS Security Inline license, or
• A SaaS Security Posture Management license, or
• A bundle that contains one of the above.

The bundles are the ones worth memorising:

Role-based access is separate from licensing. Administrators are granted access under System Settings > Identity and Access in Prisma Access managed by Strata Cloud Manager, and to manage SaaS Security comprehensively a user must also be an administrator for the SaaS Security Inline app.

---

Console Consolidation

The standalone SaaS Security web interface at https://<tenant-name>.aperture.paloaltonetworks.com/ was retired on 30 November 2024. All SaaS Security functionality now lives inside Strata Cloud Manager under Configuration > SaaS Security. Any answer or runbook that sends an administrator to the Aperture URL is out of date.

---

Decryption Is a Hard Dependency for Inline Visibility

SaaS applications are delivered over TLS. Without SSL Forward Proxy decryption (section 3.1), inline analysis sees only the SNI and certificate, which is enough to name the application but not enough to distinguish upload from download, identify the tenant instance, or evaluate a DLP data profile against the payload.

This produces a common design sequence in exam scenarios:

1. Enable decryption for the relevant URL categories and user groups.
2. Enable SaaS Security Inline so activity data flows into the analysis.
3. Review Discovered Apps and risky users.
4. Convert policy recommendations into Security rules that allow the sanctioned tenant and block or coach the unsanctioned ones.
5. Add Data Security for at-rest scanning of the sanctioned apps and SSPM for their configuration.

Tenant-Level Control

Blocking "cloud storage" wholesale is rarely acceptable, because the corporate tenant of the same vendor must keep working. App-ID plus HTTP header insertion lets a rule permit the corporate tenant of a SaaS application while blocking personal tenants of the identical application — the granular control that makes "allow the sanctioned instance, block the rest" enforceable rather than aspirational.

---

Generative AI Applications

Unsanctioned generative-AI usage is discovered through exactly this pipeline. SaaS Security Inline provides immediate visibility into the GenAI applications users are reaching so that shadow-IT risk can be discovered, managed, and controlled with granular policy, while Data Security supplies at-rest inspection inside sanctioned GenAI applications such as enterprise ChatGPT deployments. Section 9.4 covers the runtime protection of AI applications themselves; this section is about discovering and governing their use.

Exam Trap Alert: Match the tool to the data state. Inline = unsanctioned apps and data in motion. Data Security (API) = sanctioned apps and data at rest, with no traffic path involvement. SSPM = configuration posture, never content. A question describing "sensitive files shared publicly two years ago" is always an API/Data Security answer, never an inline one.