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

Thanksgiving 2023 security incident

blog.cloudflare.com

Post reply on HN
Print view View original

311–320 of 336 posts

Re: Thanksgiving 2023 security incident

#311

Post by dylan604 »

Symbiote wrote: post #275
dylan604 wrote: post #238

Earlier quoted context omitted.

> All those guys wearing headphones in the office have brought in CDs to play in their laptop CD drives? I've worked for large media companies where this is exactly the only way to have music available. The production network was blocked from accessing the www. To ensure content wasn't pirated, the original media had to be used. No CD-Rs were allowed. Personal devices were kept in lockers outside the restricted areas…

Presumably the company then takes on the task of passing personal messages from outside to their staff, e.g. if a school phones to say a child is sick.

you're free to check your device as necessary. the personal device rule is for things that have cameras and storage. so a smart watch that can receive messages would be fine. we seem to think that the only way to communicate with someone is via personal device, but in the corp world there is always a corp phone on employee's desk. you could provide that number to whatever contacts you wanted, so this lame concept of passing notes is just so unimaginative on your part that it just feels like someone grasping for straws.

Re: Thanksgiving 2023 security incident

#312

Post by prg20 »

BytesAndGears wrote: post #27
marcinzm wrote: post #6

> we were (for the second time) the victim of a compromise of Okta’s systems I'm curious if they're rethinking being on Okta.

My company will only give us new laptops that are preinstalled with Okta’s management system. I am grandfathered in to an old MacBook that has absolutely no management software on it, from the “Early Days” when there was no IT and we just got brand new untouched laptops. They offered me an upgrade to an M1/M2 pro, but I refused, saying that I wasn’t willing to use Okta’s login system if I have my own personal passwor…

IT departments do not care for the musings of self-proclaimed neckbeards. The arrogance of such users to comfort to security policy is a well known risk and usually grounds for swift disciplinary action.

Re: Thanksgiving 2023 security incident

#313

Post by prg20 »

michaelt wrote: post #108
samcat116 wrote: post #46

Earlier quoted context omitted.

> new laptops that are preinstalled with Okta’s management system Okta doesn't make device management software, thats made by companies like Jamf. Okta can integrate with them but Okta isn't what manages your laptop at all. > I wasn’t willing to use Okta’s login system if I have my own personal passwords or keys anywhere on my work computer. Do not do this, its not a personal device.

> Do not do this, its not a personal device. You think nobody's logged into their personal spotify on their work computer? All those guys wearing headphones in the office have brought in CDs to play in their laptop CD drives? And that business traveller away from their partner and kids for a week+ isn't going to video call them? Or watch some netflix in their hotel room in the evening? That's so unrealistic, you coul…

> You think nobody's logged into their personal spotify on their work computer?

I don't think anyone thinks that. No one also thinks logging into a personal account on a device owned by someone else gives you any claim of ownership over it.

The computer belongs to the company. You will do what the company says you need to with their computer.

Re: Thanksgiving 2023 security incident

#314

Post by vikramkr »

2OEH8eoCRo0 wrote: post #296
vikramkr wrote: post #271

Earlier quoted context omitted.

If the usa does I don't understand why you expect we'd know about it. Also the us totally does and we do know about it - the nsa buys zero days - it's not exactly a secret lol

The same way Cloudflare can report on foreign state hackers, other countries can discover and report on ours, no?

Right- and they probably do, and they don't know it was us just like cloudflare doesn't know what country it was. For all we know that cloudflare attack was the US. I don't know why China/Russia/Iran/nk would be able to carry out the cloudflare attack without cloudflare being able to pin who exactly did it while the US is supposed to be so incompetent that we would be immediately identified and called out?

Re: Thanksgiving 2023 security incident

#315

Post by pphysch »

sodality2 wrote: post #236
pphysch wrote: post #198

Earlier quoted context omitted.

More likely: "no one has any idea what these old credentials do, so let's not touch them and potentially break everything"

Sounds like the perfect time to revoke the credentials and find out what uses them, so we can find why they weren't registered as credentials in use. Personally I'd rather do that, have a team ready, and break production for x minutes in order to properly register auth keys. I'd definitely consider a "silent" credential - a credential not registered centrally - to be a huge red flag. Either it could get stolen, or br…

> Personally I'd rather do that, have a team ready, and break production for x minutes in order to properly register auth keys.

Sure, but you aren't going to do all that when your team is juggling N other priorities. At least, it will be very difficult getting mgmt and others on board. Unless it's explicitly in the context of a recent breach.

Re: Thanksgiving 2023 security incident

#316

Post by sodality2 »

pphysch wrote: post #315
sodality2 wrote: post #236

Earlier quoted context omitted.

Sounds like the perfect time to revoke the credentials and find out what uses them, so we can find why they weren't registered as credentials in use. Personally I'd rather do that, have a team ready, and break production for x minutes in order to properly register auth keys. I'd definitely consider a "silent" credential - a credential not registered centrally - to be a huge red flag. Either it could get stolen, or br…

> Personally I'd rather do that, have a team ready, and break production for x minutes in order to properly register auth keys. Sure, but you aren't going to do all that when your team is juggling N other priorities. At least, it will be very difficult getting mgmt and others on board. Unless it's explicitly in the context of a recent breach.

Very true. Ideally the culture would be that we’re experiencing some pain now to avoid more later, so we should do it - I’d hope management was on the same page. Real world, unfortunately, often differs.

Re: Thanksgiving 2023 security incident

#317

Post by tptacek »

de-moray wrote: post #300
tptacek wrote: post #256

Earlier quoted context omitted.

What's an AV going to do about the fact that Okta got popped?

Perhaps the parent commenter was referring to the section in the report which stating the IOCs indicated that the attackers used the known third-party command and control system named Sliver. There are multiple public yara signatures for Sliver.

Ahh, that makes sense. Thanks!

Re: Thanksgiving 2023 security incident

#318

Post by JakeTheAndroid »

mardifoufs wrote: post #280
tptacek wrote: post #262

Earlier quoted context omitted.

It's not hard to get at first, either. It's the archetypical checklist audit.

Ah I think I'm just not used to those then, I hated the whole checklist busywork that we had to do even though we were barely related to the sales infra. But yeah, it was a bit like soc2 in that regard. Is there any certification that isn't just checklist "auditing"? That involves actual monitoring or something? Not sure if that's even possible

PCI is the most checklist framework around. SOC 2 can be a checklist audit, depending on how much effort your internal compliance team puts into it. I've never had SOC 2 be really a checklist in the way PCI is. SOC 2 requires you to design and write your own controls and scope in or out different aspects of the business. SOC 2 does include monitoring and stuff like that.

The difference really is point in time vs period over time audits. PCI is a point in time audit, SOC 2 is a period over time audit. So for SOC 2 you do need monitoring controls, and then they test that control over the entire period (often 6-12 months). So you are monitoring the control effectiveness over a longer period of time with SOC 2. And even PCI has some period over time controls you need to demonstrate.

From the outside all compliance will seem like checkboxes to most people once controls are established. Because really the goal for most of the business is to make sure the control they interact with doesn't break, and the compliance team will likely give a list of things that the business can't afford to have broken. Which does seem like a checklist similar to PCI. But really, only PCI is straight up a checklist, as you don't really get to decide your controls.

Re: Thanksgiving 2023 security incident

#319

Post by giancarlostoro »

BytesAndGears wrote: post #27
marcinzm wrote: post #6

> we were (for the second time) the victim of a compromise of Okta’s systems I'm curious if they're rethinking being on Okta.

My company will only give us new laptops that are preinstalled with Okta’s management system. I am grandfathered in to an old MacBook that has absolutely no management software on it, from the “Early Days” when there was no IT and we just got brand new untouched laptops. They offered me an upgrade to an M1/M2 pro, but I refused, saying that I wasn’t willing to use Okta’s login system if I have my own personal passwor…

At a former employer, the company wanted everyone's machine to have full hard drive encryption, thankfully we were on Linux and the vendor they wanted to use was not compatible. Even so, I always encrypt my installs on laptops, not so much workstations (I didn't install it, and reinstalling would be a mess) since at that point you're physically in the office building and we have more serious problems.

Re: Thanksgiving 2023 security incident

#320

Post by zelon88 »

What I don't understand is how they got access to Jira yet you still insist there was no compromise.

The very nature of Jira and Confluence (both terrible products, btw) is to collect documentation. I'm assuming it was an internal Jira/Confluence for engineering teams, but still. There have got to be addresses, passwords, service account info, all kinds of info. If it was a tech support server then it's impossible to assert that you didn't lose customer data.

So we have this double standard where you pay for this product that is designed to house your deepest secrets and most cherished organizational information, that's so important to you that you run on premises servers to keep it safe, but it's not important enough to constitute a real "beach".

You're lying. Either the server contained junk of no value in which case it wouldn't have existed in the first place, or you actually did lose something of value that you won't identify to us. Nobody sets up on-prem Jira just to leave it empty and never put secrets in it.

Post reply on HN