Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud Security //

Google

1/18/2017
12:58 PM
Curtis Franklin
Curtis Franklin
Curt Franklin
50%
50%

Google Security Lessons for IT

Google released a new paper on their infrastructure security: What's in it for IT managers looking for security help?

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I think the boss is bing watching '70s TV shows again!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-26244
PUBLISHED: 2020-12-02
Python oic is a Python OpenID Connect implementation. In Python oic before version 1.2.1, there are several related cryptographic issues affecting client implementations that use the library. The issues are: 1) The IdToken signature algorithm was not checked automatically, but only if the expecte...
CVE-2020-28206
PUBLISHED: 2020-12-02
An issue was discovered in Bitrix24 Bitrix Framework (1c site management) 20.0. An "User enumeration and Improper Restriction of Excessive Authentication Attempts" vulnerability exists in the admin login form, allowing a remote user to enumerate users in the administrator group. This also ...
CVE-2017-14451
PUBLISHED: 2020-12-02
An exploitable out-of-bounds read vulnerability exists in libevm (Ethereum Virtual Machine) of CPP-Ethereum. A specially crafted smart contract code can cause an out-of-bounds read which can subsequently trigger an out-of-bounds write resulting in remote code execution. An attacker can create/send m...
CVE-2017-2910
PUBLISHED: 2020-12-02
An exploitable Out-of-bounds Write vulnerability exists in the xls_addCell function of libxls 2.0. A specially crafted xls file can cause a memory corruption resulting in remote code execution. An attacker can send malicious xls file to trigger this vulnerability.
CVE-2020-13493
PUBLISHED: 2020-12-02
A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. A specially crafted USDC file format path jumps decompression heap overflow in a way path jumps are processed. To trigger this vulnerability, the victim needs to open an atta...