Securing Data Within SAAS Applications

A SaaS Takeover of Corporate Data

A new paradigm of publicly available, Internet-based applications has emerged over the past decade that has resulted in a massive shift from internally deployed commercial applications to those that are cloud-based. The first major manifestation of this shift was the adoption of Software as a Service (SaaS) applications developed, sold and maintained by vendors, such as, NetSuite, Microsoft, Box, and Dropbox.

However, because the typical SaaS environment is invisible to network administrators, enterprise security tools designed to protect internal data centers, servers and workstations can't effectively protect SaaS applications or prevent data leakage.

The SaaS model makes it possible for technically unsophisticated users to acquire and use applications without taking adequate steps to protect enterprise data. The use of unsanctioned (at least by IT) SaaS applications (so-called "shadow IT") can create a risk of major data leakage and regulatory noncompliance, whether by accident or malicious intent. Even if SaaS users are aware of the need for security, their ability to protect data is dependent on tools provided by the vendor, which may not be sufficient for the task.

As a result, SaaS applications represent an enticing threat vector for attackers because they provide gaps in security visibility and the potential for threat transmission directly into a target network.

Aperture, Palo Alto Networks® SaaS security service, adds additional security to the Palo Alto Networks Next-Generation Security Platform, providing key insight into data and threat exposure within sanctioned SaaS applications. Aperture addresses the problem of SaaS application security by connecting directly to SaaS applications and providing administrators with data classification, visibility into sharing and access rights, and threat detection. Aperture is integrated with WildFire™ cloud-based malware analysis environment to protect company data residing within SaaS applications against the threat of external attacks and subsequent data leakage or regulatory noncompliance.

Whether you've just implemented Palo Alto Networks products or have been administering them for years, make sure you're maximizing their full value by reviewing best practices for securing data within SaaS applications.

As with any technology, there is usually a gradual approach to a complete implementation, consisting of carefully planned deployment phases meant to make the transition as smooth as possible, with minimal impact to your end users. With this approach in mind, we recommend a phased approach to implementing Aperture. The goal for your SaaS security implementation should be to end up with a robust set of policies to identify sanctioned, unsanctioned, and tolerated SaaS applications, and protect the data they house.


  • Use the "SaaS Application Usage Report" under the Monitor tab within the Palo Alto Networks NGFW user interface to identify SaaS applications currently in use.
  • By enabling User-ID within your NGFW, you can identify those users who are accessing the unsanctioned SaaS applications and then take steps to migrate them to sanctioned SaaS applications.
  • Label sanctioned SaaS applications as such within the NGFW user interface for better detail within usage reports.

PHASE 1: Visibility and Risk Assessment

First, take steps to identify those SaaS applications that are in use today, sanctioned or unsanctioned. Communicate with business units and technology leaders throughout the organization to determine which SaaS applications they have sanctioned for their users. Any SaaS applications you discover that are not explicitly sanctioned by your business leaders should be regarded as unsanctioned; of these, figure out which you're willing to tolerate by analyzing their risks to the organization.

For each sanctioned application that has been identified, assess the security features provided by the vendor and identify any security gaps that may be of concern. For example:

  • Who can access the application and its data; for instance, how or whether the application allows sharing with users who are outside the organization
  • How authentication is enforced, and does the application support two-factor authentication
  • How sensitive the data stored within the application is; for instance, if it falls under PII, PCI, or any other compliance standard
  • File encryption features, and how the keys are managed
  • File types supported by the application and their potential use in delivering threats

The result of this analysis will help you to determine which features and security policies should be implemented on both Aperture and the NGFW and in what sequence.

Figure 1: The SaaS Application Usage Report provides valuable SaaS application information, including which applications are being used, the number of sessions and amount of data moved by each user, and breakdown file types and malware detected


  • You can set up multiple Aperture administrator accounts and require that administrators log in using specific IP addresses or subnetworks.
  • Because the Aperture service uses the internal domain list to determine the exposure level of an asset during the scan process, you must create your internal domain list for the app before you begin scanning supported SaaS applications.
  • Tailor Aperture's content identification to your organization by uploading examples of documents commonly uploaded to your sanctioned SaaS applications, such as legal documents, source code, purchase orders, etc. Aperture can extract metadata and/or textual content from more than 100 file formats.
  • A rule can be in the "enabled" or "disabled" state. Make sure to enable new policy rules after you add them if you want them to be active during subsequent scans.

PHASE 2: Creating Sanctioned SAAS Application Policy

Because Aperture is a pure SaaS application, it does not require the installation of any hardware or resident software on your systems. Simply log on to your Aperture administrator account, using credentials provided by Palo Alto Networks, and change your administrator password.

Connect supported SaaS applications to Aperture by authenticating to the application using an administrative account. Upon authentication, the Aperture service receives a token from the cloud app, which it uses to establish and maintain a secure connection. The Aperture service then connects directly to the application programming interface (API) for the specified application, enabling it to scan all historical data that resides within it, monitor changed or new data, and identify policy violations and their associated risks.

Because both internal and external users may have access to the SaaS application, configure trust levels within Aperture for the SaaS application by identifying internal email domains, which Aperture uses to distinguish between collaborators who are internal or external users. You can also tag external users or domains as trusted or untrusted, which affects the underlying global policy that the Aperture service uses when scanning assets.

Review the list of external collaborators for personal email addresses. These may belong to employees or business partners; however, if and when these people are no longer affiliated with the company, they will still be able to access company assets shared with their personal email addresses.

Aperture defines four exposure levels:

  • Public – accessible to anyone on the Internet
  • External – shared with individuals, groups or companies outside your organization
  • Company – explicitly shared with individuals or groups within your organization
  • Internal – not explicitly shared (but, based on the particular application, others within your organization may be able to access the document via a link, for example.)

If a scan reveals that the exposure level for an asset has been exceeded, that will generate an alert.

Figure 2: The Aperture UI provides visibility into potential data exposure, regulatory non-compliance, and threats hiding within sanctioned SaaS applications

Aperture contains policies that are enabled by default, including:

  • Payment Card Industry (PCI) compliance
  • Personally Identifiable Information (PII) compliance
  • Sensitive credentials
  • Sensitive documents
  • Untrusted users – identifies files that have been shared with users in the untrusted user or untrusted domain list
  • WildFire analysis – scans files to detect malicious portable executables (PEs) and known threats based on file hash

You can also create custom policies that use keywords or regular expressions to identify policy violations. Aperture also includes a policy to identify source code.


  • You can configure email templates to use for commonly encountered alerts. These will be sent to users who violate your enabled SaaS application policy.
  • If an asset violates the WildFire Analysis policy rule, it means that WildFire identified malware in the asset. You can view the associated WildFire Report to learn about the malicious behavior WildFire observed and track down the source of the malware within your network.
  • When you delete an i ncident category, all risks that have been tagged with that category are automatically marked as uncategorized

PHASE 3: Policy Violations and Action

Aperture includes retroactive policy enforcement. When you add a new SaaS application, Aperture scans it and gathers detailed information about all users, metadata, and file contents. During this initial scan, Aperture identifies and sorts risks and exposures by severity for every asset across all supported SaaS apps. You can view the sorted list of risks in the Aperture Dashboard.

When a scan generates an alert, the following actions are available to you, depending on the type of alert:

  • Relocate an asset to another folder.
  • Remove some or all sharing of the asset – for example, remove public sharing and leave only company-wide sharing.
  • Remove a collaborator's access to that asset or all assets
  • Assign to another administrator who is more familiar with the content and its proper use for follow up.
  • Send a risk notification email to a user to warn and educate them about acceptable usage policies.
  • Dismiss the alert after determining that neither the asset content nor the way it is shared endanger the organization.
  • Use WildFire to track down threats.

After the initial scan is completed, Aperture will automatically continue to scan the SaaS application in near-real time to detect future policy violations.

Over time, as you gain more experience with Aperture, you may decide to either add a new policy rule, or fine-tune an existing policy rule.

Figure 3: Separate SaaS applications into three groups: sanctioned apps granularly managed through Aperture; tolerated apps controlled through the NGFW; and unsanctioned apps monitored or blocked via the NGFW

You can also assign an incident category to a risk, which makes it easier to filter and view risks by category, speeding up your ability to detect and respond to specific types of risks. Default categories include: Testing, Personal, Business-justified, Dismissed, Review, Incident, False positive, and Unreviewed. You can customize this list to either add or delete a risk category.

Aperture works in conjunction with the NGFW as part of the Next-Generation Security Platform to mitigate risks to your organization from unsanctioned SaaS applications. An extensive App-ID library within the NGFW provides instant classification and fine-grained controls for unsanctioned SaaS applications you choose to tolerate, providing you with the ability to control access at a granular level.

Remember, you still have features on the NGFW that allow you to control the level of interaction your users have within applications being used. Limit access to tolerated SaaS applications on the NGFW by allowing only select groups of users to access them or by disallowing certain file types from being uploaded, downloaded, or shared. Block unsanctioned SaaS applications altogether on the NGFW for the entire company or for groups of users.