Hacker News Reader

Comment by the8472 | Hacker News Reader

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

View on HN

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

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.

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

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.

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

That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.

I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.

I'd explain why you're misconceiving the tradeoff, but we have a policy against omitting policy rationales, and that's that. ;)

>Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.

Well, it's supposed to only be a handful: the handful of people who know more than the policymaker.

> 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

Very often part of the purpose of the policy is to end debate about how to handle an issue, and to get the “crackpots and geniuses” to STFU.

That's not a motivation that policy sponsors usually want in print, though.

It’s almost as if there is no single technique for reaching all members of a target audience...

You need two documents, minimum. One with rules, others to justify them.

I think it depends on the person. For myself (and probably many people with the hacker mindset), I don't like useless rules and want a justification or I tend to think I "know better" which is of course sometimes true and sometimes not.

I used to think this was a rebellious streak but perhaps it's just from that desire to know how things work. Absent a reason, I'll find my own.

A lot of people don't care either way, rules make life simple so there's no need to complicate it further.

> On the other hand, a reason can convince people,

Policies very often have official reasons for just this propaganda purpose, but it's worth noting that the reasons cited for the purpose of motivating compliance are often chosen for the specific purpose of how well they are anticipated to motivate compliance and not how well they reflect the actual reasons the policy is adopted, and thus they often are not in practice a good tool for understanding how to challenge the policy effectively.

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

There's more to it than that. There are two separate groups of reasons:

1. The reasons a policy was put in place. ("Why did we do this?")

2. The reasons a policy succeeds. ("Why is this a good idea?")

You can know the reasons in group 1. But nobody cares about those. What matters are the group 2 reasons, and they were probably never known in the first place.

I was working in a throughout computing problem domain. About the time I got there, some asshole in HR had everyone’s (current and former employees) tax information on their work laptop and lost it. Tens of thousands of people, because there was no policy against putting such information on portable equipment.

And as far as I’m aware there still isn’t. No, within the year (might have been a lawsuit, I can’t recall) new policy became everyone’s machine has whole disk encryption. Including engineering. So my software was instantly 30% slower, and a half a day added to setting up any new machine. I don’t know how many times I had to explain that it’s not our code that got slower, the whole company got slower. It took me months of work to get us back to zero.

That person should have been run off and anyone in their dept caught doing the same should have been put on probation. I don’t know how you figure that it’s “fair” for everyone to suffer for the mistakes of one member. In a small team setting? Perhaps. But not for something like this.

Thinking about the policy in terms of punishments and fairness isn’t the right approach. Something happened that cost the company a great deal of resources, so the company is trying to prevent such a thing from happening again.

It may be doing a poor job at that, but it isn’t punishing you and it isn’t about fairness. It’s trying to prevent a future mistake. And because the company is a single entity, it is the company choosing to bear the cost.

It may make your job harder and they may not modify its expectations properly after imposing this cost on you, but that isn’t punishment or fairness. It is poorly thought out systems.

"Something must be done. This is something, so we will do it."

so your job involved none of the company's IP?

I don't know if encryption was the right policy response here (it seems to be a very good idea regardless due to theft/hacking possibilities), but I'm OK with this sort of policy sometimes.

Full disk encryption is a fair response because it won't be feasible to enumerate every type of situation that results in sensitive data being put on the laptop (such as temporary files or source code). If someone was going to just add tax numbers to a list it leaves a lot out; if they say "sensitive data" it leaves a lot open to interpretation; if they list everything they can think of it'll be impossible to properly comply while still getting work done.

So perhaps it was a heavy handed approach handed down mindlessly, but it could also have been someone looking at the bigger picture. Knowing the intent as others said would help.

You act like this policy was intended as punishment instead of as risk mitigation.

Mandating full disk encryption is easy for IT to enforce. A policy of not putting sensitive information on laptops is valuable, but difficult to enforce. Encryption is a sound way to reduce the risk of harm when that policy is inevitably broken.

Full disk encryption also been the company-wide policy of everywhere I've worked in recent memory, fwiw.

I’d add another that’s nice to have:

3. The outcome we expect. (“What will happen if this is working.”)

How does that differ from choice #1, 'The reasons a policy was put in place. ("Why did we do this?")'?

A policy's expected outcome is correlated with why a policy was put in place.

A policy might be put into place because a single event. The expected outcome can drastically differ depending on who writes the policy. E.g. it could be "this type of attack won't succeed again" vs. "even if this or a similar kind of attack succeeds it won't expose our entire data"

That's my exact point. A policy isn't random but created for an effect.

As an examnple: If an HN disclosure leaks passwords and email addresses into the public domain, imposing a policy control is _meant_ to have the effect that such a disclosure would not happen again, or if it does to have a limited scope.

Or policy writers copy n pasted something off web.

In my Mega Tech corp, we have security team that has created hodge podge of conflicting policies. For example, they ask some applications to be internal network only and other are accessible via web. But they can never provide their reasoning and get annoyed when we ask any details.

The worst part is that some of their policies directly contradict with each other. For example, policy is to never run as root inside docker container but then there are some applications provided by them that runs as root in docker. And every time you use it, you have to remind them that these are their apps or else they will ask you to stop running it as root.

Finally, I had pleasure of talking with one of their Security and Compliance expert. They could not even knew how to list file perms in Linux, and other a lot of basic ideas. This person clearly had memorized interview questions but had clearly no understanding of those concepts.

Only way to hide their incompetence is act elite and don't explain their reasoning.

> Or policy writers copy n pasted something off web.

The fact that policy sponsors are more than anything looking to a single answer to end debate and establish uniformity is why policy writers can copy and paste stuff from the web and get it adopted as policy without a clear rationale connected to the organization’s particular circumstances. They aren't conflicting, alternative explanations.

> A reason can be argued against while a policy must just be followed.

And if you talk to people directing policy efforts (who are often not the ones writing, or even actively choosing, policy but generally are the ones formally signing off), you often don't have to dig very far to find that settling discussions is as important of a rationale for the policy as any of the others. This obviously conflicts with ideals like continuous improvement, but it's true lots of places including those with nominal commitments to continuous improvement.

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.

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.

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.

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.

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?

Unfortunately, they have an audited policy of not hiring sarcastic people.

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.

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

Actually, you are both half right half wrong. If GP was talking about internal audit, they are correct. If you are talking about external audit, then you are correct. If you are lumping both audit functions into one, you are both wrong. Big difference between the two.

Not responding to this, just using the example. It can be easily argued that adding AV software to (some) servers increase their surface attack and reduce their security (leaving alone performance and other AV issues).

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.

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.

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.

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.

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.

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

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.

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

Perhaps I was thinking of verifying API tokens. But see, I made a mistake while reasoning about security code. Don't make me do that more often than necessary, one day it'll go wrong.

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

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.

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

Reply on news.ycombinator.com