The Essential User Access Review Template [Checklist Download]

The Snowflake platform has revolutionized how organizations store, process, and analyze large volumes of data. It offers a fully-managed data warehouse-as-a-service solution, providing a scalable and flexible architecture allowing seamless data integration from multiple sources. As Snowflake rises in popularity as one of the top ten cloud vendors in the world, its attractiveness to organizations also draws the attention of malicious attackers. The platform's widespread adoption and extensive use in storing valuable data make it a lucrative target for cyber threats. As a result, you must implement security measures, stay vigilant against emerging threats, and continuously update your defense mechanisms to safeguard Snowflake data sharing and infrastructure from potential attackers.This post will help you grasp how to use Snowflake's built-in logging features for your security operation routine. We will explore the relevant data Snowflake exposes for hunting and describe ten threat scenarios and how to detect them. We will also share a script to execute them and perform quick threat-hunting operations in your environment to stay secure and audit-ready. What is Snowflake? Snowflake is a cloud-based data platform that provides a fully managed and scalable solution for storing, processing, and analyzing large volumes of data. It is designed to work on top of popular cloud providers like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Snowflake is built with a unique architecture that separates storage and computing, allowing identities to scale resources independently based on their needs.  This architecture, combined with its ability to process semi-structured and structured data, enables Snowflake to deliver high performance and cost-efficiency for data workloads of any size. As we'll see in the next section, a Snowflake account can hold multiple databases without taking care of the infrastructure. Key Snowflake Logging Features Each Snowflake account has a default database called “SNOWFLAKE”. It is a shared read-only database that holds metadata and historical usage data related to the objects within your organization and accounts.   The SNOWFLAKE database has a built-in schema called "ACCOUNT_USAGE", which is a system-defined schema containing a set of views providing access to comprehensive and granular usage information for the Snowflake account. It is a valuable tool for monitoring and understanding how resources are utilized within your Snowflake environment.  The schema includes views that cover  user activity  query history  warehouse usage  login history  data transfer details, and more.   There are more logging mechanisms in Snowflake, such as INFORMATION_SCHEMA and READER_ACCOUNT_USAGE. During this post, we will rely on the following ACCOUNT_USAGE views: Exploring ACCOUNT_USAGE By default, each Snowflake account has a database called SNOWFLAKE that is accessible to the ACCOUNTADMIN role. You can grant additional roles and have access through the following command: GRANT imported privileges on database snowflake to role rezonate_integration; You can explore the available views by logging in as an ACCOUNTADMIN to your Snowflake account and performing the following steps: From the left pane, choose Data and then Databases. Select the SNOWFLAKE database and expand it. 3. Expand ACCOUNT_USAGE and select any of the views within it. Each available view in the schema has its own column structure. You can see the available columns for each view by clicking on the view name, choosing the Columns tab, and selecting “Explore available columns”. Comprehensive documentation per view is available, including the retention period and logging latency. Snowflake Data Governance - How to Access Snowflake Audit Logs The Snowflake logs are accessible through a few methods, as you’ll see below. 1. Snowflake Console  The most straightforward method of accessing the logs is logging in to a Snowflake account with a user that has read permissions to the  ACCOUNT_USAGE schema. Then, choose "Worksheets" from the left pane and ensure the worksheet is querying the correct data source. You should see something like the query browser below. 2. SnowSQL SnowSQL is a command-line tool provided by Snowflake designed to interact with Snowflake's data warehouse and execute SQL queries, manage data, and perform various administrative tasks. It acts as the official command-line client for Snowflake, allowing users to connect to their Snowflake accounts and work with data using SQL commands. Information about installing, configuring, and using it is available in Snowflake’s documentation. 3. Exporting to external storage Snowflake facilitates data export to contemporary storage services like AWS S3 through  "Stage" functionality. The data exported from Snowflake can be saved in various file formats. You can find detailed information about Stages on Snowflake's official documentation page.  Once the Stage setup is complete and data is exported, you have the flexibility to utilize your preferred analysis tool to centralize the data in a location of your choice. 4. Snowflake SDKs As well as the structured methods mentioned earlier, Snowflake supports native REST API accessible through different SDKs. It can be used by any script or tool for purposes like exporting data. An example is the Rezonate Threat-Hunting Tool, which takes advantage of Snowflake Python SDK to execute threat-hunting queries. We’ll find out more later in the blog.  Besides the Python SDK, the Snowflake team has developed drivers for many popular languages, including .NET, NodeJS, and Go. The full list is available here. 10 Snowflake Threat-Hunting Techniques to Implement Now  Now we’ve learned about Snowflake’s structure, basic permissions, and integrations, we can start threat-hunting. In this section, we will guide you through some critical threat-hunting scenarios to look out for and explain each. We will also mark the relevant Snowflake views, align them to the specific MITRE ATT&CK technique, and include our own query in Snowflake query syntax. Remember, you can copy and paste them directly to your worksheet. It is important to highlight that some hunting queries may have false positives, depending on the environment and may need adjustments to reduce noisy results. Scenario 1 - Brute Force on a Snowflake User A brute force attack on a Snowflake user happens when an attacker uses trial-and-error to repeatedly submit different combinations of usernames and passwords and eventually gain unauthorized access. To hunt for this type of attack, you can search for an attacker that performed more than X failed login attempts on at least Y target users, failing or ending up with a successful login. In failure cases, the activity may result in a user's lockout. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY Query -- Get users who failed to login from the same IP address at least 5 times select CLIENT_IP, USER_NAME, REPORTED_CLIENT_TYPE, count(*) as FAILED_ATTEMPTS, min(EVENT_TIMESTAMP) as FIRST_EVENT, max(EVENT_TIMESTAMP) as LAST_EVENT from SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY where IS_SUCCESS = 'NO' and ERROR_MESSAGE in ('INCORRECT_USERNAME_PASSWORD', 'USER_LOCKED_TEMP') and FIRST_AUTHENTICATION_FACTOR='PASSWORD' and       EVENT_TIMESTAMP >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); group by 1,2,3 having FAILED_ATTEMPTS >= 5 order by 4 desc; -- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" time MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 2 - Password Spray on a Snowflake Account A brute force attack on a Snowflake account involves an attacker repeatedly submitting different combinations of usernames and passwords to eventually manage to log in and gain unauthorized access. To hunt for any occurrence of this scenario, you can search for an attacker that performed more than 1 failed login attempt on at least Y unique target users, from the same IP address. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY Query -- Get users who failed to login from the same IP address at least 5 times select CLIENT_IP, REPORTED_CLIENT_TYPE, count(distinct USER_NAME) as UNIQUE_USER_COUNT, min(EVENT_TIMESTAMP) as FIRST_EVENT, max(EVENT_TIMESTAMP) as LAST_EVENT from SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY where IS_SUCCESS = 'NO' and ERROR_MESSAGE in ('INCORRECT_USERNAME_PASSWORD', 'USER_LOCKED_TEMP') and FIRST_AUTHENTICATION_FACTOR='PASSWORD' and       EVENT_TIMESTAMP >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); group by 1,2 having UNIQUE_USER_COUNT >= 1 order by 3 desc; -- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" time MITRE Technique Credential Access | Brute Force | ATT&CK T1110 Scenario 3 - Unauthorized Login Attempt to a Disabled/Inactive User  In some cases, Snowflake user accounts might have been disabled due to security concerns or maybe even as part of employee off-boarding. Monitoring login attempts to disabled users can help you detect unauthorized activities. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY Query -- Search for login attempts to disabled users select * from SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY where IS_SUCCESS = 'NO' and  ERROR_MESSAGE  = 'USER_ACCESS_DISABLED' MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 4 - Login Attempt Blocked by Network Policy Snowflake network policies are a set of rules that govern network communication and access control within the Snowflake data platform. A network policy can deny a connection based on the client’s characteristics, such as IP address, to enforce organization policy and reduce the chances of a compromised account in case of leaked credentials.By searching for these failed logins we can identify violations of the organizational policies that may suggest compromised credentials. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY Query -- Search for network policies blocked IP addresses select * from SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY where IS_SUCCESS = 'NO' and  ERROR_MESSAGE  = 'INCOMING_IP_BLOCKED' and EVENT_TIMESTAMP >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); Scenario 5 - Exfiltration Through Snowflake Data Sharing Snowflake administrators can share data stored in their accounts with other Snowflake accounts. An attacker might use shares to exfiltrate data from Snowflake resources stored on compromised accounts to external locations. Any unauthorized event of this nature is a big red flag. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY Query -- Search for new data shares select *  from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY  where REGEXP_LIKE(QUERY_TEXT, 'create\\s+share\\s.*','i') or REGEXP_LIKE(QUERY_TEXT, '\\s+to\\s+share\\s.*','i') and START_TIME>= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique Exfiltration | Transfer Data to Cloud Account| ATT&CK T1537  Scenario 6 - Exfiltration Through Snowflake Stage A Snowflake stage is an external storage location that serves as an intermediary for loading or unloading data into or from Snowflake, providing seamless integration with various cloud-based storage services. For example, an AWS S3 bucket can serve as a stage. You can use the following queries to search potential data exfiltration using this feature.  Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY SNOWFLAKE.ACCOUNT_USAGE.STAGES Query -- Search for stage-related statements select * from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY where QUERY_TEXT ilike '%COPY INTO%' and QUERY_TEXT ilike '%@%'; -- The following query will show the stages that were created in the last 24 hours select * from SNOWFLAKE.ACCOUNT_USAGE.STAGES where CREATED>= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique Exfiltration | Transfer Data to Cloud Account| ATT&CK T1537  Scenario 7 - Persistency Through Snowflake Procedures & Tasks Procedures and tasks are Snowflake features that automate and manage workflows. Snowflake Procedures: Procedures in Snowflake are user-defined scripts written in SQL or JavaScript that allow you to encapsulate a series of SQL or JavaScript statements as a reusable unit. Snowflake Tasks: Tasks are scheduled operations that automate repetitive tasks or workflows. They are defined using SQL or JavaScript and can include SQL queries, DML statements, or calls to procedures. Tasks are scheduled to run at specific intervals, such as hourly, daily, or weekly, making them ideal for automating data pipelines and regular data processing. An attacker might utilize procedures and tasks to maintain persistently in the organization or exfiltrate data over time. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY Query -- Search for new tasks select * from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY  where REGEXP_LIKE(QUERY_TEXT, '.*CREATE\\s+(OR\\s+REPLACE\\s+)?TASK.*', 'i') and START_TIME >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); -- Search for new procedures select * from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY  where REGEXP_LIKE(QUERY_TEXT, '.*CREATE\\s+(OR\\s+REPLACE\\s+)?PROCEDURE.*', 'i') and START_TIME >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique Execution | Scheduled Task/Job | ATT&CK T1053  Execution  | Automated Exfiltration | ATT&CK T1020  Scenario 8 - Defense Evasion Through Unset Masking Policy A Snowflake masking policy is a security mechanism that protects sensitive data within a database. It allows you to define rules for obscuring or redacting specific data elements, such as Social Security Numbers (SSNs) or credit card numbers, to limit their visibility to unauthorized users. Attackers might bypass masking policies by unsetting them, given the right permission, and then exfiltrating sensitive information. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY Query -- Search for unsetting of a masking policy select * from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY where QUERY_TEXT ilike '%UNSET MASKING POLICY%' and START_TIME >= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique Data Manipulation| Stored Data Manipulation | ATT&CK T1565  Scenario 9 - Data Exfiltration: Spikes in User Queries Volume If an attacker manages to infiltrate a Snowflake account, they may attempt to extract data from the databases hosted in the compromised account. To detect this type of activity, you can identify users who exhibit significantly higher data querying rates than their typical usage patterns. The subsequent query lets us pinpoint users who have executed queries resulting in larger data volumes than their average daily activity over the previous week.  Triage tip: The suspicion level increases as the difference between the calculated standard deviation of “total_bytes_written” and the sum of “stddev_daily_bytes” and “avg_daily_bytes” grows larger. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY Query -- Spikes in user queries WITH user_daily_bytes AS (   SELECT     USER_NAME AS user_name,     DATE_TRUNC('DAY', END_TIME) AS query_date,     SUM(BYTES_WRITTEN_TO_RESULT) AS total_bytes_written   FROM ACCOUNT_USAGE.QUERY_HISTORY   WHERE END_TIME >= CURRENT_TIMESTAMP() - INTERVAL '7 DAY'   GROUP BY user_name, query_date ), user_daily_average AS (   SELECT     user_name,     AVG(total_bytes_written) AS avg_bytes_written,     STDDEV_SAMP(total_bytes_written) AS stddev_bytes_written   FROM user_daily_bytes   GROUP BY user_name ) SELECT   u.user_name,   ROUND(u.total_bytes_written, 2) AS today_bytes_written,   ROUND(a.avg_bytes_written, 2) AS avg_daily_bytes,   ROUND(a.stddev_bytes_written, 2) AS stddev_daily_bytes FROM user_daily_bytes u JOIN user_daily_average a    ON u.user_name = a.user_name WHERE query_date = CURRENT_DATE()   AND u.total_bytes_written > a.avg_bytes_written   AND u.total_bytes_written > stddev_daily_bytes + avg_daily_bytes ORDER BY u.user_name; MITRE Technique Exfiltration | ATT&CK TA0010 Scenario 10 - Anomaly in Client Application For User If a user’s credentials are compromised or there is an insider threat, the attacker may attempt to use enumeration tools or client apps to perform massive data exfiltration. It’s likely that these tools haven't been used by the legitimate user in the past. For this case, detecting any new client app used by the user could be a red flag that is worth investigating. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.SESSIONS SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY Query -- User uses a new client application WITH user_previous_applications AS (   SELECT     USER_NAME AS user_name,     ARRAY_AGG(DISTINCT CLIENT_APPLICATION_ID) AS previous_applications   FROM ACCOUNT_USAGE.SESSIONS   WHERE DATE_TRUNC('DAY', CREATED_ON) < CURRENT_DATE()   GROUP BY user_name ), latest_login_ips  AS (   SELECT     USER_NAME,     EVENT_ID,     CLIENT_IP   FROM ACCOUNT_USAGE.LOGIN_HISTORY )  SELECT   s.USER_NAME AS user_name,   ARRAY_AGG(DISTINCT s.SESSION_ID),   ARRAY_AGG(DISTINCT s.CLIENT_APPLICATION_ID) AS new_application_id,   lh.CLIENT_IP as ip_address FROM ACCOUNT_USAGE.SESSIONS s JOIN user_previous_applications u   ON s.USER_NAME = u.user_name JOIN latest_login_ips lli   ON s.USER_NAME = lli.USER_NAME JOIN ACCOUNT_USAGE.LOGIN_HISTORY lh   ON s.LOGIN_EVENT_ID = lli.EVENT_ID WHERE DATE_TRUNC('DAY', s.CREATED_ON) = CURRENT_DATE()   AND NOT ARRAY_CONTAINS(s.CLIENT_APPLICATION_ID::variant, u.previous_applications) group by s.USER_NAME,lh.CLIENT_IP; MITRE Technique Credential Access |  ATT&CK TA0006 4 Additional Queries to Identify Snowflake Threats On top of the scenarios mentioned above, there are more relevant queries you can use to hunt for threats in a Snowflake environment. However, the results of these queries are harder to rely on since they require a deeper context of the regular activities in the organization to differentiate the legitimate operations from those that may be part of a threat. For example, imagine that MFA has been disabled for an administrator. This activity could be either part of a malicious operation or just an operational benign activity. To answer this question, you would need additional context: Who disabled the MFA device? Is it part of any task associated with an active project or duty? And If not,was it really the user, or is it a persistent action caused by an attacker? Query 1 - New Administrative Role Assignment  In the post-exploitation phase of a Snowflake attack, the attacker might create a new administrative user as a persistence mechanism. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS Query -- Search for new admin role assignments select * from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS where ROLE in ('ORGADMIN', 'ACCOUNTADMIN')  and CREATED_ON>= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique https://attack.mitre.org/techniques/T1136/ Query 2 - New Permissions Assigned to a Role In the post-exploitation phase of a Snowflake attack, an attacker may add permissions to a non-privileged role in an effort to achieve persistence using a low-privileged user. Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES Query -- Search for new admin role assignments select * from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES where ROLE NOT in ('ORGADMIN', 'ACCOUNTADMIN')  and CREATED_ON>= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique https://attack.mitre.org/techniques/T1136/ https://attack.mitre.org/tactics/TA0004/ Query 3 - Changes to Users Security Settings An attacker might change user security settings like passwords, MFA settings, or other authentication methods to ensure persistence, or as a post-exploitation step.  Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY Query -- Search for user security settings changes select * from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY where QUERY_TEXT ilike '%ALTER%USER%'        and QUERY_TYPE = 'ALTER_USER'        and REGEXP_LIKE(QUERY_TEXT, '.*(PASSWORD|ROLE|DISABLED|EXPIRY|UNLOCK|MFA|RSA|POLICY).*', 'i')       and START_TIME>= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique https://attack.mitre.org/techniques/T1098/ Query 4 - Changes to Network Policies An attacker might alter network policies to allow traffic from a specific IP address.    Relevant Snowflake View SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY Query -- Search for network policies settings changes select * from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY where (QUERY_TYPE in ('CREATE_NETWORK_POLICY', 'ALTER_NETWORK_POLICY', 'DROP_NETWORK_POLICY') or        QUERY_TEXT ilike any ('% set network_policy%', '% unset network_policy%') )       and START_TIME>= DATEADD(HOUR, -24, CURRENT_TIMESTAMP()); MITRE Technique https://attack.mitre.org/techniques/T1562/004/ Choose a Reliable, Fast, and Simple Snowflake Threat-Hunting Tool In our pursuit to empower organizations with proactive cybersecurity measures, Rezonate is excited to introduce our open-source tool designed specifically for threat-hunting in Snowflake. This tool leverages Snowflake SDK to run the different threat models mentioned in this post and allows you to easily start your own hunting journey in your own environment. Feel free to suggest expansions and improvements – we’d love to hear from you 🙂 You can find a link to our repository here.

In the ever-evolving world of cybersecurity, staying steps ahead of potential threats is paramount. With identity becoming a key for an organization's security program, we increasingly rely on Identity providers (IdP) like Okta for identity and access management, and for federating access to cloud services, systems, and critical SaaS applications. Therefore, the logs produced by these systems become a critical source of information that can help you detect and eliminate threats before they wreak havoc. This blog post is your compass across a wide range of available Okta logs. Whether you’re a seasoned security professional or just getting started in the field, this step-by-step guide will empower you to turn raw data into actionable insights. We’ll explore: Each Okta audit log, learning how to analyze and extract critical information from How to uncover hidden threats, analyze their patterns, and respond effectively. From detection of brute force and MFA fatigue attempts to impossible traveler and privilege escalation techniques A set of free tools the Rezonate team has provided you to collect, analyze, hunt, and detect identity threats faster and easier. Understanding Okta Audit Logs Okta's System Log API records various system events related to an organization, providing an audit trail that can be used to understand platform activity and diagnose problems. The System Log API gives near real-time, read-only access, capturing a wide range of data types and the exact structure of each change. That being said, some data points are agnostic and appear in each log record. Here is the log structure scheme, as defined in the Okta Documentation: Event Structure Schema (Okta docs) Every property in this log could be useful in certain use cases, but we highlighted some properties that you should focus on for most investigations and hunting scenarios: UUIDUnique identifier for the eventPublishedEvent timeEvent TypeDescribe the type of the event, from a list of ~850 event typesActorDescribe the entity (user, app, client, etc.) that acts. It includes details like ID, type of actor, alternative ID (which is the user’s email address), and display nameClientDescribes the client that issues the request that triggers an event. It provides contextual information about the user, such as HTTP user agent, geographical context, IP address, device type​​ , and network zone.TargetDescribes the entity that an actor acts on, such as an app user or a sign-in token. It also includes details like ID, type, alternative ID, and display name.Note that in some events, there could be more than one Target object, in these cases, it's best to find the relevant target based on its type (AppInstance, AppUser, etc..)Authentication ContextProvides context about the credentials provider and authentication type of the connection. Includes the externalSessionId which is the Session ID of the operating user.Security ContextInclude context regarding the IP Address of the client. Useful data points within this object are isp (Internet Provider that the request was sent from) and asOrg (the organization that is associated with the asn)Debug ContextInclude detailed, per event, context with additional information such as device hash (DtHash) or ThreatSuspected OutcomeInclude the result for the event (such as Login request), in the Result field and the reason for this result in the Reason field. Accessing Okta Audit Logs Okta keeps the data accessible for customers with a retention of 90 days, and during this period there are primarily two ways to access it: 1. Okta Admin Console Via the Okta Admin Console, Administrative roles, enabled for management of policies, users, groups, and “Audit Log” reports, can use the interface by clicking “System Log” in the reporting menu: Alternatively, the web interface can be accessed directly through the following URL(replace OKTA_DOMAIN with your unique okta domain name) https://{OKTA_DOMAIN}-admin.okta.com/report/system_log_2 Through the web interface, we can apply different filters on the event time or any of its properties, and see the results, and several statistics, directly from the console. For example, in the query below we can see all of the activity against one specific application in the tenant - In this case, it's AWS Client VPN. You can also see the different actors that performed the operations involving this target application. Query results - Okta Admin Console On top of the basic Search panel it is also possible to add combinations of filters for more specific criteria. In the example below, we are looking for all events performed by a specific user, against a specific application, which resulted in ALLOW. This can be achieved by clicking the “Advanced Filters”. Advanced filters, Okta Query Log After applying filters, it's possible to either examine the details of each event or to export the filtered logs to a CSV file (by clicking on the Download CSV button). Note that this feature is limited to 200,000 results, so for bigger exports, the Okta System Log API is preferred. 2. Okta Admin Console The Okta System Log API is the programmatic counterpart of the System Log UI, and it offers the ability to execute more advanced queries and filters against the Okta logs. Operating through this interface requires either OAuth integration with the okta.logs.read scope or Read-only API Key. Here is an example of an API call, selecting all events of a specific type (user.session.end): GET /api/v1/logs?filter=eventType eq "user.session.end" HTTP/1.1 Host: {OKTA_DOMAIN} Accept: application/json Content-Type: application/json Authorization: SSWS {{apikey}} The most common use case of operating through the API Interface would be to export batch data in real-time to another system, such as streaming logs into a SIEM or any other security product, to monitor and conduct introspection and audit​.  One of the biggest advantages of exporting the data with the System Log API is to correlate the collected logs with other data sources, adding critical context and completeness of data making the advanced investigation a lot easier. Rezonate real-time correlated information for users' activities 3. Exporting The Logs As mentioned, there is more than one way to get your hands on the relevant Okta logs and perform your threat-hunting actions on them. Exporting through the Admin Console is easy, yet size-limited while exporting the data through the API could be more tricky for beginners. To get around this limit, we have created a basic tool that allows you to export Okta logs into a file, based on a time frame. It can be downloaded directly from the Rezonate github repository. Let the Hunt Begin After we have exported the logs through one of the methods, we can get to work and start analyzing the data to start identifying potential risks and threats. For the hunting process, you can use any data analytics solution or database based on your  preferences, as long as it supports filtering and grouping of data. In this section, we will guide you through some of the top-relevant threat scenarios to look out for, explaining them, marking the relevant Okta events, aligning to the specific MITRE ATT&CK technique, and including our own query in PostgreSQL query syntax. Important to highlight that some of the hunting queries may have false positives, depending on the environment, and may need some adjustments to reduce noisy results. Scenario 1 - Brute Force on an Okta User A brute force attack on an Okta user involves an attacker repeatedly trying different passwords in an attempt to eventually guess correctly and gain unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than X failed login attempts on at least Y target user, failing or ending up with a successful login. In cases of failure, the activity may result in a user's lockage, or Okta blocking the client IP. The same logic can be applied to two different types of events: user.session.start - Search for traditional Brute Force attack user.authentication.auth_via_richclient - Search for Brute Force attack that uses legacy authentication protocols. Legacy authentication does not support MFA and is thus being used to guess passwords on a large scale Relevant Okta Eventsuser.session.startuser.authentication.auth_via_richclientQuery-- Get users who failed to login from the same IP address at least 5 timesselect count(id), "clientIpAddress", "actorAlternateId", min(time) as "firstEvent", max(time) as "lastEvent"from okta_logswhere "eventType" ='user.session.start' and "actionResult"='FAILURE' and "resultReason" in ('INVALID_CREDENTIALS', 'LOCKED_OUT')and "time" > now() -interval '1 day'group by "clientIpAddress", "actorAlternateId"having count(id) >= 5order by count desc-- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" timeMITRE TechniqueCredential Access | Brute Force | ATT&CK T1110 It's also worth mentioning that based on the tenant  behavioral configuration Okta can also enrich each sign-in attempt with additional fields that add more context such as: Threat Suspected  New Device New IP Address New Geo Location  (Country\City\State) Including these enrichments in the query can help reduce false positives and focus on the more relevant events. Scenario 2 - MFA Push Notifications Fatigue Okta MFA Push Notification Fatigue refers to user exhaustion or annoyance resulting from frequent multi-factor authentication (MFA) push notifications sent by Okta for verification purposes. In this scenario, we assume that an adversary has already compromised user credentials and start flooding the legitimate user with Push notifications, with the hope that the user will approve one of them by mistake. To hunt for this threat scenario, you can search for more than X MFA push notifications, within a short period of time, originating from the same IP address. A successful MFA fatigue will also generate a user.authentication.auth_via_mfa event. This event will be logged after the targeted user was tricked to allow suspicious access. Relevant Okta Eventssystem.push.send_factor_verify_pushuser.authentication.auth_via_mfauser.mfa.okta_verify.deny_pushQuery-- Genericselect count(id), "clientIpAddress", "actorAlternateId", min(time) as "firstEvent", max(time) as "lastEvent"from audit_log_okta_idp_entitywhere "eventType" ='system.push.send_factor_verify_push'and "time" > now() -interval 'X hour'group by "clientIpAddress", "actorAlternateId"having count(id) >= 5 -- configurable number of MFA attemptsorder by count desc-- Find FAILED MFA fatigue attempts that were denied by the userselect count(id), "clientIpAddress", "actorAlternateId", min(time) as "firstEvent", max(time) as "lastEvent"from audit_log_okta_idp_entitywhere "eventType" ='user.mfa.okta_verify.deny_push'and "time" > now() -interval '24 days'group by "clientIpAddress", "actorAlternateId"having count(id) >= 5order by count descMITRE TechniqueCredential Access | Multi-Factor Authentication Request Generation | ATT&CK T1621 Scenario 3 - Okta ThreatInsight Detection Okta ThreatInsight is a security module that aggregates sign-in activities meta-data across the Okta customer base to analyze and detect potentially malicious IP addresses and prevent credential-based attacks. It is also a great starting point to find an initial indication for identifying targeted attacks against specific identities in the organization’s directory. Relevant Okta Eventssecurity.threat.detectedQueryselect min(time) as "first_event", max(time) as "last_event", "actorName", "actorType", "actorAlternateId", "eventType", "threatDetections"from audit_log_okta_idp_entity aloiewhere "eventType" ='security.threat.detected'group by "actorName", "actorType", "actorAlternateId", "eventType", "threatDetections"MITRE TechniqueCredential Access | Brute Force | ATT&CK T1110 Scenario 4 - Okta Session Hijacking A Session Hijacking attack refers to a situation in which an attacker was able to get his hand on the browser cookies of an authenticated Okta user. This risk is mostly involving targeted attacks and includes either malware infection on the user endpoint or a man-in-a-middle (MITM) attack that hijacks the user's traffic. (read more in this Okta Article). Okta’s dtHash serves as a useful tool for identifying stolen Okta sessions. Okta's dtHash, also known as the "de-identified token hash," is a cryptographic hash function utilized to safeguard user identifiers within Okta sessions. Its purpose is to mitigate the risk of sensitive user information being compromised in the event of a data breach or unauthorized access to Okta's portal or applications. For our hunting, we will search for a stolen Okta user's session that is being utilized in a different geographical location. We will detect it by searching for a dtHash that has been used from multiple geo-locations. Important Note - To enhance the effectiveness of detection, the session length limit plays a vital role. Okta recommends customers set a session length limit of 2 hours. It is worth noting that increasing the length limit raises the possibility of encountering false positives in the detection process. Relevant Okta EventsEvery Okta eventQueryselect count(distinct "clientCountry"), "actorAlternateId", "dtHash" from audit_log_okta_idp_entitywhere "dtHash" is not nullgroup by "actorAlternateId","dtHash"having count(distinct "clientCountry") >1MITRE TechniqueCollection | Browser Session Hijacking | ATT&CK T1185  Scenario 5 - Okta Privilege Escalation via Impersonation In this threat scenario, an Okta application administrator could impersonate another user by modifying an existing application assignment, specifically by editing the 'User Name' field used by Okta to identify users in the destination application. This manipulation allows the administrator to authenticate themselves as a different user in any federated application, presenting a risk of privilege escalation, especially in critical SaaS applications like AWS IAM Identity Center. Relevant Okta EventsApplication.user_membership.change_usernameQueryselect * from audit_log_okta_idp_entity aloie where "eventType" ='application.user_membership.change_username'-- For each result, check the target application. If the target application is relevant for this detection, the target AppUser is the field that we need to validate. An impersonation configuration was set if there's a mismatch between the targetName and the targetAlternateId.MITRE TechniquePersistence | Account Manipulation | ATT&CK T1098 Scenario 6 - Phishing Attempt (Blocked by FastPass) FastPass is Okta’s passwordless solution designed to minimize friction for the end-user during the login process while protecting against real-time phishing attacks. By adding additional layers of context to the login process (such as managed device information) it allows Okta to identify potentially suspicious authentication flows and it automatically blocks them, generating an indicative log in the audit. We can use this event result to identify potentially compromised credentials of Okta identities. Relevant Okta EventsUser.authentication.auth_via_mfaQueryselect * from audit_log_okta_idp_entity aloie where "eventType" ='user.authentication.auth_via_mfa' and "actionResult" ='FAILURE' and "actionResult" = 'FastPass declined phishing attempt'MITRE TechniqueInitial Access | Phishing | ATT&CK T1566 Scenario 7 - Okta Impossible Traveler Within the realm of threat hunting, the concept of the "impossible traveler" denotes a detection method employed to uncover compromised identities. Specifically, it involves identifying instances where an identity records successful login events from two distinct geographical locations within a brief time span, which may suggest a compromise. To identify potentially compromised identities, conduct a search for users who have experienced successful sign-in events from different geographical locations within a short timeframe. It is recommended to exclude VPN and proxy addresses from the analysis to focus on genuine geographic variations and to avoid false positives. If pre-configured properly, you can also use  Okta's velocity within the triage process to elevate the suspicion level of a particular sign-in location over others.  Relevant Okta EventsUser.session.startQueryselect count(distinct "clientCountry"), "actorAlternateId" from audit_log_okta_idp_entity aloie where "eventType" ='user.session.start'and "time" > now() -interval '1day'group by "actorAlternateId"having count(distinct "clientCountry") > 1MITRE TechniqueInitial Access | Valid Accounts | ATT&CK T1078 Scenario 8 - Cleartext Credentials Transfer Using SCIM  The SCIM (System for Cross-domain Identity Management) protocol is a standardized method for managing user identities and provisioning them across different systems and applications. It simplifies user management by providing a common framework for creating, updating, and deleting user accounts, as well as managing user attributes and group memberships, across various platforms. One of Okta's features allows setting a sync workflow, pushing any password changes to a target SCIM application. Configuring this requires Admin privileges to the Okta Console, so most likely to be a legitimate operation, yet, on rare occasions could be part of a hostile password-stealing attack by an insider.To detect this, we can search for the credentials export activity, and check that all of the target applications are legitimate and intended. Relevant Okta Eventsapp.user_management.push_okta_password_updateQueryselect * from audit_log_okta_idp_entity where "eventType" ='app.user_management.push_okta_password_update'MITRE TechniqueCredential Access | Exploitation for Credential Access | ATT&CK T1212 Scenario 9 - Application Access Brute Force When an attacker gains access to a compromised Okta user, they may attempt to use Okta’s portal to connect to various trusted applications. However, the attacker's attempts to access multiple apps can be denied by authentication policy requirements that have not been satisfied, such as the absence of MFA. An attacker may try to access different applications one by one, until finding those that allow him to operate without additional factors or conditions. To identify this behavior we will search for a user who has experienced multiple failed access attempts to different applications within a short time frame. This could raise a red flag and require a follow-up investigation of the user’s activity. Relevant Okta Eventsapplication.policy.sign_on.deny_accesstQueryselect count(targets."targetId"), logs."actorAlternateId", logs."clientIpAddress", logs."actorAlternateId"from audit_log_okta_idp_entity logs, audit_log_target_okta_idp_entity targetswhere "eventType"='application.policy.sign_on.deny_access'and targets."auditLogId" = logs."id"and targets."targetType" = 'AppInstance'and "time" > now() -interval '1 month'group by "clientIpAddress", "actorAlternateId"having count(targets."targetId") >= 5order by count descMITRE TechniqueCredential Access | Exploitation for Credential Access | ATT&CK T1212 On top of the scenarios mentioned above, there are more interesting events that can be used to hunt for threats in an Okta environment. These events are harder to rely on since they require having a deeper context of the regular activities in the organization to differentiate the legitimate operations from those that may be part of an attack. For example, an API Token created by an administrative user. It could be malicious or legitimate, and requires triage for a verdict:  Why did the user create this API key? Is it part of any task associated with an active project? If not,  Was it really the user, or is it a persistent action by a hostile actor? Okta Event TypeDefinitionMITRE ATT&CKuser.session.access_admin_appOkta admin T1078system.api_token.createAdministrative API Token CreatedT1098.001user.account.privilege.grantgroup.privilege.grantAdministrative Privileges Assignment N/Auser.mfa.factor.*MFA Changes T1556system.idp.lifecycle.create system.agent.ad.createAddition of external IdPT1556policy.rule.*policy.lifecycle.*application.policy.*Authentication Policy Changes.T1556network_zone.rule.disabledzone.*Changes to Network ZonesT1556user.account.report_suspicious_activity_by_enduserSuspicious Activity ReportedN/Auser.mfa.attempt_bypassAttempt to Bypass MFAN/Asecurity.request.blockedAccess from a Known-Bad IP was Blocked N/Auser.session.impersonation.initiateOkta Impersonation Session StartedN/A To see how Rezonate can help detect risks and threats across your Okta infrastructure, contact us for more information or request a free demo. Like this article? Follow us on LinkedIn.

As we at Rezonate  analyze the 2023 Verizon Data Breach Investigations Report, an unmistakable deja vu moment grips us: A staggering 74% of all breaches are still exploiting the human factor — be it through errors, misuse of privileges, stolen credentials, or social engineering. This recurring theme serves as a clear call for businesses to switch gears and move away from static security approaches towards a more dynamic, identity-centric model. An Unyielding Threat Landscape Year after year, our IT landscape and attack surface continue to expand. Cloud adoption has soared, hybrid work becoming the norm, and our infrastructure continues to evolve. Yet, the threat statistics remain frustratingly consistent. This consistency points to a key issue: our security measures aren’t keeping up. Traditional security approaches, designed for a static operational model, distributed across tools and teams, are only increasing complexity and not meeting the demands of an ever-changing, dynamic infrastructure. In turn, this provides ample opportunities for attackers. The commonplace of Shadow access, increased attack surface, and greater reliance on third-parties all present identity access risks, making it harder see, understand and secure the enterprise critical data and systems. How Are Attackers Winning? Attackers are using simple yet effective methods to gain access to valuable data without the need of any complex malware attacks. A variety of account takeover tactics, bypassing stronger controls such as MFA, compromising identities, access, credentials and keys, brute forcing email accounts, and easily laterally expanding as access is permitted between SaaS applications and cloud infrastructure. Stolen credentials continue to be the top access method for attackers as they account for 44.7% of breaches (up from ~41% in 2022). Threat actors will continue to mine where there’s gold: identity attacks across email, SaaS & IaaS, and directly across identity providers. Where We Fall Short Security teams are challenged by their lack of visibility and understanding of the entire access journey, both across human & machine identities, from when access is federated to every change to data and resource. We're also seeing gaps in real-time detection and response, whether it be limiting user privileges or accurately identifying compromised identities. These shortcomings are largely due to our reliance on threat detection and cloud security posture management technologies that fail to deliver an immediate, accurate response required to successfully contain and stop identity-based threats. What Should You Do Different? We’re observing that businesses adopting an identity-centric approach:  Gain a comprehensive understanding of their identity and access risks, further breaking data silos, Are able to better prioritize their most critical risks and remediation strategies, Can more rapidly adapt access and privileges in response to every infrastructure change , Automatically mitigate posture risks before damage is inflicted, and Confidently respond and stop active attacks. Identities and access, across your cloud, SaaS, and IAM infrastructure, is constantly changing. Your security measures must evolve in tandem. The identity-centric operating model enables businesses to proactively harden potential attack paths and detect and stop identity threats in real-time. Breaking the cycle in Verizon DBIR 2024 Now is the time to make a change. Let’s change our old set-and-forget habits and know that security needs to be as dynamic and adaptive as the infrastructure it is protecting.  For more information about how can Rezonate help you build or further mature your identity security, contact us and speak with an identity security professional today.  This post was written by Roy Akerman, CEO and Co-Founder at Rezonate, and former head of the Israeli Cyber Defense Operations.

A pivotal shift from perimeter-based security measures is being witnessed in the rapidly shifting landscape of cybersecurity. Identity management is becoming more complex with the move to the cloud, calling for a thorough re-evaluation and fortification of existing security frameworks. Threat detection and response mechanisms must be recalibrated as the narrative of identity compromise unravels at an alarming pace. Here is your guide to identity-centric security challenges, showcasing real-life breach examples and introducing innovative frameworks that will allow you to: Examine recent high-profile breaches where compromised identities are the common denominator. Recognize how identity-related security challenges increase with the shift to cloud environments, moving away from traditional centralized identity management. Highlight the limitations of traditional detection methods. Transform threat detection by applying tactic, technique, and procedure (TTP) mappings to cloud and Identity and Access Management (IAM) infrastructures. Reveal a framework that acknowledges and prepares for identity threats across various clouds, establishing a foundation for a strong identity-centric security paradigm. 100% of Breaches Involve Compromised Identities User and machine identities, access privileges, trust relations, and credentials have been threat actors' prime targets for over a decade. A brief overview of the Verizon 2023 Data Breach Investigation Report (DBIR) and all previous ones is enough to determine that identities are the number one target for security breaches. This problem has quadrupled with organizations’ transition to the cloud.  If you’ve read the security news in the past 12 months, you probably noticed high-profile breaches at MGM Casinos, Uber, Sony, Okta, Microsoft, and many other organizations that were not published to the public. The root cause of all those incidents is compromised identities. In the on-premise world, most identities were managed in a single directory, such as the “Active Directory," allowing for more straightforward and less complex management despite higher risk as a “single point of failure." In the on-prem world, threat actors tried to compromise and steal identities and their credentials through the Endpoints and through targeting the Active Directory itself.  Well-known tactics, techniques, and procedures (TTPs), such as the usage of variations of the Mimikatz tool, as well as novel methods to execute pass-the-ticket (PtT) and pass-the-hash (PtH) techniques were researched and investigated by security professionals worldwide. Other detection techniques included incrimination of outbound network traffic to well-known malicious addresses (IPs and Domains) to identify a potential Identity breach.  As we evolve to the next phase of identity evolution, we need to be able to answer the following: How do we prevent identities from being breached? How do we detect and respond fast enough when identity credentials are lost or compromised? How do we make sure identity privileges won’t be abused? How do we ensure that the complex trust relations between the various platforms will not be taken as a vantage point by hackers? Once you hack this, you hack it all. The Cloud Changed Everything When organizations transition to the cloud, it most notably impacts the identity architecture. Transitioning from a centralized Identity management to decentralized identity management. From a “single source of truth” to multiple sources of truth, some have trust (or federated access) between them, and others are completely managed separately.  An average organization has more than three Identity management platforms across SaaS, Identity Providers, and Cloud Infrastructure providers. In addition to the distributed management and complex architecture, the cloud also made everything publicly accessible - in the past, organizations trusted their perimeter and had some idea of which interfaces and “login screens” were internet-facing. For cloud-first organizations, everything is publicly accessible.  Every login interface is open for everyone to try and log in to SaaS applications such as Salesforce, M365, GitHub, and Snowflake; Cloud providers (IaaS) such as AWS, Azure, or GCP; and identity providers (IdPs) such as Okta, Azure AD or Google workspace.  The perimeter is dead, there are no boundaries, and the barrier to identifying a specific organization’s login interface in Okta, Azure AD, or Google is pretty low and depends on how well someone can search the internet. In addition, the authentication and authorization methods changed drastically, and no longer rely on protocols such as NTLM or Kerberos, but are REST API based and fully documented so that every threat actor could try and abuse those APIs.     Looking for malware or tool signatures is no longer relevant, and the detection and prevention techniques must change. A quick example that showcases that the traditional threat detection approach is insufficient is the recent MGM Resorts data breach, which allegedly started on September 7, 2023, and was detected by MGM Resorts on September 29, 2023. The breach involved: A complex series of events. Leading to significant data exposure and operational disruptions. Causing a financial impact estimated at around $100 million.  Potential attack flow of the MGM Resorts breach “Hackers don’t hack, they mostly login” Identities in cloud environments are the connective tissue between different systems, and the “connection” between those systems is done via APIs and trust between different IAM platforms.  Most of those systems and APIs require authentication (if not, that is a significant problem that needs to be addressed ASAP). This leaves attackers focused on identity takeover with two options to breach an organization: Try to abuse \ exploit those APIs and bypass their authentication Steal an identity’s credentials and leverage those credentials for further lateral movement and privilege escalation Option #1 requires high sophistication unless there are known vulnerabilities that were not patched. In that case, the initial access through the vulnerable asset shouldn’t be too complex. Either way, getting from the exploited asset to the asset the threat actor desires (the crown jewel) will still (most likely) require a stolen identity to get there. Option #2, on the other hand, doesn’t require high sophistication but more consistency and access to stolen credentials DBs or relevant people like Admins or users of the targeted companies (as demonstrated in the past by Lapsus$ and SCATTERED SPIDER\ Roasted 0ktapus\ UNC3944). Once a threat actor can access legitimate, stolen credentials, they have a “Golden ticket” (pun intended) and paved road to critical assets and sensitive information. With legitimate identity being stolen, detecting malicious activity is becoming increasingly challenging and near impossible. The new paradigm is that the defenders' life is getting much more complicated and requires very strong technical skills across many technologies, while the skills required to breach an identity is some “Tor” magic, some spare cash, or just consistent brute forcing \ Password spraying & Email scraping from Linkedin coupled with an organization’s Okta or Azure AD login interface. A Complex IAM Landscape Requires a New Detection Approach Due to the increasing complexity of cloud IAM (Identity and Access Management) platforms and the relationships between them and different authentication and authorization protocols, a new approach to detecting malicious activity Vs. A benign activity is needed.  In the On-premise Endpoint world, many detection engines relied on atomic indicators (IOCs) such as IP addresses, File hashes, Domain names, specific strings in a command line, or file metadata (e.g., string analysis). There are even more advanced techniques. Some might call Behavioral indicators (IOBs) looking to inspect specific OS-level API calls or process execution tree analysis to determine if the executed program is malicious or not. Those methods are not enough in a “multi-threaded” API world. Using one or even both of those methods isn’t enough, as one identity can generate millions of API calls daily across multiple cloud & SaaS services.   The new approach needs to include the following detection building blocks TTP mapping & adjustment to cloud infrastructure, SaaS Apps, and IAM infrastructure. Statistical analysis of identity activities (e.g., UEBA) & profiling Blast radius analysis and access map calculating the access trusts between different IAM infrastructures. Exposure of an identity (how susceptible it is to be exploited \ compromised) Known IP & Domain block lists \ TI Note: It is crucial to correlate and aggregate 3rd party vendor indicators (such as Okta, AWS, and AAD) to reduce friction and redundant alerts. Market Maturity We’ve gone a long way in researching and investigating various tools and techniques for stealing credentials and bypassing authentication mechanisms on-prem. Frameworks like the MITRE ATT&CK have been developed to help map the different TTPs used in the attack lifecycle.  Unfortunately, we are not as close to having that level of understanding and knowledge of the cloud. The cloud and its trust relationships are entirely different from the On-Prem world and require a different approach to prevent, detect, and respond to Identity threats. Rezonate has developed an equivalent to MITRE ATT&CK framework to address Identity-related threats in the cross-cloud world. The goal of this framework is to help organizations to understand better and prepare for identity threats. Most of those TTPs rely on legitimate actions and events across the different platforms.  MITRE Framework For ITDR Frameworks like MITRE ATT&CK have been invaluable for understanding on-premise threats. However, the cloud presents a different set of challenges that are not fully addressed by existing frameworks. Rezonate Identity ATT&CK Framework Rezonate has developed a framework specifically designed to address identity-related threats in a multi-cloud environment. This framework aims to help organizations better understand and prepare for the evolving landscape of identity threats. It covers various TTPs that rely on legitimate actions and events across different providers, offering a comprehensive view of potential vulnerabilities. Rezonate is proud to share this framework with the security community and embrace an identity-first approach to threat detection and response: Rezonate MITRE-Like framework for Identity Threat Detection and Response The Rezonate approach At Rezonate, we practice what we preach, and we are committed to developing a cutting-edge ITDR Platform that will reduce the mean time to detect (MTTD) and mean time to respond (MTTR) to identity threats in real time. Have you ever wondered how a breach starting from an Identity provider (e.g., Okta or Azure AD) could progress into business-critical assets such as production cloud infrastructure (AWS) or Data warehouses (Snowflake) containing PII? How can you stitch it all together into a single attack flow in real-time? Track which configuration changes happened when a compromised identity changed the access policy of a blob or a bucket. Or maybe a compute resource? How about a compromised identity reading significant amounts of data from various databases all at once and doing it from a completely foreign location to where this identity usually resides? How about a compromised identity accessing a business-critical SaaS application (Salesforce, Hubspot) containing all of your revenue information and customer data? Those scenarios and the threat detection approach that is outlined in this blog have been developed for several months by Rezonate labs, and we are proud to present what a cross-correlated, behavioral & profiling based, access and privileges risk-based cloud identity threat looks like in one shot or 200 words: 1. The attack was initiated by a "Malicious Actor." The attacker is trying to gain initial access through brute force vectors. The attacker has targeted Barb W, an employee at Trexony.com who owns the Email address "barb.w@trexony.com". 2. Initially, the “Malicious Actor” has several unsuccessful attempts at a brute force attack. 3. A few minutes later, the attacker successfully gains initial access using brute force methods. 4. After achieving initial access, the attacker seems to move laterally, trying different avenues: SSO Azure AD to Snowflake: The attacker gains access to Snowflake using Single Sign-On (SSO) credentials from Azure Active Directory (AD). SSO Azure AD to AWS: Another lateral movement involves utilizing the Azure AD SSO credentials to access AWS resources. 5. Data Exfiltration:  Within Snowflake, the attacker is querying large amounts of data. Data is exfiltrated (or stolen) and uploaded to a publicly accessible S3 bucket that the attacker made public (it was private before).  6. Storage Enumeration Attack: The attacker is also attempting a storage discovery or enumeration attack, possibly trying to identify more data storage or resources, through which he enumerates: QLDB Resources RDS Resources  S3 Resources  Try Rezonate today to assess your organization’s identity risk!

Like a Swiss watch, your organization has hundreds, if not thousands, of moving parts. Each employee accesses a multitude of different documents, systems, and software every day, and they probably rely on their colleagues to make this happen.  The global market for Enterprise Identity Management Software Solutions is booming, with a value of $20.75 billion – and this is just a sign of things to come in this industry. There are so many vendor options, each one with different features, and choosing the right tool for your organization can feel like searching for a needle in a haystack. Since we live in an era where cyberattacks dominate the digital world (and the headlines), choosing a vendor isn’t a decision to take lightly.  What are Enterprise Identity Management Software Solutions? Enterprise Identity Management Software Solutions, commonly known as IAM (Identity and Access Management), provide tools, policies, and processes designed to manage and secure digital identities within your organization. These solutions ensure that the right people have access to sensitive data and applications at the right times, all while upholding security and compliance standards.  IAM systems can handle a range of critical functions, including user authentication, authorization, and user provisioning. They're instrumental in managing digital identities, allowing employees and customers to access information and applications efficiently and securely. Benefits of Enterprise Identity Management Software Solutions Enhanced security: Authenticate and authorize users, protecting sensitive data and applications. Efficient onboarding and offboarding: Reduce administrative workload, granting new employees access swiftly and revoking access for departing staff. Visibility and privilege control: Gain clear visibility into user access paths and changes in privileges for audits, regulatory compliance, and early detection of potential security risks. Source Key Features to Look For in an Enterprise Identity Management Software Solution Multi-factor authentication (MFA) significantly enhances security by adding an extra layer of protection beyond just passwords. User self-service portals allow users to manage their accounts, reset passwords, and request access. Role-based access control (RBAC) assigns access permissions based on job roles. Single sign-on (SSO) provides one set of login credentials per user to access all services. Test to ensure seamless integration and deployment with your existing technology stack. How to Choose an Enterprise Identity Management Software Solution Here are some key aspects to weigh up when evaluating IAM solutions. Look for a solution that can grow and scale with your organization's needs. Consider the level of support and maintenance services offered by the solution provider. Calculate the total cost of ownership, including licenses, installation, and continuous maintenance. Look for a user-friendly interface. Check the vendor’s support for security features like MFA and encryption. Top 10 Enterprise Identity Management Software Solutions  1. Okta  Source Okta is an identity management tool that allows you to customize and configure policies to match your unique requirements. See our recent blog for Okta Security best practices and essential tips.  Key features: Universal Directory feature is a centralized store for user profiles and identity data. Maintains a competitive pricing structure suitable for both large and small businesses. Adaptive authentication function assesses the risk associated with each login attempt based on user location, device, network, and behavior, providing enhanced security. Best for: Building customizable authentication and authorization services for your applications. Price: Enterprise pricing is by inquiry.  Review: “Okta can hold up multiple applications and serve as a one-stop shop, as you can access all these tools by logging in to one application.” 2. Rezonate If you’re in the market for identity management software, you’ll likely need to manage your identity posture and protect against identity threats too. Rezonate is a radically simple identity security platform that provides end-to-end coverage and visibility of all access, from the creation time to the last active session and activity performed.  Key features: Easy one-click deployment gets you set up within 15-60 mins for large organizations. Simple and highly scalable. Gives you complete visibility over accounts, assets, and identity levels. Real-time risk scores help your teams learn and recognize security gaps. Proactively enforces a real-world least privileged access.  Detects malicious impersonating, access rights, and excessive privileges before damage occurs.  Best for: Continuous protection, end-to-end visibility, and risk prioritization.  Price: Contact Rezonate customer support for pricing details.  Review: “Our DevOps team uses Rezonate daily to understand context and prioritize critical risks. We are now 10X faster and more effective in remediating security gaps.” 3. Microsoft Entra ID (previously called Azure AD)  Source Microsoft Entra seamlessly integrates with Microsoft software products, providing additional authentication elements beyond passwords, such as SMS codes, phone calls, mobile app notifications, and biometrics. See our recent blog on Azure Active Directory threat hunting techniques for help setting up and using Azure AD.  Key features: Password synchronization. Customizable single sign-on (SSO) portals for each user. Authentication support for on-premises applications Supports MFA.  Best for: Organizations that utilize Microsoft services such as Office 365 and Azure. Price: Microsoft Entra offers four pricing plans: Free, P1 ($6 user/month), P2 ($9 user/month), and Governance ($7 user/month).  Review: “It adds a strong layer of security when accessing my Microsoft account and apps, especially when working from home.” 4. CyberArk Identity Security  Source CyberArk is a comprehensive identity management toolkit, including privileged access, secrets management, endpoint privilege security, cloud privilege security, and workforce and customer access.  Key features: Supports JIT access capabilities, enabling temporary and time-bound access to privileged accounts. Facilitates the monitoring and recording of privileged user sessions. Integrated behavior analytics that generate alerts and access adjustments when abnormal activities are detected.  Best for: Offers self-hosting options that give you greater autonomy over your security environment. Price: Free trial, then pricing depends on your chosen features. For example, CyberArk Adaptive MFA will cost you $3 per user/month.  Review: “The best thing about it is their tools are user-friendly.” 5. SailPoint Source SailPoint is purpose-built for today's enterprise demands as it supports both on-premise and cloud deployment options. Key features: Identity governance capabilities allow you to manage user identities, roles, entitlements, and access controls effectively.  Provides full identity lifecycle management capabilities, covering the entire spectrum from user onboarding to user offboarding. Access resources easily through user-friendly self-service portals. Best for: Backend customization.  Price: By inquiry. Review: “We can have a complete hand on backend code so we can manipulate the Workflow and rules and customize our requirements.” 6. Ping Identity  Source You can easily integrate Ping Identity with other products (PingFederate, PingID, and PingCentral) from the Ping portfolio to build custom IAM solutions for your organization.  Key features: Supports SSO and passwordless sign-on. Supports MFA. Secure user authentication. Adaptive authentication assesses the risk associated with each login attempt. Efficient user life cycle management to connect any user to any asset. Best for: Integration and interoperability with other Ping products.   Price: By inquiry.  Review: “Ping Identity provides 2FA security from unauthorized access to the account even if the password is compromised.” 7. Slauth Source Slauth.io is an AWS IAM policy creation software that simplifies the implementation of least privilege in your AWS environment. It will be available on GCP and Azure in the near future.  Key features: Tracks identity activity via real-time API calls from end-to-end tests to AWS. Generates custom IAM roles to suit your company’s infrastructure requirements within minutes.  Provides complete visibility of your identity activity through logs placed throughout different SDLC stages. Best for: An alternative to AWS console and Access Analyzer.  Price: By inquiry.  Review: “Slauth enables teams to focus on delivery and eliminate security risks by automating IAM policy creation. Less to worry about, more to deliver!” 8. IBM Security Identity Manager  Source IBM Security Identity Manager has built-in governance capabilities through the IBM Security Identity Governance (SIG) adapter. The dashboard is almost entirely customizable to suit you.  Key features: Provides adaptable MFA options and SSO support. Configuration wizard feature helps you with deployment and setup.  Self-service password reset and password synchronization. Advanced analysis and diagnostics for reporting and monitoring capabilities.  Best for: Enforcing complex compliance requirements at scale.  Price: By inquiry.  Review: “It has been an integral part of our infrastructure and that of our clients for many years, providing an extra layer of authentication and authorization for mission-critical software.” 9. Auth0  Source Auth0 is a flexible, drop-in solution to add authentication and authorization to your applications. It helps you avoid unnecessary costs, time, and risks of building your own authentication mechanisms. Key features: Designed with customer UX in mind.  Integrates with popular social identity providers like Google, Facebook, Twitter, and LinkedIn. Offers adaptable MFA options. Best for: Authentication and authorization for mobile applications. Price: Offers four plans: Free, Professional ($240/month), and two Essentials plans ($23/month and $130/month). Review: “Its Multi-Factor Authentication (MFA) and anomaly detection work pretty well.” 10. JumpCloud  Source JumpCloud is a directory platform that provides a variety of identity features like authenticating, authorizing, and managing users, devices, and applications in line with the Zero Trust Model.  Key features: Open directory platform unifies your technology stack across identity, access, and device management. Serves as a centralized cloud-based directory service, the primary point of contact for user IDs, groups, and organizational units. Supports SSO.  Supports passwordless authentication. Best for: Central management of users’ SSO connections.  Price: Offers a free plan and a La Carte plan for $2/user/month. Review: “One of the most valuable aspects is the seamless control over user access and permissions.” Radically Simple and Automated IAM Choosing the right identity and Access Management (IAM) solution is critical to protect your digital assets against evolving cyber threats. Out of the ten solutions, Rezonate stands out because it can connect to every cloud environment and provide a complete picture of cross-cloud identity and access risks.  Rezonate’s Storyline feature profiles identities for total visibility over permissions, access paths, and activity patterns, plus Rezonate’s Adaptive Access engine secures powerful permissions with conditional access and optimized security controls. Get started and book a demo today.

Imagine this: Your company part ways with an unhappy ex-employee who still has access to cloud resources and applications. Although you assume they won't take sensitive data to a competitor, how can you be sure? A shocking 83% of people say they still had access to their previous employer's digital assets, including third-party integrations connected to their environment. This problem is not just about security – it's also about preserving your company's integrity, reputation, and competitive edge. That's why it is essential to clearly understand the identity management lifecycle to safeguard your organization against such breaches. What is Identity Lifecycle Management? Identity Lifecycle Management (ILM) is a comprehensive process that involves the management of your organization's digital identities (individuals, devices, or entities) throughout their entire lifecycle. ILM includes various stages like creation, modification, usage, and eventual de-provisioning or retirement of digital identities. The primary goal of ILM is to ensure that these identities are correctly and securely managed from their initial creation to their termination. ILM helps you maintain security, prevent unauthorized access, and comply with regulatory requirements by ensuring digital identities are always aligned with your organization's needs and policies. What is the Identity Lifecycle Management Process? ILM is crucial for managing your company's access, security, and compliance. This process ensures that the right individuals have the appropriate level of access to resources, enhancing security and efficiency. ILM consists of several key phases: Onboarding: Creating an identity when a new user joins involves provisioning access to relevant resources, setting permissions, and establishing initial configurations. Ongoing Access Modifications: This phase involves modifying access permissions to ensure they align with the user's current responsibilities. Monitoring and Reporting: Consistent monitoring of access activities is crucial for identifying suspicious behavior or unauthorized access.  Offboarding: The process of deactivating a user's access to resources when they leave the organization.  Source Why Do You Need Automated Identity Lifecycle Management? When your organization scales, manual identity management processes can be complicated, error-prone, and time-consuming, which is why automated identity lifecycle management offers a range of benefits: Efficiency: Streamlines the identity management process, reducing administrative overhead and ensuring that identity-related tasks are performed quickly and accurately. Security: Enforces consistent security policies and access controls. It can automatically revoke or adjust user privileges when someone changes roles, leaves the organization, or when security threats are detected. Compliance: Helps organizations demonstrate compliance with regulations like GDPR, HIPAA, and others by providing auditable access controls and data governance. Risk reduction: Manual processes are prone to errors, oversights, and inconsistencies. Automated ILM can reduce the risk of security breaches, data leaks, and compliance violations by ensuring that user identities and access permissions are always up to date. Scalability: Automated ILM solutions can scale with your organization, ensuring that identity management remains efficient and effective even as your business expands. User experience: Enhances the user experience by providing self-service options for identity-related tasks. Users can reset passwords, request access, and manage their profiles more easily, reducing the burden on IT support. Mastering Identity Lifecycle Management: The Essential Guide Although automation provides multiple benefits to the identity management process, you might face some challenges when implementing it. So, let's discuss the tips and best practices for overcoming the challenges associated with digital identity management. 1. Automate Onboarding and Offboarding Effective identity management starts with automated onboarding and offboarding to streamline the provisioning of accounts for new hires and remove access for departing employees. This automation ensures that employees quickly access the necessary resources, which boosts productivity. Also, it simplifies the de-provisioning process when employees leave, enhancing overall security and operational efficiency by protecting your business against disgruntled ex-employees. Actionable tips to follow:  Use rule-based access control to assign access rights based on job roles and responsibilities. Integrate identity management with HR systems to synchronize employee data. Define access templates that outline the specific permissions and resources required for various job roles. Source 2. Contractor and Temporary Employee Management Contractors and temporary employees require distinct identity management strategies to ensure that these individuals have access only to the resources necessary for their specific roles. This process involves creating separate user groups and access policies for these workforce segments, promoting a more tailored and secure approach. Actionable tips to follow:  Define specific access policies for contractors and temporary employees. Implement automated solutions to provision and de-provision access based on contract durations. Review and adjust access privileges periodically to ensure alignment with job responsibilities and contract terms. 3. Access Level Updates As employees change roles or responsibilities, organizations must also modify their access. Automation through role-based access control (RBAC) systems ensures that employees always have the right resources for their current roles while assuming the ‘trust no one, always verify’ approach as per the Zero Trust Maturity Model.  Actionable tips to follow:  Align employee roles with their job descriptions. Use automation to enforce access policies consistently. Periodically review and update role definitions. Create a straightforward process for employees to request role changes.  Periodically certify access levels to verify that employees have only the necessary resources for their roles. 4. Secure Offboarding Secure offboarding is essential for minimizing the risk of disgruntled ex-employees who maintain access to critical systems. It involves immediate revocation of access rights, asset retrieval (such as laptops and access cards), and thorough exit interviews. This comprehensive process ensures departing employees cannot access company systems, therefore safeguarding your organization. Actionable tips to follow:  Disable access rights instantly upon an employee's departure to prevent unauthorized access. Ensure the return of company assets, such as laptops and access cards, during offboarding. Conduct thorough exit interviews to identify potential issues or risks. Maintain an inventory of assets. 5. Attribute and Password Management Managing user attributes and passwords is fundamental to identity management, including enforcing strong password policies, promoting multi-factor authentication (MFA), and automating attribute updates. Ultimately, it will enhance security by reducing the risk of data breaches and ensuring compliance with regulatory requirements. Actionable tips to follow:  Enforce strict password policies, including complexity requirements and regular changes. Use of MFA to enhance security. Utilize identity management tools to automate attribute updates. Provide a password manager tool to help users generate and securely store complex passwords. Source 6. Audit and Reporting Regular audits and reporting are integral to effective identity lifecycle management. Audits involve the periodic review of user accounts, access rights, and system logs to detect anomalies and potential security breaches. Automated reporting generates insights into compliance adherence and potential threats, helping you keep in line with industry regulations and internal policies. Actionable tips to follow:  Conduct periodic audits of user accounts, access rights, and system logs to detect anomalies and potential security breaches. Use identity management tools that generate automated reports and alerts based on predefined criteria. Use reporting to demonstrate compliance with industry regulations and internal policies. 7. Training and Awareness Educating employees on security best practices is essential to increase their awareness of responsibilities. Training programs help understand threats like phishing, the importance of strong password practices, and adherence to security policies. Actionable tips to follow:  Develop awareness programs covering different areas related to your organization's security. Conduct periodic training sessions. Tailor training content to the specific roles of employees. Use real-life examples and scenarios to illustrate security threats. Your Automated Solution to Identity Lifecycle Management Challenges: Rezonate  This article discussed the ins and outs of ILM, but following these best practices might not be enough to survive in the fast-changing world of digital security. New threats are always popping up, and you need a more active and straightforward way of managing identities.  To protect your identities at speed and scale, choose an automated IAM solution like Rezonate. Rezonate simplifies privilege management, giving your IT team total visibility over all your identities and access behaviors immediately. Real-time risk scoring provides valuable insights for your teams to swiftly recognize and address security gaps, helping proactively enforce a least privileged access model and ensure users only have the access they need. Rezonate automatically detects identities that are not active for customizable periods of time. Our solution identifies specific entitlements that are not being used by identities and allows for a smoother and more secure offboarding process.Request a demo today to stay ahead in the digital security landscape.

Most enterprises recognize IAM strategies as an effective way to mitigate security challenges, but turning intention into action is another story. Why do some businesses still allow their employees to use '12345' as a password despite knowing the financial and reputational implications of a data breach? 61% of all breaches involve credentials, and while it's hard to believe, '12345' and 'password1' continue to top the list of most-used passwords. Creating a strong password isn't a silver bullet, but it does represent a critical and often overlooked aspect of IAM and the importance of robust best practices.  In this article, we'll delve into what IAM is, its benefits, and its components, and we'll lay out essential best practices for 2023. What is IAM? IAM (Identity and Access Management) is a cybersecurity practice that controls user identities and access permissions in computer networks. IAM ensures that the right users and devices can access the right resources at the right time by automating identity management and enhancing security through tools like MFA (multi-factor authentication) and SSO (single sign-on). Some other authentication methods are: Multi-factor authentication (MFA): Requires users to provide two or more verification factors, such as codes, biometrics, or passwords, to gain access to a resource. Biometric verification: Uses unique physical characteristics like fingerprints or facial features for identity confirmation. Token-based authentication: Employs physical or digital tokens to generate temporary access codes. IAM in On-premises Vs. Cloud Environments IAM differs in on-premises and cloud environments. In on-premises setups, IAM controls access to internal systems and physical resources. IAM in cloud environments extends to cloud-based applications and services, accommodating remote access and scalability. Why is IAM Important? By ensuring proper user authentication, authorization, and audit, IAM has several advantages for organizations. Enhanced Security and Compliance IAM ensures that access privileges are granted based on policies, guaranteeing proper authentication, authorization, and audit of individuals and services. This helps companies adhere to regulatory standards like GDPR and PCI-DSS, reducing the risk of data breaches and demonstrating compliance during audits. Efficiency and Cost Savings Automating IAM streamlines user access management, decreasing manual effort, time, and expenses. This efficiency allows businesses to operate more smoothly and focus resources on core activities rather than access management. Reduced Data Breach Risk IAM is an effective strategy for data loss prevention caused by both internal and external threats. It adds layers of authentication beyond passwords and enforces policies that limit unauthorized lateral movement, thwarting potential threats. Facilitates Digital Transformation With the evolving landscape of remote work, multi-cloud environments, and IoT devices, IAM centralizes access management for various user types and resources. This enables secure access without compromising user experience, supporting digital transformation efforts. What are the Components of IAM? The IAM framework is essential for maintaining organizational efficiency and securit. Here are some components that it’s made up of. Authentication: This is where users prove their identity to access resources. It involves unique identifiers like usernames, passwords, fingerprints, or even smart cards. Multifactor authentication (MFA) adds extra layers of security, ensuring a robust login process. Authorization: Once a user is authenticated, authorization sets the boundaries. It determines what a user can access based on their role. Think of it as the bouncer at the door, only letting approved users in. Administration: This manages user accounts, permissions, and password policies. Administration is the foundation for authentication and authorization. It ensures accounts are secure, and it's where user roles and groups are handled. Auditing and Reporting (A&R): A&R keeps track of users' actions. It examines and records access logs and activities to detect unauthorized or suspicious actions.  10 IAM Best Practices for 2023 By implementing these best practices and tips, you'll establish a strong foundation for identity and access management, ensuring the security of your systems, data, and users. 1. Implement a Zero-Trust Approach to Security Zero trust is a security model that rejects the notion of implicit trust within networks and requires continuous verification of users and devices. This approach is crucial because it minimizes the risk of unauthorized access, especially in a dynamic threat landscape. To implement Zero Trust, start by segmenting your network, requiring MFA for all access, and enforcing strict access controls based on user roles. You could also implement contextual policies, such as only allowing certain types of access from certain locations or devices, for an extra layer of security. 2. Use Multi-Factor Authentication (MFA) Multi-factor authentication mandates users to provide several forms of identification before accessing systems. It’s a vital step, as passwords alone remain susceptible to vulnerabilities. Implement MFA by integrating it into your authentication process, using options like hardware tokens or biometric data as secondary authentication factors. Time-based one-time passwords (TOTP) can be an effective alternative to SMS-based codes, and strategies like this won’t cause alert fatigue or burden the user excessively.  3. Adopt the Principle of Least Privilege The principle of least privilege is core to a zero-trust approach, as it restricts user access to the minimum permissions necessary for their roles. To apply this principle, regularly review user permissions and adjust them based on job requirements (otherwise known as role-based access control), ensuring that users have access only to what's needed for their tasks. Pair this with automated monitoring solutions that continuously scrutinize access rights and flag anomalies, and fine-grained permissions that let you customize access down to specific tasks or projects.  4. Perform Mandatory Awareness Training  Recent research from Stanford University suggests that up to 88% of data breaches could be caused by human error – ouch. In-person and computer-based security awareness training educates staff on the principles of secure password management, helping them recognize phishing attempts and understand the implications of access control policies. If you run the training regularly and get everyone involved, you can create a security-conscious culture and help break the cycle of compromised credentials.  5. Adhere to Regulatory Compliances Following regulatory compliance checklists like CCPA and GDPR ensures data protection and privacy, which is vital for maintaining a culture of trust amongst your business and customers. You can stay informed about the latest regulations and ensure your IAM policies and processes align with them. Other essential best practices include staying audit-ready with automated compliance reporting (e.g., using an IAM platform) and User Access Review templates. 6. Go Passwordless 8 out of 10 users find password management difficult. Passwordless authentication reduces the risk of credentials-related breaches, and it usually involves integrating biometric authentication or email-based login with unique codes. But should you get rid of them entirely? The choice is yours. You could alternatively implement a strong password policy by setting requirements for complexity, length, and rotation, and you can utilize advanced password management tools to help you do this. 7. Run Penetration Tests  Efficiency, effectiveness, and productivity are the golden trio of a successful IAM strategy, and automated and non-automated penetration tests are indispensable tools for evaluating these three pillars of your IAM framework. Automated pentesting tools rapidly scan for well-known vulnerabilities and provide quick insights into potential security gaps, helping alleviate some workload and support ongoing vulnerability management. Non-automated (or manual) testing enables experts to catch complex, context-sensitive threats, especially after significant system updates or access control changes.  8. Centralize Log Collection Centralized log collection simplifies monitoring and auditing for quick incident response and compliance. Utilize cloud-based or on-premises log storage solutions that aggregate logs from various data sources in real-time. This best practice will also help your compliance efforts too, as you will gain advanced analytics and alerting capabilities on suspicious activities.  9. Choose the Right IAM Security Platform Selecting the right IAM platform is critical for effective security management. You’ll need to choose one that offers end-to-end coverage and visibility across your entire access journey to your business assets. Otherwise, you only get a fraction of the story. Deployment is also a factor – when it comes to access control, you can’t afford any downtime or mistakes, so choosing a solution with fast and flexible deployment and integration options is a good idea. The whole point of an IAM security platform is to offer automated risk monitoring and remediation, or you’ll just create more work for your internal team. With that in mind, make sure the solution does what it says on the tin. 10. Implement Time-based access control Time-based access control is a strategy where user access permissions are restricted based on time constraints. This can help you effectively improve security by ensuring that users can only access resources (systems, applications, and data) when appropriate. Time-based access control helps to reduce risks by reducing the attack surface, increasing operational efficiencies, and, in some cases, is a requirement of compliance standards. Embrace IAM and Secure Access to Sensitive Information IAM's complexity is offset by its security advantages, and the need to stay vigilant against threats can't be overstated. When you have tens or even hundreds of employees and thousands of machine identities accessing a vast variety of systems, applications, and assets multiple times a day, IAM can become overbearing for both the users and the administrators.  With Rezonate’s identity-centric platform, IAM is radically simple. It offers end-to-end coverage and visibility of all access, from the creation time to the last active session and activity performed. Rezonate helps you see the complete picture of your IAM map, understand the context, and prioritize critical risks such as weak password policies, identity logging through SAML or SSO, Identity compliance checks, and overprivileged identities.  With Rezonate you can easily adhere to IAM security best practices and track your identity maturity program continuously in real time. Get a free demo of Rezonate today.

In the brick-and-mortar world, our physical presence assumes our identity. But the virtual world disrupts this age-old presumption. From pseudonyms to shadow identities and avatars to digital twins, we have many ways to represent our identity online.  However, 80% of cyberattacks today leverage identity-based attacks, and the cloud-based landscape only makes verification more difficult and hackers more excited. That’s why ITDR has emerged as an indispensable approach to counter cybersecurity threats. In this article, we will understand the concept of ITDR and delve into the security challenges addressed by it. We will also reveal seven key features and capabilities every ITDR platform should have. What is ITDR? Identity Threat Detection and Response (ITDR) is one of the approaches to cybersecurity risk mitigation. Before understanding the goal of ITDR, it's essential to recognize the difference between these key terms: Credentials prove who you are. Privileges define what you can do. Access is the ability or permission to interact with resources. Identity providers validate and assert your identity. Cloud resources are the digital assets you might want to access in a cloud environment. ITDR establishes processes to prevent, monitor, detect, and mitigate identity threats related to user and machine identities with access to the cloud infrastructure, IAM infrastructure (such as identity providers like Azure AD and Okta), and third-party SaaS applications. The rise of cloud computing, remote working, digital transformation, and decentralized identities have made credentials and user or system identities a prime target for cybercriminals. Therefore, the process of verifying an identity (authentication), determining what that identity can do (authorization), and the actual identity data itself are all potential attack vectors. For this reason, ITDR is focused on detecting and responding to malicious activities and threats associated with the access journey: authentication, authorization, and the management of actual identities. It uses capabilities like real-time monitoring, analytics, and AI-driven pattern analysis to pinpoint anomalies or suspicious activities and alert security teams to trigger fast incident response.  Source How is ITDR Different From EDR and XDR? ITDR, EDR (Endpoint Detection and Response), and XDR (Extended Detection and Response) are all security frameworks or solutions designed to detect and respond to threats. However, their goals and scopes of protection differ. Here's a breakdown of their differences: ITDR Focuses on the security of identities and their associated access.  The access journey (including authentication, authorization, and actual identity management) forms the basis of ITDR's threat detection. Ensures only legitimate users can access resources and quickly detects and responds when identities are misused or compromised. EDR Focuses on endpoints, including desktops, mobile devices, and other connected hardware.  Continuously monitors, detects, investigates, and remediates threats on endpoint devices. Provides tools for analysis and incident response.  XDR Takes a more comprehensive approach by looking beyond just endpoints. Combines data from endpoints, networks, servers, cloud resources, emails, and other environments. Provides a comprehensive view of your threat detection program.  Detects more sophisticated attacks by correlating data from various sources and extending the security perimeter.  Challenges of EDR and XDR Both EDR and XDR are based on the principle of securing tangible assets of your organization's network, such as workstations, servers, routers, and gateways. However, routine maintenance, upgrades, and network expansions make maintaining a consistent security posture and threat detection program challenging. Moreover, technological advancements add newer endpoints to the network, expanding the attack surface.  Why ITDR Provides a Solution The ITDR approach to cybersecurity is unique in response to the changing threat detection landscape. It focuses on identity, which is not a tangible asset of the network – it is an intangible concept.  There’s been a huge increase in sophisticated identity-based attacks, such as privilege escalation, lateral movement techniques, or data exfiltration by malicious insiders and external threat actors that compromise the super admins who manage the IAM infrastructure. Given this surge, ITDR ensures that identity-related threats are rapidly detected and neutralized, safeguarding your critical assets and data. Unlike EDR and XDR, ITDR is the only solution that provides comprehensive and real-time visibility over identities and their behavior across clouds, SaaS, and IdPs from end to end. ITDR enables you to be proactive and narrow down your window of exposure by finding human and machine root causes for your risky and compromised identities before attackers take advantage of them.  What Security Challenges Does ITDR Address? Hackers are two things: intelligent and, well, pretty greedy. They’ll try to compromise identities in as many ways as possible, meaning ITDR platforms must monitor: Keys (e.g., cryptographic keys, tokens, or API keys) to protect services or data.  Credentials (e.g., username-password combinations) to thwart unauthorized access attempts. Programmatic attacks that use automation to compromise identities on a large scale.  Console attacks directed at management interfaces that give hackers high-level administrative privileges.  Admins and super admins who have the keys to the kingdom – once they’re compromised, hackers have everything they need.  The full scope of ITDR also covers the following areas: User Activity ITDR detects and responds to suspicious access attempts to critical systems by monitoring user activity. Sometimes, insiders and external threat actors carry out these unauthorized access attempts. Therefore, observing their behavior and alerting security teams about repeated suspicious behavior is also under the purview of ITDR. Identity Credentials Credentials are the secret information used to identify a user or a device, such as passwords and private keys. ITDR gathers intelligence related to using credentials to detect possible credential theft attempts. Source Access Permissions ITDR also detects and responds to privilege escalation attempts by monitoring identity permissions. This process also ties back to compliance requirements for granting the least possible privileges for identity and access management. 7 Features to Look Out for in an ITDR Platform An ITDR platform acts as an umbrella security cover over EDR and XDR. It performs real-time identity centric threat analysis, actively profiling and monitoring the identities and monitoring their usage, enabling continuous visibility of potential threat situations. ITDR supports a risk-based alerting mechanism and auto-remediation to manage all the stages of a threat lifecycle.  To augment the capabilities of an ITDR platform, here are the seven must-have features that can elevate its effectiveness to become an integral part of any organization's arsenal to counter cybersecurity attacks. 1. Compatibility with Multiple Clouds, SaaS, and IdPs An ITDR platform connects to cloud services, SaaS applications, and IAM infrastructure (like IdPs) to collect data on identities and access privileges. It analyzes authentication and authorization events to produce actionable insights on identity-related threats.  Therefore, it is vital to ensure that the ITDR platform you choose is compatible with native IAM services provided by Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), or other cloud providers. It should also integrate with the specific identity management solutions used by the organization, such as Okta or Azure Active Directory. 2. Room for Scalability and Elasticity Cloud environments are known for their scalability and elasticity. The ITDR platform must be equally capable of scaling with the cloud infrastructure to handle increasing workloads and user accounts without performance degradation. One important aspect of scalability is multi-cloud and hybrid-cloud deployment. If your organization uses multiple cloud providers or a hybrid cloud approach, an ITDR platform must also be able to monitor identities across different cloud providers. 3. Source of Identity Monitoring Typically, an ITDR platform relies on several sources to monitor and analyze identity-related activities. These sources primarily include logs and event data generated by various IT systems, including network devices, application servers, and authentication systems. To make the platform more effective, it must support additional sources that are indirectly accessed or fetched externally. ITDR platforms need to integrate with threat intelligence sources that have lists of leaked credentials and users, as well as third-party vendors that provide enrichment capabilities to the ITDR engine.  The dark web is yet another external source of data. ITDR platforms can leverage this data to monitor for stolen credentials to perceive early warnings of potential risks. 4. Integration with External Threat Intelligence Services and Vulnerability Feeds ITDR platforms rely on third-party vulnerability feeds from credible sources for comprehensive coverage of the threat landscape. Advanced ITDR platforms also offer features associating identity risk factors with the MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework for advanced protection. 5. Cloud Native Security Support Modern cloud applications have foregone the traditional monolithic, long-running process architecture, favoring cloud-native deployment to achieve super scalability. This approach relies on short-lived, ephemeral processes for performing specific tasks, such as handling API requests or accessing a particular database table. Tracing identities within a cloud-native environment requires additional integrations. As an advanced feature, ITDR platforms can support cloud-native deployments, such as the ability to monitor identities associated with API calls, serverless function execution, and container orchestration tasks. 6. AI (Artificial Intelligence) and ML (Machine Learning) Capabilities AI and ML significantly enhance an ITDR platform's capabilities. They provide more advanced and proactive methods for identifying and mitigating identity-related security threats. Some key areas where these technologies play a pivotal role include behavior baselining, user and entity profiling, threat profiling, and alert categorization. Overall, AI and ML can help ITDR platforms learn and adapt over time based on feedback and new data, improving their accuracy in identifying threats. 7. Data Privacy and Compliance Of course, the ITDR platform you choose must be verified for adherence to data privacy regulations and industry compliance standards applicable to your organization, such as GDPR, HIPAA, or PCI DSS. Further, the platform must support reporting and auditing capabilities to demonstrate compliance. Synergizing IAM and ITDR: A Resilient Future for Cybersecurity ITDR is a relatively new method of countering cybersecurity risks. It takes a radically different approach by safeguarding the identities, which are the virtual assets of a cloud environment. Since IAM is responsible for generating and provisioning these identities, it is all the more logical to combine it with ITDR. Rezonate offers the perfect synergy between ITDR and IAM to help security engineers and DevOps teams maintain the perfect sanity of their IAM configuration. With a few minutes of setup and an intuitive dashboard, Rezonate can connect to the most popular cloud providers and capture identity weak spots quickly. See Rezonate in action today.

So, it looks like your organization was hacked, you are almost sure, but it’s still under investigation. What should you do to avoid immediate damage ? Cybersecurity breaches revolving around compromised identity security have become increasingly common, making it essential for organizations to have a robust incident response plan. When faced with a suspected or confirmed identity breach, here's a step-by-step guide to managing the situation effectively. Identity Security: Speed, Strategy, and Controlled Actions  Responding promptly and strategically to an identity security breach can tilt the balance in your favor against hackers. Awareness is crucial: understanding the breach timeline, piecing together the incident's narrative, and recognizing potential damages. As you build your incident response (IR) plan, incorporate critical components such as reporting cadences (to regulators, CISOs, management, and customers), in-depth investigation, documentation, action steps, and retrospective evaluations to glean lessons learned. This proactive approach ensures a comprehensive and resilient defense. So what should I do now when I suspect an identity is compromised or was highly exposed - the rezonators share the 14 steps you should take, based on 100s of incidents we have solved over the years:  14 Best Practices for Identity and Access IR and Blast Radius Analysis  Blast Radius Analysis: Understand the Power of the Identity at Risk 1. Access Journey Mapping - own the identity security storyline: Hackers will laterally move across Identities and try to fully leverage their credentials to gain persistence and velocity in their attack execution. Ascertain how this identity is utilized from authentication methods, identity assumption patterns, privilege utilization, authorization paths, and privilege-chaining capabilities. Understanding the possible exploit paths offers insights into a hacker's potential reach. 2. Stakeholder Identification: Pinpoint all entities, both direct and indirect, associated with this identity. Recognizing the people or processes that depend on it helps orchestrate an effective response and risk analysis.  Reduce the Attack Surface 3. Blast Radius Analysis: Examine the depth and breadth of privileged access management. What data, applications, processes, infrastructure, or business assets can it touch? Specifically, assess its capabilities across reading, writing, changing, or deleting data. Scrutinize direct, indirect, hidden, or toxic access privileges associated with this identity. 4. Risky Privileges Assessment: Identify high/substantial privileges that the identity possesses but rarely uses. These can be potential vulnerabilities that you can easily taken out of the game, simply remove them. 5.  Behavior Analysis: Delve into the regular and rare activities associated with this identity. What are the implications, both from infrastructure and business perspectives, if this identity is rendered inactive? 6. Misconfiguration Audit:  Utilize tools to uncover and rectify vulnerabilities linked to the identity, such as weak passwords, lack of session controls, outdated keys, weak authentication methods, or risky practices. 7. Hackers will laterally move across Identities:   Excise unutilized, risky, or exclusive privileges. 8. Strengthen Security Controls:  For privileges that are essential but potentially risky, implement additional security measures, such as geographic or device-specific restrictions. 9. Authentication Reinforcement:  Reset and fortify authentication processes, possibly by incorporating multi-factor authentication, enhancing password security, limiting session durations, or narrowing down granular actions. Damage Assessment and Containment 10. Asset Protection: Based on the assessed blast radius, prioritize assets. Temporarily restricting access to certain assets might be less damaging than allowing a hacker to manipulate them. 11. Attack Story Compilation:  Differentiate between legitimate and malicious activities by creating a narrative of the identity's actions. The differentiation process requires a comprehensive understanding of the identity's typical behavior. Techniques such as threat modeling or statistical reputation analysis can assist here. 12. New Assets Examination:  Detect any newly generated assets, like databases, storage units, or machines, and neutralize them to prevent attacker persistence or data exfiltration. 13. Cryptographic Scrutiny:  Identify cryptographic elements generated by the identity, which could either be used to lock you out or exfiltrate data. Ensure you have control over these elements. 14. Continuous Monitoring:  After implementing containment measures, keep an eye out for any attempts to re-assume the identity or detect recurring patterns that might indicate the attacker's active presence.By meticulously following these steps, organizations can significantly mitigate the risk of extensive damage following the compromise of a critical identity. While preventive measures are crucial, an effective response strategy is equally imperative in today's volatile cyber landscape. Learn more about securing identities across the entire access journey to your business assets with Rezonate.

If your organization hasn't already adopted the Cloud, you'll be met with one question: "Why?" The shift towards Cloud computing brings unprecedented advantages, yet it heightens exposure to cyber threats. As organizations increasingly rely on technology, unforeseen vulnerabilities often lurk in the shadows, catching security teams off guard until disaster unfolds.  The evolution towards hybrid work models and the rising dominance of AI further complicate the landscape. 60% of mid-sized businesses that asked their employees to work remotely swiftly experienced a cyberattack. Given this dynamic scenario, a revamped strategy for countering cyber threats in Cloud environments becomes imperative. In this article, we’ll break down two important Cloud cybersecurity approaches: CIEM and ITDR. While they address distinct aspects of cybersecurity for a Cloud environment, we will learn how they can be combined for a holistic action plan for managing security risks. What is CIEM and How Does it Work? Cloud Infrastructure Entitlement Management (CIEM) is primarily responsible for governing Cloud infrastructure privileges and entitlements. It manages access pathways to secure Cloud services and applications by enforcing certain principles that prevent excessive privileges and providing visibility and analytics about them. As a result, CIEM is responsible for streamlining access control, enforcing access policies, and ensuring compliance related to privileges across the entire Cloud environment. How Does CIEM work? To understand CIEM better, let’s break it down. Firstly, we know that a Cloud infrastructure represents the cluster of components such as servers, databases, networking hardware, and platform services representing the underlying workload for hosting an application.  "Privileges" refers to the permissions required to access the components and data within the workloads, which are assigned to human users, connected devices, and AI bots via IAM, an essential part of any Cloud service for managing user access rules and permissions. CIEM works in conjunction with IAM best practices. It acts as an overarching layer that audits the IAM configurations. It scans the IAM entitlement configurations to determine what permissions are allocated to humans or machines. It performs remediations, if necessary, to ensure every device or person has the right permissions. Why Do You Need CIEM? In today’s increasingly Cloud-centric and remote work-focused IT landscape, CIEM is crucial to administering an organization's cybersecurity posture. CIEM solves four major problems. 1. Manual IAM Provisioning Native IAM services supported by Cloud providers (like Azure Identity Protection) offer a manual interface that lacks intelligence about the security impact of each privilege configuration. Therefore, you're missing out on the opportunity to use automation to act on possible blind spots. CIEM fills this gap with intelligence capabilities to automate and remediate over-privileges. 2. Misconfigured Privileges In a complex hybrid or multi-Cloud environment, IAM provisioning leads to human privilege errors, which are difficult to visualize and understand. CIEM provides continuous visibility into all Cloud entitlements and enforces the principle of least privilege by identifying and mitigating entitlements with excessive permissions. 3. Unchecked Identity Lifecycle How can you preempt identities in specific conditions, such as unused or dormant identities? CIEM is capable of addressing these issues through proactive identity lifecycle monitoring. It ensures that privileges are activated at the right time for the right set of identities and are quickly revoked when identities are dormant, reducing security risks. 4. Lack of Compliance Any lapses in the above aspects of privilege management can lead to noncompliance with regulatory requirements, which creates headaches in the form of penalties or bad press. CIEM solutions help organizations meet regulatory compliance requirements by continuously monitoring and reporting access control across Cloud and multi-Cloud environments. What is ITDR and How Does it Work? Identity Threat Detection and Response (ITDR) tackles cybersecurity risks by safeguarding Cloud identities for accessing a Cloud infrastructure instead of infrastructure components such as servers, networking equipment, and devices. A Cloud identity can include information like credentials and secrets and determines whether the identity can access specific resources in the Cloud environment. However, if the identity data is compromised and credentials are stolen, access gets transferred to a rogue user. ITDR helps prevent malicious use of identities like this. ITDR maintains a vigil on each identity's dynamic activities in the Cloud environment, including login and logout events, command execution logs on servers, and network traffic on workstations where the identity has access rights. Based on these activities, ITDR can predict possible suspicious activities arising out of any identity provisioned in the IAM. Why Do You Need ITDR? ITDR also adds an intelligent layer atop IAM and is essential in preserving your organization's security posture. The significant problems addressed by ITDR include: Static Identity Monitoring IAM is responsible for provisioning the identities and can't monitor how they are used in the Cloud environment. ITDR is capable of real-time monitoring of identities to ensure that all identities are used within the parameters behavior expected by the users of those identities. Lack of Visibility in Entitlement Usage IAM doesn't guard the Cloud infrastructure from unruly users who want to abuse their entitlements. This rogue activity can happen knowingly or unknowingly, either by disgruntled employees or through identity theft. Based on its real-time monitoring capabilities, ITDR can flag an identity if it detects suspicious use. Compliance gaps ITDR looks beyond IAM’s identity and permissions configuration to investigate system logs, network traffic, and other data sources to monitor identities. Therefore, ITDR can provide deeper and more comprehensive observations on potential identity-related threats compared to IAM and CIEM. How You Can Use CIEM and ITDR Together CIEM and ITDR solutions provide different but complementary security capabilities over IAM. Here are a few ways to leverage these two approaches to strengthen your organization’s security posture and outsmart cybercriminals. 1. Better Visibility on Identity Lifecycle You can leverage the capabilities of CIEM and ITDR for better visibility into the identity lifecycle. For example, CIEM can track quantitive aspects of an identity usage, whereas ITDR can deliver qualitative insights about the context in which the identity was used.  Further, ITDR’s analysis of identity risks can establish links with cloud and IAM infrastructure where login and activity records of that identity are discovered. Therefore, by combining with CIEM, it is possible to visualize and trace the privileges, from identities all the way to cloud resources, SaaS applications, and IdPs. 2. Adaptive Security Posture The combined strength of CIEM and ITDR is a potent weapon to dynamically equip you with the tools to respond to specific threat perceptions.  One example is adaptive authentication. CIEM guards the authentication procedure while ITDR accesses the authentication and access related data to enforce additional policies that activate different authentication factors depending on the risks perceived by ITDR.   3. Enhanced Threat Detection By combining CIEM and ITDR solutions, you can enhance your threat detection and response capabilities. CIEM can help identify excessive or unused permissions that cybercriminals can exploit. At the same time, ITDR can quickly determine any matches between the credentials used in the malicious activity and those of authorized users.  This level of scrutiny helps uncover the attack’s root cause. It provides an opportunity to bolster security measures to prevent similar incidents from occurring in the future and to reduce the blast radius of an attack. 4. Better Control of Shadow IT Practices Shadow IT refers to using information technology systems, devices, software, applications, and services without explicit approval from your organization's IT department. The trend of working from home has contributed to the rise of shadow IT due to the increased use of personal devices and applications. Such practices also raise concerns about security due to data inconsistency, lack of IT visibility, and compliance violations. CIEM and ITDR can solve all the above problems associated with shadow IT practices by detecting shadow access and tracing the identities and entitlements associated with them. 5. Intelligent Policy Enforcement IAM and CIEM often define access control policies to add additional authorization criteria to entitlements. One example is time-based access, where an entitlement is granted for a limited time. While CIEM can enforce policies like this, ITDR can bolster them to ensure the policies are in force and any unauthorized access attempts trigger alerts and responses. 6. More Efficient Workflows Organizations can leverage CIEM and ITDR platforms to share contextual information between the two systems for better synergy in security-related workflows. It includes user identity attributes, access permissions, and historical data. This enriched data enhances the response time to security incidents. For example, security incidents can be logged with identity-related information for better first-hand context of the affected identities and enforcing access controls as part of the incident response workflow. You can achieve similar improvements in security audit workflows. 7. Centralized Management & Monitoring of IAM Combining CIEM and ITDR solutions provides centralized management of Cloud identities. CIEM takes care of centralized provisioning of all identities and their associated permissions and supersedes the IAM configuration to ensure minimum privileges. ITDR handles centralized monitoring of all identities and enables deep insights into identity usage and potential threats. CIEM and ITDR: The Path to Identity Resilience in the Cloud CIEM is a strategic initiative – it manages identity security and monitors overall identity hygiene metrics. ITDR is a tactical initiative – it detects identity gaps in real time and predicts ongoing risks arising from identity usage.  Both approaches are relatively new in the context of cybersecurity, which was traditionally dominated by EDR and XDR-based approaches. However, CIEM and ITDR offer a more resilient way to secure Cloud infrastructure since identity theft is the most potent way to commit cyber crimes stealthily without getting noticed.   Rezonate is an identity centric security platform that provides CIEM capabilities across the entire identity fabric (everywhere identities are operating and managed), in the IAM infrastructure (like Okta and Azure AD), and business-critical SaaS applications. Also, Rezonate’s ITDR engine uses anomaly detection and AI-driven pattern analysis to profile the level of access, drive least privileges across the board, and detect and respond to threats. To find out more, you can book a demo.

Azure Active Directory (Entra ID) stands as one of the most popular and widely-used cloud-based identity and access management services provided by Microsoft. It serves as a comprehensive solution for managing user identities and controlling access to a diverse range of resources, both within the Microsoft Azure ecosystem and across other platforms. Azure AD offers crucial features like single sign-on (SSO), multi-factor authentication (MFA), role-based access control (RBAC), and directory services.  Understanding  Azure AD logs is essential for maintaining a robust security posture in a cloud-centric environment. These logs provide a comprehensive record of user activities, authentication attempts, and access permissions. By analyzing Azure AD logs, organizations can detect and respond to suspicious or unauthorized activities promptly, identify security threats, track user behavior, and ensure compliance with regulatory requirements. Understanding these logs is pivotal in proactively mitigating security risks, protecting sensitive data, and safeguarding the integrity of Azure-based services, making it a fundamental aspect of any effective cybersecurity strategy in the cloud. Reading this blog will provide you with: Understanding of the logs that can be extracted from your Azure AD, and how. Knowledge about how to analyze these logs, and get the right information out of them. Learning about more than 10 Threat scenarios and corresponding hunting queries that you can run in your own environment to identify threats. Access to a tool Rezonate wrote to extract logs from AzureAD to any preferred analysis platform of your choice. Azure Active Directory Log Sources Azure Active Directory (Azure AD) offers two log sources that capture different types of events and activities within the Azure AD environment. These logs provide valuable insights for monitoring, security, and compliance purposes: Sign-in Logs: capture information about user sign-ins, including successful and failed attempts, sign-in locations, device details, and authentication methods used. Directory Audit Logs: capture information about various administrative activities, such as changes to user accounts, group memberships, application access, role assignments, and permission modifications. Data retention settings for the different licensing levels can be found here. Azure AD Sign-in Logs Azure AD sign-in logs are records that capture information about user sign-in activities within the Azure Active Directory (Azure AD) environment. These logs provide insights into the authentication and access activities of users as they interact with Azure AD-integrated applications and services. Sign-in logs are a crucial component of monitoring and maintaining the security of an organization's identity and access management infrastructure. The full structure of the sign-in logs can be found on Microsoft’s official reference page. Every data-point  in the log record could be useful in certain use cases, but we highlighted some of them  that you should focus on for most investigations and hunting scenarios: IdUnique identifier for the event.CreatedDateTimeEvent time.ActivityDisplayNameThe name of the activity, used as the type of the event. The full list can be found in Microsoft’s documentation.AppId The identifier of the Azure AD application that the entity logged in to.AppDisplayNameThe name of the Azure AD application that the entity logged in toUserPrincipalNameThe user name that was used to sign in.DeviceDetailThe device information from where the sign-in occurred. This property includes the client’s operating system and browser details.IpAddressThe IP address that was used for the authentication. UserAgentThe user agent that was used for the authentication.StatusIndicates the result of the sign-in. The full list of errors can be found in Microsoft’s documentation.IsInteractiveIndicates if the sign-in was interactive or not.CorrelationIdA unique identifier that is used to correlate other logs that are related to a specific sign-in event.  Sign-in logs are separated into four groups: Interactive sign-in: Interactive sign-ins occur when a user logs in using a web browser, a mobile app, or another client application, and the user directly interacts with the authentication prompts.  Non-interactive sign-ins: These logs typically involve automated processes, such as service accounts, background tasks, or system-to-system interactions, where user intervention is not necessary for authentication to occur. Service principal sign-ins:  A service principal is a security identity used by applications, services, or automation tasks to access Azure resources and perform specific actions. Service principal sign-ins occur when these identities are used to authenticate and access resources or services. Managed identity sign-ins: A managed identity is a feature in Azure that provides an identity for resources like virtual machines, Azure services, and applications. This identity can be used to authenticate with various Azure services without requiring explicit credential management. Managed identity sign-ins occur when resources or applications use their managed identity to authenticate and access other Azure services, APIs, or resources. Azure AD Directory Audit Logs Azure AD directory audit logs are records that capture details about administrative activities and changes within an Azure Active Directory (Azure AD) environment. These logs provide insights into actions taken by administrators or privileged users that impact user identities, groups, roles, and directory settings. Directory audit logs are essential for maintaining security, compliance, and accountability within an organization's identity and access management infrastructure. These logs help track changes, monitor user activities, and investigate potential security incidents. The structure of the audit logs can be found on Microsoft’s official reference page. Each data point in this log could be useful but we highlighted some of them that you should focus on for most investigations and hunting scenarios: IdUnique identifier for the event.ActivityDateTimeEvent time.ActivityDisplayNameThe name of the activity is used as the type of the event. The full list can be found in Microsoft’s documentation.InitiatedBy Provides information about the entity that performed the action that triggered the event.TargetResourcesThe resources that were involved in the event.ResultIndicates the result of the eventResultReasonLogs the reason for a failure if the event was not successful.CorrelationIdA unique identifier that is used to correlate the event to a specific sign-in event.  Exporting Azure AD Logs Exporting  Azure AD  logs requires one of the following roles: Reports Reader Security Reader Security Administrator Global Reader Global Administrator There are two primary approaches to accessing Azure AD logs. 1. Azure AD Console: In the monitoring section, you will find both “Sign-in Logs” and “Audit logs”. Login to Azure Portal From the Azure Services, select Azure Active Directory From the left pane, navigate to the “Monitoring” section Each sign-in event, of an interactive user, is displayed as a single event and can be expanded to view more detailed information: The tree remaining sign-in log groups are displayed differently. Instead of showing each sign-in attempt in a single event, the sign-in events are grouped by the target application that the user signed into: 2. Exporting The Logs To CSV\JSON While accessing the Azure AD logs from the Azure portal is easy, it is recommended to export the logs out of  Azure AD  so you will be able to cross reference Azure AD activity with other data sources and perform advanced queries and analyze it in scale. To export logs from Azure AD, we recommend using an Azure AD application and Microsoft Graph API. Follow the instructions below to create a new application for logs export in your tenant: Sign in to the Azure portal using your administrator account. From the Azure services, choose Azure Active Directory. From the left pane, choose App Registrations Click on “New Registration”. Name it as you wish. In “Supported account types” select  “Accounts in this organizational directory only (Default Directory only - Single tenant)”. Click Register. In the newly created application page, from the left pane, choose API Permissions. Click on Add permission. Click on Microsoft Graph - Application Permissions. Type “AuditLog” in the search box. Click on “AuditLog.Read.All”, and then “Add permissions”. Grant admin consent for the default directory - In other words, allow the application to use the assigned privileges. From the left pane, choose “Certificates and Secrets” Click on “New client secret” Choose your desired expiration date. Use the new secret to authenticate to Azure AD and query your logs. Let the Hunt Begin In this section, we will guide you through some of the top-relevant threat scenarios to look out for, explain them, mark the Relevant Azure AD Event Sources, align to the specific MITRE ATT&CK technique, and include our own queries in Postgres query syntax. Scenario 1 - Brute Force on an Azure AD User A brute force attack on an Azure AD user involves an attacker repeatedly trying different passwords to guess correctly and eventually gaining unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than X failed login attempts on at least Y target user, failing or ending up with a successful login. In cases of failure, the activity may result in a user's lockage. (Read more about Microsoft’s Smart Lockout protection mechanism) Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Get users who failed to login from the same IP address at least 5 times SELECT "userPrincipalName", "ipAddress" , "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" = 50126 -- Error code for invalid credentials AND "createdDateTime" > now() - interval 'X hours' GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent" having count(id) >= 5 ORDER BY "eventCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Attention: The user-agent field in authentication logs indicates the client application employed for the authentication process. To bypass modern authentication requirements like Multi-Factor Authentication (MFA), threat actors might exploit legacy authentication protocols such as SMTP. In cases where a legacy protocol is utilized for authentication, the user agent in the logs will be identified as 'BAV2ROPC'. In case you encounter a brute force attempt with the user agent set to 'BAV2ROPC', it is crucial to consider it as malicious unless proven otherwise. Scenario 2 - Password Spray on an Azure AD Account A password spray attack on an Azure AD account involves an attacker repeatedly submitting different usernames with the same password (a small set of passwords) to eventually manage to log in and gain unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than 1 failed login attempt on at least Y unique target user, from the same IP address. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Get users who failed to login from the same IP address to at least 5 unique users SELECT "ipAddress", "appDisplayName", "userAgent", count(distinct "userPrincipalName") as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" = 50126 -- Error code for invalid credentials AND "createdDateTime" > now() - interval '1000 hours' GROUP BY "ipAddress", "appDisplayName", "userAgent" having count(id) >= 5 ORDER BY "eventCount" desc -- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" time MITRE Technique Credential Access | Brute Force | ATT&CK T1110 Scenario 3 - Multiple User Lockouts In certain instances of brute force attacks, the malicious actor may lock out the targeted users during their unauthorized access attempts. To identify such scenarios, we can employ a detection method that involves searching for multiple user lockouts originating from a single IP address. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for login attempts to disabled users SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 50053 -- Error code for user locked out AND "createdDateTime" > now() - interval 'X hours' GROUP BY "ipAddress", "appDisplayName", "userAgent" having count(distinct "userPrincipalName") >= 5 ORDER BY "userCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 4 - Multiple Authentication Failures During MFA Challenge An attacker that managed to compromise a credential set of an AzureAD user that is protected by MFA, upon authentication, will generate a specific sign-in log with the error code 500121 which correlates with the following message: “The user didn't complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or have an issue with their authentication setup.” We can highlight suspicious IP addresses that generated multiple events with the mentioned error code.  Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for failed authentication attempts during MFA challenges SELECT "userPrincipalName", "ipAddress", "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" in 500121 -- Error code for no MFA response AND "createdDateTime" > now() - interval '2000 hours' GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent" having count(id) > 1 ORDER BY "eventCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 5 - Authentication Attempt to a Disabled User  In some cases, Azure AD user accounts might have been disabled due to security concerns, or maybe even as part of employee off-boarding. Monitoring login attempts to disabled users can help you detect unauthorized activities. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for login attempts to disabled users SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 50057 -- Error code for user disabled --AND "createdDateTime" > now() - interval 'X hours' - optional filter GROUP BY "ipAddress", "appDisplayName", "userAgent" ORDER BY "userCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 6 - Suspicious User Consent to Application When an attacker gains access to an Azure AD Tenant, they can create a new multi-tenant application equipped with specific API permissions such as Mail.Read, Mail.Send, Mailboxsettings.ReadWrite, Files.ReadWrite.All and User.ReadBasic.All, of which do not require administrative consent. Next, the attacker invites external users (potential victims) to use this application. Upon the first login by a new user to the attacker's application, a "Consent" prompt appears. If the user grants consent to the application, it enables the application to perform actions on behalf of the user, potentially leading to unauthorized access and misuse of the user's data and resources. We can utilize non-administrative consents to detect privileged applications that have access to user data. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search for non-administrative application consent select id,dn,"newValue" from (select id, jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' as "dn", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newValue" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName"='Consent to application') as subsearch where dn='ConsentContext.IsAdminConsent' and "newValue"='"False"' MITRE Technique Initial Access | User Consent | ATT&CK T1204  Scenario 7 - Persistence Via Service Principal Credentials An attacker could establish a persistence mechanism by adding new credentials to an already existing Azure AD application if one of the following applies to them: Application Administrator  Global Administrator (GA)  microsoft.directory/applications/credentials/update Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search new application credentials events SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", count("oldVals") AS "oldValsCount", count("newVals") AS "newValsCount" FROM ( SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", jsonb_array_elements("oldVal"::jsonb) AS "oldVals",jsonb_array_elements("newVal"::jsonb) AS "newVals" FROM ( SELECT "id", "initiatedBy"->'user'->>'ipAddress' AS "ip", "initiatedBy"->'user'->>'userPrincipalName' AS "user", "activityDateTime", "activityDisplayName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' AS "property", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' AS "oldVal", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' AS "newVal" FROM directory_audit_activity_azure_ad_entity WHERE "activityDisplayName" = 'Update application – Certificates AND secrets management ' ) AS subquery WHERE "oldVal"!='[]' and "oldVal" is not null) AS query GROUP BY "id","user","ip", "activityDateTime", "activityDisplayName", "property" HAVING count("newVals")> count("oldVals") MITRE Technique Persistence | Additional Credentials | ATT&CK T1098 Scenario 8 - Admin Privileges Assignments Not Via PIM Azure AD PIM (Azure Active Directory Privileged Identity Management) is a Microsoft Azure service that helps organizations manage, control, and monitor access to privileged roles and resources in their Azure environment. It allows administrators to grant just-in-time privileged access, enforce approval workflows, and provide auditing and reporting for enhanced security and compliance.It is important to monitor Azure AD admin privileges assignments, not through PIM, since this behavior should not be common, and might suggest that an admin account is compromised. Relevant Azure AD Event Source  Azure AD Directory Audit Logs Query -- Search AAD administrative privileges assignment not via PIM select "ipAddress", "initiatedUser",category,"operationType", "targetResourceType", coalesce("targetUser","targetApp") as "targetDisplayName", ass3."value" as "newRoleName" from (select "id","ipAddress","userPrincipalName" as "initiatedUser",category,"operationType","TR"->'type' as "targetResourceType", nullif("TR"->'userPrincipalName', 'null') as "targetUser", nullif("TR"->'displayName', 'null') as "targetApp" from directory_audit_activity_azure_ad_entity daaaae , jsonb_array_elements("targetResources") as "TR" where category='RoleManagement' and "operationType" ='Assign' and "targetResources"::text like '%dmin%' and ("initiatedBy"->'app'->>'displayName' != 'MS-PIM' or "initiatedBy"->'user' is not null)) bq, (select * from (select "id",jsonb_array_elements("sub")->>'newValue' as "value", jsonb_array_elements("sub")->>'displayName' as "valueName" from (select "id",jsonb_array_elements("targetResources")->'modifiedProperties' as "sub" from directory_audit_activity_azure_ad_entity where category='RoleManagement' and "operationType" ='Assign') base1) base2 where "valueName" = 'Role.DisplayName') as base3 where bq."id" = ass3."id" and "targetResourceType"!='"Role"' MITRE Technique Privilege Escalation | Privilege Assignment via Valid Account | ATT&CK T1078 Scenario 9 - Account Hijacking Social engineering for initial access is on the rise. These techniques are simple in most cases and do not require much technical knowledge. Attacks such as phishing, MFA relay, or even buying credentials online may help attackers compromise user accounts.Usually, when an adversary compromises a user, gaining persistent access to that account is important. To do so, the adversary might change the user’s password and enroll a new MFA device. In some cases maybe even delete the original user’s factors.The following query identifies user accounts that performed a series of actions from an IP address that is not being used often by the organization, and during a short period of time - which might suggest that these accounts are compromised. The actions that this query searches for are: Self-password reset MFA enrollment MFA deletion  Relevant Azure AD Event Source  Azure AD Directory Audit Logs Azure AD Sign-In Logs Query -- Search multiple security information changes from a rare location in a short timeframe select * from(with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion" FROM ( SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount", "ipAddress","countryOrRegion" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 0 AND "createdDateTime" > now() -interval '1 week' GROUP BY TimeBucket, "ipAddress", "countryOrRegion" HAVING COUNT(distinct "userPrincipalName") > 1 ) subquery GROUP BY "ipAddress","countryOrRegion" HAVING count("timebucket") > 1) select count(distinct "activityDisplayName") as distinct_event_count, min("activityDateTime") as first_event, max("activityDateTime") as last_event, daaaae."ipAddress", "userPrincipalName",array_agg(distinct "activityDisplayName") as events, "result", age(max("activityDateTime"),min("activityDateTime")) as duration, extract(EPOCH FROM max("activityDateTime")) - extract(epoch from min("activityDateTime")) as duration_epoch from directory_audit_activity_azure_ad_entity daaaae , org_ips where "activityDisplayName" in ('Reset password (self-service)', 'Self-service password reset flow activity progress', 'User deleted security info', 'User registered security info', 'User started security info registration') and daaaae."ipAddress" not in (select distinct org_ips."ipAddress" from org_ips) and "result"='success' group by "userPrincipalName",daaaae."ipAddress", "result") base where distinct_event_count = 5 and duration_epoch <= 604800 MITRE Technique Initial Access | Social Engineering and Phishing | ATT&CK T1566 Scenario 10 - Abusing Third-Party Users (Supply Chain Attack) Many Azure AD tenants are trusted by third-party accounts - IT providers, security tools, or maybe trusted partners. Third-party accounts should perform directory changes only if the activity is authorized by the tenant administrator. Use the following query to detect changes performed by guest accounts in your organization. Unauthorized activities may suggest that the third-party account is compromised  Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest directory changes select daaaae."activityDateTime", daaaae."ipAddress", daaaae."userPrincipalName", daaaae."activityDisplayName", daaaae."result", jsonb_array_elements(daaaae."targetResources")->>'userPrincipalName' as "external_user_name", siaaae."homeTenantId", siaaae."resourceTenantId" from directory_audit_activity_azure_ad_entity daaaae, sign_in_activity_azure_ad_entity siaaae where "result" ='success' and daaaae."correlationId" = siaaae."correlationId" and siaaae."homeTenantId" is not null and siaaae."homeTenantId"!=siaaae."resourceTenantId" MITRE Technique Execution | Trust Relationships | ATT&CK T1566 Scenario 11 - Abusing Single Password Authentication Single-factor authentication is a security risk that is best avoided by enforcing MFA, but it is not always possible to do so. Adversaries will often try to abuse users that are not protected by MFA. Use the following query to monitor single-factor authentication from non-organizational IP addresses. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest invites with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion" FROM ( SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount", "ipAddress","countryOrRegion" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 0 AND "createdDateTime" > now() -interval '1 week' GROUP BY TimeBucket, "ipAddress", "countryOrRegion" HAVING COUNT(distinct "userPrincipalName") > 1 ) subquery GROUP BY "ipAddress","countryOrRegion" HAVING count("timebucket") > 1) select "createdDateTime", "ipAddress", "autonomousSystemNumber", "countryOrRegion", "userPrincipalName" , "appDisplayName", "conditionalAccessStatus" from sign_in_activity_azure_ad_entity siaaae where "authenticationRequirement" ='singleFactorAuthentication' and "errorCode" = 0 and "isInteractive" = true and "ipAddress" not in (select distinct "ipAddress" from org_ips) and "countryOrRegion" not in (select distinct "countryOrRegion" from org_ips) MITRE Technique Initial Access | Valid Cloud Account | ATT&CK T1078.004 Scenario 12 - Azure AD Sync Abuse Azure AD Connect is a Microsoft tool that enables synchronization and integration between on-premises Active Directory (AD) and Azure Active Directory (Azure AD). It allows organizations to extend their on-premises identity infrastructure to the cloud, providing users with a seamless single sign-on experience across both environments.  AAD Connect synchronizes user accounts between on-premises domain controllers and AAD tenants, utilizing a privileged user account authorized to update to the AAD directory. A compromised domain controller could allow an attacker to move laterally to Azure AD by extracting the login credentials of an AAD Connect user.  Relevant Azure AD Event Source  Azure AD Directory Sign-In Logs Query -- Search AAD Connect user abuse select "createdDateTime", "ipAddress", "countryOrRegion", "userPrincipalName", "appId","appDisplayName", "errorCode" from sign_in_activity_azure_ad_entity siaaae where "userPrincipalName" ilike 'Sync_%' and "appDisplayName" not in ('Microsoft Azure Active Directory Connect','') MITRE Technique Initial Access | Valid Cloud Account | ATT&CK T1078.004 3 Additional Queries For Azure AD Access Governance On top of the scenarios mentioned above, there are additional relevant queries that can be used to hunt for threats in an Azure AD tenant. Their results are harder to rely on since they require having a deeper context of the regular activities in the organization to differentiate the legitimate operations from those that may be part of an actual threat. For example, a user was assigned an administrative role. It could be malicious or legitimate, and requires triage for a verdict:  Who performed the action? Is this the first time this actor assigns privileges?  Are there any client characteristics that do not make sense coming from that actor? Query 1 - New Application Creation Malicious applications can serve adversaries to get their first foothold in an Azure AD tenant. Review the installed applications that were installed by administrators. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search for new AAD applications select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'displayName' as "appName" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Add application' MITRE Technique https://attack.mitre.org/techniques/T1204/ Query 2 - A Guest Was Invited to the Organization Guest users can be invited to an Azure AD tenant - This means that users from different Azure AD tenants can access your tenant. It’s important to review these invites to make sure that only authorized third-party users will be invited. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest invites select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'userPrincipalName' as "external_user_name" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Invite external user' MITRE Technique https://attack.mitre.org/techniques/T1199/ Query 3 - New Authentication Policy Exclusion Azure AD Conditional Access Policy is a powerful feature that controls access to the organization based on specific criteria. If a user or a group of users are excluded from a conditional policy, they might put the organization at risk. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Policy Exclusions select "activityDateTime", "userPrincipalName", category, "activityDisplayName", "operationType",jsonb_array_elements("targetResources")->>'displayName' as "policyName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newConditions", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' as "oldConditions" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName"='Update conditional access policy' MITRE Technique https://attack.mitre.org/techniques/T1556/ Rezonate Tool For Exporting Azure AD Logs As promised, we have included 2 tools that can be used to accelerate the application creation and the log extraction process. They are both available in our GitHub repository.

In April 2023, Rezonate research team explored prevalent misconfigurations of GitHub integration with cloud native vendors. GitHub OIDC-based trust relations have been found with the critical misconfigurations that leave connected AWS/GCP accounts vulnerable to potential takeover attacks. Although this issue was discovered and reported in the past, we have found that dozens of GitHub Public Repositories, and potentially many private ones, have demonstrated this critical issue, leaving dozens of companies vulnerable. The team notified recognizable affected organizations, but there may be more private repositories and organizations at risk. In this article, we will introduce the misconfiguration research process,  explain the OIDC implementation process that GitHub uses to authenticate to the cloud, present the misconfigurations that we have identified across various organizations, provide a step-by-step guide for discovering and fixing the problem, and propose how to avoid the issue completely. Key Points Rezonate research team has explored an attack vector that exposed AWS & GCP accounts to unauthorized access through misconfigured OpenID (OIDC) GitHub Actions role. Based on our scans, these known misconfigurations exist in dozens of the GitHub public repositories that use Github OIDC provider to AWS or GCP. During the last few weeks, the Rezonate team has reached out to a few dozens of vulnerable organizations and personal accounts, providing them with information in order to remediate this misconfiguration. To check whether your GCP or AWS accounts have been affected by this misconfiguration, please refer to the “Remediation Guidelines” section. Background Cloud and SaaS technologies have made identity and access controls the connective tissue between operational tools and cloud-native environments. To ensure business operations flow as seamlessly and as fast as possible, IAM and Devops teams are required to share administrative access and create trust relations between 3rd-party tools and their core cloud environments. The key challenge is to limit privileges and conditions on these cases, and to protect and monitor this highly-privileged administrative access. One of the most common examples of trust relations can be found in a software CI/CD pipeline, where strong privileges and access to an organization’s Cloud infrastructure are provided. We’ve seen dozens of cases where this access path was exploited due to misconfigurations, lost credentials and access keys, and compromised supply chains such as the CircleCI incident, the NPM incident, and many others. Figure 1: Attacker scans for misconfigured trust relations in GitHub, and uses them to impersonate a CI/CD app, gaining full access to AWS or GCP accounts. Due to the highly-sensitive nature of these access paths, CI/CD vendors have added support for the OpenID Connect (OIDC) protocol to supply short-term credentials, which are considered more secure. The trend toward OIDC support is reflected through the announcements of GitHub, GitLab, and CircleCI within the last 2 years. OIDC is a modern, secure authentication method for creating trust relationships, but when not configured correctly, the method can become the root cause of a hidden, critical access risk. Even though these misconfigurations were reported in the past, in books, as well as in security blogs, the Rezonate research team has identified many organizations that remain vulnerable.  GitHub OpenID Provider Integration The GitHub OIDC deployment guide highlights many advantages to using OIDC over access keys. OIDC allows you to adopt good security practices, such as: No cloud secrets: Eliminating the need to store cloud credentials as long-lived secrets. Instead, workflows will request and use a short-lived access token from the cloud provider through OIDC. Authentication and Authorization management: Having granular control over how workflows can use credentials, using the cloud provider's authentication and authorization tools to control access to cloud resources. Rotating credentials: With OIDC, the cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires. The following diagram provides an overview of how GitHub's OIDC provider integrates with GitHub Actions and the cloud provider: Figure 2: Overview of GitHub OIDC provider integration In general, integration involves the following steps: Start by creating an Identity Provider in the target cloud environment. GitHub Actions will generate an OIDC temporary token containing execution context (such as the repository, organization, or branch). GitHub will send a request to the cloud provider, containing the GitHub OIDC token. The cloud provider will validate the token and the context, and exchange it with short-lived credentials that allow access to the cloud environment. GitHub OIDC Integration with GCP & AWS Integrating GitHub Actions through OIDC includes setting up trust between the cloud infrastructure and GitHub, which workflows can then use to access roles and service accounts. Configure Trust The process of configuring trust between the cloud provider and GitHub is similar between different cloud providers, and includes two main steps: Create an OIDC Identity Provider that points to: https://token.actions.githubusercontent.com. Create a Role or Service account and establish trust with the recently created Identity Provider. Let's examine the setup for GCP and AWS. Configure Trust with GCP Based on Google Cloud documentation, the following process creates a Workload Identity Federation, which provides the issuer ID and basic attribute mapping. Figure 3: Creating a Workload Identity Federation Optionally, after configuring the attribute mapping according to the Google Cloud documentation, add Attribute Conditions such as a GitHub organization, repository, or branch. Figure 5: Adding Attribute Conditions Now that we have the Identity Provider configured, we can bind it to service accounts and allow GitHub to use them as part of its workflow. In the picture below we can see the github-actions-integration service account connected to the Identity Provider recently created.  Figure 5: Bind service accounts to Identity Provider Configure Trust with AWS Similar to GCP, AWS starts with creating a new Identity Provider (OpenID Connect) with the GitHub Provider URL. Figure 6: Create an Identity Provider in AWS Next, we can create an IAM Role and reference the recently created Identity Provider, allowing users federated by the Identity Provider to assume roles in the account. Figure 7: Create an IAM Role Next, we name the role, add a description, and modify the access conditions of the role. By default the trust policy condition only includes audience filters. Figure 8: Modify access conditions using filters As mentioned in the GitHub integration documentation, it's highly recommended that you limit access to specific repositories by adding filters against the token subject. Note that by default the AWS process does not enforce adding additional conditions. To add conditions, click the “Edit Policy” button, which reveals the following warning: Figure 9: Missing additional conditions warning in AWS Configure GitHub Workflow Now that everything is configured from the cloud infrastructure side, the next step is to use the relevant GitHub actions as part of the workflow. First, add permissions to the workflow, allowing it to read an OIDC token. Add the following permissions to the beginning of the workflow YAML file: Figure 10: Add permissions to GitHub workflow Next, add the matching action to the authentication process, based on the cloud provider:For AWS, use the configure-aws-credentials: Figure 11: Add matching action to authentication process - AWS For GCP, use the google-github-action/auth: Figure 12: Add matching action to authentication process - GCP After performing the steps above, the integration process is completed and the workflow can perform operations in the cloud environment. Potential Misconfiguration Although the integration between the cloud and GitHub is relatively simple, potential misconfigurations could expose access to unauthorized parties. GitHub articles refer to Conditional access as part of the integration process, however, the cloud infrastructure is not flagging or alerting when conditional access is not being used. The lack of notification from the cloud provider during the setup increases the chances that an organization will have misconfigured trust settings. Those misconfigurations may result in roles and service accounts that can be abused by threat actors/attackers, leading to unauthorized access. As a result of our research, we have discovered two specific types of misconfigurations that can be exploited by attackers to gain unauthorized access to a trusted cloud account. Misconfiguration - Lack of Subject Condition This misconfiguration occurs when the user who integrated the role did not add conditional limitations to cloud access. This misconfiguration allows any GitHub organization to access the cloud account. Misconfiguration - Poorly-Defined Condition Pattern This misconfiguration occurs when the conditions defined limit the subject, but are not restrictive enough and thus can be bypassed. For example, the subject condition may include a wildcard to allow all the repositories in the organization to use the same role or service account as part of the GitHub Actions workflow. If the wildcard is mistakenly placed in the organization name (and not in the repository name), the condition allows unauthorized access from any GitHub organization with a name that fits into the pattern. Identifying Vulnerable Organizations To Identify vulnerable organizations and understand how prevalent misconfigurations are, we used GitHub search, looking for Actions workflows that use OIDC with AWS or GCP. Using GitHub Code Search, we executed the following queries: Figure 13: GitHub Code Query - AWS OIDC Workflows Figure 14: GitHub Code Query - GCP OIDC Workflows We split the query into subqueries to avoid reaching GitHub’s result limit, and eventually produced a list of roles and accounts that were potentially vulnerable. Having the list, the next step was to identify what was misconfigured. GitHub actions query returned thousands of results, and checking them through GitHub actions would be time-consuming. As a workaround, the team developed a different approach to identify vulnerable organizations using self-hosted runners. Self-Hosted Runners Github Self-Hosted Runners is a feature that allows organizations to execute parts of the GitHub Actions workflows in their own environment. The team discovered that by controlling the machine that authenticates against the cloud, we can extract the OIDC token, and perform batch tests on AWS roles and GCP service accounts outside of GitHub. The batch tests included the following steps: Setup a self-hosted runner:Download and install the GitHub self-hosted runner: Figure 15: Our self-hosted runner Configure the runner to proxy all of the traffic through our local proxy:Use the http-proxy parameter within the GitHub action. Figure 16: The GitHub workflow configured to trigger token generation. Intercept a workflow request and extract the Web Identity Token:After everything was ready, we triggered the workflow by performing a commit to the repository. The commit started a GitHub workflow which performed a network request to assume the target role with the Web Identity token. Then, we extracted the token from the request sent by the runner to AWS. Figure 17: Extract token from runner request - AWS Decoding the JWT Token reveals our sub, along with other identifiers that are being sent and logged by the cloud provider as part of the authentication process. Figure 18: Decoding JWT token Copy the token to our multithreaded script, which will check the potentially vulnerable roles. Using a pre-developed script and leveraging Boto3 and Gcloud, we scanned a list of potentially vulnerable roles while having the JWT at hand. Results After reducing duplicate roles and service accounts, we scanned approximately 1500 roles and service accounts across GCP and AWS. As for the first misconfiguration, lack of subject condition, we determined that dozens of the roles were vulnerable, allowing anyone to use them to access the accounts. The second misconfiguration, poorly-defined condition, was harder to test and required setting up a dedicated GitHub organization per target. Thus, we performed a random test against 20 organizations, finding one of them to be vulnerable to this attack. The vulnerable accounts included various organizations, including private companies, non-profit organizations, software development studios, and many personal accounts. During the last few weeks we have reached out to the relevant organizations and people, sending them information regarding the vulnerable roles and sharing remediation guidance. Remediation Guidelines Could My Environment Be Affected?  Based on our research, this type of misconfiguration is a risk for AWS and GCP users who use GitHub Actions with modern authentication (OIDC). Identify Potential Misconfigurations: Lack of Subject Conditions To identify this misconfiguration In AWS, check for roles that have no subject limitations in its trust policy. Figure 19: Misconfigured Role with no Subject - Example - AWS To identify this misconfiguration in GCP, check for service accounts connected to the Identity Provider that has access to the Entire Pool. Figure 20: Misconfigured Role with no Subject - Example - GCP Identify Potential Misconfigurations: Poorly-Defined Conditions To identify this misconfiguration in AWS, locate the StringLike conditions for roles that are connected to the Identity Provider, and check for wildcards in the organization name. Figure 21: Misconfigured Role with Poorly-Defined Condition Pattern - AWS For example, in this case, we have a role that was originally intended to be used by different repositories within the Rezonate organization. Since the StringLike conditions included a wildcard in the organization name,  every organization that starts with “rezonate” can assume this role. This means that an attacker can create a new GitHub organization with the name “rezonateX” and get access to the role. This misconfiguration option does not apply to GCP, as GCP does not support wildcards. Identity Risks in the Rezonate UI Rezonate customers should look for the security risk “GitHub Actions Role vulnerable to hijacking” in the Rezonate UI and follow the guided remediation steps attached to it. Use a Script to Perform a Quick Scan For the general public, we have released a script to our GitHub repository (link here), which performs a quick scan against the AWS account or GCP project and reveals possible vulnerable roles and service accounts.

Azure Identity Protection is the enigmatic sentinel of the Microsoft realm. Understanding the inner workings of Azure Identity Protection is essential to any information security officer, and will unlock the keys to an effective user risk policy. Unsurprisingly, cyber attackers are sharp – they have found various ways to infiltrate and compromise digital applications. Sometimes, users make their malicious conquests even easier by using weak passwords, leaving over-privileges, and failing to recognize social engineering attacks.  So far, in 2023, 60% of medium-sized companies have reported theft of credentials. As a result, tools like Microsoft’s Azure Identity Protection have become a staple in protecting against compromised identities, account takeover, and misuse of privileges. With a strong identity protection foundation, organizations can adopt concepts like zero trust and confidently progress toward a dynamic, identity-centric model that keeps credentials safe. In this article, we will discuss what Azure Identity Protection is, its features, and its benefits. Then, we’ll review eight best practices to help you get the most out of Azure Identity Protection. What is Azure Identity Protection? Azure Identity Protection is a security service that provides a consolidated view of risky user activities and potential vulnerabilities affecting your identities. It uses adaptive machine learning algorithms to detect anomalies and suspicious incidents such as leaked credentials, sign-ins from unfamiliar locations, infected devices, and impossible travel.  The service generates reports and alerts that enable administrators to investigate and respond to possible vulnerabilities. It also provides remediation capabilities like password resets and multi-factor authentication (MFA) enforcement to resolve issues. What are the Main Features of Azure Identity Protection? Here are 5 key features of Azure Identity Protection: Risky sign-ins detection - Analyzes sign-in patterns and flags anomalous ones like logins, unfamiliar locations, infected devices, or anonymous IP addresses. Risky user detection - Identifies potentially compromised user accounts based on indicators like leaked credentials, suspicious inbox activities, and impossible travel. Risk-based conditional access policies - Automatically blocks or challenges sign-ins and users via MFA or password change. Reporting and investigation - Provides reports on risky users and sign-ins with detailed drill-downs for security teams to investigate. API access - Allows exporting risk detections to SIEMs for further correlation and automated workflows. How Can Azure Identity Protection Improve Security  Overall, Azure Identity Protection has numerous benefits for organizations, including: Detects potential vulnerabilities affecting identities. Investigates risky incidents and takes appropriate action.   Remediates issues and enforces multi-factor authentication. Identifies patterns using machine learning to enhance protection. Reduces the account takeover risk. Promptly identifies, investigates, and responds to identity threats. Helps you view and understand IAM policies.  How to Get the Most out of Azure Identity Protection  1. Engage Stakeholders Early  Securing buy-in and clarity on expectations upfront from internal stakeholders like IT security teams, infrastructure/operations teams, application owners, business leaders, etc., ensures smooth adoption and optimal use of Identity Protection, which maximizes ROI.  Tips: Identify all stakeholders impacted by Identity Protection, such as security admins, IT teams managing authentication systems, application owners, helpdesk, etc. Conduct workshops to demonstrate Identity Protection capabilities like risk modeling, automated response, and reporting. Define their roles and responsibilities in deploying, supporting, and getting value from the solution. Get their input on policies, alerts, and integrations with other tools like SIEM based on their needs. Keep them updated on timelines, changes, and requirements from their side. Set up an onboarding plan for users impacted by MFA registration and risk policies. Create a support/escalation process for issues faced by users. Establish a feedback process for continuous improvement after rollout. 2. Configure Risk Policies Azure Identity Protection allows the creation of Conditional Access policies to automatically respond to user and sign-in risks detected through its AI-driven risk modeling. Properly tuned risk policies act as automated sentinels, promptly responding to abnormal activity before incidents occur. Tips: Enable the user risk policy to enforce actions like MFA or password change for risky users. Enable the sign-in risk policy to trigger MFA prompts or block access for risky sign-in attempts. Set appropriate thresholds for user/sign-in risks based on your security posture. Aggressive thresholds lead to more false positives. Scope policies to all users or specific critical groups like administrators, based on coverage needed. Exclude emergency access accounts from the policies to prevent accidental lockout. Use report-only mode to evaluate policy impact before full enforcement. Review automated remediations in usage reports to correlate risk detections with user/sign-in actions taken. Adjust policies periodically based on analysis of risk patterns in your environment. Export risk detections to your SIEM for further correlation and monitoring coverage. Ensure sufficient testing to balance security with user experience. 3. Require MFA Registration The Azure Identity Protection policy for MFA registration prompts users to enroll for Azure AD Multi-Factor Authentication (MFA) during sign-in, strengthening account security beyond just passwords.  Tips: Enable policies for cloud services, applications, and systems, and enforce registration for all users. Gradual rollout is also an option to minimize disruption. Educate users on MFA and how it safeguards their accounts. Provide clear instructions on enrolling their devices for MFA. For mobile devices, ensure users have downloaded and activated the Microsoft Authenticator app. For desktops/laptops, guide users to enable phone-based MFA or FIDO2 security keys as the second factor. Encourage users to register multiple verification methods as backups. Prioritize MFA registration for privileged accounts like administrators to protect critical access. Consider excluding break-glass accounts from MFA to prevent a lockout. Use report-only mode initially to gauge impact before enforcing registration. Evaluate if existing MFA solutions need to be phased out after the Azure AD MFA rollout. Monitor registration status and follow up with users who don't complete registration after prompts. 4. Exclude Emergency Accounts  When configuring Azure Identity Protection risk policies for user and sign-in risks, excluding emergency access or break-glass administrator accounts from the scope is crucial. The rationale is to maintain admin access to Azure AD in worst-case scenarios like mass user lockouts due to policy misconfiguration or synchronization errors.  Tips: Create at least two emergency access accounts in your Azure AD tenant and ensure they have global administrator privileges. Explicitly exclude these accounts from the Conditional Access policies enforcing MFA, password reset, etc., for risky users/sign-ins. Have a documented process for keeping these accounts secure, including: Ensure the credentials are known only to designated people like CISOs, security leads, etc. Rotate the credentials periodically, ideally every 30-90 days. Monitor the accounts for any anomalous sign-in or usage patterns. Outline the verification process before use if accounts are accidentally locked out. 5. Add Trusted Locations Configuring named locations for office networks and VPN ranges is an essential optimization for Azure Identity Protection's risk modeling. By declaring internal networks as trusted/known locations, sign-ins originating from them will have lower risk scores in Identity Protection. This minimizes false positives and unnecessary challenges for users accessing resources on the internal corporate network. Tips: Create named locations in Azure AD Conditional Access representing office IP ranges and VPNs. Mark on-premises office networks as 'trusted locations' once configured. Configure VPN IP ranges as named locations marked as 'known.’ Update location definitions if office networks or VPNs change. Verify location mappings by checking sign-in logs to see if IP addresses are correctly matching. Exclude unnamed/unknown locations from the trusted or known designations. Review sign-in logs periodically to validate mappings. 6. Enable Security Monitoring Ongoing monitoring and alerting are critical for managing risks Azure Identity Protection detects. Robust monitoring is vital to realizing the value of Identity Protection. You can make risk visibility and response coordination a 24x7 capability through SIEM integration and smart workflows. Tips: Configure email notifications for new risky users/sign-ins and weekly digests. Alert appropriate security team members. Review Identity Protection reports like risky users, sign-ins, and risk detections daily. Create Azure Monitor dashboards to view risk trends, policy actions taken, and track remediation status. Use the Identity Protection workbook template to gain insights through interactive reports. Export Identity Protection events via the Graph Security API to your SIEM solution. Correlate risk detections with other identity-related security events in your SIEM for enhanced monitoring. Configure playbooks in solutions like Azure Sentinel to trigger response workflows based on Identity Protection alerts. Document investigation and remediation processes for security operations. 7. Train End Users An educated user base is less prone to lapses that can jeopardize account security. Continuous training and motivation help sustain user cooperation, which is crucial for successful Identity Protection usage. Tips: Inform users about new Identity Protection policies like MFA registration and risk-based sign-in challenges. Explain the needs and benefits. Provide clear instructions on enrolling for MFA during sign-in prompts.  Train users on proper password hygiene, like using strong passwords, password managers, and not reusing passwords across sites. Set up self-service password reset (SSPR) for accounts. Raise awareness about phishing attacks and how to identify suspicious emails or links. Inform users about reporting suspicious activity, like unfamiliar sign-in locations. Reward security-conscious behavior by employees to drive engagement. Track training completion rates and measure security awareness over time via red teaming. 8. Leverage Rezonate's Identity Threat Protection  While Azure Identity Protection provides fundamental risk detection capabilities, solutions like Rezonate can augment protection for cloud identities and access. Rezonate is an identity threat protection platform that integrates natively with Azure AD and continuously analyzes identity and access patterns to uncover risks. Rezonate also protects and protects and monitors potential compromises of the Azure AD admin console and infrastructure, as experienced in July this year.  Key capabilities to help you maximize Identity Protection: Discovers all human and service identities across Azure AD, Okta, Google Workspace etc., and provides a unified view. Continuously monitors privileged access and entitlements to detect anomalies and generate actionable alerts. Correlates cross-cloud identity management, events, and user behaviors to identify sophisticated attack patterns. Recommends one-click remediation actions for resolving policy violations or mitigating risks. Automates response through integration with existing workflows like Azure playbooks. Provides easy-to-understand visualizations of identity relationships and access paths to resources. Identify Vulnerabilities Before Attackers Do Azure Identity Protection offers adaptive and intelligent capabilities to identify vulnerabilities, remediate risks, and enforce access controls. You can build a comprehensive identity-centric security strategy by leveraging features like risky sign-in policies and integrating Identity Protection with solutions like Rezonate. Rezonate provides unified visibility, detection, and response powered by industry-leading identity graphs. See Rezonate in action today.

We all understand the importance of maintaining strong security protocols and controls. That’s why Rezonate decided to invest in the SOC 2 Type 2 compliance early on, and after only one month since our out of stealth announcement, we successfully achieved attestation. What exactly is SOC 2 Type 2 certification, and why is it important to you? SOC 2, or System and Organization Controls (SOC) 2 type 2 is a widely recognized set of standards that ensure a company’s controls have been independently examined and tested.  The “Type 2” designation refers to the fact that the audit covers a period of time, meaning that a company has not only implemented proper controls, but also demonstrated their continuous effective operation over a period of time.  Which is the key point I want to highlight here: a point-in-time validation vs. continuous readiness. Rezonate protects Rezonate Following any compliance requirements can be quite challenging. For starters, you need to fully understand the specific framework by analyzing and interpreting the right categories and controls. Then, using different assessment tools and manual efforts, you compile a list of all requirements, identifying what has been completed and what needs to be done, ensuring that the process is properly documented, logged, and monitored. So, how can you take steps to remove manual time-consuming actions, excel at all delicate tasks, ensure an error-prone process and achieve zero exception compliance? At Rezonate, we, the Security & DevOps team, use the Rezonate Cloud Identity Protection Platform (CIPP) on a daily basis for several use cases. As part of our ongoing protection of - our own human and compute resources’ IdP-IaaS identities and every access attempt to and from our cloud-native stack -  we ensure continuous compliance readiness across key identity-first trust principles defined by the SOC 2 audit: Security - Enforce the protection of data and systems, against unauthorized access, enforce MFA, and strengthen access controls. Strict inbound and outbound rules. Availability - Maintain availability SLAs at all times. Building inherently fault-tolerant systems which do not crumble under high load. Invest in network monitoring systems and DR plans in place. Confidentiality - Restrict and monitor access to organization’s confidential data and adhere to the principle of least privilege. We do that with the goal of continuously improving our controls and processes, ensuring that we are always meeting the highest standards in the industry. In a real-world and active environment, drifts may happen, however the process we’ve built around it course-correct itself. Protect identities, access, systems, and data We operate in a faced paced environment and therefore our infrastructure changes fast. Yet, we still allow our team the flexibility required to build fast - without compromising security. Using the Rezonate platform, our customers understand the identity security posture with complete visibility of their identities, policies, and access requests to meet all IAM aspects required for the security, availability, and confidentiality principles. Centralized identity inventory - Up to date inventory of all identities: employees, 3rd party vendors, machine resources, roles, groups, applications, and all required context across your multi-IdP / multi-cloud infrastructure. Access events - Discover and understand every access performed on or from a monitored identity, since its creation time to its last active session and activity performed. Privileges analysis - Evaluate entitlements provided to actual usage and true need for access and business operation. Behavior baseline & drift - Analyze every access request to critical data and application and realize possible risk across our IdPs and cloud infra. Risky exposures - Detect and better understand critical exposures, new access requests, and policy distribution to our engineering and overall staff. While we evaluate each request and relevant context to uncover potential hidden interdependencies, risk and implications. Threat detection - Detect any malicious impersonating, access rights, and excessive privileges, while evaluating possible impact, and taking action before damage occurred. Remediate - Proactively enforce a real-world least privileged access where Rezonate’s DevOps can ‘flex’ policy for unnecessary and risky privileges and ‘relax’ entitlements and access privileges for confirmed benign ones for increased productivity and agility. We have built this mechanism, all while abiding compliance mandates, to comply and stay audit-ready despite complex architectures to protect our most trusted asset - our customers’ data. Be able to provide required proof for observation period instantaneously without the manual effort involved.  If you want to speak with our team on how we are leveraging the Rezonate platform to protect Rezonate and by doing that, maintain SOC 2 Type 2 audit readiness for everything related to your identity and access, sign up for a demo or simply let us know info@rezonate.io.  Thank you to our partners, EY and Scytale, for their partnership on this and future milestones. 

In this riveting new episode of 20 Minute Leaders, Rezonate's CEO, Roy Akerman, the visionary mind behind Rezonate, a groundbreaking cybersecurity firm aimed at securing identities and protecting businesses. With 85% of today's attacks stemming from compromised identities, machines, or users, the need for a cybersecurity revolution is louder than ever. Roy enlighteningly delves into how Rezonate was born out of this urgent demand, Rezonate's innovative approach that disrupts traditional systems, and the future of cybersecurity. Don't miss out on this deep dive into the world of tech security, where old paradigms are challenged and revolutionary solutions are birthed. To listen to the full episode: https://youtu.be/F0xvRBrvS_M Spotify: https://open.spotify.com/episode/6dzJlrSrmVshYOGh4j6Jli?si=IG7SZiKNQOSBb4SXKlAEwA For more information, contact us or request a free demo. Like this article? Follow us on LinkedIn.

We are proud and humbled to announce that Rezonate has been named a 2023 'Cool Vendor' by Gartner Identity-First Security report. We believe that this is a significant milestone in our journey to build an identity-centric security platform to protect user and machine identities and their access privileges all across their access journey to cloud-native resources and critical SaaS Applications.  The rise in cloudification and SaaSification of things has consequently increased the volume and complexity of identities, their privileges, and activities, with that, the challenge of preventing and stopping access-based attacks. A new paradigm is necessary in this dynamic and distributed construction of the digital world. A paradigm that puts the defender a step ahead, exerting greater control than the adversaries. A paradigm that doesn't isolate applications and cloud services but instead views and orchestrates an identity in its entirety across its access journey with accumulated privileges and security controls, automating security posture enhancements, threat detection and response, and compliance requirements. The Magic of faster and more robust identity security adaptation lies back in the interdependencies between these 3 parts of the security missions, which cannot be done separately anymore and should Resonate together with the business cycle. This is our rai·son d'ê·tre, reason of existence - to make the rapid building, securing, and threat elimination Rezonate, which makes defenders much more powerful and successful vs. eliminating adversarial opportunities to compromise identities and breach organizations. At Rezonate, we believe from day zero that identities are the new core of security in the shared security model of cloud and SaaS. Our platform is built from the ground up to provide real-time visibility to identity's full access journey across clouds, SaaS, and identity providers. We aim to continuously fortify identity posture, reducing its susceptibility to compromises and defending against cyber attacks in real-time. This approach has enabled our customers to understand better, solve, and protect their assets. Congrats to all our customers, partners and of course the Rezonators all over the world. Let’s go! Join the revolution today and use Rezonate to mature your IAM Program and stop the next identity breach.  Rezonate was named as a Cool Vendor in the 2023 Gartner® Cool Vendors™ in Identity-First Security report.  “Gartner defines “identity-first security” as an approach to security design that makes identity-based controls the foundational element of an organization’s protection, detection and response architecture. It marks a fundamental shift from the perimeter-based controls that have become obsolete because of the decentralization of assets, users and devices. The focus of identity-first security is on the three C’s — Consistent, Contextual and Continuous — which marks a fundamental shift from perimeter-based, static controls toward dynamic ones.” Unique to Rezonate is our platform's ability to continually discover permissions based on identities' privileges and activities, identify weak spots and risky behaviors, and enable remediation playbooks. Rezonate offers a window to your entire ecosystem, extending to SaaS applications, identity providers, and native cloud. We believe this Gartner recognition is a significant milestone for us at Rezonate. We remain steadfast in our commitment to providing an all-encompassing identity-first security platform that continually strengthens security posture, empowers robust defense, and enables effective remediation. Thank you for helping us shape the space and redefine the way identity security should be done in the age of cloud and SaaS, and thank you to our customers, partners, and the awesome rezonators worldwide. This is only day one! Let’s go! Gartner, Cool Vendors in Identity-First Security, By Brian Guthrie, Robertson Pimentel, Henrique Teixeira, Michael Kelley, Felix Gaehtgens, Erik Wahlstrom, Rebecca Archambault, Published 6 September 2023 Gartner Disclaimer GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and COOL VENDORS is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

The world of Identity and Access Management (IAM) is not just about selecting a vendor – it's about selecting the right vendor. In a rapidly evolving sector, making informed decisions is critical for your business to stay secure and efficient. With its long-standing reputation in tech research, Gartner has led the way in offering crucial insights into this domain. A telling projection is that by 2026, 90% of organizations will primarily rely on identity threat detection tools – a jump from less than 20% today. This shift underscores the criticality of understanding the IAM vendor landscape and making informed choices. What is the Gartner IAM Magic Quadrant and What Does it Mean? The Gartner IAM (Identity and Access Management) Magic Quadrant is a research methodology that presents a graphical representation of a market's direction, maturity, and participants. It offers an analysis of technology providers in the IAM domain, focusing on their ability to deliver and the completeness of their vision. The IAM Magic Quadrant evaluates the strengths and weaknesses of the most significant providers in the marketplace. It offers custom category weighting, showcasing the evolution of the vendor space over time. Furthermore, it incorporates user reviews to provide a comprehensive understanding of each vendor, ensuring a cap of twenty vendors to maintain the quality and significance of its insights. Getting included in the Magic Quadrant means getting exclusive approval from Gartner, which proves to your customers that you are an exceptional vendor.  The Four Quadrants: 1. Challengers Challenger providers have a good capability to execute but may not have a fully realized vision. They are solid and stable, often having a large market presence, but may lack innovative features or forward-looking strategies. 2. Leaders Leader vendors excel in both their ability to execute and the completeness of their vision. They are often the dominant players, demonstrating a clear understanding of market needs and exhibiting robust performance through a comprehensive range of products. Rezonate integrates with a Magic Quadrant Leader, Okta, to help detect risks and threats across your Okta infrastructure through least privilege best practices and auto-remediation. No matter how big a vendor’s reputation is, it’s always essential to consider solutions like Rezonate that continuously monitor your systems and offer real-time threat protection. 3. Niche Players Niche players focus on a specific segment or have a limited innovation capability beyond their niche. They may excel in their specialized domain but not offer a broad suite of solutions or expansive growth strategies. Source 4. Visionaries Visionaries are companies that showcase a strong ability to envision future market trends and plan accordingly, even if they might currently lack execution capability. They are innovative and forward-thinking, often introducing new features and capabilities ahead of the market. What are the Goals of the Magic Quadrant? The Gartner IAM Magic Quadrant is designed to help you navigate the often intricate landscape of IAM vendors. Its primary goals and benefits include: Informed Decision Making The Magic Quadrant serves as a guide for businesses to choose the right vendor, ensuring they evade the costly repercussions of a suboptimal decision. With a comprehensive analysis of each vendor's strengths and weaknesses, businesses can make choices that align with their specific needs and objectives. Optimized Expenditure The Magic Quadrant is pivotal in financial planning as it benchmarks vendor pricing against the market. This means businesses can show if they are getting value for money or if they can achieve the same or better outcomes at a more competitive price point. Minimized Complexity and Risk One of the unsung advantages of the Magic Quadrant is its analysis of contract terms and conditions. By doing so, Gartner helps shield businesses from unforeseen costs and potential pitfalls, ensuring a smoother engagement with vendors and a more predictable budgetary landscape. In effect, the Magic Quadrant is a strategic compass, guiding businesses toward vendors that meet their immediate needs and align with their long-term goals while ensuring cost-effectiveness and reduced risks. 7 Tips to Make Sense of the Gartner IAM Magic Quadrant Navigating the Gartner IAM Magic Quadrant can initially seem daunting, given its comprehensive analysis of vendors. However, understanding its methodology and nuances can help both IAM vendors aiming for a spot in the Quadrant and businesses seeking the best solution. Here's a breakdown of seven critical sections of the report: 1. Market Definition/Description Understanding the IAM market as defined by Gartner is crucial: “Gartner defines access management (AM) as tools that establish, enforce and manage journey-time access controls to cloud, modern standards-based web and legacy web applications.” For example, Gartner-approved capabilities provided by AM tools could include: API access control User authentication (e.g. least privilege and zero trust principles) Advanced lifecycle management capabilities Journey-time orchestration in the context of access management Internal access administration (e.g. user onboarding and provisioning) Reporting for compliance purposes Gartner's market definition ensures businesses are comparing vendors catering to the same market segment. When you align your vendor evaluations with Gartner's definition, you're better poised to select a solution that truly fits your needs. On the other hand, vendors should streamline their offerings to fit within this defined market. By doing so, they enhance their visibility and relevance in the Quadrant. Caption: This graph shows where the top vendors lie in the four quadrants. Source 2. Inclusion Criteria The inclusion criteria are akin to the gatekeepers of the Magic Quadrant. They stipulate the fundamental requirements a vendor must meet to be considered. For businesses like yours, this gives you confidence that every vendor in the Quadrant has already met a baseline of quality and capability. Vendors aiming for a spot should meticulously tailor their pitches and presentations to highlight how they meet or surpass these criteria. 3. Exclusion Criteria While the inclusion criteria set the stage, the exclusion criteria provide a reality check. Knowing who didn't make the cut – and why – can offer you clarity on Gartner's stringent standards. In contrast, vendors should steer clear of pitfalls that lead to exclusion. Avoiding exclusionary factors is paramount, whether this means ensuring a significant market presence or ramping up core IAM capabilities. 4. Evaluation Criteria Part 1 | Ability to Execute A vendor's operational prowess comes to the forefront with their ability to execute, encompassing everything from product quality to overall business health. For businesses, the Magic Quadrant offers a peek into a vendor's operational strengths and potential longevity in the market. Vendors can bolster their position by relentlessly improving product quality, fortifying their financial health, and refining their customer service approach. Table 1: Ability to Execute Evaluation Criteria Evaluation CriteriaWeightingProduct or ServiceHighOverall ViabilityMediumSales Execution/PricingHighMarket Responsiveness/RecordHighMarketing ExecutionMediumCustomer ExperienceHighOperationsLowAs of August 2022 Source: Gartner (November 2022) 5. Evaluation Criteria Part 2 | Completeness of Vision A vendor's foresight is illuminated through their completeness of vision. Businesses can glean insights into whether a vendor is merely keeping pace or truly pioneering the future of IAM using the Magic Quadrant. This criterion serves as a testament to a vendor's innovation and adaptability. Vendors can impress Gartner by immersing themselves in continuous market research, aligning their strategies with emerging trends, and remaining receptive to user feedback. Table 2: Completeness of Vision Evaluation Criteria Evaluation CriteriaWeightingMarket UnderstandingHighMarketing StrategyMediumSales StrategyLowOffering (Product) StrategyHighBusiness ModelMediumVertical/Industry StrategyLowInnovationHighGeographic StrategyHighAs of August 2022 Source: Gartner (November 2022) 6. Market Overview The IAM market is in constant flux, marked by innovations, challenges, and shifts highlighted in the Magic Quadrant report. The market overview section gives businesses a panoramic view of IAM industry activity, helping you align with prevailing best practices and be attuned to upcoming changes. Vendors can carve out a competitive edge by staying in sync with market movements and preemptively addressing emerging needs in their product offerings. 7. User Reviews In an age of information overload, authentic user reviews stand out. They offer businesses a raw, unfiltered view of a vendor's offerings, echoing the voice of real-world users. Gartner's rigorous process ensures these reviews are comprehensive and trustworthy. Vendors can enhance their Quadrant positioning by nurturing customer relationships, promptly addressing concerns, and cultivating an ecosystem where satisfied users are advocates. Navigate the IAM Landscape With a Gartner-approved Vendor The Gartner IAM Magic Quadrant provides you with a clear compass to navigate the IAM vendor space. By breaking down the market, evaluating vendors meticulously, and incorporating valuable user reviews, it offers companies like yours a robust tool to make strategic decisions in the realm of Identity and Access Management. But there’s more to the IAM industry than the Magic Quadrant report. Recognized as a Cool Vendor in the 2023 Gartner Cool Vendors Report in Identity-First Security, Rezonate is making waves with our forward-thinking approach. Our commitment to identity-centric security tackles the pressing challenges of compromised identities and rising breach costs. Explore Rezonate’s platform or request a demo to see firsthand how identity-first security can redefine your protection strategy.

Identity is a topic philosophers have struggled with for years. Identity as a concept spawns many smaller questions, such as "What makes you who you are?". In the realm of cybersecurity, identity is just as groundbreaking and raises comparable concerns when trying to discern who is who and who should have access to what. In 2023, the global average cost of a data breach was $4.45 million, representing a 15% increase over the last three years. Now more than ever, it is imperative that companies take a proactive approach to secure their resources and continuously monitor their security posture – starting with that age-old yet ever-changing concept of identity.  This article will discuss what the zero trust maturity model is, its stages, and its pillars. Then, we will provide actionable steps for you to implement zero trust maturity model principles in your enterprise. What is the Zero Trust Maturity Model? The Zero Trust Maturity Model (ZTMM) provides a framework organizations can use to incrementally bolster their security by implementing zero trust in their environment. The fundamental principle of zero trust refrains from granting implicit trust to any user or asset within a given environment. In simpler terms, trust no one, always verify. The Cybersecurity and Infrastructure Security Agency (CISA) released the initial version of the Zero Trust Maturity Model in August 2021, and it served as a valuable resource for organizations considering adopting a zero trust security architecture. In March 2022, the CISA released a second version (ZTMM 2.0) in response to feedback from the original and to reflect modern security practices. Because the path to zero trust is an incremental process that may take years to implement, the CISA recommends a three-stage approach to zero trust maturity. Stages of Zero Trust Maturity Model 1. Traditional This is where most organizations find themselves at the starting line of their zero trust journey. Here, security practices are often largely manual and may rely on conventional trust models, where access controls are based on network location rather than the individual's identity or device posture. It's a common starting point characterized by a sense of trust within the network perimeter. 2. Initial  At the Initial stage, organizations are tentatively moving away from heavily manual processes. Instead, they’re starting their digital transformation journey by automating tasks like policy enforcement, attribute assignment, and incident response, plus integrating external systems into their business operations. 3. Advanced The Advanced stage in the Zero Trust Maturity Model signifies a vital evolution from traditional security practices. You can move beyond the initial manual security measures and embrace more sophisticated strategies. At this point, security professionals recognize the limitations of perimeter-based defenses and begin to prioritize identity and context in access control decisions. For example, they have started implementing multi-factor authentication, network segmentation, and more robust monitoring. 4. Optimal In this pinnacle stage of the Zero Trust Maturity Model, organizations ascend to an advanced state of cybersecurity readiness. The Optimal zero trust architecture stage represents the zenith of their journey, where manual processes have largely yielded to automated tools and systems. What are the Five Pillars of the Zero Trust Maturity Model? 1. Identity Identity is central to zero trust as it focuses on verifying all users, devices, applications, and services within the network. The purpose is to ensure that only legitimate entities gain access to resources, reducing the risk of unauthorized access. 2. Devices This pillar emphasizes securing all devices accessing the network, including endpoints like computers and mobile devices. Its purpose is to establish trust by assessing the health and compliance of devices, preventing any from compromising the network. 3. Networks The Networks pillar advocates for network segmentation and micro-segmentation. The aim is to minimize the attack surface by enforcing strict access controls, ensuring that threats cannot easily move laterally, even if a part of the network is compromised. 4. Data The Data pillar is dedicated to protecting sensitive information. It aims to protect data through encryption, monitoring, and access controls, ensuring that data access adheres to policies and that data remains secure even if other security measures fail. 5. Applications and Workloads This pillar focuses on securing applications and workloads to determine access based on dynamic policies. It provides the principle of least privilege and ensures that users or systems only have access to the resources relevant to their operations. How Can You Apply Zero Trust Maturity Model Principles to Your Enterprise? Applying Zero Trust Maturity Model principles to your enterprise is a gradual process that requires buy-in from all stakeholders and must align with your organization's overall security goals. To help you become a zero trust enterprise, follow the below steps. Define the Protect Surface The "Protect Surface" spans the entirety of your organization's digital assets, from critical data to the devices and applications that access it. To effectively safeguard this surface, it's essential to begin by visualizing your current cybersecurity landscape. Understanding where your security misconfigurations lie is the first step towards fortification. In this context, IAM solutions step into the spotlight for discovering and profiling human and machine identities and proactively enforcing real-world least privileged access. Create a Strong Identity and Access Management Framework Verifying identity is at the core of zero trust, so you can ensure that only legitimate users and devices have access to your resources. After all, 61% of data breaches involved credentials.  Verifying identity through robust authentication methods is the first line of defense against unauthorized access. Implementing multi-factor authentication and single sign-on (SSO) is essential for enhancing your security posture. While MFA and SSO are vital, keep in mind that you’ll need to continuously monitor access and identity across all your services and devices to rapidly address blind spots in your identity access management policies.  Data: Protect Your Crown Jewels The primary target of cyberattacks is often data, and it's no surprise there were 493.33 million ransomware attacks in 2022 alone. The importance of protecting your data cannot be overstated. Encrypting data in transit and at rest plays a significant role here. Pairing this strategy with other IAM best practices fortifies the data pillar in your zero trust journey. Mapping the Transaction Flows Understanding how users interact with services, what resources they access, and how data flows within your ecosystem is paramount to security. Mapping the transaction flows reveals potential security misconfigurations and empowers you to proactively enforce access controls in line with a zero trust approach. For example, with Rezonate’s simple and intuitive platform, IAM engineers can see and orchestrate the full identity and access map, giving you better visibility over access journeys and greater confidence in making administrative changes.  Again, IAM security platforms prove their value in this case. You can choose a platform that seamlessly integrates into this landscape, offering a comprehensive view of transaction flows. The best platforms enable you to profile and stay consistent with the principles of least privilege across multiple providers. Implementing Security Controls Across the Stack 57% of organizations found the shift to decentralized work made patch management harder. As businesses embrace decentralized work models and multiple cloud service providers, ensuring consistent security controls across the stack becomes both challenging and critical. Performing regular security audits and assessments to identify and rectify weaknesses in your security stack is crucial for maintaining compliance. In addition, you can implement a centralized patch management system to streamline updates across all your services, reducing vulnerabilities. Educate and Train Your Workforce Many people think it's true that humans are the weakest link in cybersecurity. This adage underscores a fundamental truth: even the most advanced security systems can be compromised through human error or manipulation. That's where education and training become indispensable.  Everyone within your organization must adopt a security-conscious mindset in a zero trust environment. By fostering a zero trust culture, you create a collective defense that operates on the principle of "trust but verify." In this instance, trust is never assumed; it's continually validated through stringent authentication and authorization. For example, you could introduce regular incident response drills to prepare your team in case of a security incident. Securing Your Applications and Workloads Safeguarding your workloads in the world of zero trust goes beyond mere firewalls and access controls; it's about active, real-time protection.  Runtime security steps into the spotlight here. It's akin to having vigilant sentinels patrolling your digital kingdom 24/7. These sentinels, equipped with the power of runtime security, proactively monitor workloads, ensuring they adhere to the sacred principles of least privilege. Make Zero Trust Easy and Effective With Real Time Visibility Zero trust is where trust is earned, not assumed, and proactive measures are paramount. To help you implement zero trust, Rezonate's identity-centric platform offers comprehensive coverage and visibility of all access plus continuous risk reduction and protection. With Rezonate, you're not just prepared but actively discovering and mitigating risks. The world of security is evolving, and your security should evolve with it. Take action and use Rezonate to proactively enforce real-world least privileged access and become a zero trust enterprise. Book a free demo of Rezonate today.

Cyber attackers are continuously upping their game. They make it their mission to constantly search for user, system, and infrastructure vulnerabilities and gain unauthorized access to sensitive data.  With 61% of all data breaches involving compromised credentials. An IAM breach's consequences can vary from immediate financial losses to irreparable long-term reputational damage. Organizations must take proactive measures with specialized tools like Okta to identify and prevent IAM breaches. Okta is a leading identity and access management provider with excellent features to safeguard your digital identities against cyber attacks. In this article, we will discuss eight security best practices to get the most out of Okta. What is Okta Security? Okta Security is a robust identity management service designed for businesses and developers. It offers two leading solutions: Customer Identity Cloud and Workforce Identity Cloud. The Customer Identity Cloud is designed to secure consumer and Software as a Service (SaaS) applications across various industries, handling authentication, authorization, and secure access. On the other hand, the Workforce Identity Cloud aims to secure employees, contractors, and business partners, covering every part of the identity lifecycle. Regardless of Okta's reputation and capabilities, even they couldn't stop the most recent security breach. This highlights the importance of continuously monitoring your systems and being prepared to take action if something goes wrong. It doesn't matter how trusted a tool is; you should always be vigilant and prioritize security. Why Do You Need an Identity Provider Like Okta Security? Imagine your organization is a fort, holding your most valuable hidden digital treasures. In this context, identity provider Okta emerges as the watchful protector, improving the castle's defenses against IAM threats and safeguarding sensitive data. But the story doesn't end there. As your organization scales, the benefits of having such an identity provider will multiply. Enhanced security - Like the guardian at the castle gates, Okta centralizes access controls, authentication, and user management, ensuring that only those with the right keys gain entry to your digital assets. Increased productivity - If you have users who constantly access your resource, you can use single sign-on to allow them access resources without repeatedly re-entering credentials. Reduced IT workload - Okta can also act as the magician of your castle by automating various identity and access management tasks like user provisioning and freeing up IT resources. Regulatory compliance - Okta helps organizations meet compliance requirements around data security, access controls, and auditing. What Types of IAM Threats Might You Face? IAM attacks constantly change, and attackers keep trying different methods to find weaknesses in users or systems. Here are a few common types of IAM threats and how Okta protects your organization against them: Brute force attacks - Attackers try to guess user passwords through repeated login attempts. Okta prevents brute force attacks by locking accounts after several failed attempts. MFA push notification fatigue - Attackers flood users with MFA push notifications, hoping they accidentally approve one. Okta lets you set policies to limit the number of MFA verification messages sent within a period. Session hijacking - Attackers steal a user's valid browser session cookie and take over their account. Okta's device trust feature helps detect compromised sessions. Phishing - Attackers try to steal credentials via spoofed login pages. Okta's domain-bound certificates and email authentication features help block phishing attempts. 8 Okta Security Best Practices DevOps 1. Use Okta SDKs and Libraries Okta provides various SDKs and libraries for different programming languages and platforms. These pre-built code components and features are highly recommended when integrating Okta into your applications. In addition to smooth integrations, this approach provides several significant advantages: Saves time Ensure secure communication Standardize the IAM implementations Reduces the likelihood of coding errors Tips for selecting the best SDKs: Choose the SDK that matches your application's programming language. Regularly update the SDKs. Look for security vulnerabilities in the libraries. 2. Secure API Tokens API tokens are the keys to your digital fortress, providing access to stored digital assets. Therefore, securing API tokens is crucial to prevent unauthorized access to sensitive information and resources. Tips to secure API tokens: Store API tokens in a secure secret management solution rather than code or config files. When creating tokens, grant only the minimum scopes needed for that application. Set tokens to expire automatically after a shortened 30-90 days. Audit and revoke tokens that are no longer needed. Ensure tokens are transmitted only over secure channels like SSL/TLS. CISOs (Chief Information Security Officer) 3. Integrate with ITDR Solutions Identity Threat Detection and Response (ITDR) is a security solution category designed to detect, investigate, and respond to potential security threats that target an organization's identities, credentials, and cloud entitlements. It entails detecting unusual activities, identifying compromised credentials, integrating with identity and access management (IAM) policy enforcement, and more. It's important to note that integrating Okta with ITDR is a continuous process. While it helps to enhance an organization's security posture, it does require regular updates and reviews to ensure it evolves with the changing threat landscape and effectively mitigates identity threats. Here are a few tips to follow when integrating Okta with ITDR: Conduct a thorough analysis to understand the gaps in your current ITDR strategy and see if the ITDR vendor has good coverage for Okta related threats and behavioral analysis. Ensure you understand your organization's compliance requirements and see how Okta's features can help meet those requirements. Before full-scale implementation, conduct pilot testing to understand any potential issues and fix them. Conduct simulation exercises to help users understand how to respond to alerts and notifications generated through the Okta-ITDR integration. Set up real-time monitoring of identity threats leveraging Okta's analytics and reporting features. Ensure the ITDR solution integrates, streamlines, and prioritizes Okta's threat insights according to your business's threat models. Leverage Okta's API capabilities to integrate it with other systems in the organization's IT ecosystem. Implement Single Sign-On (SSO) functionalities to streamline access management and enhance security. 4. Develop an IAM Strategy When organizations scale, they face issues managing user identities and access across multiple systems. But, if you have a well-defined IAM strategy, you can easily tackle such situations. A typical IAM strategy consists of objectives, identity inventory, IAM solution selection, access control policies, and more. With Rezonate's IAM intuitive and collaborative IAM solution, you can gain real-time visibility over accounts, assets, and identity levels. It automatically uncovers and removes risky permissions. Rezonate integrates with Okta, so you'll be up and running within 15 minutes with just one-click, fast deployment.  Tips to follow when developing an IAM strategy: Clearly define the objectives and goals. Create workflows for user onboarding, offboarding, and role changes. Take stock of all user identities within your organization. Choose a robust IAM solution. Use RBAC to assign and manage permissions based on user roles. SecOps 5. Automate Account Lifecycles Automating account lifecycles involves creating processes to manage user accounts from creation to deactivation or removal automatically. This simplifies tasks related to onboarding, offboarding, and role changes. For example, when a new employee joins a company, automation will create an account, assign role-specific permissions, and provide access to the necessary resources. This ensures employees can access the tools and resources they need from day one. Tips to automate account lifecycles: Set up policies to provision and de-provision accounts immediately when employees join and leave. Set alerts to detect if users gain additional application access or privileged roles over time to curb privilege creep. Ensure automation is integrated with identity management, HR, and other relevant tools. 6. Regularly Audit Access and Privileges Regular access and privilege audits help organizations ensure users have appropriate access levels to perform assigned tasks. In addition, they help to identify security gaps, reduce the risk of unauthorized access, and ensure compliance with policies and regulatory requirements. Tips to follow when performing audits: Establish a routine audit schedule. Maintain precise records of user accounts, their roles, and their permissions. Identify and pay special attention to high-privileged accounts like administrators. Revoke access and privileges that are no longer needed. Implement RBAC. IAM Engineers 7. Leverage Multi-Factor Authentication (MFA) Multi-factor authentication (MFA) is a security measure that requires two or more verification methods to grant access to a system. MFA combines something you know (password) with something you have (mobile device) or something you are (fingerprint or face recognition). For example, consider a scenario where an employee's password gets somehow leaked. If you enabled MFA, the hacker couldn't access the account because they didn't have the second authentication factor. Here are a few tips to follow when enabling MFA: Enable MFA for all users. Select robust authentication methods such as one-time passwords (OTP), biometrics, or hardware tokens. Consider adaptive authentication, which assesses risk factors and adjusts the level of MFA required. Ensure there are backup authentication methods in case users lose their primary MFA device. 8. Configure Strong Password Policies Password policies are rules and requirements defined to strengthen the passwords users create. These policies typically include password complexity, length, and expiration time guidelines. Even without specialized tools, a strong password protects against brute-force attacks. Here are a few tips to consider when defining a password policy: Require passwords to include a combination of uppercase and lowercase letters, numbers, and special characters. Require a minimum length for passwords. Enforces regular password changes every 90 days. Prevent using common passwords like 'abcd1234'. Set rules to lock user accounts temporarily after a certain number of failed login attempts. How to Protect Your Okta Environment from Threats Okta is one of the leading identity providers around the globe. However, as organizations move their resources towards the cloud, we can see a significant increase in threats to cloud identities and access management. This highlights the importance of using specialized tools like Rezonate to detect and mitigate risks before they become critical. Rezonate is a modern identity and access management tool that integrates with Okta to help detect risks and threats across your Okta infrastructure. Moreover, it brings continuous risk monitoring, least privilege, real-time threat detection, and automated remediation to supercharge your IAM solution. Book a free demo of Rezonate today and witness firsthand how it can revolutionize your organization's access security.

Success for Switzerland’s largest international private media company means always staying ahead of the digital curve – and security is no exception. Rezonate makes this possible. “With Rezonate our DevOps and security teams are now enabled to work hand-in-hand and understand the complete identity story - across our IdP and cloud infrastructure. We reduce manual workload, increase productivity and eventually reduce the time to remediate critical risks.” Andreas Schneider, former Group CISO and Olivier Martinet, current Group CISO for TX Group The Challenge: Finding and Fixing Identity ‘Blind Spots’ – Fast Speed is of the essence in the media industry: news happens fast, and it’s imperative to deliver – and secure – it rapidly, as well.  Detecting identity issues and compromises in this complex environment, Schneider says, was like finding the proverbial “needle in a haystack.” He used several different tools to try to uncover every vulnerability, but he knew that he wasn’t seeing the complete exposure map. But finding and closing the identity and access management gaps seemed nearly impossible. AWS’s own insight tools proved difficult even for the engineers to use. So Schneider sought help – and found it in Rezonate. “We had blind spots. There were things we didn’t really think about. We check configuration, for example, but do we check privileges? If a vendor says they need access to something, it is a real challenge to continuously validate need and actual usage.”  The Solution: A team approach that really works Schneider chose Rezonate to handle TX Group’s  identity management for a number of reasons:  Real problem solving.  Rezonate sees the extent to which identities use their access privileges so TX Group can revoke  access to unused resources and applications – the “least privilege” approach.  “I don’t know of any other technology that does this. Rezonate alone could give us real-time visibility into our cloud accounts as well as guidance for quick response. We now know exactly what’s going on and where, every moment.” Rapid response. TX Group can now spot risky accounts and mitigate them with ease using Rezonate, and its security and DevOps teams can work together to resolve the identity and access issues that are so common in the cloud — without slowing or stopping operations. Rezonate accomplishes this feat via its Identity Storyline™, the brains behind the Rezonate platform. Identity Storyline simplifies complex identity and access problems and provides clear guidance on how to resolve them.Now, using Rezonate, TX Group can quickly see, in context, each identity’s behaviors in the cloud – past as well as present – and know which might increase its risk of breach, as well as how to best remediate.Identity Storyline goes beyond static dashboards to answer the dynamic questions that need always-current answers such as Where are our blind spots? Where have identities changed or deviated from patterns of behavior? Where are our active threats? “Without Rezonate, we would not be able to see these kinds of suspicious activities on all our identity providers and cloud accounts. Before, we were seeing just minor parts of our  identity and access risk. We now have the complete picture, and can make decisions with confidence.” User-readiness. The Rezonate platform software is up and running and ready to use in minutes. “Rezonate takes zero trust to the next level. Rezonate is, for me, the one-stop shop security tool for protecting our identities in the correct way – for identifying and remediating threats.” The Outcomes: A full and complete view of identities, access, and privileges via Rezonate’s Identity Storyline™ – leveling up “zero trust” security for the cloud Faster time from risk discovery to risk remediation – from days or weeks to minutes Reduced workload for DevOps and security teams as automation handles detection and remediation before risks become threats Greater productivity as DevOps works hand-in-hand with security  to safely design, create, and deploy Optimized access permissions, ensuring a “least privileges” approach Proactive, prioritized responses to risk and threats

Empowering micro businesses to achieve more with a full suite of fintech products means building new tools and functionality fast – without cloud identity and access security slowing teams down. Rezonate makes this possible.  “Partnering with Rezonate to protect identity and access allowed both our security and DevOps teams to feel more secure and confident in how fast we’re moving – despite increasing challenges.” Alexander Sorochan, Head of DevSecOps, PayMe The Challenge: Striking the Right Balance Between Speed, Agility, and Security Financial technology (fintech) companies are innovating with unmatched speed and agility to meet new demands in a digital-first world. But securing this fast-growing industry in sync is proving to be more difficult.  For fintech startup PayMe, one of the biggest security challenges has been cloud identity and access management.  “Swiftly detecting and responding to risks across cloud environments is critical,” says Sorochan, “but it’s next to impossible when security teams are managing access for multiple identities in multiple cloud accounts on different platforms.” Piecing together data across identity sources takes time – something most fintech companies simply do not have to spare.  PayMe knew they needed to act quickly to protect their cloud environment with a security tool that could: Increase operational visibility into cloud identity and access security across platforms Reduce the overwhelming number of insignificant incident alerts and the time spent addressing them Discover and monitor third party cross-cloud access Limit permissions and restrict access to the minimum users required without any impact to operations. With Rezonate, PayMe was able to achieve all of the above, and more.  “Rezonate provides unparalleled visibility into one of the core problems facing fintech today: cloud identity and access. Now, we can prioritize exposures and identify threats as they emerge, without sacrificing speed or agility.”  The Solution: A Single Platform for a United Path Forward PayMe chose Rezonate to protect its cloud identities and access for a variety of reasons: Rapid deployment. Rezonate quickly connected with all of PayMe’s identity and cloud providers, enabling self-launch in no time. Within minutes of deployment, PayMe could see, profile and analyze all of their cloud identities across all of their cloud providers; within hours, PayMe was identifying, prioritizing, and mitigating their most critical risks. The result? A complete view of critical findings for immediate prioritization, instant optimization for access and entitlements, and real-time validation for fixes – all in a single platform.  “Within hours of deployment, we understood the complete picture of our cross-cloud identity and access risks. Our DevOps team uses Rezonate daily to understand context and prioritize critical risks. We are now 10X faster and more effective in remediating security gaps.” Reduced complexity. At Rezonate, simplicity is key to quality security. The brains behind the Rezonate platform, Identity Storyline replaces complex graphs with easy-to-understand storylines that trace every identity risk, exposure and threat from root to impact for a panoramic view at every point in time. Now, PayMe’s security team can spot cloud identity and access weaknesses as they are created, and conclusively determine: What they are and their possible impact Who created them in its original intent Where they exist and how abnormal they are Why they have access and how is that usedHow they might impact security and business operations With complete visibility into its cloud environments from Rezonate, PayMe can now optimize remediation and minimize operational impact using a simple, fast, and unified approach.  A united path forward. Rezonate’s platform brings PayMe’s security and DevOps teams together so they can work as one, quickly identifying and remediating risks across the cloud environment in tandem. With Rezonate, PayMe can holistically connect risk, threat, and operational visibility across teams and across the board. Now, PayMe’s security team can respond with confidence – immediately stopping attacks and wiping out risks from within – freeing their developers to work without security slowing them down.  The Outcomes:  Compliance-ready cloud identity and access security in minutes A proactive security stance with complete coverage for cloud-wide environments Context and automation to prioritize and remediate risks  Active threat detection for prevention before progression Minimized excessive access and administrative permissions Better ability to pinpoint risky exposures, reducing identity exposure debt Visibility into AWS and Okta environments in a single platform

On January 4, 2023, CircleCI, a continuous integration (CI/CD) and delivery service, reported a data breach. The company urged its customers to take immediate action while a complete investigation is ongoing. First critical actions recommended by CircleCI were to ‘rotate any and all secrets stored in CircleCI’ and ‘review related activities for any unauthorized access starting from December 21, 2022 to January 4, 2023’. Why is it such a big deal Malicious use of access keys in conjunction with privileged access can have a significant impact on an organization’s source code, deployment targets, and sensitive data across its infrastructure.  CI/CD pipelines operation requires exactly that - high-privileged access which in most cases is administrative and direct access to source code repositories essential for smooth operation - and as such, considered a critical component of the software development life cycle (SDLC).  Start investigating for malicious activity in your cloud environment Data breaches are unfortunately common and should no longer be a surprise. Every third-party service or application has the potential to act as a supply chain vector by an attacker. When that occurs, excessive access that was previously benign can become a critical exposure, allowing the threat actor to exploit the system freely. Here are immediate next steps security and DevOps teams should take to eliminate any possible supply chain risk - those recommended by CircleCI and beyond: Discover possible entry points - Critical first step involves mapping, linking and reviewing the access of all secrets given to the compromised third-party service to fully understand all initial access attempts and possible lateral movement across all supply chain vectors.Specific to CircleCI data breach, Rezonate observed that multiple accounts had a few AWS programmatic access keys with administrative privileges in the CircleCI configuration, allowing for creation and modification of any resource within the account. Threat containment (& traps) - Once you identify any and all keys, the first option is to deactivate or delete them and create new ones (avoid rotating an unused key). However, while you prevent any future use of these keys, you also limit any potential traces of benign or malicious activity. Why? In the case of AWS, Cloudtrail has limited authentication logging for invalid or disabled keys.A second more preferred option is to remove all privileges from users while keeping the keys and users active. This enables further monitoring of activity using ‘canary keys,’ where every access attempt triggers an alert and extracts threat intelligence artifacts (IOCs such as IP address). Activity review & behavioral profiling - Once you capture all suspected keys, you can begin analyzing their activity within the defined range reported. In our case, we used AWS Cloudtrail as the main data source and investigated the access behavioral patterns. The goal is to create a ‘clean’ baseline of activities that occurred prior to the breach. To help define a profile, understand the scope, and identify any potential areas of concern, consider asking the following questions: Reduce the overwhelming number of insignificant incident alerts and the time spent addressing them Increase operational visibility into cloud identity and access security across platforms Discover and monitor third party cross-cloud access Limit permissions and restrict access to the minimum users required without any impact to operations. Once we have a good understanding of normal operation, we can apply the same approach to inspect activities from the date of breach until the present. In this case, the context of workflows, resources, and overall architecture is paramount, so it is critical to collaborate with the dev/infra team to quickly assess, validate, and prioritize findings. Activity review & threat models - Based on the results of previous steps, further questions may indicate a potentially malicious exploitation, such as attempts to elevate privileges, gain persistence, or exfiltrate data. To help pinpoint the most relevant findings, consider the following options: Activities performed outside of our regular regionsAlerting for anomaly of regular access in an attempt to locate compromised resourcesIdentity-creation activities(ATT&CK TA0003)Activities such as CreateUser and CreateAccessKey attempting to gain persistencyResource-creation activitiesDiscover attempts to perform resource exhaustion for crypto mining and othersActivities performed outside of the regular CircleCI IP rangesIdentify any access attempts from external IPs that may relate to known bad intelErrors occurredDetect “pushing the limits” attempts to exploit user privileges resulting in error (e.g. AccessDenied)Spike in enumeration activities(ATT&CK T1580)Detect increased recon and mapping actions (e.g. user and role listing)Defense evasion techniques(ATT&CK TA0005)Detect tampering attempts to limit defense controls (e.,g. DeleteTrail or modify GuardDuty settings)Secret access attemptsDetect bruteforce actions against mapped secrets to elevate account foothold It’s important to consider all suggested actions as part of the overall context, as some may be legitimate while others may be malicious. By correlating them all together, you can reduce noise and false positives.  How Rezonate can help It’s important to note that while this guidance specifically addresses key actions related to the CircleCI data breach, it can also serve as best practice for addressing any risks for any breach. Rezonate automates the actions described above to streamline the compromise assessment process and reduce the time and effort required for manual analysis. Rezonate simplifies discovery, detection, and investigation of the compromise. Work with a system that can automatically correlate and summarize all activities of all identities to save critical time. Working directly with CloudTrail can be challenging, lacking aggregation, data-correlation  and privileged tagging eventually slowing you down.  We have been collaborating with our clients and partners to utilize the Rezonate platform to thoroughly investigate the security incident and assess its potential impact on all activities mentioned here. If you require assistance, please do not hesitate to contact us. Providing support to our clients and the community is a key purpose of Rezonate's founding.

Update Note Due to the recent events at MGM, which included the compromise of MGM’s Okta tenant, and the surge in attacks of Okta Admins,  we have updated the threat-hunting article, adding a few relevant queries to increase visibility surrounding compromised administrators, and detection of ransom groups that tend to perform aggressive steps to cause maximum disruption to their target and prevent recovery attempts.To read our first Blog Post - Okta Logs Decoded: Unveiling Identity Threats Through Threat Hunting, click here Let the Hunt Continue  Scenario 1 - User Account Hijack Social engineering for initial access is on the rise. These techniques are usually simple and do not require much technical knowledge. Attacks such as phishing, MFA relay, or even buying credentials online may help attackers compromise user accounts.Usually, when an adversary compromises a user, gaining persistent access to that account is essential. To do so, the adversary may change the user’s password and enroll a new MFA device, and in some cases even delete the original user’s factors.The following query identifies user accounts that performed a series of actions from an IP address that is not being used often by the organization, during a short period of time - which might suggest that these accounts are compromised. The actions that this query searches for are: Self-password reset MFA enrollment MFA deletion  Relevant Okta Events: user.mfa.factor.activate user.mfa.factor.deactivate user.account.reset_password user.session.start device.user.add Okta Log Query -- User Account Hijack -- You can use the "actorAlternateId" filter to focus on administrators select "clientIpAddress", "clientCountry", "actorAlternateId", min(time) as first_event, max(time) as last_event, count(distinct "eventType") as unique_events, count(id) as event_count, array_agg(distinct "eventType") as events, extract(EPOCH FROM max("time")) - extract(epoch from min("time")) as duration_epoch from audit_log_okta_idp_entity aloie where "eventType" in ('user.mfa.factor.activate', 'user.mfa.factor.deactivate', 'user.account.reset_password', 'user.session.start', 'device.user.add') and "actionResult" = 'SUCCESS' and time > now() -interval '1 week' --and "actorAlternateId" in ('admin1', 'admin2', ...) group by "clientIpAddress", "clientCountry", "actorAlternateId" having count(distinct "eventType") >= 3 MITRE Technique: Initial Access | Social Engineering and Phishing | ATT&CK T1566 Scenario 2 - Rogue Administrator Tenant Takeover When an adversary successfully compromises an administrator they might try to block access to the rest of the administrators in the organization to strengthen their hold on the tenant and ensure that no one can reverse their actions. In such a scenario, the rogue admin might try to revoke administrative privileges or disable multiple user accounts. Use the following queries to detect the described scenario. Relevant Okta Events: user.lifecycle.deactivate user.lifecycle.suspend user.account.privilege.revoke group.account.privilege.revoke Okta Log Query 1 -- Multiple users disabled or deactivated by a single user select "clientIpAddress", "clientCountry", "actorAlternateId", min(time) as first_event, max(time) as last_event, count(distinct "targetAlternateId") filter (where "eventType"='user.lifecycle.suspend') as unique_suspended_users, count(distinct "targetAlternateId") filter (where "eventType"='user.lifecycle.deactivate') as unique_deactivated_users from (select aloie.time ,aloie."clientIpAddress", aloie."clientCountry", aloie."actorAlternateId",aloie."eventType", altoie."targetAlternateId" from audit_log_okta_idp_entity aloie, audit_log_target_okta_idp_entity altoie where "eventType" in ('user.lifecycle.deactivate', 'user.lifecycle.suspend') and aloie."actionResult" = 'SUCCESS' and aloie.id = altoie."auditLogId") base group by "clientIpAddress", "clientCountry", "actorAlternateId" having (count(distinct "targetAlternateId") filter (where "eventType"='user.lifecycle.suspend') > 1 or count(distinct "targetAlternateId") filter (where "eventType"='user.lifecycle.deactivate') > 1) Okta Log Query 2 -- Multiple admin privileges revoked select "clientIpAddress", "clientCountry", "actorAlternateId", min(time) as first_event, max(time) as last_event, count(distinct "targetAlternateId") filter (where "eventType"='user.account.privilege.revoke') as revoked_users, count(distinct "targetAlternateId") filter (where "eventType"='group.account.privilege.revoke') as revoked_groups from (select aloie.time ,aloie."clientIpAddress", aloie."clientCountry", aloie."actorAlternateId",aloie."eventType", altoie."targetAlternateId" from audit_log_okta_idp_entity aloie, audit_log_target_okta_idp_entity altoie where "eventType" in ('user.account.privilege.revoke', 'group.account.privilege.revoke') and aloie."actionResult" = 'SUCCESS' and aloie.id = altoie."auditLogId") base group by "clientIpAddress", "clientCountry", "actorAlternateId" having (count(distinct "targetAlternateId") filter (where "eventType"='user.account.privilege.revoke') > 1 or count(distinct "targetAlternateId") filter (where "eventType"='group.account.privilege.revoke') > 1) MITRE Technique: Impact | Account Access Removal | ATT&CK T1531 Scenario 3 - Authentication Policy Downgrade When an adevrary successfully compromises an administrator account, they may downgrade the tenant’s authentication requirement to ease their access to the tenant. Policy changes are not events that are triggered frequently since these are sensitive events that occur when the organization updates their authentication requirements. We can use these event to hunt for an adversary that made multiple changes to authentication policies and rules with the following query. Relevant Okta Events: policy.lifecycle.update policy.rule.update policy.rule.add Okta Log Query -- Multiple authentication policy and rules changes select "clientIpAddress", "clientCountry", "actorAlternateId", min(time) as first_event, max(time) as last_event, count(distinct "targetAlternateId") filter (where "eventType"='policy.lifecycle.update') as unique_policies_updated, count(distinct "targetAlternateId") filter (where "eventType"='policy.rule.update') as unique_policy_rules_updated, count(distinct "targetAlternateId") filter (where "eventType"='policy.rule.add') as unique_policy_rules_created, count(id) as event_count from (select aloie.id, aloie.time ,aloie."clientIpAddress", aloie."clientCountry", aloie."actorAlternateId",aloie."eventType", altoie."targetAlternateId" from audit_log_okta_idp_entity aloie, audit_log_target_okta_idp_entity altoie where "eventType" in ('policy.lifecycle.update', 'policy.rule.update', 'policy.rule.add') and aloie."actionResult" = 'SUCCESS' and aloie.id = altoie."auditLogId") base group by "clientIpAddress", "clientCountry", "actorAlternateId" having count(id) >= 3 MITRE Technique: Persistence | Modify Authentication Process | ATT&CK T1556 Scenario 4 - Authentication Via Proxy  Adversaries will try to disguise their origin IP addresses using proxy solutions. When a user uses a proxy for authentication, Okta marks the sign-in as such. Monitor administrators that are logging in via proxy to detect suspicious administrator sign-ins. Relevant Okta Events: user.session.start Okta Log Query -- Proxy Authentication select "clientIpAddress", "clientCountry", "actorAlternateId", min(time) as first_event, max(time) as last_event, age(max(time), min(time)) as duration, count(id) as event_count from audit_log_okta_idp_entity aloie where "eventType" ='user.session.start' and "actorAlternateId" in ('admin1', 'admin2', ...) and "isProxy" = true and "actionResult" = 'SUCCESS' group by "clientIpAddress", "clientCountry", "actorAlternateId" MITRE Technique: Initial Access | Proxy Usage | ATT&CK T1090 2 Additional Queries For Administrative Okta Governance Okta Log Query 1 - Access to Okta Admin App from Rare Locations Monitor access to the Okta admin app from rare IP addresses and search for unauthorized access to the Okta Admin app. Relevant Okta Events: user.session.access_admin_app Okta Log Query -- Admin app access from non-oranizational IP addresses with org_ips as (SELECT count("timebucket"),"clientIpAddress", "clientCountry" FROM ( SELECT DATE_TRUNC('day', "time") AS TimeBucket, COUNT(distinct "actorAlternateId") AS "userCount", "clientIpAddress", "clientCountry" FROM audit_log_okta_idp_entity WHERE "actionResult" = 'SUCCESS' AND "time" > now() -interval '1 week' GROUP BY TimeBucket, "clientIpAddress", "clientCountry" HAVING COUNT(distinct "actorAlternateId") > 2 ) subquery GROUP BY "clientIpAddress", "clientCountry" HAVING count("timebucket") > 1) select time, "clientIpAddress", "clientCountry", "actorAlternateId", "eventType" from audit_log_okta_idp_entity aloie where "eventType" ='user.session.access_admin_app' and aloie."clientIpAddress" not in (select distinct "clientIpAddress" from org_ips) order by time desc MITRE Technique: https://attack.mitre.org/techniques/T1078/ Okta Log Query 2 - Admin Sign-In With Abnormal Client Characteristics Note - The following query is relevant only for tenants who use Okta’s behavior detections in their session policies.Use Okta’s sign-in behavior enrichments to detect suspicious sign-ins to Okta administrators.   Relevant Azure AD Event Source Azure AD Directory Audit Logs Okta Log Query -- Admin Sign-In With Abnormal Client Characteristics select time, "clientIpAddress", "clientCountry", "actorAlternateId", "eventType" from audit_log_okta_idp_entity aloie where "eventType" ='user.session.start' and "actionResult"='SUCCESS' and "actorAlternateId" in ('admin1', 'admin2', ...) and "clientBehaviorVelocity" = true and "clientBehaviorNewIP" = true and "clientBehaviorNewDevice" = true and "clientBehaviorNewCountry" = true and "clientBehaviorNewGeoLocation" = true order by time desc MITRE Technique: https://attack.mitre.org/techniques/T1078/ Learn More Discover more Okta Security best practices to Implement Now with Rezonate.