Sophos Connect and delivery of configuration via User Portal

By giving a service out for the Internet, every time the service is vulnerable to attack. It does not matter, if the service is the user portal or only the SSLVPN config download page. In the end, it is a exposed service. Likely most customers use the user portal for SSLVPN. So by creating a new service, the potion of customers, using "a new service" will have the same attack vector - If you call it user portal or "sslvpn download page" - its the same. You need to verify and approve the client towards the firewall to roll out the file to the client. The attack vector is important. If the service is vulnerable, it does not matter, what kind of service it is. 

The core problem is the way, how to role out the configuration. And this is actually already resolved differently with solutions like ZTNA. Sophos ZTNA for example is completely integrated with Central and rolls out the config via Central. No need to have the authentication and approval concept to the firewall. 

LuCar Toni you miss the point. I know any internet exposed service is vulnerable to attack (which includes the whole firewall itself, and Sophos Central BTW). The point is that the more functionality you expose the higher the risk. User Portal has a lot of functionality that isn't required for configuration delivery and if you remove that, you reduce the attack surface.

If you look at the details of CVE-2022-3236, you will see it affects both the User Portal and the Webadmin. Webadmin doesn't deliver configuration updates as far as I know, which implies that the vulnerability was in a different part of the functionality. If this is the case, a service that just delivered configurations wouldn't have suffered from this vulnerability.

You keep pushing ZTNA but as I have replied before, it is ridiculously expensive for small deployments and almost impossible to justify to small companies that want basic VPN functionality

LuCar Toni you miss the point. I know any internet exposed service is vulnerable to attack (which includes the whole firewall itself, and Sophos Central BTW). The point is that the more functionality you expose the higher the risk. User Portal has a lot of functionality that isn't required for configuration delivery and if you remove that, you reduce the attack surface.

If you look at the details of CVE-2022-3236, you will see it affects both the User Portal and the Webadmin. Webadmin doesn't deliver configuration updates as far as I know, which implies that the vulnerability was in a different part of the functionality. If this is the case, a service that just delivered configurations wouldn't have suffered from this vulnerability.

You keep pushing ZTNA but as I have replied before, it is ridiculously expensive for small deployments and almost impossible to justify to small companies that want basic VPN functionality

In a way, your first point is not valid. At the time, you open a service, it can be potentially be exploited. It does not matter, if its a user portal or a small "banner". The HTTP service has to run for this to be able to deliver something. This means, it is a potential externally facing service. Do not forget: Exploits are "bugs in the software". RCE most likely mean, you can execute code without authentication. The RCE does not care, if its a user portal or just a "banner in a http page". It will execude the code. So by reducing the amount of "data stored on one page" does not potentially mean, it is "more secure" in that way. Because the user portal is secured by authentication, it means, all of the data of the user portal is protected by authentication - But the basic http is still there - no matter what service you actually use. For example: In UTM you can disable certain features in User Portal - But the User Portal is still there. So the User Portal is still external facing and a surface.

In the end, something has to deliver the code and that is http service. If you call it user portal, webadmin or something else for SSLVPN only - It would have the same attack surface. 

And i am not the only one pushing ZTNA. ZTNA is the most likely the future of security posture management. We should move away from the general "ZTNA = VPN" thinking and more towards the general ZT approach. You want to keep your clients connected in a secure manner even in your own network. ZTNA can do this and build a seamless integration between apps. Its not a VPN tool - Its a security tool within the thinking of how to securely map your network. You do this in your network (behind the firewall) and on the road/home office. It does replace the need of VPN by its nature but its not a replacement product of VPN, because its build to work everywhere and connect the apps to the user. 

Hello LuCar Toni,

it's really surprising how you once again ignore the request of a community forum participant that your key security product SFOS is NOT safe and functional, and on the contrary, you are again "pushing" ZTNA here without complete knowledge of the needs of JasP.

JasP only wants a functional and safe product that Sophos sells, but so far it still only receives a very problematic product. Just like the rest of us.
How can you know that ZTNA will benefit for JasP if you don't know his needs, network topology, if he has a data center, branches, applications in the public cloud, etc..?!? Because without all that, ZTNA is just a completely unnecessarily overpriced VPN access to a single SFOS installation!
You are still ruthlessly forcing ZTNA, while JasP only wants your product and the related support to be functional!
Nothing more and nothing less...

And how YOU will JasP guarantee that the Sophos ZTNA solution will be reliable and secure, when the elementary security product of this architecture, SFOS, has such problems?!?

Regards

alda

I will not comment on your post, as this will lead to the same conversation about the same points. Feel free to reach out to your Sophos peers if you want to discuss anything further.