Hacker News new | ask | show | jobs
by bramblerose 1147 days ago
> It's just laziness towards doing it the right way.

Just because "least privilege" is "the right way" from a (some?) technical perspective, doesn't mean that it's the right way from a business perspective. There is a real, and significant, business cost to needing to wait for access and not being able to discover data (and thus not even knowing that you need to ask for access).

3 comments

Definitely worth keeping in mind the business needs. I'm not going after "well designed security that meets the business needs". I'm calling out lazy security that cuts corners because doing it well takes time and effort.

That being said, there is also a real, significant business cost to leaking sensitive information. If users are frequently waiting for access or unable to discover data, that's a failure in understanding the users needs and/or failing to test those needs in UAT during implementation. Convenience should never trump security, in this context.

Knowledge workers aren't usually hired to be process-following automatons confined strictly to requirements known in advance by their superiors, but rather to creatively design, optimize, and troubleshoot the processes around them. Which requires visibility into how they are actually operating in production, and not just in the imagination of some other designer.

That doesn't excuse exposing things publicly, or to employees who have no plausible business purpose, but relatively permissive structures internally are good.

Salesforce's worst design principle is hiding things people don't have access to.

And it cuts to the heart of the agility you're describing -- if I can't know what I'm NOT seeing, then how can I discover I need to request it?

From this perspective, Salesforce is absolutely engineered for top down "Identify the process, create a set of permissions that allows it, then apply those permissions to the appropriate set of people" design.

As opposed to bottom-up discoverability (e.g. I can see that I don't have access to this thing, somewhere) + RBAC requests for a permission set I learn I need.

>if I can't know what I'm NOT seeing, then how can I discover I need to request it?

This is so true. I feel that most of our closed source scripts are duplicates because you can't search for existing internal projects in our system. If you know it's there you can ask for it, but you usually don't, so you build your own.

One company I worked at had default org-wide GitHub visibility.

It made me realize everyone else was using source control completely wrong. Game changer to be able to look at or copy the source for {anything}.

Most places I’ve worked default to letting everyone read any source. Is that not the norm? Agree that it’s a game changer for those willing to use it, but I find that last qualifier to be surprisingly rare.
I'm calling out lazy security that cuts corners because doing it well takes time and effort.

Time and effort cost money. It's possible that the value gained is less than the cost, and so therefore isn't worth it. Of course, it's also possible they don't understand the value gained until there's a scandal.

A great example of the "CIA Triangle," and how it's not always easy to balance the legs of confidentiality, integrity, and availability.
Someone here said: “Be permissive for people, least privilege for servers.”