201–210 of 239 posts
Earlier quoted context omitted.
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.
Okta is the Oracle of identity management. https://auth0.com is the "still cares about customers" vendor I'm not affiliated with them, just traumatized by working in IT
> There is no impact to Auth0 customers, and there is no impact to HIPAA and FedRAMP customers.
Earlier quoted context omitted.
It is really clever wording, but it is possible for the statements to be true, while being deliberately misleading. What they initially detected, and what the 3rd-party investigation found, were two different things. Okta initially "detected an unsuccessful attempt" - the successful attempts were not detected initially but the detected event did lead to an investigation. Now, JUST this week (presumably, in the last 7…
I didn't find this misleading at all. Just a chronology of their evolving understanding.
Earlier quoted context omitted.
It is really clever wording, but it is possible for the statements to be true, while being deliberately misleading. What they initially detected, and what the 3rd-party investigation found, were two different things. Okta initially "detected an unsuccessful attempt" - the successful attempts were not detected initially but the detected event did lead to an investigation. Now, JUST this week (presumably, in the last 7…
I didn't find this misleading at all. Just a chronology of their evolving understanding.
> limited data - for example, Jira tickets I wonder how many passwords and other creds were harvested from tickets alone. Lapsus$ went after Okta's customers and in some cases successfully, it appears.
> it appears. Where does it appear like that? I have tried to follow this but the only thing I have seen shares is info from within Okta. I have seen email addresses of CloudFlare employee in screenshot of Okta, is that what you are referring to?
https://www.vice.com/en/article/y3vk9x/microsoft-hacked-laps...
Earlier quoted context omitted.
If I use your laptop to get access to your Gmail isn't your Gmail account compromised? I might not have access to your Gmail username and passwords (and MFA), but I can read your email, I can send email as you, etc etc. I feel like I have compromised your gmail account. If I steal your secure token and log into you through a cloned browser session and access your gmail have I compromised your gmail? It feels like it.…
> your Gmail account compromised The access is transient and you remain in ownership over the credentials and account, because the credentials were not compromised (just the programs/browsers with pre-existing auth). Though with physical access it's probably only a mater of time before local admin passwords are brute forced and access to keychain/browser saved logins is inevitable? > If I steal your secure token It's…
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.
Earlier quoted context omitted.
> If that service is compromised, it doesn't really seem to matter how? I hear what you're saying, but the how does really matter, and will change how customers perceive the issue and make decisions about how to react. e.g. "databases were open to the Internet and all data has been siphoned" lands quite differently than "a staff member abused their privileges but the scope of abuse was limited to xyz". If I'm a custo…
How it happened doesn't change the fact that they have been breached. If I was a bank and claimed that I haven't been robbed, an insider just transferred billions of pounds out of the bank and then fled, I think everyone would rightly say "What are you talking about, you have been robbed!" It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a…
I have to respectfully disagree.
Yes, the end result may be the same, but even in a bank robbery, the how matters, and will drive different behaviors from everyone involved: the bank, law enforcement, and customers of that bank.
If as a customer, I learn that a guy in a stripey t-shirt holds a teller at gunpoint, my conclusion goes something like "that's a terrifying situation for the teller, and I hope they're ok". I'm probably not going to stop using that bank.
If on the other hand, I learn that there are systemic issues with bank security, and internal employees have been embezzling funds somehow, I'm probably going to think hard about whether this is a bank I want to do business with.
> Security isn't just about technical security - it's the whole process involved in making sure these things don't happen.
Yes, and when factors are involved that are out of the bank's control (e.g. a crazy person walks in with a gun), it might be fair to ask why the guy got inside to begin with, but the conclusions you draw about such an incident are far different than the conclusions you'd draw if internal employees were involved.
In case this wasn't clear from my earlier comment, I didn't mean to imply that an internal process issue makes any of this ok. But it does make it different than other types of breaches.
Bottom line: the how still matters, not because one type of problem is ok and the other isn't, but because the actions a customer should take / consider will be different depending on how the breach happened.
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.
I’d look at stuff like FedRAMP as a starting point for the control environment and explore further.
Earlier quoted context omitted.
> The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is consistent with the screenshots that we became aware of yesterday. Yeah, it was.
You can take my laptop from me and have access to it without having compromised my Okta account. In that scenario you wouldn't have my okra password or my MFA - what you would have is transient access to everything I'd already auth'd to until it times out and requests that you auth again.