McAfee EPOLICY ORCHESTRATOR 3.6 - WALKTHROUGH GUIDE Manual page 57

System protection, a product overview and quick set up in a test environment version 3.6
Table of Contents

Advertisement

5
®
ePolicy Orchestrator
3.6 Walkthrough Guide
Rogue System Detection
The sensor packages the gathered information about the detected system into an XML
message. It sends this message via secure HTTPS to the ePolicy Orchestrator server
for processing. The server then queries the ePolicy Orchestrator database to determine
whether the system is a rogue system.
To save bandwidth in large deployments, you can configure how often the sensors send
detection messages to the server. You can configure the sensor to cache detection
events for a given time period, such as one hour, and then send a single message
containing all the events from that time period.
Choosing systems to host sensors
Systems on which the sensor is installed should be likely to remain on and connected
to the network all the time, such as a server. If you don't have a server running in a given
broadcast segment, deploy several sensors to several workstations to ensure that at
least one of them is connected to the network at any time.
Best practices information
To guarantee that your Rogue System Detection coverage is complete, you must install
at least one sensor in each broadcast segment of your network. Installing more than
one sensor in a broadcast segment does not create issues around duplicate messages
— the server filters any duplicate detection messages. However, additional active
sensors in each subnet results in traffic sent from each sensor to the server. While
maintaining as many as five or ten sensors in a broadcast segment should not cause
any bandwidth issues, you should not maintain more sensors in a broadcast segment
than is necessary to guarantee that the broadcast segment is covered.
Primary and inactive sensors
When deploying multiple sensors to the same subnet, you can configure how many are
actively reporting to the server at any one time (three by default). These are the primary
sensors. Any additional sensors you deploy are backups that remain inactive until the
ePolicy Orchestrator server makes them become active.
At regular intervals, the ePolicy Orchestrator server changes primary sensors so that it
is not dependant on any one sensor for too long. Also, if the primary sensor is disabled
or stops responding, the ePolicy Orchestrator server automatically assigns a different
sensor on that broadcast segment the role of primary sensor.
Subnet List
Subnets
The
table on the
tab of the Rogue System Detection interface allows
you to view the subnets in your network where you already have ePolicy Orchestrator
agents. From here you can deploy sensors to systems.
Configure sensor policy settings before deploying
Before you deploy sensors, you should configure the sensor policy settings to suit your
needs. These needs are probably the same for all sensors in your environment. Most
likely, you can configure sensor policy settings at the Directory root of the console tree
and let them inherit throughout the Directory.
54

Hide quick links:

Advertisement

Table of Contents
loading

This manual is also suitable for:

Epolicy orchestrator

Table of Contents