Okta hit by third-party breach, stealing employee data | Hacker News Reader

Okta hit by third-party breach, stealing employee data

arstechnica.com

202 pointsBrajeshwar89 comments

What a misleading and click-baity title choice by Ars Technica.

This had nothing to do with Okta's platform, as implied. A third-party Vendor Okta used for health insurance information was breached, and personal information on Okta employees was stolen.

I'm disappointed in Ars Technica, and Dan Goodin.

edit: Updated to be more specific about what part of Okta this had nothing to do with.

Okta (or any company) can't outsource its responsibility when it outsources to a supplier.

If Okta printed all that personal data and left it in a box on the street they would be liable.

Ok, but that's not what the article says. It says Okta was breached. Okta was not breached.

It says Okta was "hit by" a breach, which it was. A breach happened, and Okta was impacted. Furthermore, it happened to data which Okta is ultimately responsible for, and Okta should be held responsible for their choices which led to their employees' data being stolen.

I'm not sure why you're splitting hairs on this.

"another" is the weasel word

It implies this breach is the same as the previous breach, which it's not.

Ars has gone to shit over the last decade.

I don't think I agree that the use of the word "another" implies that the breaches were equal, but I can see why others might interpret it that way.

I won't disagree with opinion on the quality of Ars' reporting or this particular article, but I do disagree with the original comment's statement that "this had nothing to do with Okta".

Without knowing the context, I doubt anyone reading the title is thinking "maybe they mean another breach where Okta is impacted but Okta is not the culprit, despite recent events". No, the title is simply misleading. They could have swapped Okta for another company's name or something like "Personal information stolen in healthcare company breach", and the news likely wouldn't get much attention, which is as much as what the article is actually worth. Singling out Okta among many of that company's clients is simply meaningless and wrong and does nothing other than attention grabbing.

Immediately what I thought when I read it.

The person you’re responding to is being obtuse to the point where it feels like trolling or contrarianism for the sake of contrarianism. Certainly a bad-faith argument.

> but I do disagree with the original comment's statement that "this had nothing to do with Okta".

I could have probably phrased this as "this had nothing to do with Okta's technology."

Because context and sentiment matters. By your logic clickbait is perfectly fine and we should maybe do more because they are (usually) technically correct.

Just continue reading the title all the way to the end? I know it's a long haul but come on, we can't just stop at the first bit of punctuation:

> Okta hit by another breach, this one stealing employee data from 3rd-party vendor

It's clear a breach has affected Okta employees.

It says Onta was hit by a breach, Okta was hit ny a breach, it even says that is was a third party vendor. That's exactly what happened.

The problem is the article is farming clicks by piggie backing off of the very recent and public breach Okta had. I don't know if there's a term for this, but it's clear to me they're abusing oktas name.

Re-read the above comment.

Okta the company had a breach.

Okta the platform did not.

Employee data vs customer data

Maybe someone is short selling.

The truth is usually less exciting.

Someone(s) almost certainly (are), not necessarily relatedly (to the article, to the breaches, yeah absolutely), what a pointlessly vague thing to say.

The concept of journalists trading on the news they break is coincidentally making waves right now with this new startup called Hunterbrook[^1]. I assume that outright misleading headlines won't be something they'd risk, but it's an interesting concept, since, yeah normally this is something you'd accuse someone of, and not expect that to be the whole point.

[^1]: https://www.ft.com/content/3c861c6c-87be-459d-b62f-b44bf2d75...

https://www.rightwayhealthcare.com is the company mentioned in the article. Okta is shown as a customer on the website, and the company's marketing says "Our members love using Rightway". There is zero mention of security on their website that I see, but the website is entirely marketing and self-congratulatory. I would expect that other Rightway customers were likely also affected, but they had no comment mentioned in this article so how wide the breach was is unknown. Okta is a well-known company so that's why this article focused on them, which is not the real story, but I guess like you said clickbait.

Okta is promoting Rightway as a benefit of Okta: https://rewards.okta.com/us/healthcare/medical/rightway-heal...

Honestly Ars has really fallen in the past few years.

ARS commenters seem to have created a very specific kind of echo chamber and they guard it passionately, fiercely rebuking any and all dissenting opinions into oblivion. Sadly, ARS writers seem motivated to cater these folks' predilections. Sometimes it seems like they write articles with little purpose other than to provide grist for their beloved mob's mill. Perhaps these journalists are rewarded for 'high audience engagement.'

So glad HN hasn't devolved into that. Gratitude to the mods here.

Thanks. I've belatedly changed the title above.

Connecting a few dots why, while the headline seems misleading, it might matter.

1. Okta employee PII and foreign key to employee health info (a particularly sensitive class of PII) may be exposed.

“On October 12, 2023, Rightway informed Okta that an unauthorized actor gained access to an eligibility census file maintained by Rightway in its provision of services ...”

https://www.documentcloud.org/documents/24110001-okta-indivi...

The file contained the following information on current and former Okta employees and their dependents:

- Full names

- Social Security Numbers (SSNs)

- Health or Medical Insurance plan number

2. Okta and its customer pool are known to be under an aggressive series of phishing and social engineering attacks.

3. This type of information makes those attacks more effective.

So while this particular breach starts as a Rightway problem, the nature of what was taken puts Okta itself at additional risk, as attackers build their social engineering / phishing dossier while looking for ways to get into Okta and/or get to Okta's customers in bulk.

Thanks for this. Posts like this are why I like Hacker News. This is a valid problem for Okta, and I think accurately frames the problem.

Real-talk, if you were calling the shots at Okta, what would you do here?

Enforce hardware-key MFA everywhere, for every vendor service? Impose a no-professional-social-media policy for all employees? This probably is too late to do any good, but it's pretty clear phishing is a hot vector right now.

Good question.

From their incident report yesterday it looks as though Okta started by blaming the victims, taking half a month to realize Okta itself was the problem. Then they clamped down on Chrome's automatic exfil of company credentials.

https://sec.okta.com/harfiles

That feels narrow.

What seems evident, but not addressed, is their initial reaction of victim customer blaming, the identification of suspicious behavior by multiple different customers before seeing it themselves, and the previous latitude for Chrome, likely trace back to lax culture and behavior, particularly around insider threat: not behaving as if they really believe "the problem is us".

So, address the specific faults as Okta did, but attribute those to a 'root cause' need for a stronger 'security mindset' with active insider threat modeling across all employees and roles, and insider focused detective controls.

Something like, "We spend all our time helping less secure customers level up their security and it's easy to feel good about how much more secure we are than most. But we ourselves don't have to be just better than our customers which probably seems easy. We have to be better than the threats who want to use us against our customers, and that's incredibly hard. Clearly we can do better."

Then double down on security mindset training (for customers to be secure, we have to be secure), and as part of that do comprehensive insider threat modeling and tabletop exercises across roles (even janitors or receptionists), with internal incentives to identify frictionless 'detection and response' controls opportunities across processes and systems.

In parallel I'd pick a new red team pen test firm (more than one, with different strengths and different cultural backgrounds outside US, e.g. Eastern Europe, Israel, Asia), adding a bonus above the standard fixed bid for every avenue identified.

But for the biggest backlog of things to fix, I'd have them do a round inside, with privilege. No room for the idea "if they're inside we already lost" since they will get inside. If I don't know to prevent things like what the insider pentests find, could I at least have seen those types of things?

We need to hear less whack-a-mole prevention in breached firms' writeups, more recognition of insider vantage threat, with visibility and detection.

- - -

TL;DR: Think through: (1) How do we become more worthy of trust. (2) How do we make trust irrelevant?

Not really Okta's fault here, just so happened that Okta was a client of this benefits company. Still, not a good look for Okta.

Does that matter, though? The message I get is that Okta isn't good with security, and they're not good at choosing vendors who are good with security.

Yes, context matters. If you discount every company that might be impacted by a third-party breach of employee data, you will be left with no vendors. At some point you have to decide what is acceptable, and have insurance/indemnity for the risks.

I would not discount Okta because of a decision made by HR.

Most large companies vet their vendors to some extent. It's hard to know if that happened in this case or not, but it's still part of the normal procurement process to perform a security review. These reviews have varying levels of security requirements depending on what type of PII will be stored or processed. Considering this breach included SSN's I'd have expected this to be one of the more thorough reviews.

Those "assessments" amount to sending over a document that says

    1. Are you secure?
    2. Are you secure?
    3. Are you secure?
    4. Are you secure?
    ...
    37. Are you secure?

and the company sends back

    1. Yes.
    2. Yes.
    3. Yes, definitely.
    4. Oh yes.
    ...
    37. Yes.

There's a lot more words, but not necessarily a lot more value in those words then what I have here. Some, I admit, but not necessarily a lot.

Maybe at the high government end a real assessment is done where the experts of the client's choosing go into the provider's actual environment and makes a real assessment. But from what I've seen it's self-reporting the vast majority of the time, and the provider could honestly believe they're running a tight ship and not realize there's one setting in one AWS account that's just a bit too open and oh no my database. (Or perhaps rather "oh no your database".)

Another way of looking at it is that if a company doesn't truth you to answer truthfully, why are they choosing you as a vendor?

Presumably you'd be lying about the thing they'd be buying too, or innumerable other things.

And 'subsequent lawsuit' is usually a powerful motivator to be honest.

The next layer of cynicism down is more complicated. I'm going to make this up to protect the guiltocent, but I've been on the receiving end of security assessments that ask the moral equivalent of "Do you salt the MD5 hashes you use to store password hashes?" and we end saying Yes in some large number of words because we use bcrypt/scrypt properly, or some industry SSO, or our systems communicate with an internal CA TLS authority where "passwords" aren't even in sight, or whatever other solution leaves salted MD5 in the dust.

It's literally a deal breaker to send back No, so there's a lot of incentive to do what it takes to send a Yes back.

And "subsequent lawsuit" is a very distant threat in this case.

Less cynically, there are some standards that do have some non-zero teeth in them. Some audits are challenging and at least rate "a good exercise". But that's what I mean by even if the vender truly believes they are compliant with ISO-Thirty-Three-Million-And-Two-Subrevision-A24, they're just one error away from ohnoyourdatabase anyhow.

The net-net of it all is that, as I sort of alluded to, are these assessments worthless? I mean, no, not quite literally zero. If you send one of these documents to a startup of two dudes and a cat and they claim ISO-Thirty-Three-Million-And-Two-Subrevision-A24 compliance, they're lying and the person examining their assessment at least has a chance to be suspicious about it. But in real terms, are they going to be the difference? Unlikely.

Or, let me put this another way. I would bet substantial money Okta has in their possession a response to their questionnaire from Rightway Healthcare in which Rightway Healthcare sings the praises of their immense, extraordinary, back-breaking, industry-leading security efforts, complete with citation of the relevant industry standards they comply with, and that it looks as good as anyone else's answers.

Yet, here we are.

Yeah. This is what always trips engineer-types up when dealing with legal. A contract isn’t code. There is usually, on both sides, a certain degree of BSing that goes on. Put another way, both parties are usually knowingly taking on risk associated with non-compliance. “We meet the security requirements in spirit only” is easily one of the more tame instances of this.

It's not that clear cut.

A contract is a probabilistic promise.

According to the writer's understanding of the law (and the risk tolerance they have for being caught) these are the terms they're putting to paper.

Generally, that means the writer's legal team feels confident that if everything goes sideways and they're standing in a courtroom, they have the best possible chance at winning the case with the language they used.

Now everyone around legal (e.g. sales, marketing, product, etc.) likely has different incentives. But the entire reason legal is somewhat firewalled is because they're the ones thinking about that future courtroom.

So it's less "there's a certain degree of BSing" and more that sometimes sales gets their preferred language and sometimes legal wins.

And of course, sometimes neither of them know relevant technical details and both their proposals are jibberish.

Self-assessments are definitely an option some companies use, but there is a middle ground between a full assessment conducted by the customer and a self-assessment. ISO, SOC2, etc. all provide what I would consider to be better than a simple self-assessment as they require a third-party audit. They aren't anywhere close to perfect but they are significantly better than a self-assessment IMHO. There are no guarantees, of course.

I think you haven't seen enough. Self assessment is a great start. I've seen companies demanding their vendors to go through pentesting from several different pentesting companies, and then addressing all high-severity issues to the satisfaction of the pentesting company before officially allowed as a vendor.

Naturally you still have to trust the pentesting company to do a good job but it's better than just a self assessment.

I'm discounting a security company with several recent high-profile security incidents. As somebody that implemented Okta for a bank, for both customers and internal personnel, I am very concerned.

EDIT: Before you defend Okta, tell me why it took three weeks for them to disclose this breach to their own employees? If they're dragging their feet for their own employees, and given Cloudflare's recent experience, why should I trust Okta at all?

> Okta learned of the compromise and data theft on October 12 and didn’t disclose it until Thursday, exactly three weeks later.

I would.

A critical part of having a robust security program is having an effective third party risk management program which evaluates all third parties that you do business with and holds them to high security standards. Okta is the ultimate party that is responsible for protecting this data, and that still remains true even if they subcontract out the protection of that data. If you aren't doing third party risk management, then it calls into question what other critical parts of security you're failing at.

For a company like Okta, which supposedly is a "security" company, to have _repeated_ security failings like this should make everyone question them.

Okta isn't just any random company though. Employee data can be used for targeted attacks, and Okta is a significantly more interesting target than most other companies.

As such I would expect a company like Okta to take much more care about which 3rd party solutions they use.

There are two types of people, people who take responsibility for things that aren’t directly their fault, and people who regularly experience negative outcomes.

Okta chose this vendor and they chose to have them store this data. They probably even have security requirements in their contract with them. They could have prevented this. And when you present yourself as a security company, you’re expected to.

There are two types of people, those who express everything in dichotomies, and those who don't, and those who start indexing at zero.

People who start indexing at 0 still say that {0, 1, 2} has 3 elements, not 2. ;)

> “The types of personal information contained in the impacted eligibility census file included your Name, Social Security Number, and health or medical insurance plan number,” a letter sent to affected Okta employees stated. “We have no evidence to suggest that your personal information has been misused against you.”

That seems like a pretty ridiculous statement. Is it supposed to be reassuring or something? Like, obviously Okta has no way of knowing whether or not their employees PII, having been leaked, will be exploited, and when it does get exploited, it almost certainly will be the employees who find out about it, not Okta.

Sounds like the statement is referencing the past not the future. I think it’s a reasonable thing for them to say: this was stolen, and that sucks, but perhaps a little reassuringly we haven’t detected this being misused. idk.

To the extent that it is reassuring, it is misleading, right? Unless they have some way of being reasonably sure that the fact that they haven’t detected misuse implies that it hasn’t happened.

I think there's probably a legal reason that's included, as it's in all info leak announcements I've seen.

It seems like the most reassuring/misleading thing that can be said without technically lying.

Or there's a legal responsibility to disclose if you know anything? So everyone has to explicitly say they don't?

IANAL, so not sure.

That it's always included and worded exactly the same makes me suspect legal instead of PR.

I don’t know why people are all pretending like this is irrelevant to Okta's security.

An employee list like that is a goldmine for all sorts of social engineering and phishing attacks.

It’s not that it isn’t relevant, it’s the clickbait-y headline and insinuation that Okta itself was compromised again. Any major company using third-party vendors would be in the same position (and for all we know, this healthcare company provided services to multiple other companies). Fault Okta for not doing enough vendor due diligence, sure, but don’t use clickbait to imply Okta itself was breached.

The real takeaway for Okta in 2023, if they didn't know it already, is they are dealing with nation state threat actors, and if they think they are over-investing in security, they probably aren't.

Be it as it may, it does not really matter, whether it came from a Okta database or of any other company. It further compromises Okta's security which is pretty bad because being secure is basically their primary service proposition.

Firstly, the title literally does what you're asking:

> Okta hit by another breach, this one stealing employee data from 3rd-party vendor

You have to read the whole thing.

Secondly, let's assume you were right and the title was simple "Okta hit by another breach" and there were no other words.

Do you not view it as problematic that the company has in two months had a major compromise of its own services via phishing, as well as that of a company supplying health-related services to its own employees? Do you not view that as potentially hazardous and concerning?

They chose this company. Effectively, they vetted this company and believed them to be doing things in a way that was secure for their employees. If that vetting process is terrible, then it speaks to how organization-wide the issues there are.

If this is directly related to negligence at Okta or not (which seems like it’s not in this case) doesn’t really matter when “Okta” and “Data Breach” seem to show up close together in headlines a lot.

Rough task for people tasked with holding together the “brand”

It'd be more forgivable if they weren't so bad at listening to their customers when they report things, technical or security related.

The best thing Okta has going for them right now is that a lot of these companies are so bloated and slow that changing platforms takes a long time to pull off even the initial agreement that they'll be changing, so they have plenty of time to let things settle even if you're mad at them because switching everything to a new idp is "just not something the business can prioritize right now"

They probably look like hot garbage to customers shopping around but I'd venture with most existing clients over a certain size they'll just ask them for a statement they can email out then the Okta sales guys will treat a few directors to happy hour and a ball game, delaying the long process of being dumped from even starting.

Again? Does anyone keep a list of all their breaches and hacks? The one on wiki doesn't seem complete https://en.wikipedia.org/wiki/Okta,_Inc.#Security_incidents

A friend of mine jokingly told me they got a "confidential" report from Okta today that apt actors were up in them for 3 weeks. I wonder who all else got this, said friend is at a high-profile enterprise/retail account for them.

For a moment I got scared. But then I got angry at the clickbaity title.

Did anyone read the article? It's literally not a compromise of Okta. It's a compromise of a healthcare provider that Okta is a customer of. Has absolutely nothing to do with Okta's products, at all, whatsoever.

This is bordering on yellow journalism. I am all for giving shitty companies their due when they fuck up, but that's not what this is at all.

I guess we have to decide if as customers, our security is treated better or worse than their employees'.

> We have no evidence to suggest that your personal information has been misused against you.

What a fucking horribly disingenuous statement. They are trying to say that nothing bad happened, but their SSN and information was stolen!! The information is going to be sold and at a later date it could be used. But they're not saying that, they're trying to say "Nothing to see here, your information wasn't misused so don't worry!" I would never trust them after giving this statement.

Not to discount your point- you’re right it’s so disingenuous.

BUT we’re quickly approaching a world where every American has been in a leak that affects their data and SSN. Not 100% of course (simply because young people haven’t had a chance to be screwed over) but at some point we should assume that the information is public for a large enough portion of the population and we need to set new expectations.

> we’re quickly approaching a world where every American has been in a leak that affects their data and SSN. Not 100% of course (simply because young people haven’t had a chance to be screwed over)

… that number, presently, has to be a rounding error from being 100%. My SSN was first breached when I was in high school, at least.

But yeah, I agree, we should set new expectations. There could definitely be a better system, and I would like to see companies held to account, but material fines against corps are basically unicorns in America.

We need a bunch of case law indicating that banks and credit card companies that don’t authenticate past this widely leaked PII are on the hook for the loss of money (rather than the uninvolved third parties who are being impersonated).

This is already the case. You have to prove you weren’t involved (a quick police report will do), but you’re expected to be made right already. Banks have just deemed this current level of fraud acceptable.

Currently, if Mallory finds Alice’s SSN and opens a credit line at Lazy Bank Corp, and then runs up a bill in Alice’s name, Alice will be assumed responsible. It’ll affect Alice’s credit score, etc when the banks report these balances.

If Alice notices these changes, they can submit a letter to the bank, demanding that the bank remove these reports and close the account (Fair Credit Reporting Act?). The bank can say “but we have the SSN of Alice, so it’s Alice’s” but if Alice can prove they’re not responsible -through lawyers or strongly worded letters or otherwise- (“I don’t and have never lived at the address on file, that IP address originated from Belarus, etc”) then the bank is legally required to remove the association between Alice and that debt. Note that filing a police report is like “auto winning” because it’s a crime to lie to the police.

I think the real question is what’s the actual harm on a society level in not validating further? We already have a process to undo the harm on an individual level, but do we need more onerous procedures?

The bigger question for me is, "why is my SSN still such a valuable bit of information"

We, the IT industry, have demonstrated repeatedly that we are not smart enough and/or not diligent enough to consistently protect this information. I think we should admit that and try the reverse approach: make knowledge of our PII worthless for committing fraud and theft. We need to fundamentally shift our methods of proving identity to something that doesn't rely on keeping a 9-digit number a secret.

This is the dangers of a too-powerful bureaucracy.

It's obvious that having the SSN as a single point of failure is exceedingly stupid, but our government bureaucrats refuse to do anything about it. You can't even request a new SSN, it's practically impossible to get a new one even if your identity is stolen.

The only thing holding us back is red tape, which is the dumbest reason of all.

It's the danger of using something as a universal password (terrible practice #1) that's often stored in plain text (terrible practice #2).

I don't regularly deal much with federal government agencies beyond the IRS. Which ones let you do nefarious things if you only know a person's name, address, and SSN? The IRS doesn't, because they require you to know info from what you filed last year.

It probably seemed a lot more reasonable back when most people’s exposure to “password” was “the thing you needed to get into the speakeasy.”

That’s a bigger questions, and it is a good one, but practically it is not really relevant (other than, I guess, Okta’s vendor has made a small contribution to making it obvious how ill suited these numbers are for authentication).

Because the US has a political aversion to centralized IDs at the federal level, but an identity provider of some sort is necessary for lots of business interactions.

But this kind of statement is the unfortunate industry standard. A more honest thing to say would be to say "there is no way to prove that your personal information has been or may yet be misused against you, and as such you should take the following steps to minimize risks [...]".

But compare how that looks compared against the bigger players which can afford to treat their weekly apocalyptic security incidents like it's just a bad weather phenomenon we just have to accept, apply a patch for and move on.

Reading the article, it says Okta and its employees are the actual victims here.. couldn't be more misleading..

A whole lotta nothing. Unless you are an Okta employee.

Or unless you're someone who depends on Okta employees' security to keep yourself secure.

Which has been a problem, and this enables being more of a problem.

Okta is so lame no wonder is so popular among corporate mediocrity.

Out of interest - what makes you say this? I'm not disagreeing, just want to understand the general (and seemingly commonly held) belief that they suck.

They have lots of ready to go connectors which makes it easy to integrate lots of apps instead of figuring out all the SAML settings... but any SAML provider will work as long as you can map the right fields. But people like easy things and Okta makes it easy. Many apps who don't have a connector will have docs on how to set things up with Okta, for others you'll have to take the Okta instructions and figure out what that means for an alternate provider. There are other things like counter-signatures which may be easier to do with Okta but also possible with others, if you have the right docs.

Thank you.

Ok another question - where do you see Cerby fitting into that mix?

I'm a bit confused, this seems like a list of pros or at least neutral things?

People use them because they are easy to use, on the other hand their security issues over the past few years could make clients consider alternatives.

As far as SaaS SSO providers go, I think they're pretty cool. But all the breach related news lately has me wondering what the best alternatives are. You sound like you would have opinions.

What is your preferred alternative?

Out of interest, why would you not just use the directory services that you get bundled with google workspace, azureAD (Now: Entra) or freeipa/keycloak?

All of these support oauth2 and SAML, and dynamic groups for less than the cost of each and okta (it seems to be the case everywhere I have seen okta used, another of the above providers is used additionally).

If you have AzureAD you don’t typically also have Okta. Also the features you listed are like 20% of Okta’s functionality here.

If you have office licenses you have AzureAD. Lots of places have office licenses for all of or most of their employees and still have Okta.

AzureAD licenses near the feature equivalent of Okta are much more expensive than base office licenses that only give you access to the office apps and cloud storage.

I kind of wondered the same thing the last time they were hacked... someone answered with this:

"Okta: comprehensive scim allowing your IT instead of random application admins throughout your company to manage user provisioning / deprovisioning. Start pages that don't require users to remember urls but instead show them a list of applications they can use. Adaptive MFA with IT-administered settings (though Google's super-enterprisey solutions may have sth here.)"

https://news.ycombinator.com/item?id=37995670

Personally, I just go with the Google Workspace and call it a day. Start page is one of those nice to have, but not required features in my book.

Reply on news.ycombinator.com