In the complex landscape of cloud security, ensuring that sensitive data remains protected and that threats are neutralized is paramount. Netskope, as a leading Secure Access Service Edge (SASE) platform, employs sophisticated content inspection engines for both Data Loss Prevention (DLP) and Threat Protection. However, no system is infallible, and there are specific scenarios where these engines might fail to reach a definitive verdict. This is where "Fallback Actions" come into play.
This article will break down the concept of Fallback Actions in Netskope, differentiating the conditions and implications for DLP and Threat Protection separately, while leveraging a clear tabular format for easy comparison.
What is a Fallback Action in Netskope?
A Fallback Action in Netskope is a pre-defined safety measure triggered when the content inspection engine — whether for DLP or Threat Protection — fails to complete its analysis on a file or transaction. Instead of leaving the outcome uncertain, the system reverts to a pre-configured action (e.g., allow, alert, or block) to manage the risk. This mechanism ensures that even when a full inspection isn't possible, a controlled response is still executed.
The core conditions that trigger a Fallback Action are fundamentally the same across both DLP and Threat Protection, as they both rely on the underlying content inspection infrastructure. These conditions represent technical limitations or errors in processing:
| Condition | Description |
| 1. File Size Limit Exceeded | The size of the file being processed (uploaded or downloaded) is larger than the maximum file size configured for scanning within the respective DLP or Threat Protection settings. Large files demand more resources, and exceeding configured limits can prevent a full scan. |
| 2. Scanning Timeout | The content inspection engine requires more time than the maximum allowed (the "timeout value," often configurable up to 300 seconds) to complete its analysis of the file. This is common for very large, complex, or highly nested archive files. |
| 3. Internal System Error | An unexpected error within the Netskope content inspection system or a temporary component failure prevents the scan from finishing successfully. |
Differentiating Fallback Actions for DLP and Threat Protection
While the triggering conditions for a fallback are similar, the context, configuration, and primary security objective of the scan lead to important distinctions in how Fallback Actions are managed and perceived for DLP versus Threat Protection.
Here’s a detailed comparison:
| Feature | Data Loss Prevention (DLP) Fallback | Threat Protection (TP) Fallback |
| Primary Goal of Scan | To determine if a file contains sensitive data (e.g., Personally Identifiable Information (PII), payment card data (PCI), intellectual property, confidential documents, source code) that should be prevented from exfiltration. | To determine if a file contains malware, viruses, and other advanced threats that could compromise the organization. |
| Typical Configurable Max File Size | Often has a smaller maximum configurable file size limit for content inspection. For instance, common limits might be up to 128 MB for detailed DLP analysis, as extremely large files are less likely to contain a singular, concentrated sensitive data chunk requiring full scan. | Generally supports a larger maximum configurable file size limit. For example, some configurations allow up to 400 MB or more, as malware can be embedded within larger executables or archives. |
| Trigger Logic | Fallback is triggered because the system could not conclusively determine if the file matches any configured sensitive data profiles (e.g., GDPR, PCI, custom regex). The verdict of "contains sensitive data" or "does not contain sensitive data" could not be reached. | Fallback is triggered because the system could not conclusively determine if the file contains malicious code or is benign. A definitive malware verdict (clean or malicious) could not be rendered. |
| Available Fallback Actions | DLP configurations typically offer three distinct fallback options: Allow, Alert, or Block. The choice depends on the organization's risk tolerance for data exfiltration when inspection fails. | Threat Protection configurations often prioritize security, commonly supporting Alert or Block as the fallback options. An "Allow" option might exist but is generally discouraged due to the higher risk of threat introduction. |
| Interaction with Uninspectable Files | If a file is inherently uninspectable due to encryption or password protection (e.g., a password-protected ZIP or Azure Information Protection (AIP) protected file), Netskope generates a specific consolidated bypass alert named "All DLP Policies." This is distinct from a Fallback Action, as the inspection wasn't even attempted, due to file inaccessibility. | Threat Protection also encounters uninspectable files, but depending on configuration, specific features like "Block till Benign Verdict" (Patient Zero capability) might be employed. This pre-emptive blocking is a different mechanism than a general fallback triggered by a scanning failure. |
| Alert Name on Console | When a DLP Fallback occurs, the alert name in the console will typically be "Fallback Action" and specify the relevant DLP profile or a generic "DLP" context. | When a Threat Protection Fallback occurs, the alert name will also be "Fallback Action" and specify the Threat Protection profile or a "Threat Protection" context. |
Conclusion
Understanding Fallback Actions is crucial for effective cloud security management. While both Netskope DLP and Threat Protection share common triggers for these actions (file size, timeouts, internal errors), their implementation reflects their distinct security goals. DLP prioritizes preventing sensitive data loss, while Threat Protection focuses on blocking malware. By carefully configuring the respective file size limits, timeouts, and most importantly, the fallback actions themselves, organizations can ensure robust security postures that account for the inevitable complexities of real-time content inspection in the cloud. Knowing when and why a fallback occurs allows security teams to fine-tune policies, optimize performance, and minimize exposure to both data exfiltration and advanced threats.
