For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more CKMo's commentsregister

Nintendo delivered. I'm only several hours in and know that I will be spending hundreds of hours on this game.


> Moreover, zero trust security can also take advantage of micro-segmentation to isolate parts of a network into smaller, more manageable segments. These segments can then be subjected to specific security controls and policies depending on the nature of the processes and data they are handling.

No. Access control should be implemented on a per-resource basis. Even legacy apps can be secured by a reverse proxy.


Is this related to fractional reserve banking?



Thanks!


Wonder if the IRS will try this soon or if the zero trust architecture they're implementing will come fast enough


SP had it right.

Freemium - the 'mium' means "not really"


VPNs use the perimeter-based security model, which has been declared faulty by NIST.

https://www.nccoe.nist.gov/sites/default/files/2022-12/zta-n...

Line 259:

"It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects (e.g., end users, applications, and other non-human entities that request information from resources) within it can be trusted."

A VPN has security at the gate, aka, it keeps people out of the network perimeter. The assumption is that if someone gets within the perimeter, they passed most checks and can be trusted. Or, if something is already within the perimeter, that entity is to be trusted.

Insider threats are very real. Negligent/malicious employees cause damages. BYOD stands for both Device and Disaster. Supply chain attacks work through ways that the perimeter cannot defend against, and that is why the National Institute of Standards and Technology calls for a shift away from the perimeter-based security.


Except, you can combine VPNs with other tech. There is nothing exclusionary about it. It's defense-in-depth which, tada, NIST recommends.


I agree that the VPN can be combined with other tech, such as layer 7 tooling to get best of both worlds (VPN for layer 4 data, layer 7 tooling for layer 7 data). What NIST recommends is shifting away from VPN-only infrastructure, and if one were to reevaluate the modern digital infrastructure stack for the current threat landscape, probably sparingly.

Page 22 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

"Remote enterprise assets should be able to access enterprise resources without needing to traverse enterprise network infrastructure first. For example, a remote subject should not be required to use a link back to the enterprise network (i.e., virtual private network [VPN]) to access services utilized by the enterprise and hosted by a public cloud provider (e.g., email)."


Right, VPN-only is bad. But VPNs are still needed because getting every last application to use TLS or whatever is a non-trivial project. So no, VPNs aren't bad, VPNs are only bad when it's all you use. We don't have to keep going on and on around this. It's very very simple.


You've misunderstood the quoted paragraph. They are saying that services that aren't on the corporate network behind the VPN or PEP should not require being routed through the corporate network to access, ideally.


It's a good direction but I wonder if it's strong enough. It acknowledges a lot of the problems in the current state of cybersecurity and effectively states "OK, we know this is a problem, we're going to do something about it."

But I wish they'd state exactly what they're going to do. Coming out with nominal fines for service owners and providers will just be chalked up as the cost of doing business. If a service like LastPass is going to be liable in the case of a data breach causing a consumer to be vulnerable but it's just a wrist slap, that just means prices shoot up without any necessary change on the provider.

It's one thing to acknowledge the issue, but being minimally invasive is worrying. If you're going to acknowledge that market forces have failed the consumer in your report, I hope your next step isn't going to be "hope the market is scared by scarecrows"


Glad to hear you've come around on zero trust! How did you apply zero trust to the webapp you mentioned, if I may ask?


Just installed the Tailscale client on my desktop machine, my laptop, and iPad. Logged in with GitHub on all three devices. The desktop machine was assigned a fixed IP and I can just type in an http URL with the ip address and the browser connects from any device.

One nice thing about it is it does the right thing if the client is in my house (connect via the LAN) or if I am out or about. Early on I had the tablet disconnect, but I found out that I just had to restart the Tailscale client and it was back up right away.


That's one of the ways I like to think about it. When you have zero trust, you can comfortably expose any app to the internet.

If you can't comfortably expose your app to the internet, you probably don't have zero trust.

The problem is, "exposed to the internet" is pretty much how most things are today, in a world where everything is trying to be "smart." There is a pathway to most assets and resources and that's what causes breaches. So all services and resources should be assumed as "exposed" until proven otherwise, therefore all infrastructure (and development) should apply zero trust principles.


https://www.pomerium.com/comparisons/tailscale-with-pomerium...

The tools do different things. Pomerium plays well with Tailscale.


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

Search:

HN For You