4 ms·

> it requires a development team to realise that just because they're good at programming computers it doesn't mean they're good at administering them. Yes, it

• octodog 4y ago
  Pretty weird question. Are you writing malicious executables and then running them at work?
  • hawski 4y ago
    With this logic we don't need IT policies, because I just don't run malicious executables. Thanks to that I can run a graphical session with root.
  • gregmac 4y ago
    What the GP is talking about is not letting developers install stuff on their PC. I assume this is also "run unknown exe" because.. well I can't see any reason local root could hurt the network in a way my user account couldn't. Unless maybe the PC is shared, there's no difference of install (local root) compared to run as normal non-user, as far as attack surface on the network. So this comes back to: do you block "potentially malicious" executables or not? How do you tell if a new never-before-seen executable needs to be blocked, without either just blocking every unknown executable ("dev can't get anything done") or opening a giant loophole ("anything in x directory is safe")? Let me write it a different way: An exe with an unrecognized name and unrecognized sha256 suddenly appears on my computer. Maybe I just compiled it from source I wrote, or maybe it is a random thing I downloaded and unzipped. How does a decision get made on whether my system will run that or not?
    • pixl97 4y ago
      Your local non root user can install new network drivers and launch ARP attacks against the switch in promiscuous mode? There are plenty of ways for a local dev to self sign local trusted executables that can only run on their own machine for testing purposes (that would not be trusted being distributed to the public). At least in Windows there are a few different systems that protect against running unknown executables, and downloading and running unknown executables would be a resume generating event that would get you walked out the door by security.
• dspillett 4y ago
  > What exactly is IT doing when a dev requests to install randomtool.exe? Some basic research on its creator/distributor and history, particularly with regard to security issues and how well/quickly they were addressed. Also perhaps running the software in a constrained environment to see what calling home it tries to do, or does as part of its core function¹, if it is monitoring the clipboard, etc. > Why is it a developer is incapable of that same thing? It isn't really a question of capability, it is a question of whether they are convinced⁵ of the necessity and can all be relied upon to be appropriately diligent. For many all that "contracts", "auditing", and "data protection law" stuff is someone else's problem, not interesting, and thinking about it wastes time & gets in the way of getting the interesting stuff done. > how I supposed to do my job? Do you want all that compliance stuff to become part of your job? Is that what you got into development for? Do you want to be held responsible if something is missed? If not then accept that someone else has to do it so that you don't have to, which sometimes means waiting for them to do it properly. ---- [1] we work with banks, we have to be very careful about potential accidental data exfiltration routes because we sometimes handle PII (and, more cynically, because we'd fail an external audit required by some big contracts if we didn't!)², we have a local instance of languagetool if someone needs that sort of thing but people still try to install grammarly³ and done seem bemused that potentially sending everything you edit⁴ is being sent to another country could be a bad thing. And that one is obvious, as it is part if the products core function. [2] for other companies, their own "trade secrets" could be the concern [3] nothing against grammarly, that is just a good glaring example of a tool with which we could accidentally breach promises made to clients about where information could reside or be processed. The same concerns, along with a few extras like licensing and stability, are also relevant for dependencies that actually become part of our products. [4] yes, of course we have proper data access controls in place and all but a few of us have no access to real data if all is well with that, and even then that access is gated and used sparingly, but security-in-depth is a thing... [5] from your question, you don't sound convinced currently
• faeriechangling 4y ago
  > What exactly is IT doing when a dev requests to install randomtool.exe? Selecting/paying for secure repositories from legitimate well maintained sources. Packaging the software and deploying it through some means, so all users who need the software can get the software. Regular patching of software across many users who may only be intermittently connected to the internet. Lots of busywork updating configurations as new teams are formed, teams dissolve, people come, people leave, new patches come out, new software comes out, have to move to a new OS with old software. Company policy or circumstances might require some tweaks. Generally though as to your question, there’s no reason you can’t do what the IT department does. The IT department can also have such a setup and then have a dev sandbox environment you can pull random code into. The larger point of what they’re doing is building a software supply chain, and once you actually have every piece of software you’re using in a secure repository, you can do BIG things like blocking all applications that aren’t whitelisted in prod which essentially shuts down entire classes of security threats against a company, and maybe that’s what a company wants. Maybe a company shouldn’t be trying to maintain a centralized repository and that’s a dumb idea…