DRAFT
Sophos Services:
UCLA Prevention and Remediation Supporting the Mobile user
UCLA needs a production level distribution service to handle peak loads during a
virus outbreak. This service would consist of multiple redundant servers located across
different subnets. In case of the loss of one production server or one subnet, the client
would be set to fail-over onto the other sub-net as explained below. Can units organize
redundancy across subnets and departments?
UCLA needs enough staffing to operate a production level service. In terms of
survivability, we need to have some level of redundancy in personal. If something
should happen to the primary systems administrator (illness or other factor) in one group,
then a secondary group would have a common understanding and their primary systems
administrator could pick up the load. Creating redundancy across groups, with common
setup and deployment strategies would create the advantage of not working in isolation,
someone else could discuss settings, performance issues and provide a cross check.
There may be a need for additional staffing, or there may be a need for an organizational
time commitment to this project from each of the units deploying Sophos. Will Units be
able to commit this level of resources to the project?
UCLA needs an ongoing campus structure or organized group to help develop
specifications and test deployment. An organized group would review, test, and provide
feedback to help in the deployment and determining settings that would be optimal for
the users. Campus help desk leaders, System administrators, Security personal, would
provide the initial testing and feed-back to help with the initial roll-out and continual
product update.
Sophos - Technical details
Sophos is a distributed anti-virus product. In the Sophos model a department
would install the enterprise manager on a departmental server. This enterprise manager
regularly downloads updates from Sophos and then distributes those updates to the
network clients. Enterprise manager simply plugs into the Domain and functions in
much the same way as the McAfee epolicy orchestrater.
The enterprise manager has one additional function of keeping a local IIS web
server or departmental UNC up to date with current Virus definitions, so that remote
users can download Sophos and the latest virus definitions (IDEs) to a laptop or non-
domain computer. In the Sophos model each department would then update its own
domain based computers using enterprise manager, and update the laptops and non-
domain based computers using an IIS web server. .
1
DRAFT
Sophos
Departmental
Enterprise Manager
IIS Web distribution
As Sophos replaces the McAfee epolicy orchestrator at the departmental level
each department would then have the ability to set up a Sophos distribution point for their
local users on their departmental IIS server.
Many departments have not yet transitioned to Sophos with the exception of the
Residence Halls, UCLA Extension and Medical Enterprises. Without the departmental
model in place to handle the distribution of Sophos it will fall to the central departments
to maintain the points of distribution. First we need to understand the load and then look
at a potential distribution models.
The load calculations are based upon the maximum number of McAfee users in
the last academic year. Our McAfee distribution had 13,300 home users and 10,000 AVD
or departmental computers. If we consider the average IDE download is 5k then with
20,000 users we are looking at 100mb of traffic if all 20,000 users were to hit the server
at the same time. With a program download which happens about once a month the total
file download is roughly 300kb again with 20,000 users the total load would be 6,000mb
of traffic if all the users connected at the same time. With a 100mb/second sustained
through-put, the theoretical download time for all users doing a full download would be
60 seconds.
The Sophos settings for frequency of update and amount of bandwidth
consumed per update are tunable so the server load can be adjusted by changing client
settings which are then put into place at the next download cycle. So the bandwidth and
server output can be adjusted according to load. Sophos recommends using a 3 hour
update time.
The estimated initial setup time for the Sophos servers is about 60 hours and the
on-going maintenance time for the product should be about 20 hours a month to include
2
DRAFT
product testing, updates and tracking down questions and resolving some support issues
with departments and help desks. Initially, building in additional time to provide support
and problem resolution in conjunction with departments, may facilitate the deployment of
Sophos at the departmental level.
Each client has a setting for a primary and a secondary server. So in terms of
creating a more robust infrastructure we might be better served with four total servers on
two separate sites to handle the laptop and home user load. Geographically distributing a
pair of servers would offer redundancy in case of network failure or connection overload
during an outbreak or in case of other problem.
At one site, place a primary Server A and a secondary server B. At another
secondary site place a primary Server C and a secondary server D. Then establish a
mechanism so that each half of the download population uses a primary server at one site
and the secondary at the other.
The first client would set up as A primary and D secondary, while the second
client would set up as C primary and D secondary to assure a load balance and secondary
servers accessible from separate networks in case of failure. The servers should be
optimized for download and through-put as they would be doing little else other than
distributing files.
3