10 IAM Best Practices for 2023

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.

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 [email protected].  Thank you to our partners, EY and Scytale, for their partnership on this and future milestones. 

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.

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

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.

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.

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

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.

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.

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.

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.

Imagine having the power to scrutinize user permissions with the finesse of a master locksmith, uncovering hidden backdoors and granting access only to the deserving. Sounds great, right? However, in order to do that, we need to first start our process with a User Access Review (UAR). As cloud adoption continues to surge ahead, User Access Reviews are increasingly becoming essential as part of any access management audit process. This necessity is punctuated by the fact that 33% of breaches have human error at their root, but it's not always the user's fault. Some employees are over-privileged without even realizing it, and it's easy for inactive accounts to fly under the radar without regular auditing and UARs.  It's no longer just about who is on your network; a UAR tackles the chaos by ensuring everyone has the right key to do their job – no more, no less. Beyond being a best practice, User Access Reviews are often mandated under regulatory frameworks. Let’s decode the DNA of this essential template, discovering what a UAR is, why you need it, and how to do it. What is a User Access Review? A User Access Review (UAR) is a security and compliance process that ensures that only authorized individuals can access specific systems and data within an organization. Conducted periodically (e.g., monthly or quarterly) or during role changes, a User Access Review is an essential part of your cloud security toolkit, helping you create an inventory of user accounts and their privileges and verify their appropriateness based on job roles.  Managers or system owners often participate in the review to confirm the necessity of these privileges. The process identifies and rectifies inactive, duplicate, or overly privileged accounts, reducing the risk of unauthorized access and leaked secrets. UARs are crucial for meeting regulatory requirements like NIST and GDPR and maintaining a secure environment. Why Do You Need to Do a User Access Review? Imagine an intern with more access rights than your CEO – it's not a crazy or far-fetched idea. Organizations often grant access rights but neglect the importance of revocation. This leads to something called privilege creep, where permissions accumulate as employees transition roles, support other teams, or simply navigate their tasks.  Unfortunately, the accumulation of access rights is a ticking time bomb, as excessive privileges expose your organization to the cycle of compromised identities, account takeover, misuse of privileges, and other threats. Regularly auditing who has access to certain resources allows organizations to better defend against internal and external threats – after all, it only takes one disgruntled employee to trigger a significant data leak.  A User Access Review offers a way to maintain accountability, visibility, and data integrity across your organization, eliminating cloud identity risk. While having the exact permissions they need helps streamline employees' workflows, visibility into active, inactive, and redundant accounts is particularly valuable in forensic investigations following data breaches or during employee transitions.   Download the Free User Access Review Checklist Which Standards Require User Access Review Access reviews aren't just a choice; they are a mandate dictated by various IT frameworks: ISO 27001: Achieving ISO 27001 certification requires organizations to demonstrate a commitment to systematically managing and protecting sensitive information and data.  GDPR: Europe's data protection regulation emphasizes limiting access to personal data to individuals with a legitimate interest. This necessitates audits of who can access personal data, reinforcing compliance. NIST: The NIST Cybersecurity Framework is a voluntary guideline for cybersecurity best practices, and its special publications, like 800-53 and 800-171, stress auditing accounts for compliance. PCI DSS: The Payment Card Industry Data Security Standard ensures that all organizations that accept, process, store, or transmit cardholder information meet strict access control and cybersecurity compliance requirements. The Essential User Access Review Template From creating an access policy and involving stakeholders to embracing the principle of least privilege, here are the essential steps you can take to complete a User Access Review. Regularly Update Your Access Management Policy You can continually review and update your access management policy to reflect organizational changes, new technologies, or compliance requirements. Establish a schedule for these reviews, such as quarterly or biannually, to ensure the policy remains current and effective. You can also get everyone involved and consult with departments like IT, HR, and legal during a policy update to ensure it is comprehensive and aligns with all organizational needs. Review the User Access Audit Procedure Keep your processes agile by continually assessing how you conduct User Access Reviews. Firstly, you can revisit your audit procedures to ensure they align with current best practices and regulatory requirements. Secondly, make sure you know what data you'll collect, how you'll analyze it, and what metrics will indicate success or issues. Finally, you can utilize audit software or tools that provide detailed logs and real-time monitoring capabilities to streamline the audit procedure. Implement Role-based Access Control Use Role-based Access Control (RBAC) to assign permissions based on roles within the organization. This makes managing and reviewing access rights easier, as employees changing roles can simply be switched from one predefined role to another, aligning access with job responsibilities. Periodically re-evaluate the roles and associated permissions to ensure they remain aligned with changing job responsibilities and organizational structures. Involve Regular Employees and Management While it's your job as DevOps, CISO, SecOps, or IAM engineer to prioritize access control, it's also everybody's concern – yep, right down to the interns and temp staff. Be sure to include both regular employees and management in the review process to get a 360-degree view of access needs and usage. Management can confirm which access levels are appropriate for specific job roles, while employees can identify potentially unnecessary or missing access privileges. Structured interviews or surveys can help gather insights about access needs and potential security risks. Document Each Step of the Process Thorough documentation is your ally in understanding challenges and optimizing the review process. Maintaining comprehensive documentation of the User Access Review is critical for audit trails and future reviews. As a bare minimum, you should record who was involved in each step, what changes were made, and why, as well as any anomalies or issues that arose and how they were addressed. Securely store the documentation in a centralized repository that is only accessible to authorized personnel (of course!) to maintain confidentiality and integrity. Educate Your Personnel You don’t know what you don’t know, right? All employees should be aware of the importance of proper access management for security and compliance. Provide training on requesting access, reporting issues, and understanding the impact of access controls on data security. Implement regular refresher courses and updates to keep the workforce on top of any changes in policy or emerging security threats, and pair the training with other cybersecurity know-how sessions like phishing simulations. Choose the Right Access Management Platform You can choose an access management platform to automate privilege management and help meet compliance goals. The right platform will facilitate reviews, manage role-based access controls, and offer features like automated alerts for suspicious activity or non-compliance. Most companies are already jumping on board – this year, 65% of large enterprises will use IAM software to enhance security measures and make compliance easier. For example, some platforms (like Rezonate) help you see IAM problems and solutions by discovering, profiling, and protecting human and machine identities, automatically and proactively enforcing real-world least privileged access.  Get a Complete Picture of Your Access Control Compliance  User Access Reviews have emerged as a critical weapon against unauthorized access and potential breaches, and the secret to success relies on the regularity and longevity of your IAM strategy. Thankfully, protecting identities and meeting regulatory targets doesn’t mean adding more tasks to your to-do list – simply automate it.  Rezonate simplifies compliance tasks by enabling Admins to easily confirm that each user has the correct access rights for their job, providing much-needed visibility over access journeys and the IAM map for confident real-time detection, response, and security.  Rezonate easily categorize and highlights dormant identities across the identity fabric - from workforce identities no longer active, to machine identities such as roles and access keys.  In addition to that, Rezonate enables simple a flow to review access of specific subsets or groups of identities based on specific attributes, such as: Identities that are members of the marketing team and can access the cloud providers such as Azure or AWS Identities that have Administrative privileges and can access SaaS applications such as Salesforce Identities that did not login for more than 30 days and can access specific service on the cloud provider such as RDS in AWS Rezonate’s Identity Centric for Access Review All is done automatically as part of Rezonate’s Identity discovery and effective privileges modules which enables Access Reviews in a click of a button. See Rezonate in action today.

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.