Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They're also (intentionally?) misrepresenting the memo.

> MFA should be integrated at the application layer, such as through an enterprise identity service as described above, rather than through network authentication (e.g., a virtual private network).

They comment with:

> While it’s no surprise seeing multi-factor authentication being a requirement, what stands out is that doing so at the network level is explicitly disallowed. Meaning all VPNs and tunnels – nextGen or not – do not meet the standard.

Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy.

I don't know or care who pomerium is or what they sell, but this sort of anti-advice severely diminishes their trustworthiness.



First of all its not a misrepresentation of the memo. The memo states:

> Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet.

Second with regards to this statement:

> Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy.

That's precisely what zero trust networking is. Ala Google's BeyondCorp:

> Virtually every company today uses firewalls to enforce perimeter security. However, this security model is problematic because, when that perimeter is breached, an attacker has relatively easy access to a company’s privileged intranet. As companies adopt mobile and cloud technologies, the perimeter is becoming increasingly difficult to enforce. Google is taking a different approach to network security. We are removing the requirement for a privileged intranet and moving our corporate applications to the Internet.

(https://storage.googleapis.com/pub-tools-public-publication-...)

Maybe they're wrong about all this, but it's not anti-advice. It's a legitimate security model being pursued by many different companies.


Even the BeyondCorp paper doesn't fully buy into this idea. If you're on a coffee shop's wi-fi network, you'll talk directly to Google's Access Proxy. But if you're in the building, you're 802.1x authenticating to their network before getting access.

The problem with VPNs is that enterprises have used them for decades as a crutch, extending their perimeter model out so that instead of a small SPOF, they have a gigantic, ever-changing SPOF. "ZTN-think" pushes this basic idea way past usefulness, to the point where all network controls are somehow suspicious. Which is crazy; BeyondCorp fundamentally relies on network access controls as well as application access controls, like every other modern network design. They're just different controls.


Zero trust is about not trusting anything, which means neither external nor internal network. Not trusting the internal network does not mean that you should open it up to everyone. You have misunderstood this gravely.

Google doesn't do what you suggest and I'll throw in another large security-aware company as well, known for their privacy-conscious phones. They protect the perimeter as well as the inside. As does any military organization. Stop spreading misinformation.


You're missing the point. There is no internal network in this new model.


That's not true. If you read what Google wrote regarding BeyondCorp the argument is that firewalls and VPNs were perimeter defences for weak internal networks and this is the main complaint, that breaching this defence would allow lateral movements as well as of course internal attacks. They have no issue with strong internal zero-trust networks.

So as I said previously, for most organizations, it would be crazy to the point of lunacy of their infosec team to allow the internet access to internal corporate systems and just rely on those to have been individually secured.

I would dare to say that nobody does this or I'll ask you to please give me the IP address of Google's internal DVCS server.


> Which of course is completely untrue. You still want VPNs to connect sites or even client/network and any security expert worth their salt will surely recommend you to have layered security. Opening up your internal network to the internet and rely on every app to do security correctly is a ridiculously bad strategy.

Having done FedRAMP and also running Tor servers, I'm also at the conclusion that using IP in any sort of rules is a bad practice. You should be identifying/verifying/authorizing/logging the connection regardless how it came to you. Consistently doing that means you now can control user access at a chokepoint (usually an IdP or similar token passing credentialled login).

If you have a malicious entry, you do not want lateral transfer to end up hitting less secure stuff on the network because of implicit network trust. Zero-Trust is about removing those implicit things. And if everything has service-level IdP token checks, not even replay attacks will work. As a malicious hacker, you're stuck there. Less scope of damage.

Same with Tor. For anyone running a Tor client or operating a Onionserver, all connections are actually an IPv6 overlay with routers that only support TCP (not UDP/ICMP). And since those absolutely will be randomized every 10m on average, you absolutely must verify the connection AND NOT the source/destination.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: