3 ms·
yep was trying to avoid word which carry varying connotations, e.g. vpn or zero trust. zero implicit trust is likely the best term? you have to trust somethin
by gz5 2y ago
yep was trying to avoid word which carry varying connotations, e.g. vpn or zero trust.
zero implicit trust is likely the best term? you have to trust something, but enforce (and therefore trust) strong (not network based) identity, authN and authZ. this can be done anywhere via a software-only overlay.
a litmus test is server iptables (to use an example) looks like:
iptables -P INPUT DROP
iptables -P FORWARD DROP
and the only route outbound from the server is to the private overlay on one port, and that server still can't make those connections unless it is strongly identified and authenticated, and the overlay will not connect the client and server unless they are both authorized to communicate for that particular service(1)
(1)so for example if there is a zero day causing the 'server' to try to communicate with some_IP then the private overlay will not accept the connection, even though it is coming from the server
- mbreese 2y agoFor highly secured services, I completely see the rationale for a private overlayed network. Tailscale, et al are great for this, where you're only exposing services to members of the private network. The problems start when people make the assumption that the private network is a secured network. I don't think any of this would have mattered to ATT, as the breach was from a third party that wouldn't have been on a private network anyway. But, that would be a great service bonus -- only being able to connect to a service via a user-configurable private overlay network. It would be nice, but highly impractical... I can't even begin thinking about how customer support would be able to handle a scheme like this.
- wmf 2y agoCompanies worked that way for decades. Everything was on the corporate network which was only accessible in an office or via VPN.
- mbreese 2y agoSorry, I was trying to refer to creating overly VPN networks with vendors. So in the ATT case, it would mean their DB vendor (I’m assuming) creating separate VPN networks for each of their customers to connect through (in addition to username/pass credentials). The logistics of managing separate VPNs for each customer, for each user account, etc seems overwhelming. For more traditional single-entity networks, you’re right. But with more and more BYOD, those networks are at a higher risk than they used to be. That’s the reason for the shift… VPN tech is still sound, but it requires that you trust the devices that are connected to it. If you’re now also trying to trust devices from your company and your customers, that’s harder to work my head around.