4 ms·

This is the downside of centralized Identity Providers, they become a more and more tempting target the more people that use them. EDIT: Update after looking

This is the downside of centralized Identity Providers, they become a more and more tempting target the more people that use them. EDIT: Update after looking through the article the important bit is >In an advisory sent to an undisclosed number of customers on Oct. 19, Okta said it “has identified adversarial activity that leveraged access to a stolen credential to access Okta’s support case management system. The threat actor was able to view files uploaded by certain Okta customers as part of recent support cases.” So it wasn't a full breach so much as someone was able to get in and view the support tickets customers have opened. Which although bad isn't nearly as bad as losing a bunch of people's keys. (again)

deleted 3y ago
[deleted]
richbell 3y ago
Viewing files uploaded to support tickets is still a scary prospect. I doubt Okta can say with 100% confidence that no confidential data or credentials are uploaded to their support portal.
spatley 3y ago
Sure, not as catastrophic as getting prod root keys directly, but the breach was detected by an Okta customer that found a bad actor using session cookie data the was provided to Okta by their user in a support incident. It is nearly certain that sometime in that 15 days a bunch of Okta customers got breached and are infiltrated now without their knowledge.
- albert_e 3y ago
  the malicious actor likely had access to Okta support systems for much longer and was able to use HARs and also other information from other Okta customers undetected till they walked into a customer that was alert
samtho 3y ago
Regardless of the impact of this breach in particular, your point still stands and is one I do share: this is a major downside to centralized identity providers. Their existence creates a centralized point of access that all an attacker must do is bypass once for some sort of benefit. “Security” as a practice within a company comprises of technology, process, and culture. Should one of these pillars be subverted by leadership in anyway, the organization security stance becomes crippled. In my experience, this security kneecapping happens because some bonehead exec looks at ways to cut costs or doesn’t like having to pull their phone out to login, and decided on a layoff or loosening of policy because, “we haven’t had any problems so far, so why do we have these staff members or this highly obstructive 2FA in place?” I mean, people used to die with greater frequency in car accidents prior to seat belts, too, maybe we can eliminate those next?
- sophacles 3y ago
  > process, and culture Are possibly even more important than the tech. A good culture of "always report suspicious things, no one will be upset over false alarms" and a process that follows up on each report with rigor and responds to the constant stream of false positives in an engaging and encouraging way[1] catches a lot of problems before they start and/or are in the early stages. I've witnessed and heard stories of such cultures and policies catching pretty sophisticated targeted phishing campaigns with 0 breach. Similarly even for actual compromise - having a "always tell us when you suspect something, if you click on a bad link and report it when you realize it you won't get in trouble" means that breaches can be stopped early (again I've seen this prevent incidents from turning catastrophic). It's cheaper to spend a few $100K on more people to handle false positives than it is to lose millions in direct costs from a breach and even more millions on reputational loss. [1] e.g. "We examined the email and link you sent. Thank you for reporting it - it does in fact look suspicious, but in this case we've verified it's the a safe and legitimate link. Please continue sending in anything you're unsure of!"
starkparker 3y ago
Having worked support for an infra company that requested similarly sensitive information, it is _wild_ to me that: - customers wouldn't scrub sensitive details from support HARs, unless those details were required for the issue - if customers weren't required to submit sensitive details, that Okta support wouldn't have a tool to scrub any accidentally included from the support system (looks like it's SFDC-backed) - if sensitive details were required, that Okta support didn't have an extremely tight data retention policy, in terms of hours not days, with active enforcement These kinds of things were hard requirements just as presales demands from fintech and healthcare customers, much less for certification.
- albert_e 3y ago
  breach happened within 30 minutes of the HAR being uploaded

deleted 3y ago

[deleted]

richbell 3y ago

Viewing files uploaded to support tickets is still a scary prospect. I doubt Okta can say with 100% confidence that no confidential data or credentials are uploaded to their support portal.

spatley 3y ago

Sure, not as catastrophic as getting prod root keys directly, but the breach was detected by an Okta customer that found a bad actor using session cookie data the was provided to Okta by their user in a support incident. It is nearly certain that sometime in that 15 days a bunch of Okta customers got breached and are infiltrated now without their knowledge.

albert_e 3y ago
the malicious actor likely had access to Okta support systems for much longer and was able to use HARs and also other information from other Okta customers undetected till they walked into a customer that was alert

samtho 3y ago

Regardless of the impact of this breach in particular, your point still stands and is one I do share: this is a major downside to centralized identity providers. Their existence creates a centralized point of access that all an attacker must do is bypass once for some sort of benefit. “Security” as a practice within a company comprises of technology, process, and culture. Should one of these pillars be subverted by leadership in anyway, the organization security stance becomes crippled. In my experience, this security kneecapping happens because some bonehead exec looks at ways to cut costs or doesn’t like having to pull their phone out to login, and decided on a layoff or loosening of policy because, “we haven’t had any problems so far, so why do we have these staff members or this highly obstructive 2FA in place?” I mean, people used to die with greater frequency in car accidents prior to seat belts, too, maybe we can eliminate those next?

sophacles 3y ago
> process, and culture Are possibly even more important than the tech. A good culture of "always report suspicious things, no one will be upset over false alarms" and a process that follows up on each report with rigor and responds to the constant stream of false positives in an engaging and encouraging way[1] catches a lot of problems before they start and/or are in the early stages. I've witnessed and heard stories of such cultures and policies catching pretty sophisticated targeted phishing campaigns with 0 breach. Similarly even for actual compromise - having a "always tell us when you suspect something, if you click on a bad link and report it when you realize it you won't get in trouble" means that breaches can be stopped early (again I've seen this prevent incidents from turning catastrophic). It's cheaper to spend a few $100K on more people to handle false positives than it is to lose millions in direct costs from a breach and even more millions on reputational loss. [1] e.g. "We examined the email and link you sent. Thank you for reporting it - it does in fact look suspicious, but in this case we've verified it's the a safe and legitimate link. Please continue sending in anything you're unsure of!"

starkparker 3y ago

Having worked support for an infra company that requested similarly sensitive information, it is _wild_ to me that: - customers wouldn't scrub sensitive details from support HARs, unless those details were required for the issue - if customers weren't required to submit sensitive details, that Okta support wouldn't have a tool to scrub any accidentally included from the support system (looks like it's SFDC-backed) - if sensitive details were required, that Okta support didn't have an extremely tight data retention policy, in terms of hours not days, with active enforcement These kinds of things were hard requirements just as presales demands from fintech and healthcare customers, much less for certification.

albert_e 3y ago
breach happened within 30 minutes of the HAR being uploaded