Comment by digitaltrees
18 hours ago
I actually think it’s the opposite. I think people will move back to their own hardware with OSS deployment like dokku. If everything is more bespoke the attack surface is smaller as is the pay off. Hacking railway got access to lots of api keys, hacking some random vps gets less payoff.
> If everything is more bespoke the attack surface is smaller
This is exactly the problem that LLM assisted attacks solve. For a human attacker, the extra work to figure out a bespoke solution is too time consuming to be worth the effort. LLMs can search for vulnerabilities and spit out bespoke attacks like it's nothing. On top of this the bespoke solutions weakness leans heavily into the AI attackers advantage: response time. Even if they can just get your company's single Anthropic key, if they do it at 2am while your one infra person is on vacation, they have plenty of time to extract enough value for their effort.
I agree with the move to hyperscalers. The future (well, actually present) is going to be constantly seeing new attacks happening. The only real solution to this going to be having teams of people and agents constantly watching for these and able to deploy fixes and respond to risks immediately.
You’re technically right, which is the best type of right, but my point is the fragmentation and lower reward will make discovery harder, and the value of searching and cracking less worth the effort.
I had a html game I built for my niece on railway with an open ai API key so she could vibe code changes. No hacker would have looked for it but now I am catching strays because railway was a juicy target. Hyper scalers would be the same. Some random colo not so much.
>and the value of searching and cracking less worth the effort.
This is depending on the cost of tokens not trending towards zero. Maybe not today, but in a couple of years I'd expect hacking models on asics to reduce this to almost nothing and the systems being very competent in using deterministic tools very well.
> LLM assisted attacks solve
Yes, LLMs can easily knock over your on-prem docker appliances.
But you can still put stuff out of reach. I'm currently designing a key on-prem appliance that is can be compiled down to transistors, giving deterministic wire-speed performance while ruling out RCEs. It's cryptographically homomorphic: it processes authorized inputs but doesn't know what they mean, so an attacker who obtains the disk doesn't benefit either. The design will be highly resistant to exploits, and is likely to remain outside the "next-token" prediction training set.
This is the kind of thing AWS won't sit down and engineer for you. But thanks to LLMs I finally have the time.
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.
It's much easier to protect yourself if you have your infra behind a perimeter firewall you control.
Until there's a exploit for Palo Alto, Juniper, Cisco, F5, <pick your defender>.
7 replies →
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".
3 replies →
Until the attacker bypasses your perimeter firewall by convincing an employee to download and install malware.
3 replies →
[dead]
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.
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.
3 replies →
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.
15 replies →
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.
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.
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
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.
This is absolutely happening. I'm not a developer in SV, I'm an IT leader out on customer land, and I can tell you a LOT of companies are looking to bring things back on prem for security and cost reasons. And before anyone laughs, yes, you ABSOLUTELY can save money going on prem, I've done it for company after company. It's one reason the PE firm that I've worked under for a decade kept moving me to new companies.
Let them laugh. Self hosting is much easier with OSS that solves most of the pain that made the cloud transition worth it, and commodity hardware has been cheap and capable for over a decade.
Sadly these relatively recent price bumps on hardware have made on-prem a bit of a harder sell for some.
My company just did this. Still using AWS S3 but everything else is on-prem with kubernetes.
That sounds insanely expensive. AWS S3 only makes sense if your workload is also in AWS. Using AWS S3 while having your compute elsewhere is a recipe for an insane egress bill.
1 reply →
How much of your public facing workloads rely on S3 if I can ask?
1 reply →
This is misguided thinking. You are less likely to hear about on-prem breaches in the news just because they are less likely to be newsworthy incidents, but they are even more likely to happen. Part of the reason people moved to the cloud is because it is much easier to have a team manage updates and security at scale.
Being a small target is not helpful these days, attacks on on-prem software today simply scans the internet, or uses databases by people who have already scanned it, and is automated.
On-prem software has not been spared from the recent spat of security incidents.
There is a difference of the security of software running in your cloud resources rented from AWS etc. managed by you and being a tenant in many SaaS systems all cobbled together all running on rented hardware. There is a lot more attack surface and a lot more diffusion of responsibility.
My comment[0] tries to explain the nuance and I would agree with you and both the GP in some sense.
For Entreprise, the shift will be towards hyperscalers as they want trust and less blame (Nobody got fired for picking AWS)
For consumers, we care about pricing and stability and control and we will move back to our own hardware or cheap VPS providers and self-host things.
The middle ground would be where the slight pain could be at in my opinion.
[0]: https://news.ycombinator.com/item?id=50307410
> For consumers <snip> self-host things.
That's not how consumers work. That's a nerd/geek/hobbyist mentality.
If Ikea and Wayfair went out of business you wouldn't expect consumers too take up woodworking and build their own furniture en masse.
For consumers/small orgs, how is the security at a cheap VPS provider going to be any better than at a cheap IaaS provider?
as long as you follow the herd (for example, disable password ssh login, only allow ssh key login, use something mind numbingly boring like debian stable, set up unattended updates, update and reboot every night, etc, don't use any exotic packages etc) I suspect you are simply not a worthwhile target even with LLM agents as opposed to humans
3 replies →
It's probably both.
Cost of hacking a custom setup is going down rapidly. There was broad agreement that the PHP vulnerability was very difficult to exploit in practice. It took two hours for someone to get into Steal My Bitcoin. Apparently all they did was tell a decent model "go exploit that." AI isn't free but it's not that expensive.
If you have to hack 1,000,000 custom setups to get the same results as one hyperscaler, would you bother?
Depends on what takes more effort. It's not at all clear to me that the 1,000,000 custom setups takes more effort. The first few will take some, then you'll start to see patterns and it'll get easier as you go. Custom setups aren't going to be all that unique in practice.
No thats an old way of thinking because it assumes mass targets are better because hacking is a high effort activity. But with the automation of intellect the unpatched systems (which a much more numerous when everyone self hosts) is the key point.
Mass credential stealing is just the top funnel of hacking and (compatativly) isnt that lucrative - these credentials are then sold on the black markets to the next step of hackers who use them to exploit targets.
With unpatched systems and self hosting, this second group can just set an llm at a target and have a much higher chance of success without needing credentials
It would be a dream for the infiltration hackers to have everyone self host. Unpatched and miscondigured systems would be everywhere and LLM automation could make mass scanning them and exploiting them very attractive - not mass scanning and exploiting them for credentials stealing, no! For layer 2 stuff