[unisog] Network Access systems?

Eric Weakland eric at american.edu
Sun Nov 20 15:12:47 GMT 2005


We purchased Perfigo right around the time they were acquired by Cisco and 
aside from having to deal with disappointing implementation assistance, 
support (at first) and some fits and niggles with Antivirus vendor support 
- we are very pleased.  Here's how we decided and to quote one of my 
professors - "apply prescriptively according to your situation."   Or if 
you prefer - "don't crack a walnut with a 10 pound sledge hammer."  A lot 
of these steps just involved getting together with the team and a 
whiteboard.  Start early.  We started Dec. 04, finished Resnet 
implementation in Aug. 05.  Still working on the rest of the campus.

Get strong support from as high up as you can.  We had a  mandate from the 
CIO.  (Unfortunately he and the university parted ways half way through 
the project, but I just chose to ignore that!)

Come up with the requirements (what you have to have) and use cases (user 
experience) for how you are going to use the solution.  Really work out 
what you want to accomplish on a computer (checks, scans, what types of 
users, how will you treat different OS'es, how often, what authentication 
base do you want to use, etc.) Think about what the staff burden will be 
too. (training, administration,documentation - more on this later) 

Then consider deployment model.  Is all the endpoint traffic going through 
the box or does it just manipulate the endpoint/port  - making this 
decision can involve looking at the capacity of your uplinks, reliability 
and redundancy. (This took some real thinking about how traffic moved at a 
layer 2 level in our environment.)  Decide which you prefer. 

Take a fresh look at the market landscape.  We made a conscious effort to 
not only look at commercial systems, but also at modifying our existing 
home-brew system (a layer 3 registration system) or building a new system 
using open source building blocks.  Compare each option against your use 
cases and preferred deployment model.  We did a matrix that showed which 
"could," "could not" or "not sure" for each of our requirements.  It was 
around this time that we also started figuring out how much each of the 
possible solutions would cost.  Lists like this one are invaluable when 
doing research, but you know that already.

Consider the risks posed by each of your choices.  (Failure Mode and 
Effects Analysis can be fun to use here!)  How can you reduce risk?  How 
much will it cost to reduce the risk?  Think about how you will justify 
your choices.  (especially important if you are having to fight for 
funding and/or expect to meet resistance.)  Think about futures - how will 
this work with what we are thinking about doing in a year? 

If we have time we like to do bake-offs at this point, but we didn't  have 
time with Perfigo/CCA. We just did a demo/test deployment and verified 
that we could accomplish our use cases.  Some things didn't work "as 
promised/implied" - like web AUP acceptance that didn't care if you 
clicked "Accept" or not! 

At this point we had Perfigo/Cisco and one other vendor at the top.   The 
facts that we were a Cisco shop, that Cisco promised that an out of band 
deployment model would be possible on much of our hardware in the future 
and their assurance that we would have no interoperability problems with 
VOIP made it our obvious choice. 

 Finally - what I didn't do that I wish I had. 

        1.  Document the need and ask for more staff/adjusted duties from 
the beginning.  My team was already over-worked and the time to properly 
administer a CCA deployment is not insignificant if you do it properly.  I 
should have had a firmer commitment for at least another FTE at an earlier 

        2.  Start thinking about what other systems you will need to 
integrate with early.  We are in good shape on this - but I should have 
done an information flow diagram after the requirements step above.  This 
doesn't have to be complicated, just map out what information you need 
shipped off to and brought in from what systems.  Help desk tracking 
systems, data warehouses, network management systems, LOGS, reports and 
graphs.  Brainstorm on this one - it can really pay off.

        3.  Do more propaganda.  Fighting rumors and getting accurate 
information out is important.  I would have bought more pizza, given away 
ipod shuffles and done demos to students before they left in the spring.

These are my opinions, not American University's.  Hope this helps.

Eric Weakland, CISSP
Director, Network Security
Office of Information Technology 
American University
eric at american.edu

You wrote:

We're in the process of researching our options as far as Network Access
systems go. Specifically, products like Bradford Campus Manager,
StillSecure, Sygate, Cisco CleanAccess (although we're not a cisco shop, 
probably not) or other varations.

We're looking for a system that can clean/scrub/quarantine bad machines 
do such a check on a regular basis. If it could be coupled with some form 
authentication, that would be bonus.

I'm just wondering if anyone out there has any experience with these
products on their campus, and if so, what have been the results so far.


Matt Ashfield
mda at unb.ca 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dshield.org/pipermail/unisog/attachments/20051120/c2bd1c31/attachment.htm

More information about the unisog mailing list