x
Cloud Security

Google Security Lessons for IT

On matters of computing infrastructure, when Google talks, people listen. Because, you know, they have a lot of it. And when they speak on matters of infrastructure security, people tend to listen closely, not just for details of Google's security, but for details of how that security will have an impact on Google customers.

That's why a recent document, Google Infrastructure Security Design Overview, is getting so much attention around the Internet. It's important to note that this is not a multi-hundred-page detailed recipe for how to duplicate (or defeat) Google's security. This is, instead, a look at the broad principles and brush strokes that define the security at Google. Nevertheless, those interested in security will want to read the whole thing because there are several points that bear closer scrutiny from IT professionals.

While many pieces of the Google infrastructure security plan fall into the "common sense" category, three of the broad strokes seem less recognized among IT professionals. These three could be worth visiting even for those who lack the time or interest to read through the entire document.

Google's security plan is thorough in both scope and depth. The scope is dealt with in the first major point, the depth in the next two.

  • Security begins outside the door -- Google makes a rather big deal about the way in which they start taking secuirty seriously before the hardware hits the data center's raised floor. Their servers are built for them, to their own specifications, by carefully vetted manufacturing partners, so there's no chance of malware coming in the door in a 1U box. And they're just as careful with the employees, partners and contractors who have access to those data centers. The IT infrastructure extends to the physical infrastructure and a very broad perimeter.
  • Encryption is everywhere -- Security professionals frequently debate precisely which information should be encrypted, but Google takes an expansive view of encryption, providing multiple layers of encryption for many customers. In addition to the storage- and application-layer encryption that Google offers its customers, according to the document, "We enable hardware encryption support in our hard drives and SSDs and meticulously track each drive through its lifecycle." So the data is encrypted both at rest and in motion between applications and storage, and between the Internet and applications. Within the infrastructure, RPC traffic is also encrypted to make it more difficult for an attacker to hijack procedure calls and inter-process commands.
  • People and process are critical -- Yes, everyone gives lip service to the three legs of IT (and IT security); people, process and technology. But in practice, technology often gets the most attention because it's the easiest to tackle. In the document, Google describes a philosophy of constantly reviewing access permissions to make sure that each employee has the least privilege required to do their job. They also aggressively monitor employee activity to check for files, processes and applications accessed. The employee focus is one that begins with hiring and extends throughout the time that the employee has access to any part of the infrastructure.

Google is far from the only cloud service provider that gives glimpses into their security philosophy and processes. Amazon Web Services has a white paper on security processes and Microsoft Azure has a group of web pages on security. It's notable that so many similarities exist between the different documents -- and that so many of the policies and practices are adaptable for even very small companies and user populations.

— Curtis Franklin, Security Editor, Light Reading

Page 1 / 2   >   >>
kq4ym 1/30/2017 | 9:17:22 AM
Re: Human error And it would seem the last of the noted concerns might be the hardest or at least the least paid attention to in "constantly reviewing access permissions to make sure that each employee has the least privilege required to do their job." The monitoring of access by employees and what they are allowed or not to view could be a challenging task and may be why it's down on the list of priorities.
brooks7 1/23/2017 | 1:57:49 PM
Re: Human error  

I think the difference is the concern.  What I read is that Google is trying to avoid computers that show up at their premise pre-hacked.  And yes that is a thing.  It is possible in retail channels to get computers that come out of the box with their own Root Kit.  

seven

 
mendyk 1/23/2017 | 10:09:58 AM
Re: Human error The whitebox movement kind of reminds me of a DIY approach, with all the risks and rewards that entails. The fact that Google, with all its resources and brainpower, is locking in to an environment of a select few trusted partners reaffirms that DIY has its limits.
Curtis Franklin 1/23/2017 | 10:01:40 AM
Re: Human error mendyk, it's absolutely closer to the old model. But if there's anything I've learned in <mumble> decades in the business, it's that we move in cycles. "Everything old is new again..." and all that.

With any luck, we get a little better at it every time we cycle through, though. With any luck at all.
mendyk 1/23/2017 | 9:47:25 AM
Re: Human error "A very few trusted partners" -- that's a description that's much closer to the old (and not necessarily broken) model than to the whitebox model.
Curtis Franklin 1/22/2017 | 7:31:13 PM
Re: Verify the security stance of partners HardenStance, I'm old enough to remember when "Trust, but verify" was a big deal in the political realm. I think it's still tremendously important in business partnerships but it takes effort and dedication.
Curtis Franklin 1/22/2017 | 7:28:11 PM
Re: Human error mendyk, I think that disintermediation is a "thing" but that there are going to be a handful of huge exceptions. I think we can agree that few organizations buy as many servers as Google, but those that do -- I'm thinking Amazon, Microsoft, and a few big MSPs -- could very well go the route of designing their own hardware sourced from a very few trusted partners.
HardenStance 1/20/2017 | 3:13:53 AM
Verify the security stance of partners Verifying the security credentials of vendor partners is a key one.

A vendor partner says that they are compliant to this or that? That they're up to date with this or that latest release or this or that security patch?

Really?

Verify it.

There are solutions out there that trawl the Internet and can health-check the security status of this or that vendor's infrastructure. The customer can then verify if there are any gaps between what their vendor is telling them and what the independently verifiable status really is.

Nowadays there are fewer and fewer excuses for just taking your partners security stance at their word.

As relevant in the telco as well as the broader enterprise use case too.
mendyk 1/19/2017 | 3:37:57 PM
Re: Human error So it sounds like disintermediation of technology suppliers is, to use a Twitterverse term, over-rated. That's kind of a big development, if true.
Curtis Franklin 1/19/2017 | 3:19:28 PM
Re: Human error mendyk, I suspect we're getting into that sticky "total cost of ownership" area. The initial purchase price is almost certainly lower with a white-box server, but if you include things like security and performance, Google has evidently done the math and found that custom iron is the way to go. I'd love to moderate a panel with proponents of each side presenting their evidence!
Page 1 / 2   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE