Transcript
team. In this series of short videos, we're taking a look at the baseline recommendations for configuring a data protection policy inside ZIA. This is part six, covering the out-of-band data loss prevention policies. To provide out-of-band data protection, Zedscaler leverages API connection with different SAS applications. This is called SAS Security API. SAS Security API allows you to onboard tenants. Over 25 SAS applications are supported. Once these tenants are onboarded, Zedscaler can then scan these SAS tenants to detect and remediate policy violations. The same API connections are leveraged to detect and remove malware inside your SAS tenants as well, protecting them, your users, and your data from malicious files. Additionally, the same connection can be used to continuously assess SAS security posture for these tenants. DLP policy, meanwhile, is applied to data at rest inside these tenants, leveraging the same engines and dictionaries configured for your inline data loss prevention policy. Finally, UEBA alerts can be configured to trigger in case of anomalous user behaviors, such as bulk uploads or downloads of files. Let's talk about the steps required to configure data at rest. First, onboard your SAS tenant. Zedscaler supports API integrations with over 25 SAS applications. Onboarding a tenant is as simple as selecting the SAS application from the menu and then logging in to authorize the SAS application with Zedscaler. Once this is done, you can create policy. Policy, as usual, follows a top-down evaluation. There are 18 total actions that can be configured between all applications. Some actions can only be configured for some applications. As with all data protection policies, evidence collection is also configurable, including sending emails on alerts and integration with incident receiver. Additionally, for file sharing applications, a link to the offending file can be shared with the auditor. Finally, once the SAS tenant is onboarded and policy has been configured, you'll move on to scan configuration. This involves selecting a SAS tenant, selecting policy for both malware prevention and data loss prevention, and selecting the date to scan as well as the frequency for scanning. For example, you can scan all data or only data that's of a certain age or from a certain point onwards. Next, let's take a look at how you can start building a SAS Security API policy for data loss prevention. Here, a very simple report-only policy has been created. This policy is designed to detect sensitive data and report on it. Here, we've created a policy that applies to all users, groups, and departments. Engines has been configured to Any to match all engines, or you can select specific engines if you'd prefer. This policy will need to be configured once for each SAS tenant that you wish to scan. So for example, if you have eight SAS tenants onboarded, you'll need to make this policy a time once for each SAS tenant. The collaboration scope here should be set to Any, and the action should be sent to report incident only to ensure that no blocks happen. Note that before you move on to applying this policy in the scan phase, you should make sure your engines are optimized so that your scan results are accurate. All files will be scanned and logged, and only matched files will be hashed. You should also consider staging scans to manage the number of incoming alerts during this process. Once a scan has been performed, you'll be able to see the results inside the SAS Asset Summary Report. You can then analyze these results and make decisions as to how you'll build a block policy. The process for building, configuring, and iterating on a block policy will not be covered in depth in this video. Please refer to the inline DLP policy video for more details. Next, here's an example policy for SAS Security API malware detection. Here, there's only one thing to configure, which is configuring a scan and an action for every tenant that you wish to secure using the SAS Security API malware detection policy. Actions for this policy can be configured to either remove the file, optionally leaving a configurable tombstone file behind, quarantine the file, moving it to a specific location, or simply report on malware. Obviously, for a more secure policy, we recommend configuring a remove or quarantine policy. The second part of data protection for data at rest is SAS Security Posture Management, or SSPM. SAS Security Posture Management leverages the same SAS Security API, but is available for a smaller number of applications. These include Bitbucket, Confluence, GitHub, Google Workspace, Jira, Microsoft 365, Okta, Salesforce, and Service Now. SSPM includes 400 plus posture checks with continuous evaluation and support for many compliance frameworks. The results of this continuous evaluation can be viewed inside the SAS Security Configuration Report. Here is an example. We have some of the policies applicable to the Bitbucket application using SSPM. Finally, we have third-party app governance. Again, this leverages the same SAS Security API and supports Atlassian, GitHub, Google Workspace, Microsoft Azure, Okta, Salesforce, and Slack applications. Third-party app governance scans your SAS tenants for third-party add-ons and browser extensions. These third-party add-ons and browser extensions are then displayed in the SAS Security Third-Party Application Report. This report includes in-depth risk attributes from research and API sandboxing for each add-on and browser extension, allowing you to make the decision to allow or block these add-ons. The report also allows you to prioritize remediation based on implementation complexity and severity. Controlling add-ons and browser extensions via the third-party app governance policy allows you to ensure that third-party applications that integrate with your SAS applications or with your users' browsers cannot be used to exfiltrate data. Let's take a look at the actions you should take in order to configure data protection policy for your data at rest. First, you should onboard SAS applications tenants. Onboarding SAS applications with Zedscaler is the first simple step in enforcing DLP, malware, and security posture management policies for data at rest. This will allow you to gain visibility and secure sanctioned SAS applications used in your organization, authorize sanctioned SAS applications with Zedscaler by adding them as tenants, and see general information about each tenant, such as authorization status and configured policies. Once you've onboarded tenants, you should configure malware detection for every SAS tenant individually. Adding a malware policy for SAS applications allows Zedscaler to detect and remove malware threats to extend its comprehensive web security to your SAS applications, securing your cloud environment from malware by detecting and remediating it. Next, you should configure a SAS Security API DLP baseline policy, building a policy that applies your dictionaries and engines to your data at rest. Adding a DLP policy for SAS applications provides the ability to detect sensitive data at rest in your SAS applications and take remediation steps to protect against data loss. You should also configure SSPM. SAS Security Posture Management allows you to harden SAS cloud posture by addressing misconfigurations and configuration drift. This allows you to systematically assess, monitor, and improve the security posture of your SAS applications by connecting checks for a collection of recommended security policies. Additionally, it's recommended, if possible, to configure watermarking to protect sensitive files. Once watermarking is configured, you can create separate policy to apply watermarking as an action to your files. This will replace your files with a watermark file containing watermark text, identifying the document and the user. Watermarking will allow you to enhance the visibility of files that trigger your data loss prevention policy. Additionally, you can also configure redaction to replace the data that triggers your DLP policy inside documents with asterisks or hash signs. Finally, you should configure third-party app governance. Configuring your third-party app governance policies enables you to easily and efficiently set and perform automatic actions, such as classifying applications as sanctioned or unsanctioned, and take automated actions, such as revoking, banning, or reviewing these third-party applications. Policies also enable you to set notifications for new applications that are added to the application and to rematching a rule. Automating these actions will further secure your SAS applications from undesired behavior. That's it for this video. Thank you for watching.
