In the cloud era, the DMZ has become more important – and more vulnerable – than its original architects ever thought possible. Ten or twenty years ago, back when most endpoints were still on-premise, the DMZ was an afterthought. It was very rare for a user outside the LAN to request access to a service within it, or vice versa, so the DMZ barely had anything in it. Now? Not so much.
Today, you’re either a software company, or you work with a huge number of SaaS vendors. You’re constantly providing access to users outside LAN or requesting access from services in the cloud. As a result, your DMZ is crowded with various applications. Although the DMZ is supposed to serve as a perimeter checkpoint, its function nowadays is more like an advertising billboard for attackers.
Each service you publish to the DMZ is another blip of information telling a potential hacker how many users you have, where you’re keeping your mission-critical data, and if that data includes something an attacker might want to steal. Here are four ways to stop that from happening.
- Make the DMZ a True Discontinuity
The idea behind the DMZ is that it must truly be separate from the LAN. As such, you should establish different IP routing and security policies in the DMZ, as opposed to the rest of the network. This makes it that much harder for attackers; they might figure out your DMZ, but they can’t then apply that knowledge to attack your LAN.
- Optimize Data Flows
Ideally, services from outside the DMZ will establish direct connections only to the DMZ itself. Services inside the DMZ will connect to the outside world only via proxies. Services inside the DMZ are more secure than those outside of it. Services that are better protected should assume the client role when requesting data from less-protected areas.
- Use a Two-Firewall Approach
While it’s possible to create a DMZ using just a single firewall with three or more network interfaces, two firewalls create a more secure deterrent. The first firewall represents the outer perimeter, and it directs traffic to the DMZ alone. The internal firewall allows traffic from the DMZ into the internal network. This approach is considered more secure, as it provides two distinct obstacles for an attacker to overcome.
Implement Zero Trust Network Access
Safe-T’s Zero Trust Network Access (ZTNA) solution, Secure Application Access, is changing the way organizations grant secure external access to their services. Safe-T Secure Application Access offers secure and transparent access for all types of entities (people, applications, and connected devices) to any internal application, service and data.
The solution forces users to authenticate into resources first and then they are granted access by the solution. Configurable policies define the orchestrated authentication steps that each user or group member must perform. Now, back-end services are not visible to unauthenticated users and the probability of suffering a successful attack is minimized. It’s like we always say here at Safe-T: Allow Everything. Trust Nothing.
Safe-T Zero Trust Network Access is based on Safe-T’s Reverse Access patent. The patented approach will make your DMZ even safer. This technology removes the need to open any ports within a firewall, while allowing secure application access between networks (through the firewall).
Reverse Access technology works by allowing to authenticate accessing users before they have access to your mission-critical applications. An attacker with access to your applications over an illegitimate session can perform reconnaissance on your network, attempt, code injection attacks, or even try to move laterally through the network. Without the ability to pose as a legitimate session, however, an attacker’s toolkit becomes much more limited.
A poorly-implemented DMZ draws attackers like moths to a flame, but a DMZ with ZTNA enabled is more like a bug zapper. Want to learn more about how to make this technology yours? Contact Safe-T today!