This raises a number of architectural questions for Okta:
- Can a support engineer for customers in one region access the systems/databases relied upon by customers in other regions?
- Do employees get notified when their account is logged into or used (e-mail/SMS/otherwise)?
- Do customers get notified when a support engineer accesses (with privileges) a system/database the customer relies upon?
[1] https://work180.com/en-US/for-women/job/215617/tier-2-techni...
Otherwise, the goal is to give each agent access to an arbitrary subset of users, so it's harder to recruit an agent who can access the "target" victim customer.
* Balancing the assignment of users to appropriate agents
* Less flexibility for agents to be specialized (instead of an agent responding to all X related tickets everywhere in the world, an agent must respond to X, Y, and Z from these specific users)
* Handling user coverage when agents are busy, PTO, etc. The spirit of splitting agent access would mean agents would need to request access from an out-of-region authority in order to help with things last minute. An authority who will be expected to be responsive 24/7 without also being an attack vector
Technically, the current model is a full M customer x N agents mapping. All customers served by all Agents. Adding some 0's to that mapping should certainly be possible without sacrificing much from current system. No way to know how many is reasonable
All that said, there is a natural logic that arises from this 'analysis' - Limit access to customers who are inactive, or who rarely have issues. A common sense addition would be to raise their default priority for when they do interact.
The screenshots show that LAPSUS$ had access via the account of the outsourced Costa Rican based Tier 2 TSE worker to view details of and reset the password of a UK-based site reliability engineer of a well known Internet global infrastructure company. This level of access in itself doesn't sound hugely problematic on its own if it weren't for job applications for Okta Tier 2 TSE workers indicating server/network administration responsibilities. There is some publicly published information that provides more context on what access a Tier 2 TSE worker may have to customer data:
- Okta's security whitepaper [1] states that multi-factor authentication is needed for administrative access to AWS instances (host operating systems) so this could have possibly prevented LAPSUS$ from using their access to do anything more sinister than perhaps causing customer organisation-wide outages by disabling/resetting all their user accounts. The response for control AC-17(06) at [3] indicates that remote access requires valid multi-factor authentication to occur so if LAPSUS$ could gain remote access, perhaps they had already gained the ability to generate valid multi-factor authentication tokens, or otherwise bypass multi-factor authentication for remote access.
- The response for controls IA-02(09), AC-06(07), PS-04(01) and SA-12 at [3] indicates that Okta employee access to customer data is deemed privileged access and that fewer than 30 Okta employees have this level of privileged access to this customer data. I doubt this is true, unless the SP 800-53r4 responses at [3] are only referring to the US government tenancies that are hosted separately from tenancies of global companies.
- The response for controls SI-04(12), SI-04(19) and SI-04(20) at [3] indicates that changes made to a customer tenancy (for example resetting passwords for customer users as shown in the LAPSUS$ screenshots) should have triggered events being sent to both Okta's Splunk SIEM system and also to a customer SIEM system if they have set one up. Theoretically this should quickly raise a red flag to the customer if LAPSUS$ were to use this access to bulk deny the customer access to their ICT systems. It is however not clear that privileged access to the host operating system for the AWS instance would cause an event to be sent to the customer's SIEM system.
== Level of segregation of customer tenancies and whether LAPSUS$ may have been using Okta access to attack customers ==
It's fairly straightforward to enumerate the Okta hosting arrangements from DNS records as listed below. The sample targeted company in the screenshots has their Okta tenancy hosted within AWS region us-west-2 (Okta OK7) and other screenshots showed that the compromised account had recently accessed privileged access tools for OK3, OK8 and OK12. Thus it would appear that a Costa Rican-based Tier 2 TSE worker would have access to customer information within perhaps any of the clusters (not geographically restricted).
ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com - response when a tenancy is invalid/doesn't exist
ok2-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-1.amazonaws.com - companies (global)
ok3-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-1.amazonaws.com - companies (global)
ok4-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-1.amazonaws.com - companies (global)
ok5-crtr-tls12-fips-nlb-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com - US government agencies
ok6-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-2.amazonaws.com - companies (global)
ok7-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com - companies (global)
ok8-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.ap-southeast-2.amazonaws.com - Australian government agencies and some other Australian companies/associations
ok9-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.eu-west-1.amazonaws.com - unknown / no customers found
ok10-crtr-tls12-fips-nlb-xxxxxxxxxxxxxxxx.elb.us-east-2.amazonaws.com - US government agencies
ok11-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-2.amazonaws.com - unknown / no customers found
ok12-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com - unknown / no customers found
microsoft.okta.com - likely customer - ok3-crtr-tls12-nlb-dfef298ffc8f82ca.elb.us-east-1.amazonaws.com
nvidia.okta.com - likely customer - ok2-crtr-tls12-nlb-acd62f33a2a6a463.elb.us-east-1.amazonaws.com
vodafone.okta.com - confirmed customer [4] - ok4-crtr-tls12-nlb-29367a8e4bb80716.elb.us-east-1.amazonaws.com
samsung.okta.com [5] - possibly not a customer - ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com
ubisoft.okta.com - possbily not a customer - ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com
lg.okta.com [5] - possibly not a customer - ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com
[1] https://www.okta.com/resources/whitepaper/okta-security-tech...
[2] https://trust.okta.com/security/
[3] https://www.okta.com/resources/whitepaper/using-okta-to-prot...
[4] https://miniorange.com/atlassian/atlassian-single-sign-on-ss...
[5] Note: also tried similar names known to be used by company divisions.
My (admittedly outdated) experience is that this is always the case, regardless of any assurance vendors might have provided to the customer. In the end, people have to get stuff done, and offshore bodies are just too cheap to pass on. Things might have changed a bit since GDPR but, in practice, I expect there will always be "channels" for people to reach out cross-region.
Just because a customer is based in Europe doesn't mean they don't need to get a hold of support at 03:00 local time. Even small, growing, startups now have HQs in one part of the world and staff across the globe due to the ease of movement many enjoy.
No. It's a tricky situation too, since even if one did receive such email, I won't look at work email until working hours. So even with such a notification, if you logged in on friday 20:00, you've over 50 hours to do your work.
I might also add that Okta DOES NOT support any form of physical 2FA (e.g.: yubikeys), only software-based ones.
Not sure where you got this from, but we've been using yubikeys for a few months now. They even allow policies to only allow physical 2FA methods.
You might be operating under outdated information. I absolutely use a YubiKey with my Okta account.
A single support account reading say 10x the normal number of accounts per day, with a different geographic distribution than the norm, should ring alarm bells. It’s not enough to say “well shucks they have access to the data, guess we’ll do nothing”
As an industry I don't know if we have made rational choices along the way.
This is cope - managers repeat this narrative so they can blame some other factor rather than having to put in the work to fix the problem of hiring good FTEs. Unfortunately, this narrative has been repeated so often that it is perceived to be axiomatic, which is why it is repeated without any criticism.
No, its not that hard to find good FTEs, you just haven't tried hard enough, or you're not paying enough, or your glassdoor reviews are bad.
this is not a negligible barrier. Sure you could argue that a business that isnt successful enough to hire for that expensive FTE maybe shouldnt exist at all, but a lot more is possible by being able to outsource it. And there really isnt a good reason why it cannot be outsourced from an operations standpoint - it is entirely a security problem. It's not like auth is hard to do for a third party.
e.g. nobody got a promotion because the change they pushed for 5 years ago prevented an attack today.
That's not to say people are just greedy and only chase what gets them a promotion, but replace "promotion" with "received positive feedback".
A portion of our industry seems to be bad at risk calculation, but that's not inherent to the SaaS model - this app very well could've been made with strictly separated tenants.
> well-tested, audited and certified software package
Who is selling this?
> If you receive a credible bribe and report it immediately to X we will report to relevant authorities and provide a bonus equal to the value of the bribe (capped at Y).
If you reported a fraudulent bribe, which was reported to the police there is a risk the briber and you both are arrested.
I see only trouble with this approach.
Just hire good people, treat them right, have sensible audit and monitoring procedures.
It's very difficult.
edit: By which I mean 1) audit your processes and 2) get to know your people.
Processes require good engineering to thrive; people require good management. When you confuse the two, you get problems.
Some will take it as a sign they should poke further your system, or shop around for others paying better.
That's kind of a weird moral take on things. If you don't like the bounties offered then simply don't invest time in the platform looking for things to exploit.
You wouldn't know how insulting that is before going through a good of paperwork that legally tames your desires.
Industries ex software know that since time immemorial.
Prob the software way of solving that is with least privileged access, automatic auditing and approvals.
I wonder why not even security companies are doing that correctly though.
Why should a business care if it gets hacked? It's the users that suffer and they don't have an alternative.
Most people worldwide will take the moral equivalent of a bribe. It may require a sum so large as to be implausible for it to ever happen, but anybody that tells you they wouldn't at least consider illegal activities for life-altering amounts of money is statistically a liar. Millions of people have done and will continue to do it for seemingly trivial amounts of money.
The prisons of your country are full of such people.
Only if you assert that it is only useful if it solves 100% of the cases.
There are other motivations, but money is a big one. If you could block X% for a large value of X (I'd say easily > 50) then you're better off than before, even if some insiders driven by other motivations still remain.
Still your point stands that money is a common factor. However you still have the problem that bribes usually aren't a one time payment but an ongoing thing, so a purely financially motivated adversary would take the total value into account.
Similar to how IT in many large companies nowadays runs internal phishing tests.
That changes the risk/reward, so while every reported bribe is a nice cash bonus, accepting any received bribe becomes significantly riskier, and by 'practicing' bribe reporting it becomes the default reaction.
(not a criticism of the comment above me, btw. not point I was making.)
I checked their telegram group and I can see that they specifically recruit people with access to VPNs/internal support systems. This okta breach seems to have happened through similar means. The group has made specific calls for access to gaming companies, hosting providers, telcos, call centers, and bpm providers. They offer payment.
It doesn’t feel difficult to see how some overworked, underpaid support agent (or even a well paid disgruntled one) might decide to go with this. Just takes 1 well placed agent to give creds and this group has access to a huge attack surface instantly. This might sound like an overreaction, but corporations in the future might need to make least privilege access and access logging everything a priority from day 1.
https://t.me/minsaudebr/162 (Link to the recruitment message)