Section 1: Cisco Umbrella Identity Federation Configuration.
Introduction.
Cisco Umbrella is a cloud-delivered security platform that provides DNS-layer protection, secure web gateway (SWG), cloud-delivered firewall, and cloud access security broker (CASB) capabilities. It enforces security policies and blocks threats at the DNS and IP layers before connections are established, making it a powerful first line of defence in a layered security model.
Cisco Umbrella logs can include DNS requests, proxy traffic, IP-layer events, and firewall decisions depending on your licensing and configuration. These logs offer valuable insight into user activity, threat prevention actions, and internet-bound traffic patterns.
It delivers DNS protection across endpoints, ensuring that users and devices are secure no matter the environment, which makes protecting users that work from home a breeze.
Integrating Cisco Umbrella with Microsoft Entra ID allows for centralised identity management, secure single sign-on (SSO), and improved visibility across your organisation's secure web gateway traffic. By federating identity, user authentication and access control policies can be managed consistently, aligning with enterprise identity governance standards.
This article section outlines the process to configure identity federation between Cisco Umbrella and Microsoft Entra ID, enabling user-based policy enforcement and reporting.
Step 1: Creating The Cisco Umbrella Enterprise Application in Entra ID.
Navigate to the Microsoft Entra ID portal:
Select the Cisco User Management for Secure Access application and create it.
Step 2: Configuring the Entra ID Application Using A Cisco Umbrella Static API.
Once added, proceed with configuring SSO and SAML-based sign-on. Cisco provides the necessary metadata XML or input fields:
-
Step 3: Provisioning Identities from Microsoft Entra ID.
Set up the app in the Microsoft Entra ID portal with your Cisco Umbrella token and Azure Active Directory Provisioning URL (collected from the previous step):
Navigate to the enterprise application (created in Step 1).
Add your token to the Secret Token field.
Add the Azure Active Directory Provisioning URL to the Tenant URL field.
Click Test Connection to confirm that you can use your Umbrella SCIM token to connect the Umbrella API with Microsoft Entra ID.
Complete the steps to provision users from Microsoft Entra ID to Umbrella. Review the user attributes that are synchronized from Microsoft Entra ID to the Cisco User Management Connector app in Attribute Mappings. The attributes selected as Matching properties are used to match the user accounts in the Cisco User Management Connector app for update operations. If you choose to change the matching target attribute, ensure that the Cisco User Management Connector app supports filtering users based on that attribute.
Click Save.
Section 2: Microsoft Azure Sentinel (SIEM) Integration For Log Analysis.
Introduction.
Cisco Umbrella offers valuable security telemetry including DNS-layer threat detection, proxy activity, and cloud access visibility. Integrating these logs into Microsoft Sentinel enables enriched correlation, threat hunting, and incident response across your broader security ecosystem.
This section covers the process of integrating Cisco Umbrella logs into Sentinel using Log Analytics workspace connectors and parsing them for effective SIEM use.
Use this Microsoft article for reference for ingesting DNS logs into Microsoft Azure Sentinel: https://learn.microsoft.com/en-us/azure/sentinel/data-connectors-reference#cisco-umbrella-preview
Overview.
Cisco Umbrella supports log export to AWS S3. Microsoft Sentinel ingests these logs using a pre-built Azure Function template found in the Content Hub. This allows continuous ingestion and analysis of DNS and security events in Sentinel for threat detection, investigation, and response.
Step 1: Integrating Cisco Umbrella Logs into Microsoft Sentinel Using the Azure Template Method.
To begin ingesting logs from Cisco Umbrella into Microsoft Sentinel, the first step is to enable Umbrella's log export functionality. Cisco Umbrella supports exporting logs to an Amazon S3 bucket. When you enable this feature from the Umbrella dashboard, a new managed S3 bucket will be provisioned on your behalf by Cisco.
During this process, you will be provided with three important values: the S3 bucket path (or "data path"), an AWS access key, and a corresponding secret key. These credentials are only visible once during the setup, so it is essential to copy and store them securely at the time.
These details can be found within the Cisco Umbrella dashboard:
- Navigate to Admin > Log Management > Amazon S3.
Step 2: Installing The Microsoft Sentinel Content Solution.
Once Umbrella log export has been configured and your keys are stored, the next stage takes place in Microsoft Sentinel.
Navigate to Microsoft Azure Sentinel > Content Management > Content Hub.
Search for Cisco Umbrella and select the featured solution from the list.
Select Install to begin deploying the solution.
Step 3: Deploying the Azure ARM Template.
Once installed:
Navigate to Configuration > Data connectors > Cisco Umbrella (Using Azure Functions) and open the connector page.
Choose the Azure Resource Manager (ARM) Template deployment method. This is the recommended approach for most environments and requires no manual code configuration.
- The ARM template method will launch a deployment blade in Azure with a form that needs to be completed using the information from Umbrella and your Sentinel workspace.
The steps for deploying the template are as follows:
Provide a Function App Name. This must be unique across your tenant (e.g., sentinel-umbrella-fnapp).
Select a Region that matches your Sentinel Log Analytics workspace.
Enter your Workspace Name and the full Workspace Resource ID, which can be copied from Azure or referenced from 1Password.
In the AWS section of the form, input the S3 bucket path (as given in the Cisco Umbrella console), specify the region (e.g. eu-west-2), and paste in the AWS access key ID and secret key that were provided by Umbrella during activation.
Click Review + Create, then Create to deploy the function app.
Verify that the connector status shows Connected.
If you encounter any issues when deploying the template, verify that you have sufficient permissions within the resource group.
Step 4: Verify Log Ingestion.
Logs are uploaded in ten-minute intervals from the Umbrella log queue to the S3 bucket. Within the first two hours after a completed configuration, you should receive your first log upload to your S3 bucket.
To check to see if everything is working, the Last Sync time in the Umbrella dashboard should update and logs should begin to appear in your S3 bucket.
Example:
"2024-09-11 18:46:00","Active Directory User ([adusername@example.net](mailto:adusername@example.net))","Active Directory User ([adusername@example.net](mailto:adusername@example.net)),WIN11-SNG01-Example","10.10.1.100","24.123.132.133","Allowed","1 (A)","NOERROR","domain-visited.com.","Software/Technology,Business Services,Allow List,Infrastructure and Content Delivery Networks,SaaS and B2B,Application","AD Users","AD Users,Anyconnect Roaming Client","","506165","","8234970"
The example entry above is 480 bytes. To estimate the size of your S3 Logs, see Estimate the Size of Your Logs.
Order of Fields in the DNS log:
<timestamp><most granular identity><identities><internal ip><external ip><action><query type><response code><domain><categories><most granular identity type><identity types><blocked categories><rule id><destination countries><organization id>
Timestamp—When this request was made in UTC. This is different than the Umbrella dashboard, which converts the time to your specified time zone.
Most Granular Identity—The first identity matched with this request in order of granularity.
Identities—All identities associated with this request.
Internal IP—The internal IP address that made the request.
External IP—The external IP address that made the request.
Action—Whether the request was allowed or blocked.
Query Type—The type of DNS request that was made. For more information, see Common DNS Request Types.
Response Code—The DNS return code for this request. For more information, see Common DNS return codes for any DNS service (and Umbrella).
Domain—The domain that was requested.
Categories—The security or content categories that the destination matches. For category definitions, see Understanding Security Categories and Understanding Content Categories.
Most Granular Identity Type—The first identity type matched with this request in order of granularity. Available in version 3 and above.
Identity Types—The type of identity that made the request. For example, Roaming Computer, Network, and so on. Available in version 3 and above.
Blocked Categories—The categories that resulted in the destination being blocked. Available in version 4 and above.
Rule ID—The ID of the access rule when the DNS request is matched by a policy.
Destination Countries—The two-character country identifier of the domain that was requested.
Organization ID—The Umbrella organization ID. For more information, see Find Your Organization ID.
For more information, read this article: https://docs.umbrella.com/deployment-umbrella/docs/dns-log-formats
Step 5: Verify Log Ingestion - KQL.
Once log ingestion has been established, the Cisco Umbrella connector will populate multiple custom log tables within your Log Analytics workspace. These typically include:
To confirm that logs are being ingested and structured as expected, open the Logs blade within your Sentinel workspace and run the following basic queries:
DNS Log Verification
Cisco_Umbrella_dns_CL
| take 10
This query will return the latest 10 DNS logs ingested from Umbrella. If the connector is functioning correctly, you should see structured records including fields such as timestamp_t, InternalIP_s, Domain_s, Action_s, and Categories_s.
To filter DNS logs by action (e.g. blocked):
Cisco_Umbrella_dns_CL
| where Action_s == "Blocked"
| project timestamp_t, Domain_s, InternalIP_s, Identities_s, Categories_s
| sort by timestamp_t desc
This allows you to identify recently blocked DNS queries, which can be used for detection rules or investigation.
Search for DNS Queries to a Specific Domain
Cisco_Umbrella_dns_CL
| where Domain_s endswith "example.com"
| project timestamp_t, Domain_s, InternalIP_s, Action_s, Identities_s
This will return logs showing requests to any subdomain under example.com.
Filter by Identity Type (e.g. Roaming Client)
Cisco_Umbrella_dns_CL
| where IdentityTypes_s has "Roaming"
| summarize Count = count() by bin(timestamp_t, 1h), IdentityTypes_s
| sort by timestamp_t desc
This provides a high-level view of DNS activity coming specifically from roaming clients over time.
Proxy Log Verification.
If Umbrella Secure Web Gateway (SWG) is in use and proxy logs are being exported, confirm ingestion with:
Cisco_Umbrella_proxy_CL
| take 10
Best Practices for Queries.
Always use time filters (e.g. where timestamp_t > ago(1d)) to limit the result set and optimise performance.
Combine fields such as InternalIP_s, Domain_s, and Categories_s to build actionable detections.
Leverage Kusto functions to alias and reuse logic consistently in scheduled rules and hunting queries.
For optimal performance, consider creating custom functions or scheduled analytics rules that alert on high-risk DNS activity, such as queries to known malicious domains or sudden spikes in traffic to newly registered TLDs.
→ Next Steps:
Once ingestion and validation are complete, you can begin to build custom detection rules, dashboards, and investigations using the data. You may also wish to enable or create custom analytic rules for SOC incident and alerting.
Sentinel's native integration with Microsoft Defender XDR also enables enriched correlation between Umbrella telemetry and endpoint, identity, and email signals.
For further schema details and field references, consult the official Cisco documentation.
