Hacker News Reader

Comment by southerntofu | Hacker News Reader

> any security-conscious GCP customers

Does that exist? In my book, if you're security conscious, you can only do self-hosting whether on premises or in your own bay in a datacenter.

Giving away your entire computing and networking to a third party such as Google is orthogonal to security.

View on HN

Confidential computing (Intel SGX, ARM TrustZone, AMD SEV-SNP) handle this by encrypting the virtual machine memory so that even having full root on the host does not expose vm compute or memory.

There are plenty of ways to do zero trust networking, a slick commercial implementation is https://tailscale.com/, which you can totally use in the cloud for secure node to node comms if you're worried about those things.

> Confidential computing (Intel SGX, ARM TrustZone, AMD SEV-SNP) handle this by encrypting the virtual machine memory so that even having full root on the host does not expose vm compute or memory.

Google's current confidential compute offering does not prove at runtime that it's actually confidential. You just get a bit in your cloud console saying 'yep it's confidential' (and some runtime CPU bit too, but that's easily spoofable by a compromised hypervisor), but no cryptographically verifiable proof from AMD that things actually are confidential.

Yes, Google tries to abstract SEV from you, but it is SEV-SNP that we really need for this. Our account manager confirmed they’re not offering SEV-SNP yet.

But you know this for metropolis, right? :)

Most people's threat models do not assume Amazon or Google are threats. Especially when you sign very large contracts with them, the law is enough to keep them in check.

You should absolutely consider your cloud provider a threat. What happens in a black swan even where a provider is completely compromised? Design around zero trust networks.

It's unreasonable to always design around not trusting any third party.

Sure you must always put some levels of trust in 3rd parties. What level of trust is the important question. Ideally, you distribute that trust among several actors so a single compromise is not too much of a deal.

That's why you use different hardware vendors for your routers and servers, another vendor for your network connectivity, and yet other vendors for your software. This way, MiTM is mitigated by TLS (or equivalent) and server compromise is mitigated by a good firewall and network inspection stack. Placing all your eggs in a single Google basket is giving a lot of power to a single "don't be evil" corporation, who may get hacked or compelled by law enforcement to spy on you and your clients.

Do it right, and you might mitigate threats, but do it wrong, and you are introducing more points where you could be compromised - a single supplier can be audited, a 100 cannot

It really depends on your threat model. It is not always unreasonable.

Target trusted their HVAC management firm so much that they had full unsegmented access to the LAN in each store. The credit card swipe terminals in the same LAN were totally compromised and millions of users had their credit card credentials stolen.

Defense contractors and places that store / manage large amounts of money are totally within their mandates to trust no one, not even many of their own employees.

Did Target really trust their HVAC firm or was their network just poorly segmented?

Both.

Someone hacked their HVAC firm to hack target credit swipe terminals.

At the time it was the biggest hack in US history.

Right, I'm familiar with the hack. My point is Target almost certainly didn't decide that the HVAC firm could be trusted to have access to the credit terminals - the fact that they had access was the result of poor security design, not Target's threat model.

Ok fair. I see the lack of simple things like segmented vlans as a lack of a threat model entirely. They trusted them implicitly, not explicitly, through their clear incompetence. Perhaps that’s better?

I think we are mostly in agreement.

I've often found poor security designs justified by many of the arguments in this thread that it's unreasonable to treat everything as a threat.

They know it's a bad design but doesn't matter because the threat is too improbable. Until it isn't :p

I’ve been in meetings where executives have said precisely this and I have tried to gently nudge them towards defense in depth.

It's the everything always part of the argument that's unreasonable. You realise that that's impossible? You can't vet and control the whole stack. And, if you could, it would be prohibitively expensive.

For certain use cases, it is not cost prohibitive. Take defense or banking…

By all means, but then are assuming that your suppliers are a threat? Did you check every chip on the motherboard that comes im, verify the firmware and bios on all components, including firmware of webcams and SSD's? Who inspected source code of evrry driver? Did you vet every employee and what did you do about Intel Management engine?

All these measures are not feasible unless you are working in national security or a Megacorp, and insisting on one of them, while ignoring others, is daft

> working in national security

& for national security cases they're provided sovereign clouds

Supply chain is still an issue in sovereign clouds. At some point there's still a trust decision, whether that's to trust the cloud provider, the hardware manufacturer, the chip manufacturer, etc.

For organisations with the resources to deal with an APT, great lengths are gone to in order to verify that the supply chain is trusted all the way down to the chip manufacturer. The hardware used isn't just bought from Best Buy and given a huge dose of trust, but instead there are with many many steps to verify that the eg the hard drives are using the expected firmware version. You spend as much as you can on the whole process, but if your threat model includes the CIA, China, and the FSB, it's exceeding expensive.

I wish that were true but it's really not. At least not within the public sector, maybe wealthier private firms can afford to do that level of verification.

Anyway, even then you still need to make trust decisions. How do you verify the ICs in your HDD haven't been tampered with? How do you know the firmware wasn't built with a malicious compiler? Or that a bad actor didn't add a backdoor to the firmware? Realistically there's a lot of components in modern computers that we have no choice but to trust.

Thats the issue, Amazon and Google are dependencies that are overlooked as too big to fail. Anything overlooked because it "can't fail" is the perfect place to attack.

But if you don't, your threat model is a work of fiction and you're wasting your time play-acting.

A threat model has no basis in reality if you do not accurately model threats, and your infra vendor is a glaringly obvious threat. Now, maybe that's a risk worth the tradeoffs, but how do you know that?

I agree, but given your how grey your text currently is I think too many HNers' careers depend on the cloud for them to ever agree with us.

Reply on news.ycombinator.com