Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Updated Okta Statement on Lapsus$

okta.com

Post reply on HN
Print view View original

171–180 of 239 posts

Re: Updated Okta Statement on Lapsus$

#171

Post by lurker91283 »

dvtrn wrote: post #165
hughrr wrote: post #142

Earlier quoted context omitted.

Yep. All these standards are tick boxing for liability. Nothing more. They are not effective security controls and never will be and should never be a measure of that.

We’ve been monitoring this internally, as customers of an Okta-like service. I’ve also been closely monitoring the responses from our CTO and VP of Security when someone from our DevOps team posted a link to the Verge article in slack this morning. Which brings me to this inquiry: How are your orgs responding to this? We have a dependency on an Okta-like provider and my first thought when reading this news was “you k…

I moved over to Azure AD this morning (we only have a few devs and were already using Azure DevOps so this was doable). I requested that Okta cancel our account and let them know the reason was the potential data breach and their CEO's response on Twitter. Okta's response was that we signed an MSA agreement and that cancelling isn't an option, nor termination of fees.

Re: Updated Okta Statement on Lapsus$

#172

Post by hughrr »

lurker91283 wrote: post #171
dvtrn wrote: post #165

Earlier quoted context omitted.

We’ve been monitoring this internally, as customers of an Okta-like service. I’ve also been closely monitoring the responses from our CTO and VP of Security when someone from our DevOps team posted a link to the Verge article in slack this morning. Which brings me to this inquiry: How are your orgs responding to this? We have a dependency on an Okta-like provider and my first thought when reading this news was “you k…

I moved over to Azure AD this morning (we only have a few devs and were already using Azure DevOps so this was doable). I requested that Okta cancel our account and let them know the reason was the potential data breach and their CEO's response on Twitter. Okta's response was that we signed an MSA agreement and that cancelling isn't an option, nor termination of fees.

They sound like they're running the organisation like a dating site.

More reasons to look elsewhere.

Re: Updated Okta Statement on Lapsus$

#173

Post by ttt2022 »

adam0c wrote: post #163

Copy / Paste from Lapsuss telegram ;) https://www.okta.com/blog/2022/03/updated-okta-statement-on-... I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the…

> kkkkkkkkkkkkkkk

"kkkkkkk" is the Brazilian way of typing "hahaha". Is Lapsus from South America?

Re: Updated Okta Statement on Lapsus$

#174

Post by zmmmmm »

templapsusread wrote: post #31
templapsusread wrote: post #23

Lapsus has responded https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c...

they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...

tbh it is a reassuringly weak response.

Mostly picking apart logical inconsistencies in the language and / or re-emphasising the already disclosed info. Does not seem like they were able to produce any hard collateral to contradict anything Okta stated which probably means it's at least ball park accurate.

Re: Updated Okta Statement on Lapsus$

#175

Post by stefan_ »

hughrr wrote: post #142
maldeh wrote: post #119

Earlier quoted context omitted.

A more poignant elegy to the modern landscape of compliance theater I have never seen: > Security Standards. Okta's ISMP includes adherance to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: > a) Internal risk assessments; > b) ISO 27001, 27002, 27017 and 2701…

Yep. All these standards are tick boxing for liability. Nothing more. They are not effective security controls and never will be and should never be a measure of that.

And yet Okta is the ultimate in box-ticking technology. They are bought to tick the boxes. So what happens now that the box tickers are not ticking the boxes?

Re: Updated Okta Statement on Lapsus$

#176

Post by zmmmmm »

gedy wrote: post #86
Consultant32452 wrote: post #53

Earlier quoted context omitted.

The LAPSUS$ post suggests that they queried the AWS keys out of Slack. So the support engineers just have access to Slack, and Okta engineers were dumb enough to put those keys in Slack.

I'm incredulous an auth focused company would do this without someone freaking out? Even my much smaller SaaS companies would react quickly to stop and rotate these if this happened.

looking closely at that I'm suspicious that lapsus$ is playing up what were perhaps trivial or ephemeral keys that were non-sensitive ... eg: test / dev / debug instances etc.

The reason I think that is because if they really had keys for production machines it seems very unlikely they wouldn't have used them to produce some more damaging collateral than they've presented.

Re: Updated Okta Statement on Lapsus$

#177

Post by hughrr »

stefan_ wrote: post #175
hughrr wrote: post #142

Earlier quoted context omitted.

Yep. All these standards are tick boxing for liability. Nothing more. They are not effective security controls and never will be and should never be a measure of that.

And yet Okta is the ultimate in box-ticking technology. They are bought to tick the boxes. So what happens now that the box tickers are not ticking the boxes?

Usually a mass exodus to a similar service with the same guarantees resulting in months of capacity problems as they try and scale out from customer influx.

There are no winners.

Re: Updated Okta Statement on Lapsus$

#178

Post by raffraffraff »

eugenekolo wrote: post #101
politelemon wrote: post #79

Earlier quoted context omitted.

8600 channels? Wouldn't that overwhelm you? I'm trying to think up scenarios where an org would need so many, but I can't. Is this normal?

Support tickets, or incidents, or escalations might require creating a new slack channel

It's not a bad idea to create channels for incidents. Ever tried to keep an incident timeline in a Jira ticket? It's absolutely horrendous. We used to automatically create a slack channel whenever a Jira incident ticket was created, and post it into the engineering channel with a message like "SEV1 incident, please join channel #INCIDENT-21". Slack is real nice for posting graphs, links, screenshots, going off on different investigation threads, pinning a status that gets constantly updated, calling out for people to join the channel using @you-hoo and running automations using bots. Jira absolutely sucks for live incident handling.

Of course, you still wouldn't have 8500 channels. That's a lot of incidents.

Re: Updated Okta Statement on Lapsus$

#179

Post by Closi »

dboreham wrote: post #126
t0bia_s wrote: post #109

Reply from Lapsus$ on Telegram: I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't succes…

Posting a key in Slack is obviously not good opsec, but whether this is a big problem depends whether those keys allowed access to anything sensitive. They could be keys allowing access to random test data, or public data, etc. They could have been revoked immediately they were posted.

It does directly/partially contradict their statement though, i.e.

> The potential impact to Okta customers is limited to the access that support engineers have

Well the implication here is that the support engineer only had some limited set of tasks, but if that Support Engineer also indirectly had access to AWS keys then it suggests that Lapsus could have had broader access than just what the support engineer had direct access to.

Re: Updated Okta Statement on Lapsus$

#180

Post by wepple »

dboreham wrote: post #131
siskiyou wrote: post #122

I've never worked at Okta, but I've worked with several production ticketing systems at big and small companies, and all of them contained critical information about customers and operations. Including credentials.

Not putting secrets and sensitive data in bug reports / tickets has been a thing for at least 20 years, so you worked at some crappy run places.

Ah, I see you’ve never worked at a large company with lots of humans
Post reply on HN