Funny how this article points that Okta was notified by a third-party of suspicious tenant activity, Okta did not find evidence of the breach, and only after some persistence from BeyondTrust did Okta re-investigate and identify the breach.
It's beyond my comprehension why anyone is using Okta anymore. Authentication is the most critical piece of any IT. Okta has proven again and again to be untrusted party lacking integrity. It's just a time bomb about to go off.
also vendor lock in once youre invested is very real with execs. change is hard in general its even harder when its a significantly embedded service thay takes time and money to replace plus your director likes going to sports with their sales guys.
also i sincerely believe theres a little bit of not minding they suck because they can just blame okta if something happens and blame is the worry.
It's a consequence of corporate culture that punishes failure. Part of changing is admitting the previous approach isn't working, and why it isn't working.
They could always punish the internal person who chose Okta. But I guess they're now big enough to be into "no one was ever fired for choosing [Okta]" territory?
> It's beyond my comprehension why anyone is using Okta anymore.
Because, if you are already using Okta, it costs budget to change that. Who is signing up to to do that? Didn't Family Circus used to have a ghost character labelled "Not Me"?
And, an bunch of people who didn't like Okta went with Auth0 and then wound up with Okta, anyway.
Counter question, how has Okta proven that they have integrity and are competent and can be trusted to run critical IT?
What quantitive evidence have they ever demonstrated that shows they can stop the attackers who would like access to the billions of dollars of assets whose access they authenticate? A criminal enterprise can literally hire tens to hundreds of skilled hackers full time for years to target these systems and still turn a profit.
The default assumption is that systems are easily hacked. Claiming protection against even small teams of moderately skilled attackers, let alone organized crime, is a extraordinary claim. Where is their extraordinary evidence?
So I can just give you a cardboard box and call it a vault? You can not prove me wrong upfront so you have to believe me? That is ridiculous.
There is plenty of evidence you can provide to establish confidence that a certain degree of security has been achieved. Robust auditing, thorough review, formal methods, exhaustive testing, competent red teams exercises failing to find any vulnerabilities, etc. The only people throwing their hands up claiming security can not be evaluated have nothing useful to say about security because they do not even believe it is possible to know if they did anything.
Counter argument. Okta does all those things. Provides all the evidence, the red teams, etc. and still you don’t trust them (because they continue to have breaches) so to argue that one can prove security is false. One can only practice security and find assurance in certainty that they can identify events after or when they occur. No one can predict the future and no one can guarantee security in perpetuity. So I agree with you that Okta sucks. I also agree with the argument that you have to keep the knife sharp but you can’t just state the knife is sharp. You have to draw some blood to prove it. Likewise security postures are tested when incidents occur, through testing oneself or from another testing you. Complacency in this is when holes form. Security can only be evaluated at the moment in time. You can audit the past, but you can’t audit the future.
Counter argument, prove that Okta does any of those things to any meaningful degree. They are responsible for guarding the authentication to literally billions of dollars of assets. They are a prime target for organized crime who can field teams of tens to hundreds of hackers and state actors who can field teams of thousands for years. The recent Ceasar's attack had a 15 M$ payout, which means it would have been profitable to spend 5-10 M$ of hacking resources to pull off that attack. Okta is a much juicier target. They need to have security adequate to defeat a attack with 10 M$ of funding at a bare minimum.
So yeah, show me a red team exercise with 10 M$ of funding, they get a 30 person hacking team and 1 year fulltime, that failed to find any vulnerabilities and failed to gain access to any sensitive data, then we can talk about if they provided evidence of adequate security. I bet all they have is what everybody else has which is red team exercises that had 3 people for a month that reported 27 serious vulnerabilities, then another red team exercise that found a different 23 vulnerabilities, then another, then another, then another, always finding new ones because their systems are actually at the 100 K$ quality level. Those exercises do provide evidence and confidence in their security, you can be extremely confident their systems are grossly inadequate for their threat landscape. I have not looked, but the same can almost certainly be said about their certifications, audits, etc. since the gold standard that everyone aspires to is, when looked at objectively, grossly inadequate.
No and no, but I was just providing a counter argument so we can get past our bias and get to the heart of the issue. Can we trust Okta going forward? Do they understand the scope? The risks? Or are they full of Id and Ego that they think they are untouchable?
Having red teams, having audits, having scans, etc is simply not enough for some folks but in Okta’s eyes, it’s enough for C-suite talks of taking Authentication/authorization off the plate of their IT department.
I firmly believe for every individual who thinks they are untouchable, there’s a hacker who knows more and is willing to throw it all away to prove a point.
Great, so your argument is based on misinterpreting my single usage of the word “prove” to mean the mathematical definition rather than the colloquial definition meaning substantiated as is obvious to even the most casual observer based on how my statements talk about evidence, not logical inference rules.
I mean, do you seriously think that if person A says: “My vault is secure for 15 minutes against a human with a crowbar.” And person B says “Prove it.” That person A would ever respond with: “I can not because a vault is not a mathematical object and therefore proof is impossible, but I can substantiate it.” That would be ridiculous beyond belief. That is what you are doing.
Not that I am aware of, which bolsters my point. If airsoft pellets keep ripping through everybody's "bulletproof" vests and they all keep telling you to have faith in their new vest, and no, they will not provide you any evidence that it works, then any sane person would be running for the hills. You should be completely skeptical that an entire industry that can not even stop airsoft pellets can suddenly able to stop bullets, 354th times the charm for sure, until they show you some extraordinary evidence. Fool me once, shame on you. Fool me 354 times in a row for three decades, shame on me.
It’s actually comical that Cloudflare is trying to blame Okta for this. A Cloudflare employee uploaded secrets to Okta’s support tool. That is what caused the breach.
'Malicious Okta employee' who already has privileged access in the systems the customer has chosen to outsource their auth to?
If Okta employee is a high priority threat model... then the customer is better off not using Okta.
Not that it shouldn't be considered, but if Okta top-to-bottom penetration is expected and accepted, then that's taking Zero Trust to a whole new length.
It's literally a policy from Okta to investigate issues, which isn't Cloudflare's fault. The tool from Okta got compromised and all clients that needed support from Okta could/have been damaged as well.
Additionally, it was Cloudflare that SAW something was off and notified Okta. Cloudflare didn't get breached at all.
> The root cause is that Okta got compromised.
It's even suprising that Cloudflare's policies are so good in detection that they detected this at all, before Okta.
Purely anecdotal but their systems are designed very poorly, they outsource their support to some really low quality vendor (read: you get 0 support). This is not a company I would trust if I had the choice.
I was at an org who started using Okta a few years ago (left a few months later, unrelated). Among the issues, it wasn't confidence inspiring that the policies that org set (like requiring the Okta app for 2FA rather than TOTP, or enforcing certain properties about the passwords you're allowed to use) were only enforced in the browser and could easily be circumvented by just sending an appropriate request. Maybe they're fine otherwise, but my rule of thumb is that every security-critical single-point-of-failure like Okta will have major problems, and they certainly haven't presented enough evidence to sway that opinion.
I know this is old, so I'm not sure if you'll see it, but I'm genuinely curious what alternatives you suggest.
My experience has been: start with Google until it's too painful to continue, choose between Azure AD or Okta. Self-hosting for plenty of firms is just asking for worse scenarios. Is there some market leader I'm unaware of?
My company uses Okta. Several of the lower level security employees expressed concerns and management told them to go fuck themselves. IT simply does not care. So that’s probably why - ignorance and apathy.
That title from Okta has to be the lamest in all history of security breach announcements!! "Tracking Unauthorized Access to Okta's Support System"
Horrible title, not transparent or direct, pretty lame. and I agree, it's dreadful that Okta did not even mention that BeyondTrust told them about it on Oct 2 (30 minutes after BT uploaded their HAR file to Okta Support).
> Okta’s Deputy Chief Information Security Officer Charlotte Wylie said Okta initially believed that BeyondTrust’s alert on Oct. 2 was not a result of a breach in its systems. But she said that by Oct. 17, the company had identified and contained the incident
Nothing like disclosing a hack to company that's supposedly an expert at cyber security and authentication (within 30 minutes!) only for them to tell you that you're wrong and not admit it for 15 days while a hacker runs amok.
See this blog post (linked in original article) from a security firm that was one of Okta's customers, and alerted them to the breech, when they detected suspicious activity on their network shortly after sharing the HAR file with Okta:
Amazon service just asked me to share a HAR file and I though for sure it was a security risk. Doesn’t that mean that agent has an authentication cookie to my account? Why can this be common with practice
Yes, modulo your session durations and, for services which implement it, IP fixation. You should treat HAR files as secrets for anything involving a login.
The post glossed over how exactly they detected session hijacking. They mentioned “This detection looks for suspicious sessions appearing without an authentication event that are consistent with session hijacking.”, but authentication obviously happened at some point, otherwise the session wouldn’t exist. I’m guessing this is a complicated way of saying the IP changed since login.
Of course the easiest solution is you shouldn’t voluntarily share HAR files for an active session.
How they detected it can be found at the bottom of the blogpost:
> *Indicators of Compromise*
> ...
> Okta activity for a user without any clear indication that the user authenticated (e.g. a user.session.start event for that user from a similar geographic area)
Oops. Here's an unpopular opinion: maybe critical gatekeeping with SSO using OAuth, SAML, and 2FA is something to run on-prem rather than pressing the SaaS "easy button".
This includes not only Okta but Auth0 (Okta acquired), Authy, and Duo.
Unfortunately, running things on-prem will not prevent security breaches and may be far far worse than relying on a cloud vender for authentication. Here is why:
1. All software has security bugs. This includes on-prem software.
2. Many IT groups do not have the expertise to run and secure a directory. You don’t just install some software, setup some accounts, and leave the box in the corner. You have to make sure the system survives disasters, you have to test backups, you have to figure how to determine if you were hacked, etc. This is very hard work.
3. No one has ever shown that on-prem IT security is better than cloud vender IT security. My experience has been that some on-prem IT departments have very poor security. Here are some examples:
- One IT department I worked with used a VPN which used an MD5 certificate. This was between 2010 and 2020. MD5 was cracked and it meant anyone could preform a man in the middle attack.
- One IT department I worked with deployed a web service which allowed unauthenticated users to access person customer information (national ID/tax number, address, name, phone number, etc.). Note the person doing this knew he was doing something unethical and did it anyway.
- One IT department I know of supples nurses with an add supported text editor to type up patient notes. Adware is not know to value privacy and should never be used to process sensitive information.
- One IT group I know of will not update Redcap to a supported version. The version of Redcap the IT department uses has known security bugs and the IT department was told about them. The official excuse for not upgrading it is the IT group does not like Redcap.
I think Redcap is a piece of software which stores information used in medical studies and used to calculate public health statistics. It contains lots of sensitive data.
My main point is moving from the cloud to on-prem may or may not improve security. It really depends on the capability of individual IT groups and many IT groups are not capable of running an identity service like Okta.
The other thing to consider is cloud venders typically have much larger budgets and can spread costs over many customers. This means they can afford more security specialists, spend more on securing systems, spend more on detecting breaches, etc.
On prem systems have the advantage of not being part of a monoculture, so if another party is breached that will not necessarily have immediate impact on your installation.
This cuts both ways: if your on-premise system is using the same components as someone else you might be unpatched for longer than a responsible cloud service (c.f. Cisco customers currently for multiple product lines, F5, Atlassian, etc.). The challenge is accurately assessing whether your IT department is better or worse than a given cloud service. In both cases, I think more regulation is essential – companies shirk on things like ops staffing because it’s cheaper and that could change.
The question is also whether those cloud providers are much better proportionally. They may put somewhat more effort into security but they're also a much bigger target.
Then there also is the question of cascading effects. E.g. if someone compromises a cloud provider and gains SSO access to Org A and Org B at the same time they might be able to do more harm
Running the same software as everyone else on-prem doesn’t make it more secure — it might even do the opposite unless you’re quick to do security updates.
Everyone using a one of a few cloud providers means lots of golden eggs in very big baskets.
Sure, everyone deploying things on-prem will mean attackers will focus on the software instead of the cloud vendor. But that's A∨B vs. only B.
> - One IT department I worked with used a VPN which used an MD5 certificate. This was between 2010 and 2020. MD5 was cracked and it meant anyone could preform a man in the middle attack.
MD5's collision resistance has been broken. Corporate VPNs are often deployed by shipping the cert's pubkey on each client. In that case you're not using PKI which means the switcheroo attack involving collisions aren't relevant and you only need to rely on MD5's preimage resistance which is still ok.
So while using MD5 doesn't smell great it's not necessarily an open barn.
> My main point is moving from the cloud to on-prem may or may not improve security. It really depends on the capability of individual IT groups and many IT groups are not capable of running an identity service like Okta.
Whether it might improve security is definitely questionable. But it does limit the impact to only one org. Even if multiple orgs use the same product, the local implementations might differ and increase friction to scale the exploit over large swaths of companies.
Well, I agree with this but nowadays calculation for on-prem costs is rather rigorous whereas for cloud any nincompoop can come out and say "Look, we converted capex to opex and implemented best of breed auto scalable cloud native solutions" and be hailed as genius. No question will ever be asked to such managers and executives.
FYI technology execs stopped citing Capex vs Opex as a driver of cloud use years ago. Source: my day job consisted of interviewing F500 tech execs about why they were moving to the cloud, among other things.
Good. On second thought though it seems worse as Capex vs Opex even though not the greatest thing it is still measurable. While the rest of message is pure bullshittery.
Source: I see this communication at (large enterprise) workplace and so many other grand cloud migration pronouncements on internet by executives of F500 companies.
Identity providers, password managers, VPN companies, …. should never get hacked. They make their money from security products. I won’t use them if they are breached. They probably have deeper problems.
Everyone will get hacked. It is obvious no one knows how to write completely secure software. It is also obvious no one knows how to never make operational mistakes, never misconfigure software, never forget to remove access, always rotate secrets, etc.
In fact, not everyone will get hacked. There are security mechanisms that could be used to significantly reduce the chance or increase the cost for the attackers, e.g., adding layers, sandboxing etc.
The goal is not absolute security, rather practically secure systems against attackers with moderate resources.
We can’t prove that a security company will not be breached. But once they have a significant breach, it might be time to move on. They likely have other problems. I’m looking at you LastPass!
Okta holds the keys to the castle. It has had a security incidence in the past. A compromise of the Okta systems will have a huge impact on its users. The margin for error is small.
Why would you use them before they prove they can not be breached?
The default assumption is that they can all be breached, the burden of proof is on them to prove they will not get compromised. It would only seem prudent to wait for positive proof of the extraordinary claim that they can not get hacked rather than extending the benefit of the doubt to serial incompetents.
How do you prove that “they will not get compromised”
when a breach can be caused by an unknown CVE in the future?
That seems impossible to prove, I mean I understand you can patch, audit, encrypt, your way to a safer system, but proof (by definition) is a very high bar.
What is an acceptable demonstration of proof given unknown future events? How does one define proof in the sense “will not get compromised” (future tense is used in your phrasing so a proof would have to include all possible future outcomes)
The person I was responding to said these providers “should never get hacked”. Given that the default assumption is that systems are easily hacked, then logically such a requirement demands proof (in the sense of robust evidence) before acceptance that it is met. There is no sense in waiting for it to happen first when that is the default assumption.
To go a step further, you can apply this to any acceptance criteria. What evidence is there that any of these systems meet any meaningful acceptance criteria. What evidence is there that Okta has systems that can protect billions of dollars worth of assets from the teams of professional and state attackers that currently target their systems?
To then get to your direct question, if you really need “should never get hacked”, you could provide machine checked mathematical proofs of correctness, robust and exhaustive validations, and NSA penetration test reports showing zero identified vulnerabilities like what was done for the F-35. I mean, I guess that is only like 1000x better than prevailing commercial IT systems and not completely foolproof, but it is certainly a good starting point. You can probably think of some ways to evaluate even more robust security if you need more assurance than the US air force.
Unfortunately, getting breached is not a sign a person or organization is incompetent. All getting breached means is someone decided to attack and organization and found one or more holes in the organizations services.
Shooting a hole in a bulletproof vest with a slingshot is not a sign the bulletproof vest is garbage. All shooting a hole in a bulletproof vest with a slingshot means is someone decided to shoot a bulletproof vest with a slingshot and found one or more weak points in the bulletproof vest.
Sounds pretty stupid, right?
Okay, now replace slingshot with tank.
Now it does not sound so stupid.
Turns out you can learn something based on the effort needed to breach a defense.
As it turns out, the entire commercial IT industry is basically incapable of stopping small teams of moderately skilled attackers as has been demonstrated to death. A team with just 1-2 M$ of resources is basically unstoppable even with 100 M$- 1 G$ budgets. That is the definition of gross inadequacy.
‘Click Here to Kill Everybody’ talks in great detail about the asymmetry of defending against attacks. We are in a timeline where this is getting worse over time. A 100x or even 1000x budget/effort is now required to defend against some attack vectors. This isn’t fair, but it’s the state if affairs. My point being: you’re right, but tanks are now orders of magnitude cheaper than anti-tank defenses.
If you have a problem and your provider asks for the active HAR file.
It seems a problem with the provider. You're problem is probably not even going to be checked without fulfilling their request.
Okta should have revoked the token after the file was no longer needed.
Should I remind you that multiple customers were compromised because of this and that Cloudflare was probably the only one that wasn't breached AND notified Okta...
As the old saying goes, security is process, not a product. But since it's very hard, there is always temptation to lean on the latter, not the former.
Those services are honeypots by definition. It would be naive to think that they never get hacked. It's only a matter of time until they do. If they're competent and responsible enough they'll notice and disclose it publicly, but I reckon that most of them never do, precisely because people like you would stop using them.
This is why anyone even slightly concerned about this should use offline, self-hosted, or self-built alternatives.
Why not say "it's a pot of gold", "it's a treasure for attackers" or something like that? Honeypots being a trap is the common definition, and it's confusing when used otherwise
Okta try not to get hacked for a month challenge [level impossible].
In all seriousness, they seem to love getting pwnded. You would hope that the constant stock drops as a result of events like these would force change, but I guess not.
Some day I'm going to do a conference talk where I just pay people to take on support positions at different companies and then compromise access to those companies through the systems they're given access to.
Okta outsources their support staff to save millions of dollars while losing billions of dollars in market cap each time their support staff gets hacked.
If Equifax is anything to go buy, the stock price will recover just fine.
In fact, until we get actual liability for breaches like that, an investing strategy based on "buying the dip" every time a company gets breached would be probably be quite successful.
Isn't Equifax part of a de facto monopoly? Okta doesn't have that luxury. Security is also not Equifax's core competency, but it is supposed to be Okta's. I would be happy for you to be right, but I think this happening a second time to Okta is going to cause massive damage to their reputation in the industry.
Are centralized identity/auth vendors the Adobe Flash of B2B software?
Less tongue in cheek, does anybody have a recommendation for a reputable centralized identity/auth provider? Like Mullvad is to VPNs as <> is to OAuth?
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)
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?
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!"
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.
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
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.
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.
What kind of resolution are you hoping for? Or asked differently, what kind of threads do you still see as open?
For me, the biggest bummer was the lacking security culture that let a cert validation component to not properly validate certs, in at least two ways (didn't enforce tier separation; accepted tokens signed by an expired or revoked CA).
Most companies making this jump are already using azure and vulnerable to any azure compromise. And for a long time, adding in okta was some kind of trendy thing to do "for security" but all its adds at this point is another point of failure. Organisations that can rely exclusively on azure much better off doing so imo, the argument about the mfa being somehow better in okta just isn't right in 2023.
Especially because if you use azure ad (or entra now) as a backend behind okta (as we do at work too), you now have two vendors that might get hacked instead of one. If I have a valid azure cookie it bypasses all IDP login rules (eg this cloud service may only be connected to from the company network).
Also, Microsoft and Google have one big thing in their favour: they run consumer services with billions of customers that they get a ton of experience from. And which are a huge target which rarely gets breached.
Those consumer services are not running on the same IDP services e.g. "Entra ID" but as a company it does prove they know what they're doing. I have to give them that. I know MS got breached recently too but they have a decent track record overall. Saying this as a MS critic by the way.
Yeah gotta love Microsoft marketing goons that rebrand everything every few years.
Though azure ad was actually a bit confusing. But usually their rebranding makes zero sense. Like from lync to Skype or msdn to my visual studio. Or sms to sccm to mem.
Rebranding Yammer is a complete head-scratcher to me. At least "Azure AD" might be a little confusing since it's independent (I think?) from Azure itself.
I just have folks use different auth in different contexts, not about rolling my own. Basically means using more passwords. Sorry, you need to login to each place separately. I offer a locally hosted password manager.
Identity and auth provider consumers are a mix of lazy, under resourced, and unsophisticated. Lots of inertia and checkbox completion vs due diligence. It's also a pain to move, having had to help an enterprise move from Lastpass to 1password. Even worse trying to swap out idps. Operating your own idp internally requires sophistication and resources (engineering talent, org will, etc).
I am sympathetic to the idea of not reinforcing bad behavior at a vendor, but also mindful that sometimes you're going to risk accept and move on (and revisit when the contract is up for renewal). Time and resources are finite.
EDIT: With all the above said, Okta would not be my first idp choice, considering all available information.
(head of security @ fintech, I own customer and internal IAM, thoughts and opinions my own)
It depends if you are talking about Okta's "Workforce Identity cloud" which is their flagship product under the Okta name and serves businesses needing an IDP to manage their employees. Or if you are looking for "Customer Identity cloud" aka Auth0 alternatives which is primarily for authenticating a businesses end-users/customers.
yeah, forgot to mention. I'm looking into "workforce identity cloud", and apparently Microsoft's offer is very hard to pass, if an organisation uses/requires to use MS Office.
Microsoft Entra ID formally known as Azure Active Directory is popular option. But the list goes on Ping Identity, One Login, Google Workspaces, and more are all options out there.
Okta published a blog post here: https://sec.okta.com/harfiles and kicks it off with
> Okta Security has identified adversarial activity
and no mention of the notification from the third-party. Nice transparency!