- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
You must log in or register to comment.
Title author must get paid by the comma
It’s correct, just a bit confusing to parse at first. Like a garden path sentence, but with commas.
I would replace the 2nd comma with a colon
No, Okta: senior management, not an errant employee, caused you to get hacked
Wellhehasabetterpaymentplanthan**methen
I just came to note that seeing Mastodon inserts instead of Twitter in an Ars article makes me feel warm and fuzzy.
That’s where infosec people are these days.
The biggest threats to infosec and ethics violations are from management, not the rank and file.
Yeah, cause the rank and file have to work overtime to fix that shit when it breaks
This is the best summary I could come up with:
While the postmortem emphasizes the transgressions of an employee logging into a personal Google account on a work device, the biggest contributing factor was something the company understated: a badly configured service account.
In a post, Okta chief security officer David Bradbury said that the most likely way the threat actor behind the attack gained access to parts of his company’s customer support system was by first compromising an employee’s personal device or personal Google account and, from there, obtaining the username and password for a special form of account, known as a service account, used for connecting to the support segment of the Okta network.
“During our investigation into suspicious use of this account, Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury wrote.
Accessing personal accounts at a company like Okta has long been known to be a huge no-no.
Unlike standard user accounts, which are accessed by humans, service accounts are mostly reserved for automating machine-to-machine functions, such as performing data backups or antivirus scans every night at a particular time.
The breach, however, underscores several faults that didn’t get the attention they deserved in Friday’s post.
The original article contains 473 words, the summary contains 203 words. Saved 57%. I’m a bot and I’m open source!
How does Okta not have systems like support systems like what was breached with the credentials behind a VPN as well? A system like that really ought to be on a secured network. We have so many systems at work that are VPN required and it’s mostly those where sensitive data lives.
I could see my own company falling victim to this kind of attack. I guess for a targeted attack all personal Google accounts or other password managers are a vulnerability. I’d cry if my work blocked the chrome password manager.
I stopped using browser built in password managers a long time ago. Third party password managers that require 2FA on a timeout are where it’s at. All of my passwords are available on all web browsers and my mobile device as necessary
Session network binding on its own seems pretty damn basic.
Dont bind to IP or other browser fingerprinting.
For security and privacy, my IP address and browser fingerprint change every 60 seconds. Its so fucking annoying when I get false-positive logged out every minute “for my security”
I hesitate to ask, but, why do you have your IP change every minute? You seem to have a very atypical usecase
I was oversimplifying. So the user agent and other browser setting change every 60 seconds using the chameleon add-on.
The IP doesn’t automaticallychanges, but I use a VPN. Often on shitty internet where packet loss routinely spikes to 30% (considered normal for most ISPs), I often have to disconnect and reconnect to the VPN, which causes the IP to change.
