Omar Marques/SOPA Images/LightRocket via Getty Images
Identity and authentication management provider Okta recently experienced a breach that granted hackers administrative access to the Okta accounts of certain customers. Okta’s chief security officer, David Bradbury, published an autopsy report on the incident, attributing the breach to an employee logging into a personal Google account on a work device. However, the root cause of the breach was actually a poorly configured service account.
In the post, Bradbury explains that the threat actor likely gained access to Okta’s customer support system by compromising an employee’s personal device or Google account. From there, they were able to obtain the credentials for a service account used to connect to the support segment of the Okta network. With administrative access, the threat actor could enter the Okta accounts of customers like 1Password, BeyondTrust, and Cloudflare.
Deflecting Responsibility
Bradbury points out that during the investigation, Okta discovered that an employee had signed into their personal Google profile on a Chrome browser installed on their Okta-managed laptop. The service account’s username and password had been saved in the employee’s personal Google account, and the compromise likely occurred through the employee’s personal device or Google account. While the employee violated company policy, it is incorrect to solely blame them for the breach. The real fault lies with the security personnel responsible for configuring the breached service account.
Service accounts are typically used for machine-to-machine functions and cannot have multifactor authentication. However, Okta should have implemented additional access controls, such as IP address restrictions or regular access token rotation for the service account. Employees should also never be allowed to log into personal accounts on work machines. These precautions are the responsibility of senior individuals within Okta.
Okta first became aware of suspicious activity on September 29 when 1Password reported a compromise of their Okta instance. While Okta initially suspected a malware infection, they received another report on October 2 from BeyondTrust, confirming a customer account compromise. The source of the breach was not identified until October 16, allowing the threat actor to maintain access to the service account for over two weeks.
Okta’s lack of network visibility, while not the cause of the breach, exacerbated the situation. The breach could have been mitigated earlier if the access had been detected promptly. Bradbury acknowledges these shortcomings in the remediation steps outlined in the post.
Moving Forward
In conclusion, Okta deserves credit for implementing changes and providing a timeline of events. However, their attempt to blame an errant employee deflects responsibility from senior management, who were ultimately responsible for the security failings. It is crucial that these higher-ranking individuals address the real issues highlighted by the breach. Hopefully, they take heed of the lessons learned.
