It’s likely that most companies who are planning large-scale Cloud Access Security Broker (CASB) projects are users of Active Directory (AD). This paper will discuss how to get the most out of your Netskope implementation by using the AD integration features appropriately. In a future Part 2, we dig deeper into the implementation of certain of these features and provide some helpful sample code.
This document is not intended to replace the existing Netskope documentation, and will not cover the implementation details for the Netskope tools, as that is already well defined. Rather, we will discuss which tools solve which use cases, and why you would choose to use them.
Active Directory Use Cases
Netskope provides a set of tools called the NS Adapters, as well as a REST API, and we will look at each of these in some detail. But first, we are going to look at three use cases that show why extracting AD data is so important.
Use Case 1: Enriching log data to support Discovery and Remediation
A prime use case for almost all CASB users is SaaS application discovery and remediation. The driver for discovery is data that comes two sources:
Data from an organization’s web proxy or firewall logs. This data is collected by an on-premise component, parsed, and send to the Netskope tenant instance.
Data that is captured in flight using an inline proxying model, either using Forward or Reverse Proxy models.
In both cases, the data it is made available in the Netskope dashboard, providing a range of analytics, as well as the ability to perform deep dives into the data using various reporting and searching tools. It can also be extracted to a .csv file for more ad hoc analysis. To use this data successfully, the Netskope customer will need a governance process that will depend to a large degree on the structure of the company. For example, in some companies, one small team might be authorized and mandated to analyze all data and perform the necessary activities, such as blocking access to applications, or following up with employees who consistently use non-sanctioned tools. In other companies, this might be a delegated task, where a CASB operations team will need to send reports out to business area or geographic region based teams who will deal with the remediation aspects based on their own policies. In either case, for this to be successful the tools need to be available for the operational teams to perform a set of activities that will likely include:
Identifying the riskiest applications (application triage processing)
Identifying the users of the current application under remediation
Working with appropriate business units to address issues
Making policy changes based to address the problem
In many cases, the raw log data from a user’s proxy or firewall will not contain sufficient information to perform these steps in an efficient way. For example, the process might need to know the user’s name, their email address, who their manager is, their location and department, etc. This data is unlikely to be in the raw log data in a complete form. There may be a unique key present that identifies the employee, but the other data would need to be looked up, either from the AD or from an HR application. In some cases, the only identifying information from the logs might be the source IP address. Using tools that Netskope provides, the necessary additional data attributes can be added to the log data in the Netskope tenant, so that it is all available in one place for reporting and analysis purposes.
Similarly, for inline data, Netskope may also be lacking the complete set of user attributes that are needed. Again, the AD tools can be used to enrich the data.
Use Case 2: Creating policies at a more granular level
Netskope policies can be created to be global, but in many cases, there will be a need to define policies that have a smaller scope. Importing the AD information into the Netskope tenant makes it possible to define policies that apply to an OU, a group, or even an individual user. Some examples of why this might be needed:
The legal team has more severe restrictions on how they use certain types of information in correspondence and documents
Certain regulatory aspects differ by country, so for a multinational organization there may be a need to define regional policies
An application that is unsanctioned to the wider population might be made available to one small team who needs to use it to integrate with the workflow of a business partner. A policy needs to be set up to cover the users in that single department.
Importing AD data into Netskope allows for the creation of policies at these more selective levels.
Use Case 3: Installing the Netskope Client on user devices
AD data can be used to allow administrators to push the Netskope client out to users, which can then ensure that all selected network traffic is proxied by Netskope. This relies on a complete list of users being uploaded from AD into the Netskope tenant.
Netskope AD Tools
Now that we had looked at the use cases let’s look more closely at the tools that Netskope provides. The Netskope Adapters can be downloaded from your Netskope tenant at the Directory Tools page under settings. There are three tools available, and we are going to discuss two of them, the Directory Importer and the AD Connector. (The third tool in the package is the DNS Connector, which is not relevant to this discussion). As mentioned previously, Netskope also provides a REST API, and one of the key features of that API is the ability to upload additional AD attributes. We will look at each of these capabilities in turn.
Netskope Directory Importer The Directory Importer runs as a Windows service. It needs to be able to connect to a Domain Controller in the AD, as it periodically makes calls to fetch user and group information, which it then posts to the Netskope tenant. Once the configuration is working, you will see the list of users and groups in the tenant under Settings>Active Platform. This data can be used to fulfill use cases 2 and 3. You will see, once this data is uploaded, that you can now set up policies at the user, group and/or OU level, depending on what data you have selected to upload. You can also make use of the list of users to send invitations to install the manually Netskope client, or to integrate with tools such as SCCM or JAMF for automated installations.
Note, however, that the Directory Importer by itself does not resolve use case 1. Data that is uploaded to the tenant via the Importer does not enrich log data as seen in SkopeIT or Reporting. In order to achieve that goal, one of the other tools will be necessary.
Netskope AD Connector The Netskope AD connector also runs as a Windows service. It retrieves user login events from a configured set of Domain Controllers and passes the IP to username mappings to any Netskope Secure Forwarders or On-Premise Log Parsers that have been configured locally. In addition, custom attributes can be selected from the Active Directory and passed to the other components. However, there are some limitations here.
The IP address that is in the log data might not match the IP address that the user was logged in from, depending on how the local network has been configured.
The AD Connector only allows for a maximum of five extended attributes, which may not be sufficient to meet the business need for discovery and remediation processing.
The AD Connector can be used to enrich data that traverses an OPLP (log data) or Secure Forwarder (inline forward proxy). However, it does not address other proxying options, such as the Netskope Agent or the SAML Reverse Proxy.
Some customers may be unwilling to have Netskope read their security logs.
The data in AD might not be the most accurate data. Some users might prefer to take data from their HR system, or some other Identity and Access Management (IAM) solution.
In the situation where the AD Connector is not workable or does not provide accurate or sufficient information to meet the business need, the final option is to use the REST API to upload additional attributes to enrich the data in the tenant.
Netskope REST API
The Netskope REST API provides a variety of functions, one of which is to upload additional user attributes to the Netskope tenant that can be used to enrich the data in SkopeIT events. This feature is documented on the Netskope Support site at: https://support.netskope.com/hc/en-us/articles/115012504527-Add-Custom-User-Attributes
The REST API allows you to upload a CSV file of data. This data can be obtained from Active Directory, or from some other source the provides more accurate data, such as an HR System. The document listed above provides details as to how the CSV file should be structured. One key aspect of this is that the first column must contain the user identity key that identifies the data in Netskope. If that data comes from multiple sources, such as Web Proxy logs and the Netskope Secure Forwarder, it is possible the different identifiers are being used for the different sources. In this case, it will be necessary to have duplicate rows in the CSV file, one for each possible key that can be matched against.
Netskope provides a Bash script that can be used to upload the file to the tenant. This script will split the upload into 5MB chunks if the data is too large. Note that the script assumes the existence of the CSV file. It does not extract the data from its source, nor does it manage job scheduling. You will need to implement those aspects of the solution.
In part 2 of this series, we will show you how to create a Powershell script to extract the necessary attributes from Active Directory, as well as perform the upload to the Tenant (to avoid needing to move the file to a Linux machine), and to handle scheduling. To access the second part of the series, please click here.
Paul Ilechko | Senior Security Architect
Andrew Hejnas | Cloud Security Specialist & Solutions Architect
Comentários