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

RBACv2

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.   

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 “sCASB - DLP - App] Slack Forbes Article ALLOW” and “Collaboration Forbes Article BLOCK” becomes “oCASB - 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. fCASB - DLP - Category] Webmail Forbes Article BLOCK


2. fCASB - Access - App] Block Slack Post


3. fCASB - 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. fCASB - DLP - App] Slack Draft Test


2. fCASB - DLP - Category] Webmail Forbes Article BLOCK


3. fCASB - Access - App] Block Slack Post

Figure 15: Properly Ordered CASB Policies

In Summary

Steering

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.  

RBACv2

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.