Slashdot Mirror
Google Reveals Its Servers All Contain Custom Security Silicon (theregister.co.uk)
Google has published an Infrastructure Security Design Overview that explains how it secures the cloud it uses for its own operations and for public cloud services. From a report on The Register: The document outlines six layers of security and reveals some interesting factoids about the Alphabet subsidiary's operations, none more so than the disclosure that: "We also design custom chips, including a hardware security chip that is currently being deployed on both servers and peripherals. These chips allow us to securely identify and authenticate legitimate Google devices at the hardware level." That silicon works alongside cryptographic signatures employed "over low-level components like the BIOS, bootloader, kernel, and base operating system image." "These signatures can be validated during each boot or update," the document says, adding that "the components are all Google-controlled, built, and hardened. With each new generation of hardware we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above mentioned Google-designed security chip."
It won't stop a warrant or a subpoena...
“He’s not deformed, he’s just drunk!”
With all that security for their own systems, you would think they could put a little more effort toward making Android more secure. But alas, Android remains more vulnerable, by total number of vulnerabilities, than any other product.
I remember cracking open a GSA with a failed hard drive that was out of warranty to try and fix it. Aside from weird part configurations and non standard sizes, they did just about every other trick to keep you from mucking about in there.
I did manage to get a new drive in there but the thing was worthless without google's software on it. Thanks for telling me that before I spent a day on it, Dave.
Google has been designing and manufacturing their own data center motherboards for years. If a motherboard died in the rack, it was cheaper to leave it there. I knew that when I worked at the Google IT help desk in 2008 and built out a Google data center testbed in 2011.
Sounds like TPM functionality, which can certainly have custom deviations and extensions to facilitate other security operations. Going with TPM (or at least, it's interface) means the motherboard design & electricals are already readily accessible, the BIOS already knows how to use it for secure boot, etc.
Your statement of "fact" is utterly false, and would be meaningless if it were true.
Mac OS X, Mac iOS, several versions of Windows, several Linux distributions each have more CVEs than Android. Android is in fact #17 on the list of most vulnerabilities (in other words, it's among the most secure popular operating systems, by CVE count).
However, counting the number of reported vulnerabilities is utterly bogus. One day we got a CVE for Linux which was essentially "by running 'ls /*/*/*/*/*/*' a local user can use up a chunk of their resource allotment. By doing so in a hundred shells at once, they can DOS themselves". That's a pretty stupid, CVE, IMHO, but okay, we put it in our database as an informational. The same day, there was a CVE for Windows remote code execution - an attacker can run whatever code they want, over the network.
So each of these is one vulnerability:
On my own Linux machine, I can use the CPU time allotted to me.
From here, I can connect to your Windows machine over the internet and delete all your stuff.
Counting those as equal would be just stupid, so "number of vulnerabilities reported" doesn't at all mean a lower count is safer. In fact, there is a significant element that is the opposite: where some software is closely inspected and any behavior that's at all interesting is documented, that system is likely safer than one where only the most egregious security holes are documented. If "omg a local user can choose to waste the resources assigned to them" is considered a vulnerability worth documenting by Linux standards, that may mean Linux is pretty safe - people are documenting even the most minor non-issues because they aren't finding b significant issues.
You know that's what they're not telling you.
Does anyone know if this precedes custom NSA firmwares being deployed?
Actually the exact same source cited by your Bleeping Computer article.
https://www.cvedetails.com/top...
Which is largely a list of "most popular software", of course. The numbers in that list are approximately meaningless.
Things that sounds true but aren't?
Some hardware manufacturers seem to be doing so for quite some time, for various reasons. For example Cisco has been equipping its routers with such chips for many years:
http://www.cisco.com/c/en/us/p...
They have a whole process for securely booting such devices:
http://www.cisco.com/c/en/us/a...
Given increasing numbers of counterfeit manufactured devices and NSA tricks this is likely going to become more widespread.
Those numbers for malicious and questionable apps are interesting, thanks.
I'm the AC who posted the Bleeping Computer links. While raymorris and I clearly disagree on the matter of Android security (#17 on the all-time list is a misleading metric for the current state of Android security), I think we can find a bit of common ground on at least one matter. You, sir, are incredibly creepy and a complete jackass. There's no reason to follow raymorris around and post your spam in response to everything he posts. If you have an actual point to make about security, then make it. So far, you have yet to do so. I'm sure you'll reply by calling me a troll, then posting as AC pretending not to be APK to say that APK destroyed my arguments. It was a tired act a long time ago. Get lost.
"I don't shoot my mouth off without knowing what I'm talking about" - by raymorris (2726007) on Thursday December 31, 2015 @09:29AM (#51215379)
Raymorris you shoot your mouth off f'ing up in 2 security fuckups https://it.slashdot.org/comments.pl?sid=5351503&cid=47379233/ & https://slashdot.org/comments.pl?sid=5351503&cid=47374033/ + raymorris = scriptkiddie https://politics.slashdot.org/comments.pl?sid=8895203&cid=51726265/
&
Tell us how ONLY 'newer script kiddie tools' have stringlength built in (when PASCAL had it for ages - my fav tool) https://slashdot.org/comments.pl?sid=8472509&cid=51114383/ YOU BLUNDERING WANNABE!
APK
P.S.=> You like to talk behind others' backs like the gossiping bitch TROLL you are raymorris https://slashdot.org/comments.pl?sid=9880997&cid=53312265/ well, here I am letting YOU TALK in those links, showing your FAILS wannabe ... apk
Nobody is scheming behind your back. People would like you a lot better if you weren't constantly spamming your shit on this site. Your behavior toward users like raymorris and many other users in the past is despicable and no way to treat any human being. Fuck off.
See subject & https://slashdot.org/comments.pl?sid=9880997&cid=53312265/ & raymorris the fake has it coming for it!
* When I post about hosts (what you WEAKLY call 'spamming' as you have NO other 'out' weasel) it's on topic & solves issues (doing more for less natively + faster & more efficienctly vs. other crippled or bug riddled 'solutions') - let's see "Mr. 20 yrs of security & programming" (bullshit webchump CRAP & 1 line 'fixes' a kid in highschool can do) do better!
* Clue: You NEVER will. He's incapable of it.
APK
P.S.=> Plenty here like my work & as far as HUMAN SHIT like you liking me? I like STOMPING shits like you raymorris, into the FUCKING GROUND by letting you yourself illustrate your fuckups & incompetence, big mouth you can't backup & FUCKUPS galore https://tech.slashdot.org/comments.pl?sid=10125411&cid=53679377/ ... apk
The tl;dr is that security war is basically lost everywhere, so anyone telling you they're winning is not to be trusted. A boast from Google about their security ironically makes me believe in them less. (I respected their security a lot before.)
More concretely, overspending on any one of prevention (avoid classes of bugs), mitigation (avoid lateral spread), detection (avoid stealth rootkits), and recovery (never be in a situation where you have to shut down the business or run compromised for a week) is a sign of hubris and an operational mistake.
Google has the best security and the highest investment in security I'm aware of, but I still feel they are underinvested, especially now that they are moving to cloud.
OP is mostly about detection.
They have more security assets that are public aside from this detection stuff: they limit attack surfaces and write everything by hand in decent languages, which is good prevention. These are significant assets and are what drives me to cloud instead of expecting self-hosting to remain a defensible security decision.
They have a good "response" story in that, because they were all in on "continuously deployed microservices" before the rest of the devops fanbois, they have many options to mitigate an _unexploited_ bug that aren't so painful the business guys would fight them.
But an exploited bug is different, and that's the difference between "response" and "recovery." Response slide decks usually involve storytelling that conveniently excludes worst-cases covered by "prevention" and "detection."
Suppose the features the OP promise find malware in hard drive firmware. What do you do about it?
First, you "detected" it, yeah, but you have no idea how long it's been there or how it got there. You just have a bad signature. You have no idea what other persistence techniques may be in use, but probably not zero other persistence techniques based on what we have read from NSA leaks. They are very aware of "detection" regimes. The best plan may be to conceal from the adversary that you've discovered the malware and let them continue to steal your data while trying to answer these questions. Otherwise you tip your hand on your "detection" techniques and give the adversary an evasive edge: do you want to delude yourself into believing you've eliminated them or actually eliminate them? "Delay while performing rushed bespoke research uncertain to succeed" is terrible recovery.
Second, most persistence comes from an initial exploit plus a bunch of lateral moves. If you fix the initial exploit but not the lateral moves, and remove all the persietence, you have recovered. Where is the story about how they will remove all persistence, including stuff they're not specifically looking for? It is a significantly more terrible version of the "backdoored C compiler" story. Rebuilding a global compute network that has grown organically from cold start is basically impossible without planning, and business-wise unpalatable without a lot more planning. I haven't heard any company with a story about how they're going to do this, and I definitely haven't heard one from Google. Financial companies have a "DR site", but that is not sufficient because it's not cold so it doesn't act like a snapshot. "Cold start" implies "from a snapshot before the exploit." "Rebuild" implies safe ways of rolling the snapshot forward that recover data without also restoring persistence. This is incredibly hard and IMHO is almost all of the engineer-hour investment required in a "balanced" security investment scheme.
There is another discussion to be had on "mitigation". For some reason the "minimize attack surface" and "design security from the beginning" mindsets tend to go out the window when talking about lateral moves. It's all about throwing a bunch of ad-hoc "maybe this will help" stuff at the problem, "balancing" it against inconveniencing the programmers. I would like to see this story retold as "within approximately our existing convenience-bounds, how can we make the strongest promise from the fewest lines of assumed-correct code." Instead it's more like detection has spread to mitigation: booby traps and speedbumps all over the place.
...and not even read the article before saying that you "designing" something doesn't mean you're also "manufacturing" it. What you design might be really cool but take into account (no pun) who is actually implementing that design for you and how those "tests" are going to pan out. Media releases of "we're so safe and on top" don't work anymore. Wait, yeah they do. Just like the evening news, they give people things to talk about around the water cooler.
Good work with those designs!!!
Since Google does not have its own fab, it must go to an outside Fab, likely one firmly entrenched with Chinese operatives, to have them built. That means the silicon they get is not the silicon they designed.
Just ask Cisco..