32 ms·

This is exactly extremely common. In my company there is this constant battle about the devs having admin rights on their machines. We need admin rights to do o

This is exactly extremely common. In my company there is this constant battle about the devs having admin rights on their machines. We need admin rights to do our job. We have had dozens of meetings explaining the situation but IT can’t come up with a solution so the devs go around security because they have no alternative if they want to finish their work . Same with Dropbox. They block it but we have suppliers who use Dropbox. So the result is that people download confidential files from Dropbox on their home computers or phones and transfer them to their work machines. In my view security shouldn’t be isolated at corporate headquarters but they should be close to the end users so they see what users need to do and help them to balance security with getting things done. They can’t just block stuff without providing alternatives or they will either hurt the business or they will be circumvented.

7748394773639 7y ago
I have my own PC strapped under my desk connected to public Wi-Fi. I use it to do all my work. My company pc is left turned on but disconnected, sitting on top of my desk to dissuade suspicion.
- maxxxxx 7y ago
  I have a WiFi router hidden so we can do some specific network testing. We also have a consumer DSL line so we can test on a network where IT doesn’t block random stuff. It’s not even much of a secret. Everybody local knows this stuff and every six months a guy at IT headquarters throws a fit, doesn’t provide an alternative and gets ignored. I have thought about sending them recordings of previous meetings so we don’t have to repeat the series of same meetings every six to twelve months.
  - miahi 7y ago
    We had the same kind of "hidden" router at my previous employer, as we had a team of ~10 developers who needed a lot of different access to different servers and between eachother. We put the name of another tenant in the office building as the SSID :). After about a year the network through that router started to slow down. When we checked why we realized that we had more than 40 wifi clients, as other (non-dev) teams learned about the network through the grapevine and actually the new employees from sales (the neighboring office) were told to connect to that network directly - as the process to connect to the "normal" network was too much of a hassle.
    - maxxxxx 7y ago
      The funny thing is that after a recent remodel the router got moved and we don’t know where it is. It still works but nobody knows the exact location. It may be in the ceiling or the floor.
      - iaw 7y ago
        I hope it never needs to be reset.
      - geggam 7y ago
        LOL reminds me of a very old bash.org http://www.bash.org/?5273 http://www.bash.org/?5273
        pickle-wizard 7y ago
        That reminds me about the story of a University that an old DEC VAX that got walled up during a remodel. Machine kept running and no one notice. A decade later another remodel came along and they tore down the wall to find the machine just happily running.
        antod 7y ago
        I remember an old Netware version of that story.
        pickle-wizard 7y ago
        You know, maybe it was Netware. My memory has some bitrot in it after all these years.
- esoterica 7y ago
  Does your company know you have their IP on your personal device (and are sending company communications over public WiFi)?
  - 7748394773639 7y ago
    It’s not highly confidential information. Mostly its to use a machine with adequate ram. Besides I’m using end to end encryption instead of being MITMd by their third party ‘security’ gateway
- megaremote 7y ago
  I have a VM on my mac to go on the work network, using ethernet, while I do everything over wifi.
- brokenmachine 7y ago
  Don't you need shared drives, etc? We can't connect to anything internal from outside, there is VPN access but it seems a step too far to use that all the time.
ConfusedDog 7y ago
I entirely agree with you. This is the same idea in the Greatness video by David Marquet (https://www.youtube.com/watch?v=OqmdLcyES_Q https://www.youtube.com/watch?v=OqmdLcyES_Q) Try to control everything is just futile. I think hiring and retaining best people is the best countermeasure to this sort of things.
rb808 7y ago
I think most of the reasons for admin rights are no longer valid. Its easy to change user environment variables and lots of applications can be installed as a user. Why would you need admin rights? Dropbox/googledrive is a huge security hole that is definitely blocked at most companies I work at.
- beart 7y ago
  One example off the top of my head: It used to be (may still be) the case that you needed admin rights to install and run the Windows Subsystem for Linux. Sure, you might not need this to do your job, but IT is not really in a position to decide that. It could be that WSL greatly increases your productivity.
  - maxxxxx 7y ago
    Exactly. Unfortunately windows admin rights are not very granular so if you do anything serious you end up needing full admin soon.
    - basch 7y ago
      Application control is granular if you use SCCM or Intune and Application Guard. https://docs.microsoft.com/en-us/windows/client-management/mdm/windowsdefenderapplicationguard-csp https://docs.microsoft.com/en-us/windows/client-management/m... There is absolutely middle ground if you have the time and resources to get it running smoothly.
      - maxxxxx 7y ago
        I am sure solutions could be found. But it would require effort from IT to understand what we are doing and finding real solutions.
  - esoterica 7y ago
    You can ask IT to install it for you. You don’t need to install it yourself.
exabrial 7y ago
I really wish some big shots in the security world would write an ISO standard or something stating how harmful blanket 'block Dropbox' policies are for the reasons you list.
- maxxxxx 7y ago
  And they should commit to talking to my VP every time the VP commits us to working with a supplier who uses Dropbox and also commit to finding solutions that allow us to get our work done within deadlines.
- ubermonkey 7y ago
  The "dumb" here isn't even limited to "block Dropbox." Lots of my customers have blanket "block everything that could plausibly be used for file sharing" policies, and explicitly include services literally AIMED at corporate/B2B data exchange like Citrix's ShareFile. No, we don't have an internal FTP site. No, I won't set one up for you. We use Sharefile for distribution so we don't have to do that. Your IT blocks it? Yeah, that's dumb. Go talk to them; it's not my problem. We're not going to do customized delivery channels just because your halfwit CIO decided to block every site with an upload button.
  - maxxxxx 7y ago
    The funny thing is that they block Dropbox but then there are plenty of shady upload sites that aren’t blocked. We don’t use them because we think they aren’t secure but our IT guys would have no problem with that.
    - natch 7y ago
      That highlights a problem woven through the industry which is that the IT department isn’t always the sharpest team in the building, even on security matters.
      - maxxxxx 7y ago
        They are completely outsourced and offshored. Only a few competent people are left.
protomyth 7y ago
I'm still not sure why developers aren't on their own network for development. Have a red box / blue box type system at the developers desk. Given modern networking, it wouldn't actually be that hard to setup and keep development / integration / system tests (or what names you use) away from a locked down production would not be such a bad thing[1]. Having some dual homed file shares wouldn't be that hard either. 1) I would probably still use different terminal color schemes, but being in front of a different physical box might be quite a good thing.
- maxxxxx 7y ago
  I have proposed that. Give us a network where we can do what we want do and protect the boundaries of it. So far no luck.
- lightbritefight 7y ago
  Developer data can still be confidential/sensitive, so you still need to monitor and control this second network with many of the same restrictions as the main one. You still have most of the same risks to compensate for, like data exfiltration and cryptolocker, etc. It doesnt introduce that many positives for lots of admin overhead, not just in maintaijg two distinct networks, but also in ensurijg interoperability when needed.
  - protomyth 7y ago
    Developer data can still be confidential/sensitive Yes, there are confidential data, but it shouldn't be any real customer data. Right?!? Frankly, given best practices from professional developers, stuff like cryptolockers just aren't an issue (blank the machines). Developers need admin, so building a network for them is actually a lot easier.
    - TeMPOraL 7y ago
      > 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!
pmorici 7y ago
Shouldn't this kind of thing be a problem for the managers to address? If you just circumvent this kind of nonsense instead of addressing it head on it just proliferates and allows the people who promote it to think they are doing an acceptable job. At minimum you should inform your direct manager of the situation so they can address it or accept the consequences that the work that depends on the restricted resource won't get done w/o circumventing company policy.
- maxxxxx 7y ago
  Management knows.
- lnanek2 7y ago
  I've heard security management say it is their job to say no all day. They definitely don't care about preventing work getting done. They will only get fired if a data leak occurs, etc.. Preventing work won't even ding their promo outcomes.
  - Endy 7y ago
    If work happens and somehow anything goes wrong, they get fired. Therefore it's a matter of self-preservation to get everything possible frozen.
  - dreamcompiler 7y ago
    Incentive structures always tell the tale, and people have a nasty tendency to figure them out quickly, regardless of what their mission statement says on paper.
  - jpindar 7y ago
    The most secure network is one that no one uses. Therefore the goal is to make the network as difficult to use as possible.
  - pmorici 7y ago
    That's the point of telling your manager and letting them deal with it. Ultimately the business needs to make money or show some result. If the company policies prevent that then their cost benefit needs to be evaluated and that is a manager's job. "No" is fine as long as a conscious decision is being made with the consequences in mind. That way your security person isn't saying no to Dropbox access they are saying "No" to the successful implementation of the CEO's #X priority for the quarter or "No" to 10% additional revenue for the company or whatever.
jnosCo 7y ago
I'm one of those assholes that makes security policy. I deal with the same requests. The problem is, I write up a proposal identifying the risks associated with the exemption, along with minimum and recommended compensating controls. This then gets discussed among IT Management, where it is usually decided it's too much overhead, and to just deny the request or if the user can scream loud enough, allow it outright and get some director to sign something. The third oft-used response is ignore the problem and hope the user finds their own work around so we can get back to the 13 projects we're somehow expected to complete this quarter.
- maxxxxx 7y ago
  I feel you. The whole setup is dysfunctional by design.
- AstroJetson 7y ago
  Me too, we try, but it's too easy for people in the management chain to push a fix into the "Too Hard Bucket" (tm) and it dies.
- novok 7y ago
  It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'. Not letting people do their jobs, or in how fast they can do their job. Employees are a captive audience, and if there was competition they would probably chose something else.
  - TeMPOraL 7y ago
    > It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'. I tend to summarize my experience with IT in large companies and universities like this: IT is evaluated in "how secure things are", or "whether things are not broken". The only sure-fire way to ensure a system is secure and not broken is to make it completely unusable, so that people don't use it. If people don't use a system, they can't break it!
oceanghost 7y ago
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 the problem lasted almost a year. It got so bad our "source control" became yelling "Whose got the latest main.cs?!" and walking it over with a USB key. I realized we needed to disintermediate the IT group, and my boss was supportive. I ended up establishing our own, parallel IT department with a business cable line, some routers, and NAS devices. I outsourced any task to any cloud service (this was over a decade or so ago when that was somewhat unusual) — eventually hiring our own IT person even. People would ask for access to our network because it was more reliable :-) Then things got vicious. They actively interfered with our group, trying to get us fired (they had some success with this previously). They were able to get our IT guy fired. Things just went on that way for years. They'd find some way to make trouble, and then we'd route around it. Once they even took my computer for two days, denied they had it, then returned it but locked me out of it. I was certain this was part of some scheme to get me fired, so I turned the computer off, zeroed the hard drive, and req'd a MacBook to work on. They all eventually got fired when someone took note of their gross incompetence. One of their replacements was eventually fired for embezzling, proving that despite thinking we had the worst IT department anyone could imagine-- we really didn't.
- user5994461 7y ago
  Why would you stay for years in a company like that? It's so dysfunctional and toxic.
  - mywittyname 7y ago
    Judging by the statement that he worked with some high-level EE/CS/ME people, I assume the actual job was pretty interesting or cutting edge.
    - noobiemcfoob 7y ago
fancyfish 7y ago
I've consulted for a big bank which blocks most file sharing sites and also blocks you from attaching scripts, server logs, etc to emails. Luckily, S3 is not blocked. I set up a bucket and have them upload to the bucket, which I then download on my own computer. Mission accomplished. Just getting free Windows applications procured and installed on the company laptop takes several layers of approval, emails back and forth, etc. Also the lovely forced password resets every 2 months. This is true for the banks I've worked with/at. Security systems actively block you from the tools you need to do your job, let alone get the job done in an efficient manner.
- padraic7a 7y ago
  I work for a local government department. Must try your S3 workaround. I swear sometime I think our IS dept are playing jenga, they just pull random services at will. Today I couldn't update our website because the proxy settings allowing me access the login page somehow changed without notice. Last week they blocked USB access to machines without telling anyone who backs up to external 8tb drives. Tomorrow who knows what they'll decide. And it doesn't make for a secure environment! Everybody tries to figure out workarounds. Staff actively try to undermine security policies. It's a total disaster.
- BonesJustice 7y ago
  Be careful. I work for such a bank, and even secure traffic is MITM’d when possible. There are data loss controls in place to analyze outbound traffic for things like source code. Just because you’ve circumvented IT’s blocks doesn’t mean you won’t land yourself in hot water.
- OkGoDoIt 7y ago
  I used to work at a place like that, it was incredibly frustrating and time-consuming. So I came up with a solution that works even if S3 is blocked: I built https://github.com/OkGoDoIt/UploadAndPaste https://github.com/OkGoDoIt/UploadAndPaste and set up SCP file hosting on my own server that listens on port 443. (They blocked most outgoing connections to non-standard ports and did MITM sniffing on any port 80 traffic, so this was the only way to get through.) Then I could just easily "paste" a file to a my remote server and download on the other machine via a url.
Shivetya 7y ago
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 well and you can guess it, cannot do their work. If they need admin rights all the time then put those particular machines on a protected network and not allow any other business work to occur there.
- mcshicks 7y ago
  I think it really depends on what kind of development you are doing. I worked at an IC company, and among other things we developed (and tested) USB drivers for our devices. We installed them on literally hundreds of windows machines for testing before they were signed/ whql approved. This happen all the time. So really no way do our jobs without admin passwords. We did have the machine on isolated networks, but even on the regular networks many of the team member frequently would need to hand install drivers. This is just one of many examples. If you do anything even remotely hardware related, it can really be a totally different problem. We had IT installed USB filter drivers (we were not told about for security reasons) that actually broke a lot of testing in our labs and it took us months to figure out.
- Aeolun 7y ago
  Even if you need admin rights only once a week, if it takes a day to get them you waste 20% of your time.
  - maxxxxx 7y ago
    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.
twunde 7y ago
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 have access to servers and admin rights. At the very least they have source code an attacker could analyze, and likely have access to external services. The reality is that compliance, security and usability are often in direct conflict that can only be solved to make everyone happy with significant work.
- richk449 7y ago
  > 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 what does it really say?
  - tyingq 7y ago
    SOX doesn't actually say much about IT at all. It says mostly that you need internal controls to maintain the integrity of financial information. Anything more specific than that, around IT, is just someone extrapolating out what they think a good set of internal controls are. Mostly when you hear "because SOX", that person has never actually read the document.
  - thwarted 7y ago
    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 <company-policy-compatible enforcement mechanisms>". 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 https://news.ycombinator.com/item?id=9025958
m463 7y ago
> In my company there is this constant battle about the devs having admin rights on their machines. One company I worked for had two lans. The admin lan and the engineering lan. Your admin machine would always work. The eng lan could go to hell, and it/management wouldn't know/care. I think it worked well. It was kind of like having the common areas of the house neat and tidy, but giving the kids creative control over their rooms (and being able to close the doors when things got out of hand or guests came over).
orionblastar 7y ago
Or they block Youtube, and you got clients using Youtube to describe how they want things done. Watch it on your phone or at home.
vikingcaffiene 7y ago
> In my company there is this constant battle about the devs having admin rights on their machines. I ended up leaving my last job over this and more stuff like it. They had a url filter in place for instance, that would randomly block access to our network resources. It would never be the same one so every now and again your stuff would start failing and you would lose a few hours debugging until you realized.... GAH! Then have to email and lose the rest of your day waiting for them to fix it. Never. Again.

7748394773639 7y ago

I have my own PC strapped under my desk connected to public Wi-Fi. I use it to do all my work. My company pc is left turned on but disconnected, sitting on top of my desk to dissuade suspicion.

maxxxxx 7y ago
I have a WiFi router hidden so we can do some specific network testing. We also have a consumer DSL line so we can test on a network where IT doesn’t block random stuff. It’s not even much of a secret. Everybody local knows this stuff and every six months a guy at IT headquarters throws a fit, doesn’t provide an alternative and gets ignored. I have thought about sending them recordings of previous meetings so we don’t have to repeat the series of same meetings every six to twelve months.
- miahi 7y ago
  We had the same kind of "hidden" router at my previous employer, as we had a team of ~10 developers who needed a lot of different access to different servers and between eachother. We put the name of another tenant in the office building as the SSID :). After about a year the network through that router started to slow down. When we checked why we realized that we had more than 40 wifi clients, as other (non-dev) teams learned about the network through the grapevine and actually the new employees from sales (the neighboring office) were told to connect to that network directly - as the process to connect to the "normal" network was too much of a hassle.
  - maxxxxx 7y ago
    The funny thing is that after a recent remodel the router got moved and we don’t know where it is. It still works but nobody knows the exact location. It may be in the ceiling or the floor.
    - iaw 7y ago
      I hope it never needs to be reset.
    - geggam 7y ago
      LOL reminds me of a very old bash.org http://www.bash.org/?5273 http://www.bash.org/?5273
      - pickle-wizard 7y ago
        That reminds me about the story of a University that an old DEC VAX that got walled up during a remodel. Machine kept running and no one notice. A decade later another remodel came along and they tore down the wall to find the machine just happily running.
        antod 7y ago
        I remember an old Netware version of that story.
        pickle-wizard 7y ago
        You know, maybe it was Netware. My memory has some bitrot in it after all these years.
esoterica 7y ago
Does your company know you have their IP on your personal device (and are sending company communications over public WiFi)?
- 7748394773639 7y ago
  It’s not highly confidential information. Mostly its to use a machine with adequate ram. Besides I’m using end to end encryption instead of being MITMd by their third party ‘security’ gateway
megaremote 7y ago
I have a VM on my mac to go on the work network, using ethernet, while I do everything over wifi.
brokenmachine 7y ago
Don't you need shared drives, etc? We can't connect to anything internal from outside, there is VPN access but it seems a step too far to use that all the time.

ConfusedDog 7y ago

I entirely agree with you. This is the same idea in the Greatness video by David Marquet (https://www.youtube.com/watch?v=OqmdLcyES_Q https://www.youtube.com/watch?v=OqmdLcyES_Q) Try to control everything is just futile. I think hiring and retaining best people is the best countermeasure to this sort of things.

rb808 7y ago

I think most of the reasons for admin rights are no longer valid. Its easy to change user environment variables and lots of applications can be installed as a user. Why would you need admin rights? Dropbox/googledrive is a huge security hole that is definitely blocked at most companies I work at.

beart 7y ago
One example off the top of my head: It used to be (may still be) the case that you needed admin rights to install and run the Windows Subsystem for Linux. Sure, you might not need this to do your job, but IT is not really in a position to decide that. It could be that WSL greatly increases your productivity.
- maxxxxx 7y ago
  Exactly. Unfortunately windows admin rights are not very granular so if you do anything serious you end up needing full admin soon.
  - basch 7y ago
    Application control is granular if you use SCCM or Intune and Application Guard. https://docs.microsoft.com/en-us/windows/client-management/mdm/windowsdefenderapplicationguard-csp https://docs.microsoft.com/en-us/windows/client-management/m... There is absolutely middle ground if you have the time and resources to get it running smoothly.
    - maxxxxx 7y ago
      I am sure solutions could be found. But it would require effort from IT to understand what we are doing and finding real solutions.
- esoterica 7y ago
  You can ask IT to install it for you. You don’t need to install it yourself.

exabrial 7y ago

I really wish some big shots in the security world would write an ISO standard or something stating how harmful blanket 'block Dropbox' policies are for the reasons you list.

maxxxxx 7y ago
And they should commit to talking to my VP every time the VP commits us to working with a supplier who uses Dropbox and also commit to finding solutions that allow us to get our work done within deadlines.
ubermonkey 7y ago
The "dumb" here isn't even limited to "block Dropbox." Lots of my customers have blanket "block everything that could plausibly be used for file sharing" policies, and explicitly include services literally AIMED at corporate/B2B data exchange like Citrix's ShareFile. No, we don't have an internal FTP site. No, I won't set one up for you. We use Sharefile for distribution so we don't have to do that. Your IT blocks it? Yeah, that's dumb. Go talk to them; it's not my problem. We're not going to do customized delivery channels just because your halfwit CIO decided to block every site with an upload button.
- maxxxxx 7y ago
  The funny thing is that they block Dropbox but then there are plenty of shady upload sites that aren’t blocked. We don’t use them because we think they aren’t secure but our IT guys would have no problem with that.
  - natch 7y ago
    That highlights a problem woven through the industry which is that the IT department isn’t always the sharpest team in the building, even on security matters.
    - maxxxxx 7y ago
      They are completely outsourced and offshored. Only a few competent people are left.

protomyth 7y ago

I'm still not sure why developers aren't on their own network for development. Have a red box / blue box type system at the developers desk. Given modern networking, it wouldn't actually be that hard to setup and keep development / integration / system tests (or what names you use) away from a locked down production would not be such a bad thing[1]. Having some dual homed file shares wouldn't be that hard either. 1) I would probably still use different terminal color schemes, but being in front of a different physical box might be quite a good thing.

maxxxxx 7y ago
I have proposed that. Give us a network where we can do what we want do and protect the boundaries of it. So far no luck.
lightbritefight 7y ago
Developer data can still be confidential/sensitive, so you still need to monitor and control this second network with many of the same restrictions as the main one. You still have most of the same risks to compensate for, like data exfiltration and cryptolocker, etc. It doesnt introduce that many positives for lots of admin overhead, not just in maintaijg two distinct networks, but also in ensurijg interoperability when needed.
- protomyth 7y ago
  Developer data can still be confidential/sensitive Yes, there are confidential data, but it shouldn't be any real customer data. Right?!? Frankly, given best practices from professional developers, stuff like cryptolockers just aren't an issue (blank the machines). Developers need admin, so building a network for them is actually a lot easier.
  - TeMPOraL 7y ago
    > 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!

pmorici 7y ago

Shouldn't this kind of thing be a problem for the managers to address? If you just circumvent this kind of nonsense instead of addressing it head on it just proliferates and allows the people who promote it to think they are doing an acceptable job. At minimum you should inform your direct manager of the situation so they can address it or accept the consequences that the work that depends on the restricted resource won't get done w/o circumventing company policy.

maxxxxx 7y ago
Management knows.
lnanek2 7y ago
I've heard security management say it is their job to say no all day. They definitely don't care about preventing work getting done. They will only get fired if a data leak occurs, etc.. Preventing work won't even ding their promo outcomes.
- Endy 7y ago
  If work happens and somehow anything goes wrong, they get fired. Therefore it's a matter of self-preservation to get everything possible frozen.
- dreamcompiler 7y ago
  Incentive structures always tell the tale, and people have a nasty tendency to figure them out quickly, regardless of what their mission statement says on paper.
- jpindar 7y ago
  The most secure network is one that no one uses. Therefore the goal is to make the network as difficult to use as possible.
- pmorici 7y ago
  That's the point of telling your manager and letting them deal with it. Ultimately the business needs to make money or show some result. If the company policies prevent that then their cost benefit needs to be evaluated and that is a manager's job. "No" is fine as long as a conscious decision is being made with the consequences in mind. That way your security person isn't saying no to Dropbox access they are saying "No" to the successful implementation of the CEO's #X priority for the quarter or "No" to 10% additional revenue for the company or whatever.

jnosCo 7y ago

I'm one of those assholes that makes security policy. I deal with the same requests. The problem is, I write up a proposal identifying the risks associated with the exemption, along with minimum and recommended compensating controls. This then gets discussed among IT Management, where it is usually decided it's too much overhead, and to just deny the request or if the user can scream loud enough, allow it outright and get some director to sign something. The third oft-used response is ignore the problem and hope the user finds their own work around so we can get back to the 13 projects we're somehow expected to complete this quarter.

maxxxxx 7y ago
I feel you. The whole setup is dysfunctional by design.
AstroJetson 7y ago
Me too, we try, but it's too easy for people in the management chain to push a fix into the "Too Hard Bucket" (tm) and it dies.
novok 7y ago
It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'. Not letting people do their jobs, or in how fast they can do their job. Employees are a captive audience, and if there was competition they would probably chose something else.
- TeMPOraL 7y ago
  > It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'. I tend to summarize my experience with IT in large companies and universities like this: IT is evaluated in "how secure things are", or "whether things are not broken". The only sure-fire way to ensure a system is secure and not broken is to make it completely unusable, so that people don't use it. If people don't use a system, they can't break it!

oceanghost 7y ago

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 the problem lasted almost a year. It got so bad our "source control" became yelling "Whose got the latest main.cs?!" and walking it over with a USB key. I realized we needed to disintermediate the IT group, and my boss was supportive. I ended up establishing our own, parallel IT department with a business cable line, some routers, and NAS devices. I outsourced any task to any cloud service (this was over a decade or so ago when that was somewhat unusual) — eventually hiring our own IT person even. People would ask for access to our network because it was more reliable :-) Then things got vicious. They actively interfered with our group, trying to get us fired (they had some success with this previously). They were able to get our IT guy fired. Things just went on that way for years. They'd find some way to make trouble, and then we'd route around it. Once they even took my computer for two days, denied they had it, then returned it but locked me out of it. I was certain this was part of some scheme to get me fired, so I turned the computer off, zeroed the hard drive, and req'd a MacBook to work on. They all eventually got fired when someone took note of their gross incompetence. One of their replacements was eventually fired for embezzling, proving that despite thinking we had the worst IT department anyone could imagine-- we really didn't.

user5994461 7y ago
Why would you stay for years in a company like that? It's so dysfunctional and toxic.
- mywittyname 7y ago
  Judging by the statement that he worked with some high-level EE/CS/ME people, I assume the actual job was pretty interesting or cutting edge.
  - noobiemcfoob 7y ago

fancyfish 7y ago

I've consulted for a big bank which blocks most file sharing sites and also blocks you from attaching scripts, server logs, etc to emails. Luckily, S3 is not blocked. I set up a bucket and have them upload to the bucket, which I then download on my own computer. Mission accomplished. Just getting free Windows applications procured and installed on the company laptop takes several layers of approval, emails back and forth, etc. Also the lovely forced password resets every 2 months. This is true for the banks I've worked with/at. Security systems actively block you from the tools you need to do your job, let alone get the job done in an efficient manner.

padraic7a 7y ago
I work for a local government department. Must try your S3 workaround. I swear sometime I think our IS dept are playing jenga, they just pull random services at will. Today I couldn't update our website because the proxy settings allowing me access the login page somehow changed without notice. Last week they blocked USB access to machines without telling anyone who backs up to external 8tb drives. Tomorrow who knows what they'll decide. And it doesn't make for a secure environment! Everybody tries to figure out workarounds. Staff actively try to undermine security policies. It's a total disaster.
BonesJustice 7y ago
Be careful. I work for such a bank, and even secure traffic is MITM’d when possible. There are data loss controls in place to analyze outbound traffic for things like source code. Just because you’ve circumvented IT’s blocks doesn’t mean you won’t land yourself in hot water.
OkGoDoIt 7y ago
I used to work at a place like that, it was incredibly frustrating and time-consuming. So I came up with a solution that works even if S3 is blocked: I built https://github.com/OkGoDoIt/UploadAndPaste https://github.com/OkGoDoIt/UploadAndPaste and set up SCP file hosting on my own server that listens on port 443. (They blocked most outgoing connections to non-standard ports and did MITM sniffing on any port 80 traffic, so this was the only way to get through.) Then I could just easily "paste" a file to a my remote server and download on the other machine via a url.

Shivetya 7y ago

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 well and you can guess it, cannot do their work. If they need admin rights all the time then put those particular machines on a protected network and not allow any other business work to occur there.

mcshicks 7y ago
I think it really depends on what kind of development you are doing. I worked at an IC company, and among other things we developed (and tested) USB drivers for our devices. We installed them on literally hundreds of windows machines for testing before they were signed/ whql approved. This happen all the time. So really no way do our jobs without admin passwords. We did have the machine on isolated networks, but even on the regular networks many of the team member frequently would need to hand install drivers. This is just one of many examples. If you do anything even remotely hardware related, it can really be a totally different problem. We had IT installed USB filter drivers (we were not told about for security reasons) that actually broke a lot of testing in our labs and it took us months to figure out.
Aeolun 7y ago
Even if you need admin rights only once a week, if it takes a day to get them you waste 20% of your time.
- maxxxxx 7y ago
  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.

twunde 7y ago

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 have access to servers and admin rights. At the very least they have source code an attacker could analyze, and likely have access to external services. The reality is that compliance, security and usability are often in direct conflict that can only be solved to make everyone happy with significant work.

richk449 7y ago
> 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 what does it really say?
- tyingq 7y ago
  SOX doesn't actually say much about IT at all. It says mostly that you need internal controls to maintain the integrity of financial information. Anything more specific than that, around IT, is just someone extrapolating out what they think a good set of internal controls are. Mostly when you hear "because SOX", that person has never actually read the document.
- thwarted 7y ago
  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 <company-policy-compatible enforcement mechanisms>". 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 https://news.ycombinator.com/item?id=9025958

m463 7y ago

> In my company there is this constant battle about the devs having admin rights on their machines. One company I worked for had two lans. The admin lan and the engineering lan. Your admin machine would always work. The eng lan could go to hell, and it/management wouldn't know/care. I think it worked well. It was kind of like having the common areas of the house neat and tidy, but giving the kids creative control over their rooms (and being able to close the doors when things got out of hand or guests came over).

orionblastar 7y ago

Or they block Youtube, and you got clients using Youtube to describe how they want things done. Watch it on your phone or at home.

vikingcaffiene 7y ago

> In my company there is this constant battle about the devs having admin rights on their machines. I ended up leaving my last job over this and more stuff like it. They had a url filter in place for instance, that would randomly block access to our network resources. It would never be the same one so every now and again your stuff would start failing and you would lose a few hours debugging until you realized.... GAH! Then have to email and lose the rest of your day waiting for them to fix it. Never. Again.