>> when stuff like this exists it’s pretty clear that large enterprises’ idea of security and risk management is all made up to sound good and lacks teeth.
For some reason your comment reminded me of a huge human failing ;-)
Imagine some security consultant running down a checklist of common problems. Number 15: Does your software have any hard coded passwords. Engineer actually thinks of one briefly, but dismisses it in his mind because "it's there for reason XYZ and this guy doesn't know anything about out XYZ need, so it's not what he's talking about" and verbally says "no."
I can't tell you how many apparently smart people have similarly failed to plainly answer plain questions due to this kind of thinking. Not sure how guilty I am of course, but it drives me nuts when other people do it and I notice.
The problem is that the security checklists are often flawed in the other direction - they're poorly targeted towards the system under review, technically out-of-date, and wielded by rigid and inflexible thinkers who won't take anything but "No" for an answer.
A few years I filled out a checklist for a customer (for my entirely cloud-based business) that had the question "The company's file server is secured against physical intrusion: Yes or No?"
then...
"All physical access keys to the file server are under control of company management: Yes or No?"
Blech - what am I supposed to answer here?
In another example, a checklist asked us to verify that our codebase did not contain any instances of libraries implementing the MD5 algorithm. Of course, it was used in a number of places for innocuous, non-cryptographic purposes, which were hard to change due to backward compatibility. This one we couldn't squirm out of - and it took us three months to overcome the fact that we "failed" the security checklist because of that one question.
So, nearly every engineer who is forced to go through one of these stupid checklists learns they have to first transform the question into the mental space of their system, and then transform the technically correct answer into the mental space of the checklist author before determining exactly what to write down.
I think your MD5 scenario is a good example. Just answer the question honestly. The fact that the auditor doesn't understand it not being a security concern is a different problem that needs to be addressed. Yes, its painful, but working these issues IMHO is the best long term solution.
For some reason your comment reminded me of a huge human failing ;-)
Imagine some security consultant running down a checklist of common problems. Number 15: Does your software have any hard coded passwords. Engineer actually thinks of one briefly, but dismisses it in his mind because "it's there for reason XYZ and this guy doesn't know anything about out XYZ need, so it's not what he's talking about" and verbally says "no."
I can't tell you how many apparently smart people have similarly failed to plainly answer plain questions due to this kind of thinking. Not sure how guilty I am of course, but it drives me nuts when other people do it and I notice.