We recently learned about a breach that impacted Okta. Although the breach was through a third-party outsourcing firm named Sykes, Okta was nonetheless impacted. According to open-source reporting, it appears that a threat actor group named LAPSUS$ gained RDP access to a laptop of a Sykes support engineer who had access to one of Okta’s internal portals. This access gave LAPSUS$ the ability to change Okta customer passwords. Okta reported that LAPSUS$ breach may have impacted 366 corporate customers. Through the timeline shared by Okta, we learned that the initial breach of Sykes occurred around January 16, 2022 and LAPSUS$ was active for 5 days before being discovered and remediated. Although Sykes was initially warned about a possible breach by Okta on January 20, 2022, Okta did not receive the forensic investigation’s initial findings until March 17, 2022 with the finalized report being delivered on March 22, 2022. Okta reported that they have reached out to the potentially impacted customers via email – it was not publicly stated when this email was sent; however, it stands to reason that it was not sent before the final report was received on March 22. The complete timeline of these events can be found here.
What this means is that over a period of weeks, Okta customers could have had their account passwords changed. Hopefully the impacted users would have noticed this but by the time they did, in an imperfect world, threat actors could have already been exploring and exfiltrating critical company assets. This is where a zero-trust environment can help. A key tenant of zero trust is that the subject (user) and the asset (laptop) have to be validated before access can be granted to the resource (company data). In the strongest zero trust configuration, the only way you would be able to access the resources is through a policy enforcement point, in our case an iboss Zero Trust SASE. This configuration allows you to restrict access to these resources to only your policy enforcement points via source IP restrictions so that even if an actor managed to get user credentials and simultaneously compromise MFA, the threat actor would still not be able to access your company resources because they are not visible to anyone who is not authorized to go through the policy enforcement point. This holds true for any assets your company owns, whether physically located in your corporate infrastructure or hosted in the cloud (Azure, AWS, etc.) as well as for cloud applications such as O365, DropBox, and others. In addition, since your resources are not accessible to the internet, attackers cannot find them through the typical web scanning process nor can they use any known exploits against them, even if you are running unpatched software.
iboss moves security to the cloud and strictly follows the Zero Trust approach as defined by NIST 800-207. The platform is built on a containerized cloud architecture, thereby making it the only platform that can control what NIST refers to as the “Implicit Trust Zone.” This verifies all resources – including those on prem or in the cloud – are completely private and only accessible through the service. As a result, applications, data, and services are protected and inaccessible without going through the iboss Zero Trust SASE. Interested in learning more about Zero Trust and how iboss adheres to NIST 800-207 standards? Download our new e-book.
Blog post authored by Jim Gogolinski, VP of Research and Intelligence at iboss.
