Sitel, on the other hand, engaged a forensic response group to get a full understanding of the event and ensure that all avenues were covered. The forensic investigation began on January 21st and was in process until February 28th with a final report delivered on March 10th. Okta received the report from Sitlel on the 17th of March. This delay in the report is what Okta is standing behind as to why they did not disclose anything sooner. However, the launch of a full investigation is exactly what Okta should have done and failed to do. Having worked in multiple industries where 3rd party contractors/vendors we always maintained plans to conduct a full investigation in the even of a vendor/contractor related incident. It is what you do and in many cases is required by different compliance standards.
Why Okta felt they could let a security incident (the issue was classified as a security incident by Okta on the 20th of January) go and not perform a more thorough internal investigation is not clear at all. In fact even their apology does not take ownership of the event with Okta saying; “At that time, we didn't recognize that there was a risk to Okta and our customers. We should have more actively and forcefully compelled information from Sitel. In light of the evidence that we have gathered in the last week, it is clear that we would have made a different decision if we had been in possession of all of the facts that we have today,”
If Okta had a security policy that included an internal investigation after any suspected or reported vendor or contractor security incident, they would have had more information and not needed to wait on Sitel. Based on the timeline Okta released showing that they received a summary report from Sitel on the 17th, they still did not start their own internal investigation until five days later when Lapsus$ released screenshots from inside Okta’s systems on the 22nd of March. A full two months after the incident that we now know started on January 16th and finally ended on the 21st.
In the end Okta had to disclose that 2.5% (366) clients were affected by the incident, a huge difference between the “unsuccessful” attempt announcement and what actually happened. Okta’s claims that the compromised account did not have superadmin access that Lapsus$ claimed is about the only good news, if it is true. Lapsus$ was not known lying about what it had accomplished, but they often misinterpreted things when they felt their skills or talents were in question. A good example of this was their belief that NVIDIA “hacked” them after the VM they were using was encrypted and isolated. The reality of what happened was more likely an automated response to a DLP (data loss prevention) policy than an active hack. This means that Lapsus$ might have misinterpreted the actual access level they had inside Okta and did not really have full admin level permissions. At least I hope that is the case.
Regardless of the access level, Okta is responsible for not conducting their own internal investigation after they discovered a possible contractor compromise. Nothing that happened after that, including the long time it took Sitel to Get Okta their findings change this fact. Okta says they will use this as an opportunity to learn and improve their responses, let’s hope one improvement is taking ownership of any incidents and not just pushing it back on the vendor or contractor in the future.
