5 ms·

> but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. The

> but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. And appending "exceptions may be granted for equivalent or better processes" to requirements would also help. I was faced with a password "security policy" that pretty much only whitelisted SHA2 + salting for password hashing. We were using a time-hard (not memory-hard though) password hashing function instead and several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference. It's terribly demotivating to have to argue with people enforcing policy they do not understand and erodes any willingness to engage with those policies instead of seeing them as theater and working around them.

edoloughlin 6y ago
several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference The auditors' policy? Are you sure? An auditor's job is to check if you're doing what you say you should be doing. If you're arguing with an auditor then you're essentially arguing with your own organisation without any hope winning the argument.
- ath0 6y ago
  Not really a fair assessment. An auditor's job is often to check if you're doing what an external standard says you should be doing (SOC 2 => AICPA trust principles; FedRAMP => NIST 800-53, etc.). Unfortunately, these external standards may be written vaguely and while you may have policies that define X as Y, the auditor doesn't have to accept your answers. For example, when PCI requirement 5 says "Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).", your policy may say "antivirus is not required inside containers that run on platforms like GKE, as these are not commonly affected by malicious software." It's very likely you'll have a discussion about your interpretation of that requirement.
  - deleted 6y ago
    [deleted]
  - edoloughlin 6y ago
    So every team gets to argue with the auditors? Seems like the people writing the policy should do that so there's one argument instead of n.
    - ath0 6y ago
      Sounds like you've mostly worked in perfectly-sized and structured corporations, where the auditors and policy-writers were perfectly connected to changing product, business and technical needs; well-staffed with policy writers and architectural governance committees who have the time, skill and background to have regular, even-handed tradeoff conversations when these issues occur, and where the engineering teams are prepped and able to engage in those conversations well. Are they hiring?
      - edoloughlin 6y ago
        Unfortunately, they have an audited policy of not hiring sarcastic people.
  - viraptor 6y ago
    PCI also suggests a hardened system image, for example CIS and consistency checking like Aida. I'm getting tired of explaining that CIS (and other) "hardened" images just flip a few options and install lots of crap that can actually increase risk. E.g. You don't need cron? Haha, it's scored in the CIS benchmark, now you're running it. I don't mean to just single out CIS as bad, but recently I learned that Ubuntu CIS docker images contain Aida, cron, and sysctl configuration. Yes, you pay for that. I'll be making fun of that for a long time.
  - hobs 6y ago
    No, they check if you're doing what an external standard that you purport to follow is being followed. You dont have to claim that you follow some standard that actually makes you less secure, you are just not going to be able to sell to clients who are also sheep in this manner (read: everyone.)
- the8472 6y ago
  Multi-national corporation. The auditing department and the ones writing the policy aren't even on the same continent. So it is all internal and "our own policy" in a sense, but so far removed that I might as well be talking to an external bureaucracy. By coincidence we later learned about the contact person within our own sub-org who would be responsible for forwarding change requests on those policies. The auditors themselves didn't see that as their responsibility, even when you explicitly asked them to do so.
  - PeterisP 6y ago
    It's definitely not the responsibility of auditors even if you explicitly ask them to do so. In essence, the auditors are there to evaluate whether certain assertions are true. E.g. the company is asserting that they are doing X because they have a policy that X must be done. If it turns out that the internal communication within the company is screwed up and some teams are following the policy and some are not, then the claim is false and the core job of the auditors is to detect and note this. Detecting such discrepancies the main reason for why such an audit (often external,, and if internal, then mostly independent, not reporting to the audited departments) is requested. It's not their job to fix this or decide who's in the wrong - the initial claims are found to be false, and that's not okay no matter if the policy should be changed or will be changed. It does not matter how (and if) the company negotiates changes to the policy, it does not excuse the misleading claims of "X is being done" if actually the company is doing Y instead of following the stated policy. When the management has fixed this (or claims to have fixed this) one way or another, then the auditors should re-evaluate whether the claims are true now.
    - the8472 6y ago
      Compliance serves a purpose and is not an end unto itself. So if you only enforce the rules even when they achieve the opposite of the underlying goal then you are goodhart's law personified. So even assuming for the moment that it's not the auditor's job to evaluate the rules themselves then at the very least they should escalate all the way back to those who write the rules if an inconsistency between rule and underlying goal is found. There's no point of having a separate channel for such communication because a particular issue for which it is relevant cannot be resolved (without missing the underlying goal) until the rule is clarified.
hnick 6y ago
> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like when web companies disable your account and won't say exactly why. Not gonna take the risk you prove them wrong, are they? It would be nice though if all laws had a purpose included.
- whatshisface 6y ago
  On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.
  - ardy42 6y ago
    > On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt. Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook. This seems like one of those areas where there are unavoidable tradeoffs: * clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas. * clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions. * policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.
    - whatshisface 6y ago
      You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.
dustingetz 6y ago
As explained in the book "Moral Mazes: The World of Corporate Managers", the goals are unstated on purpose, due to the Principal Agent Problem.
hinkley 6y ago
Goal and value statements are a hallmark of effective leadership, and even people who don’t know this seem to know it on an unconscious level. It can make some people who don’t have “it” very defensive if you try to address the elephant in the room. I’m not going to tell you how to accomplish the goal, but I’m going to tell you what we are trying to do and the manner in which we want to get there.
pavon 6y ago
There is also the concern of letting perfect be the enemy of good. For every developer that correctly integrates a better password storage scheme, there will be dozens that use something worse. Consistently standardizing on something that is good enough might be a net win and avoid the overhead and risk of verifying that other approaches are as good or better. Easier to evaluate/amend the policy periodically than to evaluate every single password storage instance. This is a common issue in policies. If you try to accommodate every possible situation then the policy becomes incredibly complicated and difficult to understand let alone follow. If you have a simple policy that is easy to understand, there will inevitably be exceptions where the policy doesn't make sense.
thaumasiotes 6y ago
> I was faced with a password "security policy" that pretty much only whitelisted SHA2 + salting for password hashing. We were using a time-hard (not memory-hard though) password hashing function instead and several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference. You can comply without downgrading by just applying the SHA2 hash after your time-hard hash.
- the8472 6y ago
  That's possible but it would mean unnecessarily changing security-critical code. I'd again have to make sure to use constant-time comparisons of the different output, migrate the existing data or require users to reset their passwords and so on. All to tick a box. Ultimately we pretty much did that, switched to scrypt which is based on sha2 and pointed to the standard saying it's sha2-based. But that does not change the fact that the policy imposes incorrect requirements on teams. SHA2 is not appropriate for password hashing.
  - thaumasiotes 6y ago
    > I'd again have to make sure to use constant-time comparisons of the different output Why? What would this mean? You have a flow like this: 1. User sends "password". 2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done. 3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password. But even in step 3, you don't need constant-time comparisons. What purpose would they serve? Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH. But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.
icedchai 6y ago
Are the people "enforcing" the policy going to actually look at the code? Probably not. Just tell them what they want to hear so they can check their box. If it comes up again, just tell them it was a mistake. Sorry, I thought we were using SHA2... we're really using more-secure-thing.
orblivion 6y ago
I wonder if there's a value in simplicity of policy. Just like with coding. Sometimes you decide not to add more features or make something more efficient because it would make the code harder to maintain. If you have one blanket policy at your company, it cuts down on conversations. Case in point: you said that auditors don't understand the benefit of better hashing functions. If the policy allowed for "equivalent or better" maybe it would cause the confusion in different departments with different auditors many times over. If this is the case, though, I agree that this should be listed as the rationale, because I can imagine it's demotivating when people are required to do a worse thing for no apparent reason.
heelix 6y ago
For every dumb rule, you always find out someone did something even more stupid.

edoloughlin 6y ago

several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference The auditors' policy? Are you sure? An auditor's job is to check if you're doing what you say you should be doing. If you're arguing with an auditor then you're essentially arguing with your own organisation without any hope winning the argument.

ath0 6y ago
Not really a fair assessment. An auditor's job is often to check if you're doing what an external standard says you should be doing (SOC 2 => AICPA trust principles; FedRAMP => NIST 800-53, etc.). Unfortunately, these external standards may be written vaguely and while you may have policies that define X as Y, the auditor doesn't have to accept your answers. For example, when PCI requirement 5 says "Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).", your policy may say "antivirus is not required inside containers that run on platforms like GKE, as these are not commonly affected by malicious software." It's very likely you'll have a discussion about your interpretation of that requirement.
- deleted 6y ago
  [deleted]
- edoloughlin 6y ago
  So every team gets to argue with the auditors? Seems like the people writing the policy should do that so there's one argument instead of n.
  - ath0 6y ago
    Sounds like you've mostly worked in perfectly-sized and structured corporations, where the auditors and policy-writers were perfectly connected to changing product, business and technical needs; well-staffed with policy writers and architectural governance committees who have the time, skill and background to have regular, even-handed tradeoff conversations when these issues occur, and where the engineering teams are prepped and able to engage in those conversations well. Are they hiring?
    - edoloughlin 6y ago
      Unfortunately, they have an audited policy of not hiring sarcastic people.
- viraptor 6y ago
  PCI also suggests a hardened system image, for example CIS and consistency checking like Aida. I'm getting tired of explaining that CIS (and other) "hardened" images just flip a few options and install lots of crap that can actually increase risk. E.g. You don't need cron? Haha, it's scored in the CIS benchmark, now you're running it. I don't mean to just single out CIS as bad, but recently I learned that Ubuntu CIS docker images contain Aida, cron, and sysctl configuration. Yes, you pay for that. I'll be making fun of that for a long time.
- hobs 6y ago
  No, they check if you're doing what an external standard that you purport to follow is being followed. You dont have to claim that you follow some standard that actually makes you less secure, you are just not going to be able to sell to clients who are also sheep in this manner (read: everyone.)
the8472 6y ago
Multi-national corporation. The auditing department and the ones writing the policy aren't even on the same continent. So it is all internal and "our own policy" in a sense, but so far removed that I might as well be talking to an external bureaucracy. By coincidence we later learned about the contact person within our own sub-org who would be responsible for forwarding change requests on those policies. The auditors themselves didn't see that as their responsibility, even when you explicitly asked them to do so.
- PeterisP 6y ago
  It's definitely not the responsibility of auditors even if you explicitly ask them to do so. In essence, the auditors are there to evaluate whether certain assertions are true. E.g. the company is asserting that they are doing X because they have a policy that X must be done. If it turns out that the internal communication within the company is screwed up and some teams are following the policy and some are not, then the claim is false and the core job of the auditors is to detect and note this. Detecting such discrepancies the main reason for why such an audit (often external,, and if internal, then mostly independent, not reporting to the audited departments) is requested. It's not their job to fix this or decide who's in the wrong - the initial claims are found to be false, and that's not okay no matter if the policy should be changed or will be changed. It does not matter how (and if) the company negotiates changes to the policy, it does not excuse the misleading claims of "X is being done" if actually the company is doing Y instead of following the stated policy. When the management has fixed this (or claims to have fixed this) one way or another, then the auditors should re-evaluate whether the claims are true now.
  - the8472 6y ago
    Compliance serves a purpose and is not an end unto itself. So if you only enforce the rules even when they achieve the opposite of the underlying goal then you are goodhart's law personified. So even assuming for the moment that it's not the auditor's job to evaluate the rules themselves then at the very least they should escalate all the way back to those who write the rules if an inconsistency between rule and underlying goal is found. There's no point of having a separate channel for such communication because a particular issue for which it is relevant cannot be resolved (without missing the underlying goal) until the rule is clarified.

hnick 6y ago

> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like when web companies disable your account and won't say exactly why. Not gonna take the risk you prove them wrong, are they? It would be nice though if all laws had a purpose included.

whatshisface 6y ago
On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.
- ardy42 6y ago
  > On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt. Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook. This seems like one of those areas where there are unavoidable tradeoffs: * clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas. * clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions. * policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.
  - whatshisface 6y ago
    You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.

dustingetz 6y ago

As explained in the book "Moral Mazes: The World of Corporate Managers", the goals are unstated on purpose, due to the Principal Agent Problem.

hinkley 6y ago

Goal and value statements are a hallmark of effective leadership, and even people who don’t know this seem to know it on an unconscious level. It can make some people who don’t have “it” very defensive if you try to address the elephant in the room. I’m not going to tell you how to accomplish the goal, but I’m going to tell you what we are trying to do and the manner in which we want to get there.

pavon 6y ago

There is also the concern of letting perfect be the enemy of good. For every developer that correctly integrates a better password storage scheme, there will be dozens that use something worse. Consistently standardizing on something that is good enough might be a net win and avoid the overhead and risk of verifying that other approaches are as good or better. Easier to evaluate/amend the policy periodically than to evaluate every single password storage instance. This is a common issue in policies. If you try to accommodate every possible situation then the policy becomes incredibly complicated and difficult to understand let alone follow. If you have a simple policy that is easy to understand, there will inevitably be exceptions where the policy doesn't make sense.

thaumasiotes 6y ago

> I was faced with a password "security policy" that pretty much only whitelisted SHA2 + salting for password hashing. We were using a time-hard (not memory-hard though) password hashing function instead and several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference. You can comply without downgrading by just applying the SHA2 hash after your time-hard hash.

the8472 6y ago
That's possible but it would mean unnecessarily changing security-critical code. I'd again have to make sure to use constant-time comparisons of the different output, migrate the existing data or require users to reset their passwords and so on. All to tick a box. Ultimately we pretty much did that, switched to scrypt which is based on sha2 and pointed to the standard saying it's sha2-based. But that does not change the fact that the policy imposes incorrect requirements on teams. SHA2 is not appropriate for password hashing.
- thaumasiotes 6y ago
  > I'd again have to make sure to use constant-time comparisons of the different output Why? What would this mean? You have a flow like this: 1. User sends "password". 2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done. 3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password. But even in step 3, you don't need constant-time comparisons. What purpose would they serve? Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH. But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.

icedchai 6y ago

Are the people "enforcing" the policy going to actually look at the code? Probably not. Just tell them what they want to hear so they can check their box. If it comes up again, just tell them it was a mistake. Sorry, I thought we were using SHA2... we're really using more-secure-thing.

orblivion 6y ago

I wonder if there's a value in simplicity of policy. Just like with coding. Sometimes you decide not to add more features or make something more efficient because it would make the code harder to maintain. If you have one blanket policy at your company, it cuts down on conversations. Case in point: you said that auditors don't understand the benefit of better hashing functions. If the policy allowed for "equivalent or better" maybe it would cause the confusion in different departments with different auditors many times over. If this is the case, though, I agree that this should be listed as the rationale, because I can imagine it's demotivating when people are required to do a worse thing for no apparent reason.

heelix 6y ago

For every dumb rule, you always find out someone did something even more stupid.