LLM discovers exploit -- you don't realize it in time because you don't have a security team as big as the PaaS you used to use -- you get pwned anyway.

This has happened to many high-profile self-hosted pieces of software just this past month.

▲

ang_cire an hour ago | parent [-]

An exploit in what, the network stack of the Linux distro you're using for the mTLS proxy? Or the crypto module? Sure, could happen. But then, you're unlikely to be the top target of anything.

Or do you mean a customer was running it?

▲

kube-system an hour ago | parent | next [-]

There have been a lot of exploits for a lot of software on-prem tech stacks rely on just over the past month - proxmox, php, nodejs, palo alto, eMudhra, etc come to mind.

> But then, you're unlikely to be the top target of anything.

That would have protected you 3 years ago when a human had to bother to attack you. Today it doesn't protect you because it's trivial to deploy an LLM to act like an APT against any random target that shows up in shodan.

It takes more effort to secure on-prem software today than it did just a couple of years ago. Updates are more frequent, zero days are more frequent, attacks are more common, more persistent, and more automated.

I think most people responsible for securing production systems today will share the experience that their workload has increased.

▲

ang_cire 24 minutes ago | parent [-]

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 18 minutes 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 6 minutes 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.

▲

sdenton4 44 minutes ago | parent | prev [-]

Or the configuration parameter that you got wrong because you rolled your own and didn't know any better.

▲

ang_cire 34 minutes ago | parent [-]

Why would you roll your own?

▲

kube-system 16 minutes ago | parent [-]

You would inherently be rolling your own configuration when deploying something on-prem.

	▲	ang_cire 4 minutes ago \| parent [-]
		1) where did you get "on-prem" from? 2) that's not what "rolling your own" means. Building your own web proxy is "rolling your own". Standing up e.g. Caddy and configuring it is not.