Implementation of your own NGFW on your own infrastructure: how we ate the cactus and what came of it

These solutions had matured over decades, were unrivaled in their characteristics, and, as a result, dominated the Russian market. Now, when the transition to domestic NGFWs is about to happen, companies not only have to choose the optimal solution for their tasks but also implement it in their infrastructure in such a way as not to disrupt all corporate traffic. Based on the experience of implementing our own product InfoWatch ARMA Wall (NGFW) in our infrastructure, we tell you how events unfold when a company has already chosen a firewall and begins piloting it. In the article, recommendations for NGFW customers: what important points need to be considered at the start, how to form a list of requirements, and what steps need to be taken for refinement to get a working product in the end.

We, like most companies in the Russian market, have been closely engaged in the creation of NGFWs for the past few years, and in 2019 we developed and released a commercial version of the ICS for the protection of industrial networks InfoWatch Industrial ARMA Firewall. That is, we are not newcomers in the development of firewalls. The first version of the NGFW was built on the basis of this industrial firewall, and in the summer of 2024, we presented a new version - InfoWatch ARMA Wall (NGFW), with a new architecture and hardware platform.

In this article, Vladimir Sadovnikov, CTO of InfoWatch ARMA, and Stas Rumyantsev, product manager of InfoWatch ARMA, talk about how we decided to test all stages of firewall implementation on ourselves and rolled out our NGFW on our own infrastructure. Thanks to this pilot, we felt all stages of ICS implementation in double volume - simultaneously as a customer and as a developer.

How we decided to eat a cactus

Vladimir Sadovnikov, CTO of InfoWatch ARMA: "In 2022, after the departure of foreign manufacturers, many Russian companies were left without protection against cyberattacks, the number of which increased sharply, so it was important for us to offer the market a working option for protecting the network perimeter. However, as we developed the functionality, we came to the need to create a new platform for corporate NGFW - with a new level of performance and a wide range of options, and therefore a different architecture."

When planning the development of the updated version, we identified three major customer segments that we focused on first. The first are those who already have an idea about NGFW, have long used leading global solutions and are accustomed to their capabilities. Now they are looking for a replacement for them - both due to regulatory requirements and due to the complexity of purchasing, renewing licenses, and servicing foreign firewalls.

The second are those who previously solved the tasks of protecting network traffic using a set of specialized products. They built a kind of software chain in their IT infrastructure, most often based on Open Source, and maintained it largely on the enthusiasm of administrators. Now this solution is not suitable for them either due to regulatory requirements or due to increased risks of cyber threats, an increase in the number of targeted attacks, including on small companies.

The third are those who have already purchased a Russian NGFW solution, but for one reason or another want to supplement it with missing functionality or completely replace it.

Obviously, the updated version needed to be assembled taking into account the requests and requirements of these target audiences, put on pilots, and the expertise obtained used to refine the product. Even before the internal implementation began, we started communicating with customers and partners about which firewall functions they needed first and foremost - here and now. We conducted surveys to form a critically important set of features, interviewed specialists who operate the solution from both IT and IB sides, and gradually verified the list of requirements. At the same time, we remembered the certification restrictions - after all, the solution must replace the critically important tasks of existing infrastructures and for this, pass the FSTEC certification.

At some point, we decided to eat the cactus whole and implement our NGFW on the InfoWatch infrastructure as the main solution. This transition allowed us to debug the product's technical support process, conduct the latest version's operation in working conditions, and provide the development team with the most detailed report on identified defects. Now it sounds much simpler, but in practice, everything was much more complicated. As a result, internal piloting greatly influenced the entire development process. Developers followed the old principle of “eat your own dog food”, because they were the first to encounter the results of their work.

The entire implementation process can be divided into several key blocks:

• drawing up terms of reference and requirements

• refinement

• implementation

• technical support

• useful conclusions that we use to refine the product.

Drawing up terms of reference: bargaining, compromise, and trimming requirements

The IT and IB departments of InfoWatch participated in the formation of the terms of reference, each of which provided its own list of requirements. In fact, these lists represented a detailed list of the capabilities of a foreign NGFW.

We went from simple to complex, did not try to integrate all the features known on the market into the current version – we planned what functionality is needed right now, what capabilities can be implemented later, and what is redundant. We focused on the current hygienic minimum, without which no network can survive, on the current needs of customers and the functionality they need today.

Thus, we formed several large groups, each of which resulted in a ranked list of requirements: firewall, intrusion detection system, network functions, monitoring and events, management, fault tolerance, access protection, VPN.

The process of working with requirements moved quite quickly – a month for discussion and elimination, and another three months for implementation. As a result of negotiations, we cut more than 20% in the lines of requirements, and in terms of meanings and volumes of work, it turned out to be much more. That is, the list of wishes turned into a list of specific functions.

Vladimir Sadovnikov: "Some customers tell us – do it like Check Point. And there is an even more sophisticated combine, an even more complex router, even more protocols, but not all of this is really necessary. Let's proceed from our real needs, there is no need to focus on Western solutions with their specifics and more than 50 years of development experience. There is no need to look for Cisco numbers and indicators in domestic products, it is better to evaluate what your business really needs right now."

Refinement: performance and functionality that is sufficient

There is a level of requirements under which the product will have to be adjusted in any case. In our case, refinement was needed because we use specific services such as ActiveSync support, Radius, and others. In addition to planned work, many interesting points were revealed in the internal pilot that we did not even suspect.

A lot of effort had to be spent on minor improvements to make everything work as it should. Each item on the list of requirements was first tested within the development team, then in the InfoWatch team. A significant amount of time was spent on internal communication and consultation, as it was initially difficult to perceive your company as an external customer: everyone is sitting in the same office and to solve an urgent issue, it is easier to walk to a colleague instead of creating a ticket in the CRM.

An important point – in the context of product improvements, it is worth mentioning the speed and performance of the solution and how we moved in this direction, what results and conclusions we came to. Today, "The Wall" is presented in three hardware configurations: K10000, K1000, and K100. All of them are certified by the Ministry of Industry and Trade and meet the needs of most Russian companies – as a rule, their distributed infrastructure uses exactly 1 Gbit/sec and 10 Gbit/sec network interfaces. By the way, in our own networks, only in certain points was 10 Gbit/sec, everything else was gigabit. As for 25 Gbit/sec or 40 Gbit/sec interfaces – this is already the level of data centers.

Implementation: expectations and reality

Pilots usually last several months, and during the testing process, various problems and questions may arise. Some of them can be solved without additional development through flexible settings and configuration changes. The development time can also vary - from a couple of hours, when you just need to rebuild the configuration chain, to requests for new functionality, which can take up to six months.

The problem we faced was that our large network, which was running on different equipment, was not ready for NGFW. Reality and our expectations were very different. Then we made the first test contour ARMA, which currently works as a full-fledged test alpha laboratory, where the latest versions are uploaded, and tested stable releases go to the external contour. First, the solution was launched on the guest Wi-Fi network, received powerful feedback from colleagues (in different formats:), and when we achieved high-quality NGFW operation in this area, we transferred it to a larger network segment.

Vladimir Sadovnikov: “All corporate traffic passes through our product, including video calls, access to internal resources, mail, VPN, etc. So developers not only create the product, but also actively use it, checking performance and functionality in real conditions. At the same time, they have the opportunity to verify the operability of user scenarios, the correctness of the applied security parameters, overall performance, and fix errors that may occur during debugging.”

The biggest challenge for us at this stage was to decide on the final transition. Everyone was afraid to flip the switch and go into production, although we were ready even for the most unpleasant scenario that the network would go down for some time. We were treading water and wasting time, but the fears were not justified, and the main problems were solved in the test contour.

Of course, all companies have different networks, it is impossible to make them the same and foresee all scenarios: different segments and contours, some have virtual subnets, some have legacy under the hood twenty years ago. To solve the issues with product refinement after implementation, the combination of support engineers who communicated with the customer and the development team, and the combination of the development team with engineers with feedback to the customer worked perfectly. When all the stars aligned and the processes were established, we had a feedback, analysis, and solution search pipeline with subsequent feature refinement.

Technical Support Tested on Ourselves

The lack of quality technical support can halt any piloting. We were able to build the process so that it took several hours, including because we literally worked behind one "wall": the IT and IS departments acted as the customer, and the development department was responsible for troubleshooting, delivering features, and finding optimal configurations for a large number of interconnected functions and services.

Now several times a week we discuss new requests, everyone receives feedback on their statuses and sees development plans, we exchange information about the timing of feature installations, assess the need for certain functionalities. We closely interact with all participants in the process from other departments and can plan our workload, order additional equipment, move infrastructure, and other activities. We do not block each other, we work as a single front, and this allows us to move forward.

Vladimir Sadovnikov: "We work at the priority level to ensure that the goal we are pursuing is achieved. At the implementation stage, the main goal was to launch. At the stage when we have already launched and made mistakes, the goal was to fix the errors so that colleagues could continue testing."

What's Next?

We are adding user scenarios to the NGFW from the list that resulted from communication with internal and external customers, and we adjust them as new needs arise based on the results of pilots, validate the resulting scenarios and technical requirements, and include them in the solution.

By the end of 2024, we plan to expand integration capabilities in terms of interaction with external SIEM systems, the InfoWatch ARMA Management Console, and the InfoWatch DLP product line. Integration is extremely important because the implementation of NGFW takes place on a formed infrastructure, and the firewall must qualitatively complement all its elements - for example, enrich the SIEM system with data, be managed centrally through a familiar interface, and enable the implementation of new DLP scenarios. And we are also continuing the process of certifying the software part of the product.

Conclusions based on the results of the internal pilot

A company that decides to install NGFW must definitely prepare its information security service for this: review the rules that they used to secure the network, adapt them to the new solution. Information security specialists should be comfortable working with the new tool.

Do not rely on abstract performance figures from tender specifications. It is better to evaluate the real indicators that support your networks and network cards, as well as the speeds of your devices.

Even with typical scenarios, there is and cannot be a universal NGFW. Network segments in each organization are different, and the load in different segments is distributed differently. In one of our pilot projects, a customer from the industrial sector did not have a single traffic entry point, and after long joint searches, we found the most critical places: two points with clusters where 10 Gbps traffic actually passed, and two without clusters - a slightly less important segment with traffic up to 100 Mbps. This is a good example of how several products were used to meet the needs of one client.

And probably the most important and somewhat philosophical conclusion: the domestic NGFW market is essentially at the initial stage of its evolution, and now both customers and developers have an excellent opportunity to participate in the development of this segment under Russian realities. This is a win-win process that, as we believe, will benefit the entire industry.