Lessons from the Okta Breach for IT Asset Managers

The Okta breach highlights a pattern that has been gradually growing in recent years – Identity-based attacks.

Compromised credentials are preferred by attackers to gain access to desired locations because this is the most vulnerable attack vector in today's enterprise setting.

You should recognize identity as a critical attack surface and protect it accordingly – with real-time prevention, detection, and response to identity threats.

In late January, a well-known cybercrime group, Lapsus$, broke into the accounts of Okta customers through Okta's sub-processor, Sitel. Okta stated that 366 customers' accounts might have been accessed as a result of the incident.

Lapsus$ then posted screenshots of the incident to its Telegram channel. The screenshots showed Okta's Slack channels and a \"Superuser\" dashboard for Cloudflare.

How the Attack Took Place?

Attackers belonging to the Lapsus$ hacking group successfully compromised an endpoint used by a third-party support engineer of the Site by connecting to it using RDP (Remote Desktop Protocol).

After gaining access to the endpoint, the attackers proceeded to deactivate the endpoint security agent. After that, they utilized these tools on the compromised endpoint to obtain the Office 365 account credentials. The account was associated with a business the third-party service provider purchased in 2021.

After gaining access to Office 365, the attackers created a new account and set up a rule to forward all mail to the newly created account.

This incident was estimated to have potentially impacted 366 Okta customers, but the latest report published by Okta has revealed that the breach has impacted only two of its customers.

Like many other SaaS companies, Okta uses sub-processors to supplement its workforce. Sitel is an Okta’s sub-processor that supplies contract workers for their customer support department.

While the recently announced Okta attack sheds light on the vital role compromised, credentials played in the breach. In the context of today's threat landscape, this breach indicates that user identities have become a top targeted attack surface.

This shift in threat actors' tactics has an impact on our security landscape and policies. And we need to defeat attacks that exploit user account credentials.

In this post, we examine the critical lessons that the Lapsus$ threat actors have taught us through this breach, as well as how CIOs and IT leaders can use the insights to strengthen the resilience of their security infrastructure against identity attacks.

Lessons Learned from the Okta Breach

1. Hacker’s Feast on Compromised Credentials

In this attack, compromised credentials had a dual purpose. The first was gaining access to the hacked system, and the second was gaining access to Office 365. As a result, the identity attack vector combines the weaknesses into a very effective attack that puts resources that appear to be well-protected in danger.

2. Identity Protection that is Spread Out Create Loopholes

Blind spots are created by dispersed identity protection. Only a unified identity attack surface can be safeguarded.

Attackers will circumvent loopholes one by one if, for example, remote access via RDP (Remote Desktop Protocol) is protected by the VPN provider, SaaS login by CASB, and internal connection between on-prem workstations by an EDR (Endpoint Detection and Response).

The preferable option is to centrally monitor and protect every authentication and access attempt, such that a recognized risk in a user login to one resource might result in that person's access to all other resources being restricted as well.

One thing that is clear is that identification is the primary attack surface vulnerability. And if you want to win the battle against cyber attackers, the security architectures must change, adapt, and become built around this knowledge.

3. Do Not Take So Long To Notify a Security Breach

On March 17, the summary of a third-party investigation into the incident was made public for the breach that took place in late January. Almost two months!

Due to the delay in notifying, Okta has faced major backlash.

Not notifying the breach on time and not communicating properly to the customers whose data have been compromised can seriously impact the company's reputation.

In the event of a data breach, the controller must notify the authorities within 72 hours about the data breach incident unless there is no reasonable risk to the data subjects. In addition, if there is a high risk to the affected data subjects, then in such cases, data subjects should also be notified.

This is a significant undertaking for any organization, as it necessitates exploring and implementing a comprehensive containment strategy.

4. Take Responsibility for the Cloud Services You Use

It is rather assumed that because you are paying your cloud service provider for their services, it is their responsibility for what happens to your data.

The cloud service provider is responsible for keeping your data safe, but the company takes the bullet if a data leak happens.

How security is handled in the cloud is a shared responsibility of both the contractor and processor- and that is enforced via contracts (who is responsible for an XYZ and what they should do to prevent that).

Having adequate safeguards in place for the use, processing, storage, transmission, and destruction of data is essential.

To ensure that your SaaS vendor has adequate safeguards and is living upto the contract, have their regular due diligence for security controls and compliance measures.

Performing regular due diligence at your end is also important. If the security and compliance measures in question do not meet your ideal standards, you can put remediation measures on your own end. Otherwise, look for a different vendor.

5. The End Points are Not Secure

The Okta event has prompted SaaS providers to have a more in-depth conversation about how they should give the least privileged access to the admins, particularly those belonging to third parties.

The computers or endpoint devices your employees use to connect to cloud apps get hacked, then hackers can easily get their hands on the stored credentials and can easily access SaaS applications and cloud workloads.

When you look at these weaknesses, you can see that they are not as bad as an unpatched vulnerability or a badly set up policy. You can't just click a button to get rid of them, and they aren't caused by bad security practices. Instead, they are a part of the infrastructure of any modern IT environment.

6. Prepare an Incident Response Plan

A cybersecurity incident response plan is a collection of tools and procedures that the security team can use to detect, eliminate, and recover from cyber threats. It is designed to help your team respond swiftly and uniformly to any type of external threat.

Plans for incident response guarantee the most effective responses possible. These preparations are necessary to limit the effects of cybercrime and data loss.

7. Have an Approval Process When a New Application is Added

If a threat actor has access to the SSO platform, they can add a malicious app or replace an existing one.

Malicious apps can abuse the delegated permissions assigned to them after getting the user's content.

For e.g., a malicious app can request to access read email or request cloud-based storage. So there should be an approval process when a new application is installed in the SaaS landscape.

8. Implement the Necessary Technological Safeguards

Controlling who has access to what and how the cloud resources are being accessed are really important to keep the data safe and secure.

Both you and your SaaS provider should have sufficient access controls in place to ensure that attackers do not get any opportunity to cause harm.

Every organization should employ the principle of least privilege. So that only the minimum necessary rights should be assigned to the requester and only for the shortest duration necessary.

It is very important to implement the following:

• Privileged access management system
• Zero-trust models
• Multi-factor authentication
• Encryption
• Remote wipes
• Just in time access
• Keeping credentials unique and complex and frequently changing them
• Credential Rotation

There will never be a single approach to managing security risk; it is all about taking a multi-layered approach.

Use Zluri to Take Control of SaaS Threat

Zluri is an all-in-one platform for IT teams to manage SaaS apps. It helps you find, manage, control SaaS spending, secure, and comply with 3rd party SaaS apps from an intelligent command center.

Zluri has taken all the steps to protect your sensitive information seriously against modern-day cyber threats, secure your SaaS environment, and help you stay GDPR, HIPPA, SOC 2, and PCI DSS compliant.

Zluri can assist customers in fulfilling their obligations as data controllers by:

• Providing a platform for discovering, managing, securing, and optimizing SaaS applications.
• Keeping you in control of SaaS purchase, renewal, and disposal.
• Discover Shadow IT.
• Supporting customers in complying with requests from Data Subjects.
• Aggregating applicable personal data for customers replying to requests from Data Subjects.
• Replying to investigations and inquiries from supervisory authorities concerning processing activities on behalf of a customer.
• Conducting Data Protection Impact Assessments.
• Alerting instantly whenever a risky application enters your SaaS stack.
• Block or terminate them and prevent your organization from malicious apps and users.

Book a Demo