Comment by contingencies | Hacker News Reader

Comment by contingencies | Hacker News Reader

Many of these solutions are unavailable below a certain scale, and there is currently little commercial utility or pressure in offering these features in a wholly-owned-and-operated fashion to small businesses or individuals. The new deal (eg. DDOS resistance) is to rent an implementation, or go without. Basically, the gap between everyone else and the Googles of the world is large and growing.

On the other hand, I wonder how useful some of them are. Boot-level security sounds fantastic but the cost of engineering and at the rate they probably cycle hardware, with decent service-level signatures this probably largely wasted money (eg. unexpected behavior like comms from service X to service Y is default-denied at multiple levels, logged, triggers hard shutdown/reset of system). While performance is cited as a concern, you'd save a lot of money removing the design/deployment/maintenance of all that complexity and could afford a little extra (more standard) hardware.

I find that thoroughness to be what's most impressive about this stack, considering every layer and securing it both independently and in relation to the others: it's as close to a textbook example as I can imagine. After all, what's the point of securing up the stack if you can't trust the bottom? Here's hoping AWS and Microsoft get there too.

Edit: Just trawling through, seems like quite a few of the tools are on github.com/google

> Many of these solutions are unavailable below a certain scale

This was true before Google Cloud. With Google Cloud, you can enjoy these benefits whether you are an individual developer with a sub 100$ monthly budget / a mom n pop shop with 1000$ budget or a SMB / Startup with a 10K$ - 100K $ to spend on your infrastructure.

That's exactly what he's saying. Small startups, who don't want to use Google, would have a lot of difficulty implementing some of these designs on their own.

Without boot level security, it's easy for the NSAs of the world to slip in a hard drive or two with extra "surprise" software on it, later engaging in active/passive surveillance or credential theft. Always assume that any one single employee could be compromised.

First of all, NSA hardware attacks of this ilk are supposed to occur through mail. Operations the scale of Google can acquire hardware in a secure/monitored fashion that bypasses public shipping facilities which would largely frustrate this type of attack. Also, I would hazard a guess than Google building their own hardware makes attacks on their boards far more difficult than for the rest of us. As for disks, they would be acquired in serial numbered batches from known suppliers and could be quickly tested to match known performance and sensor (eg. heat) metrics at the time of ingress. This is not very difficult, and assists in protection against tampering. In addition, the use of commercial grade disk hardware acquired in large batches means that the ultimate internal destination of a given disk in the organization is very difficult to ascertain, therefore the workload would be unidentifiable. Careful internal distribution processes would add stronger protections. Regardless of a compromised disk, proper architecture in a large-scale system mitigates the impact and data exfiltration capacity of individual compromised machines. Removed hardware would always be destroyed.

With the NSA's budget, I don't see why they would limit themselves to mail-only attacks. They could compromise any level in the supply chain, especially for targets which are worth the effort. They, or, more likely, the Brits tapped Google's DC-to-DC fiber and reverse engineered all sorts of internal protocols, as seen in Snowden's leaks.

Yes - or they rigged _all_ commercially available HSMs in use for encrypting a DC-to-DC fiber.

I think it was Neils Provos who said on stage that Google does not trust link encryption, but rather prefers end-to-end, even though that's a much greater problem in terms of key management.

The NSA's of the world don't need to hack Google's infrastructure. They can just ask.

This is protection from rogue employees acting independently, assuming it's not just marketing and ego-stroking for the engineers.

Why don't you google "NSA google smiley face".

I don't get it....search results returned only your comment.

First result for that search: http://www.slate.com/blogs/future_tense/2013/10/30/nsa_smile...

OPs comment:

> The NSA's of the world don't need to hack Google's infrastructure. They can just ask.

NSA doesn't just ask; they found ways to MITM Google.

Yes, and that happened before many of the security measures described in this doc were in place. It's one of the reasons behind Google's current and ongoing investments in security. Knowing that yes, the NSA is going after you is a wake-up call.

In particular, the doc says all data on the WAN (between data centers) is now encrypted.

> Boot-level security

You can get pretty far with commodity hardware. Even Secure Boot with custom keys prevents most threats.

IMHO the biggest problem with commodity hardware is IPMI BMCs, a problem so insidious and widespread as to limit the utility of implementing trusted boot. (I designed datacenters for a major bitcoin exchange.) I would hazard a guess that Google's custom hardware has a more intelligent/limited/secure (and crypto-validated firmware based) IPMI implementation, and this contributes far more to security versus commodity hardware than cryptographically secured main processor / system boot.

I agree. Is there any serious effort at making an open source BMC firmware?

At least Intel AMT improves the situation a bit.

OpenBMC https://code.facebook.com/posts/1601610310055392/introducing...

Reply on news.ycombinator.com