SAN FRANCISCO -- Google created the BeyondCorp program because it, like many other companies, found that as more and more employees needed to work rem
SAN FRANCISCO — Google created the BeyondCorp program because it, like many other companies, found that as more and more employees needed to work remotely the traditional notion of network perimeter security became meaningless.
Rory Ward, site reliability engineering manager at Google, told an audience at RSA Conference 2017 that he and his team have been working on BeyondCorp at Google for six years in order to move Google’s network security infrastructure to a “zero trust model” where authentication is based on trusting devices and users rather than the network itself.
Heather Adkins, director of security at Google, said that historically enterprise has envisioned the corporate network as a castle or a “bonbon” in which the sweet goodies are on the inside and surrounded by a strong perimeter.
“We designed it this way because 20-30 years ago we would buy hardware and software and we would connect it to networks inside a physical perimeter, inside a building,” Adkins said. “There came a time where we needed to protect it from the internet so we bought networking equipment that provided us with layer-3 firewall, layer-2 firewall and web application firewalls. This created the castle-like perimeter.”
However, Adkins noted as workers became mobile and people lived “outside the castle” and Google services were moving to the cloud, what had been a strong perimeter became more like Swiss cheese and difficult to maintain. Enterprises adopted VPN to extend the reach of the enterprise network, but employees don’t like them because they are “slow and cumbersome” and can be unreliable, especially on mobile networks.
Breaking down the (fire)walls
Adkins and Ward realized that if walls didn’t work, there needed to be a massive overhaul of how Google thought of network security. This led to the creation of BeyondCorp, which is based on three main principals:
1) All networks are treated as untrusted.
2) Access is granted based on what is known about the user and the device.
3) All access to services must be authenticated, authorized and encrypted.
Ward explained the key to making BeyondCorp work was all about “intimacy.” First, Google needed to reinvent the employee database with far more granular job codes to be used for determining what applications and data a user would be allowed to access. And they needed to “get more intimate” with devices by creating a detailed database of managed devices, which tracked hardware from procurement to provisioning to end of life, including repairs or upgrades. Interestingly, this “dynamic trust repository” of devices included digital certificates issued by Google’s internal CA to be used as unique identifiers.
Ward explained that the repository gave trust levels to different hardware configurations and created a policy for what a device can do on the network. For example, to access source code systems, one would have to be a full-time Google employee with an engineering job code and using a fully-trusted desktop.
“The trust definition of a device can go up or down dynamically depending on what was done and what the policy says,” Ward said. “We have complete knowledge of users, devices and an indication of trust of every device accessing Google systems.”
Google then externalized the company’s single-sign on and created what was essentially a “reverse proxy” to authenticate users.
Christopher Steffen, technical director at Cryptzone, said BeyondCorp’s method of security is similar to “an implementation of the software-defined perimeter (SDP) standard, created by the Cloud Security Alliance.”
“This approach makes lateral movement impossible for the user and any possible attackers, as the device or the user is only permitted access to resources for which they are specifically authorized to consume,” Steffen told SearchSecurity. “Accordingly the enterprise is able to reduce their attack surface, by as much as 99% in some cases — effectively leaving very little downside for a security-minded enterprise.”
Bobby Kuzma, system engineer at Core Security, said the BeyondCorp strategy model is “a natural outgrowth of what cloud providers have been doing for a while now.”
“I think that a move to this type of architecture is inevitable… eventually. It’s very much akin to, and an outgrowth of, the moves to microservice application architectures,” Kuzma told SearchSecurity. “There are a lot of hurdles that Google is able to make disappear by fiat. Legacy applications and non-standard protocols are a problem that impedes this strategy. For enterprises, I think that the legacy application problem is going to be a bigger hurdle than getting devices under active management for trust.”
Extending BeyondCorp to other organizations
Ward said it took two years just to create the trust repository of users and devices before beginning the task of migrating users over from the traditional corporate network to the BeyondCorp network — another long process of identifying when the new system didn’t work for certain users and adapting it. Because of this, Adkins said communication was key.
Now that the work is done, the team wanted to explain to others how they accomplished the task with a series of talks and white papers and guide other enterprises towards how their networks can be shifted.
Adkins admitted that their experience building BeyondCorp for Google was likely atypical for a number of reasons. First, BeyondCorp had full support and patience from Google’s executives, including co-founders Larry Page and Sergey Brin, which was invaluable because although this type of network was less expensive to maintain, the unlimited budget and support afforded by Google was instrumental in getting the program off the ground. Also, Ward said the BeyondCorp initiative would not have worked without “highly reliable systems” that experience almost zero down time, something that Google has worked diligently on over the years.
The budget issues could be exacerbated for some because “currently, all devices are managed devices,” according to Ward. Google hopes to be able to get to the point where users can bring their own devices but that makes maintaining the device trust repository more difficult.
Adkins advised that enterprises maintain clear communication with auditors because the BeyondCorp concepts may not be familiar to regulators.
“We found that by deeply engaging with [auditors], explaining how to translate the concepts that we used to be the rules and procedures that they have to follow, we’ve actually found quite good ability to be able to translate that,” Adkins said. “But that requires that you have a good relationship with your auditor.”
Steffen said cost should not be a factor for an enterprise looking to migrate to a software-defined perimeter (SDP) because “SDPs are considered affordable, especially when you factor the cost of security breaches and the solutions that an SDP can replace.” However, he noted that it could be difficult for a security professional to understand the “authenticate first, connect second” nature of its architecture.
“This is an approach that enterprises should consider adopting — be it the BeyondCorp model or any other version of the software-defined perimeter model, as it provides a new paradigm of security. An approach where devices and users are not trusted, and can only gain access to authenticated resources,” Steffen said. “In either model, after the initial setup, ongoing maintenance of users and managed devices is not significantly different or more burdensome than other security methods, and the enterprise creates a much more secure environment.”
Powered by WPeMatico