Maybe I’m just an unimpressed security professional but I’ve still not seen evidence I’d call a breach. At least not a significant one if you want to argue sublantics.
Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.
The screenshots on the linked tweet make it look like okta dog foods their own product for access to various services and someone has access to one of their admin accounts. Which is bad, but that could mean “we phished this one person who works at okta” and not “we compromised okta and have unfettered access to their customers/valuable assets”.
The news of the coming days may well prove me wrong, but i am not assuming the worst from this yet. Many companies whether or not they use an idaas do things like login anomalie detecting, and users coming in from weird locations and weird times of day would be sure to set of alarm bells at some of the big targets. Heck, AWS does it for customers with guard duty.
Implicit grant is depecrated, in the forthcoming OAuth 2.1 [1] standard this is solidified.
We start using the language "public client" and "private client", where a public client is an OAuth client like a mobile app or SPA that does not have a client secret, but has an access token delegated to it(+optional refresh token). Public clients must use implicit+PKCE.
Private clients are what we would have previously thought of as an Authorization code grant client where a server process has an access token to take actions on behalf of a user.
Depending on the OAuth use case, maintainers of the system may need to keep track of what clients are public or private, and limit their entitlements accordingly.
Public clients have the obvious issue that they're on an end-user device and thus the tokens may be stolen, proposed standards like JWT DPOP [2] and token binding [3] aim to address this.
Job Role/Further details are risky to discuss because this forum is read by my colleagues and likely the nerdier execs. I could leave it at I am someone very senior and actively involved in trying to tackle our problem, so I see the efforts and the challenge first hand.
I can tell you that execs are very aware of the problem. Higher ups have spoken about it at townhalls, though they use softer language than I do. Since 2017 a lot of modernization attempts have been made(go cloud, use standards, use off the shelf software as much as possible), with very little to show for it so far.
Obviously it isn't all just tech that causes this, culture has a big part to do with it.
It feels like the scenario in the phoenix project almost, it'd be funny if it wasn't so serious.
I think it represented poorly. It's more than just code in one system. It's systems built upon systems built upon systems. It encompasses our network, our software deployment stack, our proprietary extensions to standards and much much more. Unknown dependencies on unknown dependencies on unknown dependencies (and it's not like we're slacking on trying to map that/keep the asset inventory up to date).
It's basically paralyzing. It's so hard to get a release done, add capacity, or add new features for our lines of business (we have dozens!).
I work in an huge enterprise. We have incredibly customized software and stacks that have not changed much for 30 years, because they did not need to.
Now the people who wrote those stacks and who understand them are retiring/quitting. Kids coming out of school don't want to learn these systems, nor do people off the streets. You can only pay people to come out of retirement so many times to keep the plant running. This is above and beyond mainframes, and is intertwined deep in the code that powers every single application that runs the plant today.
We can't run off the shelf software on-prem, a huge level of customization is needed to bring it in.
We cannot pivot quickly to new things or support new languages.
We really struggle to add new features/releases and add new software to drive revenue. The IT overhead that just goes into keeping the plant running every day is astounding.
This is what I think of when I hear technical debt.
Going down this road did give us advantages for a long time, but now we're in an enormous crisis. It's not an insurmountable challenge, but I would be surprised if there aren't a lot of large companies who are brought down by their technical debt as faster moving competitors move around them. I certainly feel that unless we get our act together, we will be disrupted.
I actually have never seen it's kubernetes security platform.
If it's using RQL for that I would take that as a redflag that it won't support much customization or logic that would allow you to tailor it to your organization.
Prisma cloud (the cloud monitoring part) is not a great product. It lags pretty far behind cloud provider capabilities.
I also got the email that orca probably sent to everyone in their CRM about this, and while I didn’t need any reason to think less of prisma, I now associate Orca as a competitor and probably an earlier call than palo alto for cloud.
You're responsible for managing the server in beanstalk, but it's not far off. I suppose it's just an earlier generation of the same idea. WHat I mean is, beanstalk runs on EC2 instances that you are responsible to make sure are patched, configured correctly and have everything you need for your application to run.
Fargate/Cloud Run are probably better serverless examples - you bring a container and config and the cloud provider will handle the rest.
I mean, what are we really calling serverless. Many serverless platforms, like fargate allow you to bring a container image, and whatever happens in that container image is non of fargate's business.
I agree with many of the points made though, and admit I am writing this reply mostly because the ckick baity headline got me.
This was a great read, thank you for sharing. I deal with identity and federation problems all day at work because I am one of those annoying enterprise customers.
We’re just getting our external openid connect capability enabled and I’m excited to start getting everything moved over. We’re also moving all our internal apps over to openid connect for auth as well, exciting times.