Global Secure Access in Sentinel, Part 1: Logs Are Not a Strategy

Every house has a junk drawer. You know the one. Dead batteries, three takeout menus, a single Allen wrench, and a charger for a phone you sold in 2018. Everything went in because “we might need it later.” Nothing has come out since.

A Log Analytics workspace can turn into the junk drawer of your Microsoft cloud. We flip on diagnostic settings, feel productive for a day, and promise ourselves we’ll build dashboards “when things slow down.” Meanwhile the logs pile up, the ingestion bill grows, and the one night you actually need answers, you’re digging past the takeout menus at 2 AM.

Today we’re cleaning out the drawer. In this post, we’ll stream Global Secure Access (GSA) logs into Microsoft Sentinel, install the official GSA solution from the Content hub, and build a workbook view that answers real questions: who went where, what got blocked, and which policy did the blocking. In Part 2, we’ll bring Microsoft Purview Network Data Security into the picture, correlate GSA blocks with Defender device risk, and turn what the workbook shows us into analytics rules.

If you’re brand new to GSA, start with my post on blocking AI apps with Entra Internet Access, then come back. We’ll wait. In addition, if you want the enforcement side of this story, my recent post on GSA file policies and Purview shows you how to install the deadbolt. This series is about proving the deadbolt actually works.

What You’ll Need

Before we start, make sure you have the following in place:

  • Microsoft Sentinel enabled on a Log Analytics workspace.
  • Global Secure Access deployed with at least one traffic forwarding profile enabled (Microsoft traffic, Internet Access, or Private Access).
  • The Microsoft Entra ID data connector configured in Sentinel.
  • Security Administrator in Entra to configure diagnostic settings, plus Microsoft Sentinel Contributor on the workspace’s resource group to install Content hub solutions.

Nothing exotic here. If GSA is already forwarding traffic in your tenant, you’re most of the way there.

Step 1: Point the Logs at Sentinel

First things first, we need to tell Entra where to send everything. Sign in to the Entra admin center and head to Entra ID > Monitoring & health > Diagnostic settings, then select Add diagnostic setting.

Give it a name that future you will recognize. “diag-setting-1” is NOT that name. Trust me on this one.

In the Logs section, these are the GSA categories and where each one lands in your workspace:

Diagnostic categorySentinel tableWhat it gives you
NetworkAccessTrafficLogsNetworkAccessTrafficTransaction-level detail for every request through GSA: user, device, destination, policy, action
NetworkAccessConnectionEventsNetworkAccessConnectionEventsConnection lifecycle with identity, device, and PoP region context
NetworkAccessGenerativeAIInsightsNetworkAccessGenerativeAIInsightsGenerative AI and MCP activity, including prompt-level visibility (preview)
RemoteNetworkHealthLogsRemoteNetworkHealthLogsIPsec tunnel and BGP session health for remote networks
NetworkAccessAlertsNetworkAccessAlertsGSA’s native security and policy alerts

Select the categories you need, choose Send to Log Analytics workspace under Destination details, pick your Sentinel workspace, and save.

Heads up: NetworkAccessTraffic is transaction-level, which is a polite way of saying it’s chatty. Every HTTP request through GSA becomes a row. Turn on the categories you’ll actually use, then keep an eye on ingestion volume for the first week before you commit to all five everywhere.

Step 2: Install the Global Secure Access Solution

Microsoft ships an official GSA solution in the Sentinel Content hub, and it saves you from starting with a blank canvas. The package includes three workbooks and seven analytics rules.

To install it, sign in to the Defender portal and browse to Microsoft Sentinel > Content management > Content hub. Search for “Global Secure Access,” select the solution, and click Install.

Here’s what comes in the box on the workbook side:

  • Network Traffic Insights. The operational dashboard for GSA traffic across all three forwarding profiles. This one only needs the diagnostic settings from Step 1.
  • Enriched Microsoft 365 logs Workbook. Correlates OfficeActivity audit events with GSA traffic using UniqueTokenId as the join key. This requires the separate Microsoft 365 data connector in Sentinel, since OfficeActivity doesn’t come from Entra diagnostic settings.
  • MCP Servers Dashboard (preview). Visualizes MCP and AI agent traffic from the NetworkAccessGenerativeAIInsights table. If shadow AI is on your radar, and it should be, this is the one you came for. It also has a prerequisite the install won’t mention, which we’ll get to in Step 3.

The seven analytics rules are worth a quick look too:

RuleWhat it catches
GSA – TI Domain EntityGSA destinations matching threat intel domain IOCs
GSA – TI IP EntityDestination IPs matching threat intel IP IOCs
GSA – TI URL EntityDestination URLs matching threat intel URL IOCs
GSA – Detect Abnormal Deny Rate for Source to Destination IPDeny-rate spikes against a learned five-day baseline
GSA – Detect Protocol Changes for Destination PortsProtocol mismatches that suggest tunneling
GSA – Detect Source IP Scanning Multiple Open Ports100+ distinct ports hit in 30 seconds
GSA – Detect Connections Outside Operational HoursConnections before 8 AM or after 6 PM

Installing the solution gives you these as rule templates. You still have to create a rule from each one you want running, so don’t assume you’re covered the moment the install finishes.

Tip: That last rule assumes your company sleeps at night. If you have shift workers or a global footprint, tune the hours before enabling it, or enjoy a fresh batch of incidents every morning at 6:01.

Step 3: Make Sure the Data Actually Showed Up

Sentinel only creates a table once data lands in it. In other words, if you check five minutes after saving the diagnostic setting and see nothing, don’t panic. Give it time.

Once you’ve waited a bit, browse to Microsoft Sentinel > Configuration > Tables in the Defender portal and confirm the GSA tables exist. Only the categories that have actually received data will appear here, so a short list is normal early on.

For a faster sanity check, run this in a query window:

union isfuzzy=true
    NetworkAccessTraffic,
    NetworkAccessConnectionEvents,
    NetworkAccessAlerts,
    RemoteNetworkHealthLogs,
    NetworkAccessGenerativeAIInsights
| where TimeGenerated > ago(24h)
| summarize Events = count() by Type
| order by Events desc

The isfuzzy=true flag keeps the query from failing if one of the tables hasn’t been created yet. Tables that exist show a count, tables that don’t just stay quiet.

One table deserves its own warning, because it behaves differently from every other category in the list. NetworkAccessGenerativeAIInsights is a lake-only table. Microsoft’s table reference lists “Lake-only ingestion: Yes” in the attributes box, and what that means in practice is that a standard Analytics-tier workspace never creates the table at all. Not slowly, and not eventually. The diagnostic category saves happily with the box ticked, the portal gives you no warning, and the table simply never shows up in Configuration > Tables. The MCP Servers Dashboard workbook reads from that table, so it renders empty right along with it.

None of that means GSA missed anything. In my lab it was decrypting and parsing MCP conversations perfectly the whole time, down to the JSON-RPC method per event and the client and server names lifted out of the initialize handshake. All of it was sitting in Entra under Global Secure Access > Monitor > Gen AI Insights logs, current to the second. It just never crossed into Log Analytics.

One query settles which situation you’re in:

Usage
| where TimeGenerated > ago(30d)
| where DataType startswith "NetworkAccess"
| summarize TotalMB = sum(Quantity), Last = max(TimeGenerated) by DataType

If a data type shows bytes there, ingestion is working and you are only waiting on latency. If NetworkAccessGenerativeAIInsights never appears at any volume, nothing has ever been ingested and waiting will not change that. Treat the Entra blade as the source of truth for MCP visibility today. If you need it queryable in Sentinel, budget for Microsoft Sentinel data lake and verify it end to end before you build detections on top of it.

Step 4: Build the Overview Tab

The built-in Network Traffic Insights workbook is a solid starting point, and I recommend exploring it first. That said, the whole reason for this series is building a view tailored to your environment, one that we’ll extend with DLP and Defender correlation tabs in Part 2. For that, we need our own workbook.

Head to Microsoft Sentinel > Threat management > Workbooks, select Add workbook, and switch to edit mode. From here, each visual is just a query item. These four are my starting lineup.

Traffic volume by action

NetworkAccessTraffic
| where TimeGenerated > ago(24h)
| summarize Events = count() by bin(TimeGenerated, 15m), Action
| render timechart

Top destinations by action

NetworkAccessTraffic
| where TimeGenerated > ago(7d)
| summarize Events = count() by DestinationFqdn, Action
| top 20 by Events

Render this one as a bar chart. It shows you at a glance which destinations dominate your traffic and whether they’re sailing through or bouncing off a policy.

Blocked traffic by user and policy

NetworkAccessTraffic
| where TimeGenerated > ago(7d)
| where Action =~ "Block"
| summarize Blocks = count() by UserPrincipalName, PolicyName, RuleName, DestinationFqdn
| top 20 by Blocks

This is the SOC-friendly view. Instead of making an analyst pivot across three blades, one grid ties the user, the policy, the specific rule, and the destination together. When someone asks, “why can’t I get to this site,” the answer is one row. Two caveats before you go looking for it. PolicyName and RuleName only populate for traffic an Internet Access filtering policy actually evaluated, so traffic riding the Microsoft profile leaves both columns empty. If nothing has tripped a block rule yet, the whole grid comes back empty, which is the right answer on a quiet tenant rather than a broken query.

Remote network health

RemoteNetworkHealthLogs
| where TimeGenerated > ago(24h)
| summarize Events = count() by RemoteNetworkId, Status

Skip this one if you’re not using remote networks. Sentinel won’t even create RemoteNetworkHealthLogs until a remote network reports in, though the query window resolves the schema anyway and just returns nothing rather than erroring. If you are using remote networks, this separates two very different stories: a blocked transaction while tunnels are healthy is a policy question, while widespread failures during a degraded tunnel is a network operations question. Knowing which fire you’re fighting is half the battle.

Here’s the finished tab after a night of real traffic. The timechart separates Allow from Block cleanly once both exist, the blocked-traffic grid ties one user to one policy, one rule, and one destination on a single row, and I tacked on a fifth tile for top cloud apps once CloudAppName turned out to be the enrichment column that actually populates.

Wrapping Up: One Drawer Down

Look at that. The junk drawer has dividers now. GSA logs are flowing into Sentinel, the official solution is installed, seven detection rules are ready to enable, and a workbook tab answers the questions that used to require three portals and a prayer.

Here’s the thing about junk drawers, though: organizing the drawer is only step one. The next step is noticing when someone tries to sneak something out of the house. If you followed my deadbolt post, your GSA file policies and Purview DLP rules are already blocking sensitive uploads. In Part 2, we’ll find out where those events actually land in Sentinel, add a DLP tab to this workbook, correlate blocked traffic with Defender device risk, and graduate from dashboards to detections.

Future you, the one who gets asked “did anyone upload customer data to that AI site,” will appreciate it.

Dustin Gullett
Dustin Gullett

Dustin Gullett is a Microsoft MVP focused on Microsoft Security, Intune, Entra ID, and Zero Trust architecture. He writes practical guides for admins deploying Microsoft security tools in the real world.

Articles: 40