In which I agree with the federal government and bash VPNs for fun and profit
bastionzero.com
bastionzero.com
Only run stuff yourself that you have the resources to secure. It is why I'm bullish on Saas, it is eating the intranet.
1. Task management (JIRA clones, but worse) and coordination, possibly with external user (contractor) access which opens up a hole in the system anyways.
2. Custom workflows (BPMN-ish, but not disciplined and not, easily, connectable to each other), again with external user (contractor, citizen, applicants, whatever) access.
3. Document sharing (SharePoint, but more like a skin over a network share), again with external user access.
All of those can be covered by other systems, sometimes simpler ones than presently used (3 is the core of what HTTP was meant to serve, they "just" need access control on top of a basic HTTP server which is a solved problem these days).
A bigger problem with the bespoke apps is that they often have their own access control mechanisms, which don't always play well with the larger organization access control systems. They have their own user names and passwords, they may or may not connect to a CAC-authenticated backend. Or they do stupid things (had to fix one of these once) like not authenticating the CAC but using trust-on-first-use, and then the user's access had to be reset when they got a new CAC. Brilliant. These aren't good systems, they are serviceable systems.
There are other rapid application development tools (see Appian and others) that can cover (1) and (2) but provide a unified backend (which means the workflows can now be composed, too). SharePoint and other document management systems can cover (3). SharePoint can also cover (1) and (2) (though I've barely tolerated it for either use, it is at least better than dropping $1 million+ a year on hardware and software licenses for a one-off product supporting a half dozen users that doesn't integrate into the rest of the system).
This is still a big win, because:
a) You still have to go through the layer even if you’re on an office network.
b) The layer knows exactly which application you’re talking to, and maybe even something about the transaction you’re attempting (URL).
c) The layer can cooperate with the application, for example injecting a header about the authenticated user’s identity and groups.
a) You just mandate that people be logged into the VPN always — “the office network” is just as untrusted as a coffee shop.
b) That’s the address of the service.
c) That’s the address of the client. Also apps that care what user you are basically all implement auth again against probably LDAP if it’s a corp network.
I still think it’s a win because VPNs are clunky as hell but I think the security benefits are more to do with the political “rewrite” than the technical details. You can store your policy bits anywhere.
You can but the application layer produces a far more legible policy and record of events. The right layer of abstraction for policy is at the application layer.
Do people not realize that for every one "internet server" there are at least 10 servers that aren't connected to the internet and are only accessible via LAN?
What's their solution, just expose all this underwater glacier mass of compute to the public internet??
Lol.
1. Your IT infrastructure is mature enough that all application access is directed through a series of authenticating proxies, so that you're not making individual app-by-app configuration changes to enforce SSO/MFA/device-context rules.
2. Your VPNs have strictly iptables-style network access control (if that).
The latter subtext is true of most existing VPNs and is responsible, I think, for almost all of the flak access control VPNs take. Until pretty recently, the state of the art for access VPNs was stuff like OpenVPN, which is so painful to set up and maintain that most installations have no access control at all.
The former subtext is true almost nowhere, and that's a problem I have with arguments like this. I like the BastionZero people, but, obviously, most engineering teams aren't using BastionZero, or anything remotely like it. I also don't believe the dust has settled on what products/solutions like this are going to look like.
If you can't get that first subtext to hold true for your team, and you nevertheless adopt the logic of this post, you are going to be boned; you'll effectively be setting your security posture to a mid-oughts level, when VPNs were themselves a novelty at small engineering teams, and debug instances of apps hanging out on the Internet were a norm.
Meanwhile, you can mostly break the subtext about VPNs by using a modern VPN like (sorry, I have to say it again) Tailscale, which has fine-grained per-app ACLs based on role-based access control.
A major complaint the "Zero Trust" people have about modern VPNs is that app-layer proxies can do device-context authentication --- so "employer-owned device, up-to-date patches" is a valid access rule, and that's harder to do right now with things like Tailscale. Fair enough. But almost nobody is doing anything like that today, and I'm not sure that when the dust settles it'll be a market win for app-layer ZTA proxies.
You should do whatever you can to limit the scope of exposure for your networks, and you should not put off network access controls you can deploy today because you think you should just wait to see how ZTA products mature.
I think Tailscale is probably the most pragmatic next step for most companies.
I may be missing the mark, but Okta and competing IdP (identity platform) or CASB (cloud access security broker) products do stuff like this. SSH access is one piece of the puzzle when you talk about a VPN-less model; generally orgs need this capability around any corporate system that is web/ssh/vpn/api accessible.
An organization I worked at in the past solved this problem by using Terraform/IaC to deploy authenticating proxies with any in-house applications that were deployed. Everything else went through a CASB or CASB-like product. Seemed to work well enough, but added a lot of complexity to the overall infrastructure that we would have loved to avoid.
I haven't used it personally, but it looks pretty neat -- authenticating proxies in the cloud, no VPN needed. It seems that I need to implement authentication in my webapp is to (1) have my app listen on localhost (2) set up cloudflared on the same host (3) check the right HTTP header for authenticated user's email. And in return this gives me SSO and full logging (including per-request, something that Tailscale cannot give me)
I haven't read anything that suggests that webapp internal authentication is handled by Cloudflare Access. Cloudflare Access as far as I can tell just uses your SSO to setup a tunnel to your webapp, but you still need to authenticate to the webapp separately. If you found something that says different please LMK. I might have missed it.
If you look at how Cloudflare Access does SSH, you create a tunnel to the target host, the target host then runs a webserver that proxies between the SSH-server and your browser and you login to SSH via the browser.
> Cloudflare's browser-based terminal does not access the device's certificate store to gather SSH keys. Instead, users can input a username and password for password-based authentication or paste their private key. The terminal is rendered entirely in the user's browser [0]
So Cloudflare doesn't enforce policy on what Linux user a user can assume on the target host. It just merely establishes a tunnel. You can configure Cloudflare access to use short-lived certificates in which case:
> Access matches based on the identity that precedes an email domain. Unix usernames must match the identity preceding the email domain.
Which is nice but now requires you have configure all your linux boxes to have linux user accounts for all your SSO users. Then you are still mananging the privileges of the linux users in linux. It's doable with LDAP but I've rarely seen it done.
This is different from how bastion-zero works. Bastion-zero allows you to set and enforce policy between SSO identities and Linux users, e.g. Alice@example.com can assume `dev-user` or `readonly`. We are a bit ahead of the curve here. The biggest advantage of bastion-zero is that to compromise security both your SSO and the bastion need to be compromised. I don't believe CloudFlare Access has that yet.
[0]: Connect from a browser-rendered terminal https://developers.cloudflare.com/cloudflare-one/tutorials/s...
[1]: Ensure Unix usernames match user SSO identities https://developers.cloudflare.com/cloudflare-one/identity/us...
> After a visitor authenticates to Cloudflare Access, all subsequent requests to the application server contain a Cf-Access-Authenticated-User-Email header with the authenticated user. Our example uses user@example.com. This allows you to identify the user currently logged in.
So authorization is still app's responsibility, but at least the authentication is handled. Well, at least plain-text list of admins' emails is much easier to implement than full user-password database.
Regarding SSH, that requirement does sound annoying, agree that Bastion-zero's approach is superior.
[0] https://developers.cloudflare.com/cloudflare-one/identity/us...
In practical terms this new model is demanding a 5-10x increase in the number of security focused people at any subject organization, and there frankly aren't that many people out to be hired that are actually any good at it. (and the "cybersecurity" organizational mentality does not overlap as much as might be imagined with security research or forward-thinking computer science, those people would be bored to suicide filling out the forms all day that they know no one ever reads)
Most organizations are going to find a way to out-source this to things like "government clouds" so it's mostly a major revenue windfall for existing larger players in the same vein as other defense and government contracting.
Doesn't this usually require the VPN to do weird packet inspection things? Like you can't, afaik, have a VPN do application or request aware auth of an HSTS enabled endpoint.
But with the beyondcorp model, you can. So you don't need to sacrifice this, you just sacrifice the bad parts of it.
The application can be made aware of the VPN identity.
Whereas, just to pick an example and not as any sort of vendor endorsement, I can have a Palo Alto "VPN" that isn't even using private address ranges but sends user tagging data and performs traffic inspection to stop a compromised but authenticated user endpoint from performing attack attempts on the application endpoint.
Comedy example: The PAs we put it as part of a protection scheme for wide area renewable energy products blocked attempts to update some shitty GE SCADA software because GE was too lazy to renew their signing certificate and was somehow still OK with shipping builds. All the end users had been trained to simply click the "WTF YES I DON'T CARE I HAVE TO WORK TO DO" button. The network control policy did not give them the option.
Application layer proxies can do the same thing, sure, but that fundamentally isn't really any different other than it moves responsibility around.
But it obviously doesn’t go down to the app level, which is what the original government document is actually saying we should do. Unless you can guarantee that one host belongs to one and only one app, then restricting things to the host level doesn’t really help you that much beyond segmented VPNs.
So, I don’t really see how this is a huge improvement.
> But it obviously doesn’t go down to the app level, which is what the original government document is actually saying we should do.
Bastion-zero does go down to the app level. Bastion Zero lets you log into roles in applications not mere hosts or ports. This is one of the big advantages of bastion-zero over say tailscale or segmented VPNs.
With kube, bastion-zero you could enforce a policy that a particular user identity, say "Alice@example.com", can only access the control plane of certain kube clusters with the kube role 'dev-user'.
Not only is this policy enforced at the application and role level but logs are application and identity aware as well.
Look at an example of using bastion-zero for shell access. Alice's gsuite identity is Alice@example.com and lets say she has a policy in bastion-zero which allows her to login to the linux shell as 'qa-user' on the host 'qa-dev-123'. Without bastion-zero logs on 'qa-dev-123' would only capture the 'qa-user' performed some action so:
1. Application role: 'qa-user',
2. hostname: 'qa-dev-123',
3. Action: 'rm -rf /'
That isn't helpful if multiple people can sign in as 'qa-user'. Additionally since the logs are stored on the host, an attacker might be able to delete or tamper with them after the fact.
With bastion-zero, the bastion captures the logs off-the-wire preventing tampering and it associates each action Alice takes with:
1. OpenID Connect auth session: 'a specific authorization token issued by gsuite and associated with a particular machine',
2. Alice's OpenID Connect identity: 'Alice@example.com',
3. Application role: 'qa-user',
4. hostname: 'qa-dev-123',
5. cryptographic identity of host: 'pubkey:0x4e32...'
6. Action: 'rm -rf /'
This way we can tell, oh Alice's OpenID Connect identity token has been compromised on her laptop. Revoke that token. What other actions where taken under that token? Did the attacker successfully answer an MFA challenge from the Bastion? Yes? we know Alice's MFA secret has been compromised.
Our goal with basiton-zero:
* all parties have pubkeys which are strongly bound to their identity forever, but only usable over short periods of time
* all pubkeys are short lived and ephemeral you are expected to generate new ones, you don't need to remember old ones
* all the content of all messages is digitally signed by public keys producing logs which can be cryptographically attributed
* no single points of trust or compromise
* policy and logging are identity and application aware
No way in hell we'd expose their stuff directly to the internet, especially since these internal tools deal with things like benefits, paystubs, asset allocations, access control, etc.
Write your software as if it was going to be directly exposed to the internet. While VPNs do provide protection, they do not provide sufficient protection.
If software isn't safe to use without a VPN, it isn't safe to use with a VPN either.