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

this is where zero trust has steered us wrong, inadvertently.

absolutely perimeter security based on weak auth (being 'on' the WAN) is insufficient.

but improving internal security doesn't address all internet-based attacks - which are the vast majority. in those cases, auth before connect is a good practice - but the auth (authentication and authorization) itself needs to be strong, and part of a multi-layered approach (the WAF etc are actually able to be simplified and do their job better when they don't need to filter the entire internet).



It does not matter how strong the auth is. As long as people can authenticate - regardless of how - there's a hole in the perimeter, and your security reduces to the capabilities of what is behind. Attacks do not even have to be targeted - when you have hundreds, thousands or even hundreds of thousands of employees, the likelihood of a laptop getting compromised by even a random attack is pretty high, and then the foot is in the door.

In other words, any kind of proper defense require the internal services to be fully battle-hardened to withstand arbitrary attacks anyway as the perimeter is breached, or you set yourself up for a catastrophic security breach. In this case, the perimeter added nothing but cost, inconvenience and a false sense of security.

If you are afraid of exposing such services without a perimeter, you should not be running those services at all.


well said and i agree. i believe we are talking about different layers. your point - essentially assume your network is always breached - absolutely.

and don't you make that 'battle hardening' simpler and more effective by reducing the attack surface? e.g. by taking your servers off the internet (meaning your inbound firewall rules become deny all inbound (even 443)). so enforce (strong) auth outside your dmz, before allowing sessions on your network (or overlay network), even for APIs, B2B etc (otherwise your fw has exceptions).

and, yes, when that gets compromised, the attacker now needs to deal with the next set of 'battle hardened' layers.

meaning, shouldn't reducing attack surface and battle hardened services be an 'and', not an 'or'?


If you have wall strong enough to block a missile, there is no value in putting a paper wall in front of it. "And" only wastes and confuses.

Attack surface is defined by the service, not by which malicious actors you expose it to.




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

Search: