The purpose of this article is to highlight issues and recommendations related to the production implementation of a Netskope solution, based on our experiences using the technology in the field. The article is not intended to replace the existing Netskope documentation, but rather to supplement it with ideas that should be considered when embarking on an implementation project. This paper is not aimed at beginners with Netskope. It assumes an understanding of the Netskope architecture, including both cloud and on-premise components.
The Netskope Tenant
One of the earliest decisions that you will need to make is whether to have a single tenant implementation, or whether to have separate development and production tenants. You need to consider whether you regard the Netskope solution as a network architecture component, or whether you regard it as a cloud-based application solution. Users who are of the former mindset will generally be used to working with firewalls, proxies, and similar components, and will not expect to need a development environment. Rather, they will be inclined to make policy changes directly in their production system in much the same way that they would make firewall changes. However, it should be noted that the level of policy configuration available within Netskope can be quite complex, and making an incorrect change could cause regulatory issues if certain violations are no longer being reporting due to an error. Also, incorrect configuration might cause applications to be erroneously blocked. Policies can be defined to test a specific OU/Group/User, which allows for testing before implementing them across all users. There is another caveat to be aware of. Netskope currently does not support migrating policies between tenants. Therefore, you would need to manually copy the tested policy from one environment to the other, it you were to use separate tenants. This is clearly a potential source of human error, and so it is recommended that a second person should review the work of the person who performs the production update. (Note that a migration script is planned, and should hopefully be available later in 2018.) Netskope recommends that the two-tenant approach should be limited to specific use cases. At Cedrus, we are inclined towards taking a cautious approach when risking production problems due to development activities. Any production update should follow normal production change control procedures and approvals even if there is only a single tenant. This is an area that does not have a clear-cut answer and requires careful planning on the part of the user, irrespective of the approach taken.
Introspection is used to examine data at rest within supported, sanctioned applications, looking for policy violations, malware, etc. Configuration is performed within the tenant, under Settings>Introspection. Documentation is available within the tenant for configuration of supported applications. The configuration process may involve enabling API access within the target application, and then granting access to Netskope as a client to that API, using the OAuth protocol. One critical area that needs to be considered is the granting of appropriate privileges to the service account that is set up to run Introspection. In general, you should follow the “least privilege” model. If you are planning to perform Introspection against SalesForce instances, you should be aware that the Netskope documentation recommends cloning a Sys Admin user, which would be drastically over-privileged for the task that it needs to perform, and thus could be a security risk. If the account were to be compromised it would have super-user level of access, and as it is a service account it is not necessarily easy to audit individual user activity. Based on our experience, a Sys Admin account is not necessary, provided the appropriate permissions are set on the introspection user profile. The required permissions for the introspection user are:
Manage Chatter Messages and Direct Messages
Manage Unlisted groups
Password Never Expires
View All Data
View All Users
Similar issues are likely to crop up for other services, so this is an area to spend time evaluating. One example is Microsoft SharePoint, where a Netskope app needs to be installed in the SharePoint catalog. This app is visible to all SharePoint site admins. You will need to communicate to them what it is, so that they do not attempt to install it in their own instances.
Forensics is a way of providing additional information to the operational analyst who is researching an introspection violation. Without Forensics, the incident management system will list your Data Loss Prevention (DLP) violations, but won’t show you the actual data that caused the issue. This is because Netskope only stores metadata, and never your actual user data. When you set up a Forensics profile you will configure a storage location within one of your cloud storage applications, such as Box or OneDrive, that you have already configured for Introspection. Netskope will then store additional data in that location to augment incident management. You do not need to have a separate Forensics profile for every service that you are introspecting – you choose one, and store data for all other services there. For example, your DLP violations from SalesForce might store their forensic data in Box. Note, however, that even with Forensics enabled, there may be insufficient data available to the incident response team to fully evaluate if this is an actual violation or merely a false positive. (Forensics stores a small amount of the data from around the triggering attribute, but not the whole document). In that case, the analyst will need to review the full document that triggered the alert. You can download or preview the file using the Netskope UI.
Reverse Proxy is one of Netskope’s models for inline monitoring. It adds specific value for its ability to intercept interactions between an unmanaged client and a sanctioned cloud application. This is achieved by making modifications to the single signon flow using either SAML 2.0 or WS-Federation protocols. However, it is only useful for a small percentage of cases. Very few services are available for integration, and even for the ones that are, only HTTP traffic is supported. This makes Reverse Proxy of minimal value for an application like Office 365, where the bulk of activity will be made using either native or synch clients. It’s best to consider this as a niche solution for certain corner cases that cannot be addressed by any of the forward proxy options (such as the Netskope Client, the Secure Forwarder, or Proxy Chaining), or as a supplemental solution in addition to a forward proxy. It should be noted that Reverse Proxy will be bypassed if the user is already being monitored by a forward proxy connection, so there is no conflict is setting up both.
On-Premise Log Parser
Configuring the OPLP is relatively straightforward and well documented, so there is not much to add here on that front. It is recommended to stream syslog events to the OPLP so that you have an up-to-date view of log data in your tenant, and minimal manual intervention necessary. From a continuity and reliability perspective, it’s hard to justify making the OPLP redundant. If it’s down for a day and needs to be re-built, the impact is minimal. Discovery data is typically looked at analytically, rather than at a transaction level. If data is not flowing to the tenant, the administrator will receive notifications and the problem can be addressed. One area that should be looked at closely is the content of the log data. We will talk in more detail about the governance of the system later, but the operations team that is managing the Netskope product will need sufficient data to be able to report back to business divisions when anomalies or unsafe behaviors are discovered. To do so, they may need data that is not present in the log file, such as a user’s email address, location, management chain etc. There are ways to enrich the log data, many of which were addressed in a previous blog post. We will briefly touch on them again in the next section on the Active Directory integration capabilities of Netskope.
Active Directory Integration
This topic is covered in detail in the following blog posts: Using Active Directory with Netskope (Part 1) and Using Active Directory with Netskope (Part 2). As mentioned in the previous section on OPLP, it is important to look at how complete the data is that is available in the Netskope tenant and, if necessary, enrich it. These two papers will provide information on a set of tools that help you do that, including the Directory Importer, the AD Connector and the REST API. As with the OPLP, the AD tools do not necessarily need to be made highly available, as the impact of downtime is minimal.
Forward Proxy Options
We discussed in section 2 the use of Introspection and Reverse Proxy for policy enforcement. However, both options only cover a small number of scenarios, specifically for sanctioned applications that are currently supported by Netskope. To address policy and DLP for the mass of applications requires a forward proxying solution that enables the bulk of network traffic to be routed through the Netskope cloud. There are three main options to accomplish this:
Netskope Secure Forwarder virtual appliance
Which of these options makes the most sense will depend on several factors, including existing network infrastructure such as firewalls, web proxies and DNS services; the availability of device management capabilities; and your tolerance for installing software on managed endpoints. Proxy chaining is probably the simplest solution, but may not be an available option depending on the web proxy in use. For example, it is not available for the Zscaler cloud-based proxy. Both proxy chaining and the Secure Forwarder only address traffic that flows through the corporate network, either originating from on-premise devices, or via VPN. Neither one will see “direct to cloud” traffic from remote devices, either home laptops that do not connect via VPN, or mobile devices. The Netskope client is more comprehensive, covering any managed device, whether connected to your network or not. The only DLP gap then becomes unmanaged devices. This can be partially mitigated by using Reverse Proxy for sanctioned applications, but Netskope itself cannot address the end user who connects direct to a cloud service from an unmanaged device and shares data to an unsanctioned application. Addressing this problem requires a more holistic approach to data security, addressing the ways in which data could be sent to the unmanaged device in the first place. Typical ways in which this can happen are:
a user emailing a file to themselves
a user sharing a file via an unsanctioned cloud application
a user connecting a device via a USB port
The email problem can be addressed by blocking unsanctioned webmail at the firewall or web proxy, and by monitoring sanctioned email traffic using Netskope or native Email DLP. File sharing traffic can be addressed in a similar way using Netskope DLP. USB lockdown is a well understood problem. integrating Netskope as part of an overall data security strategy can greatly enhance your ability to prevent leakage of privileged or regulated data.
Like any other major security component, Netskope requires ongoing care and feeding. As part of the implementation, it will be necessary to address the operational aspects of the ongoing process lifecycle. It’s likely that a new operations team will be formed that specifically supports the Netskope tool and the governance and management processes that surround it. Solid communication to major stake holders so they know what to expect, and what is expected of them, is key for a successful operation.
Roles and Responsibilities
Netskope provides certain built in roles, which include Tenant Admin and Delegated Admin. A Delegated Admin is similar to a Tenant Admin, but does not have the ability to add new Admin users, create roles, or make a small number of other changes. It’s also possible to create custom roles and assign them permissions. You can also integrate with your existing Single Sign-On (SSO) solution to enable role based access control. Netskope supports SSO using SAML2.0 with the Service Provider (SP) initiated flow. This also allows for the use of multi-factor authentication with the Netskope console. You will likely want to have at least two users defined as Tenant Admins, so that they can back each other up. You might also want to have Delegated Admins if you have a large organization and you need to have regional or distributed control of certain aspects of the system. If you want to provide access to aspects of the Netskope console to users who are not full time operators of the product, but who need to see, for example, reporting or analytical data, you can create custom roles with just the necessary permissions. For example, you might want to give restricted access to users from Risk Management, or from the operational areas of Business divisions. It’s also possible to limit the data that the non-Admin users can see:
Some data can be obfuscated if necessary. This includes User information, Source location information, File information and Application information.
Limit the scope of the user population that is visible to certain OU’s, Groups or Individual Users.
The specific operations processes that are necessary will depend on exactly how a customer chooses to use Netskope. Here are some typical processes that might be used. Application Discovery and Remediation This is the ongoing process for using cloud application discovery in Netskope to drive the application evaluation process for in-use, non-sanctioned applications (a.k.a. Shadow IT). This will need to include a prioritization component to ensure that applications that are of high risk are addressed promptly. A typical process might look something like this:
The Netskope Operations team will determine which category of cloud applications has the highest priority. For example, Cloud Storage might be regarded as the riskiest area.
The Operations team will use the Netskope reporting tool to create a prioritized list of unsanctioned applications, based on a combination of perceived risk and volume of usage, that are in use within the organization for the selected category.
For the highest priority application, the Operations team will use the Netskope reporting tool to create and prioritize reports (for each business area) of the user activity within those applications. Reports will be delivered to the appropriate Risk officers or business area management for further investigation
Once the appropriate teams have completed their investigation, the application can be removed from subsequent reports by use of the Netskope “tagging” capabilities. An application may be tagged as “Sanctioned” if it has been determined that there is a valid business case for its usage, and satisfies the organization’s vendor and system security controls and standards, respective to the data being used.
If an application is not regarded as important enough to the organization to sanction its usage, but the Risk team is satisfied that the application usage is not harmful, the application can be tagged as “Ignored” so that it may be left off future reports. If it is determined that ongoing monitoring is needed, the application can be tagged as “Monitored”, to allow for it to be removed from triage reporting, but included in ongoing usage monitoring reporting. These may be temporary designations to allow a business area to migrate to a sanctioned alternative.
Applications which are not safe for continued usage may be blocked, either immediately, or after a grace period.
The above process will then be repeated for the next most critical application.
Incident Management Various types of incidents may be discovered based on data captured within the Netskope tool. The categories of incidents include:
User Behavior Anomalies
General activity alerts, including policy and DLP triggers
For each of these categories, the Operations team will extract the relevant data from the Netskope console, and distribute it to the teams that need to take action. This might use an internal ticketing system. For example, a compromised credential might trigger a password reset, while DLP violations might involve both business group management and the Risk team.
DLP Rule Tuning
DLP rules are used to find certain type of restricted, regulated or privileged data inside documents or requests. Often, to avoid false positives, it is necessary to look for data in certain formats, such as a social security number or a credit card number, that are located physically close to a text label that identifies the data. Without this, every nine-digit number will trigger a personally identifiable information check, even if the number is something completely harmless. Typically, you will use a rule that looks for that data within some number of characters of the identifier. If too many false positives are found, you might want to tighten that restriction. If you feel that you are possibly missing valid hits, then you will loosen it. But there is no absolute rule as to what the correct value is, this is a trial and error process. As a recommendation, it’s easiest to tighten the restriction when you have too many false positives. There is no obvious way of knowing if you are missing items, so it’s best to start on the generous side.
This article covers a wide variety of areas related to taking a Netskope solution from concept into production. Based on our experience with the product, we have tried to document some of the issues that you need to be particularly aware of. We hope that you find it helpful! To learn more about our Netskope services, please click here!
Paul Ilechko | Senior Security Architect