How to assess the risks for foreign NGFWs and choose a scheme for connecting a domestic analogue

Many of our customers use popular next-generation firewalls (NGFWs) for network protection. With their help, companies analyze incoming and outgoing traffic, prevent intrusions, build VPN tunnels to end devices, and so on. Someone purchases hardware or virtual NGFWs and administers them himself, someone rents resources from us and receives NGFW as a service.

At the end of February, Western hardware and software manufacturers started suspend work in Russia and even completely leave the country. This is an alarming situation for the information security market. If the vendor stops updates, this will nullify all protection for which there will be no fresh patches and signatures. Therefore, all owners of foreign NGFWs, even those with active support, thought about a replacement, or at least a temporary fallback.

In the article, using the example of the domestic UTM UserGate, I will show insurance options: from temporary switching to a domestic firewall to a complete replacement of NGFW.

What do customers face and what are they afraid of?

When a company acquires ownership of NGFW, it actually pays under two models:

  • One-time payment for a software and hardware complex or a virtual analogue. Most often, technical support is already included in the cost of a physical or virtual upline.

  • Monthly subscription to protection modules. IPS, IDS, application control, logging, and other security modules are often sold separately. The client can choose only the functionality he needs or buy a bundle with all modules. While the subscription is active, the equipment updates the necessary signature databases by accessing the vendor’s cloud.

After February 24, reports began to appear about the withdrawal of such subscriptions from Russian companies by NGFW vendors. Accordingly, all devices of these clients contained databases that were up-to-date at the time of the last update.

The uplines themselves continue to work. But any new vulnerability or new virus – and the firewall will no longer receive a signature from the developers and will not protect the network perimeter from the threat. Therefore, without new generation security modules, NGFW turns into a regular firewall, for which there are many free alternatives. And outdated IPS and antivirus will need to be replaced sooner or later.

In this situation, clients turn to domestic NGFWs. Many of them lack the opportunity to first test the solution and understand something about it. Here’s what we suggest you find out before using a new product, even if you’re considering it as a temporary solution.

What needs to be clarified before implementation

  1. Private NGFW or Public Subscription Service. In a normal situation, the client chooses a private solution on his own resources if he wants to be certified according to the requirements of the FSTEC.

    NGFW by service model (or MS) are more likely to choose if they want to transfer administration to qualified specialists, but they don’t have their own in the state.

    But in the current situation, there is another additional advantage of NGFW in cloud subscription: we do not know how long the situation will last, whether vendors will return, whether they will resume support. So, investing in new hardware is risky. You can overpay and then wait a long time for delivery on a wave of increased demand. Any virtual options will be cheaper and more accessible. And if the old vendor returns, NGFW in the cloud can simply be extinguished at no extra cost.

  1. What are the sizing requirements: how much traffic is planned to be passed, what VM parameters are needed for this. Based on this information, engineers will select the appropriate NGFW model.

  2. What are the requirements for fault tolerance: whether the client needs a cluster and in what mode.

  3. What NGFW modules the client needs and why. Here, specialists define the parameters for subscribing to additional modules.

  4. Is this a permanent move or temporary solution. The connection scheme of the solution in the cloud will depend on this.

  5. Where are client resources located?. This item also affects the connection scheme. For example, if the client is already hosted in our data centers with MSS NGFW, we can organize a joint network between UserGate and client resources.

    If the client is at their site, then instead of a junction, engineers will build an IPSec tunnel between the cloud with NGFW and the client site. The main downside here is performance.

With this information, you can proceed to the choice of connection scheme. I will show the three most common using UserGate as an example.

If you want to move immediately

The first option is for those who have assessed the risks of using foreign NGFWs, studied the possibilities of a domestic solution and did not find stop factors for a complete move.

Then the standard resource allocation scheme for MSS NGFW in our cloud will be as follows:

Of course, the real scheme can be more complicated, for example, the client may have more segments for different cases. But in any scheme, proven practices are observed, for example:

  • mail relays and exchangers are located in a separate segment of the DMZ;

  • there is a separate network core so as not to burden NGFW with routing. In this case, the firewall only filters incoming and outgoing traffic, and the specialized network equipment distributes this traffic across segments.

Moving to UserGate is similar to the process of migrating to other NGFW MSSs, as my colleague already told. Let me remind you the main points:

  1. First, all network and security settings are transferred “as is”: the old config is moved to UserGate. To avoid downtime during migration, engineers agree on the technological window in advance and document all parameters in detail:

    • How is the network segmented?

    • what VLANs are used,

    • what types of networks: routed, isolated (if we are talking about virtualization),

    • how the client accesses the Internet,

    • How everything is monitored

    • what NAT translations are used.

    Then a separate VM is created on UserGate, VLANs are sent there. All access rules are transferred from the old equipment, NAT translations are created with new addresses. Engineers extinguish the interface on the old NGFW and bring up the interface with the same address on UserGate. In parallel, the client changes DNS and sequentially switches all VLANs.

  2. Then we put the system on monitoring, observe the activity, check the operation of the configured rules and, if necessary, correct them.

  3. After we configure the necessary NGFW modules: IPS, application control, antivirus. First, we put the security profiles into monitoring mode and observe the triggers so as not to block the excess. And only then, together with the client, we agree on the rules for blocking.

Not everyone is ready for such radical changes: someone hopes for the resumption of the old firewall, does not want to invest in a new solution and change the network. Someone doubts an unverified product or waits for management’s decision. They have the following options.

If you want to test first

The cloud client can protect resources and at the same time check UserGate for lice using one of the temporary schemes.

  1. Put test circuit behind NGFW. The scheme for the test migration will be the same as above. So you can check how the system works with certain settings, wind up security modules, make a test publication and check the correctness of the business logic. After such a transfer, it is easier to put a productive system behind UserGate.

  2. Put UserGate “in the gap” between the Internet and the client firewall. This is a temporary option that requires very small changes to the network infrastructure. Traffic will be filtered on UserGate with up-to-date signatures, and client NGFW settings will be saved on the old equipment and there will be no need to migrate them.

    The diagram looks like this:

    In this case, only firewall rules are transferred to UserGate and selected NGFW modules are configured: first in monitoring mode, and only after agreement with the client – in blocking mode. By agreement with the client, you can also add NAT translations or resource publishing to UserGate.

    You can refuse the domestic solution at any time: it is enough to switch one route. And if the client likes the new NGFW, then the process of moving will be easier: it remains to gradually switch internal networks to UserGate.

  3. Loop traffic from client NGFW to UserGate. Interference with existing network infrastructure can be further minimized. In this case, we set up a junction with the client’s edge network equipment and wrap the traffic in a “loop” to UserGate, which acts as a filtering center. Looks like that:

    In this case, nothing is transferred to UserGate from the client’s old networks, only firewall rules and security profiles are configured.

In conclusion, I will briefly show what opportunities UserGate provides and why we settled on it. I will not do a full review of the product, I will focus on the features that are important in the current realities.

What and how can be protected by domestic UserGate

When switching to a domestic solution, 2 points are important for customers: how well NGFW meets the requirements of the Russian market, and how well its functionality suits the tasks that the western NGFW solved.

Russian specifics. Here, import substitution has a formal and practical side. I’ll start with a formal one – for those who care about certification.

UserGate is certified by FSTEC of Russia:

  • on requirements for firewalls (4th class, profiles A and B);

  • on requirements for intrusion detection systems (4th class);

  • 4 levels of trust.

For most clients, this protection is sufficient, except for those who work with state secrets.

From an informal point of view, it is important how quickly the solution adapts to market and legislative changes, for example, it helps customers quickly connect the necessary modules or signatures for blocking. Here UserGate is maximally focused on the Russian market: the developers have their own laboratory where signatures are written to neutralize vulnerabilities taking into account Russian specifics, they also have their own geobases.

Necessary and sufficient functionality. UserGate supports dynamic routing and is logically similar to Western counterparts. After the move, it will be easy to understand the interface: it is designed taking into account the usual patterns of work.

UserGate has modules that customers are most interested in:

  • IPS,

  • antivirus,

  • content filtering,

  • IRL filtering

  • IPSEC-VPN tunnels,

  • SSL VPN,

  • mail security,

  • mobile device control.

But besides this, there is specific protection, for example, support for automated process control systems (Scada). See the full list of modules here.

So, even in the current unstable situation, we have a choice of how to solve the problem of the withdrawal of Western NGFW:

  • select domestic analogues with the closest functionality;

  • avoid unnecessary capital expenditures thanks to the monthly lease of resources according to the MSS NGFW model;

  • it is not necessary to immediately move to the domestic NGFW: in the cloud, you can test the solution using a hybrid scheme and make a decision.

The proposed schemes are not the only ones; there are many more options for a specific situation. Some may like other domestic producers. Therefore, we are always ready to discuss and help with the implementation of other solutions.

Similar Posts

Leave a Reply Cancel reply