You're still describing an environment that presents a pre-auth surface area beyond a listening port.

And I am literally a security engineer; the work has absolutely not gotten harder, it's just changing in how you think about security, just like it shifted before from "secure the perimeter" to "defense-in-depth", it's now changing again to focus on automated response and compartmentalization/ segmentation (and I mean real segmentation, not the checklist-style "we have 3 vlans, but they can all talk to each other" 'segmentation' you used to see.

▲

kube-system an hour ago | parent [-]

Yeah, most organizations need to expose something to the internet as a matter of normal operations -- at least some sort of a web app if not dozens. It would be great if we could all just have udp 56820 listening silently for a key, but that isn't reasonable for most organizations that have normal users expecting normal applications.

Yes, everyone is rushing to implement zero-trust principles for real now. It's getting harder to trust that your public facing endpoints don't have vulnerabilities, and it's getting harder to trust that your internal software and endpoints haven't been compromised from within your pre-existing trust boundaries. A lot of the increased workload is due to patching up the existing security infrastructure, and on top of that, building out new solutions to better fit today's threat landscape.

▲

ang_cire an hour ago | parent [-]

Ideally they need to divide those apps entirely; your public website doesn't need to talk to your app.

For stuff like Netflix that is truly consumer-facing, where mTLS or IP whitelisting are non-starters, the reality is you have to rethink your model entirely.

Also, I'm not sure where you got the idea I'm talking about on-prem only; this also applies to using IaaS/ cloud hosted infra.

	▲	kube-system an hour ago \| parent [-]
		The reason we were talking about on-prem is because we're talking about the effort of doing these things yourself vs farming it out to a third party. If you're a security engineer responsible for securing only: 1. a public website 2. stuff that can be ip whitelisted and/or use mTLS Consider yourself very lucky. Most orgs need to expose a lot more than that.