2,583 karma · joined February 9, 2011
[ my public key: https://keybase.io/preinheimer; my proof: https://keybase.io/preinheimer/sigs/xuqraBrBI-TAX8MtkyTCa-K8RyFslHOHT1dfAddxO1Q ]
preinheimer.at.hn
Far too many systems don’t have a zero downtime key rotation.
This all seems reasonable to me. If you want my money or things, you’ll have to use them like I suggest.
Reminds me of the whole "disney must pay" debacle.
From our side we noticed a VPN provider had a location we'd been trying to get, but had been unable to, so we started digging to find their provider. Long story short the server purportedly in some middle east country was actually 3ms away from our server in Berlin.
https://medium.com/@xianghangmi/resident-evil-understanding-...
Technical paper: https://ieeexplore.ieee.org/document/8835239
Quite a few days after work, or just on a weekend adventure I'd go to a bookstore a few blocks south of work and grab another Discworld book, and a slice of pizza from my favourite pizza shop labelled "Rays". I'd read some in a park, and explore.
I didn't know a lot of people in the city, filling days with Terry Pratchett was a great joy.
If getting a ticket one ride in a thousand is cheaper than deploying another 2000 cars to make up for the increased trip time I’d expect them to keep getting tickets.
I’m also not sure they don’t do it on purpose. Tesla self driving has an aggressive mode willing to speed and roll through stop signs. Those were deliberate, law breaking, choices.
A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to “fix” it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. “In each of these envelopes is an attack against your cipher. Take one and read it. Don’t come back until you’ve discovered the other two attacks.” The amateur was never heard from again.
https://www.schneier.com/crypto-gram/archives/1998/1015.html
The problem with actually owning hardware is that you need a lot of it, and need to be prepared to manage things like upgrading firmware. You need to keep on top of the advisories for your network card, the power unit, the enterprise management card, etc. etc. If something goes wrong someone might need to drive in and plug in a keyboard.
Eventually we admitted to ourselves we didn't want those problems.
Lacking better options I’ve turned on parental controls on my phone to block YouTube, and installed an extension to remove shorts from the site on my laptop.
I wish sites provided more real options.
Paper: https://xianghang.me/files/resi_paper.pdf Medium Article: https://medium.com/@xianghangmi/resident-evil-understanding-...
Did someone actually go and confirm your role based access control matrix is up to date and user accounts have the right access? Were all of those screenshots watermarked with timestamps?
There is work to do, whether or not auditors are doing it is another question.
In my mind getting a clean report required three kinds of work:
1. Work that actively improved our security posture. 2. Work that didn't change much, but made our security posture easier to understand. 3. Busy work.
I think for most companies all three kinds of work will be required, but you can also make decisions that will push the percentages around. SOC 2 required us to start doing an annual security table top exercise. You could sit down, run a scenario, run it as fast as you can, and come up with a few pre-determined "improvements" that would help if you actually had that problem in the future. Or you could sit down and really put work into it, and see what works well and what doesn't.
As an example in our last tabletop I "exfiltrated" some data from one of our servers, and challenged the team to figure out what I'd done. The easy way out would have been for someone to say "We'll look at the logs and figure it out", but instead I asked them to actually try and find it. We discovered that the sheer volume of logs for that system made them hard to work with. So we made some changes to make them easier to work with and repeated the exercise later.
It could have been busy work, but instead we got real value from it.
There's a fair amount of boiler plate language in these reports, and a bunch of re-stating the SOC 2 controls. I'd expect two reports (same auditors, same platforms) to be nearly identical. If they're both using AWS, Github, Stripe, Vetty, they're subbing a lot of the exact same thing out to the same companies, referencing the same set of internal controls.
Reading ours. There's a section titled $Company's Controls, followed by 20 pages listing the various SOC 2 controls. e.g.
---
CC9.0 Common Criteria Related to Risk Mitigation
CC9.1 The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.
IR-01 A Security Incident Response Plan that outlines the process of identifying, prioritizing, communicating, assigning, and tracking confirmed incidents through to resolution is accessible to all relevant employees and contractors and is reviewed annually.
---
Then there's another 20 pages of those same controls being listed, some language about how they tested the controls, and hopefully "No Exceptions Noted".
That's not going to change much between companies.
I think there's a wide spread in how that's implemented. I would certainly not describe Grok as a tool that's prioritized safety at all.
If you want to ineffectivly filter out most candidates just auto-reject everything that doesn’t arrive on a timestamp ending in 1.
One of our competitors was claiming a server in a middle eastern country we could not find any hosting in. So I figured out what that server's hostname was to do a little digging. It was >1ms away from my server in Germany.
We're in 100+ countries, and I'll stand by that claim. It's a huge pain in the neck. In our early years we had a lot of problems with suppliers claiming to be in Mexico or South America who were actually just in Texas. I almost flew to Peru with a rackmount server in my luggage after weeks of problems, that plan died when we realized I'd need to figure out how to pay Peruvian income tax on the money I made in country before I could leave.
We've also had customers complaining that a given competitor had a country we'd had trouble sourcing in the Middle East. A little digging on our part and it's less than a ms away from our server in Germany.
There should absolutely be a better answer here.