3 ms·
"So if you want to run a rogue service, you need a conspiracy across departments" Or a developer that plants a back door in the code. He then exploits it on th
by nroets 8y ago
"So if you want to run a rogue service, you need a conspiracy across departments"
Or a developer that plants a back door in the code. He then exploits it on the production server.
Maybe time is better spent on code reviews ?
- Kalium 8y agoYou're right! That's one approach to exploiting this. It's worth considering that multiple approaches, across multiple departments, can be used. A good environment might use Vault for authentication between services and require that code cannot go into production without a review and enforce it in code. Then you tightly control who has access to the administration of those restrictions and log all usage to somewhere else, such that even if someone does compromise the infrastructure to allow them to insert their back door it can be detected and the culprit identified. Again, you're completely right. Code reviews can be a great way to spot malicious code! You're also right that the Vault usage pattern that parent pointed to definitely has vulnerabilities. It's perhaps worth considering that this approach could be used in a context where it might not be the only defense. Perhaps you could ask parent for a more detailed explanation of their org's information security practices?
- _jal 8y agoAs the other poster noted, this is not the only mechanism employed, which would be pretty silly. Among some of the others are, indeed, code reviews, static analysis and anomaly detection. Another point worth noting about insider threats: overconfidence on the part of the attacker is frequently the defenders' friend. Metaphorically speaking, the crook knows about the camera over the door and will avoid showing their face to it, but didn't notice the other ones. And because they work there, they think they have a better handle on how things work than they actually do.