3 ms·

audits, soc 2, and all the other bs hoops the industry jumps through… for what? when stuff like this exists it’s pretty clear that large enterprises’ idea of s

audits, soc 2, and all the other bs hoops the industry jumps through… for what? 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.

doctor_eval 4y ago
Well I was forced to add password rotation to an enterprise product by a large enterprise user only a couple of years ago despite password rotation being rejected by research for a decade and no longer recommended even by Microsoft. So, yeah. Like most enterprise stuff it’s all just a bunch of boilerplate.
- Hizonner 4y ago
  Your opportunity for vengeance on something like that is to have it put up a big warning that says "This setting is dangerous and violates the guidance of the following long list of experts and government bodies: list goes here. Are you SURE you want to take this security risk?". And don't forget to log the insecure configuration every time the system starts up, too.
  - DaiPlusPlus 4y ago
    If you do that, you'll get dinged in your performance review for being insubordinate.
  - doctor_eval 4y ago
    This is the germ of a good idea. I don’t do that kind of work any more (building and selling enterprise applications) but I suspect that the way to push back is to have a document they would need to sign that transfers all associated risk to the customer. The people in charge of these companies couldn’t give a shit about research or actual good practice, but dear god they hate taking responsibility for stuff.
throwawaysleep 4y ago
I work for a security company that helps with the audit process. Nobody on my team can tell you the first thing about SOC 2. It is an external selling point, not something actually adopted by the org.
- wkdneidbwf 4y ago
  definitely. i’ve been doing startups selling to enterprise customers for a while. audits and soc 2 compliance generally do lead to improvements or caught some things we’ve overlooked, but it certainly is not comprehensive. you’re checking boxes in some horrific xlsx file so some folks at Acme Corp can check boxes in another horrific system of theirs. earlier on i tried to fight the good fight on some points and explain why it was unimportant or nonsensical in our context. that’s a brutal way to live though. i try to go with the flow and have more of an open mind these days. it’s easier for all parties involved. i just want them to write us a check.
phkahler 4y ago
>> 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.
- avalys 4y ago
  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.
  - phkahler 4y ago
    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.

doctor_eval 4y ago

Well I was forced to add password rotation to an enterprise product by a large enterprise user only a couple of years ago despite password rotation being rejected by research for a decade and no longer recommended even by Microsoft. So, yeah. Like most enterprise stuff it’s all just a bunch of boilerplate.

Hizonner 4y ago
Your opportunity for vengeance on something like that is to have it put up a big warning that says "This setting is dangerous and violates the guidance of the following long list of experts and government bodies: list goes here. Are you SURE you want to take this security risk?". And don't forget to log the insecure configuration every time the system starts up, too.
- DaiPlusPlus 4y ago
  If you do that, you'll get dinged in your performance review for being insubordinate.
- doctor_eval 4y ago
  This is the germ of a good idea. I don’t do that kind of work any more (building and selling enterprise applications) but I suspect that the way to push back is to have a document they would need to sign that transfers all associated risk to the customer. The people in charge of these companies couldn’t give a shit about research or actual good practice, but dear god they hate taking responsibility for stuff.

throwawaysleep 4y ago

I work for a security company that helps with the audit process. Nobody on my team can tell you the first thing about SOC 2. It is an external selling point, not something actually adopted by the org.

wkdneidbwf 4y ago
definitely. i’ve been doing startups selling to enterprise customers for a while. audits and soc 2 compliance generally do lead to improvements or caught some things we’ve overlooked, but it certainly is not comprehensive. you’re checking boxes in some horrific xlsx file so some folks at Acme Corp can check boxes in another horrific system of theirs. earlier on i tried to fight the good fight on some points and explain why it was unimportant or nonsensical in our context. that’s a brutal way to live though. i try to go with the flow and have more of an open mind these days. it’s easier for all parties involved. i just want them to write us a check.

phkahler 4y ago

>> 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.

avalys 4y ago
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.
- phkahler 4y ago
  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.