5 Things To Know On Okta’s New MFA Requirements
Following a series of breaches impacting IT systems outside Okta’s core product, the vendor is raising all of its systems to ‘the same high bar for security,’ Okta CSO David Bradbury tells CRN.
Following a surge in attacks targeting Okta and its customers — several of which have been notably successful — the company is rolling out a series of security enhancements including stronger multifactor authentication (MFA) requirements for administrators interacting anywhere on Okta’s platforms.
In an interview with CRN, Okta Chief Security Officer David Bradbury said there has “definitely been an escalation in attacks targeting Okta in the last six months.” The identity platform maker has been a major target partly due to the fact that many organizations use Okta to provide employees with access to their applications and resources.
[Related: Cloudflare Discloses ‘Limited’ Impact From Okta Breach]
When it comes to Okta specifically, as well as the industry-wide increase in attacks, “it’s clear that there is a war that's going on out there,” Bradbury said. “We feel this is an appropriate, strong response to ensure that we can secure Okta and our customers.”
What follows are five things to know on Okta’s new MFA requirements.
Increasing Security For All Okta Systems
What Okta has now recognized is that while its own products have been adequately protected against attackers, not all of the auxiliary systems around Okta have reached the same bar, Bradbury said.
And attackers have exploited this disparity, including last fall’s breach of Okta’s customer support system and the early 2022 breach of a third-party Okta support provider. The stricter MFA requirements from Okta are a response both to these incidents and to “the threat environment deteriorating over the past six months,” Bradbury said.
For the company, “the crown jewels are the Okta products, and the vast majority of the security resources that are under my control get applied there,” he said. The support system breach disclosed in October — which saw the theft of all support customer names and emails while also compromising log-in information for customers including Cloudflare and BeyondTrust — falls outside the core area that Okta has previously prioritized for top-level security, however.
The same is true for the early 2022 incident when Sitel, a third-party Okta support provider, was breached by the Lapsus$ hacker group.
“If you look at the incidents we've had across the past couple of years, these are all production-adjacent areas. They’re just on the edge of production, they're not considered within this [core product] boundary,” Bradbury said.
“As part of our rethink here on how we approach security, we need to leverage the same threat model that we do with production as we do with everything else across the company,” he said. “And so where there has perhaps been a preference to invest more within the product than in other areas, we need to remedy that. And that's part of what our commitment is, that we will treat everything — whether it's internal technology, our people, our processes — we will treat all of this with the same threat profile as our customer-facing environments.”
Ultimately, “the same high bar for security that we have across the Okta product, we will raise everything else to that same level,” Bradbury said.
MFA Required For Admin Console
One major update is that Okta will require MFA to access the Okta Admin Console for all administrator roles. The company said it plans to take a “phased approach” to the rollout, with the system initially preventing the creation of new admin app authentication policies without MFA, Okta said.
While today Okta already has more than 90 percent of admins on its platforms using MFA, “we need to close that gap,” Bradbury said. “We can't have any admins on our platform who aren't using MFA. That introduces risk to Okta and Okta customers.”
MFA Required For Major Admin Actions
Within the Okta Admin Console, the company will also be requiring MFA for “protected actions,” such as when key settings are accessed or modified, according to Okta. The aim here is to limit the possibility of exploiting stolen sessions or tokens to perform actions in the console, the company said.
“If you are a threat actor and you've managed to bypass all of the protections to get to the console, and you want to attach another identity provider which is threat-actor controlled, we would actually force a biometric authentication,” Bradbury said. “You won't be able to affect any action because you'll still need to do biometrics to [attach the identity].”
MFA Required For Okta Support Portal
In addition to admins, Okta will also be increasing the security for customers looking to use its support portal at support.okta.com. The company plans to roll out this requirement to general availability in March.
Even though the incident from last fall was enabled by an attacker impersonating an admin rather than a customer, “a whole suite of work is focused right now on raising the bar particularly for that application,” Bradbury said.
Results Of 90-Day Security Push
Following the recent support system breach, Okta CEO Todd McKinnon said in late October that the company was delaying product and feature launches for 90 days in order to focus on its security.
The new MFA requirements — as well as a number of other security improvements that Okta is rolling out — are a result of that 90-day security push, Bradbury told CRN.
“Over the last 90 days, we've done nothing but build and deliver security features,” he said. “And so what you're seeing here are the outcomes of that work.”
Preventing Future Incidents
The bottom line is that Okta believes that taken together, the new MFA requirements and other security upgrades will prevent the sorts of incidents that have impacted the company over the past two years, according to Bradbury.
For instance, in the attack last fall, attackers exploited the fact that organizations have a small number of accounts for admins that don’t need to authenticate through Okta to log into third-party SaaS applications. One of those accounts was compromised in the attack, but in the future, that won’t be possible due to the new MFA requirements, Bradbury said.
Overall, “I think all of the hygiene elements that we’re baking into the plan to specifically raise the security of that platform would have addressed [those issues],” he said. “It encompasses everything from service accounts through to the way that we retain data within that system, to the way that customers access the system. So there's a whole suite of improvements there.”