3 ms·
These other responses are great justification to always dig into what someone's threat model is. I've had so many "security" conversations get resolved somethin
by ye-olde-sysrq 4y ago
These other responses are great justification to always dig into what someone's threat model is. I've had so many "security" conversations get resolved something like this:
other dev: this is insecure
me: what's your threat model?
other dev: <convoluted, opportunistic-only highly-timing-sensitive scenario that assumes attacker has gained internal network access>
me: you do realize all our boxes have an "admin:password"-esque standard login available and passwordless sudo. if they're on our network they can already just do basically anything.
People (well, devs) love to think about security in very fine-grained detail, and honestly that's good. We should all be thinking about this. But your security is only as good as your weakest link, and when your security policy already literally codifies "we will trust the firewall to make intranet security less annoying/complicated" then unless you want to go change that or your threat model is describing an attack on that security model, then please don't try to get overly clever.
Now - that said - I do wish more orgs just did defense-in-depth from the beginning. It's so easy to provision certs nowadays that there's almost no reason not to do mTLS etc even in something like a homelab setting.
- tptacek 4y agoThis isn't a convoluted, timing-sensitive scenario; it's more like, there is the possibility that if you have tcpdump running anywhere, an attacker can strobe a packet that will trip a memory corruption vulnerability in some tcpdump printer, which is not, like, out of the realm of possibility.