LESSON-OF-THE-DAY: Companies Finally Face Consequences for Alleged Cybersecurity Lapses... POSTMORTEM BUCK PASSING | Ars Technica

Okta’s lack of visibility into its network is another failing that, while not a cause of the breach, allowed it to be much worse than it would have been had the access been spotted sooner.  

No, Okta, senior management, not an errant employee, caused you to get hacked

If a transgression by a single employee breaches your network, you're doing it wrong.

DAN GOODIN - 11/3/2023, 5:31 PM

Enlarge

Omar Marques/SOPA Images/LightRocket via Getty Images

156WITH

Identity and authentication management provider Okta on Friday published an autopsy report on a recent breach that gave hackers administrative access to the Okta accounts of some of its customers. 

• While the postmortem emphasizes the transgressions of an employee logging into a personal Google account on a work device, the biggest contributing factor was something the company understated: a badly configured service account.

In a post, Okta chief security officer David Bradbury said that the most likely way the threat actor behind the attack gained access to parts of his company’s customer support system was by first compromising an employee’s personal device or personal Google account and, from there, obtaining the username and password for a special form of account, known as a service account, used for connecting to the support segment of the Okta network. Once the threat actor had access, they could obtain administrative credentials for entering the Okta accounts belonging to 1Password, BeyondTrust, Cloudflare, and other Okta customers.

Passing the buck

“During our investigation into suspicious use of this account, Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury wrote. “The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”

This means that when the employee logged into the account on Chrome while it was authenticated to the personal Google account, the credentials got saved to that account, most likely through Chrome’s built-in password manager. Then, after compromising the personal account or device, the threat actor obtained the credentials needed to access the Okta account.
Accessing personal accounts at a company like Okta has long been known to be a huge no-no. And if that prohibition wasn’t clear to some before, it should be now. The employee almost surely violated company policy, and it wouldn’t be surprising if the offense led to the employee’s firing.
However, it would be wrong for anyone to conclude that employee misconduct was the cause of the breach. It wasn’t. The fault, instead, lies with the security people who designed the support system that was breached, specifically the way the breached service account was configured. . .

READ more >> Ars Technica