2.5% of all customers were accessed by all Sintel employees for the period in question. How many customers did the particular affected Sintel employee access?
They assessed all the actions that took place by the Sintel employees. Were any of them sensitive?
The tool doesn't allow them to create or delete users. Does it allow them to modify users so that an attacker can take over an account?
The attacker had access to "Jira, Slack, Splunk, RingCentral, and support tickets through Salesforce". Doesn't sound bad on its own but have those tools been evaluated to ensure they don't have sensitive information? Do we know what the Sintel employee in question accessed from each of those tools for the time period?
The employee's machine was logged into using an RDP session. Was the employee's machine assessed to ensure they weren't storing other sensitive information? While not allowed, a lot of support engineers will quickly drop in "temporary" sensitive stuff into random notepads and what not. Was this assessed? Also, why does a support engineer have a machine that has the ability to enable an inward bound RDP session at all?? How was that not the first trigger since this is a known attack vector for support agents.
Given the possibly small blast radius of this issue, Okta had all the opportunity to turn this into a communications win for them and just build a multiple of trust really quickly. All these half communications have utterly botched it and that's just really disappointing. We'll still continue to use them because the switching costs just don't justify moving off Okta. But Okta has really taken a hit in their "trust bank".