Some of my readers got annoyed when I mentioned Google’s BeyondCorp and RFC 1925 in the same sentence (to be perfectly clear, I had Rule#11 in mind). I totally understand that sentiment – reading the reactions from industry press it seems to be the best thing that happened to Enterprise IT in decades.

Let me explain in simple terms why I think it’s not such a big deal and definitely not something new, let alone revolutionary.

Before moving on…

Please note that although the idea itself is simple and old, Google engineers did another great engineering job (I would expect nothing less) … but in my grumpy opinion that still doesn’t warrant the reactions we’ve seen from salivating clueless fanboys.

It’s also perfectly possible I’ve missed something fundamental, in which case please write a comment. Oh, and just in case you want to get it straight from the source, here’s the original article.

Back to the topic at hand…

As always, let’s start with The Problem. This time we have users connected to an untrusted network that want to access an application we care about (at least a bit). The “only” problem is that there are other people around who might also want to access that same application for nefarious purposes.

Nothing new, right? Well, the one thing Google BeyondCorp team nailed was admitting that the internal client networks aren’t much safer than the global Internet, and decided to treat them (almost) the same.

You get mostly the same results once you move your internal workload to the $Cloud, so let's not pretend it's something revolutionary. Ed Horley will speak about this particular can of worms in the June 2018 session of Building Next-Generation Data Center online course.

Anyway, back to the original problem. You can harden the application so it can survive the Big Bad Internet in all its “glory”. After all, there are all sorts of mission-critical applications accessible from the public Internet. Guess what – most people don’t trust their internal applications (or their developers) enough to do that. Sometimes they shouldn't trust even their public-facing application, but that's a different story.

Step 1: let’s solve the problem with a hefty dose of voodoo magic aka Next-Generation Firewall.

Just for the sake of completeness – people who know what they’re doing know that the first thing that will fall over when exposed to a decent DDoS attack will be the next-generation firewall so they invest in writing tight ACLs and hardening their servers and applications instead of financing the vendors. Sorry, I’m digressing…

Anyway, even the Next-Generation Firewalls are not good enough for most enterprise **applications. The powers that be want to make sure that only the authorized users can access those applications, naively hoping that all the authorized users are totally benevolent. Fat chance, but let’s not go down that path.

Enter the wonderful world of VPNs – let’s authenticate the users at a central point before admitting them into the network, and then use network-layer encryption to protect the data traversing less secure networks.

Interestingly, you wouldn’t need VPNs if only (A) all your applications would be accessible over TLS (next-generation SSL/HTTPS) and (B) you’d have a centralized sign-on solution similar to whatever you’re using to authenticate VPN users. You could use any browser on the client side and web proxy to ensure client communication is always encrypted… and that’s BeyondCorp in the nutshell.

Let’s recap. Assuming everything you do is web-based:

• Replace IPsec with TLS (HTTPS)
• Throw away VPN clients (because all you need is a browser)
• Pass all the traffic through a web proxy that handles user authentication and authorization.

Oh, and a bonus idea:

• Put the web proxy in front of the data center (between all client networks and web servers), not between Internet and the internal network, and you got BeyondCorp.

Not only is this not revolutionary, I know people who have been doing similar things for decades.

As for other perceived benefits:

• Yes, we got rid of VPN client… but guess what, you can’t access anything that’s not HTTP-based anymore. No problem, right?
• We replaced VPN concentration with web proxies, but we still have a central chokepoint.
• Traditional pointy-haired bosses wouldn’t trust an internal team to get it done right; those environments would be back to buying $vendor appliances no matter what… or buy a service from someone like CloudFlare (which is what I’ll be doing the next time my VPN client falls over when faced with an IPv6 network).

To summarize:

• Whenever you read about something revolutionary on the Internet, there’s a pretty high chance it isn’t;
• You can continue believing in Santa Claus and amazing power of technology (in which case I have a stock of blue pills for you), or decide to figure out what’s really going on;
• Find the original sources – most things you read about in industry press have been dumbed down beyond recognition. Can’t find them after extensive search? Move on, it was probably just a publicity stunt. I also decided to ignore companies that can’t get the basic paperwork right years ago – it does wonders when trying to figure out where to spend my time;
• Read the original information and try to figure out where you’ve seen similar ideas before. Based on that you’ll be quickly able to figure out what going on behind the scenes and what the benefits and challenges of the technology or solution might be… and do keep in mind that until you’ve identified the tradeoffs you haven’t looked hard enough. Don’t know enough networking history to do it? Talk to the nearest grumpy greybeard ;)