Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Employees Use Software That IT Hasn’t Approved

hbr.org

Post reply on HN
Print view View original

281–290 of 326 posts

Re: When Employees Use Software That IT Hasn’t Approved

#281

Post by maxxxxx »

Aeolun wrote: post #275
Shivetya wrote: post #180

Earlier quoted context omitted.

I have rarely found that they need admin rights on a day to day basis unless the tool is badly designed. I have one software delivery platform that requires full admin rights, it cannot write just to the user configuration! However developers are very good at presenting it otherwise. Myself, I have run into issues where admin rights were needed, again always because of some poor installer. USB has been blocked as wel…

Even if you need admin rights only once a week, if it takes a day to get them you waste 20% of your time.

On Windows you often can't even predict if you need admin rights for something. I have had plenty of cases when I tried something and couldn't get the f...ing thing to work. Then try with admin and suddenly it works.

Re: When Employees Use Software That IT Hasn’t Approved

#282

Post by thwarted »

richk449 wrote: post #258
twunde wrote: post #212

Earlier quoted context omitted.

The problem may actually be compliance requirements. SOC2/HITRUST/SOX all mandate the removal of admin rights from computers, mandate an approval process w/ manager approval. Regulated industries, especially banking have more security-related compliance requirements causing a lot of the pain. Unfortunately from a security perspective devs and system admins are probably the highest risk targets since they typically ha…

> SOC2/HITRUST/SOX all mandate the removal of admin rights from computers, mandate an approval process w/ manager approval I’ve heard this before, but never with any detail. Can you explain further, or point to a resource? For example, clearly SOX doesn’t say that nobody can have admin rights - because IT does. And I highly doubt that the law says that only departments with IT in the title can have admin access. So w…

tyingq summed it up tersely pretty well in the sibling comment. Specifically for SOX, it is all about financial information, but that information is stored and manipulated using computers, so IT related controls end up being part of it. It's easy to get away with sourcing your controls from an industry standard list of controls appropriate for SOX, but these are often significantly behind the times and don't acknowledge the state of the art.

These things are all based around "controls", which sometimes can be specified locally and some times are set by outside entities.

In my experience (SOX evidence collecting, and SOC control writing and evidence collecting), a well written control is one that covers the bases without being overly prescriptive or ambiguous. In the case of admin rights on computers, it is more useful to have the control be worded as "Only appropriate people who have legit reason to have high levels of access do" and the audit step is confirming and providing evidence that the people who do are documented and approved as having it for specific reasons, and that people who aren't supposed to have it don't have it.

I've run into crappy controls quite a bit. It's easier to push back on these when you're determining the appropriate controls than it is when you're the sucker who has to collect the evidence that doesn't, and won't, exist. Authentication and authorization controls are often some of the worst. A less useful/less meaningful control is one like "all accounts must have passwords and all passwords must be at least 12 characters long and be composed of a mix of alphanumeric and at least two punctuation characters".

The goal is to say "yes, we do this, and here's the proof" without any qualification.

Sorry, none of our accounts have passwords because we disable password authentication and use ssh public keys for authentication with two-factor via Duo. If you say that, you don't satisfy the control as worded (because none of your accounts have passwords, you can see this in the shadow file and sshd has PasswordAuthentication no, and this is difficult to explain to people who are not familiar with ssh, which is, unfortunately, a significant portion of the people who end up being put on audit projects). If you say that they do have passwords, you're lying/misrepresenting, which isn't good for an audit either. If you say you don't but have compensating controls, this doesn't look as good as it could because it is called out with an addendum/explanation and is a potential exception that needs extra consideration.

These controls should be worded more like "all users have their own accounts and accounts are authenticated using secure methods" with sub-controls specific to the environment/company saying things like "password policy is based on NIST suggestions as of YYYY-MM-DD and enforced via ". The point of the controls is to detect, catch, and re-mediate anomalies, it is for this reason that the controls need to be adjusted as standards change and the state of the art moves forward. The specifics and rationales for why something is in place is for policy documents, which means people usually don't understand why a control is worded the way it is and poorly worded controls make for really rough, drawn out audits.

Back in 2015, I previously talked about a specific experience preparing for SOX. https://news.ycombinator.com/item?id=9025958

Re: When Employees Use Software That IT Hasn’t Approved

#283

Post by oceanghost »

user5994461 wrote: post #183
oceanghost wrote: post #113

Earlier quoted context omitted.

I worked at a very bad company, where IT was aggressively incompetent, and mean about it. At best they were negligent, at worst they actively interfered with anyone who they thought was a threat, which included anyone who was more intelligent than them, which was virtually everyone since the company was full of senior EE/ME/RF/CS folks. And I mean incompetent-- our network would go do down for hours, every day, and t…

Why would you stay for years in a company like that? It's so dysfunctional and toxic.

Firstly, we had an exciting product to work on. Also, for selfish and foolish and stupid reasons? First of all, I was young. This was my first big gig. Most of all, it was fun. It was fun to keep winning against a determined enemy. At the time in the area I was in, we were considered to be one of the best software groups in our geographical locality. There wasn't really anywhere to go. The employer always ranked as one of the best in the county. Lacking humility, I thought it was simply my intelligence that brought the wins, not a mixture of my intelligence and mostly good luck. I can't imagine how many times I almost got fired but didn't for some reason.

To look on the bright side, my boss was amazing, a truly unique individual whom I thought so much of, I asked to be the godfather of my child.

Despite the chaos of the IT team, almost everyone I worked with was great. Everyone I met was really good at something, but I learned a lot from the people around me and had the opportunity to mentor a young engineer who ended up far exceeded me, which was rewarding in itself. I have several life-long friends from that company. People who have been with me through a messy divorce. A particular friend, when my wife left, called or texted every single day for six months-- just out of the goodness of her heart. The text was always the same, "Hey, wanna get some coffee? How are you doing today?" There are beautiful people working in even the most toxic places.

When I wasn't learning about engineering, I was learning about optics, about politics, and about the real world, and once again, I was winning, which was intoxicating.

So why ultimately did I stay? Because it was comfortable being the smartest person in the room. Because it was fun having latitude enough to start my own department? Because it was fun being engaged in this real-life game and winning? Because I'm crazy?

Things got far nastier than I went into. Once the IT department was openly trying to get me fired, things got personal. Really personal. It would have been easier to move on, but, I hate being bullied. Allow me to repeat myself, I HATE being bullied, and that's what this was in the end, organized harassment.

Through a set of unusual circumstances, I ended up befriending the main IT guys wife-- the man who decided he could play with my life for no reason at all, and his wife had a crush on me. So I and slept with her, and I am still sleeping with her four years later. To quote that great boss of mine, "Revenge is a dish best served every day."

Re: When Employees Use Software That IT Hasn’t Approved

#284

Post by ErikAugust »

alecco wrote: post #174
noir_lord wrote: post #76

Earlier quoted context omitted.

> It's like they get pet projects in their head from reading an article in a magazine and get locked into it. It's not like that, it's often exactly that. I'm extremely fortunate in that while my boss sets the goals he never specifies how they should be achieved. That means I get to implement them as we need them. I'll never underestimate the value of smart management :).

>> It's like they get pet projects in their head from reading an article in a magazine and get locked into it. >It's not like that, it's often exactly that. And it usually is sold also from within from know-it-all primadonnas who want to climb the ladder. Or at least put something "spectacular" on their CV.

I feel like Harvard Business Review articles are a form of keyword stuffing. Combinations of buzzwords when googled bring up a bunch of big consultancy websites.

Re: When Employees Use Software That IT Hasn’t Approved

#285

Post by alkonaut »

user5994461 wrote: post #185
alkonaut wrote: post #176

Earlier quoted context omitted.

Out of curiosity, what's the benefit of me doing bad things in a VM, instead of on my own machine - assuming the VM has full access to the same networks and data as the physical machine? Unless the VM is somehow sandboxed it's just another box on the same network. So the same reasons for me not being admin on the physical machine (e.g. to not be able to download and run untrusted software because it might spread some…

Of course the VM is isolated. That's exactly the point of a VM. An account inside a VM will only let you play in that VM. Whereas your account on the host is available and automatically granted access to all machines, fileshares and services on the active directory network. If it got admin rights, then you've got admin pretty much everywhere.

> Of course the VM is isolated.

Let's assume for the sake of discussion that to do what I need to do I not only need to install the program that requires priveleges, I also need a few of my company network drives mapped, access to some company systems, internet access and so on.

Re: When Employees Use Software That IT Hasn’t Approved

#286

Post by TeMPOraL »

nitwit005 wrote: post #267
TeMPOraL wrote: post #224

Earlier quoted context omitted.

> Yes, there are confidential data, but it shouldn't be any real customer data. Right?!? But it might be. Whenever you're doing software other than for purely internal use, you have a customer that gives you sensitive data which devs absolutely need access to - like requirements for the software you're building!

If you're handing customer data to the developers, it's basically already leaked. Most companies limit who can examine things and get customer sign off first.

Let me reiterate: unless you're doing purely internal tooling, everything about how the software you're making should look and work is essentially sensitive customer data.

Re: When Employees Use Software That IT Hasn’t Approved

#287

Post by TeMPOraL »

protomyth wrote: post #239
TeMPOraL wrote: post #224

Earlier quoted context omitted.

> Yes, there are confidential data, but it shouldn't be any real customer data. Right?!? But it might be. Whenever you're doing software other than for purely internal use, you have a customer that gives you sensitive data which devs absolutely need access to - like requirements for the software you're building!

Keep that on the biz, locked-down side of the network.

I.e. keep JIRA in one network, keep your IDE in the other?

Re: When Employees Use Software That IT Hasn’t Approved

#288

Post by hnick »

dasil003 wrote: post #114
esoterica wrote: post #104

Earlier quoted context omitted.

There’s nothing wrong with a block Dropbox policy. The problem here is a failure to establish a standardized method of transferring files in and out of the company.

And what if two companies standardized methods are incompatible?

USB sticks usually, in my experience.

Re: When Employees Use Software That IT Hasn’t Approved

#289

Post by ownagefool »

DEADBEEFC0FFEE wrote: post #262
ownagefool wrote: post #199

Earlier quoted context omitted.

Your problem statement does make it sound like you need a CRM, but I do wonder why is has to be a big CRM with a big consultancy, and why IT aren't delivering it? Who's going to run the thing afterwards? Will the bigdogs deliver something that you can maintain, or is that generally against their own interests? Finally, who's gonna secure all this customer data? Are they taking that on as part of their remit? They rar…

I expect the significant discounts offered to NFPs has some bearing on this decision. Having been involved in IT management of NFPs, the low price is a significant draw, and the total lack of internal skills is rarely able to counter this. If you don't have some sort of architecture function, technical risk management, application management, and data management these projects simply won't deliver value.

Fair enough. Do they usually complete on the cheap, or do they turn the screws after delivery?

Re: When Employees Use Software That IT Hasn’t Approved

#290

Post by ownagefool »

count wrote: post #257
matchagaucho wrote: post #223

Earlier quoted context omitted.

An IT culture that's built their budget and staff around managing a datacenter with on-premise software lacks incentive to support cloud implementations.

What IT org with that kind of focus has time to learn an entirely new stack? And nobody wants to add headcount to an overhead org...

Whilst true, the on-prem based implementations are usually insecure and manual as fuck, which largely means the IT function simply stopped learning.

Also, the move to cloud is largely driven by said IT teams failure to deliver much, you could a the CRM on-prem, but we know they'll likely take a few years to fail to deliver it.

Post reply on HN