Preparing for Your Netskope Implementation

July 13, 2023

When customers perform a proof of concept/value of Netskope, the scope of testing typically is limited to a certain subset of users. This limited focus tends to sometimes reduce the exposure of overall use cases a customer may encounter during a production deployment. In my conversations, I’ve found that the most common challenge customers experience are cloud applications that do not work correctly.

Illustrating this problem for context, Netskope is a proxy technology. Instead of routing traffic directly to a destination, Netskope brokers communications between the user and the application/website that they are trying to access. To identify the actions being performed and the data that users may be uploading or downloading, Netskope decrypts most traffic between the user and the service they are accessing. However, because applications do not always like a technology like Netskope performing SSL decryption, they may “break.”

If you are using Optiv as your implementation partner, we highlight areas that may present challenges for customers, as well as offer advice on averting potential issues during rollout. Since 2021, I have talked to numerous customers who didn’t use Optiv to implement Netskope in order to address the challenges encountered during implementation. This blog will focus on the NextGen Secure Web Gateway and Cloud Inline products to help new customers be more prepared to implement Netskope.

Let’s dive into the common issues I have seen customers run into during a production rollout.

Policy Ordering

Netskope can see and enforce granular activities that a user performs with a cloud application. But customers often put in policies to outright restrict an application from being used, while allowing a certain subset of users to perform specific actions within this application. These controls are enforced by Netskope’s Real-time Protection Policies.

Netskope’s policy structure operates in a top-down approach. When policy criteria are met, the policy is enforced. Any remaining policies are usually not inspected. There is a DLP use case that subsequent policies can be inspected, which I have commonly seen set up for customers that have a robust data protection team and process.

I have seen many instances where customers have policies out of order, leading to users experiencing issues when interacting with an application or with being unintentionally restricted from using a cloud application. Situations like this usually happen when policy governance is not followed—leading to out-of-order policies or even overlapping policies that cause conflicts.

Netskope has a detailed guide on best practices for real-time policies, which you can find on their community site.

SSL Decryption

Some applications do not mind having a proxy in the middle of the session. However, they may break or function improperly when the traffic is decrypted. Within Netskope, customers can implement do-not-decrypt policies to prevent decrypting the session. Implementing a do-not-decrypt policy, Netskope will still proxy the traffic and be able to report that a user went to a cloud application. However, one will not be able to enforce threat protection, DLP policies, or granular access/action policies, as Netskope won’t be able to see what is happening within the user’s session.

Do-not-decrypt policies should not be used as a go-to solution when issues arise with an application. Prior to implementing do-not-decrypt policies, one should perform proper troubleshooting with an implementation partner or Netskope support.

Steering Bypass

Another subset of applications exists that will break or function incorrectly even with a do-not-decrypt policy in place. Some of these applications do not like a proxy in the middle of the session, while others use certificate pinning.

Applications that use certificate pinning are usually locally installed on a machine and are not browser based. Common examples of these applications are developer tools, command-line utilities, cloud storage sync clients, and even web conferencing tools. Some of these applications use their own certificate store and do not rely on the operating system certificate store. In this case, one can install the Netskope certificates into the application’s trusted certificate store.

For applications that do not allow certificates to be installed into their certificate store, or for applications that do not like a proxy in the session, traffic needs to be bypassed from being routed through Netskope. In most deployment cases, customers are still able to log traffic that is bypassed from being steered to Netskope, but they cannot use policies to protect the traffic.

The lack of support for certificate pinned applications isn’t a Netskope issue. Other vendors in the cybersecurity market are also not able to handle certificate pinned applications and need to bypass the interception of their traffic Customers deploying Netskope who have never had another tool performing SSL decryption often run into this scenario and rush to blame Netskope for breaking the application or causing an outage.

Netskope currently maintains 50+ certificate pinned application exceptions for clients. However, customers may need to create a steering exception for industry-specific applications. Prior to implementing a steering bypass, customers should work with their implementation partner or with Netskope support to validate that a bypass is indeed needed and there isn’t another method to rectify the situation.

How Can Customers Prepare for Implementation?

Customers can prepare for the above situations in a couple of ways. The first is to attempt to understand all of your environment’s in-use applications. One can do this by adding additional users from other business units into your Netskope proof of concept/value to identify potential issues up front and to learn how to properly troubleshoot and identify how the above methods may address the issue.

If additional users can’t be included to the proof of concept/value, sometimes customers have a detailed list of applications installed on machines and the owners of those applications. Customer implementation teams can work with the application owners for those respective applications to identify if their application does in fact use certificate pinning.

For customers that have never had a secure web gateway or have not done any decryption of internet-bound traffic, it is important to educate their users and management that interruptions could occur during rollout. Any customer—no matter the organizational size—that is implementing any SSL decryption—no matter the vendor product—will most likely run into issues with applications not working correctly. Preparing management for this situation helps prevent the knee-jerk "turn it off” reaction when users start complaining that they can’t work. Educating users on the proper issue reporting process and requirements will facilitate a timely resolution.

These are some—but not all—common issues that customers encounter during deployment. It is imperative that customers work together with an implementation partner like Optiv to share information up front and identify any areas of concern prior to a production rollout.

How Optiv Can Help

If you are using Optiv for your implementation services, we bring to light these common issue areas when we begin implementation projects with our customers. Optiv’s implementation plan stresses the use of pilot groups to identify these issues on a smaller scale prior to a larger production rollout. For customers that may have used another company to implement Netskope, Optiv can assist with addressing and rectifying issues in our Optimization, Subject Matter Expert, or Maturity services.

If you are interested in hearing more about these services, please reach out to me or your Optiv sales team.

For more information on Optiv’s Netskope services and partnership, please visit: https://www.optiv.com/partners/netskope