4 ms·
A case against Layer 4 security tools
- burnte 4y agoUh, no. Maybe their tools have value, but their arguments are simply wrong. Nothing they say about L4 is true as far as cons. They link to another article about VPNs being "bad" where they said VPNs: Disrupt productivity Increase workload and margin of error No monitoring capability Poor security, utilizing a flawed and incomplete security model None of which are true. I have hundreds of healthcare employees all over the country and they're highly productive, we have LOTS of monitoring abilities, highly secure and does not have an "incomplete" security model for whatever that means. The workload increase thing is silly, clicking a single button is not an increased workload.
- CKMo 4y agoVPNs use the perimeter-based security model, which has been declared faulty by NIST. https://www.nccoe.nist.gov/sites/default/files/2022-12/zta-nist-sp-1800-35b-preliminary-draft-2.pdf 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.
- righttoolforjob 4y agoExcept, you can combine VPNs with other tech. There is nothing exclusionary about it. It's defense-in-depth which, tada, NIST recommends.
- CKMo 4y agoI 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.SP.800-207.pdf 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)."
- cryptonector 4y agoRight, 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.
- righttoolforjob 4y agoYou'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.
- 7952 4y agoI think VPNs can work great as you say but I don't think that is universal. It is very easy for them to become a bottleneck. And performance and stability issues are not always obvious to the end user so get ignored. Obviously these issues can be resolved but there is always a limit on time and resources.
- adrr 4y agoIf its layer 7, then you have to push a cert to the endpoints and MITM the traffic since everything is running SSL/TLS. Not sure that is exactly safer since now your security monitoring tools have access to everyone's password and authentication credentials.
- rileymat2 4y agoIn the picture, can someone explain FTP and MPG and JPEG at layer 6? I don't understand this. Edit: I am not exactly sure of the distinction between HTTP and FTP in the layers.
- marcus0x62 4y agoThe picture is stupid. IP networks were not designed with the seven-layer OSI model in mind, and, generally speaking, whenever someone talks about layers five and six in the context of a IP-based protocol they don’t understand what they are talking about. In the OSI reference model, it was opined that people would build common session and presentation management protocols on top of the transport layer. That, by and large, didn’t happen with IP.
- JohnMakin 4y ago"Less reliable: Layer 7 does not provide the same level of reliability as Layer 4, as it does not have the same error-checking mechanisms." Uh, doesn't stuff like HTTP run on top of layer 4? (eg, tcp). This article doesn't seem entirely correct, but I'm a dunce with this stuff.
- marcus0x62 4y agoYes. If you need reliability guarantees (guaranteed in-order delivery and retransmission of lost packets,) TCP provides that, and by extension, anything built on top of TCP, inherits TCP’s reliability guarantees. If you cannot accept the overhead of TCP’s reliability guarantees (or just don’t need it,) but still want service multiplexing, you’d typically use UDP for your protocol.