Installing sensors across several data centers: Standalone vs. ATP Sensor

Copper Contributor

In order to get full coverage of a large enterprise, besides installing on all DC's, should we install standalone sensors also? My thinking is that it is a good idea to have both types of sensors installed. 

 

Just got out of a design meeting where it was discussed that its either one or the other, not both. Any clarity on the subject would be helpful

 

Thanks 

8 Replies

Sensor duplication (monitoring a DC with more than one sensor) is not supported.

For best experience, use the integrated sensor, as it provide the complete set of detections AATP offers.

Standalone sensors provide only partial detection.

@Eli Ofek 

 

So if I understand you correctly, ATP Sensors are installed on all DC's and send alerts to ATP Cloud service. All other non-domain controllers are set up to send traffic to the standalone sensor and then the standalone sensor sends traffic to ATP. 

 

Is this correct?

@jbchris , pretty much, the sensor collects data we think is relative for detection and send it to Azure.

in standalone, you need to mirror traffic and forward windows events, but there are stuff you can't forward like ETW events. so the integrated sensor is far better is possible.

@Eli Ofek Is there an overview of what kind of use cases cannot be covered when using the Standalone Sensor? As of security related issues, we tend to proceed with the standalone sensors, thus the question. 

@CurlX  if you look at this alert list:

https://docs.microsoft.com/en-us/azure-advanced-threat-protection/suspicious-activity-guide?tabs=ext...

 

going into each one, you might see a note which contains "supported by ATP sensors only." that means using a standalone won't have this detection.

The integrated sensor is by far  more advance, as of today, less than 4% of covered DCs are protected with standalone sensors, and this number keeps dropping.

 

What is the mentioned security issue which tends you to using the standalone version which provides less detections and also much more expensive (dedicated hardware, port mirroring, event forwarding) ?

 

As for Internet hardening , there is an option to use a dedicated proxy, set only the sensor processes to use this proxy on the machine (we support that via the silent install) and limit the proxy to only connect to the AATP service tag (list of subnets we are using).

As for the load on the DC, the sensor has a resource manager that will make sure that the DC has at least 15% of free RAM and CPU. you can read about it in the docs.

 

out of the 4% of sensors we have as standalone, I am pretty sure a significant part of them are not due to security issues, but due to hardware limit sometimes, for example, if the current DC without the sensor is so load that it has no room for the sensor,  and it's a physical machine that can't be scaled up for any reason, then you are kind of forced to standalone until you can upgrade.

 

Note, that while you try to enhance security by separating the sensor from the DC, you are also hurting security by having much less detection on the DC.


We do not support partially mirrored traffic (And I am also sure it will be pretty hard to implement mirroring by protocol/ports).

 

Does the Ops team has any SPECIFIC concerns/use cases I can try to address?

"hardening"  in general is not something I can really comment on,  as I proposed hardening options above... which more than 96% of sensors wold wide are satisfied with (most of them are satisfied with much less...).
If they have specific concerns, I can try to comment on them or help in engaging someone  else who can if I don't have the answer.

@Eli Ofek This is very helpful information. I need to discuss this further in our organization and with the Ops Teams. I'll come back to you, if we have more uncertainities. Thx!