Hacker News Reader

Comment by kspacewalk2 | Hacker News Reader

>Lawyers finding problems and trying to stop things from happening instead of finding solutions.

Sounds like they're doing their jobs, which is to protect your future selves from your current selves. Sure, finding solutions is great, but faulting them from finding problems and slowing things down until solutions are found is odd.

Yes, security or IT does sometime have to act as a reality check in an organization that has over-hired over-zealous but under-experienced go-getters who want to "move fast and break things". They are a vital counterweight that makes ambition productive, instead of allowing it to wreck the organization's reputation.

View on HN

I'm going to interject my own experiences and note that some legal advice seems excessively risk averse and honestly just defaults to "no" and lazy. I suspect that's what the OP might have been referencing.

I know we're generally concerned with the folks playing fast and loose with the rules here, and that's 100% true, but. I find in big orgs sometimes it's far more on the other end of the spectrum.

And sometimes security or IT just play it excessively, and never allow anything just to make sure they can't be blamed for anything:

"No, you can't improve the situation with the Linux servers that hasn't been updated since 2013 because those servers don't exist in our roadmap, and therefore there's no policy document that we can lean on to make any decisions. So the servers stay in their miserable state until we can phase over all customers that use those servers to some other product eventually. In a few years. Hopefully."

Note that the above isn't fiction, but exactly what happened a few months ago. Luckily I managed to transfer to a team that didn't have to deal with those servers.

See this all the time - for example, zealous dev "if I had production DB read/write I could get things done so much faster."

Sure, but the production DB has an incredible amount of PII and we are audited out the wazoo, but even if that weren't the case and it was totally fine, all it takes is you being careless with your credentials one time and the company's hosed or we have a massive breach, or some rogue employee encrypts the data with ransomware. So, yes, it would make you faster, and no, you can't have it. It's insane how often I have this type of conversation and insane how often I am the bad guy in it.

The solution is replicating the DB and scrubbing the PII. Then the dev can go wild.

This is a solution oriented approach instead of a lazy ass covering approach which I think the GP was referring to. The job should be finding risks and then figuring out how to work around those risks. Very rarely are there no solutions, most of the time it is due to general laziness or in aptitude where someone can find risks but they do not find solutions.

> The solution is replicating the DB and scrubbing the PII. Then the dev can go wild.

In this particular example, often this isn't remotely feasible, either from a business logic standpoint (I can think of plenty of fintech examples), lack of qualified DBA/sysadmins, network admins, cloud cost constraints, methods and controls to ensure to auditors that devs cannot access production data - none of this is trivial, and often to the dev it seems "silly" they may need to wait a few hours for something they could technically access in a few minutes, but acting like these solutions have no tradeoffs or are always worth doing suggests a lack of knowledge as to how these things actually work in a business and on a development team. It certainly isn't always laziness, and I'd even say it's not laziness that often at all.

In your example, I am not saying you need to give the dev access to prod. But you should be working with the dev to figure out why he needs access to prod and figuring out what needs to happen to make the end goal happen. Getting read/write access to prod isn't the end goal, the dev is trying to accomplish something and they see direct access to prod as the solution.

My point wasn't that lawyers/security/IT/whatever shouldn't do their job. It's that their perspective should be focused on helping the company achieve whatever it's trying to do.

Reply on news.ycombinator.com