Comment by diognesofsinope
8 months ago
> "we've implemented all best practices, contracted out the hard parts to world-renowned experts, and had third party audits to verify that - there was nothing more we could do, therefore it's not our fault"
The amount of (useless) processes/systems at banks I've seen in my career that boil down to this is incredible, e.g. hundreds of millions spent on call center tech for authentication that might do nothing, but the vendor is "industry-leading" and "best in-class".
> It's just that understanding this explains a lot of paradoxes of cybersecurity as a field. It all makes much more sense when you realize it's primarily about liability management, not about hat-wearing hackers fighting other hackers with differently colored hats.
Bingo. The same situation for most risk departments at banks or healthcare fraud and insurance companies.
I thought risk at a bank was going to be savvy quants, but it's literally lawyers/compliance/box-checking marketing themselves as more sophisticated than they are. Like the KYC review for products never actually follow up and check if the KYC process in the new products works. There's no analytics, tracking, etc. until audit/regulators come in an ask, "our best-in-class vendor handles this". All the systems are implemented incorrectly, but it doesn't matter because the system is built by a vendor and implemented by consultants, and they hold the liability (they don't, but it will take ~5 years in court to get to that point).
Beginning to understand what "bureaucracy" mechanically is.
The fun part of bank bureaucracy is you get to experience it 10x worse if you actually work at one.
I once worked on a global, cross-asset application. The change management process was not designed for this and essentially required like 9 Managing Directors to click "approve release" in a 48 hour window for us to do a release.
We got one shot at this per week, and failing any clicks we would have to try again the next week. The electronic form itself to trigger the process took 1-2 hours to fill out and we had 3 guys on the team who were really good at it (it took everyone else 2x as long).
Inevitably this had at least 3 very stupid outcomes -
First we had tons of delayed releases. Second the majority of releases became "emergency releases" in which we were able to forego the majority of process and just.. file the paperwork in retrospect.
Finally, we instructed staff in each region to literally go stand in the required MD delegates office (of course the MD wouldn't actually click) until they clicked. The conversations usually went something like this "I don't know what this is / fine fine you aren't gonna leave, I'll approve it if you say it won't break anything / ok don't screw up"
What's funny is that checklists in hospitals have been shown, empirically, to be massive life-saving devices.
cyber perhaps not so much...
Checklists solve the problem of forgetting specific details. They work very well in situations where all possible problems have been enumerated and the only failure mode is forgetting to check for one.
They do not solve the problem of getting people to think things through and recognize novel issues.
There are some jobs you can't do well. You can do them adequately or screw them up. Checklists are helpful in those jobs.
Checklists work well in high stress situations where you cannot forget a step (medicine, aviation).
A checklist in a security incident? Probably helpful.
A security checklist to satisfy auditors and ancient regulations? This is an entirely different kind.
Yea, the problem most often in computer security checklists is misapplication of the checklist.
I do cyber security related stuff for the finance and they have some of the dumbest checklists ever.
A more recent one I got was
"We only allow the HTTP verbs 'GET' and 'POST', your application can only use that and the verbs PUT, PATCH, and DELETE cannot be used.
After not replying 'are you fucking stupid' I said
"You do realize that you are using a RestAPI application and that these verbs can go to the same interface to modify the call in different way? Not only would we have to rewrite our application which would probably take months to years, you would have to rewrite tons of applications on your side to make this actually work."
You get these dipshit auditors from other firms that pick up some 'best practice' from 2003 and put it in a list then get a god complex about it needing to be implemented when they have absolutely zero clue why the original thing was called out in the first place.
For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application.
3 replies →
Checklists are a good tool for making sure you don't forget something. They're a terrible replacement for actually thinking.