Oh, never underestimate the incompetence of clients' compliance gremlins to mangle actual regulations into impossibly contradictory checklists and requirements.
That said, we have had trick security questions before too.
I've been told we'll fail a pci audit unless we go into the datacenter and replace all the blue cat5 with a different colour. Nothing is apparently too silly.
Yeah you don't even have to get silly before you reach impossible.
One client's compliance jobsworth demanded a tour of our datacentre (AWS) to inspect physical security for low grade employee PII (email, name). I was younger and poorer then so bent over backwards to still get told "er, no thank you" from Amazon.
Client's security weren't happy with third party security certifications (of which AWS has most) so they reported up that we were likely hiding something devious. I think they'd had some sort of physical breach in the past but it just makes using an external service supplier untenable if you're going to treat security like it's 1970. I think we still got that contract but it took high-level meetings to ELI5 modern infrastructure's features and limitations.
We've had others rock up at third sales meetings (pretty advanced) saying they now "need" source and data design before they sign. One asked me to get a criminal record check. To reiterate, we're storing light employee data and everybody knows and understands that, but some people just seem to treat all data exchange as nuclear waste.
I've worked in a datacenter that had a few different networks that must not touch each other. One of the precautions we took was color coded ethernet cables. A blue cable plugged into a red server will cause an incident if someone sees it; even if the other end is another red server 1U down.
That's pretty much the story. It came in as a high priority issue with no context. I asked for clarification, he asked if we wanted to fail the the audit. I changed them to red and he wrote a thing about we were more secure now.
Quite likely. Considering the "bugs" that exist in hardware which the security auditor has no control over which is a "forced to trust hardware" exercise, before even looking at software bugs, it seems like a job to keep someone occupied whilst most of the population drinks from the kool aid decanter.
After hearing the phrase "encryption requires system administrator access" as the reason why there was no WPA2 network at my previous university for quite some time, this reads like many a true tale.
Personal ancecdote:
Our backend was exposed using a cloudflare tunnel (we call cloudflare, they expose it with security scanning, etc.)
Auditor wants to see firewall rules on our IP addresses, except we don't have IP addresses, we were small enough that the default Azure general shared outbound network worked. (Think CGNAT). No amount of explaining this would check the box.
Solution: add a public IP to our prod env, unassigned to anything, with firewall rules. Audit passed.
Another one. We once had to get a solar car inspected by the state for registration. They needed to hook up a tube to the exhaust for an emissions test. We just pointed them to the battery's cooling exhaust.
Another solar car, a police officer just came out to inspect it like a "kit car". He asked, "It has 4 wheels, right?" And we were like, "yeah for sure, if you count the steering wheel." And he went ahead and checked the box.
My favourite is the nineteen meetings it took to convince a security team to approve the use of unencrypted HTTP for the certificate revocation list endpoint.
No amount of RFC references, live demos of “see, www.google.com does it with HTTP also” would tick the checkbox.
“We have a security standard, sir.” over and over, for months.
Couldn't you just give them an empty rule set? Like, make it a nice official looking report.
I had to certify a low speed vehicle using a government test procedure. It called for all test equipment to be calibrated within the last year. I had built some of the equipment myself specifically for the test, though. I measured the relevant performance characteristics in a thermal chamber (oscillator drift was the only possible source of error), documented it on a piece of paper to stick in the office filing cabinet, and printed some "Calibrated on xx/xx/xxxx" stickers.
A purely hypothetical and fictional story: A programmer once complied with a requirement to produce a firewall policy by creating an allowlist policy that was effectively, 0.0.0.0/0 but with addresses such as the following removed:
- 100.64.0.0/10
- 192.0.0.0/24
- 192.88.99.0/24
- 192.0.2.0/24
- 198.51.100.0/24
- 203.0.113.0/24
- 233.252.0.0/24
The significance of these networks is left as a punchline for the reader.
> The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST-
TEST-NET" for use in documentation and example code. 233.252.0.0/24
SHOULD be used in conjunction with the [RFC2606] domain names
example.com or example.net in vendor and protocol documentation.
Addresses within 233.252.0.0/24 MUST NOT appear on the public
Internet.
Well dang I should've thought that through before asking the question. Should've realized up in the 220-230 range was going to be mcast reserved. Can't help but acknowledge the irony in not throughly reading the docs for the documentation reserved range though.
Other side of the problem: I've seen a vendor which moved their infrastructure to Cloudflare ask us to whitelist Cloudflare's entire set of IPs on our security platform.
They were politely told no. (Telling people no politely is a significant portion of IT operations, as it happens.)
At a large tech company, we were planning to offer a certain service to the US government. In order to comply with FedRAMP, we added some extra proxies to the infrastructure running the Gov workloads so that they would have the dedicated IP addresses required for compliance.
Having worked in security for a number of years there are 2 types of security people.
Type 1: Are super sharp guys that have spent time in half a dozen areas and went to security because it was the only way to get the exposure they want to so many different things, they often also are associated with red team and the kind of people you want as security engineers.
The second type is the type of people who focus on "security" who end up focusing on compliance and audit and are responsible for security theater. They may have a lot of certs especially the CISSP and are business savvy. They are also the most likely to do things like in the original post because they don't actually understand computers and what they are securing.
The 2nd type give the 1st (which I hope I am) a bad name, and unfortunately are more common than not.
The reason for this is that security has to be across every piece of the stack, if you have a single weak point then your entire stack is compromised. As a result you either have to be able to operate in all layers of the stack, which is very hard to get good at and understand and takes a lot of time and effort, or you trick yourself (and people who don't know what they're talking about) into believing that you can focus on just the "security" pieces of each layer of the stack. Which unfortunately means that things end up dogmatic, cargo culty, and vendor saturated because you don't have the understanding to make intelligent decisions only the understanding to follow "Da Rules" of security.
I went through the SOC 2 (Type 1 and 2) process in the last few years and I nearly quit with the amount of useless, ill-informed nonsense I had to submit to.
The regulatory controls themselves are mostly reasonable, but seeing the competency and rigor (lack thereof) of the auditors was completely demotivating.
The only “huh?” Moment I remember was when they asked me whether we used MFA, and then I proceeded to talk about how we have TOTP, WebAuthn, etc for our “2FA” as I happened to refer to it, and after talking for a minute about it, the auditor said, “just want to clarify, do you have any MFA configured”… at that point I realized how much they were just blindly marking checkboxes. So I just said “yes we do.”
I've been the internal poc for a soc2 before. The external auditors were all lawyers. As such what mattered was strict compliance with the wording of the standards. With them what we didn't say was nearly as important as what we di
I see a lot of people say this. Maybe I've just been lucky but all of my security audits have been sensible and easy.
The only exception was at one company, an auditor flagged that weren't in compliance with "antivirus software is installed on all storage servers," and as they defined it, that would have included our Docker image repositories and S3 buckets. They gave us some suggestions on how we could do this, for example a Lambda-based solution that would scan all files uploaded to S3. We just said "no" and they dropped it.
I dunno, I also feel it's fake. When I compare the experience dealing with bullshitters aginst the one in the original post, it has a different feel. The post is too "internet creative writing" in tone an substance: where every argument, counter-argument, rebuttal and retort perfectly mesh to create the ideal shower-argument-esque narrative. Particularly as it feels like the same person is writing both sides.
In real-life you either cut it off politely to save your own time, or it would just descend into a mudfight.
If it makes you feel better I had a similar, but not so exciting, situation happen to me in the past. So it's not entirely outside the realm of shit that happens. What does seem super fake is the doubling down, having it an SOP/SSP, and the tripling down without some crazy amount of escalating.
For example my experience went sort of like this:
Low Rent Auditor: Please supply a list of username and passwords for xyz systems.
Me(ccing boss and internal secops): No. Why are you asking me for that? <Links to internal SOPs, guidelines, basic common sense, etc>.
Low Rent Auditor: We need this for x box on y form. <attached>
Me (ccing their Sr. Auditor): That's not what that is asking for. Here's a copy of the PAM config. <attached>
Meanwhile my issue with it is that the story got so popular online, given it feels like a normal day with most security auditors. I have to have worked with dozens of guys just like this. The only thing consistent is that they are the ones being listened to.
The only way it could be more satisfying is if there was one more update gleefully telling everyone about how the auditor got clapped by PCI or Visa or whoever.
It’s a trap. You reply with the policies that prohibit what he’s asking. If you don’t have any, that’s a finding. If you do and violate the policy, that’s a finding.
When the premise is that the auditors are idiots, you have a problem. ;)
https://news.ycombinator.com/item?id=12434215 (with an actual thread)
https://news.ycombinator.com/item?id=2820567 (with an actual thread)
https://news.ycombinator.com/item?id=7456068 (with an actual thread)
https://news.ycombinator.com/item?id=2796423 (with an actual thread)
https://news.ycombinator.com/item?id=20333488
https://news.ycombinator.com/item?id=19540665
https://news.ycombinator.com/item?id=12432018
https://news.ycombinator.com/item?id=11360499
https://news.ycombinator.com/item?id=19400843
https://news.ycombinator.com/item?id=7458926
https://news.ycombinator.com/item?id=12416581
I doubt this story is real, for whatever that's worth.