Comment by itissid
19 hours ago
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>.
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. ;-)
1 reply →
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.
1 reply →
Or there's some exploit in an endpoint device, and the problem moves laterally from inside your firewall.
Yep, but the attack surface is much smaller!
yeah remove the door locks, the thief can just break the window
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".
Good like trying to explain to your customers that their data is no more accessible because some api key ended up in a public git repo or since you admin panel is exposed to whole internet someone was able to log in.
With the speed of exploitation hitting right now your analysis will be out of date in a few weeks to months. We are about to have very palpable fear hitting all software vendors. It will be seen as irresponsible to use centralized systems
Especially when the customers' own websites or services are down, they are a lot more understanding.
Until the attacker bypasses your perimeter firewall by convincing an employee to download and install malware.
And so? This is true for any kind of infra!
You can't defend yourself from everything, but you can try to make you life easier by reducing the attack surface and make side movements more difficult.
Having employees (or system like bastion hosts) with unrestricted access is one of the recurring mistakes in such events. I can’t understand it.
1 reply →
[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.
Security question 2: You reach down and flip the tortoise onto its back…
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.
1 reply →
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.
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?
14 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.