4 ms·

The last paragraph hits the nail on the head, it's impossible to prevent developers from elevating privileges unless one spends much more time and effort than a

The last paragraph hits the nail on the head, it's impossible to prevent developers from elevating privileges unless one spends much more time and effort than almost any business is willing to on creating a true zero trust internal environment. Developers have little RCEs throughout the entire system, it's how they do their jobs. If even system with millions of dollars worth of design and security reviews regularly get hacked by people with no internal access to it or its source code, how can you hope to stop someone who already has a foothold and can see into the system, including a bunch of its config files? The real answer is not to stop developers from doing so. That's a never ending uphill battle. You implement very good logging and RBAC systems instead. Now everybody could hack the system if they wished to, but they would be sued into oblivion if they tried to do it for nefarious reasons. IMO the main purpose of RBAC is not really to stop developers from doing malicious activity, but to stop the stupid ones from breaking the system. The smart ones will be able to get around whatever safeguards you put in, as some of them will undoubtedly be designed by those not so fortunate or experienced. Not every developer has a good understanding of infosec and its many, _many_ ways of circumventing what seems to be an impossible defence. Unless you know all the tricks in the book already, whatever you write is most definitely gonna be swiss cheese.

eyelidlessness 5y ago
The risk isn’t internal nefarious actors, it’s internal people who don’t know or don’t care that they’re granting privilege escalation to a wider audience. And zero trust is the only way to mitigate that. There are so many bad security takes in this discussion and I’ve barely read half of it. This isn’t an ignorant community. The implication is that every slightly or significantly bad take is compounded by culture and organizational ignorance. The only solution is systems that can’t be accessed by humans by design. And building better reporting and isolated debugging tools to accommodate that.
- closeparen 5y ago
  Either you need to change and deploy the debugging tool to support each new investigation, or the input to the debugging tool grows powerful enough that it is effectively a remote shell, if not literally.
- athrowaway3z 5y ago
  I couldn't disagree more on the implication of organizational ignorance. Your solution isn't wrong. It's just never going to be cheap and simple enough to expect it as a minimum for every organization.
ramraj07 5y ago
This is exactly what we did in our team, create an RBAC system to allow downstream teams to configure and request advanced stuff but with permission and logging. But then the immediate problem is that some of them has legitimate needs to modify the RBAC system itself! So we ended up creating as good as practically possible audit logging of the rbac system, tied intimately to a users authentication, and let them go wild. Worked pretty well so far (as far as we can tell that is).
MattPalmer1086 5y ago
In most secure places I've worked, devs have no access to prod at all. In the dev environment they have lots of permissions. Anyone putting a back door in to the code so they could access it in prod would be looking at a criminal investigation.
- mrweasel 5y ago
  Disallowing developers access to production is pretty common in many Danish government contracts. Contracts for new IT systems are normally submitted by at least two companies in tandem. One company will be developing the software, while the other is responsible for operations.
- concordDance 5y ago
  And this drastically slows down diagnosis and fixing of production issues in my experience. Particularly performance issues. Probably by a factor of five or more.
  - MattPalmer1086 5y ago
    I agree, it makes diagnosis much harder. It's certainly not a free lunch to lock things down. Sometimes that is what's required. I've just spent a fair bit of time working on allowing very limited access to prod by devs to investigate core dumps. Took a lot of argument to get that, but the alternative was moving the core dumps out of prod, and that wouldn't fly due to the sensitivity of data that might be exposed. It's certainly not easy working in a highly secure environment.
jnwatson 5y ago
I'm consulting with a company that has the opposite: the developer environment is locked down tight. Like, they've even managed to disable developer tools in Chrome. It is the least productive environment I've ever been in. It has made me a lot more aware of how much stuff we download from the internet for development, since I can't do that in this situation. Fortunately, I get paid by the hour.
- Thiez 5y ago
  What purpose could locking down the dev tools possibly serve? Madness.
  - acdha 5y ago
    It could be an attempt to prevent someone from being socially-engineered into running code there – if you open the dev tools on sites like Facebook you'll see a warning message telling people not to paste anything in to the dev tools due to attacks like that. It's not uncommon for places to set policies based on general concerns and not having exceptions for technical staff.
- iamcurious 5y ago
  Sounds fun, are they hiring remotely?
  - jnwatson 5y ago
    They are very, very against remote.

eyelidlessness 5y ago

The risk isn’t internal nefarious actors, it’s internal people who don’t know or don’t care that they’re granting privilege escalation to a wider audience. And zero trust is the only way to mitigate that. There are so many bad security takes in this discussion and I’ve barely read half of it. This isn’t an ignorant community. The implication is that every slightly or significantly bad take is compounded by culture and organizational ignorance. The only solution is systems that can’t be accessed by humans by design. And building better reporting and isolated debugging tools to accommodate that.

closeparen 5y ago
Either you need to change and deploy the debugging tool to support each new investigation, or the input to the debugging tool grows powerful enough that it is effectively a remote shell, if not literally.
athrowaway3z 5y ago
I couldn't disagree more on the implication of organizational ignorance. Your solution isn't wrong. It's just never going to be cheap and simple enough to expect it as a minimum for every organization.

ramraj07 5y ago

This is exactly what we did in our team, create an RBAC system to allow downstream teams to configure and request advanced stuff but with permission and logging. But then the immediate problem is that some of them has legitimate needs to modify the RBAC system itself! So we ended up creating as good as practically possible audit logging of the rbac system, tied intimately to a users authentication, and let them go wild. Worked pretty well so far (as far as we can tell that is).

MattPalmer1086 5y ago

In most secure places I've worked, devs have no access to prod at all. In the dev environment they have lots of permissions. Anyone putting a back door in to the code so they could access it in prod would be looking at a criminal investigation.

mrweasel 5y ago
Disallowing developers access to production is pretty common in many Danish government contracts. Contracts for new IT systems are normally submitted by at least two companies in tandem. One company will be developing the software, while the other is responsible for operations.
concordDance 5y ago
And this drastically slows down diagnosis and fixing of production issues in my experience. Particularly performance issues. Probably by a factor of five or more.
- MattPalmer1086 5y ago
  I agree, it makes diagnosis much harder. It's certainly not a free lunch to lock things down. Sometimes that is what's required. I've just spent a fair bit of time working on allowing very limited access to prod by devs to investigate core dumps. Took a lot of argument to get that, but the alternative was moving the core dumps out of prod, and that wouldn't fly due to the sensitivity of data that might be exposed. It's certainly not easy working in a highly secure environment.

jnwatson 5y ago

I'm consulting with a company that has the opposite: the developer environment is locked down tight. Like, they've even managed to disable developer tools in Chrome. It is the least productive environment I've ever been in. It has made me a lot more aware of how much stuff we download from the internet for development, since I can't do that in this situation. Fortunately, I get paid by the hour.

Thiez 5y ago
What purpose could locking down the dev tools possibly serve? Madness.
- acdha 5y ago
  It could be an attempt to prevent someone from being socially-engineered into running code there – if you open the dev tools on sites like Facebook you'll see a warning message telling people not to paste anything in to the dev tools due to attacks like that. It's not uncommon for places to set policies based on general concerns and not having exceptions for technical staff.
iamcurious 5y ago
Sounds fun, are they hiring remotely?
- jnwatson 5y ago
  They are very, very against remote.