I apologise in advance for this question being very sparse in details and sounding rather hypothetical, reasons for this are hopefully explained below. I am not a security expert, but I am in a managerial position and find myself now arguing in defense of extra security measures for this case.

My company is in the process of ingesting data that comes from our clients' sensors and cameras by our network. There are numerous potential clients and all of them have a different network topology. The idea is to have a "data collection" server in the client's network, all the sensors/cameras/devices that we need data from are sending their data to this server. We will remotely connect to this server to download the data to our network.

In between their network and ours is obviously the internet, but also a special (high-level next-generation) firewall set up by our service provider and our own security infrastructure.

The client may also have firewalls and various security methods, but their level of security varies greatly and so does the security knowledge of their staff who operate in their network.

Because their staff and all of the devices in their network are beyond our control, I consider them a risk by default and for this question we can assume they can be compromised by an attacker.

For simplicity's sake, let's assume the data we need comes from web cameras/security cameras.

Let's assume the hypothetical attacker gains a foothold in their network and then proceeds to laterally move in the network and maybe even escalate privileges to the client network's admin level.

I have argued that we need to at least take some steps to logically separate the "data collection" server we need from the rest of their network. These could be setting up a software firewall on the server and to change the admin/user passwords so that they would be different from the rest of the network, and hardening our server in general.

The arguments against this are that the client would be setting up said server in their network and is reluctant to do the extra work and it would not be needed, since our side of the network is quite protected by the service provider's security and our own.

The questions are:

  • What potential attacks do you see an attacker could perform to perform malicious activities in OUR network by compromising the data collection server in their network?
  • Could he for example use the data download/streaming to establish a remote shell/beacon/something else in our network?
  • Is there at least a strong theoretical opportunity to bypass our firewalls, given that we are expecting data from that server anyway?
  • Or am I just wrong to worry and we should go ahead with the integration?

I've attached a purely hypothetical topological example picture that I drew in Packet Tracer, it doesn't depict a real network. The device models don't represent the actual devices. The client side may in reality be a vast network with hundreds of users. Still, hopefully it clarifies the example situation.

Topological example

  • 1
    FYI: data collection servers are a common and well-known approach for this kind of situation. You have to treat that server as an untrusted device.
    – schroeder
    Commented Feb 29 at 21:04
  • "high-level next-generation firewall": I would really like to know more about the next-gen firewall :)
    – ysdx
    Commented Mar 2 at 10:24
  • The devices from which the data is gathered might also ideally be on their own network. If they are security cameras, for example, they should 100% have their own network or VLAN. Same with manufacturing equipment, building management (e.g., HVAC), IP telephony, and all kinds of smart devices and IoT endpoints. Once the endpoints are separated, the data gathering server would naturally go along with them. Commented Mar 3 at 22:50

1 Answer 1


Unless you can prove otherwise you should never assume that any data entering your network from the outside are trustworthy. This includes data coming from your own device (data recording server) inside the clients network, unless you can assure that it is the actual device in the first place (i.e. authentication with some hardware anchor) and that it is not tampered with (remote attestation). Very likely you cannot ensure this, so don't trust.

This means that the security of your network depends on a) the security of your internal system which communicates with the client and b) how much a potential attacker can laterally move from a compromised internal system to the rest of the network.

In case of b) a firewall might offer some protection, but it needs to be a firewall which restricts not only the incoming data from the clients network to the internal system, but also the data outgoing from your internal system to the rest of your network. Your current architecture does not provide such micro-perimeter around your internal system.

It instead assumes that no bad data will ever pass through the firewall and thus the internal system might never be compromised. This assumption is false. You should instead assume that the data processing application on your internal system has security issues which can be exploited using malformed application data send from the client network. A firewall or intrusion prevention system will very likely not detect such exploits, since these are specific to your application. A firewall is good at blocking traffic at the network level, it is bad at detecting exploits at the application level and even worse if these are not well-known exploit patterns for commonly used applications but relevant only to some specific applications with rare deployments.

There are several mechanism to harden this setup, like having protocol gateways for deeper data analysis, sandboxing the receiving application at the internal system, deploying a restrictive micro-perimeter around the "exposed" system or at least moving it into a separate firewall zone away from the other internal systems, ... Don't rely on a single method, since all of these have limitations. Combine multiple defense methods in a defense in depth approach.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .