How is that ever going to work out? The speed of discovery for LLMs is so fast, these places are getting breached more often than not due to a human errors. Its really hard for machines, let alone humans, to guard against a lot of LLMs going against them 24x7.

▲

ang_cire 2 hours ago | parent | next [-]

No self-service sign up for your app. No public access to the app itself. Website that let's you submit a sign up request form. Team reaches out and reviews your request, creates an account in the app dash for you, and you set up mTLS to get access to the dash.

▲

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

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 25 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 19 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 7 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 an hour ago | parent | prev [-]

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

▲

ang_cire 35 minutes ago | parent [-]

Why would you roll your own?

▲

kube-system 17 minutes ago | parent [-]

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

	▲	ang_cire 5 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.

▲

clickety_clack 2 hours ago | parent | prev [-]

In-person requests for access to any app. Request interview includes word association exercise that monitors your emotional reaction to a string of key words.

	▲	ang_cire 36 minutes ago \| parent \| next [-]
		You joke, but the space I work in actually does do video calls (or in our case in-person meetings if they're local to SF, often) before onboarding new customers.
	▲	itsdesmond an hour ago \| parent \| prev [-]
		Security question 2: You reach down and flip the tortoise onto its back…

▲

vb-8448 4 hours ago | parent | prev | next [-]

It's much easier to protect yourself if you have your infra behind a perimeter firewall you control.

▲

roadside_picnic an hour ago | parent | next [-]

It's also harder to explain to your customers why you're the only product they use that has a security problem when an exploit does eventually happen.

You see this already with uptime. If Github or AWS has a major outage, it's in the news and even people that don't understand software realize it's just "something happening today, everything is down".

And, unfortunately, in practice customers don't care about this inverse, when "everyone else is down but not that one product".

	▲	frankchn 25 minutes ago \| parent [-]
		Especially when the customers' own websites or services are down, they are a lot more understanding.

▲

nradov an hour ago | parent | prev | next [-]

Until the attacker bypasses your perimeter firewall by convincing an employee to download and install malware.

	▲	mlhpdx 5 minutes ago \| parent [-]
		Having employees (or system like bastion hosts) with unrestricted access is one of the recurring mistakes in such events. I can’t understand it.

▲

0xWTF 3 hours ago | parent | prev | next [-]

Until there's a exploit for Palo Alto, Juniper, Cisco, F5, <pick your defender>.

▲

m4rtink 3 hours ago | parent | next [-]

You can scratch Cisco from the list - they just announced they will re-vibecode all of their codebase! So there will not be any explots for their hardware in the future - one way or the other. ;-)

	▲	taneq an hour ago \| parent [-]
		This solving the problem once and for all.

▲

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

Or there's some exploit in an endpoint device, and the problem moves laterally from inside your firewall.

▲

vb-8448 3 hours ago | parent | prev | next [-]

Yep, but the attack surface is much smaller!

▲

echelon 2 hours ago | parent | prev | next [-]

My hate for hyperscalers is greater than my hate of being SRE.

It's time to leave GCP, AWS, and the rest.

Google and Amazon markup can eat it. Fuck those guys.

Let's not forget that Google and Amazon tried to offshore us, played a role in inventing the labor-displacing models in the first place, and that don't give a shit about any of us.

I hope they ossify and turn into the next IBMs.

They thought AI would lead to growth and a greater concentration of wealth for themselves, but it's actually the seeds of their own destruction and dismantlement.

▲

InsidiousWombat 3 hours ago | parent | prev [-]

yeah remove the door locks, the thief can just break the window

▲

buremba 3 hours ago | parent | prev [-]

[dead]

▲

ijustlovemath 3 hours ago | parent | prev | next [-]

For one, I have strict iptable rules to drop inbound from outside my specific commercial subnet and my specific residential IP. After that, all the usual best practices.

▲

nine_k an hour ago | parent | prev [-]

Breaking a lock still costs approximately the same, whether the lock is protecting a small barn or a huge hangar. A large number of small but reasonably tough (not unbreakable) targets makes the payoff per target smaller. This necessitates target selection, and chances of being deliberately skipped grow for an average target.

	▲	digitaltrees 10 minutes ago \| parent \| next [-]
		Everyone knows Fort Knox has gold, and where it is, that’s railway, heroku. No one knows where my personal safe is or whether it has anything worth taking. That’s a vps in a colo
	▲	TeMPOraL 29 minutes ago \| parent \| prev [-]
		However, the large hangar is likely to have armed guards inside, or at least able to arrive on the scene within two minutes of the alarm tripping. Your regular household with their regular locks on their regular doors does not.