Go back

Okta Logs Decoded: Unveiling Identity Threats Through Threat Hunting

Okta Audit Logs Threat Hunting

Contents

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 event
PublishedEvent time
Event TypeDescribe the type of the event, from a list of ~850 event types
ActorDescribe 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 name
ClientDescribes 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.start
user.authentication.auth_via_richclient
Query— Get users who failed to login from the same IP address at least 5 times
select count(id), “clientIpAddress”, “actorAlternateId”, min(time) as “firstEvent”, max(time) as “lastEvent”
from okta_logs
where “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) >= 5
order by count desc

— For Each result, check if the source IP address managed to login to the target user AFTER the “lastEvent” time
MITRE 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_push
user.authentication.auth_via_mfa
user.mfa.okta_verify.deny_push
Query— Generic
select count(id), “clientIpAddress”, “actorAlternateId”, min(time) as “firstEvent”, max(time) as “lastEvent”
from audit_log_okta_idp_entity
where “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 attempts
order by count desc

— Find FAILED MFA fatigue attempts that were denied by the user
select count(id), “clientIpAddress”, “actorAlternateId”, min(time) as “firstEvent”, max(time) as “lastEvent”
from audit_log_okta_idp_entity
where “eventType” =’user.mfa.okta_verify.deny_push’
and “time” > now() -interval ’24 days’
group by “clientIpAddress”, “actorAlternateId”
having count(id) >= 5
order by count desc
MITRE 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.detected
Queryselect min(time) as “first_event”, max(time) as “last_event”, “actorName”, “actorType”, “actorAlternateId”, “eventType”, “threatDetections”
from audit_log_okta_idp_entity aloie
where “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 event
Queryselect count(distinct “clientCountry”), “actorAlternateId”, “dtHash” from audit_log_okta_idp_entity
where “dtHash” is not null
group by “actorAlternateId”,”dtHash”
having count(distinct “clientCountry”) >1
MITRE 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_username
Queryselect * 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_mfa
Queryselect * 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.start
Queryselect 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”) > 1
MITRE 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_update
Queryselect * 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_accesst
Queryselect count(targets.”targetId”), logs.”actorAlternateId”, logs.”clientIpAddress”, logs.”actorAlternateId”
from audit_log_okta_idp_entity logs, audit_log_target_okta_idp_entity targets
where “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”) >= 5
order by count desc
MITRE 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&CK
user.session.access_admin_appOkta admin T1078
system.api_token.createAdministrative API Token CreatedT1098.001
user.account.privilege.grantgroup.privilege.grantAdministrative Privileges Assignment N/A
user.mfa.factor.*MFA Changes T1556
system.idp.lifecycle.create system.agent.ad.createAddition of external IdPT1556
policy.rule.*
policy.lifecycle.*
application.policy.*
Authentication Policy Changes.T1556
network_zone.rule.disabled
zone.*
Changes to Network ZonesT1556
user.account.report_suspicious_activity_by_enduserSuspicious Activity ReportedN/A
user.mfa.attempt_bypassAttempt to Bypass MFAN/A
security.request.blockedAccess from a Known-Bad IP was Blocked N/A
user.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.

Continue Reading

More Articles
Payme Case Study

PayMe: Protecting cross cloud identity and access with Rezonate

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
Read More
10 IAM Best Practices For 2023

10 IAM Best Practices for 2023

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

Breaking The Vicious Cycle of Compromised Identities

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.
Read More
See Rezonate in Action

Eliminate Attacker’s Opportunity To Breach Your Cloud today

Organizations worldwide use Rezonate to protect their most precious assets. Contact us now, and join them.