Managed firewall in focus – from service definition to reporting

We have a small advantage in that every day there's another hacker attack or something similar in the press and we can simply refer to it a little and make it clear to the customer that it's not enough to put up a firewall, install it once and then it's already running and in three years we'll do an extension or something similar, but that the protection mechanism is only really given, including the added value for the customer, if you regularly take care of the system, install firmware updates against special threats, special filter sets or similar. IT is simply too dynamic for that and the threat factors out there are simply too big and too diverse, which are currently sprouting up every day.

We have docked the systems to one of our monitoring systems, where we also continuously monitor the firewall and check what traffic is going in and out. Several times a week, we analyze what traffic has passed through the customer so that we can detect as early as possible if something is going wrong. Of course, we also use technology like MDR for some customers, which gives us help from a third party, where we can rely on the expertise of professionals and make sure that someone alerts us if something slips through the cracks.

For example, we occasionally see when customers bring devices into the network where they don't belong or include them in the WLAN or similar, where we then receive alerts where a so-called command and control server is contacted, i.e. where a device is apparently trying to download malicious code. Over the last few days, we've noticed this happening to customers on a number of occasions. Our technicians then go to the firewall. What kind of end device is it? Is this possibly legitimate traffic that really needs to get out? The last step is to talk to the customer: Listen, we've found a device here. Have you recorded something new?

Please take a look! Until one of us goes there, tries to identify the device and then removes it from the network. So far, we've actually been lucky that they've all been false alarms, i.e. that it was legitimate traffic that went out to the Internet and fortunately we weren't able to detect an attack or anything similar on the network.

Onboarding is first and foremost about coordinating as well as possible with IT or management in advance. What applications are you using? Do you use special software? So that you can then design the rules and regulations afterwards. But it often happens that it can't be clarified 100% in advance, so we set the firewall a little more laxly for the first day or two so as not to cause too much displeasure with the customer and then gradually analyze it – using log files, protocols, etc. – and then consult with the customer again to see whether these things are really needed.

Where we then see, okay, program XYZ, nobody thought of that. It still communicates on the Internet, then the set of rules has to be gradually refined and activated. It doesn't work 100 percent right from the start. It's a growing and continuous process that needs to be addressed, especially when onboarding new customers. And, as I said, it can't be intercepted 100 percent in advance.

We actually no longer have various packages in our portfolio. A few months ago, we had Standard, Premium and Basic Managed Firewall, which included different functionalities. We moved away from this because a) discussing the packages with the customer was sometimes exhausting and b) the largest package actually offers the best protection for the customer.

And we now only make the distinction based on throughput, which is reflected in the number of users. So for user number XYZ we have this package here, for a larger number you have to take this package and in it we actually already have the complete range of functions of the firewall included. And in addition, we always have the basic installation and integration into the customer's network at a flat rate, which we also charge the customer for. And on top of that, we have made adjustments to the rules, set up a VPN user, look at the reporting, take care of firmware updates, and also take care of things if a firmware update has gone wrong – all of this is included in the managed firewall packages.

What we don't include, which is billed according to the amount of service required, are major changes to the customer's network. Segmentation of networks or connection of various larger branch offices, etc., because this usually requires more know-how and effort, which simply cannot be calculated into these managed packages in advance.

We show this on our invoices via the ticket system with a €0 amount. "Included in the service contract" is then written on our invoice. So the customer knows that we have done something. And we have completely moved away from sending firewall reports to employees or the customer's management, because they are usually so technical that many customers can't do anything with them and the requests are greater than the benefits. Another thing is when we have the MDR service docked on, where customers are professionally monitored, then we have the issue of sending this report to the customer.

We do this managed firewall business exclusively with the solution that we know down to the last detail. If a different manufacturer or something similar is used by the customer, we clearly have to reject it for the Managed Service area, as we don't know all firewalls and prefer to deal with the product that is used by the majority of our customers. This is different if you are in the "non-managed service" area. You can then see, for example with partner companies, whether one or other partner can do it, but we definitely can't do it ourselves in this case. You simply open up a construction site that you don't want to have.