A good chef does not take a job at McDonald's. Someone who's good at security or a good sysadmin does not take a mind-numbingly repetitive job of periodically auditing/scanning customers for compliance and filling out an endless sea of checkboxes. Yet we all require these folks to scan/audit us quarterly. The end result is burger flippers coming into your kitchen with a dictatorial checklist, telling you the only correct way to cook pasta is to use salt and oil in the pot, while you the chef who knows better wants to use salt an no oil. But ultimately, they're the ones with the checklist that file the report that allows or disallows your company to get paid. The end result is brainlessly jumping through hoops to satisfy brainless requirements that usually include incorrect assumptions or premises, making uniformity the ultimate goal rather than security correctness.
<anecdotes> <li>I inherited an IT dept that had an *actually* insecure PPTP vpn server facing the internet, with outdated firmware and a single user account that all users shared, using the company name as the password. I phased it out, in favor of a new cisco IPSec VPN server, with randomly generated 256-bit PSK, in aggressive mode. Failed PCI compliance test because aggressive mode + PSK, which could possibly be brute forced if PSK is weak. So I had to jump up and down write a letter, call three people, submit a form indicating please excuse us and justify the reasoning, we have an unguessable strong 256 bit randomly generated PSK, to get the scan to pass. And then the problem came back again next quarter. I would have to repeat the letter writing phone calling form filling procedure every quarter if I want to keep that IPSec VPN server up. Their dumb test procedure fails the stronger security solution and passes the actually insecure solution.</li> <li>So I replaced that VPN with an SSL vpn, using startcom signed cert. Everyone in the world accepts startcom as a trusted CA, except our dumb PCI people. Compliance fail, we are required to use a different CA, because they're too dumb to care or do anything about updating their dumb scan script.</li> <li>We had a godaddy wildcard cert available, so I used that. PCI fail, because they don't know what hostname we're using, and it's merely a wildcard cert, so their dumb script can't reverse-engineer and figure out our hostname from the cert subject, and they don't have any option for us to simply specify our hostname. They require our IP address to serve up a cert with subject whose forward dns results in our IP address. End result: Also cannot use wildcard cert, because they're too dumb.</li> <li>So I had to go buy a new cert. Got it all up, got scans to pass. Next thing I know, POODLE comes out. So we disable SSLv3, we're now immune to POODLE. If any client tries to fallback to SSLv3, the firewall refuses to accept it - however unfortunately, cisco has not yet released the IOS version that *announces* the cipher suite without SSLv3 in it. So, PCI fail, due to POODLE. Their dumb script only checks what cipher suite we announce, and doesn't bother trying to actually establish an SSLv3 connection with us. Cisco TAC engineer is well aware of the problem, and informs me preemptively that we will still fail our PCI scan despite having SSLv3 disabled. Because they've heard this so many times already from other customers having the same stupid problems with the same stupid PCI auditors. The auditors cannot fix their scripts; instead Cisco TAC engineers inform customers that we need to contact the auditors and repeat the phone call & letter & form procedure to bu y ourselves another 3 months, for cisco to release an updated version of IOS which can announce the cipher suite without SSLv3.</li> </anecdotes> _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
