Real-time Policy Recommendations

  • 1 August 2023
  • 4 replies

Badge +16

Steer It And You Can See It


It goes without saying that if you cannot see data exfiltration then you cannot stop it from happening.  CASB applications need to be steered in order to be seen, including SSL certificate pinned applications, destination locations, applications (CFW and CASB custom applications), and a few other bypass exceptions.


For reference SSL certificate pinning is when a desktop or mobile application validates if the proposed server certificates match the hardcoded ones in the application. It's a security technique used to prevent man-in-the-middle attacks (MITM).


We recognize some vendor ssl certificate pinned applications by default which need to be bypassed, Amazon Drive for example.  So, in order for end users to use the application without errors resulting, we need to bypass the application traffic and allow it to go directly to the destination.  In order for that to occur, we define the application and the hosts or domains to which it needs to communicate with.  In the example mentioned earlier, we define applications for three different operating systems and the corresponding applications.

FIGURE 1: Sample SSL Certificate Pinned Application


Along with the operating system specific applications, we also define the hosts or domains.

FIGURE 2: Editing a SSL Certificate Pinned Application


In time, application vendors add applications to the list of those which are SSL certificate pinned as well as adding additional hosts or domains outside of what Netskope has previously defined.  As a result a new SSL certificate pinned applications need to be created and/or a custom app domain must be specified until we are able to update the list of predefined applications or add a new SSL certificate pinned application altogether.


This is relevant to DLP in that we need to steer to see if we are to see and protect.  A periodic review of bypasses is in order to ensure that we are in fact needing the SSL certificate pinned application in the tenant or, for that matter, any other bypass in existing steering configurations.


If you don’t need to bypass it, steer it!


A review might be in the form of pulling bypassed information from SkopeIT Page events using a query like “bypass_traffic eq yes” and then wading through a mountain of information, even after exporting the information to a spreadsheet or other method of organization.  (We do not have the bypass reason as an option for SkopeIT Page Events filtering or for standard reporting.)


A more advanced method of determining what is being bypassed is to use Netskope’s Advanced Analytics to provide clarification and, ultimately, make decisions on what to remove from steering configuration bypasses.


FIGURE 3: Advanced Analytics Reporting on Bypasses


By default Netskope steering policies include 55 items, which are:

  • 52 certificate pinned applications;
  • 1 category, comprising
    • Finance/Accounting
    • Internet Telephony
    • Streaming & Downloadable Audio
    • Streaming & Downloadable Video
    • Telecom and Call Center
    • Web Conferencing
  • Local IP address range; and,
  • Domain, comprising quite a few domains and domain wildcards.


Running an Advanced Analytics Report will tell you if users are connecting with or using applications such as the Mozy Application for certificate pinned applications or if there are sites within categories which need to be monitored.  Removing the Mozy Application from the list of bypassed applications will provide you visibility into those who are using the application since errors might be thrown in the off chance that someone decides to install the application on their own.


Block Unused Real-time Traffic Access Methods

If you aren’t going to protect Web, CASB, and other types of Real-time Traffic using all access methods, block those which aren’t used.  There’s no point in allowing connections over Cloud Explicit Proxy if you are not using it in your organization, period.  By blocking unused access methods, another avenue of data exfiltration is removed.


For example, if one user starts to access CASB applications using Cloud Explicit Proxy, traffic using this access method might be lost in the noise of other access methods being seen or reported on, i.e. the proverbial needle in a haystack.


Start with alerting on the access methods not used within your company through Advanced Analytic Reporting and move to blocking after “moving” users to an approved access method such as the Netskope Client.


By default, Real-time Traffic defaults to all access methods for source criteria. 


FIGURE 4: Real-time Protection Policy Block All Unused Access Methods


FIGURE 5: Advanced Analytics Reporting on Non-Support Access Methods


After analyzing the traffic and notifying users of upcoming blocks, it is recommended that a notification such as the following be put in place.  A redirect to a change request page isn’t shown; however, it is advisable to put this in place as well.


FIGURE 6: Unused Real-time Access Method Block Notification


Locate It and Decide On It

When you configure API-enabled Protection, you know where important data for your organization is located.  However, when that important data moves from a CASB application setup for API-enabled protection to an endpoint, we rely on Real-time traffic steering to see what a user is doing with the data.  So, if an end user is moving data with sanctioned or unsanctioned CASB applications, we will see it.

FIGURE 7: Advanced Analytics Reporting on Source and Destination Countries for Sanctioned Applications


FIGURE 8: Advanced Analytics Reporting on Source and Destination Countries for Unsanctioned Applications


FIGURE 9: Advanced Analytics Reporting on Source and Destination Countries for All Applications


Once you have analyzed traffic regarding data within your organization, Real-time Policies come into play.  Real-time Policie using constraints to specific countries are a way to influence the movement of data for your organization.


Figure 10: Sample Real-time Policy Using Constraints



We recommend using Role Based Access Control v2 (RBACv2) within any organization, even if you are not using complex roles and permissions.  RBACv2 allows administrators access into different functional areas depending on their role and scope.  While not a requirement to implement a naming convention similar to that in the next section, it does make it easier when assigning permissions for administrators as well as allow for grouping of policies. 


For example, Firewall (FW) versus Secure Web Gateway (SWG) versus Netskope Private Access (NPA), versus API Protection.  This translates into having groups of policies regardless of the size of an organization.


FIGURE 11: Real-time Policy Grouping with RBACv2


Large enterprise customers have cross functional security and compliance teams that manage different aspects of security functionality. Administration and segregation of duties can be broken down into the following functional access areas:

  • Administrator;
  • Policy Group;
  • Access Control;
  • DLP;
  • Threat Protection;
  • Behavioral Analytics; and,
  • Risk Insights.


Once RBACv2 has been enabled in a tenant, grouping of policies is easier, especially when combined with a policy ordering and naming convention.


While RBACv2 is outside the scope of this document, it is important to note this.


Naming Conventions and Policy Ordering 

Our best practices provide clear guidance on what and where to place real-time policies.  Overtime policies are added, moved around, or otherwise changed that results in a change in the security posture for real-time access methods.  In effect, the original intention of the policy might be lost or overshadowed by subsequent policy changes.


While covering real-time policy best practices is a part of a larger conversation, a discussion of policy ordering and naming is necessary.  We recommend that you adhere to a policy naming convention that makes it easier to “see” what the policy entails and allows for quicker and easier grouping of policies, see table below.   




Sample Names



[Utility - (Type/Technology) - (Misc)] Policy Description


[Utility - Access Method] Block Unused Access Methods


[Utility - CFW] DNS Over HTTPS


[Utility - CFW] DNS Over TLS




[Threat - (Type/Technology) - (Misc)] Policy Description


CFW General

[Threat - CFW General] Sample Policy



[Threat - CFW General] DNS Security


App Instance

[Threat - Malware - Instance] Google Drive Netskope Instance



[Threat - Malware - Application] Google Drive



[Threat - Malware - Category] Google Drive




[CASB - (Type/Technology) - (Misc)] Policy Description


[CASB - (Type/Technology) - SMTP] Policy Description

DLP: Instance ID

[CASB - DLP - Instance] Google Drive Netskope Instance PCI


Instance ID

[CASB - Access - Instance] Google Drive Netskope Instance Sales Access

[CASB - DLP - SMTP - <action>] Policy Description


[CASB - DLP - SMTP - HOLD] Google Mail Customer Privacy Emails


DLP: App

[CASB - DLP - App] Amazon S3 NetEng Custom Policy



[CASB - Access - App] Block All Access Amazon S3


DLP: Category

[CASB - DLP - Category] Webmail PII Block


Category Sanctioned

[CASB - Access - Sanctioned] CRM Sanctioned Alert


Category Unsanctioned

[CASB - Access - Unsanctioned] CRM Unsanctioned Block


Category Personal

[CASB - Access - Consumer] Webmail Block



[CASB - DLP - CCL] Restrict Sharing of Source Code to Low CCL Cloud Storage


Low/Poor CCL

[CASB - Access - CCL] Restrict Access to Low CCL Cloud Storage




[Web - (Type/Technology) - (Misc)] Policy Description


DLP: Category

[Web - DLP - Category] Allow Finance Group PCI Data Uploads



[Web Category] Block Access to Restricted Adult Content




[RBI- (Type/Technology) - (Misc)] Policy Description


[RBI] Newly Registered Domain Read-Only




[NPA- (Type/Technology) - (Misc)] Policy Description


DLP: Web, SSH, etc

[NPA - DLP] Internal Source Code Upload Detections


Web, SSH, etc

[NPA - Web] Internal IIS Web Dev Access


SCCM, DB Mgmt Apps

[NPA - SQL] Access Dev SQL Server

TABLE 1: Real-time Policy Naming Convention


By using the suggested naming convention in the above table, you would be able to quickly and easily move policies based on the naming prefix.  If we apply the naming convention above, we can easily transform policies and provide additional context as well.


FIGURE 12: Policy Renaming Examples


Given the naming recommendations above, the following changes are made.


“Slack Forbes Article ALLOW” becomes “[CASB - DLP - App] Slack Forbes Article ALLOW” and “Collaboration Forbes Article BLOCK” becomes “[CASB - DLP - Category] Collaboration Forbes Article BLOCK”.


FIGURE 13: Policy Renaming Complete


Using the following example policies, in Figure 13 below, we are able to see that the policies are out of order.  Using the top down methodology, once a match is made for a real-time policy, no further processing is done for the activity.  


The improperly ordered policies are as follows.

  1. [CASB - DLP - Category] Webmail Forbes Article BLOCK
  2. [CASB - Access - App] Block Slack Post
  3. [CASB - DLP - App] Slack Draft Test   


FIGURE 14: Improperly Ordered CASB Policies


As far as CASB policies are concerned, we would need to go from application, application category, and access policy.  The policies should be ordered in the following manner.

  1. [CASB - DLP - App] Slack Draft Test
  2. [CASB - DLP - Category] Webmail Forbes Article BLOCK
  3. [CASB - Access - App] Block Slack Post


Figure 15: Properly Ordered CASB Policies


In Summary



Steer everything possible, even if you don’t think it is used within the organization.  Steer.  Let it burn in.  Analyze the results.  Re-steer.  Rinse and repeat.


Real-time Access Methods

Block any steering method you won’t use.  If you are not going to use Reverse Proxy, block it.  If you are not going to use a mobile access method, block it.  Again, block any steering method you are not using.


Locate It and Decide On It

Use Advanced Analytics reporting to determine where your data is located, where it is going, and who is moving it.  Then construct Real-time Policies that influence user behaviors using advanced criteria when defining the policies.  



While not necessary when following suit below, it is highly recommended for ease of grouping and access control when accessing the tenant.


Naming Conventions and Policy Ordering

Use a naming convention that is relevant and recognizable within your organization.  We’ve provided a recommendation or guide, but adapt it to how you do business.  Once you have developed a naming convention, order the policies based on Table 1 mentioned earlier.

4 replies

Badge +12

Hello, where can I find config details on "[Utility - CFW] DNS Over TLS"

Userlevel 3
Badge +10

We block DNS over TLS through the Cloud Firewall configuration as shown:

Badge +12

Thank you. Curious over "[Utility - CFW] DNS Over HTTPS" is this also based on Cloud Firewall?


We had it through Cloud App policy. 



Badge +16

Correct, it is a CASB app whereas DNS over TLS isn't, at least for the moment.