Google reveals its servers all contain custom security silicon Google has published a Infrastructure Security Design Overview that explains how it secures the cloud it uses for its own operations and for public cloud services. Revealed last Friday, the document outlines six layers of security and reveals some interesting factoids about the Alphabet subsidiary's operations, none more so …
The more data an online service provider manages to snaffle from its freetard / paying users, the more it likes to boast abouts its security measures.
So, what do Google know about us all?!
Of course, these days Google, Facebook, etc. are snaffling data about people who are not their users (Android's use of caller ID, Facebook's face recognition and tracking, etc).
Google?
They know everything.
They know more about you than the CIA, NSA, CGHQ, and all of the other spy agencies around the world combined
You think you can just turn off google analytics and limit the javascript that runs on your PC? Guess again. There are ways around that. And note: Almost every website you visit runs Google Analytics.
Google's security is at a minimum what the US Government should be using. Had they done this... it would have been much harder for the Chinese to hack their servers (OPM) and had the DNC used it... they too would haven't been hacked from the outside.
Now you know what they (Google) do with all of that money they collect from ad revenue.
I suggest you take a deeper look at what can and can't be done using NoScript. (Which I use BTW)
But what's embedded in the javascript that runs the site?
There are other ways Google can track you. If you don't realize this then you haven't spent enough time thinking about it.
Theres a database which the FBI have which is the largest in the world. You can trace family trees back several generations, lookup sneaker patterns and practically anything else you could possibly want to know about an individual, right down to the time they were predicted to have a toilet break when at home, I shit you not.
Anyway, even if the chip does security and even if its custom built, if its got firmware which is NOT burnt into the chip for life, or needs someone to short some jumpers or pins on the chip, then it can be hacked.
The fact they use encryption when shifting data around between machines just makes it easier to hide the hacks.
So is that encrypted data passing down the wire, yours or mine?
Despite what an AC thinks. Having a security chip (which I'll bet is just a TPM chip that has only Google's certificate installed, because what they claim for it is exactly what TPM does) and encrypting devices doesn't prevent software security issues. And based on all the holes they find and fix in every release of Android, it is pretty evident that Google is no better than anyone else in terms of software quality.
While I'd guess the OPM servers were way behind in patching, and that probably aided the attack, bog standard TPM chips and encrypted drives wouldn't help there. Regular patching may have, but that would be pretty silly for Google to brag about, especially when 'custom security silicon' sounds so much better.
I'm sorry, but the use of hardware in security is only one layer of the security.
Again if the government had implemented security efforts found in Google and those found in global banks, the hacking of the OPM could have been prevented.
Granted, banks and others do get hacked. But the level of effort required grows.
>had the DNC used it... they too would haven't been hacked from the outside.
No. The DNC (Podesta) was using Google. His Gmail account was hacked. He clicked on a fake password reset link. The problem is human ignorance and that one Google password gives you full access.
If you use Google Drive, adding an extra layer of security through something like SyncDocs is a wise measure. That way, you have defence in depth.
I do find it interesting that the company that hates our privacy is so paranoid about theirs. Same with MS and FB. I do grasp it that they know "everything" and it's worth a fortune to them and if it were ever accessed by "unauthorized actors" a real shit-storm would happen. But still, a bit of respect for those who give Google everything.. like make "incognito mode" really incognito and not tell me what usernames, passwords, etc. I'm using for banks, etc.
"We do not rely on internal network segmentation or firewalling as our primary security mechanisms"
Doesn't say they don't use firewalls. Just says they're not 1990s about it like the arrogant believers in eggshell security. Willing to bet Google are at the forefront of automated incident response. None of this "nothing can get through MY defenses" machismo. Instead: "things WILL get through, but we have crazy quarantine and RCA responses automated into every layer".
You know, like actual security experts would approach things. Anyone who uses firewalls as the primary security mechanism either doesn't have an adequate budget, or doesn't care enough about the data...
(Hell, even salting and hashing your passwords in a database is accepting that firewalls can and do fail to keep the bad guys out. C'mon!...)
From the guys that never encrypted their leased line connections between datacentres until various three-letter-agencies said they were able to sniff them?
Though I don't doubt they try, it doesn't sound like they built things with the right kind of assumptions, which is probably worse than just about any other security problem you can imagine.
I trust companies that have had a good security/privacy scare more than those that haven't. Nothing causes a rethink on the howto than getting caught with your pants down. I'm willing to bet Google have refined their approaches aggressively. Remember: they're academics. Give a nerd a puzzle...
"These requirements limit the ability of an insider or adversary to make malicious modifications to source code and also provide a forensic trail from a service back to its source."
Methinks the Wolfsburg answer would be more than 2.
Which is why I would trust Google code more than the average car maker's code under my bonnet.
But then my motor is comes from the pre-code era.
Handing over design to LEA (not the NSA - the Feds and the cops) is a by-design business process. By law, actually.
The NSA smiley face "magic happens here"* type of illegal / pseudo-legal access will be what they're trying to prevent with the bootkit / microcode signing, encryption everywhere, PFS, etc.
* (it's one of the Snowden leaked presentations)
1 - we KNOW they read user data as they admit as much in their own Terms & Conditions - where is that happening, who controls that and where does it go? No data on that.
2 - it's a nice document, but until it has been vetted by an independent 3rd party that you could actually trust it is just that - a lot of theory.
3 - even if the DOCUMENT makes sense, where is the independent validation that it has actually been implemented and is maintained?
Not that I have a deep interest in the answers: I don't use them nor do I contemplate changing that at any point in the future.
What I find interesting is that this opens the possibility that, in future, in-house chips to validate hardware could well become readily available to every company. I don't think end users will get any because that's not the market, but Fortune 1000 companies could well invest in that kind of scheme, as well as important web site companies that are not (yet) in the Fortune 1000 list.
That's potentially a lot of money available to push this kind of tech forward. I wonder what the ripple effect would be.
just turning on the TPM isn't useful. you need to present the measurements to someone so that they can provide you with the means to unlock some resource that is needed (network access, a keychain, a specific secret, etc.).
the only use case for TPM in, say, a laptop is to enable TPM-bound SED. And that has its own problems - SW installs must be carefully managed to ensure that at a version boundary the SED can still be unlocked even though the TPM has changed - you can do this if you are a vendor [this is how we do it at skyportsys] but good luck if your workload is 2008-or-before-windows or linux and you aren't running on a platform like ours.
I can personally verify most of this stuff. Of course the system is not perfect. The custom chips business is a thing that I have been predicting for a number of years. The reason to publish is mostly to brag, but also because good security is in everyone's benefit. Laying out a roadmap for people who having gotten this far encourages others to implement these steps while they research better ones.
Interesting. We do basically all of this as a service for normal mortal enterprises at Skyport Systems (all of the attestation, etc.).
It's not easy to do especially because measurement is consistently not the most wonderful thing in the world to make robust given that the measurement/robustness of most BIOSes is pretty poor since no one is using it so the vendors mostly don't fix it. PCIe option roms, etc. need to be covered. A lot of vendors got caught with their pants down a few years back not even making the flash read-only after booting (and almost everyone screwed up update capsule validation!).
I am really curious if Google actually fails closed or open or some hybrid (fail to honeypot) when they see a failure.
Apart from the custom security chips and fitting them to all(?) their servers, (more details would be welcome here!) they seem to be doing exactly the same as any other reasonably large enterprise. I would be interested in knowing the quality and thoroughness of the implementation, which tends to vary in organizations I have been involved with.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
