For many organizations, a Single Sign On (SSO) identification system is used to verify users’ access to applications and services. Everyone uses SSO, such as when you authenticate using a Microsoft account to access outlook.com, or a Google account to access gmail.com (or visa-versa). You can of course use either a Microsoft or a Google login (they are SSO providers) to authenticate to countless business and commercial websites (people that trust the SSO providers).
- SSO frees the organization from the need to hold passwords in their databases, and cuts down on login troubleshooting, so it’s a key authentication choice for Cloud and Mobility.
- User-centric business advantages of SSO include streamlined user access to their applications and reduced load of memorized passwords.
- Protect the keys to the kingdom by watching your SSO interactions with a best practice cloud-based security service.
This article focuses on how Microsoft’s cloud-based SIEM, Azure Sentinel, delivers proactive defense to your organization when you are using either of two popular SSO services: those from Microsoft (Azure Active Directory) and from Okta, Inc. License and Azure costs associated with the solution are included in the discussion.
SSO is a part of our daily life
SSO systems have been compared to ID cards or passports, which are issued by trusted government authorities, and accepted as proof of identity by doorkeepers most everywhere. Figure 1 (courtesy Brian Cheatham) illustrates how you can use either Azure AD (top) or Okta (left) as an SSO provider to Software as a Service (SaaS) app Microsoft Office 365 (upper right).
Figure 1 – SSO identity providers like Azure AD and Okta offer Identity as a Service (IDaaS) to access SaaS apps like Office 365.
Modern SSO services are based on either OAuth2.0 or Security Assertion Markup Language (SAML), open standards for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. Popular SSO identity providers in addition to Microsoft and Okta include CA Technologies, Centrify Corporation, NetIQ Corporation, Onelogin Inc., and Oracle Corporation. Most other SSO services can be monitored by Azure Sentinel using techniques similar to those described in this article.
Azure Sentinel mitigates SSO risks
There are some downsides to SSO however, such as use of a single password increasing the chances of password vulnerability (all your eggs in one basket), as well as that when SSO fails, access to all related systems is lost (single point of failure). Just as even the best security guard can’t detect every fake or stolen ID, if we rely only on our doorkeeper’s skills—occasionally—someone improperly gets a Fake ID past the checkpoint (Figure 2).
Figure 2 – If only compromised SSO user identity was this easy to spot.
The best modern SIEM tools (Security Information and Event Management) augment cloud-based identity service directory and authentication with security event detection and analysis on SSO-related actions. For example, tracking where a user is logging in from, or how many times a user fails to login. Every organization needs an intelligent process evaluating SSO event data, watching for anomalies and checking data against the characteristics of known exploits. Think getting an alert when a user logs in from an unusual location, or when 10 or more failed login attempts times occur in an hour.
Azure Sentinel and the suite of Microsoft cloud-based security tools do a great job at analyzing SSO login and account activity. Organizations using most any SSO can and should benefit from all the analytics, alerting, and investigation features of Azure Sentinel. Failing to analyze the data from your SSO means not helping the doorkeeper do their job better. Azure Sentinel can help your doorkeeper detect the fake and stolen IDs, for example, by alerting you when an otherwise valid SSO user credential might be compromised. This article will demonstrate how to connect both SSO services to Azure Sentinel, and showcase the alerting and dashboarding products available in the solution.
Connecting Azure Active Directory to Azure Sentinel
In terms of Azure Sentinel data connectors, Azure Active Directory is a first-class citizen and is supported for immediate connection after creating an Azure Sentinel workspace. Azure Active Directory Premium P1 or P2 is required to use this connector. (EMS E3 or Microsoft 365 E3 (that includes EMS and Office 365) includes Azure AD Premium P1. EMS E5 or Microsoft 365 E5 includes Azure AD Premium P2.) Figure 3 shows an operational Azure Active Directory data connector.
Figure 3 – Connecting Azure Active Directory SSO Sign-in and Audit logs to Azure Sentinel is a simple task if you have the right license and permissions.
The key to getting this connector going is to log into the Azure Portal and configure the connector with a user credential that is also a Global Administrator or Security Administrator in the Azure AD tenant associated with the Azure subscription where the Azure Sentinel workspace is located. Activating this data connector enables 4 x Azure Sentinel workbooks and 22 x Azure Sentinel Analytics rules templates. Figure 4 is representative of the data you will start processing, in this example, a report of an Azure AD user that failed login due to use of an expired password.
Figure 4 – Azure Sentinel Log Viewer: A security event of the LogManagement solution type about a failed Azure AD login.
Cost accounting for security monitoring of Azure Active Directory SSO logs using Azure Sentinel
In addition to the mentioned Azure Active Directory Premium P1 or P2 license for each user:
-
There is an Azure Sentinel data ingestion charge for the SigninLogs data from Azure Active Directory of $2.46 per GB (at pay as you go rates, rates vary by region).
- A medium sized business might expect from 25-GB / mo. = $61.50 / mo. to 50-GB / mo. = $123 / mo. consumption-based charges.
- Larger customers (those with >100-GB log data per day) can achieve >50% data ingestion cost savings using a capacity reservation.
- Data retention of 90 days is included and beyond that there is a charge of $0.12 per GB per month.
- Microcharges for running Azure Logic App playbooks and Azure Monitor alert rules related to SSO security incidents are a final consideration, usually well under $10 per month
Connecting Okta to Azure Sentinel
Unlike Azure Active Directory, there is not a built-in connector for the Okta SSO service. However, Okta is fully supported via an Azure Sentinel Playbook that imports Okta logs from the Okta cloud into your Azure Sentinel workspace. To add raw events from Okta into your Sentinel workspace, go to this URL in the Azure Sentinel github repository and click Deploy to Azure: https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/OktaRawLog. This will launch a standard Deploy from a custom template blade in your Azure portal loaded with settings from the OktaRawLog Azure Resource Manager (ARM) template at github. Generate an API token from Okta, and enter it when you configure the playbook as shown in Figure 5.
Figure 5 – Configure the OktaEvents-to-Sentinel Playbook with your Okta cloud service information.
The resulting playbook by default will run every 5 minutes and query Okta for new events. Opening the playbook in the Azure Logic Apps Designer (Figure 6) shows the key tasks where Okta Logs in JSON format are queried via HTTP URI and API Key, parsed, and ingested to Azure Sentinel with the Custom Log type of Okta_Events.
Figure 6 – An Azure Logic App does the work of the Sentinel Playbook OktaEvents-to-Sentinel that scrapes events from Okta using a REST API query to an HTTP URI.
Figure 7 is representative of the data you will start processing, in this example a report of an Okta user that logged on successfully from an iPhone.
Figure 7 – Okta SSO events are transcribed to the Azure Sentinel workspace for analysis.
Cost accounting for security monitoring of Okta SSO logs using Azure Sentinel
-
There is an Azure Sentinel data ingestion charge for the Okta_Events_CL data from Okta of $2.46 per GB (at pay as you go rates, rates vary by Azure region).
- Small organizations of under 100 users might expect under 2 GB per day.
- A large organization with several thousand users might expect 25-50 GB / day consumption-based charges.
- Larger customers (those with >100-GB log data per day) can achieve >50% data ingestion cost savings using a capacity reservation.
- Data retention of 90 days is included and beyond that there is a charge of $0.12 per GB per month.
- Microcharges for running Azure Logic App playbooks and Azure Monitor alert rules related to SSO security incidents are a final consideration, usually well under $10 per month
Analytics Rules Detect Real Time Security Threats
Once you have connected your SSO service provider to your Azure Sentinel workspace, a next step in Azure Sentinel data connector onboarding is to deploy Azure Sentinel Analytics rules and optionally Azure Monitor rules. These rules will watch Azure Sentinel for new incidents to be detected and then perform automatic notification (alerting) and optionally automatic remediation (workflow).
Analytics rules for Azure Active Directory SSO log data
Immediately after connecting Azure Active Directory Logs to Azure Sentinel, you should select analytic templates–appropriate to convert into rules for your environment–from the Relevant analytic templates shown in Figure 8. There is a Create rule button column available in the right-most column (not shown, scroll right) to give you a head start on each rule.
Figure 8 – Azure Sentinel | Data connectors -> Azure Active Directory -> Open connector page -> Next steps.
There is no need to enable every rule associated with Azure Active Directory, just those that involve scenarios in your environment. For example, if you are not using Azure AD SSO for login to Amazon AWS services, there is no need to create a rule from the Failed AzureAD logons but success logon to AWS template.
Sample rule walk-thru: When you enable the analytics rule Sign-ins from IPs that attempt sign-ins to disabled accounts, an incident will be created when a non-disabled account signs in successfully from the same IP as the disabled accounts. Investigating such an incident (as shown in Figure 9) leverages the sophisticated features of Azure Sentinel. This is what this is all about—you are augmenting the surveillance of your SSO doorman by analyzing and aggregating otherwise discrete events to detect security situations you want to be aware of.
Figure 9 – Investigating IPs that repeatedly are the source of failed logins to disabled accounts followed by successful logins to other accounts.
Analytics rules for Okta SSO log data
Since Okta is an added (third party) data source integration, there is not a convenient pre-configured list of relevant analytics templates to enable as rules (like there was for Azure Active Directory). However, we know that Okta is an SSO service like Azure Active Directory, so we can copy the functionality of relevant built-in Azure Active Directory templates and adapt them to the Okta data source. Figure 10 shows a custom rule for Okta data that alerts when four (4) or more Okta user login failures occur in a one-hour period. [In Okta logs, “WARN” events of the “user.session.start” type indicate user login failure.]
Figure 10 – Author custom Azure Sentinel Analytics rules for third-party SSO provider logs.
The custom Sentinel alert rule seen above in Figure 10 maps the Okta-specific custom fields “actor_alertnateID_s” and “client_ipAddress_s” to the AccountCustomEntity and IPCustomEntity fields that Azure Sentinel understands. This lets you take advantage of Azure Sentinel’s advanced investigation features to search across incidents for correlation and anomaly detection. Figure 11 shows an incident being investigated where USER1 from PUBLIC IP 1 failed to login to Okta, but the same user account did login successfully to local servers SERVER1 and SERVER2.
Figure 11 – Third party SSO logs integrate seamlessly into Azure Sentinel where all failed and successful logins are tracked and analyzed.
Connect your SSO provider to MCAS for the world’s most advanced cloud security analysis
One of Microsoft’s most compelling cloud security offerings is MCAS, a Cloud Access Security Broker (CASB) that provides control over data travel and sophisticated analytics to identify and combat cyberthreats across all your Microsoft and third-party cloud services. MCAS anomaly detection policies provide out-of-the-box user and entity behavioral analytics (UEBA) and machine learning (ML) so that you can immediately run advanced threat detection across your cloud environments, regardless of your SSO provider. Figure 12 (courtesy @boriskacevich) demonstrates how MCAS watches the totality of your cloud app portfolio for holistic, integrated security surveillance across all platforms, SSO providers, and apps.
Figure 12 – Add MCAS coverage for all the apps your organization uses by connecting cloud provider APIs.
While Azure Sentinel analysis of raw log data from your SSO provider, such as Azure AD sign in logs and Okta event logs, is invaluable, the force multiplier of adding MCAS cannot be understated.
Consider at Table 1, a list of actual incident types created by MCAS and surfaced in Azure Sentinel, in a large enterprise customer during the first quarter of 2020:
|
Activity from a Tor IP address |
Discovered app security breach |
Mass download |
|
Activity from an anonymous proxy |
Impossible travel activity |
Multiple failed login attempts |
|
Activity from infrequent country |
Malware detection |
New risky app |
|
Data exfiltration to unsanctioned app |
Mass delete |
Suspicious Power BI report sharing |
Table 1 – MCAS alerts appearing in an Azure Sentinel workspace.
An incident produced by integrating Okta, MCAS, and Azure Sentinel can be seen in Figure 13, an Impossible travel activity detection made by MCAS involving an Okta SSO login. The MCAS incident experience in Azure Sentinel is identical regardless of which SSO provider and/or cloud app is involved.
Figure 13 – MCAS acting on the SSO data ingested by Azure Sentinel produces its own incidents as a superset of Sentinel analysis alone.
Cost accounting for using MCAS along with SSO connections to Azure Sentinel
For Azure Active Directory, your SSO service must be connected to Azure Sentinel as shown previously in Figure 3, and third-party SSO connections need to be enabled similar to the Okta connection shown previously in Figure 10. MCAS has its own data connector for Azure Sentinel which can be seen in Figure 14.
- Microsoft Cloud App Security is required for each user in the organization. MCAS is included in Windows 10 Enterprise E5 ($57.00/user/month), Microsoft 365 E5 Security ($14.80/user/month), and is available as a Stand-Alone license from an Azure CSP (such as an MSSP) for $5.00/user/month.
- Azure Sentinel incidents are raised in real time by MCAS with no additional data ingest charges.
- Microcharges for running Azure Monitor alert rules that effect real-time alerting on MCAS incidents in Azure Sentinel are a final consideration, usually just a few dollars a month.
Figure 14 – Connect MCAS to Azure Sentinel for maximum value when monitoring SSO providers.
Azure Sentinel Workbooks are Dashboards for your SSO Operations
To complete this tour of Azure Sentinel’s capabilities when monitoring SSO services, we will take a look at the Azure Sentinel Workbooks that help you visualize and manage your SSO health and utilization.
The Azure Active Directory data connector for Azure Sentinel includes four (4) built-in workbooks: Azure AD Sign-in logs (seen in Figure 15), Azure AD Audit logs, Insecure Protocols, and Azure AD Audit, Activity and Sign-in logs.
Figure 15 – Visualize your SSO data from Azure Active Directory with built-in Azure Sentinel workbooks.
The Okta connection to Azure Sentinel is a third-party integration, so as in the case of the custom Azure Sentinel Analytics Rule seen previously in Figure 10, you need to create custom Azure Sentinel Workbooks based on the custom Okta log data. Guided by the built-in Azure Active Directory workbooks, you can author workbooks for your third-party SSO in a similar fashion. Figure 16 shows such a custom workbook: Okta events.
- Each chart element is just a KQL Query, like one that returns data of interest in the Log Viewer, formatted as a chart.
- Edit and save workbooks on the fly, such as to resize or re-order charts, by pushing the Edit button at the top left of the workbook.
- Save custom workbooks for just your use, or share them with teammates across your organization.
Figure 16 – A custom Azure Sentinel workbook that draws data from a custom log of third-party SSO data.
Summary of high-level steps to enable Azure Sentinel as the SIEM for your SSO services
- Connect your SSO provider to Azure Sentinel as a data source.
- Add your SSO provider to MCAS and add MCAS as an Azure Sentinel data source.
- Deploy rules to alert you when incidents needing your attention arise.
- Perform investigation using advanced tools including anomaly detection and event correlation.
- Use Workbooks to visualize and manage SSO operations.
Additional resources
-
Azure Sentinel: Syslog, CEF, Logstash and other 3rd party connectors grand list (includes the Okta connector described in this article)
-
Connect apps to Microsoft Cloud App Security (monitor SaaS apps with Azure Sentinel by connecting them to MCAS)
Tags: #MVPBuzz #AzureSentinel #securityManagement #SIEM #AzureAD #Okta #MCAS #CASB #SSO