
How to use BeyondCorp to ditch VPN, improve security and go to the cloud - fhoffa
https://www.blog.google/topics/google-cloud/how-use-beyondcorp-ditch-your-vpn-improve-security-and-go-cloud/
======
fortyfivan
Great to see them continue this series, and glad that this one touches on what
it takes for other companies to achieve something similar. I talk about
BeyondCorp a lot as evidence that the Zero Trust model works, and that
employees will love it.

The most common feedback I get is that it seems like too much of a stretch for
companies that don’t operate at Google scale. That may be true if looking at
the system as a whole, but the principles behind the architecture should
attract anyone’s attention - remove trust from the network by authenticating
and authorizing every request based on what’s known about the user and
connecting device at the time of the request.

Disclaimer: I work for ScaleFT, a provider of Zero Trust access management
solutions.

Edit: If folks are interested in hearing more about how other companies can
achieve something similar, here's video of a talk I gave at Heavybit a few
months ago on the subject: [https://www.heavybit.com/library/blog/beyondcorp-
meetup-goog...](https://www.heavybit.com/library/blog/beyondcorp-meetup-
google-security-for-everyone-else/)

~~~
api
The major barrier is really for companies that lack a lot of internal IT
expertise. It's really dangerous for people who don't understand security and
networking to just open up like this, since _most_ enterprise software is
grotesquely insecure out of the box. Everyone assumes LAN = safe = no need to
worry about security. This is always false, but it's especially false if
you're devolving away from LAN.

~~~
closeparen
The illusion that it's okay to run cleartext, unauthenticated services on an
internal network is also pretty dangerous. Making it clear that the network is
out in public might actually yield a better security posture overall.

If an organization is doing 802.1x, competently manages its endpoints (this is
a tiny, tiny fraction of "managed" Windows sites), etc then _maybe_ a
BeyondCorp-style architecture is a net loss of security.

If an attacker can waltz into a conference room or exploit some salesperson's
IE6 and start making requests from the "secure" network, probably best to make
it obvious that there is no secure network.

~~~
api
I've believed this for a long time, but try re-educating two generations of IT
people who think firewall equals security.

It's hard enough to get them to adopt IPv6 since most think NAT is essential
for security. "But my address is world reachable!" Face palm...

------
jgsec
I commend the Google team for not only deploying an effective and innovative
security solution, but also for contributing to security community through
this series of informative articles.

Enterprises need to know that while BeyondCorp is Google-specific, there are
similar types of open architectures that they can deploy today, most notably
the Software-Defined Perimeter (SDP).

SDP is an open architecture from the Cloud Security Alliance, and with it
security teams can ensure that:

. All users are authenticated and authorized BEFORE they can access network
resources

. Network resources are inaccessible to unauthorized users, dramatically
reducing the attack surface

. Fine-grained policies control access for all users – remote and on-premises
– to all resources , whether physical, virtual, or cloud

. All network traffic is encrypted, even if the underlying protocol is
insecure

Here’s a video of me presenting on Software-Defined Perimeter at the CSA
Summit at the 2017 RSA Conference
[https://www.youtube.com/watch?v=ysi_9c5fmBg](https://www.youtube.com/watch?v=ysi_9c5fmBg)
and a brief overview from our corporate site
[https://www.cryptzone.com/products/appgate/why-a-software-
de...](https://www.cryptzone.com/products/appgate/why-a-software-defined-
perimeter)

Disclaimer: I led the CSA’s Software-Defined Perimeter working group
publication of SDP-for-IaaS, and am leading the current effort to create an
SDP Architecture Guide. I also work at Cryptzone, an SDP platform vendor.

------
yegle
My ex-manager who left Google to another well established company once said
the most missed thing from Google was the ability to work remotely right away
on corp laptop with BeyondCorp.

Disclaimer I work for Google not related to BeyondCorp.

~~~
izacus
I thought Google doesn't allow remote work?

~~~
theDoug
This is incorrect! I began as a full-time remote employee and stayed so for 16
months until it made more sense for me to move to HQ.

There are hundreds of remote workers, but being local has definitely allowed
me to not need to rely on email and video chats so heavily.

(Disclosure: Google employee)

~~~
milesward
I concur: I'm typing this from my home office in Palm Springs, and I'm a
Director at Google.

~~~
JeremyBanks
Directors might get to work remotely. Good for you. I hope you enjoy Palm
Springs while your reports are trapped on 101.

 _Mere_ Developers are essentially never permitted to work remotely long-term.
Google would rather lose someone valuable like Tim Bray to a major competitor
than allow him to do so.

If you're a global subject expert like Professor Hinton, maybe you'll be
accommodated, but you dare don't mislead people into believing it's _remotely_
common. That would be a lie.

~~~
obstinate
Probably more dependent on one's immediate manager and/or chain than on
company wide policy.

Personally, I would not want to report to someone who spends the majority of
time remote. But maybe this person is a really great boss.

~~~
openplatypus
> I would not want to report to someone who spends the majority of time remote

Why? There is really little to no difference if person is in next cubicle or
video chat away.

~~~
obstinate
I work on a team with another remote team, and I assure you this is not always
the case.

------
johnmaguire2013
I work for Duo Security, which this year launched the first major commercial
implementation of BeyondCorp as a part of our product offering. Using it to
jump on to the wiki, for diff reviews, and other internal resources has been
excellent.

In addition to simple primary and second factor, you can design policies for
MDM-controlled devices only (i.e. designing endpoints that are trusted for
remote access), geolocation, and software versions on a per-application basis,
for example.

I think save for a few use cases (SSH into your datacenter, e.g.), VPNs will
be dead before we know it.

~~~
thomashabets2
VPNs will remain because of SSH, eh?

[https://github.com/google/huproxy](https://github.com/google/huproxy)

~~~
johnmaguire2013
I think you misunderstood. My point is that you will still need direct access
into the network in order to work on the BeyondCorp servers themselves, for
example -- not that SSH shouldn't, or couldn't, be covered under the zero
trust model as well.

~~~
thomashabets2
Maybe.

Are you saying that "the bootstraps" (panic access) is VPN? Why isn't the
first level just an open SSH port?

I'm not sure why "when all else fails" is better left a VPN port than an SSH
port.

I'd say SSH infrastructure (a server with only pubkey login, maybe behind TCP-
MD5 and/or heavily filtered source addresses) is probably more reliable and
safer than a VPN.

~~~
johnmaguire2013
With a VPN you have two security layers -- one into the network, and a second
one into each individual server.

They aren't mutually exclusive. Sure, you can leave SSH open publicly on WAN.
I wouldn't for anything mission-critical.

~~~
thomashabets2
I did mention two other security layers, so I take issue with you counting
only one.

Especially since the SSH access would obviously be on a dedicated jumpgate, so
that _IS_ two just right there. Maybe running a different OS and architecture
just lower risk of one zero-day piercing both.

Also huproxy, or squid, or anything else that provides network-level access.

But I also think that if you consider network-level access as fundamentally
different from other access then that's kinda missing the point of BeyondCorp.

~~~
johnmaguire2013
> But I also think that if you consider network-level access as fundamentally
> different from other access then that's kinda missing the point of
> BeyondCorp.

I understand what you're saying here. I think to me, the point is, don't trust
LAN access more than WAN access. But that doesn't mean that restricting LAN
access is a bad idea. One of the benefits to BeyondCorp is that you don't
(generally) require LAN access in order to access resources. But if your
BeyondCorp server goes down, then what? How will you access it?

I probably still wouldn't want to expose my mission critical services over WAN
(though I understand your point that VPN is a service exposed over WAN -- and
why not SSH then?) Maybe that's wrong of me (I likely haven't given this as
much thought as you), especially if you're using TCP-MD5 (which I actually
haven't heard of until now, sorry for missing that), or filtering source IP
addresses.

This is an interesting discussion, and I really appreciate your
thoughtfulness. I'd love to hear more about huproxy and how it's working for
you, if you'd care to discuss it more. My email is jmaguire@duo.com.

------
api
This is really awesome. My own venture ZeroTier (www.zerotier.com) was
strongly influenced by the original BeyondCorp paper. Our vision is a little
different in that we do network virtualization that treats the whole world
like one data center. Instead of eliminating the LAN you make it fully virtual
and mobile and replace the physical perimeter with a cryptographic one.

Here's a somewhat over-simplified TL;DR on Google's approach:

Make everything in your company a SaaS app that lives on the Internet via
cloud hosting or a proxy.

Nice but not always readily do-able.

~~~
rkrzr
Thank you for creating ZeroTier. It is really awesome. It's so much simpler to
setup than e.g. OpenVPN and the peer-to-peer architecture also makes a lot
more sense to me.

------
JoshMnem
Yesterday, I saw an article[1] about Amazon's plans to block websites in their
stores (a very bad thing) and was wondering when a company like Google was
going to launch a VPN service. I wonder if these things will meet in the long
term. If companies that control the network try to limit access to information
about their competitors, then their competitors might try to liberate that
information.

[1] [http://gizmodo.com/just-in-time-amazon-patents-method-to-
pre...](http://gizmodo.com/just-in-time-amazon-patents-method-to-prevent-
comparis-1796195563)

~~~
bitmapbrother
One of the more interesting insights from the comments (which I agree with)
was that the Amazon patent was for defensive purposes in order to prevent
other companies from trying to implement such an idea in their stores.

I have never given much thought to the idea of defensive patents, but if this
is truly the intent of Amazon's patent then it's brilliant.

~~~
euyyn
Not a lawyer, but wouldn't that be challengeable in court? I see the ethics of
it, but maybe legally it falls in the same bucket as patent trolls that hold
on a patent with no intention of ever commercializing it.

~~~
mikeash
I thought the whole problem with patent trolls was that holding a patent with
no intent of commercializing it was perfectly legal.

------
manigandham
This seems so completely obvious that it's surprising how common intranets and
internal services locked only by network rules are.

Also highly recommend [https://www.scaleft.com/](https://www.scaleft.com/) for
anyone who wants beyondcorp-style access to infrastructure.

------
madjam002
How is this different or more secure than let's say TLS client authentication
with the private key on a smart card / Yubikey?

~~~
DorothySim
They also take into account the state of the machine you're working on. So
locked bootloader and probably a client cert in TPM-like component, plus
"device health". Client certs alone are good for authentication (don't work in
HTTP/2 though) but they want to reach even better target - no malicious
software running on your computer.

That's from reading old papers, I don't know if anything changed now.

~~~
maxsaltonstall
That's correct. Previous papers touch on the inventory data pipeline and
machine health, though without as much detail as I might like in your shoes.
Our agents track a wide variety of things on client machines, and we use that
inventory data to determine how trustworthy a machine could be. [I work at
Google, and helped make these papers, and blog post, happen]

~~~
DorothySim
Interesting design. As far as I understood from old papers client certificates
are used only to identify the device while user authentication is handled
differently.

Could you elaborate on the technical details on user authentication? (If
that's not top-super-secret) I guess it's just like accounts.google.com for
Enterprise with mandatory 2FA (username+password+U2F key?). Does it work the
same on mobile/Android (U2F via NFC or codes)?

~~~
weeks
Android supports U2F via NFC and Bluetooth now, which is used for user
authentication on Android devices. We've also released an (experimental?) iOS
app to support U2F over Bluetooth.

[https://itunes.apple.com/us/app/google-smart-
lock/id11520663...](https://itunes.apple.com/us/app/google-smart-
lock/id1152066360)

------
rayvd
Dumb question - is the 4th article in the series only available via
;login;[1]?

The other articles in the series have PDF links, but not the latest one. I'm
assuming it will eventually...

[1]
[https://www.usenix.org/publications/login/summer2017/peck](https://www.usenix.org/publications/login/summer2017/peck)

~~~
maxsaltonstall
I think that was my mistake, the PDF is in the pipeline, expect it live within
a week.

~~~
maxsaltonstall
Blog post now links to downloadable PDF

------
com2kid
With productivity apps being cloud hosted (Office 365, Google Docs, Tableau,
PowerBI, etc) and with source code and team management services being hosted
(Github, Visual Studio Online, Gitlab, etc) huge percent of people's day to
day work can seemingly happens without a VPN.

The largest notable exceptions seem to be internal file shares, and remote
connections to machines that need to be behind a firewall.

I guess the overall point I have is that with the data files for both
productivity and source code being stored cloud side, that VPNs become less
and less necessary for a large % of workers.

~~~
sooper
"The largest notable exceptions seem to be internal file shares, and remote
connections to machines that need to be behind a firewall."

Office 365 / OneDrive and Google Drive are even doing away with the
requirement for internal fileshares. We used the former heavily at my previous
job and I use the latter in my current role. Both have been pretty good
alternatives.

~~~
whyagaindavid
I am looking for ideas to control hardware connrcted to PC. We use vnc-viewer
now. Can beyondcorp help here?

------
zxv
Part 3 [0] discusses "Wrapping SSH traffic in HTTP over TLS." Can one
comfortably do coding over a good cellular (LTE) connection over this?

I ask because, I find it relatively comfortable to do coding on a chromebook
over a 'mosh' session over LTE.

[0]
[https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45728.pdf)

~~~
londons_explore
To get good performance, one would need a BeyondCorp enabled mosh proxy.

With plain SSH over HTTP over TLS, performance is satisfactory but not great.
4G is just about usable for vim, but you'd probably be best off using sshfs
over http over tls and running vim locally, then compiling and running
remotely.

~~~
e12e
Git/mercurial over ssh and preform actions on push?

------
angry_octet
It almost seems like this could be described as dynamically building a per-
user VPN, via inbound proxies for admission control and traffic src/dst
filtering, and services hosted behind multiprotocol terminating proxies. Some
extra client analysis (practically effective, even if no theoretically valid
remote attestation), tedious but necessary work to understand the access
patterns for all the internal services, etc.

It seems there can still be lateral re-infection via difficult to patch shared
services (finance/procurement/obscure wikis). The examples in one of the
papers (delivery people not needing access to financial systems) is completely
bogus -- sometimes the worst engineered, most xss-y, mission critical apps
have to be accessed by everyone, have insanely hand coded 'business logic',
and no docs. Content aware behavioral profiling would seem to have a role in
managing that risk.

------
ransom1538
Sorry this will come off as a super dumb question. I use ssh. I can login,
edit, develop, run, basically anything. What am I missing? I thought VPNs are
for 'admin' types that need access to a MS Excel file.

~~~
justabystander
The VPN changes your network route. This can get you around geographic locks
(services that only work in certain areas). It can also get you around traffic
issues, if your ISP has technical/political routing issues. Like with
Comcast/Verizon refusing to add additional peering because they wanted to
double-bill netflix traffic.

Some VPN services also advertise additional privacy or anonymity, but trusting
a stranger to not sell you out to their local government isn't usually a good
idea.

From a business standpoint, you may want web and network services without
exposing them to the wider internet. So they're only accessible on IPs in
local subnets. VPNs will get you inside the wall.

------
mtgx
Duo Security seems to be offering a BeyondCorp-like third-party solution for
client companies:

[https://duo.com/pricing/duo-beyond](https://duo.com/pricing/duo-beyond)

------
troymc
"Over the course of the migration we’ve discovered [Google] services that we
thought were long dead..."

Maybe some Google employees were still using Google Reader?

------
pamatthe
Stumbled across beyondcorp.com a few months ago. Great to see google, scaleft,
and others pushing the envelope here.

------
brianhama
This sounds a lot like Microsoft's DirectAccess which has been in the
Enterprise version of Windows since Windows 8. Please correct me if I'm wrong
though.

~~~
brazzledazzle
Kind of. Microsoft sold it more as an always-on VPN. They weren't selling a
radically different philosophy for securing your network with it. But
regardless of the differences Microsoft really hamstrung themselves by making
it so Windows centric.

~~~
Spivak
At the present moment Cisco is getting our money rather than MS for our VPN
specifically because our Linux users couldn't leverage DA.

------
metalliqaz
Interesting. This will never happen at my big company, though. Seems hard to
imagine most companies being able to manage the complexity.

~~~
wmf
You never know. SaaS is kind of a gateway drug to BeyondCorp since SaaS isn't
inside the firewall to begin with. The next step is to start applying a SaaS
mindset to your own internal apps and then you're mostly there.

------
maxsaltonstall
Link the blog post now points to a downloadable PDF thanks to Google Drive.

~~~
karlgrz
Still not seeing that.

------
VectorLock
Anywhere we can read the publication without being a subscriber to LOGIN?

------
coverband
Is there a link to the actual (fourth) paper? I only see the abstract.

~~~
maxsaltonstall
Working on that now, I think I messed up on my end with our internal tool,
hope to have the full PDF download from research.google.com in a day or two,
maybe next week if I epic failed. [I work at Google, and helped make these
papers, and blog post, happen]

~~~
medina
& add cross-link to things like google/huproxy ?

------
macawfish
"We discovered services we thought were long dead..."

------
libeclipse
What's wrong with VPN?

~~~
rocqua
Just doing VPN reinforces the wrong notion that LAN == Safe.

~~~
libeclipse
Wait, _that 's_ the massive problem? Jesus.

I'll stick with a VPN.

------
talles
off topic: I never noticed that there's a .google TLD...

------
tempodox
Google wants my traffic for themselves and calls it “more secure”. Ha ha, nice
try.

------
ddalex
I n k

------
ddalex
Llllklklll

------
cosarara97
So google bought the .google TLD!

~~~
hamandcheese
This is not news:
[https://news.ycombinator.com/from?site=blog.google](https://news.ycombinator.com/from?site=blog.google)

------
devoply
Yes turn keys over to Google. I am sure if you are an American Fortune 500
company you have no problem with this. Not so if you are a non-American
company. Though a lot of people will jump on board despite the huge security
implications of doing something like this and turning over all your security
over to Google. Meanwhile nation states are exploring how to use quantum
encryption to prevent eaves dropping others are being coerced to simply hand
over security to a third party that you hardly trust with any sense of
privacy.

~~~
magicalist
It seems from the article this is only being offered as a product to people
already using Google Cloud services, specifically for accessing those
services? Otherwise it's just a series of papers describing the system.

~~~
maxsaltonstall
You're right, the initial version of Identity-Aware Proxy (IAP) is for Cloud
applications, but that's not the end of the story, and we're learning from
BeyondCorp's 7 year journey to inform the direction of IAP going forward. [I
work at Google, and helped make these papers, and blog post, happen]

~~~
puzzle
How do you use IAP with GKE?

~~~
mikecb
Haven't tried yet myself, but since the ingress resource is just an https load
balancer, enable IAP on that. Like so: [https://medium.com/@DazWilkin/google-
cloud-iap-and-gke-c773d...](https://medium.com/@DazWilkin/google-cloud-iap-
and-gke-c773da56c3cf)

Edit more direct: [https://cloud.google.com/iap/docs/container-engine-
quickstar...](https://cloud.google.com/iap/docs/container-engine-quickstart)

