Integration Web Transactions from Netskope Log Streaming to Microsoft Sentinel

Netskope has officially published the Web Transaction connector on Azure Sentinel Content hub. You can avoid the template deployment steps. (Updated 25th September, 2026)

✅ Update: Azure now supports restricting public network access on Blob Storage through Azure Network Security Perimeter (NSP). See the 🛡️ Securing Blob Storage Access with Azure Network Security Perimeter (NSP) section below for the full walkthrough.

This document outlines the seamless integration of Netskope Web Transaction Logs with Microsoft Sentinel using the Codeless Connector Framework (CCF). This native integration provides near real-time visibility for effective threat hunting and incident management. To configure Netskope Log Streaming to send logs to your Blob storage please go through the article: https://docs.netskope.com/en/stream-logs-to-azure-blob

🏗️Integration Architecture Overview

The integration leverages several Azure services to ensure reliable and scalable log delivery:

1. Netskope to Azure Storage Blob: Netskope pushes Web Transaction Logs (and Alerts/Events) into a customer-owned Azure Storage Blob Container.

2. Event Grid Notification: Every time a new file (blob) is written, an automatic notification is sent to Azure Event Grid.

3. Storage Queue Messaging: Event Grid pushes the blob URI to a Storage Queue. This acts as a work queue for the connector.

4. Microsoft Sentinel CCF Connector (Scuba Workers): These connectors continuously pull (pop) messages from the Storage Queue.

5. Data Ingestion: The Scuba workers retrieve the data from the Blob Storage, process it, and ingest it into the Log Analytics Workspace via a Data Collection Rule (DCR).

6. Log Analytics: The Netskope Web Transactions and Events appear in the specified Log Analytics table within Microsoft Sentinel.

This blog explores how this new integration seamlessly pulls in near real time all of your organizations Web Transactions to a single Log Analytics table. 
 

🔒 Prerequisites

To successfully deploy the custom template and configure the Netskope Data Connector, the user or Service Principal performing the steps must have the following minimum permissions assigned:

1. Configure Netskope Log Streaming to Azure

Follow the documentation: Stream Logs to Azure Blob - Netskope Knowledge Portal for the Netskope Log Streaming configuration to Azure

2. Microsoft Entra ID (Tenant-Level Role)

The deployment process involves working with Enterprise Applications (Service Principals) to set up the connector.

3. Azure Role-Based Access Control (Subscription-Level Role)

The connector deployment uses an ARM template that creates several Azure resources (Data Collection Rule, Event Subscription, etc.) and requires the ability to deploy resources.

4. Microsoft Sentinel-Enabled Log Analytics Workspace

You must have a Log Analytics workspace with Microsoft Sentinel enabled. If you don't have one, create it first: Onboard to Microsoft Sentinel | Microsoft Learn

5. Enable Auditing & Health Monitoring

Make sure to turn on Auditing & Health Monitoring for the Azure Sentinel: https://learn.microsoft.com/en-us/azure/sentinel/enable-monitoring?tabs=defender-portal. This will help us to get to the root cause of the issue.
 

🚀 How to Enable the Integration

Netskope’s native integration simplifies log shipping with minimal deployment overhead. Follow these steps to enable the connector:

1. Deploy the Azure Sentinel Connector Template

1. Navigate to the Azure Portal.

2. Search for and select Deploy a Custom Template.

3. Select Build your own template in the editor.

4. Paste the following JSON file URL into the editor:

   • Netskope Web Transactions JSON: https://raw.githubusercontent.com/netskopeoss/Netskope_Web_Transactions_Azure_Sentinel/refs/heads/main/netskope_webtx_log_streaming.json

5. Click Next.

6. Fill in the required deployment parameters (Workspace Location, Region, and Resource Group where your Sentinel instance is located).

   

7. Click Review + Create and then Create to deploy the necessary Azure resources (Event Subscription, Storage Queues, Data Collection Rule, etc.).

   

2. Configure the Data Connector in Sentinel

1. Navigate to your Microsoft Sentinel Instance.

2. Under Content management, select Data Connectors.

3. Locate the new connector named NetskopeWebTxConnector.

4. Select Open connector page.

5. Fill out the required parameters:

If the ServicePrincipal doesn’t exist. It will show something like below and grant the tenant admin consent.

It will create the ServicePrincipal something like below. The details related to ServicePrincipal will be auto populated as shown in other screesnshot.

6. Before clicking on connect assign the Storage Blob Data Contributor and Storage Queue Data Contributor at the ServicePrincipal Level.
    

   

    

7. Click Connect to finalize the integration.

   

    

📝 Note: Data will typically begin appearing in your Log Analytics workspace within 20 minutes after successful connection.

8. After connection you can check out the data in the Table: NetskopeWebTransaction_CL

   

Workbook & Analytics Rules

For Workbook and Analytics Rules creation. Please follow the article: 

Securing Blob Storage Access with Azure Network Security Perimeter (NSP)
 

Once your Netskope Web Transactions connector is up and running, you can further lock down your environment by restricting public network access to the Blob Storage account using Azure Network Security Perimeter (NSP). NSP lets you centrally manage inbound and outbound access rules for a group of Azure resources, so you can secure the storage account without breaking log delivery from Netskope or ingestion by the Sentinel CCF connector.

⚠️ Prerequisite: Complete the connector setup described above and confirm the Data Connector shows a Connected status before enforcing NSP. Enforcing NSP before the connector is connected will block the initial handshake and log delivery.
 

Step 1: Create a Network Security Perimeter and profile

1. In the Azure Portal, search for and open Network Security Perimeters.
2. Create a new perimeter (e.g., com-netskopewebtx-nsp).
3. Inside the perimeter, create a Profile (e.g., netskopewebtx-storage-profile). This profile will hold the inbound access rules that control who can reach your storage account.

Step 2: Add three inbound access rules to the profile

Add three Inbound access rules to the profile so that Netskope, the Microsoft Sentinel ("Scuba") workers, and your own subscription can all still reach the storage account once public access is locked down.

1. Allow-Netskope-IPs — add the Netskope Log Streaming IP addresses.

2. Allow-Scuba — add the Microsoft Scuba/Sentinel worker IP ranges. Pull the current list from Microsoft's Azure IP Ranges and Service Tags download.

📝 Note: Only IPv4 addresses are supported — Inbound access rules on a Network Security Perimeter do not currently support IPv6.

3. Allow-Subscription — add your own Azure subscription as an allowed source so you and other in-subscription resources aren't locked out.

Step 3: Grant the Event Grid system topic permission to write to the Storage Queue

Deploying the connector template creates an Event Grid System Topic on your storage account, which delivers BlobCreated notifications into the Storage Queue. Once you restrict network access, this system topic's managed identity needs explicit permission to write to the queue:

1. On the Storage Account, go to Access Control (IAM) → Add role assignment.
2. Select the Storage Queue Data Message Sender role.
3. Assign it to Managed identity → select the Event Grid System Topic associated with this storage account (e.g., eg-system-topic-... or netskope-webtx-systopic).

Step 4: Switch the system topic's event subscription to a system-assigned managed identity

1. On the Storage Account, go to Events, and open the relevant Storage Queue event subscription (e.g., sentinel-connector-blobcreatedevents).
2. Go to the Additional Features tab.
3. Under Managed Identity for Delivery, change the Managed identity type from None to System Assigned.
4. Click Save.

Step 5: Associate the NSP profile with the storage account's networking

1. On the Storage Account, go to Security + networking → Networking.
2. Under Network security perimeter, click Associate.
3. Select the Network Security Perimeter and the Profile you created in Step 1 — the one containing all three inbound rules.

Step 6: Move Public network access to "Secured by perimeter"

Still on the Networking page:

1. Under Public network access, change the setting from Enable to Secured by perimeter (Most restricted).
2. Click Save.

Step 7: Change the perimeter's access mode from Transition to Enforced

1. Go back to the Network Security Perimeter resource → Associated resources.
2. Select your storage account resource.
3. Click Change access mode, choose Enforced, and click Apply.

📝 Note: Transition mode logs what would be blocked without actually enforcing it — useful for validating your rules first. Enforced mode is what actually restricts public access to only the sources defined in your inbound rules.

Step 8: Enable diagnostic logging on the NSP for troubleshooting

Before you rely on the perimeter in production, turn on diagnostic logging for the Network Security Perimeter resource itself. This gives you an audit trail of every allowed and denied request, which is the fastest way to root-cause it if Netskope or the Sentinel connector ever appear to stop receiving data after NSP is enforced.

1. On the Network Security Perimeter resource, go to Monitoring → Diagnostic settings → + Add diagnostic setting.

2. Give it a name (e.g., nsp-diagnostic-logs).

3. Under Categories, select at minimum:

   • Public inbound access allowed by NSP access rules
   • Public inbound access denied by NSP access rules
   • Public inbound access allowed by PaaS resource rules
   • Public inbound access denied by PaaS resource rules

   Or select allLogs under Category groups to capture everything.

4. Under Destination details, check Send to Log Analytics workspace and select the same Sentinel-enabled workspace used by the connector — this makes it easy to correlate NSP denials with gaps in NetskopeWebTransaction_CL.

5. Click Save.

Troubleshooting:

1. Perform all the steps below first in a "clean room" environment. That is, create a new resource group which contains only the minimal # of resources: Sentinel-enabled Log Analytics workspace, a Storage Account, and a Blob Container with expected name.
2. Ensure diagnostics logs are enabled on the Sentinel Workspace. Do this before anything else.

3. Deploy ONLY ONE Netskope Log Streaming Blob solution template into this workspace. Check resource group deployments to ensure that it deployed without error. After deploying, if you make any changes to the solution template, start over from step 1 in a new clean resource group.
4. Connect the connector. Use the storage account in the same resource group as the Sentinel Workspace. In case of Netskope connector, leave event grid topic blank, and be sure to set a folder name.

5. Check resource group deployments to ensure that it deployed without error.
6. Check that the storage account has an "Microsoft.Storage.BlobCreated" Event Subscription, with expected prefix folder.
7. Click into the Event Subscription details. Ensure the "Endpoint" is {name}-notification
8. Check that the Storage account has two queues, {name}-dlq and {name}-notification.
9. Check the role assignments on each queue. Ensure expected App Registration (e.g. "ScubaSentinelToStorageProd" has Storage Queue Data Contributor role. You can verify it's the correct app by clicking on its name, and comparing Object ID on the "Enterprise Application Overview" page with the Service Principal ID in the connector deployment page.
10. Manually add a piece of test data to the blob container. Be sure the data is formatted correctly, as the DCR will expect it, is in correct format (e.g. .csv.gz), and is in expected folder.
11. Ensure the blob was added in the correct folder, with the expected name.
12. Check the metrics on Events page for Storage Account. Look for Published Events and Delivered Events to jump up to 1. Refresh as needed.
13. Check the {name}-notification queue quickly. Look for a message to arrive in that queue with folder and file name matching the file you just added. Refresh regularly for a few minutes, could be up to 10. The event should disappear from the queue because it has been picked up by the connector.
14. Check the metrics for the DCR. Look for "Log Ingestion Requests per minute" to come up.  
15. Check the Sentinel Logs, run a simple KQL query for just the table name. Look for matching data to come up.
16. Visit the connector page. Look for green status, and indication that "last log received" was recently.
17. Repeat steps 10-15 a few more times.
18. Now turn on your blob data source, and repeat steps 11-15.
19. Problems? Check the SentinelHealth table for clues.

Common Errors:

•  If you see the error: Deployment Failed At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.
  { "error": { "code": "BadRequest", "message": "Connectivity check failed. ConnectorId: NetskopeWebTransactions, Status code:S3B40010, Message:An unknown exception occurred." } } - The issue is mainly due to missing role assignment to the ServicePrincipal or ServicePrincipal not created properly or Blob storage is enabled from selected network and Scuba IPs are not whitelisted. All the above steps are already covered in the above documentation

  

• Failed to create required resources for data connector Invalid output table schema {0}: The following columns which exist in the current schema do not exist in the new schema or have different types : {1} - This kind of error are seen when you have done some changes in the template schema or directly in your environment which can lead to the above error.
• If you see the errror: { "code": "BadRequest", "message": "{\r\n \"error\": {\r\n \"code\": \"InvalidRequest\",\r\n \"message\": \"System topic source cannot be modified.\"\r\n }\r\n}" - Your system topic is already existing. Copy the existing system topic name from the Blob Storage > Events.

Change Logs:

• Updated the template to only deploy the connector. Now all the role assignment need to be done manually as the role assignment needs owner level access and delay steps which were earlier being used for the role assignment have been removed as this was causing issue in some of the customer environment while deploying.
• Above documentation has been fully updated to the new flow and capture some new update with the same.
• Additionally if the customer have firewall enabled from their particular blob storage they can use scuba IPs whitelisting step with the script for whitelisting 100s of Microsoft Scuba IPs. The Same Script has been uploaded to the same github repo and link for the same has been attached to the above docs.
• Recently a lot of errors were seen related to the Bad request during performing connection. The error didn’t have any details but we have captured what could have been missing which have caused the issue. Also captured the other kind of errors seen while deploying or after deploying the template
• Added the link to Workbook and Analytics Rules Article. Additionally updated the warning related to the Network restriction